为什么开发总吐槽产品经理给的意图定义是“垃圾”？
场景通常是这样的：
PM： “用户问‘发票去哪开’，为什么模型识别不到 开具发票 这个意图？”Dev： “因为你还定义了一个意图叫 发票常见问题，这俩在语义上重叠了，模型神仙难断。”很多时候，Agent 的“智障”表现，不是因为模型参数不够大，也不是因为 Prompt 写得不够骚，而是因为意图分类体系（Intent Taxonomy） 本身存在逻辑塌方。
意图定义，表面上是整理语料，本质上是将人类混沌的自然语言，映射为机器确定的服务能力。
如何定义一个清晰、无歧义、高鲁棒性的意图体系？作为产品经理（PM），你需要掌握这四维意图设计法。
维度一：业务映射 —— “意图即服务”
这是意图定义的第一性原理。
很多 PM 犯的第一个错误，就是“跟着用户话术跑”——用户怎么问，他就怎么定。
❌ 错误视角（基于话术）：
用户问：“怎么开票？” -> 定义意图 Ask_Invoice_Method用户问：“发票在哪开？” -> 定义意图 Where_Invoice用户问：“我要报销。” -> 定义意图 Want_Reimburse✅ 正确视角（基于服务）：
后端能提供的服务（Tool/API）是什么？只有一个：开具发票接口。
所以，无论用户怎么问，在L0 核心业务层，这只能是一个意图。
💡 判别法则：API 同构性
如果两个需求背后，调用的是同一个 API，且参数结构一致，它们必须合并为一个意图。
差异点（如：电子发票 vs 纸质发票）应通过 槽位（Slot） 来区分，而不是拆意图。
维度二：边界控制 —— “RAG vs Intent”
在 LLM 时代，PM 必须搞清楚：什么是意图？什么是知识？
很多 PM 会定义 查询利率、查询网点营业时间 这种意图。这是错的。
Intent (意图)： 是为了做事。需要调用 API，需要参数，需要改变状态（如：转账、查余额）。Knowledge (知识)： 是为了“获取信息”。答案是静态的文本。💡 判别法则：动静分离
如果是“动态”办事（如：查我的实时账单） -> 定义意图。如果是“静态”问答（如：查银行营业规则） -> 不要定义意图，直接丢给 RAG（知识库）去检索。把知识问答从意图体系里剥离出去，你的模型准确率瞬间能提升 30%。
维度三：交互体验 —— “澄清优于分类”
当用户需求模糊时，不要强行让模型去“猜”，而要设计中间态。
场景： 用户对理财助手说：“我想理财。”
❌ 赌博式分类：
模型强行命中 Recommend_Product（推荐理财产品），推了一堆基金。
✅ 澄清式交互：
定义一个中转意图：Finance_Ambiguous（理财相关_模糊）。
Action： 不调 API，而是触发多轮对话卡片 —— “您是指：1. 查看收益；2. 推荐产品；3. 知识科普？”PM 请记住： 意图定义不仅仅是 NLU 分类，更是对话流（Dialogue Flow）的设计。
维度四：数据演进 —— “全生命周期管理”
意图体系不是写完就封板的 Word 文档，它是有生命的。
1. 孵化期：从 Unknown 到 Known
上线初期，一定要定义一个 Unknown（拒识）意图。
方法论： 每周对 Unknown 日志进行聚类分析。如果你发现有 1000 个人都在问“有优惠券吗”，而你没定义，这就是下个版本必须孵化的 P0 意图。
2. 分裂期：从粗到细
初期你可能只有一个 Order_Service。
随着数据增加，发现 80% 问物流，20% 改地址。为了提升精度，必须将其分裂为 Query_Logistics 和 Modify_Address。
意图的粒度，是由数据分布决定的，不是由 PM 的想象力决定的。
📝 落地工具：工业级 PRD 模板
最后，送给大家一份的标准意图定义模板：
| | |
|---|
| 基础层 | Intent Code | 唯一标识，建议对应后端 Tool。例：tools.flight.change_date |
| Business Logic | 一句话定义边界 |
| 模型层 | Positive Cases | 正例 |
| Negative Cases | 负例 (核心)：最容易混淆的场景。例：(意图:改签) "帮我退票" (这是退票，不是改签) |
| 交互层 | Slots | 参数 |
| Clarification | 澄清话术：缺少参数时怎么问？例：“请问您想改签到哪一天？” |
总结
一个清晰、无歧义的意图体系，是 AI Agent 的骨架。
当你能从这四个维度去审视每一个意图时，你就不再只是一个“提需求的人”，而是一个AI 系统的架构师。
粤ICP备14082021号
免费POC，
零成本试错
