从人工研判到智能调度：FDE用AI重构城市规划研判流程

访谈资料整理：依据 Datawhale《FDE案例100》所收录访谈。案例叙述与成果均归属于原访谈，本站未进行独立项目审计。

原案例封面

为什么这个案例值得看？

城市规划选址涉及总体规划、详细规划以及交通、水务、市政、公共服务和产业等多部门信息。项目将空间数据、业务规则、专业知识、RAG 检索和工具调用组合进工作流，使一份跨部门规划报告由 3—5 天缩短到 10—20 分钟形成可继续推敲的初稿。

这个案例的价值不只在于采用了某种模型，而在于把数据、规则、系统和人工责任连接成可执行的业务链路。落地过程围绕问题识别、方案选择、交付路径、业务结果和关键难点展开。

一、企业与业务场景

城市规划这个行业本身比较特殊。

规划设计不是拿到一张表、做几个分析、生成一份报告这么简单，它背后有非常复杂的专业分工。

比如要规划一个方舱医院，首先是总体规划部门判断大概应该落在哪个片区；再往下，要看这个地方有哪些规划约束和规则；真正落到具体地块时，还要进一步考虑道路、水务、市政、公共服务、产业等一系列因素。

所以项目团队真正要打交道的，有大约10个部门。

更复杂的是，这个项目里不仅有普通的业务数据，还有空间数据。

以前项目团队做很多政务、电商或者其他企业项目，主要处理的是二维业务数据，也就是这个东西叫什么、属性是什么、参数是多少。

但城市规划多了一层空间关系。

一块工业用地，不仅要知道它的业务属性，还要知道它具体落在地图上的哪个坐标、和周围哪些道路或设施发生关系。

除此之外，每个部门还有自己的专业工具、业务语义、数据规则和工作流。

所以随后，FDE总结，这个场景真正的难点，是把业务、数据、空间、工具这四件事情连起来。

而且最后还有第五件事，就是人。

因为10个部门的人工作方式不一样，对同一个指标的理解也可能不一样。

FDE必须把他们真正使用的业务语言、计算规则和工作流程理解清楚，否则AI生成出来的东西看起来很专业，真正的规划师一看就知道不对。

为什么这个问题值得做？

因为城市规划本身正在发生变化。

过去城市快速扩张的时候，很多规划是在增量空间里做选择；现在更多是在已有城市空间和存量地块里找最优解。

规划做得越来越精细，决策涉及的约束也在变多。

而规划师原来的工作流程又非常重。

领导可能只说一句：“帮业务人员看看识别下xx区域的潜力用地有哪些？”下面的人就要开始查资料、调数据、做空间分析、跑工具、讨论，最后才能形成报告。

所以项目团队最开始看到的机会，是能不能先把规划师每天反复做、规则相对明确、数据能够追溯的那部分工作接下来，让人把时间留给真正需要判断和创新的事情。

这也是随后，FDE判断一个场景值不值得用AI的一个基本标准：它是不是重复发生？

重复成本是不是足够高？

工作流能不能定义？

背后的事实和数据能不能追溯？

涉及的专业工具能不能被调用？

如果这些条件都不存在，只是为了“AI First”硬找一个场景，项目实践表明没有必要。

二、原有流程与核心问题

其实规划设计院原来的数字化程度并不低。

他们不缺软件，使用的专业软件反而非常复杂。

规划师本身也是典型的高数字素养人群。

过去接到一个规划任务后，规划师通常先查大量资料，再进入GIS类专业工具，叠加不同图层、运行脚本、做空间计算和标注，然后根据结果形成自己部门的判断。

如果最后是一份综合规划报告，还需要把多个部门的分析再汇总起来。

一个人的单项分析，过去可能需要一个小时左右；一份跨部门的完整报告，专业人员通常也需要3—5天，有时候接近一周。

这个时间不能说明他们效率低，真正的原因是城市规划对精度要求非常高。

一条道路画在哪里、一个地块碰没碰到历史文化保护线、一个区域的污水承载能力够不够，这些都不能随便回答。

规划一旦出错，后续可能影响真实建设，所以很多结果必须反复核对、修改和讨论。

比如做选址。

系统可能先筛出20块候选地块，但最后从20块里面挑出真正适合的10块，过去往往还需要不同部门开几轮会，结合各种专业指标继续判断。

所以传统方式其实有它存在的合理性：专业人员掌握规则，专业工具保证计算精度，人的经验负责最终判断。

