AI 项目死在工程,不是模型

花了两周搭的 RAG Demo，演示会结束时所有人鼓掌。业务负责人跟 VP 握手，说这是“今年最激动人心的项目”。

三个月后，后台一看日活——零。

不是慢慢下滑到零，是从上线第二周起就一直是零。没人骂、没人投诉，只是没人用。

这个项目是全程主导的。近距离看过和参与过的十几个 AI 项目里，这样的结局不是例外，是常态。

在电商做过很多年后端架构，带过大促扛流量的团队，后来转专注做 AI 落地。遇到过很多 AI 项目，活过的不到三成。

这不是个人的体感。MIT 2025 年的 NANDA 调研显示，95% 的企业 Gen AI 项目没有产生可衡量的商业回报；RAND 同年访谈 65 位资深数据科学家，结论是超过 80% 的 AI 项目失败，是普通 IT 项目的两倍；Deloitte 2025 年的数据更直接——42% 的企业砍掉了至少一个 AI 项目，每个被砍项目的平均沉没成本是 720 万美元。

钱涌进来了，大部分烧掉了。

过去一年，越来越确信一个判断——大多数 AI 项目，败在工程，不是模型。

这里说的工程，不是狭义的写代码。是数据管道的就绪度，是评测体系，是让系统持续变好的闭环能力。

工程，是连接业务判断和大模型能力之间的所有脏活。

决定一个 AI 项目生死的，往往不是你用了 GPT-4o 还是 Claude，不是你的 RAG 用了几路召回，而是：你的数据管道能不能跑通，你的 eval 能不能自动化，你的团队三个月后还愿不愿意维护这个系统，你的老板是不是真的理解这个项目需要六个月而不是六周。

这些事，没有一件是模型能帮你解决的。

基于这个判断，把“落地一个商业 AI 项目”拆成七层——放翁七关。每一层讲清楚：核心决策是什么，判断是什么，踩过什么坑。

第一关立项判断 算不出 ROI，就别立项

第二关场景收敛 Eval 是业务与技术的铰链

第三关技术选型 选最可控的，不是最先进的

第四关工程落地 两个黑洞：脏数据与恶意输入

第五关评测迭代 评测不是技术，是信任基建

第六关组织协作 项目不是被技术杀死，是被失望杀死

第七关持续运维 活过六个月靠的是运维闭环

▲ 越往下，越不像“AI 工作” ▲

---

第一关 · 立项判断

这件事值不值得用 AI 做

在写第一行代码之前，架构师和 VP 要回答的问题不是“AI 能不能做这件事”，而是——用 AI 做这件事，比不用好多少？好在哪里？这个“好”能不能算出钱来？

大多数 AI 立项的 ROI 论证是倒过来的：先决定“我们要做 AI”，然后找场景去套。这跟十年前“我们要做中台”是一个逻辑，结局也差不多。

正确的立项逻辑长这样：理赔审核员每天处理几百单，其中 60% 是标准件——金额小、材料齐、规则明确——但每单仍需人工审阅十几份文档、核对条款、填写结论。痛点不是“人判断不了”，而是“人判断得太慢、太贵”。AI 的价值点清晰：把标准件的审核时间从 15 分钟压到 2 分钟。不是替代人，是帮人处理确定性高的那部分。

反过来，如果你的立项逻辑是“做一个智能 XX，提升效率”——到这一步就停了，没有继续追问“提升谁的效率、从多少提升到多少、省下来的钱够不够覆盖推理成本”——这种项目大概率会死。不是目标不对，是目标没有拆到可算账的颗粒度。智能客服里，“提升用户体验”本身不模糊——CSAT、NPS、首次解决率都是成熟指标——模糊的是你打算改善哪个指标、改善多少、以什么代价。三个月后老板问 ROI，你还是答不上来。

一个明确的判断是：合格的 AI 立项必须能回答三个数字——每单节省多少时间、覆盖率多少、总成本比纯人工省多少。算不出来，就别立项。

---

第二关 · 场景收敛

把模糊需求变成可衡量的任务

立项之后，最危险的阶段不是技术攻关，是需求膨胀。

做过后端架构的人都知道，一个系统最怕的不是技术难，是需求没边界。AI 项目尤其严重——Demo 太容易做了。你花一天搭个 RAG Demo，给业务方看，他们说“太厉害了，能不能再加 XX？能不能再覆盖 XX 场景？”然后你的系统从“理赔文档审核”膨胀成了“智能理赔全流程平台”。

这是死亡信号。

