城市规划的 AI 不是万能问数，而是会调用工具的地图 Copilot

城市规划不是拿到一张表、做几个分析、生成一份报告这么简单。

一次选址任务，可能要经过总体规划、道路、水务、市政、公共服务和产业等多个部门；除了普通业务数据，还要处理地块坐标、周边设施和空间关系。规划师需要查资料、叠加图层、运行专业工具、做空间计算、讨论结果，最后形成综合报告。

这个案例里，跨部门完整报告过去通常需要 3 到 5 天，有时接近一周。试点流程跑通后，报告可以在约 10 到 20 分钟形成一份能够继续推敲和交付的初稿。

但真正值得写下来的，不是“3 天变 20 分钟”，而是 AI 没有试图替代 GIS 工具和规划师。模型负责理解任务与调度，专业工具负责事实与计算，规划师负责最终判断；AI 也没有变成一个万能聊天框，而是围绕地图工作台提供 Copilot。

落地场景：从跨部门研判中接走重复工作#

规划师每天要处理的任务，往往从一句很短的领导需求开始：“帮我识别一下某区域有哪些潜力用地。”这句话背后，却包含资料查找、规划规则核对、空间分析、专业计算、跨部门讨论和报告整理。

原有数字化工具并不少，规划院甚至使用着复杂的专业软件。问题是，软件解决了单个环节的计算精度，却没有人把业务语义、空间数据、专业工具和跨部门流程连接起来。

因此，项目优先选择那些重复发生、规则相对明确、数据能够追溯、专业工具可以调用的工作：候选地块筛选、潜力用地分析、跨部门报告和相关表格整理。规划师继续掌握专业判断，机器接手查找、计算、汇总和格式化等重复劳动。

落地难点：空间关系和组织关系同样复杂#

规划数据不只有属性，还有位置和关系#

二维业务数据可以描述名称、参数和属性，但城市规划还要知道一块地具体位于哪里、与道路和设施有什么关系、是否碰到历史文化保护线或其他空间约束。

如果只把规划材料交给模型，让模型凭语言生成答案，就会失去空间计算的事实基础。空间关系必须由专业数据和工具处理，模型不能替代 GIS 的精确计算。

十个部门不一定共享同一套语言#

项目需要与大约 10 个部门协作。不同部门对同一个指标的理解、计算方式和工作流程可能不同，很多规则也只掌握在真正做业务的人手里。

这意味着 FDE 必须先把自己变成“半个规划师”：理解候选地块、潜力用地分析、指标含义和空间计算逻辑，否则生成的内容即使表面专业，规划师也会立刻发现不对。

先进的 AI 形态不一定是最好的解法#

客户一开始希望“一句话出报告”，后续也有人期待法律、经济、民生等多个 Agent 互相博弈。但很多选址问题依赖明确规则和指标计算，强行让多个 Agent 对话，反而会增加上下文丢失、歧义和结果不收敛的风险。

FDE 要帮助客户判断，哪些任务适合工作流，哪些任务适合 Agent，哪些任务应该交给传统算法或专业工具，而不是为了展示先进架构把所有问题都变成 Agent 对话。

如何落地：先收敛范围，再让 AI 调度工具#

第一步，进入行业，建立共同语言#

团队从不同部门了解数值含义、空间计算方式、业务指标和工作流程，先弄清楚规划师每天做什么、为什么这样做。

这一步决定了后续的责任边界：什么交给模型理解，什么交给专业工具计算，什么必须留给人来判断。

第二步，把全市问题缩小到可验证单元#

一期没有把整座城市、所有部门和所有第三方系统一次性接进来，而是从全市收敛到一个区，再缩到类似米市巷这样的具体单元，只选择两条明确业务流验证。

场景足够小，数据才可能治理干净；数据干净，结果才可能足够精准；结果精准，业务人员才愿意相信。试点阶段只接入真正需要的数据，而不是先做一个永远完成不了的全量数据工程。

第三步，先把数据、知识和报告底座做扎实#

AI 生成的报告要能够继续推敲，至少需要三层底座：关键数据来自真实业务数据并经过专业计算；规划规则和专业文档通过检索增强提供依据；不同部门的报告习惯被归纳成相对稳定的输出结构。

这样，AI 工作在真实数据、专业规则和固定报告结构里，而不是凭空写一份听起来合理的报告。

第四步，让模型调度工具，让地图保留为工作台#

对于高频且规则明确的任务，项目将其固化成工作流；对于城市研判和潜力用地这类开放性更强的任务，再让 Agent 理解规划师意图并调用相应工具。

最终交互保留规划师熟悉的地图工作台：左侧是筛选条件和专业工具，中间是地图，右侧是 Copilot。分析结果直接回显到地图上，规划师不需要为了 AI 重新学习一套工作方式。

落地成果：时间缩短，更重要的是能力开始留在组织里#

在已经跑通的试点流程里，跨多个部门的完整报告从过去 3–5 天、有时接近一周，缩短到约 10–20 分钟形成可继续推敲和交付的报告；单个部门的部分分析和表格，从约 1 小时缩短到约 5–10 分钟。一期涉及约 10 个部门，约 20–30 名专员使用。

变化前	落地后的变化
查资料、找规则、切换工具和整理报告占据大量时间	AI 统一理解任务并调度数据与专业工具
跨部门报告通常需要 3–5 天	试点流程下约 10–20 分钟形成可推敲结果
规划师围绕多个系统手动串联工作	地图继续作为工作台，AI 结果回显到原工作环境
工作流经验主要依赖项目成员	部门开始把识别、计算、处理、输出沉淀成 Skill

更深层的成果是组织开始长出自己的 AI 能力。FDE 陪不同部门梳理流程，后来有些部门已经能够自己沉淀 Skill、尝试搭建 AI 工作流。

这也是 FDE 和传统外包的区别：不是每个功能都永远由外部团队代做，而是交付结束后，客户更理解自己的业务流程，也更有能力继续改造下一条工作流。

这个案例给 FDE 的四个提醒#

第一，先把自己变成“半个行业专家”，再决定 AI 负责什么。不了解业务，就无法判断哪些结果必须有依据、哪些计算必须调用工具。

第二，不要一上来接全量数据和全市场景。先找到足够小、足够真实、能够形成闭环的业务单元，再逐步扩大范围。

第三，把模型、数据、工具、人和评估一起设计。模型能力只是系统的一部分，安全、准确、可追溯和兜底同样决定能不能上线。

第四，产品要顺着原有工作习惯长出来。规划师的工作中心是地图，AI 应该围绕地图服务，而不是把所有功能塞进一个输入框。

来源与边界#

• 原始资料：Datawhale《FDE案例100.pdf》，案例四“从人工研判到智能调度：FDE用AI重构城市规划研判流程”，案例访谈正文位于 PDF 第 35–46 页。
• 案例事实：过去跨部门完整报告通常需要 3–5 天，有时接近一周；试点流程约 10–20 分钟形成可推敲报告；单部门部分分析从约 1 小时缩短到约 5–10 分钟；一期约 10 个部门、20–30 名专员使用。
• 结果边界：这些数字来自已经跑通的试点流程，不代表所有规划任务都能达到相同速度，也不等于报告可以跳过专业人员复核和最终决策。
• 产品化解读：关于地图 Copilot、工具调度、范围收敛和组织能力沉淀的总结，是基于案例事实的产品化分析。