你不该上线的 AI 功能：任务形态错位核查清单

演示总是成功的。这是 AI 产品开发中最昂贵的一句话。产品经理看到模型处理好了理想路径（happy path），工程师发布了该功能的直观版本，六周后，支持队列里塞满了指标未能预见的投诉。模型本身没有退化。提示词（prompt）也没有变糟。只是该功能的形态并非模型所擅长的，而团队在工作开始前没有办法指出这一点。

相当大一部分已发布的 AI 功能都是以这种方式失败的——不是因为模型不好，而是因为任务错了。产品需要的输出是确定性的，而引擎是随机性的。用户对长尾误差的容忍度是千分之一的错误率，而模型的失败分布比这更厚。单位经济效益（unit economics）要求的延迟预算只有你在可负担范围内模型所能提供的一半。评估质量所需的地面真值（ground truth）并不存在，也无法低成本创建。这些都不是模型问题。它们是任务形态（task-shape）问题，应该在写下第一条提示词之前就被筛选出来。

这种情况不断发生的原因是结构性的。大多数产品流程都有“是的，构建这个”的推进路径和隐含的“推迟处理，稍后回顾”的否定路径。但缺乏一个明确的路径来表达：“这是一个真实的用户问题，但它不符合模型的形态，这里是它应该去的地方。”如果没有这个路径，每一个想法默认都会通过 AI 团队的待办事项，团队就会积累一系列在演示中运行良好但在生产环境中失败的功能。解决方法不是更好的提示词。解决方法是一个预构建清单，在进入队列之前拒绝任务形态不匹配的项目，并为被拒绝的想法提供一个去处，以免它们在下个季度换个名字被偷偷塞回来。

决定任务形态契合度的五个维度

将任何候选功能视为五个维度的向量。在估算工程量之前对每个维度进行评分。如果两个或更多维度未达标，则该功能不符合模型形态，团队应该转向而非构建。

输出确定性。 某些面向用户的界面要求在不同运行和不同用户之间相同的输入产生相同的输出——订单确认、法律披露、剂量计算、余额显示。LLM 推理在云端 API 级别即使固定了温度（temperature）也是非确定性的，因为批处理组合和静默的基础设施更改会改变采样。如果界面需要确定性输出，答案是带有确定性检查点后的可选模型辅助规则，而不是将模型放在关键路径上。演示捕捉不到这一点——在单个示例上设置温度为零与在数百万次调用中保持确定性并不是同一个属性。

长尾风险容忍度。 每个模型都有其失败分布。问题不在于“它平均表现如何”，而在于“最差的 1% 的输出是什么样的，当用户遇到它时会损失什么？”一个推荐不存在书籍的 AI 生成阅读清单是一种可挽回的尴尬。一个承诺了航空公司不予认可的退款的航空公司聊天机器人则是一场法庭裁决。一个报出没人能履行的价格的定价助手是伴随着长尾客户服务工作的收入损失。你能够辩护的容忍度受限于单次错误输出的成本乘以其发生率——而成本绝非平均情况下的成本。

单位经济效益所能支付的延迟预算。 语音代理需要在人类敏感的 200 毫秒轮换窗口内做出响应。编程助手需要在打字节奏内完成补全。搜索重排序需要适应页面加载预算。这些任务中的每一个都有技术上能胜任的模型，以及单位经济效益能支撑的模型，而它们往往不是同一个模型。如果满足质量要求的最便宜模型在高峰期超出了延迟预算，那么该功能就不该发布——它需要路由策略、积极的缓存或不同的形态。在构建之后才发现这一点代价高昂。

评估可行性。 团队必须能够对输出进行评分。当任务是开放式的——摘要、推荐、创意输出、带有判断力的助手响应时，这比听起来要难。如果没有办法构建一个反映生产分布的评分数据集，团队就是在凭感觉（vibes）进行发布和评估。地面真值是当产品火热时被悄悄放弃的约束，而它也是以后作为团队无法回答的监管请求而回弹的问题。清单应该询问：谁来编写评估，何时编写，针对哪种分布。如果没有人能给出可信的答案，那么该功能尚不具备评估可行性。

监管风险。 某些界面位于模型跨越的审计边界内。医疗建议、财务推荐、法律相关的辅助、任何影响受保护群体的内容——这些都有文档负担和责任风险，且与模型的好坏无关。在消费者聊天产品中没问题的功能，在受监管的界面上以同样的形式出现就不行，而尽职调查的成本由发布的团队承担，而非提议的团队。

清单在会议室中的实际作用

这份清单并不是一份长篇大论的文档。它是一个单页的向量，包含每个维度的评分，以及针对最差评分的讨论。它的职责是让讨论变得具体。“用户在这里是否能容忍幻觉”变成了“幻觉率是多少，每次发生的成本是多少，我们愿意投入的预算是多少，以及我们如何衡量对这一预算的遵守情况”。“我们能否评估这个功能”变成了“标注员是谁，一致性率是多少，以及我们抽样的生产环境分布是怎样的”。

