最近看了一份写得相当扎实的「园区数字员工技术架构方案」。
设计没毛病，毛病在于它把项目最要命的几件事，用一句「假设前提」轻轻划走了。
这篇想把那几件被划走的事捡回来讲清楚——它们是钱和时间真正的去处。
作者 | 听风
编辑/排版 | MM77
翠鸟AI技术漫研 — 拓新AI边界、探索技术增量
先说一个反直觉的结论：
当下做一个「能听懂园区大白话、自己查数据、给出专业回答」的智能体，最能体现 AI 价值的那部分——理解人话、生成查询、把数字写成人话，
快得超乎想象，一两周就能出个像样的 demo。
但真正吃掉三个月、吃掉预算、让项目在验收前夜暴雷的，是另外三样东西。它们跟「AI 强不强」基本无关，有一样甚至是被 AI 太能编逼出来的。
① 脏数据 AI 治不了
设备台账错、编码乱、跨系统对不上——
这是人去清洗的苦力活，占一个 AI 项目 60–80% 的工时，跟你用不用大模型毫无关系。
② AI 越强，关住它的成本越高
企业场景里 AI 会自信地把楼栋认错、把相关说成因果。
给它砌一道「防胡说」的护栏，是传统系统里从没有过、上了 AI 才凭空冒出来的一整层活。
③ 最后 10% 的可靠度是无底洞
demo 能过很快，「甲方敢用、答错要担责」很慢。
这段时间烧在把可靠性往上磨，换个更强的模型也省不掉。
01. 一份好方案，是怎么把最难的活划走的
☝️开头那份方案有个很聪明的定义。
它把「查询全部园区业务」里的「全部」解释成：数据已经接入、实体已经统一映射、指标和关系已经注册。
这句话读起来天经地义，其实是一次漂亮的乾坤大挪移：
项目里那 60% 最脏、最磨人、又最没法交给机器干的工作量，就被「假设前提」四个字，悄悄从工期表里请了出去。
什么叫「实体已统一映射」？
园区里一台空调，物业系统叫它 AHU-T8-5F-02，能耗系统叫它 设备10023，工单系统里干脆手填成「8 号楼五层新风机」。
要让智能体回答「T8 五楼那台新风机的告警」，你得先有一张表，把这三个名字焊成同一个内部 ID。
这张表谁来填？
一个中等园区几千个点位，第三方给过来的编码往往是脏的、重的、缺的。
画一张架构图解决不了它，得几个人对着 Excel 和现场铭牌，核上几个月。方案里，它是一行字。
把「数据已经 ready」当成已知条件的方案，等于把整栋楼最深的地基，标注成「此处已夯实，详见前提」。
这里没有贬低那位架构师的意思，能写出这么完整的终态蓝图，反而说明他很有经验。麻烦出在 蓝图和施工图是两码事：
蓝图上写一句「地基已夯实」就能往上画楼，真让施工队进场，这句话就得有人花几个月去把它变成事实。
02. 那个断崖：为什么 demo 惊艳，上线拉胯
说 AI 强，得说清楚强在哪、弱在哪。
文生 SQL（把大白话翻成数据库查询）是这类智能体的核心引擎，学术界给它做了十几年 benchmark，数字很能说明问题。
85%
前沿模型在 Spider（干净的学术数据库）上的执行准确率——接近做完了
10-21%
同样的模型，换到 Spider 2.0（真实企业数仓工作流）上——直接崩塌，8.5 倍落差
0.0%
GPT-4o在BEAVER（MIT 用真实私有数仓查询日志建的基准）上——一题没对
60%
Gartner 预测：到 2026 年，因数据质量不足被放弃的 AI 项目比例
这组数字有个业内的名字，叫「企业断崖」（Enterprise Cliff）。含义很直白：
模型在网上见过、结构干净的数据上接近满分；
一换到你自家那套字段上千列、命名全靠祖传、业务黑话满天飞的真实数仓，成绩断崖式下跌。
BEAVER 那个 0.0% 尤其诛心——因为它的数据从没上过互联网，模型没得背，于是原形毕露。
这解释了每一个 AI 落地项目都会经历的诡异时刻：
给领导演示时神乎其神，真接上生产库就漏洞百出。
demo 没造假，它喂的那点数据实在太干净了，而你家真实的园区数据，恰好落在模型最不擅长的那一侧。
所以那份方案里的 99% 准确率，是给自己挖的坑
它把「意图识别 ≥99%、实体识别 ≥99%」写进了「正式开发基线」。
可连 GPT-4 级模型在干净基准上都够不着 99%，何况中文口语、多轮指代、话题乱跳的真实园区对话。
把做不到的数字写进验收口径，结果只有两个：
要么团队永远不达标被判死刑，要么去刷一个简单到失真的测试集——数字好看，没人敢用。
03. 最贵的一层护栏，是「上了 AI 才需要」的
这一条最反直觉，也最值钱。你可能觉得 AI 越强项目越省事，实际往往倒过来。
AI 强的地方在于，它会用一模一样的自信语气把对的话和编的话都说出来——
把「相关」讲成「因果」，把一个根本不存在的设备编号说得有鼻子有眼，把算错的百分比配上一段无懈可击的解释。
这种自由发挥要是发生在写段子上，顶多算它有创造力；发生在「园区总经理助手」身上就是事故了。
总经理不会去核对你后台的 SQL，他只会照着那句「空调加时是能耗上涨的主因」去开会、去问责、去砸钱改造。万一这句话其实只是两条曲线碰巧一起涨了呢？
那份方案里最有含金量的部分，正是为这件事准备的：
它强制系统区分「观察到的事实」「相关性」和「因果」，把「空调加时是主因」这种话，在出口处拦下来，降级成「空调加时可能是重要影响因素之一」。
每个说出口的数字，都得能回溯到它是哪条查询查出来的。
传统报表系统里压根没有这套「防胡说」的护栏——
那种系统里没有一个会自己编话的东西需要你管。
上了 AI，这一整层工程才凭空冒出来。
所以「用了 AI 所以更快」这个直觉，在 To-B 场景里要打个折。
它确实省掉了写死一堆查询接口的活，可代价是：
补上一层「管住它别乱说」的工程，这层认真做下来要几个月。系统越放手让 AI 自由发挥，护栏就得砌得越厚。
04. 把工期掰开：到底哪段快，哪段慢
把「能不能三个月做完」这个问题拆细，答案其实是分层的。同一个项目，你要的可靠度不同，工期差好几倍。
| 你想要的东西 | 现实工期 | 卡在哪 |
| 能演示的 demo接大模型 + 单个域 + 文生 SQL，喂干净的数据子集 | 1–2 周 | 几乎不卡，AI 直接能干。这段就是你直觉里「AI 很快」的部分，没错。 |
| 能给甲方试用的一期几个域+基础多轮 + 数字不出错+基础护栏 | 5–8 周 | 卡在数据清洗和防幻觉护栏这些跟模型无关的地方。 |
| 甲方敢正式上线、答错要担责 | 3 个月+ | 卡在可靠性打磨和真实数据治理，AI 使不上劲。 |
「AI 强不强」这件事，只影响到第一行的那一两周。后面从五周到三个月的时间，模型再进步一代也帮不上什么忙，它们耗在数据和可靠性上。
05. 顺带说个岗位：为什么这类项目离不开 FDE
这四件事指向同一个人才问题：
既然吃掉时间的是「数据脏」「需求对不上」「护栏要贴着业务建」，那这些活谁来干？
答这个问题的，是近几年被 Palantir、OpenAI 反复验证过的一个角色——FDE（Forward Deployed Engineer，前置部署工程师）。
Palantir 把这套打法做成了看家本领：
它派工程师坐进客户的现场，一边写代码一边啃客户的业务和数据，而不是把软件打包扔过去让客户自己配。
这个岗位在 AI 时代突然被抢疯了——OpenAI 今年砸 40 亿美元成立专门的部署公司来招 FDE，Google Cloud、Anthropic 全在挖。
道理很直接：
大模型把「通用能力」变成了 API 上谁都能调的便宜货，剩下真正难、真正赚钱的那截，全是「把通用能力焊进这一家客户的脏现实」——
这件事没法远程、没法外包、没法靠一份需求文档隔空传递。
MIT 今年一份报告给了这套逻辑最狠的注脚：95% 的企业生成式 AI 试点，没跑出任何可衡量的业务影响。
模型都够用，卡在部署那一段没人接得住。
而 Palantir 靠着「把人塞进客户最复杂的系统里」这套打法，五年股价涨了 640%——市场早用钱投过票了。
| 项目真正卡住的地方 | 为什么非 FDE 不可 |
| 那张脏得没法看的主数据映射表 | 对齐设备编码要蹲现场、翻铭牌、追着物业和集成商问。这是身体在场的活，甲方讲不清、乙方猜不到。 |
| 「今天园区怎么样」到底想问什么 | 同一句话，总经理关心的和物业关心的是两回事。需求得贴身观察才挖得出，文档里根本没有。 |
| 护栏该在哪拦、拦到什么程度 | 「相关」能不能说成「主因」，取决于这家园区的业务规则和风险容忍度——只有懂业务又懂代码的同一个人，才拦得准。 |
传统的「售前 + 交付 + 客户成功」三段式里，懂业务的人和会写代码的人根本不是同一批，中间隔着一层层传话，需求走到实现那头早就失真了。
FDE 的价值就是把这两样本事塞进同一个人的脑子，省掉中间那些转述。
那份方案里被划走的 60%，摊开看就是一份 FDE 的岗位说明书——只是方案假装这份工作不存在。
给决策者的一条用人判断评估一个 AI 落地项目的报价时，看它把人力压在哪。
要是预算几乎全砸给「算法/模型」，只留一点点给「现场对接」，这方案多半要翻车——它把最贵最难的活，当成了不用人的「前提」。
真该重金投的，是一个能扎进现场、又能当场改代码的 FDE，他一个人顶得上三份漂亮的架构 PPT。
06. 那到底该怎么落地
知道了真正的难点在哪，落地路线就好定了。
核心是别再顺着「按技术模块从头往上铺」的惯性走。下面三步，我按一个真实项目该有的节奏排。
第一步，花两三周探地基
立项前先做一件方案里完全没有的事：数据现状盘点。
实际去查那张主数据映射表填了没、有多脏；实时数据源到底存不存在；工单能不能关联到设备。这份报告出来之前，后面所有排期都是拍脑袋。
它能在花大钱之前，就把方案虚在哪暴露出来——两三周，省掉后面三个月的空转。
第二步，用最土的栈跑通一条竖线
只挑一个数据最干净的域（告警是首选），把「问 → 理解 → 查 → 答」端到端打通。
这个阶段图数据库、消息队列、实时管道一样都别碰——关系查询用一条普通的表连接就能覆盖八成需求。
等这条竖线在甲方真实数据上跑出了正确答案，再谈横向铺开。
最常见的死法：先信蓝图，再补数据绝大多数「AI 中台」项目就死在这个顺序上——
被一份漂亮的终态架构说服，团队吭哧吭哧把图数据库、CDC、实时层全搭起来，六个月后发现底座很美，却没有一个真实业务问题能从头到尾跑通。
该走的顺序倒过来：先把数据验明白、先拿一条竖线跑通，蓝图上那些重家伙往后放。
第三步，重型组件留到被需求逼出来再上
图数据库、消息队列、实时流这些，等某个真实需求把简单方案逼到墙角了再引入。
每样没上的复杂度，都是替你省下的运维成本和半夜被叫醒的次数。
一个园区项目的预算和运维人力，通常撑不起一整套准互联网大厂的数据栈，硬上就是拿中台架构做项目制交付，怎么算都不划算。
写在最后
那份方案本身是资深水准，方向也对，值得当成 12 个月后的北极星。
我写这篇，是想把它默默划走的三件事重新摆回台面上——毕竟签合同、拍预算、定验收线的人，得知道钱真正会流去哪。
如果只带走一句话：
估工期时，给每段活标一下：AI 能上手的，按周算；AI 帮不上忙的，得按月算。
你会发现方案里被轻描淡写成「前提」的那些，几乎全在按月算的那一堆。