问题是随着需要考虑的数据、规则和部门不断增多，这套流程也越发沉重。

大量专业人员的时间被消耗在查资料、找规则、切换工具、重复计算、整理报告这些事情上。

这也说明，规划院的数字化工具其实一直在，只是它们解决的是单个环节的计算精度，没有一个角色把业务、数据、空间和工具真正连接起来，于是跨部门、跨工具的流程依旧靠人来串联。

因此项目团队做AI改造的时候，没打算把传统流程推翻。

FDE的思路反而是，原来正确的东西尽量留下，把机器更擅长的部分接过去。

三、AI 解决方案与交付路径

这个项目带来的一个重要启发是，FDE要先进入现场，再决定到底应该用什么。

第一步，先把自己逼成“半个规划师”。

城市规划这个行业很专业。

刚进去的时候，他们有很多专业册子，非常厚。

很多术语如果项目团队不知道，根本没办法跟业务人员继续聊。

比如对方问项目团队“候选地块是什么意思”“潜力用地分析是什么意思”，如果连这些基础业务概念都答不上来，后面其实很难建立信任。

所以当时，FDE给自己的要求是，先把自己变成他们中的一员。

FDE不需要真的达到规划师的专业水平，但至少要知道他们每天在干什么，为什么这么做，一个指标到底代表什么，一种空间计算为什么这么算。

项目团队会到不同部门去聊，把他们数值的意义、空间计算方式、业务指标、工作流程一点点搞清楚。

这一步看起来不像“做AI”，但项目实践表明恰恰是FDE最核心的工作。

因为只有理解业务，项目团队才知道什么应该交给模型，什么应该交给专业工具，什么必须留给人。

第二步，先不做本市，先把问题缩到足够小。

如果一开始就把全市的数据、所有部门、所有第三方系统、所有业务规则全部接进来，项目很容易陷入一个永远做不完的数据工程。

所以项目团队后来主动收敛。

从整个市，缩到一个区，再缩到类似米市巷这样的具体单元，然后只挑两条明确的业务流验证。

这个决策后来项目实践表明非常重要，场景足够小，数据才有可能搞干净；数据搞干净，结果才可能足够精准；结果足够精准，业务人员才愿意相信。

所以一期项目团队没有把所有第三方系统和数据中台全部接进来，只让参与试点的部门先筛选真正需要的数据，把这一小块场景的数据治理好。

第三步，把“数据、知识、报告”三个底座先做扎实。

项目团队当时为什么敢说20分钟生成的报告是“可推敲”的？

主要靠的是底下三件事。

第一是数据。

报告里的关键数据尽量来自规划院提供的真实数据，并通过专业计算得到，不让模型自己猜。

第二是知识。

项目团队把相关规划规则、专业文档等知识整理出来，通过检索增强的方式让AI能够找到依据。

比如一个写字楼为什么不能建在某个位置，可能是碰到了历史文化保护线。

过去规划师要去大量PDF里找相关规定，现在可以更快定位到对应规则。

第三是报告模板。

不同部门原来都有自己的报告习惯，项目团队把各部门模板以及行业里的模板拿过来，最后归纳出一个相对通用的输出结构。

所以最后AI是在真实数据、专业规则和固定报告结构里工作，不再凭空写作。

第四步，让AI调度专业工具，把计算留给工具。

这个也是项目团队后面非常重要的一个判断。

很多规划计算其实有明确规则。

既然有专业GIS工具能够精准计算，就没有必要让大模型自己算。

所以项目团队的分工慢慢清晰起来：模型负责理解和分析，专业工具负责事实和计算，人负责最终决策。

AI更像一个调度者。

比如规划师提出一个选址任务后，AI理解他的意图，再调用对应的数据和专业工具完成分析，把计算结果返回出来。

对于高频、规则明确的任务，项目团队更倾向于把它固化成工作流；对于城市研判、潜力用地分析这种长尾、开放性更强的问题，再交给Agent处理。

第五步，产品要顺着原来的工作习惯长出来。

项目团队没有把所有东西都变成一个聊天框。

因为规划师真正工作的中心是地图。

所以最后的交互仍然保留了他们熟悉的方式。

左边是筛选条件和专业工具，中间是地图，右边才是Copilot。

AI调用工具或者完成分析后，结果会直接回显到地图上。

这件事情随后，项目实践表明很重要。

