用户与 AI 助手进行了一个小时的长代码会话。他们建立了规范，分享了代码库上下文，并详细描述了一个多文件重构方案。接着，在第 40 条消息左右，AI 开始给出忽略其“已知”一切的建议。它推荐了一个用户二十分钟前已经拒绝的方案。当被追问时，它显得很困惑。
没有显示任何错误。没有出现任何警告。模型只是静默地丢弃了较早的消息，以为新消息腾出空间——而用户得出的结论是，该 AI 不可靠。
这不是模型失败。这是产品设计失败。
当工程师推介AI功能时，成本讨论几乎总是围绕推理API展开。每个token多少钱？按预期调用量估算每月费用是多少？能否争取到批量折扣？这是一个错误的对话——或者至少是不完整的。
在实践中，推理账单大约占运行一个成熟AI功能实际成本的20-30%。其余成本分散在一系列不会出现在LLM提供商发票上的支出中：检索管道依赖的向量数据库、填充它的嵌入任务、捕捉静默失败的可观测性平台、验证模型输出的人工审核员，以及花费数周调整提示让一切正常运转的工程师。团队通常在上线六个月后才发现这一点——当他们试图解释一个比预测高出3-5倍的成本中心时。
据一项研究显示，95% 的生成式 AI 试点项目从技术层面来看都算成功——而 74% 使用生成式 AI 的公司至今仍未展现出可量化的业务价值。这两个数字之间的落差并非巧合，而是一个被包装成技术问题的衡量问题。更糟糕的是，大多数组织无法准确诊断这一问题，因为负责衡量的人，恰恰就是被衡量的人。
这就是古德哈特定律（Goodhart's Law）在组织层面的体现：一旦某个 AI 采用率指标成为绩效目标，它就不再能衡量你真正在乎的事情了。指标持续攀升，实际结果却原地踏步甚至每况愈下。
当两个微服务在API假设上出现偏差时，集成测试会在上线前捕获问题。当两个智能体在提示词假设上出现偏差时，你只会在客户收到自相矛盾的答案——或者整条流水线因级联故障崩溃——时才会发现。多智能体AI系统在生产环境中的失败率高达41%–87%。这些失败中超过三分之一并非模型质量问题，而是协调故障：某个智能体改变了输出格式，另一个智能体仍然期望旧的数据结构，而没有人为此写过测试。
根本问题在于，智能体之间通过隐式契约进行通信。一个研究型智能体——在某人的心智模型中——约定返回带有 sources 数组的JSON对象。编排型智能体依赖这个结构。没有人把它写下来，没有人测试它。六周后，研究型智能体的提示词被优化为返回排名列表而非 sources 数组，编排型智能体就悄无声息地丢失了一半输入。
一个三人团队花了整整一个季度，为一个日活跃用户仅 200 人的应用实现了事件溯源架构。这套架构技术上无懈可击，运维上却是一场噩梦。设计方案来自 AI 的推荐，团队之所以接受，是因为推理听起来流畅、权衡分析看似严谨，而最终构建出来的系统也完全符合高级工程师架构图上的样子。
这个故事如今已成为一种警示性范式，而非孤例。AI 在特定的、可识别的场景下能够提供真正有价值的架构输入——而在从外部看起来几乎相同的情况下，它也会给出自信满满却大错特错的建议。这两者之间的差距，如果你把 AI 当成答案机器，就几乎无从察觉；但如果你把它当成思维伙伴，则完全可以驾驭。
大多数团队通过将更便宜的查询路由到更便宜的模型来优化AI推理成本。这听起来合理——但实际上是本末倒置的。首先被降级到廉价模型的查询，并不是那些简单的。恰恰相反，它们是复杂的查询，因为这些才是FinOps仪表盘标记出来的昂贵查询。
结果是：你的合同续签工作流——那个负责敲定六位数交易的关键环节——却在一个会产生幻觉、捏造条款引用的模型上运行。而你的客户支持分类——真正低风险的入门级任务——却享受着顶级模型的待遇，仅仅因为还没有人抱怨过它。
这就是预算倒置陷阱。它的产生并非源于疏忽，而是在没有价值背景的情况下单纯施加成本压力所带来的可预见结果。
你的 AI 功能上线了。它运行良好。用户正在使用。满意度评分在上升。你回头运行了原始的评估套件——依然是绿灯。六个月后，某些事情悄然出了问题，但你的仪表盘还没有显示出来。
这就是协同演化陷阱（co-evolution trap）。在你的 AI 功能部署的那一刻，它就开始改变使用它的用户。他们调整工作流、措辞和预期。这种适应使得你的功能实际处理的输入分布与发布时测量的分布产生偏离。评估套件保持绿灯，是因为它停留在部署前的世界。现实世界的表现以评估套件从未捕捉到的方式发生了漂移。
大多数团队会先发布他们最大胆的 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 治理问题。
大多数公司的本能反应是下达禁令。在网络层面封禁个人聊天机器人账号、发布政策备忘录、进行年度培训，并称之为治理。这是最糟糕的应对方式——不是因为担忧是错误的，而是因为这种干预措施在没有缩小问题的同时，反而让问题变得不可见。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
