案例 04 · 城市规划研判

文字由原PDF提取，阅读顺序和表格请以原页为准。

常关键。项目发起人可能是副院长，但真正能协调10个部门、知道谁最难推动、谁掌握
什么数据的人，往往是下面那个负责总调度的人。我们必须先跟这个人聊透。
与此同时，我也给方案留了容错空间。如果某个部门暂时不给数据，我不会让整个项目
因此停下来。少一个部门，就先少做一个场景；少一类数据，就先让这一部分不参与计
算。但是最后整体链路必须能够跑通。
我当时给自己定了一个很简单的交付原则：“一文、一图、一表”必须出来。即使少一
个节点，核心交付形态仍然成立。这让我意识到，FDE做方案不能把每个环节都设计成
“缺一不可”，否则一个部门不配合，整个项目就会被拖死。
第二个挑战，是模型能力和数据安全之间的矛盾。
当时因为数据安全要求，生产环境不能随便使用国外模型。但那个阶段可选的本地模
型，在一些复杂任务上的效果又没有达到我们想要的状态。偏偏领导还会随时要求演
示。
这时候你会发现，做真实项目和做Demo完全不一样。Demo只需要“这一次跑得漂
亮”；生产系统则必须考虑安全、稳定、准确、可追溯。
所以我们后来会通过更明确的系统提示、工具封装和工程规则去弥补模型能力，同时把
真正需要精准计算的东西尽量交给专业工具，减少对模型自由生成的依赖。技术上，我
们选用混合部署，比如推理复杂场景的我们选用云模型，跑固定流程的我们走本地部署
模型，比如Qwen7b。
这也是我后来特别深的一个体会：模型能力只是整个系统的一部分，真正决定能不能上
线的，还有数据、工具、评估和兜底。
第三个挑战，是客户想要的“AI效果”不一定真的是最好的解法。
一开始客户希望做到“一句话出报告”。听起来很自然，但真正深入之后我们发现，如
果把它简单理解成意图澄清后，再把问题转成SQL去数据库查询，其实很难满足规划业
42/243