做AI产品很容易陷入一个误区：既然有Agent，就把所有功能都塞进一个输入框。

但FDE要考虑的是用户原来怎么工作。

地图才是规划师真正的工作台，AI就应该围绕地图服务，让规划师继续按原来的方式工作，不必为了AI重新学一套工作方式。

四、项目结果与业务价值

变化最先反映在时间上。

过去一份跨多个部门的完整规划报告，通常需要3—5天，有时接近一周。

现在在已经跑通的试点流程里，大约10—20分钟就可以形成一份能够继续推敲和交付的报告。

如果只看单个部门，过去一个小时左右才能完成的一些分析和表格，现在大约5—10分钟就可以完成。

一期涉及大约10个部门，目前大概有20—30名专员在使用。

但随后，FDE慢慢意识到，这个项目真正的价值远不止“3—5天变成20分钟”。

还有两个变化更重要。

第一个是，规划师开始从大量重复操作里脱离出来。

以前很多时间花在查资料、找规则、操作工具和整理结果上。

现在这些工作被压缩以后，人可以把更多精力放在真正需要专业判断的事情上。

而且AI有时候会给出一些原来工作流之外的潜在分析因子。

比如判断一个区域经济活跃度，过去可能看交易、车流等传统指标，但AI可能提示还可以观察停车场闸机频率、房屋空置率、人口画像等其他信号。

这些建议未必直接就是答案，但它能给规划师提供新的研究视角。

第二个变化，是组织本身开始发生变化。

第一期项目团队陪着不同部门一起梳理工作流。

后来有些部门已经开始自己把“识别、计算、处理、输出候选地块”这样的流程沉淀成Skill。

也就是说，他们已经在学习怎么自己搭AI工作流。

从项目实践看，这才是FDE和传统外包很不一样的地方。

好的FDE项目，是交付结束以后客户自己开始长出AI能力。

项目图示

原案例图示（PDF 第 41 页）

原案例图示（PDF 第 42 页）

原案例图示（PDF 第 44 页）

五、关键落地难点

当然有，而且真正难的问题很多都不在模型。

第一个挑战，是部门不一定愿意给项目团队数据和规则。

10个部门里，有人天然支持AI，也有人心存顾虑，担心这套东西上线以后会影响自己的岗位和价值。

所以项目团队去问业务规则、要数据的时候，有的人回复会很慢，甚至直接说：“这些网上都有，业务人员们自己查。”但实际上很多规则只有真正做业务的人才知道。

这个时候，FDE不能只靠技术解决。

FDE慢慢摸清了一个规律，在这种复杂组织里，找到真正能推动项目的“执行一号位”非常关键。

项目发起人可能是副院长，但真正能协调10个部门、知道谁最难推动、谁掌握什么数据的人，往往是下面那个负责总调度的人。

项目团队必须先跟这个人聊透。

与此同时，FDE也给方案留了容错空间。

如果某个部门暂时不给数据，FDE不会让整个项目因此停下来。

少一个部门，就先少做一个场景；少一类数据，就先让这一部分不参与计算。

但是最后整体链路必须能够跑通。

当时，FDE给自己定了一个很简单的交付原则：“一文、一图、一表”必须出来。

即使少一个节点，核心交付形态仍然成立。

这让FDE意识到，FDE做方案不能把每个环节都设计成“缺一不可”，否则一个部门不配合，整个项目就会被拖死。

第二个挑战，是模型能力和数据安全之间的矛盾。

当时因为数据安全要求，生产环境不能随便使用国外模型。

但那个阶段可选的本地模型，在一些复杂任务上的效果又没有达到项目团队想要的状态。

偏偏领导还会随时要求演示。

这时候可以看到，做真实项目和做Demo完全不一样。

Demo只需要“这一次跑得漂亮”；生产系统则必须考虑安全、稳定、准确、可追溯。

所以项目团队后来会通过更明确的系统提示、工具封装和工程规则去弥补模型能力，同时把真正需要精准计算的东西尽量交给专业工具，减少对模型自由生成的依赖。

技术上，项目团队选用混合部署，比如推理复杂场景的项目团队选用运模型，跑固定流程的项目团队走本地部署模型，比如Qwen7b。

这也是随后，FDE特别深的一个体会：模型能力只是整个系统的一部分，真正决定能不能上线的，还有数据、工具、评估和兜底。

第三个挑战，是客户想要的“AI效果”不一定真的是最好的解法。

