耗费两周搭建的 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 系统采用了几路召回策略，而在于：你的数据管道能否真正跑通，你的评估流程能否实现自动化，你的团队在三个月后是否仍愿意持续维护这套系统，你的老板是否真正理解这个项目需要六个月而非六周的时间投入。

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

基于这一判断，我将“落地一个商业 AI 项目”拆解为七个层级——放翁七关。每一层都阐明：核心决策是什么，判断依据是什么，以及踩过哪些坑。

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

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

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

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

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

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

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

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

第一关 · 立项判断

这件事值不值得用 AI 做

在写下第一行代码之前，架构师与 VP 需要回答的问题并非“AI 能否完成这件事”，而是——采用 AI 来完成这件事，相比不用 AI 究竟好在哪里？好多少？这种“好”能否量化为具体的商业价值？

大多数 AI 立项的 ROI 论证往往是倒置的：先决定“我们要做 AI”，然后再寻找场景来适配。这与十年前“我们要建中台”的思路如出一辙，结局也大致相似。

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

反过来，如果你的立项逻辑停留在“做一个智能 XX，提升效率”这一层面，没有进一步追问“提升谁的效率、从多少提升到多少、省下来的钱能否覆盖推理成本”——那么这类项目大概率会走向失败。问题不在于目标本身，而在于目标没有拆解到可计算、可核算的颗粒度。在智能客服场景中，“提升用户体验”这一表述本身并不模糊——CSAT、NPS、首次解决率都是成熟指标——模糊的是你打算改善哪个指标、改善多少、以什么样的代价去实现。三个月后老板追问 ROI，你依然无法回答。

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

第二关 · 场景收敛

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

立项之后，最危险的阶段并非技术攻关，而是需求的无序膨胀。

做过后端架构的人都知道，一个系统最怕的往往不是技术难度，而是需求没有边界。AI 项目尤其如此——Demo 的制作门槛太低了。你花一天时间搭建一个 RAG Demo，展示给业务方看，他们兴奋地说：“太厉害了，能不能再加 XX 功能？能不能再覆盖 XX 场景？”然后你的系统从“理赔文档审核”迅速膨胀成“智能理赔全流程平台”。

这正是死亡信号。

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

以理赔审核为例，评估可分为三个层次：

第一层，文档解析正确率——关键字段是否被准确提取

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

第三层，端到端决策一致率——通过或拒绝的结论与人工判断的一致比例

每一层使用不同的指标，独立进行评测。第一层不过关，第三层就不可能做好——这样你就能清楚地知道问题出在哪个环节，而不是对着一个黑箱凭感觉调整参数。

RAND 那份报告中指出，AI 项目失败的首要根本原因是“利益相关者对问题的误解与沟通不畅”。如何实现对齐？开会没有用，写 PPT 也没有用。唯一能将业务方和工程团队拉到同一张桌子上的工具，就是评估体系。

没有评估体系，业务方无法判断系统的好坏，信任会逐渐流失；没有评估体系，工程师不知道修改是否正确，只能盲目迭代，系统会逐渐腐烂。

评估体系不仅是技术手段，更是连接业务与工程的铰链。

一个重要的判断标准：场景收敛的标志不是 PRD 文档已经写完，而是评估流水线已经跑通——并且业务方和技术团队坐下来，将评估的通过标准正式签字确认。

第三关 · 技术选型

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

场景和评估标准定义清楚之后，才轮到技术选型。

我见过太多团队在这一步翻车的方式：花两周时间评测向量数据库，花一个月对比 LangChain、LlamaIndex 与自研方案，花三个月搭建一套五级 RAG 流水线——query rewrite、HyDE、multi-hop、rerank、fusion 全部用上——然后上线后发现，用户根本不按照预设的方式提问。

技术选型的核心原则并非“选择最先进的”，而是“选择最可控的”。可控意味着：出现问题能够快速定位到具体环节，能够快速替换某个组件而不影响全局。

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

选型框架包含四个关键问题。

一，确定性的部分有多少？

如果场景中 70% 的逻辑是确定性的（如规则判断、条件校验、格式验证等），这些部分不要交给大模型处理。使用传统代码来实现，稳定、快速、成本低。大模型只负责那 30% 的不确定性部分——自然语言理解、文档信息提取、复杂条款的语义匹配。

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

但“Agent”这个词实在太吸引人了，所有人都想尝试——包括那些从未跑通过一个真实业务闭环的人。

二，数据能否形成闭环？

如果场景能够持续产生标注数据——比如理赔场景，每一单最终都有人工审核结论——那么你就有了微调的基础。先用 RAG 快速上线，积累数据，等数据量足够后再对特定环节进行微调。这比一上来就直接微调要务实得多。

三，自建还是购买？

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

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

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

四，延迟和成本能否算得过来？

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

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

至于算法工程师在这一关里扮演什么角色——从第一天的任务拆解，到持续的错误归因，再到后期的蒸馏与微调——这足够写一篇独立的文章，下一篇再详细展开。这里只提一句：工程师是建造者，算法工程师是诊断师。两个角色缺一不可。

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

第四关 · 工程落地

从 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%，评估与监控 20%，前端和产品 10%。而大多数团队将 70% 的资源花在了 AI 逻辑上，本末倒置。

第五关 · 评测迭代

从“能跑”到“能信”

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

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

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

一个可行的做法是：每周从线上流量中抽取 200 单，让资深审核员进行二次审核作为基准真相，自动计算决策一致率。这个数字每周在团队周报中透明公示。业务方可以清晰地看到系统是在变好还是变差。

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

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

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

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

第六关 · 组织协作

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

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

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

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

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

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

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

它的形式如下：

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

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

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

第七关 · 持续运维

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

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

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

运维闭环包含三件事。

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

二，模型漂移监控。API 模型会悄悄更新，你的系统表现会随之波动。需要持续运行评估，核心指标下降超过阈值就触发报警。这与电商大促的监控思路一样——不是出了问题再查，而是实时盯防。第五关中讲到的那次信任事故，正是因为少了这一步。

三，用户反馈回路。审核员觉得系统建议不对时，能够一键标注“不同意”。这些标注积累起来就是最宝贵的迭代数据——它能告诉你系统在哪些类型的案例上表现不佳，为下一次改进指明方向。

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

写在最后

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

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

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

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

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

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

你手里有没有活过六个月的 AI 项目？或者已经失败、想要复盘的项目？欢迎在评论区告诉我它长什么样——精彩的故事我会挑选几个，写进下一篇。

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