产品引入AI能力后处理多意图边界

「加一个 action 字段，AI 就能识别 create / complete / delete 了。」

这是我在啵灵日程里做多意图扩展时的初始设想——看起来是一个小改动，实测下来才发现，多意图 AI 与单意图 AI 之间，隔着不止一道坎。

这篇是我个人的复盘。

背景

啵灵日程原有的 AI 能力是单意图自然语言解析：用户输入「明天下午三点跟 Alice 开会」，模型抽取为结构化事项 JSON，由用户在 Preview 界面确认后写入。该形态作用域单一、失败可降级、用户决策保留，在开发与本地测试阶段表现稳定。

随后我们尝试将解析能力扩展到三意图：

服务端实现：Prompt 增加 action 字段及分类指南；调用模型前从数据库拉取用户最近事项作为上下文，便于模型为 complete / delete 识别目标 target_id。客户端：Preview 卡片按 action 分色显示，统一确认按钮分派到对应 API。

在内部测试中观察到三个现象：

基于上述观察，我们决定将该形态回退至 v2 单意图。这不是一次失败，而是一次重要的产品边界校准。

从单一 {title, date, ...} 扩展到 {action, target_id?, title, date, ...}，输出维度增加，对模型注意力的占用增加。

这种增加在实际表现上未必线性——增加一个分类轴可能不仅降低新轴的准确率，也可能拖累其他维度。「不会退化」不应被默认接受，而需要在真实数据上量化验证。

create 是无状态操作：模型只需理解输入文本即可。complete / delete 是有状态操作：模型必须在当前数据库的具体事项中找到匹配项。

当前 LLM 在中文复杂意图分类上的稳定性，是否足以独立承担破坏性动作，需具体测试。不应基于「大模型很强」的笼统印象，将所有意图统一交给同一模型同一 Prompt 处理。

将多意图作为「一个 Prompt 让 LLM 自己判断」是看似优雅但实际脆弱的设计。更稳妥的方式：

合并 Prompt 的代价是「调一个 bug 影响所有意图」。分离 Prompt 的代价是「需要维护多套」。在准确率敏感场景下，后者通常更划算。

主流模型的 function calling / tool_use 接口对意图识别提供原生支持。相比让模型在自由 JSON 中自己写 action 字段，调用模型选择「调哪个 tool」是更强的约束，减少自由发挥空间，提升结构正确性。

无论 AI 多准确，Preview 界面应始终允许：修改 AI 识别的 action、修改 AI 识别的目标、丢弃单条 AI 建议。

这是承认「AI 会出错」的设计承认，也是用户信任的根基。设计上不应假定 AI 总是对的。

为每次 AI 调用建立 trace：输入文本、模型版本、Prompt 版本、模型原始输出、用户最终接受版本。无可观测性则无改进依据，模型迭代退化为基于直觉的猜测。

意图分类场景尤其需要：通过对比「AI 给的 action」与「用户最终接受的 action」可量化每个意图的真实准确率，作为下一轮迭代的依据。

多意图 AI 在商业应用中的引入，不是「加一个 action 字段」的工程问题，而是「同时管理多个准确率维度 + 多个破坏性级别 + 多个上下文依赖」的产品问题。

将其作为单一 Prompt 任务统一处理是看似简洁的捷径，但实际表现往往落后于「分离意图、专门优化、分级风险」的工程化路径。

核心结论

AI 处理用户输入时的能力，与用户授予 AI 自动执行的信任，应被视为两个独立维度，分别建立。

在准确率与破坏性的两个轴上，AI 接入应保持克制——克制不是保守，而是把边界想清楚之后，再谈扩张。