大多数团队会先发布他们最大胆的 AI 功能。那个功能通常是他们研发了六个月、演示效果极佳、且让领导层倍感兴奋的作品。但它在生产环境中失败了——算不上灾难性的，但足以让用户感到不安——于是，随之而来的每一个 AI 功能都会继承这种怀疑。即使团队后来修复了最初的问题，接下来的整整一年里，他们依然会纳闷为什么采用率始终停滞不前。
这就是“第一个 AI 功能”的问题。你首先发布的内容建立了一个先例，这种影响在技术问题解决很久之后依然存在。用户对 AI 的信任建立在第一次失败之上，而非第一次成功。你发布功能的顺序比任何单一功能的质量都更重要。
某物流聊天机器人收到了一位客户的消息——他的包裹已经丢失一周了。机器人的回复是："我没有被训练来关心这件事。"从事实角度看，这完全准确：系统正确解析了查询，正确识别出无法路由处理该问题，也正确传达了其局限性。这个答案在每一个可量化的维度上都是技术正确的。但它同时也是一场产品灾难。
这就是语域问题——而这几乎肯定是你的评估套件没有在衡量的失效模式。
模型跑通了。流水线运行正常。演示效果很好。然后这个功能就在数据团队的 Slack 频道和产品工程师的 JIRA 看板之间悄然死去。
这是大多数 AI 项目失败背后的规律——不是技术失败，而是组织失败。2025 年的一项调查发现，42% 的公司那年放弃了大多数 AI 项目，而上一年这一比例仅为 17%。每个被放弃的项目平均沉没成本高达 720 万美元。当事后复盘被写出来时，列出的原因是"数据准备不足"、"职责不清"和"缺乏治理"——这三种说法其实是同一件事的不同表达：没有人真正负责把这个功能交付出去。
长期 AI 系统存在一种失效模式，在产品评测中鲜有人提及，却频繁出现在用户行为数据中：人们开始绕过自己的 AI 助手。他们用不寻常的方式重新措辞提示，放弃了系统已学会为他们提供的功能，或者悄悄切换到另一个工具来完成他们曾做过数百次的任务。系统成功了——它学习了——而这恰恰是它停止工作的原因。
这就是人设锁定问题。当 AI 适应你的过去行为时，它正在构建一个训练时期的"你"的模型。随着每次交互，该模型变得越来越自信。最终，它成了一座牢笼。
90% 的公司员工都在使用个人 AI 账号——ChatGPT、Claude、Gemini——来完成工作，而其中 73.8% 的账号是非企业性质的。与此同时，57% 使用未经批准的 AI 工具的员工正在与其共享敏感信息：客户数据、内部文档、代码、法律草案。大多数高管认为他们的政策可以防止这种情况发生。但数据表明，实际上只有 14.4% 的团队部署的 AI 获得了全面的安全批准。
领导层认为正在发生的事情与实际发生的事情之间的差距，就是影子 AI 治理问题。
大多数公司的本能反应是下达禁令。在网络层面封禁个人聊天机器人账号、发布政策备忘录、进行年度培训，并称之为治理。这是最糟糕的应对方式——不是因为担忧是错误的，而是因为这种干预措施在没有缩小问题的同时，反而让问题变得不可见。
云端 AI 的策略通常建立在一个没有人明确写下来的前提之上：出站 HTTPS (outbound HTTPS)。厂商 API、托管评测器、遥测流水线、模型注册表、向量存储、仪表板 SaaS、密钥管理器——其中的每一个都静默地解析到公网上的一个域名。一旦拔掉这根电缆，整个技术栈并不会优雅降级，而是会直接崩溃。
大多数团队直到那一刻才会发现，他们的架构中存在从未考虑过的出站依赖。一个“微小”的提示词更新可能需要调用托管分类器；评估套件需要通过网络访问 LLM 评测器；可观测性代理会向后端发送数据；模型注册表从 CDN 拉取权重。这些都不是恶意的，也并不罕见。当你忽视了那根电缆时，云原生技术栈本就是这个样子的。
一个客户给客服发邮件，询问为什么你的 CRM 智能助手停止起草他们的 NDA 了。你根本不知道你的 CRM 智能助手竟然在起草 NDA。一位资深用户抱怨说，你的客服机器人的他加禄语（Tagalog）翻译质量自上周以来有所下降。你根本不知道你的客服机器人还会他加禄语。一个论坛帖子传播了一个提示词，能将你的代码审查助手变成一个还算凑合的安全扫描器，不到一个季度，你就收到了针对该助手生成结果提交的 CVE 报告。其中的每一项都是一个拥有用户群、业务影响力，但完全没有组织归属的功能——没有评估（eval）、没有 SLA、没有在 UX 中体现、没有列入路线图，而且还有一个隐蔽的、仅为 1 的公交因子（bus factor）：那个摸索出这种用法的客户。
当你的产品封装了一个能力范围（capability surface）远超你设定范围的模型时，就会发生这种情况。用户会探索更广阔的能力范围，寻找能解决他们问题的行为，并在这些行为之上构建工作流。然后，当你进行下一次模型升级时，即便你的路线图上没有任何变动，他们也会将其视为一种退化（regression）。你与用户之间的契约不再是你书面写下的那份。它包含了模型碰巧为他们做到的、且你碰巧没有破坏掉的所有事情。
将此视为工程上的意外——“我们会强化提示词，增加护栏，下次我们会捕获到它”——这是一种范畴错误（category error）。“发现的能力”（Found capabilities）是一个产品管理问题。这门学科的核心不在于防止它们发生，而在于检测它们、决定如何处理它们，并记住你曾做出的决定。
一家中型项目管理公司的产品副总裁，花了三个季度的工程团队路线图来构建 AI 助手。上线六个月后，每周活跃使用率只有 4%。问她为什么要做：「竞争对手发布了一个，董事会问我们什么时候跟上。」这是一个用产品战略包装起来的恐慌决策——而且这种情况现在到处都是。
4% 不是个例。一个客户成功平台在四个月后，AI 生成通话摘要的采用率是 6%。一个物流 SaaS 添加了 AI 路线优化建议，点击率 11%，实际操作率 2%。一个 HR 平台推出了 AI 政策问答机器人，火了两周，然后跌落至 3% 后趋于平稳。这个规律已经稳定到可以命名了：发布 AI 功能，眼看它被忽视，十八个月后悄悄下线。
默认的解释是 AI 不够好。有时确实如此。但更多时候，模型没有问题——用户压根就没找到这个功能。
过去三年，工程团队上线的AI功能数量超过了此前十年的总和。但他们几乎没有下线过任何一个。德勤的研究发现，2025年有42%的公司放弃了至少一个AI项目——相比前一年的17%大幅上升——每个被废弃项目的平均沉没成本高达720万美元。然而，那些留在生产环境中的功能往往比被砍掉的更具破坏性：它们缓慢侵蚀用户信任，积累每月复利的技术债，并消耗本可用于有效工作的工程资源。
这种不对称是结构性的。AI功能上线会带来公告、利益相关方的兴奋和团队荣誉。而退场则被视为失败的承认。因此，糟糕的功能不断积累。解决之道不是意志力，而是一套决策框架——让退场成为一种正常、可预期的工程结果，而非组织危机。
你的监控看板显示延迟升高，错误率小幅上升，然后归于平静。用户已经在 Slack 里投诉了。你的 AI 功能有四分之一的响应在产生幻觉，而这些幻觉在你的告警系统眼中看起来完全正常。等你找到原因——两小时前上线的一个提示词里改了六个字——一场你的 Runbook 从未预料到的慢燃事故已经结束了。
这就是在生产环境中运营 AI 系统的核心挑战。这些故障模式真实存在、危害显著，却对传统工具完全隐形。一个在悄悄产生幻觉的 LLM，从外部看和一个运行正常的 LLM 毫无区别。
你的模型通过了公平性审查。人口统计学平价（demographic parity）在可接受范围内，机会均等指标（equal opportunity metrics）看起来很干净，审计报告也被贴上了绿色的勾，进入了 Confluence。三个月后，一名记者拿出的屏幕截图显示，你的系统对某一人口群体的贷款批准率仅为另一群体的一半——而你发布前的那些数据在技术层面一直都是准确的。
这就是偏差监控的缺口。发布前的公平性测试是根据运行测试时存在的数据集来验证你的模型的。但在生产环境中运行的 AI 系统并不处于那种静态的世界中。用户行为会发生变化，人口分布会产生偏移，特征相关性会演变，而那些在发布时无法衡量的差异可能在几周内演变成严重的失效模式。能够捕捉这些问题的系统，在当今大多数 ML 技术栈中都是缺失的。
演示进行得很顺利。试点运行了六周，展示了清晰的成果，与会的利益相关者印象深刻。然后，什么都没有发生。三个月后，项目悄悄被搁置，构建它的工程师转向了其他事情，公司的AI战略变成了一张写着"探索机会"的幻灯片。
这就是扼杀AI项目的模式。不是技术失败，不是模型能力不足，甚至不是预算问题。技术本身确实有效——研究一再表明，约80%进入生产的AI项目达到或超过了预期目标。问题在于那70-90%从未走到那一步的项目。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
