一份漂亮到挑不出毛病的架构图，一落地就寸步难行。
杀死它的往往跟架构没关系，是顺序反了。
这篇讲讲 Palantir 二十年前发明 FDE 的那套办法，为什么恰恰是园区运管该用的。
作者 | 听风
编辑/排版 | MM77
翠鸟AI技术漫研 — 拓新AI边界、探索技术增量
我们大概都见过这样一份文档：
几十页，甚至上百页。架构图层层嵌套，从数据底座画到语义引擎，再画到智能体编排、多路召回、事实校验，术语专业得让你插不进嘴。
写这份文档的人显然是个高手——语义层不加 API 而加 Metric 和 Capability，用证据图谱去区分相关性和因果，这些心思，一看就是资深架构师才想得出来的。
一页页读下去，我们几乎挑不出毛病。但合上文档，心里总有个声音在问：这东西，真能落地吗？
我见过太多这样的方案。当蓝图看，它无懈可击；可它是要在半年内交付的工程，一落地就寸步难行。
杀死它的往往跟架构没关系——数据库没选错，框架也够新。真正的病根特别朴素：顺序反了。
园区 AI 项目最典型的死法，病根不在架构，在顺序。
它和 CIA 那摊活是同一种难：没法提前写清楚。所以它天生是 FDE（驻场工程师）的活。
三条铁律——脏数据是上工第一天就得干的活、第一天就交付一条能跑的窄竖线、先修糙路再铺高速。
把这三条倒过来做，就是把最脏的数据当前提、把没人够得着的准确率写进验收、十几个阶段线性平推，也就是 AI 中台项目一犯再犯的标准死法。
正确顺序只有一个：先下场趟泥，再回办公室画图。
01. 一个二十年前的“故事”
要讲清楚“顺序”为什么是生死线，得先回到二十年前。
Palantir 最早的客户是 CIA、NSA、美国陆军情报单位。这些客户有个让所有软件公司抓狂的共同点：他们说不清自己要什么。
不是他们笨。是情报分析这件事本身，就没法先写清楚再开工。
威胁天天在变，今天的需求明天就作废；数据涉密，分析师不能把它摊开给外部供应商看；连他们自己的工作流都在不停漂移。
传统软件那套铁律——“你把需求写清楚，我回去开发，三个月后交付验收”——在这里彻底失灵。你连需求文档都拿不到，谈何按文档交付。
Palantir 的联合创始人 Shyam Sankar 后来有一句话，点破了整件事的本质：
能靠一份需求文档解决的问题，早就被解决了。
于是他们干了件在当时看来很不像软件公司的事：
不再隔着桌子跟客户要需求了，直接把顶级工程师塞进客户办公室，让他坐在分析师旁边，看着人家怎么干活，一头扎进那摊谁也没整理过的脏数据，当场写代码。
这个角色叫 Forward Deployed Engineer，驻场工程师，简称 FDE。
这个模式后来长到什么程度？到 2016 年，Palantir 的驻场工程师人数，比它的普通软件工程师还多。
今天你听到的 OpenAI、Anthropic、Databricks 都在抢着招 FDE，抄的都是 Palantir 这本二十年前的作业。
我越琢磨园区运管这类项目，越觉得它跟 CIA 那摊活是一路货色，得靠 FDE 这么干。
可现在市面上的方案，几乎全是“分成十几个阶段线性铺开”的那种。
02. 园区的难，和 CIA 的难是同一种难
这个类比听起来有点唬人：园区又不涉密，数据也摊得开，凭什么和 CIA 相提并论？
类比的点根本不在涉不涉密，在一件更要命的事上：这活儿没法提前写清楚。
举几个园区里最常见、听上去简单到不值一提的需求：
“帮我看看 B 座地下二层现在还有几个空车位。”
“这台新风机组昨晚为什么离线了？”
“上个月哪几家租户的能耗异常，帮我拉个单子。”
每一句都简单得像不需要做系统。
可你真下场去接，就会撞见一整面墙的脏东西：
- 空车位这个数，园区里根本没有实时的来源。
地磁、道闸、视频识别三套系统各说各话，要么没打通，要么根本还没建，得指望甲方侧新立项去对接 IoT 和楼宇自控。
你方案里写的“实时状态管道”，本质上是一张开给甲方的期票——不是你能交付的东西。
- 那台新风机组，在设备台账里叫“AHU-B2-07”，在楼控系统里叫“B2 空调 7 号”，在运维工单里被师傅手写成“二楼那个总跳的空调”。
三个名字指同一台设备，但没有任何一张表告诉系统它们是同一个。
把这种台账和楼控点位对齐，往往就是俩人对着屏幕抠上小半个月的活，末了还会剩一批怎么都对不上、只能挂着存疑的。
所谓“主数据映射”“实体关系”，就是这么一条一条抠出来的，工作量大得吓人。
- 至于“帮我拉个单子”，用户嘴里的中文口语能有八种指代方式——“上个月”是自然月还是最近三十天，“异常”是同比还是环比，“哪几家”要不要含物业自用。
多轮对话里一个“它”字，指代的可能是三句话之前提到的那栋楼。
这些东西，没有一样能提前写进需求文档。
它们只在一个地方存在：现场那摊没人整理过的真实数据里，和运营人员每天真实的嘴里。
你不蹲下去、不把手伸进泥里，你就永远只能在白板上假设它们已经是干净的。
而一旦你在方案里假设它们已经是干净的，你就已经输了。
这就是园区运管天生属于 FDE 的原因：
它的核心难度，恰好落在需求文档覆盖不到的地方。
03. FDE 的三条铁律，条条戳在软肋上
那么 FDE 到底怎么干活？剥开各种包装，就三条。而这三条，条条戳在园区项目最爱犯的错上。
- 第一条：脏数据是你上工第一天就得干的活，别指望谁把它收拾干净了交到你手上。
几乎每一份宏大方案，都会在某个章节轻描淡写地写上一句：“假设数据已接入、实体已统一映射。”然后把这句话当地基，往上盖三层楼。
问题是，这句话本身，恰恰是整个项目里最难、最脏、最吃人的那部分。
主数据从哪来、几十个系统的实体关系谁去理清、历史数据的空洞谁去填——这些加起来常常是六成以上的工作量。
你用一句“假设已完成”把它划走，问题一点没少，只是把最硬的一块骨头，悄悄塞进了地毯底下。
等真到了要落地的那天，地毯一定会鼓起来，而且是在最不该鼓起来的时候。
FDE 的做法正好相反。他进场第一件事，就是趟这摊泥。
那张所有人都想要的“语义底座”、那个漂亮的本体模型，从来没有谁递成品给他，全是他蹲在现场、对着一张张烂表、一条条错数据，一天天亲手喂出来的。
在 FDE 的字典里，数据治理压根就是工作本身，谈不上什么前置条件。
- 第二条：第一天就交付一个真能跑的东西。别调研九十天，最后只交一份 PPT。
传统交付有两种让人熟悉的姿势。
一种是咨询顾问式的：进场先访谈、调研、梳理现状，忙活九十天，交出一份厚厚的诊断报告和实施建议，一行能跑的代码都没有。
另一种是售前工程师式的：给你演一个漂亮的 demo，签完单，转手甩给交付团队，自己抽身走人。
FDE 两种都拒绝。他进场第一周，就得让客户看到一个活的东西——一条真能查询、真能出结果、跑在客户真实数据上的功能竖线。
哪怕它很丑，哪怕它只覆盖“设备报警”这一个场景，哪怕它背后的数据只清洗了一个域。要的就是它是活的。
为什么死磕这第一周？
因为你在一条真实的窄竖线上跑一遍，撞见的真问题，比在白板上推演十几个阶段学到的多一个数量级。
你会当场发现报警数据的时间戳一大半是乱的，某个你笃定一定有值的关键字段其实半数是空的，运营压根不看你以为他会盯着看的那个指标。
这些坑白板上永远推不出来，非得跑起来它才蹦出来砸你一脸。所以头三周越难看，我反倒越踏实——说明真问题已经开始往外冒了。
- 第三条：先修一条能走的糙路，再谈把它铺成高速。
Palantir 内部把这套叫“从砂石路到高速公路”。先给某一个具体场景做一个粗糙但能用的解——砂石路，坑坑洼洼但车能过去。
跑通了、被真实使用了、验证了这个模式确实成立，再回过头把它抽象成平台级的能力——铺成高速。
Foundry 这套东西就是这么从一个个客户现场的糙解里长出来的，没人在总部先设计好再下发。
反过来是什么样？一上来就要把十几条车道的高速一次铺完：
MySQL、Redis、Neo4j、Kafka、Debezium、向量库，外加一堆常驻的消费者进程，全怼进第一个版本。
这套栈本身没错——放在一个有几十号人常年维护的大厂中台里，它很合理。
但你把它整个搬来做一个项目制的园区交付，就是彻头彻尾的资源错配。项目现场根本配不出这么多能持续运维这套栈的人，上线那天就是运维噩梦的开始。
而且同一份能力，还能同时套上 Claude Code 的技能、套上 MCP、套上一个普通 API——dsh 只是它众多出口里的一个，不是唯一的那个。
04.把这三条倒过来，就是标准死法
现在你大概已经看出来了。园区 AI 项目最典型的死法，就是把上面这三条，一条一条，精确地反着做：
- 把最脏的数据当成已完成的前提，划走六成工作量。
- 把一个没有任何公开系统能达到的指标——比如中文多轮口语理解的“九成九意图准确率”——不但写进方案，还堂而皇之地写进正式验收标准。
- 这一条尤其致命：它等于在立项那天，就亲手给项目埋下了一颗注定验收失败的雷。
- 做到九成八，甲方拿着白纸黑字的九成九说你没达标；你有理说不清，因为字是你自己签的。
- 再把十几个阶段线性排开，Phase 1 到 Phase 13 一路平推，前三个月没有任何一个能点开看的东西。
这套组合拳打下来，问题的根子其实不在架构。那张架构图可能真的画得很好，语义层的设计可能真的有护城河。
根子在于：它把一件本该当作研发探索的事，当成了照图施工。
这是两种完全不同的活，需要两种完全不同的心态。
- 研发探索这种活，天生允许你试错。
- 它默认你一开始就是错的，默认头三周方向就得调头，得先修砂石路、撞几次墙、把脏数据趟明白，才慢慢逼近那张最终蓝图。进度是打着旋往前拱的，画不出一条笔直的线。
- 施工不一样。
- 图纸定死了，你只管按图把楼盖起来，甘特图能排得清清楚楚，每一阶段几个人月都算得出来。
园区 AI 项目骨子里是前一种活。
可那些宏大方案，全都在拿管施工的那套办法管它——线性的阶段、精确的验收、当成前提的数据。
你用管施工的心态去管一件搞研发的事，这项目从立项那天起就埋好了失败的雷。
它甚至会失败得很体面：
每个阶段的文档都齐全，每次汇报的 PPT 都漂亮，直到真刀真枪上线那天，才发现当初藏起来的那六成活一点没少，验收线还画在一个没人够得着的地方。
05. 所以，先趟泥
那正确的顺序是什么？其实特别土，土到不像一个技术结论。
先下场趟泥，再回办公室画图。
具体一点👇：
立项之前，先做一次诚实的数据现状盘点，把“假设已就绪”的每一项都当面核实一遍——主数据到底映射了没有，实时流到底存不存在，那张关系表究竟从哪来。
然后砍到一个最小的单场景竖线，比如就做“设备报警”这一条，先不上 Neo4j 不上 Kafka 不上实时流，关系用最朴素的数据库 join 先凑合着跑通。
等这条窄竖线真的在真实数据上跑起来了、真的有人用了，再回头对照那张宏伟蓝图，一车道一车道地铺。
这个顺序几乎没商量余地：先把数据摸清、先让一条竖线跑起来，然后才轮到照蓝图往大了铺。
谁把它掉个个儿，谁就踩进了 AI 中台项目一犯再犯的那个坑。
所以，园区 AI 项目的成败，九成不在你选了什么数据库、画了多华丽的图。它压在一个特别不体面的问题上：
你是先下场趟泥，还是先回办公室画图？
画图那拨人，图越漂亮，底下的窟窿盖得越严实，等真上线才发现地基是空的。
趟泥那个前三周最难看，汇报的时候脸上也挂不住，可他手里那条丑不拉几、跑在真实脏数据上的小竖线，是真能交付的。
干这行久了就明白，一个 AI 项目做不做得成，很多时候跟谁的架构更聪明关系不大，就看有没有人肯先弯下腰，把手伸进那摊没人愿意碰的泥里