夜雨聆风「加一个 action 字段，AI 就能识别 create / complete / delete 了。」
这是我在啵灵日程里做多意图扩展时的初始设想——看起来是一个小改动，实测下来才发现，多意图 AI 与单意图 AI 之间，隔着不止一道坎。
这篇是我个人的复盘。
背景
啵灵日程原有的 AI 能力是单意图自然语言解析：用户输入「明天下午三点跟 Alice 开会」，模型抽取为结构化事项 JSON，由用户在 Preview 界面确认后写入。该形态作用域单一、失败可降级、用户决策保留，在开发与本地测试阶段表现稳定。
随后我们尝试将解析能力扩展到三意图：
服务端实现：Prompt 增加 action 字段及分类指南；调用模型前从数据库拉取用户最近事项作为上下文，便于模型为 complete / delete 识别目标 target_id。客户端：Preview 卡片按 action 分色显示，统一确认按钮分派到对应 API。
多意图 AI 在实测中的表现
在内部测试中观察到三个现象：
基于上述观察，我们决定将该形态回退至 v2 单意图。这不是一次失败，而是一次重要的产品边界校准。
多意图为何比单意图难
一、输出 schema 复杂度的非线性影响
从单一 {title, date, ...} 扩展到 {action, target_id?, title, date, ...}，输出维度增加，对模型注意力的占用增加。
这种增加在实际表现上未必线性——增加一个分类轴可能不仅降低新轴的准确率，也可能拖累其他维度。「不会退化」不应被默认接受，而需要在真实数据上量化验证。
二、目标定位依赖动态上下文
create 是无状态操作：模型只需理解输入文本即可。complete / delete 是有状态操作：模型必须在当前数据库的具体事项中找到匹配项。
三、动作破坏性与准确率门槛不匹配
当前 LLM 在中文复杂意图分类上的稳定性，是否足以独立承担破坏性动作，需具体测试。不应基于「大模型很强」的笼统印象，将所有意图统一交给同一模型同一 Prompt 处理。
AI 与产品的边界：三项原则
推荐的实践路径
第一步：不强行合并意图
将多意图作为「一个 Prompt 让 LLM 自己判断」是看似优雅但实际脆弱的设计。更稳妥的方式：
前置一个轻量意图分类器（可用更小模型，仅判断 create / complete / delete / unknown） 每个意图路由到专门优化的下游处理（独立 Prompt 或独立工具） 各路径独立监控准确率，独立迭代
合并 Prompt 的代价是「调一个 bug 影响所有意图」。分离 Prompt 的代价是「需要维护多套」。在准确率敏感场景下，后者通常更划算。
第二步：使用结构化工具调用而非自由 JSON
主流模型的 function calling / tool_use 接口对意图识别提供原生支持。相比让模型在自由 JSON 中自己写 action 字段，调用模型选择「调哪个 tool」是更强的约束，减少自由发挥空间，提升结构正确性。
第三步：分级置信度阈值
第四步：UI 层始终保留人工覆盖入口
无论 AI 多准确，Preview 界面应始终允许：修改 AI 识别的 action、修改 AI 识别的目标、丢弃单条 AI 建议。
这是承认「AI 会出错」的设计承认，也是用户信任的根基。设计上不应假定 AI 总是对的。
第五步：可观测性先行
为每次 AI 调用建立 trace：输入文本、模型版本、Prompt 版本、模型原始输出、用户最终接受版本。无可观测性则无改进依据，模型迭代退化为基于直觉的猜测。
意图分类场景尤其需要：通过对比「AI 给的 action」与「用户最终接受的 action」可量化每个意图的真实准确率，作为下一轮迭代的依据。
结语
多意图 AI 在商业应用中的引入，不是「加一个 action 字段」的工程问题，而是「同时管理多个准确率维度 + 多个破坏性级别 + 多个上下文依赖」的产品问题。
将其作为单一 Prompt 任务统一处理是看似简洁的捷径，但实际表现往往落后于「分离意图、专门优化、分级风险」的工程化路径。
核心结论 AI 处理用户输入时的能力，与用户授予 AI 自动执行的信任，应被视为两个独立维度，分别建立。 |
📌 说明
本文为啵灵日程产品内部复盘整理，观察数据来自内部测试，未做对照实验量化 「意图分类偏向 create」等问题与「输出 schema 复杂度上升后模型注意力稀释」的假设方向一致，但尚未严格量化 文中建议为基于本次复盘整理的内部建议，未声明为通用方法论