← 案例目录DATAWHALE / FDE

案例 04 · 城市规划研判

Datawhale原书章节 · 印刷页码 33—45 · 当前仅加载一页

Datawhale《FDE案例100》,案例04,原书第44页;下方可展开文字版

原书第 44 页 · 点击页面可放大查看

查看与复制本页文字

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

如果做律师业务,就真的跟着律师跑一遍;如果做城市规划,就想办法让自己成为“半
个规划师”。很多企业表面上说出来的问题其实不是真问题。只有真正跟着他们把工作
流跑一遍,你才会发现,哪些事情每天都在重复,真正贵的成本在哪里,哪些步骤看起
来不起眼却决定最后结果。
第二,不要一上来做大。
我们这个项目一开始也可以讲一个很大的故事:整个市、所有数据、所有规划场景全部
智能化。但真正让项目跑起来的,是不断收敛。从一个城市缩到一个区域,再缩到一个
具体单元,再挑两条工作流。先找到一个足够小、足够真实、能够形成闭环的场景,跑
通之后,再扩。
第三,不要迷信技术先进性。
客户要的是解决问题,不是技术框架。硬编码能解决,就可以硬编码;若当前任务固定
工作流合适,就用工作流;若当前任务较灵活,Agent适合开放任务,就用Agent;若
当前任务需颗粒度小,传统算法比大模型精准,就用传统算法。
我现在更看重的是,模型、数据、工具、人和评估怎么组合起来,形成一个真正可交付
的系统。尤其是评估和兜底。Demo很好做,真正难的是,数据错了谁发现?模型给错
建议怎么办?计算结果能不能追溯?最后谁对决策负责?这些问题解决不了,再酷的
Demo也进不了真实业务。
第四,理解FDE自己的角色也会变化。
我在这个项目里其实经历了三个阶段。最开始,我像一个新人和助理,先进去学习他们
的行业,把自己变成他们中的一员。等我理解业务以后,我开始帮助他们重新定义问
题、设计流程、判断哪些地方适合用AI。再往后,当他们自己已经会做Skill、会Vibe
Coding、会尝试搭自己的AI应用时,我的角色又变了。这时候我不一定还要替他们写每
一个功能,可以站到更高一点的位置,告诉他们下一步有哪些坑,架构怎么选,哪些方
向值得投入。
44/243