发现的能力：当用户上线了你团队从未规划的功能

一个客户给客服发邮件，询问为什么你的 CRM 智能助手停止起草他们的 NDA 了。你根本不知道你的 CRM 智能助手竟然在起草 NDA。一位资深用户抱怨说，你的客服机器人的他加禄语（Tagalog）翻译质量自上周以来有所下降。你根本不知道你的客服机器人还会他加禄语。一个论坛帖子传播了一个提示词，能将你的代码审查助手变成一个还算凑合的安全扫描器，不到一个季度，你就收到了针对该助手生成结果提交的 CVE 报告。其中的每一项都是一个拥有用户群、业务影响力，但完全没有组织归属的功能——没有评估（eval）、没有 SLA、没有在 UX 中体现、没有列入路线图，而且还有一个隐蔽的、仅为 1 的公交因子（bus factor）：那个摸索出这种用法的客户。

当你的产品封装了一个能力范围（capability surface）远超你设定范围的模型时，就会发生这种情况。用户会探索更广阔的能力范围，寻找能解决他们问题的行为，并在这些行为之上构建工作流。然后，当你进行下一次模型升级时，即便你的路线图上没有任何变动，他们也会将其视为一种退化（regression）。你与用户之间的契约不再是你书面写下的那份。它包含了模型碰巧为他们做到的、且你碰巧没有破坏掉的所有事情。

将此视为工程上的意外——“我们会强化提示词，增加护栏，下次我们会捕获到它”——这是一种范畴错误（category error）。“发现的能力”（Found capabilities）是一个产品管理问题。这门学科的核心不在于防止它们发生，而在于检测它们、决定如何处理它们，并记住你曾做出的决定。

“发现的能力”的解剖

“发现的能力”具有三个传统功能所不具备的属性。首先，它在拥有负责人之前就已经有了用户——采用行为先于任何团队对该行为存在的察觉。其次，它的边界是由底层模型而非你的代码定义的：该功能是“模型今天在处理这类输入时碰巧表现良好的任何行为”，这是一个移动的目标。第三，它的存在对你的评估套件（eval suite）是不可见的：你针对决定上线的功能编写了评估脚本，因此模型可能会在回归过程中完全失去这项能力，而你的 CI 却依然显示绿色。

例子层出不穷。ChatGPT 用户经常将助手当作律师；关于如果法律建议出错 OpenAI 是否应该承担责任的诉讼正在进行中。客服机器人被用户指示“同意所有请求”，然后因做出荒唐的承诺而被当作权威引述。代码助手被强行推上岗位，充当安全扫描器、重构规划器、依赖审核器和文档生成器。这些都不在路线图上，但它们都有用户。

这种情况之所以与“影子 IT”（shadow IT）相似，是因为它们的失效模式是相同的：需求存在，官方产品未覆盖，用户于是利用手头现有的任何工具来绕过缺口。不同之处在于，影子 IT 的工具来自你的防御边界之外；而对于“发现的能力”，工具 就是 你的产品。你无法推卸责任。

洞察意图而非仅是 Token 的遥测技术

大多数生产环境中的 AI 系统在这个问题上记录了错误的信息。它们记录延迟、Token 计数、提示词和补全文本、拒绝率以及工具调用追踪。这些是调试单个请求的正确原语，但对于察觉上周 8% 的流量现在是你的 CRM 智能助手被要求起草合同来说，它们的观察高度不对。

你需要的信号是意图漂移（intent drift）：即用户实际要求系统执行的操作的 分布 发生了变化。意图漂移在单个请求级别是不可见的，但在群体级别却显而易见。揭示它意味着将每个请求视为具有一个潜在的意图标签，随着时间的推移对这些标签进行聚类，并观察那些在团队没有发布任何相关功能的情况下却不断增长的聚类。

在实践中，这看起来像是几个活动部件协同工作：一个运行在采样流量上的轻量级意图分类器（通常一个小巧、便宜的模型就足够了），一个能将你设定的意图与兜底的“其他”类别区分开来的稳定分类法，以及一个旨在让“其他”类别变得无法被忽视的仪表盘。当“其他”类别在一个季度内从 3% 攀升到 15% 时，这就是你的信号。没有那个仪表盘的团队只能通过流失面谈来了解其“发现的能力”。

第二层防线很有帮助：对输入措辞和输出结构进行异常检测。如果模型以前生成散文，现在开始生成 JSON，或者开始用一种你从未测试过的语言回答，这种结构性的转变会在意图转变之前显现出来。标准的 AI 可观测性工具可以通过统计学检测到这些；这门学科的关键在于将这些告警发送给一个有权询问“我们现在是否应该有意识地上线这个功能？”的人。

分流决策：提升、弃用或容忍

一旦发现的能力变得可见，你有三个选择，而假装只有两个选择是大多数团队都会陷入的陷阱。你可以提升（promote）它——将其纳入评估套件，在 UX 中命名，指派负责人，将其视为一份契约。你可以弃用（deprecate）它——在提示词或护栏层拒绝该意图，向受影响的用户告知这一变化，并接受用户流失。或者你可以容忍（tolerate）它——明确表示不支持但也不封禁，同时接受下一次模型升级可能会移除它的事实。