一开始客户希望做到“一句话出报告”。

听起来很自然，但真正深入之后项目团队发现，如果把它简单理解成意图澄清后，再把问题转成SQL去数据库查询，其实很难满足规划业务的复杂性。

所以项目团队建议把“万能问数”先放一放，让AI理解任务以后调用真正的专业工具完成处理。

到了后续阶段，又出现过类似的问题。

比如大家会期待“多智能体博弈”：法律专家、经济专家、民生专家坐在一起讨论一个规划议题。

听起来很先进。

但项目团队真正分析业务后发现，有些选址问题最终还是依赖明确的规则和指标计算。

这种情况下，强行做多智能体，不但架构更复杂，上下文在多个智能体之间传递还可能带来歧义、丢失和污染，结果反而不够收敛。

所以项目团队的思路慢慢变成，表面上可以体现不同专业视角，但底层未必真的需要多个Agent互相聊天，可以把不同专业能力封装成工具，由一个核心Agent统一调度。

甚至某些寻找最优解的问题，本身就不一定应该用大模型，传统优化算法可能更加精准。

这个过程让FDE越发笃定，FDE的职责是帮客户判断，什么地方真的应该用AI，什么地方不应该。

六、FDE 交付方法与企业启示

做完这个项目以后，项目对FDE角色定位的最大启发，是不再觉得FDE首先是一个“懂模型的人”。

第一，先进入业务。

如果做律师业务，就真的跟着律师跑一遍；如果做城市规划，就想办法让自己成为“半个规划师”。

很多企业表面上说出来的问题其实不是真问题。

只有真正跟着他们把工作流跑一遍，进一步追踪后可以看到，哪些事情每天都在重复，真正贵的成本在哪里，哪些步骤看起来不起眼却决定最后结果。

第二，不要一上来做大。

项目团队这个项目一开始也可以讲一个很大的故事：整个市、所有数据、所有规划场景全部智能化。

但真正让项目跑起来的，是不断收敛。

从一个城市缩到一个区域，再缩到一个具体单元，再挑两条工作流。

先找到一个足够小、足够真实、能够形成闭环的场景，跑通之后，再扩。

第三，不要迷信技术先进性。

客户要的是解决问题，不是技术框架。

硬编码能解决，就可以硬编码；若当前任务固定工作流合适，就用工作流；若当前任务较灵活，Agent适合开放任务，就用Agent；若当前任务需颗粒度小，传统算法比大模型精准，就用传统算法。

项目更强调，模型、数据、工具、人和评估怎么组合起来，形成一个真正可交付的系统。

尤其是评估和兜底。

Demo很好做，真正难的是，数据错了谁发现？

模型给错建议怎么办？

计算结果能不能追溯？

最后谁对决策负责？

这些问题解决不了，再酷的Demo也进不了真实业务。

第四，理解FDE团队的角色也会变化。

FDE在这个项目里其实经历了三个阶段。

最开始，FDE像一个新人和助理，先进去学习他们的行业，把自己变成他们中的一员。

完成业务理解后，FDE开始帮助他们重新定义问题、设计流程、判断哪些地方适合用AI。

再往后，当他们自己已经会做Skill、会Vibe Coding、会尝试搭自己的AI应用时，FDE的角色又变了。

这时候FDE不一定还要替他们写每一个功能，可以站到更高一点的位置，告诉他们下一步有哪些坑，架构怎么选，哪些方向值得投入。

所以项目进一步说明，FDE最终做的，是陪企业重新审视一遍自己的业务，找到真正的问题，把业务知识变成可执行的流程，再把AI放到最适合它的位置上。

项目团队要像“竹子”一样扎进去，当有一天，客户自己开始理解AI、改造工作流，甚至能够自己做新的Skill时，这个项目才真正从一次技术交付，变成了企业内部持续生长的AI能力。

七、可复用的交付资产

同类项目若要复制这条路径，可以优先沉淀以下交付物：

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• 知识地图、文档清洗规则、切片规范和高频问题测试集
• Agent 工作流定义、工具调用清单、提示词版本和任务评测集
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径
• 人工审核、失败回退、上线巡检和持续迭代清单

来源与作者

Datawhale《FDE案例100》，受访者：杜天宇（杭州恺瑞科技AI解决方案专家、FDE）；PDF 第 34-46 页，书内页码 33-45。本文为访谈资料的第三人称整理，不是本站新采访。