为什么开发总吐槽产品经理给的意图定义是“垃圾”？
场景通常是这样的：
开具发票 这个意图？”发票常见问题，这俩在语义上重叠了，模型神仙难断。”很多时候，Agent 的“智障”表现，不是因为模型参数不够大，也不是因为 Prompt 写得不够骚，而是因为意图分类体系（Intent Taxonomy） 本身存在逻辑塌方。
意图定义，表面上是整理语料，本质上是将人类混沌的自然语言，映射为机器确定的服务能力。
如何定义一个清晰、无歧义、高鲁棒性的意图体系？作为产品经理（PM），你需要掌握这四维意图设计法。
维度一：业务映射 —— “意图即服务”
这是意图定义的第一性原理。
很多 PM 犯的第一个错误，就是“跟着用户话术跑”——用户怎么问，他就怎么定。
❌ 错误视角（基于话术）：
Ask_Invoice_MethodWhere_InvoiceWant_Reimburse✅ 正确视角（基于服务）：
后端能提供的服务（Tool/API）是什么？只有一个：开具发票接口。
所以，无论用户怎么问，在L0 核心业务层，这只能是一个意图。
💡 判别法则：API 同构性
如果两个需求背后，调用的是同一个 API，且参数结构一致，它们必须合并为一个意图。
维度二：边界控制 —— “RAG vs Intent”
在 LLM 时代，PM 必须搞清楚：什么是意图？什么是知识？
很多 PM 会定义 查询利率、查询网点营业时间 这种意图。这是错的。
💡 判别法则：动静分离
把知识问答从意图体系里剥离出去，你的模型准确率瞬间能提升 30%。
维度三：交互体验 —— “澄清优于分类”
当用户需求模糊时，不要强行让模型去“猜”，而要设计中间态。
场景： 用户对理财助手说：“我想理财。”
❌ 赌博式分类：
模型强行命中 Recommend_Product（推荐理财产品），推了一堆基金。
✅ 澄清式交互：
定义一个中转意图：Finance_Ambiguous（理财相关_模糊）。
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 | 唯一标识
tools.flight.change_date |
|
|
Business Logic | 一句话定义边界
|
| 模型层 | Positive Cases | 正例
|
|
|
Negative Cases | 负例 (核心)
|
| 交互层 | Slots | 参数
new_date) |
|
|
Clarification | 澄清话术
|
总结
一个清晰、无歧义的意图体系，是 AI Agent 的骨架。
当你能从这四个维度去审视每一个意图时，你就不再只是一个“提需求的人”，而是一个AI 系统的架构师。
