一个团队以 70% 的准确率发布了某个 AI 功能。十八个月过去了。用户起初抱怨，随后逐渐适应。他们学会了哪些提示短语能绕开边缘情况，知道了涉及日期的输出需要二次核查，因为 AI 有时会产生特定字段名称的幻觉，所以他们在工作流中加入了验证步骤。然后团队发布了新模型，准确率跃升至 85%。支持工单激增。投诉最多的用户，恰恰是那些最重度使用该功能的人。
这就是"准确率即产品契约"问题，而且大多数 AI 团队都是以惨痛的方式发现这一点的。
每个上线 AI 功能的工程团队最终都会碰到同一堵墙：财务部门要看一份证明支出合理性的表格，但你做的那份根本行不通。
问题不在于 AI 功能缺乏 ROI，而在于 AI 的经济逻辑打破了标准 ROI 模型的每一个假设——固定资本、线性成本曲线、可预期的回收时间线。把 AI 支出当作 SaaS 许可费来处理的团队，要么在上线前看到虚高的数字，要么在投产六个月后看着数字崩塌。有计划的 AI 项目（ROI 达 55%）与随意部署的项目（ROI 仅 5.9%）之间近十倍的差距，几乎完全来自于团队是否在上线之前就建立了正确的度量模型。
每个 AI 融资演讲稿中都会包含一张关于数据飞轮的幻灯片。故事听起来很诱人：用户与你的 AI 功能交互，交互产生数据，数据训练出更好的模型，更好的模型吸引更多用户，循环往复。只要规模足够大，你就能拥有一道难以逾越的竞争护城河。
问题在于，大多数发布 AI 功能的团队并没有飞轮。他们只有一个日志文件。一个非常巨大、存储成本极高，但从未改进过模型，也永远不会改进模型的日志文件——因为实现真正飞轮的三个前提条件缺失了，而且没有人问过这些条件是否存在。
科技行业的传统智慧——快速行动、尽早发布、建立护城河——在模型改进曲线的特定阶段会在 AI 领域变得致命。2023 年，数十个团队围绕一项单一能力建立起了可行的业务：让用户上传 PDF 并提问。随后，OpenAI 在 ChatGPT 中添加了原生文件上传功能。这些业务的死亡不是因为行动太慢，而是因为它们行动得太早。
这并非孤立事件，而是构建在快速迭代基础模型之上的结构性特征。大多数发布时机框架是为速度较慢的技术曲线设计的。你过去用于决定何时发布 SaaS 功能的框架并不适用于 AI——输入不同，失败模式也完全不同。
一家大型医疗保险公司部署了一套AI工具来评估病后护理索赔。该系统的错误率超过90%——也就是说，每十个经人工审核人员最终推翻的拒赔案例中，有九个是被错误拒绝的。然而这些拒赔并未被主动纠正。患者不得不逐一提出申诉。当诉讼来临时，公司的回应是将矛头指向AI。
AI什么都没有拒绝。是人类在他们自己设计的工作流程中大规模地批准了这些拒赔，在他们选择部署的系统里。但"AI决定了"这句话把责任引向了一个方向，恰好让组织、批准上线的高管以及在每个案例上签字的审核人员得以脱身。
这就是责任转移问题——它不是未来的风险，而是已经在生产AI系统中普遍存在的现实。
大多数团队会先发布他们最大胆的 AI 功能。那个功能通常是他们研发了六个月、演示效果极佳、且让领导层倍感兴奋的作品。但它在生产环境中失败了——算不上灾难性的，但足以让用户感到不安——于是，随之而来的每一个 AI 功能都会继承这种怀疑。即使团队后来修复了最初的问题，接下来的整整一年里，他们依然会纳闷为什么采用率始终停滞不前。
这就是“第一个 AI 功能”的问题。你首先发布的内容建立了一个先例，这种影响在技术问题解决很久之后依然存在。用户对 AI 的信任建立在第一次失败之上，而非第一次成功。你发布功能的顺序比任何单一功能的质量都更重要。
模型跑通了。流水线运行正常。演示效果很好。然后这个功能就在数据团队的 Slack 频道和产品工程师的 JIRA 看板之间悄然死去。
这是大多数 AI 项目失败背后的规律——不是技术失败，而是组织失败。2025 年的一项调查发现，42% 的公司那年放弃了大多数 AI 项目，而上一年这一比例仅为 17%。每个被放弃的项目平均沉没成本高达 720 万美元。当事后复盘被写出来时，列出的原因是"数据准备不足"、"职责不清"和"缺乏治理"——这三种说法其实是同一件事的不同表达：没有人真正负责把这个功能交付出去。
一个用户在周二下午 3 点打开了你的 AI 功能。他们已经轻度使用了三周。这次请求卡住了 8 秒钟，然后返回了一个红色的横幅：“出错了。请稍后再试。”他们又试了一次。还是同样的横幅。他们关闭了标签页，回去做之前在做的事情 —— 并在第二天早上的站会上告诉队友，“那个 AI 功能坏了。”
实际发生的情况是：他们触碰到了一个隐形的单用户配额，这是你的成本团队在六个月前为了防止单个重度用户刷爆 GPU 预算而设置的。配额起作用了。支出保持平稳。仪表盘显示绿色。按照你的工程组织追踪的每一个指标来看，这项功能都是健康的。但它也已经名存实亡了，因为看到那个横幅的用户再也不会回来了，而且他们在站会上告知的那三个队友也永远不会去尝试它。
这就是你的成本仪表盘看不见的鸿沟。单用户 AI 配额是一个产品界面（product surface）。那些将其隐藏在 HTTP 429 错误代码中的团队，正任由其成本控制系统默默地塑造用户对产品的认知，而且直到流失率在季度回顾中显现出来且没有明显原因时，他们才会发现这一点。
每个 AI 功能上线前都有一个同样的静默时刻：在第一个用户看到它之前，团队中的某个人会问“我们怎么知道这个东西好不好？”，而诚实的回答是“我们现在还不知道”。你没有追踪记录 (traces)，因为你还没有用户。你没有用户，因为你还没有发布。这是一个真实的死循环，而它产生的两种失败模式都是致命的——要么盲目发布，让第一周的线上问题 (escalations) 成为你的评估数据集；要么等待“真实数据”，眼睁睁地看着产品路线图推迟一个季度，而竞争对手却发布了演示视频。
摆脱困境的方法不是假装冷启动评估与发布后的评估是同一个问题（只是样本量较小）。事实并非如此。你不是在对分布进行采样，而是在构建先验 (prior)。上线首日的每一个信号都是你所做选择的产物——关于衡量什么、模拟谁的行为以及关注哪些失败的选择。能够出色发布 AI 功能的团队会将发布前的评估栈 (eval stack) 视为一等交付物——它不是在准入审查前一晚匆忙拼凑的电子表格，而是一个由内部试用 (dogfooding)、模拟、专家标注和对抗性探测 (adversarial probes) 组成的层级化系统，每一层都提供不同类型的信号，并伴随着关于它能告诉你什么以及不能告诉你什么的明确说明。
每个 AI 产品团队都会有一种特定的会议，通常发生在周四。有人共享屏幕，在 notebook 里输入一个 prompt，然后运行三四个例子。房间里的人反应热烈。大家惊叹“哇”。有人截图发到 Slack。决策就这样做出了——上线、更换模型、调整 temperature。没有人记录失败率，因为根本没人去衡量它。
这就是演示循环（demo loop），它带有一种几乎没有团队意识到的结构性偏见：它筛选的不是最佳输出，而是最“易读”的输出。几周或几个月下来，你的 prompt 不断演进，最终生成的是那些能“在会议中镇住场面”的答案——自信、流利、格式整齐、切中主题。至于它们是否正确，则是另一个变量，而你的流程并没有衡量这个变量。
其结果就是我所说的“有魅力的失败”（charismatic failure）：输出结果在某些方面是错误的，但由于选择压力，你的演示循环已经被训练得会自动忽略这些错误。
一家中型项目管理公司的产品副总裁，花了三个季度的工程团队路线图来构建 AI 助手。上线六个月后，每周活跃使用率只有 4%。问她为什么要做：「竞争对手发布了一个，董事会问我们什么时候跟上。」这是一个用产品战略包装起来的恐慌决策——而且这种情况现在到处都是。
4% 不是个例。一个客户成功平台在四个月后，AI 生成通话摘要的采用率是 6%。一个物流 SaaS 添加了 AI 路线优化建议，点击率 11%，实际操作率 2%。一个 HR 平台推出了 AI 政策问答机器人，火了两周，然后跌落至 3% 后趋于平稳。这个规律已经稳定到可以命名了：发布 AI 功能，眼看它被忽视，十八个月后悄悄下线。
默认的解释是 AI 不够好。有时确实如此。但更多时候，模型没有问题——用户压根就没找到这个功能。
你的团队在六个月前发布了一项由 AI 驱动的摘要功能。采用率停滞在 8% 的用户。模型调用每月耗资 4,000 美元。构建该功能的工程师已经调到了另一个团队。现在，模型提供商正在涨价。
所有的直觉都在告诉你：砍掉它。但事实证明，停掉一个 AI 功能要比停掉任何其他类型的功能都难得多——大多数团队都是在退役过程中，当合规问题开始出现、核心用户开始反抗时，才以惨痛的方式意识到这一点的。
这是一份在发布功能之前就应该存在的指南，但在你盯着那些明显指向退出的使用率图表时，它最为有用。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