正确的做法是：Demo 之后、正式开发之前，强制做一件事——定义 eval。把模糊需求翻译成“给定输入 X，系统应输出 Y，好坏标准是 Z”。

以理赔审核为例，eval 分三层：

第一层，文档解析正确率——关键字段有没有提取对

第二层，条款匹配准确率——系统引用的条款和审核员一致的比例

第三层，端到端决策一致率——通过/拒绝的结论和人工一致的比例

每层用不同的指标，独立评测。第一层不行，第三层不可能好——你就知道问题出在哪里，而不是对着一个黑盒凭感觉调参。

RAND 那份报告里，AI 项目失败根因的第一名是“利益相关者对问题的误解与沟通不畅”。怎么对齐？开会没用，写 PPT 没用。唯一能把业务方和工程团队拉到同一张桌子上的东西，是 eval。

没有 eval，业务方不知道系统好不好，失去信任；没有 eval，工程师不知道改对没改对，盲目迭代，系统腐烂。

Eval 不只是技术手段，是连接业务和工程的铰链。

一个重要的判断：场景收敛的标志不是 PRD 写好了，是 eval pipeline 跑通了——而且是业务和技术坐下来，把 eval 的通过标准签了字。

---

第三关 · 技术选型

选最可控的，不是最先进的

场景和 eval 定义清楚之后，才到技术选型。

见过太多团队在这一步的翻车方式：花两周评测向量数据库，花一个月对比 LangChain vs LlamaIndex vs 自研，花三个月做了一个五级 RAG pipeline——query rewrite、HyDE、multi-hop、rerank、fusion 全上了——然后上线发现，用户根本不这么问问题。

技术选型的核心原则不是“选最先进的”，是

。可控意味着：出了问题能快速定位在哪个环节，能快速替换某个组件而不动全局。

做过电商架构的人对这个原则不陌生——大促系统的核心设计原则就是“可降级、可熔断、可灰度”。AI 系统一样。

选型框架是四个问题。

如果场景里 70% 的逻辑是确定性的（规则、条件判断、格式校验），这些不要交给大模型。用传统代码写，稳定、快、免费。大模型只处理那 30% 的不确定性——自然语言理解、文档信息提取、复杂条款的语义匹配。

Anthropic 的「Building Effective Agents」讲得清楚：大多数商业场景需要的是 Workflow（预定义流程），不是 Agent（自主规划）。那些在硅谷媒体和中文科技号里被反复吹捧的“自主 Agent”，放到真实的保险理赔场景里，99% 的情况下，Workflow 更便宜、更可控、也更好维护。

但“Agent”这个词太性感了，所有人都想做——包括那些从没跑通过一个真实业务闭环的人。

如果场景能持续产生标注数据——比如理赔，每一单最终都有人工审核结论——你就有 fine-tune 的资本。先用 RAG 快速上线，积累数据，等数据量够了再 fine-tune 特定环节。比一上来就 fine-tune 务实得多。

这不仅是经验法则，也是冰冷的数据。Menlo Ventures 2025 年报告显示，企业 AI 支出里 76% 是购买而非自建；MIT NANDA 的研究发现，购买或合作的成功率是自建的 3 倍。

在基础设施上造轮子，是架构师最容易犯的傲慢。你的核心壁垒是对本行业数据和业务逻辑的理解，不是自己徒手撸一个向量召回引擎。

一个值得遵守的法则：核心管道自己写，基础设施用现成的。模型用 API，向量库用云服务，可观测性用现成工具。但 orchestration 层——把各组件串起来的胶水代码——一定自己写。这一层包含你所有的业务逻辑，是最频繁变动的部分，依赖重框架会被锁死。

这个问题被严重低估了。做 RAG 时一味堆叠召回和排序——query rewrite 加 HyDE 加 rerank 加 fusion——不仅模型容易在过长上下文里迷路，还会把首字延迟拉到十几秒，用户根本等不了。再加上每单几毛到几块钱的 token 成本，如果业务单体利润撑不住，这个系统就是一个持续流血的窟窿。

做过电商的人对这个账不陌生：每一跳都有成本，每一层都有延迟，架构不是越复杂越好，是越短越好。

至于算法工程师在这一关里扮演什么角色——从第一天的任务拆解，到持续的错误归因，到后期的蒸馏与 fine-tune——这够得上一篇独立的稿子，下一篇写。这里只说一句：工程师是建造者，算法工程师是诊断师。两个角色缺一不可。

一个核心判断：先跑通最短链路，再逐环节替换和优化。不要一上来就搭“完美架构”。选型时永远先算一笔账——按当前日均请求量，月推理成本是多少，单次请求延迟能不能控制在用户可接受的范围内。算不过来的架构，技术再先进也是死路。

