AI项目死在工程而非模型，工程优化是关键

两周时间构建的RAG演示系统，在最终展示会上赢得全场掌声。业务负责人向VP表示，这是“本年度最具突破性的项目”。

三个月后，后台数据揭示——日活跃用户数为零。

并非缓慢衰退，而是自上线第二周起便一直归零。没有投诉，没有负面反馈，只有彻底的无人问津。

这个项目由我全程主导。在我近距离观察并参与的十几个AI项目中，这种结局并非特例，而是常态。

拥有多年电商后端架构经验，曾带领团队扛住大促流量洪峰，后转型专注AI落地。一路走来，见证过无数AI项目，存活下来的不足三成。

这并非个人主观感受。MIT 2025年的NANDA调研显示，95%的企业生成式AI项目未能产生可衡量的商业回报；RAND同年访谈65位资深数据科学家后得出结论，超过80%的AI项目以失败告终，失败率是普通IT项目的两倍；Deloitte 2025年的数据更为直接——42%的企业已砍掉至少一个AI项目，每个被终止项目的平均沉没成本达720万美元。

资金汹涌涌入，大部分仍被烧掉。

过去一年，一个判断愈发坚定——大多数AI项目，失败根源在于工程，而非模型。

这里的工程，并非狭义的编码工作。而是数据管道的就绪度、评测体系的完备性、以及让系统持续进化的闭环能力。

工程，是连接业务判断与大模型能力之间所有琐碎、艰苦的落地工作。

决定一个AI项目生死的，往往不是你选择了GPT-4o还是Claude，不是你的RAG采用了多少路召回，而是：你的数据管道能否稳定运行，你的评估能否自动化，你的团队三个月后是否还愿意维护这个系统，你的老板是否真正理解这个项目需要六个月而非六周。

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

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

第一关立项判断 算不清ROI，就不该启动

第二关场景收敛 评估体系是业务与技术的连接器

第三关技术选型 选择最可控的方案，而非最前沿的技术

第四关工程落地 两大黑洞：数据污染与用户恶意输入

第五关评测迭代 评测不是纯技术工作，而是建立信任的基础设施

第六关组织协作 杀死项目的不是技术，而是期望的落空

第七关持续运维 只有建立运维闭环，系统才能活过六个月

▲ 越往下，越不像常规意义上的“AI工作” ▲

第一关 · 立项判断

评估这件事是否值得用AI来做

在编写第一行代码之前，架构师与VP需要回答的问题并非“AI能否胜任此事”，而是——使用AI完成这件事，相较于传统方式，优势具体体现在哪里？提升多少？这种“提升”能否量化成可计算的商业价值？

大多数AI立项的ROI论证存在根本性倒置：先决定“我们要做AI”，再寻找场景去套用。这与十年前“我们要建中台”的逻辑如出一辙，结局也往往相似。

正确的立项逻辑应是：理赔审核员每日需处理数百单业务，其中约60%为标准件——金额小、材料齐全、规则明确——但每一单仍需人工审阅十几份文档、核对条款、填写结论。痛点并非“人无法判断”，而是“人判断的速度太慢、成本太高”。AI的价值点因此清晰：将标准件的审核时间从15分钟压缩至2分钟。目的不是替代人类，而是协助处理确定性高的那一部分工作。

反之，如果你的立项逻辑停留在“构建一个智能XX，提升效率”这个层面，而未进一步追问“提升谁的效率、从多少提升到多少、节省的成本能否覆盖推理开销”——这类项目大概率会失败。原因并非目标错误，而是目标尚未拆解到可算账的颗粒度。在智能客服领域，“提升用户体验”本身并不模糊——CSAT、NPS、首次解决率都是成熟指标——模糊的是你计划改善哪个具体指标、改善多少、以什么代价实现。三个月后老板追问ROI，你依然无法给出明确答案。

一个清晰的判断标准是：合格的AI立项必须能够回答三个数字——每单节省多少时间、预期覆盖率多少、总成本相比纯人工能节省多少。算不出来，就不应该立项。

第二关 · 场景收敛

将模糊的需求转化为可量化的任务

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

从事过后端架构的人都知道，一个系统最怕的并非技术难度，而是需求边界不清。AI项目尤其如此——因为Demo太容易制造了。你花一天搭建一个RAG原型，给业务方演示，他们兴奋地表示“太棒了，能不能再加XX功能？能不能再覆盖XX场景？”于是，你的系统从“理赔文档审核”悄然膨胀为“智能理赔全流程平台”。

这是一个明确的死亡信号。

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

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

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

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

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