“容忍”是一个真实且通常正确的选项。提升每一个发现的能力会将你的路线图变成积压他人意外行为的待办列表。弃用每一个发现的能力等同于免费允许竞争对手接管这些工作流。错误在于含糊地做出选择。一个在没有人决定容忍的情况下被“容忍”的能力，等同于偶然间不被支持的能力——这意味着下一个问“我们支持这个吗？”的人，会根据他们询问的对象不同而得到不同的答案。

一个实用的决策树，大致按以下顺序应用：

• 品牌契合度。 如果一个发现的能力是客户要求你的客服机器人充当心理治疗师，即使评估分数看起来不错，你可能也会原则上拒绝。品牌风险在后续环节是不可妥协的。
• 评估覆盖的可行性。 你能否构建一个测试集（held-out set），足以捕捉这项能力以检测回归？如果答案是“我们没有标注的例子，也没有明显的来源”，那么提升它还为时过早。
• 回滚方案。 如果下一次模型升级悄无声息地降低了这种行为的表现，你的检测滞后是多少，你的修复措施是什么？“我们会固定在旧模型上”是一个真实的答案，但前提是你之前这样做过。
• 数量阈值。 每月只有 12 个客户使用的发现的能力通常默认选择“容忍”。同一项能力如果被 12% 的 MAU 使用，则需要做出“提升”或“弃用”的决策；在如此规模下选择“容忍”意味着当模型改变时会发生事故。

决策树的输出不应仅仅是一个结论。它应当是“发现的能力登记表”（found-capabilities registry）中的一个条目——这份清单记录了团队已知、已分类、已指派负责人并定期回顾的能力。登记表与路线图不同，因为路线图描述了你承诺上线的能力；而登记表描述了模型承诺为你上线的能力。

静默升级故障模式

这一切之所以如此紧迫，是因为团队发现其“发现的能力”（found capabilities）最常见的方式就是失去它们。推理平台会悄无声息地更新模型权重、更换量化方式、更改推理预算并调整默认采样参数。这些操作都不会触及你的端点名称，也不会出现在更新日志中。但每一项操作都可能移除模型曾经表现出的某种能力，而某些用户群体可能已经围绕这种能力构建了工作流。

过去一年的事后分析中充斥着这种模式：一个编程助手的 CI 失败率在三天内翻了一番，因为后端模型在未通知的情况下进行了更换；一个写作工具的用户报告质量明显下降，原因是出于延迟考虑，系统提示词被收紧到了 100 字的上限；推理退化表现为数周内零星的 Reddit 投诉，随后供应商才确认了默认设置的更改。每一案例都首先影响了“发现的能力”，因为“发现的能力”恰恰是那些没有任何评估（eval）覆盖来捕获它们的能力。

缓解措施并不光鲜。在支持固定版本的地方，固定模型版本。针对从你的记录库中提取的一组“用户发现”的提示词（而非仅仅是你的预设提示词）运行影子评估（shadow evals）。将任何已记录能力的数量下降——即使是由于容忍而允许的下降——视为值得调查的信号。做到这一点的团队能在几天内发现退化，而不是在几个季度后的流失访谈中才得知。

组织层面的觉悟：这是 PM 的工作，而非工程工作

当“发现的能力”浮现时，人们往往倾向于将其推给工程团队：“强化提示词以拒绝它”或“添加评估并修复它”。这两者都不是首选方案。第一步应该是产品决策：我们是否希望这成为我们与用户之间契约的一部分？如果希望，条件是什么？

这一决策需要一个负责人，他要有权决定路线图容量，有视野权衡品牌和法律风险，并有判断力在“容忍”是正确答案时做出裁决。这就是产品管理。工程团队负责实现产品经理做出的三种选择中的任何一种——但工程层并不适合做出选择本身，因为工程的动机倾向于“消除不确定性”（弃用），而正确的答案可能是“我们刚刚免费获得了一个功能”（晋升）。

那些处理得很好的组织，其 PM 阅读意图漂移（intent-drift）仪表盘的方式与阅读转化漏斗的方式相同。在 PRD 中，“发现的能力”作为一个经常性章节出现：用户正在行使哪些新行为，我们对每一项行为的立场是什么，本周期记录库有哪些变化。不这样做的 PM 会在客户咨询委员会、流失访谈，或者最糟糕的情况下——在诉讼中发现他们“发现的能力”。

你从未书写的契约

更深层的架构层面体悟是，你与用户之间的契约并非服务条款或功能列表中的内容。它是模型产生的、可靠到足以让用户在其上构建工作流的所有行为的并集。你的用户不知道你预设的能力与模型恰好支持的能力之间的区别。在他们看来，这些都是同一个产品。

你可以假装不是这样，很多团队确实是这么做的。代价是，每一次模型升级都变成了针对你甚至不知道自己拥有的能力的一场俄罗斯轮盘赌，每一次客户投诉升级都是一次发现工作流的机会——这些工作流你的路线图从未承认，但你的留存曲线却一直在悄悄依赖它们。

做得正确的团队并不是那些拥有最干净提示词或最严格护栏的团队。他们是那些构建了反馈闭环的团队——能够洞察意图的遥测、能够产生决策的分选、能够记住它们的记录库，以及一个对结果负责的 PM 职能部门。模型将不断向你的用户交付你并未发布过的行为。你的工作是决定其中哪些成为契约，哪些被拒绝，以及哪些你在清醒的状态下予以容忍。随之而来的架构体悟微小且令人不安：你不再是唯一向你的产品发布功能的一方。