---

第四关 · 工程落地

从 Demo 到 Production 的鸿沟

这一关最有发言权。电商后端那些年教会一件事：一个系统的难度，80% 在上线之后。

工程落地有两个黑洞，一个来自物理世界的混乱，一个来自人心的不可控。做过后端的人应该不陌生——你的系统永远在跟两种东西作战：脏数据和恶意输入。AI 系统一样，只是烈度更高。

Gartner 2025 年预测，到 2026 年底 60% 的 AI 项目将因数据质量不达标而被放弃。Informatica 同年的 CDO 调查更直白——只有 12% 的组织认为自己的数据质量达到了 AI 应用的要求。“数据就绪度”在所有权威调研里都是头号死因，占比近 30%。

这意味着什么？意味着你那个花三个月调参的精巧 RAG，在真实世界的脏数据面前会瞬间崩溃。Demo 阶段，数据是手动清洗过的，查询是自己构造的，用户是自己。一切看起来都很好。上线后你面对的是：拍歪的照片、扫描模糊的 PDF、手写病历、格式各异的费用清单。你的文档解析管道在这些脏数据面前溃不成军。

举一个真实的例子。Demo 阶段，我们喂给系统的全是扫描清晰的 PDF 白皮书。上线第一天遇到的第一张真实票据，是被揉皱了又展平、盖着红色印章、拍照时手指还挡住一角的照片。Pipeline 直接挂了——OCR 识别率从 Demo 时的 97% 掉到不足 40%。

后来我们发现，在这个场景下，写 300 行处理图片透视变形和印章去除的传统 CV 代码，比调 30 个 prompt 都管用。

数据质量是 AI 系统的地基，但它恰好是所有人最不愿意投入的部分。因为这不是“AI 工作”——清洗、解析、格式统一、异常处理——全是后端工程师熟悉的脏活。如果一开始把 50% 的资源投在数据管道上，结局会完全不同。

当系统接触真实用户输入时，你必须假设用户会输入任何东西。Simon Willison 提出的 Lethal Trifecta——私有数据访问 + 外部内容输入 + 外发能力——三者同时存在时，prompt injection 风险无法在 prompt 层面解决，只能通过架构隔离。

更别提在金融、医疗、保险行业，把敏感数据（病历、保单、身份信息）传给公网 API 带来的合规红线——这不是工程问题，是法律问题。

这跟做电商时处理支付安全的思路一样：安全不是功能，是架构。

一个建议的资源分配：团队资源分配应该是——数据管道 40%，核心 AI 逻辑 30%，eval 与监控 20%，前端和产品 10%。大多数团队把 70% 花在 AI 逻辑上，本末倒置。

---

第五关 · 评测迭代

从“能跑”到“能信”

系统上线了，老板和业务方问：“准确率多少？”

如果你答不上来，或者答出的数字没有置信度，这个项目就开始失去信任。失去信任的项目不会因为技术更好而翻盘——因为没有人再愿意给你资源和时间了。

评测不是技术环节，是信任基础设施。

一个可行的做法是：每周从线上流量中抽样 200 单，让资深审核员做二次审核作为 ground truth，自动算决策一致率。这个数字每周在团队周报里透明公示。业务方能看到系统是在变好还是变差。

举一个反面例子。早期有一个月，为了赶一个新功能，把周度 eval 停了。那个月底上游模型服务做了一次默默的版本更新，系统的条款匹配准确率悄悄从 91% 掉到了 78%。这件事不是我们发现的，是业务方从审核员抱怨“最近引用的条款有点怪”里挖出来的。

信任裂缝一旦出现，修复的成本远比你想象的高——接下来两周花了大量时间重跑 eval、给业务方复盘、承诺新的监控机制。从那之后，eval 没有漏跑过一周。

这件事做到需要三个前提：标注资源（跟业务团队协调出的人力）、自动化 eval pipeline（不能每周手动跑）、eval 结果与系统变更之间的关联（这周改了什么，数字变了多少）。

一个关键判断：eval 投入应该占项目总工时的 20% 以上。这个比例在大多数团队看来“太多了”。但反复验证过——eval 投入不足的项目，六个月后一定进入“改了也不知道变好没”的黑暗期。

---

第六关 · 组织协作

项目不是被技术杀死的，是被失望杀死的

这一关很少有技术博客会写，但可能是最致命的一关。

做 AI 落地，最难的不是写代码，是管理预期。