大多数团队并不需要正式的评分细则——他们需要的是一个强制函数 (forcing function)，在功能进入开发队列之前，将最差的情况暴露出来。两个维度不及格意味着重定向。一个处于边缘的维度意味着需要在开发时制定明确的缓解措施，并预先记录终止标准。零维度不及格则是正常的开发流程。

强制函数之所以奏效，是因为它将隐性假设转化为明确命名的风险。曾说“用户会容忍偶尔错误”的产品经理现在必须给出一个数字。曾说“我们大概能达到延迟目标”的工程师现在必须承诺一个预算。曾说“这没问题”的法务合伙人现在必须确定审计界面。这一切都不会减慢健康的开发进程。它所做的是在沉没成本让项目无法终止之前，及时阻止一个糟糕的开发计划。

“非 AI 形态”路径

AI 产品流程中最被低估的一环，是一个记录并可见的、用于存放被拒绝的功能构思的地方。如果没有它，讨论会以“不，这不合适”告终，构思回到 Slack 讨论串中，三个月后，同一个构思会由不同的利益相关者以不同的表述再次提出。团队又不得不从头开始重新审议这一拒绝逻辑。

“非 AI 形态”路径包含三个部分。第一，一个去处——一个 Wiki 页面、一个看板列，或者一个按优先级排列的“被重定向”构思积压列表，记录失败的维度和建议的替代形态。第二，一个替代形态目录——常见的重定向方案，如“这是一个带模型回退的规则引擎”、“这是一个带模型增强排名的搜索问题”、“这是一个在人工审核后使用模型辅助的工作流工具”、“这其实不是用户需求，而是某人想要提升的指标”。第三，重新准入标准——未来需要发生什么变化，这个构思才能重新变得“适合 AI”，这样团队就不必维护一个没有回头路的构思坟墓。

这听起来像是在增加管理负担。但当利益相关者第一次重启一个被拒绝的构思，而团队可以指出失败的具体维度以及使其可发布的具体变化时，这种投入就得到了回报。对话不再关乎个人品味，而是关乎证据。

你应该为已发布功能撰写的复盘报告

有些功能即使未通过清单评估也会发布，有些功能虽然通过了评估但在生产环境中却失败了。这两种情况都值得复盘。标准的事故复盘是围绕停机展开的——什么坏了，我们何时发现的，我们如何恢复的。而针对任务形态的复盘则会提出一套不同的问题。

清单漏掉了哪个在生产环境中失败的维度？最常见的模式是尾部风险容忍评分，它在期望值上看起来可以接受，但在实际分布中却不可接受——错误输出的比例在团队可接受范围内，但单次发生的成本却高于模型的假设。复盘报告应记录团队低估了尾部成本，并相应地更新评分细则。

评估 (Eval) 漏掉了什么？评估通常是针对精选数据集进行的，这无法反映生产环境的分布。修复方法不是重新训练模型。修复方法是用生产队列采样评估取代静态评估，并将其视为发布门槛。这一改变通常会暴露其他评估同样陈旧的功能。

开发的成本与重定向的成本相比如何？这是一个难题。团队很少记录规划时可用的重定向替代方案，因此当发布的功能表现不佳时，对比就变成了“我们发布的功能”与“什么都不做”。这种框架让开发看起来比实际情况更好。一份好的复盘报告会重建替代路径，并询问团队根据目前掌握的信息，是否会再次做出同样的决定。

复盘是会产生复利效应的。在进行几次复盘之后，清单会变得更尖锐，“重定向路径”的去处会变得更丰富，组织也会形成模式识别能力，让新构思的评分速度变得更快。提交了第三份任务形态复盘报告的团队比一份都没做的团队跑得更快，因为后者每个季度仍在从头开始重新审议那些本该拒绝的提案。

资深工程师的职责是说“不”

在 2026 年，资深 AI 工程师最高杠杆的工作不是写出更好的提示词 (Prompts)。而是识别出提议的功能何时不适合 AI 形态，并在团队投入之前将其重定向。这与直觉相悖，因为在更广泛的工程组织中，资深程度的信号是吞吐量——发布的功能、审查的代码行数、维护的系统。但在 AI 工程中，资深程度的信号是作品集的质量——发布的功能中有多大比例仍能像演示时那样运行，以及团队避免了开发多少糟糕的功能。

文化上的问题在于，在一个接受了“AI 无处不在”叙事的组织中，“不，这不是一个好的 AI 功能”听起来像是在阻挠。解决之道不是更大声地拒绝。解决之道是一个任何人都可以运行的清单、一个存放被拒绝构思的去处，以及一种能为拒绝提供数据支撑的复盘文化。经过足够多的循环后，说“不”的是流程而非工程师，工程师则可以重新投入到那些应该被开发的功能中。

一个发布所有递到面前的 AI 构思的团队，并不比一个筛选构思的团队更快。它反而更慢，因为它正在支付开发、支持和悄悄下线那些本不该开始的功能的成本。筛选即加速。清单即杠杆。资深工程师的工作就是让筛选变得足够乏味，以至于它能默认发生。