每层采用独立指标进行评测。第一层不达标，第三层不可能优秀——你便能准确定位问题根源，而非对着一个黑箱凭感觉调整参数。

RAND那份报告中，AI项目失败的根源排在首位的是“利益相关者对问题的误解与沟通不畅”。如何对齐认知？开会没用，写PPT也没用。唯一能把业务方和工程团队拉到同一张桌子的工具，就是评估体系。

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

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

一个重要的判断是：场景收敛的标志并非PRD撰写完毕，而是评估流水线能够稳定运行——并且业务和技术团队已坐下来，共同签字确认了评估的通过标准。

第三关 · 技术选型

选择最可控的方案，而非最前沿的技术

在场景和评估标准明确之后，才进入技术选型阶段。

见过太多团队在此翻车的案例：花两周时间评测向量数据库，再用一个月对比LangChain、LlamaIndex与自研方案的优劣，最后耗费三个月构建一个包含五级RAG流水线——查询重写、HyDE、多跳检索、重排序、融合检索全数集成——然后上线时发现，用户的实际提问方式完全出乎意料。

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

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

选型框架可归结为四个关键问题。

一，确定性内容的占比是多少？

如果应用场景中70%的逻辑是确定性的（如规则判断、条件校验、格式验证），这部分不应交给大模型处理。应使用传统代码实现，稳定、高效且免费。大模型只需处理那30%的不确定性任务——自然语言理解、文档信息提取、复杂条款的语义匹配。

Anthropic的「Building Effective Agents」阐述得非常清晰：大多数商业场景需要的是工作流（预定义流程），而非智能体（自主规划）。那些在硅谷媒体和国内科技号中反复被吹捧的“自主智能体”，放在真实的保险理赔场景中，99%的情况下，工作流成本更低、更可控、也更易维护。

但“智能体”这个词太过诱人，所有人都想尝试——包括那些从未成功跑通一个真实业务闭环的人。

二，数据能否形成闭环？

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

三，自建还是购买？

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

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

一个值得遵循的法则：核心流程自己编写，基础设施使用现成方案。模型调用API，向量库使用云服务，可观测性使用现有工具。但编排层——将各组件串联起来的胶水代码——必须自行编写。这一层包含你所有的业务逻辑，是变动最频繁的部分，过度依赖重型框架会导致难以脱身。

四，延迟与成本能否算得清楚？

这个问题被严重低估了。在构建RAG时一味堆叠召回与排序——查询重写、HyDE、重排序、融合检索——不仅模型容易在过长的上下文中迷失方向，还会将首字响应延迟拉长到十几秒，用户根本无法忍受。再加上每单几毛到几块钱的Token成本，如果业务单体的利润无法支撑，这个系统就会成为一个持续失血的窟窿。

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

至于算法工程师在这一关扮演的角色——从任务拆解的第一天起，到持续的故障归因，再到后期的模型蒸馏与微调——这本身值得独立成文，下一篇再详细展开。这里只说一句：工程师是建造者，算法工程师是诊断师。两个角色缺一不可。

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

第四关 · 工程落地

从Demo到生产环境的鸿沟

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

工程落地面临两大黑洞，一个源于物理世界的混乱，一个源于人心的不可控。做过端架构的人应该不会陌生——系统永远在与两类东西作战：脏数据和恶意输入。AI系统同样如此，只是烈度更高。

第一个黑洞：非标准化数据。

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

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

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

后来我们发现，在这个场景下，编写300行处理图片透视变形和印章干扰的传统计算机视觉代码，比调整30次提示词都管用。

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

第二个黑洞：恶意输入。

当系统开始接收真实用户输入时，必须假设用户会输入任何内容。Simon Willison提出的“致命三重奏”——私有数据访问权限、外部内容输入能力、以及外发能力——这三者同时存在时，提示注入的风险无法在提示词层面解决，只能通过架构隔离。

更不用说在金融、医疗、保险行业，将敏感数据（病历、保单、身份信息）发送至公网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就越容易做，团队就越容易跳过基本功直接冲刺上线，然后在三个月后摔得鼻青脸肿。

在所有人都在追逐智能体和推理能力的时候，请先确保你的文档解析管道不会在遇到一张歪斜了15度的照片时瞬间崩溃。

你手里是否有活过六个月的AI项目？或者已经死掉、值得复盘的项目？欢迎在评论区分享它的真实面貌——我会挑选几个精彩的故事，写进下一篇内容。

下一篇预告：算法工程师在AI项目中到底扮演什么角色——从项目启动第一天到上线后的分阶段发力策略。