Deloitte 2025 年的调研给了一个精确的死亡时间线：56% 的失败项目中，高管支持在六个月内蒸发。为什么？因为业务方看了 Demo 觉得 AI 无所不能，期望值拉满。上线后发现覆盖率 70%、还有 30% 转人工，觉得“这也叫 AI？”

项目不是被技术杀死的，是被失望杀死的。

第一次签“能力边界协议”其实是被动的——不是主动想到，是之前一个项目上线后被业务方投诉“说好的 AI 为什么还要人工复核”，才痛定思痛倒逼出来的。现在回想，那个项目如果早三个月签，可能就不会死。

项目启动时跟业务方签一份“能力边界协议”——白纸黑字写清楚：第一期覆盖哪些场景、不覆盖哪些、预期准确率多少、什么情况转人工。这不是技术文档，是信任契约。

它长这样：

功能模块	本期范围	不在本期范围	验收标准	异常兜底方案
发片识别	机打发片	手写发片	字段准确率 ≥ 98%	转人工录入
条款匹配	单一险种	跨险种交叉判断	条款召回率 ≥ 90%	提示“建议人工复核”
审核决策	标准件（金额 < 5 万）	重大疾病/高额件	与人工一致率 ≥ 85%	自动转资深审核员

有了这张表，业务方不会在上线后问“为什么手写发片识别不了”，因为白纸黑字写着“不在本期范围”。技术团队也有了明确的交付标准，不会陷入“永远在优化但永远不够好”的泥潭。

另一个问题是团队融合。后端工程师习惯确定性——输入确定，输出确定，测试通过就行。算法工程师习惯概率性——80% 的准确率就是好结果。这两种思维方式要在一个系统里共处，需要共同的 eval 标准作为对齐工具。Eval 不只是技术手段，是团队沟通的共同语言。

一个重要的判断：架构师或 VP 至少要花 30% 的时间在非技术工作上——向上管理预期，横向协调业务团队，向下统一工程标准。100% 的时间花在技术上，项目大概率死在组织层面。

---

第七关 · 持续运维

活过六个月靠的是运维闭环

大多数 AI 项目的生命周期：第一个月兴奋，第二个月上线，第三个月发现问题，第四到第六个月疲于修补，第七个月被砍或被遗忘。

活过六个月的系统和死在六个月的系统，技术栈几乎没有区别。区别在于有没有运维闭环。

运维闭环是三件事。

知识库不是灌一次就完事的。保险条款会更新，理赔政策会调整，新的案例类型会出现。有过一次教训：某个知识库灌完之后半年没更新，结果系统引用给审核员的条款里，有一条已经被总部废止了——幸好审核员经验丰富，没直接用。那次之后建了条款更新的 webhook：任何条款变动，24 小时内自动触发重新分块、embedding、入库，再自动跑 eval 回归，确认新数据没破坏已有能力。

API 模型会悄悄更新，你的系统表现会跟着波动。需要持续跑 eval，核心指标下降超阈值就报警。这跟电商大促的监控思路一样——不是出了事再查，是实时盯着。第五关讲的那次信任事故，就是因为少了这一步。

审核员觉得系统建议不对时，能一键标注“不同意”。这些标注积累起来就是最宝贵的迭代数据——它告诉你系统在哪些类型的案例上不行，是下一次改进的方向指引。

一个明确的判断：立项时就要把运维成本算进 ROI。一个 AI 系统的月运维成本（推理费 + 数据管道 + eval + 人力）大约是开发成本的 15%–20%。这个数字你接受不了，说明这个项目的商业逻辑本身不成立。

---

写在最后

七关走下来，你会发现一个规律：越往下，越不像“AI 工作”。

商业判断、需求定义、数据工程、组织管理、运维——这些事情，十年前做后端架构的时候就在做，只是换了个语境。

这也是为什么说“败在工程，不是模型”——但工程的起点不是写代码，是定义 eval。

Eval 是连接业务判断和用户价值之间的铰链，是让 95% 的失败率不落在你头上的唯一杠杆。

模型能力在过去两年突飞猛进，但工程的基本功——数据治理、eval、监控、运维、预期管理——不会因为模型更强就自动解决。恰恰相反，模型越强，Demo 越容易做，团队越容易跳过基本功直接冲上线，然后在三个月后摔跤。

在所有人都在追 Agent 和 Reasoning 的时候，先确保你的文档解析管道不会在遇到一张歪了 15 度的照片时崩溃。

你手里有没有活过六个月的 AI 项目？或者死掉的、想复盘的？评论区告诉我它长什么样——精彩的故事会选择几个，写进下一篇。

下一篇预告：算法工程师在 AI 项目里到底干什么——从第一天到上线后的分阶段发力。