因为我最近在一个在线协作平台做了个 AI 助手，让团队用自然语言管项目。
比如：帮张三建个任务、这个迭代进度怎么样、哪些需求延期了，系统听懂后就自动执行。
做到现在，57 个意图，7 个业务域，准确率从 86% 干到了 97%。
这篇文章是我从头到尾踩过的坑和改过的方案。
第一阶段，把所有希望寄托在一个 prompt 上
最初的方案很直接。把所有意图的名称和描述塞进一个 prompt，让 LLM 返回匹配结果。一个 prompt 同时做三件事：识别意图、提取参数、输出置信度。
实际跑起来，两个问题立刻暴露。
慢。50 多个意图的完整描述塞进 prompt，大概 5000 token，LLM 每次调用 3 到 4 秒。对话系统的用户期望秒级响应，等不了。
不准。选项太多，LLM 经常在语义相近的意图之间漂移，用户说任务情况，它可能匹配到客户查询、工作记录、数据统计中的任何一个。
我把 50 多个意图按用户心智模型划成 7 个语义域，项目、任务、资源、迭代、团队、通知、数据，每个域配一组关键词。用户输入先过关键词匹配，确定落在哪一两个域，只把该域的 5 到 10 个意图送进 LLM。同时把 prompt 格式从多行描述改成单行紧凑格式，每个意图从大概 100 token 压到 40 token。再把意图识别模型从通用推理模型换成速度更快的轻量模型。
效果立竿见影。延迟从 3 到 4 秒降到 0.5 到 1.2 秒，准确率也涨了，候选少了，LLM 更容易选对。
但这带了新问题。
第二阶段，域预筛选，从 3s 降到 0.5s，但漏词是无底洞
域预筛选靠关键词，而关键词永远不够全。
每次联调都能发现新漏词。进度这个高频词，我没放进任何域的词库，任务情况、工作记录全部匹配失败。今天团队进度怎么样，没命中数据域也没命中任何任务锚点，走了闲聊。完成率在数据域的词库里，但不在任务型意图的锚点里，经营报告任务没被注入候选。
除了漏词还有误伤。我设了怎么操作、怎么做这些关键词匹配操作指南类意图。结果下个迭代怎么提效率被怎么做三个字命中，路由到了操作指南检索，但这明明是个经营策略问题，不是系统操作教学。
我搞了三层防御。
负向排除，给容易误伤的关键词加排除模式，怎么做命中操作指南，但怎么做能、怎么做才能这种模式排除掉。
多域叠加，一个关键词可以命中多个域取并集，进度同时指向迭代域和数据域。
全量兜底，如果没有任何域命中，不拒绝，用全量意图压缩格式做一次识别，宁可慢一点也不漏掉。
但说实话，这只是在打补丁。关键词方案的上限就在那里，能解决 70% 的路由问题，剩下 30% 需要语义理解。这个认知为后面的 embedding 通道埋下了种子。
回头看，这个阶段最重要的收获不是关键词怎么配，而是意识到基于规则的召回和基于语义的理解是两种根本不同的能力。后来的双通道架构，起点就在这里。
第三阶段，架构分层，让 LLM 只做理解，代码做决策
做了域预筛选之后准确率提升了，但一类问题始终解决不好：LLM 同时做理解和决策，两者逻辑互相打架。
具体来说，我的 prompt 要求 LLM 做三件事：识别涉及哪些意图，做 NLU；给出置信度，低于 0.6 就走闲聊，做路由决策；判断是单意图还是多意图需要编排，做编排决策。
结果很糟糕。
置信度是个坑。LLM 对任务型意图，利润分析、热销排行，经常给 0.4 到 0.5 的置信度，不是没识别到，是对自己不确定。但我的阈值 0.6 把它们全拦掉了，一个阈值干掉了一半的任务路由。
多意图检测不稳定，用户说建个项目再拉个群聊，LLM 应该识别出两个意图，但它经常直接匹配第一个，把第二个吃掉。
业务判例越堆越多。为了修单个 case，我往 prompt 里加规则：任务情况转数据、创建活动不匹配查询、入库和出库不要混淆。prompt 从 10 行规则膨胀到 40 行，每修一个 case 可能引入两个 regression。就是在用自然语言写 if-else。
核心改法很简单，LLM 只做语言理解，路由决策交给代码。
旧流程是 LLM 直接输出路由结果和编排判断。新流程里 LLM 只输出这句话涉及哪些意图，代码根据 len(intents) 做编排，根据结构化评分做路由。
具体改了三件事。
Prompt 瘦身，删掉全部业务判例规则，从 40 行砍到 5 行。LLM 只需要输出这句话涉及哪些意图，不需要做任何路由判断。
结构校验层，在 LLM 输出之后路由之前加一层确定性校验。每个意图预先声明它的动词类型，query、write、report、analyze，和参数语义模式，人名、手机号、金额、日期。代码根据声明做评分排序：score = 必填覆盖乘以 0.50 加 参数模式匹配乘以 0.30 加 动词匹配乘以 0.15 加 LLM 置信度乘以 0.05。
注意 LLM 置信度只占 5%。主决策靠结构化信号，LLM 置信度降到微调级别。
四态裁决：
CLEAR，唯一候选或分差明显，直接执行；
AMBIGUOUS，多候选分差小，追问用户或编排；
INSUFFICIENT，候选确定但缺参数，槽位追问；
REJECTED，全部淘汰，域引导拒绝或闲聊。
这一步改完之后，prompt 里的业务判例全清了，但识别准确率反而提升了，因为原来那些规则本来就互相打架。
我后来把这阶段总结成一条原则：系统中规则的唯一合法形式是结构化规则，基于 schema、类型、模式的判断。在 prompt 里用自然语言写的业务判例，说到底就是不可维护的 if-else。
如果你正在准备简历或面试，需要简历优化、面试辅导或者求职陪跑，可以在置顶动态找我。前端、后端、AI 全栈、AI Agent 应用开发这几个方向都可以。
第四阶段，问题分流，不是所有输入都该进意图匹配
架构分层之后意图匹配链路本身稳定了很多，但一类问题暴露了：有些用户输入压根不该进入意图匹配。
三个典型 case。
建项目怎么操作，被匹配到了建任务意图，缺参数开始追问任务ID和金额，但用户想问的是怎么操作系统，不是要执行建任务。
下个迭代怎么提效率，被匹配到了利润分析任务或操作指南，但这是个经营策略问题。
分析一下，被匹配到了经营策略建议，但用户刚查了某个客户的详情，说的是分析这个客户。
这三个问题的共同点是，它们需要在意图匹配之前先回答一个更基本的问题：这是不是一个技能问题。
在意图识别之前加一层 Problem Type 预分类，把用户输入先分成五类。
ACTION，明确执行动作，如帮张三建个项目；
QUERY，明确查数据，如查一下这个迭代进度；
GUIDE，问系统怎么操作，如建项目怎么操作；
STRATEGY，问经营建议，如下个迭代怎么提效率；
CHAT，闲聊，如你好。
分类器两步走：先用规则，关键词加模式匹配，规则不确定时才调一次轻量 LLM，不注入意图列表只判断问题类型。
这样，操作教学和经营策略在入口就被分流了，不再和业务意图竞争。
这一步揭示了一个容易被忽视的前提：不是所有用户输入都适合走意图路由。强结构任务如建任务发货适合；弱结构查询如分析数据适合但需要更强的推理；开放问题如经营策略操作教学根本不该进入意图竞争。先判断这是不是一个意图问题，比匹配哪个意图更重要。
但 case 3 分析一下还没解决。单看这四个字，Problem Type 判定为 STRATEGY 完全合理。问题在于它不感知对话上下文。所以又加了一层上下文拼装：在分类之前先检查对话中是否有刚解析的实体，比如刚查了某个项目。如果有，把实体信息拼入分类输入，分析一下变成分析一下某个项目，Problem Type 就能正确判定为 QUERY。
第五阶段，三模型对比，发现单模型天花板
做了上面所有优化之后，我决定用数据说话。写了 104 条标注路由 case，覆盖正向匹配、边界表达、混淆干扰三类，跑了三个不同能力等级的 LLM。
轻量快速模型，准确率 80.8%，平均延迟 2.2 秒。
中等均衡模型，准确率 82.7%，延迟 6.0 秒。
强力推理模型，准确率 86.5%，延迟 15.1 秒。
三个关键发现。
中等模型性价比极低。比轻量模型只提高 1.9%，延迟翻了 2.7 倍。意图识别不需要强推理能力，用贵模型是浪费。
数据分析域是最大的失败点。轻量模型在分析域只有 47% 的准确率，强力模型有 87%。利润分析、热销排行、延期预警这类任务型意图需要 LLM 做语义归纳推理，简单的关键词匹配和模式识别不够用。
没有一个模型突破 87%。27 条不同的失败 case 中，只有 4 条是三模型共同失败的，也就是说 73% 的失败是模型特异的。每个模型有自己擅长和不擅长的场景。
也就是说，如果能让不同能力互补，准确率应该能显著提升。
把失败 case 按根因分类，发现了五种模式。
任务型意图被误判为闲聊，占大约六成，LLM 给低置信度被阈值拦掉。
短词命令被误判为操作指南，占大约一成五，规则层过早拦截，LLM 没机会处理。
跨域语义歧义，占大约一成。
口语化表达不识别，调个期、人够不够，占大约一成。
歧义误判为多意图，占大约半成，查一下这个任务被当成 8 步编排。
占比最大的前两类，说到底也是同一个问题：单通道方案的天花板到了。纯 LLM 方案语义推理强，但置信度不稳定，对短词和口语表达识别弱。如果换成纯 embedding 方案，关键词匹配好，但间接表达不行，这个任务取消掉匹配不到取消订单。
这直接指向了最终方案。
第六阶段，双通道融合，突破天花板
我把最终方案总结为三层：Intent Resolution = Recall 召回加 Reasoning 推理加 Ranking 排序。
Recall 从候选池中快速找出可能相关的意图，用 embedding 向量检索。
Reasoning 对候选做语义推理和消歧，LLM 在意图树上推理遍历。
Ranking 多信号融合评分，输出最终判决，alpha 加权排序加三态决策。
这个结构不只适用于意图识别。RAG 里的文档选择、Agent 里的工具选择、推荐系统里的候选排序，说到底都是同一个问题：多信号转统一评分再排序决策。只是每个场景的 Recall 和 Reasoning 实现不同。
在意图识别这个具体场景下，Embedding 做 Recall 和 LLM 做 Reasoning 各有优劣，互补性极强。
用户说取消订单，纯 Embedding 能命中 cancel_task，纯 LLM 也能命中。
用户说这个任务取消掉，纯 Embedding 匹配不到，纯 LLM 能命中 cancel_task。
用户说今天团队进度怎么样，纯 Embedding 走到 query_revenue，纯 LLM 走到 daily_report。
用户说什么卖得最好，纯 Embedding 走到 query_product，纯 LLM 走到 hot_selling。
两个通道并行执行，结果融合为三态判决。Embedding 通道 5 到 15 毫秒跑完，意图树推理通道走 LLM 调用，两个并行。融合评分 final = alpha 乘以 embedding_score 加 (1 减 alpha) 乘以 tree_score。
通道一用 sentence-transformer 模型，bge-small 系列，大概 95MB，将用户消息和每个意图的描述编码为向量，cosine similarity 排序取 top-K。速度极快，关键词匹配好，但间接表达不行。
通道二受 VectifyAI 的 PageIndex 框架启发，将意图识别建模为 LLM 在层级树上的推理遍历。不是把 50 个意图平铺给 LLM，而是构建一棵按语义域分组的树。项目管理下面挂 check_task、create_task、task_analysis，经营分析下面挂 daily_report、profit_analysis、hot_selling。LLM 用 CoT 推理，先判断属于哪个域，再在域内精确匹配。语义推理强，但依赖 LLM 可用性和响应速度。
这棵意图树就是一个轻量的语义知识图谱：domain 是上层语义聚类，intent 是节点，tree_text 定义的不只是这个意图是什么，更关键的是它不是什么，通过描述与相邻意图的边界，给 LLM 提供了推理路径。这和传统的 flat list 分类有区别。
生产中最核心的一个 insight：一段描述不可能同时对 embedding 和 LLM 都最优。
一个意图需要配两段文本。
embed_text 面向 embedding，关键词密集，同义词丰富，喂给 embedding 模型用户实际会说的话：热销排行, 做得最多, 高频任务, 什么任务多, 爆款, 经常做。
tree_text 面向 LLM，描述性强，含消歧提示，告诉 LLM 这个意图是什么以及不是什么：用户想看任务完成排行，区分，查完成率走 daily_report，查成员效率走 staff_commission。
在 104 条标注 case 上做网格搜索找最优参数。alpha 最优值 0.10，embedding 权重极低，意图树推理主导。delta 最优值 0.10，Top1 和 Top2 差距阈值，低于此值判定为歧义。
alpha 为什么是 0.10？在我当前的数据集上 57 个意图，LLM 推理能 cover 大多数场景，embedding 更多是召回安全网的角色。但这个比例不是普适的，如果意图数量增长到 200 加，或者扩展到多行业、多语言场景，LLM 会逐渐力不从心，embedding 作为语义空间召回的主力价值会显现。alpha 应该随着系统规模动态调整，所以我把标定工具做成了开源库的一部分。
三态判决不做二选一的强制路由，承认不确定性。
CLEAR，Top1 领先明显，直接路由。
AMBIGUOUS，Top1 和 Top2 接近，执行 Top1，暗示 Top2，不烦用户追问，在结果末尾附一句如果想看某某也可以告诉我。
LOW，全部得分低，降级到闲聊或引导搜索。
单通道降级，LLM 挂了 embedding 仍然工作，embedding 出错 LLM 仍然能推理，两个都挂走 LOW。
融合和参数提取并行进行，不增加额外延迟。
生产环境的成本控制
这里需要专门说一下成本。
双通道融合建好之后，我很快意识到一个问题：ToB 场景里用户表达高度重复。帮张三建个项目、查一下这个迭代进度、哪些任务延期了，这类表达每天出现几十上百次，每次都走一遍 embedding 加 LLM 推理，纯属浪费。
加了三级缓存。
第一级，完全匹配缓存。用户输入跟历史请求完全一致，0 毫秒返回，命中率大概 15 到 20 个点。
第二级，embedding 近似缓存。用 cosine similarity 找最近的已解析请求，相似度 0.95 以上直接复用，命中率大概 30 到 35 个点。
第三级才是 LLM 推理。前两级都 miss 了才走 LLM，而且 LLM 返回的结果也会写回缓存。
加上这套缓存之后，实际走 LLM 的请求占比降到了不到 40%。
还有一个容易被忽略的点：域预筛选用的关键词匹配就是传统 NLP，正则、模式、高频词。问题分流那步的规则分类器也是。这些技术在整个链路里承担了前置过滤和快速路由的工作，高频表达走规则秒回，低频长尾才上 LLM。不是什么先搭好 LLM 舞台再挂传统 NLP 装饰，而是从一开始就是 waterfall 结构，便宜的规则和 embedding 先跑，不确定的才上贵的 LLM。
最终成绩与剩余问题
逐阶段演进，单模型基线 104 条准确率 80.8%；
双通道融合初版 104 条准确率 87.5%，加了 6.7 个点，意图树补上了任务型识别；
双通道融合加口语优化，扩展到 140 条准确率 97.1%，加了 9.6 个点，embed_text 覆盖口语加编排检测修复。
数据分析域变化最大，从单模型最差的 47% 干到了满分。
单模型轻量 47%，7 对 15；
单模型强力 87%，13 对 15；
双通道融合扩展集 100%，21 对 21。
140 条扩展回归中剩 4 条失败，全部是含指代词的短句：
那个任务排多久需要上下文才知道指什么，
把这个任务调个期需要上下文，
这个任务不做了先归档需要上下文，
那个需求评审了没需要上下文。
结论：剩余失败全部属于对话上下文层的职责范围，意图识别层本身已无系统性短板。
为什么这是一个通用结构
写完这个系统之后，我试着从更抽象的角度理解为什么双通道融合有效。
核心原因是：用户输入是不完整、不确定的信息。而不同方法的区别在于如何利用这些信息。
纯规则，信息利用率低但确定性高。
纯 embedding，利用表层语义但缺乏推理能力。
纯 LLM，推理能力强但稳定性差。
单一方法都是对输入信息的单视角解释，因此一定存在盲区。
而 Recall 加 Reasoning 加 Ranking 的结构，我理解成：
Recall 从不同视角尽可能保留信息，不遗漏可能性；
Reasoning 对候选进行语义推理，补全隐含信息；
Ranking 在多信号下做一致性决策，选择最优解释。
这个结构的关键不是具体实现，embedding 还是 BM25，LLM 还是规则引擎，而是通过多信号融合最大化信息利用率，同时控制不确定性。
所以它不只适用于意图识别，也适用于其他需要在不完整信息下选最优解释的场景。
RAG 文档选择，Recall 候选文档转 Reasoning 判断相关性转 Ranking 排序。
Agent 工具选择，Recall 可用工具转 Reasoning 判断可行性转 Ranking 决策。
推荐系统，Recall 候选集转 Reasoning 用户意图转 Ranking 精排。
沉淀的设计原则
最后把踩坑过程中最值得带走的几条总结一下。
- LLM 只做理解，代码做决策。让 LLM 告诉你用户消息涉及哪些意图，代码决定路由策略。不要让 LLM 同时做 NLU 加路由加编排判断。
- 不要把 LLM 的 confidence 当硬开关。LLM 置信度是不稳定的主观信号。用它做弱参考，5% 权重，不要用它做路由阈值。用结构化信号，必填参数覆盖率、动词匹配、参数模式，做主决策。
- 一段描述不可能同时对两个通道最优。embedding 需要关键词密集的同义词集合，LLM 需要描述性强且含消歧提示的自然语言。独立维护 embed_text 和 tree_text。
- 先判断问题类型，再挑具体意图。操作教学、经营策略、数据查询、执行动作，这些是不同类型的问题，不应该在同一条链路里竞争。
- 不要低估短句和口语的破坏力。用户不会按你的意图描述说话。调个期、人够不够、最近啥项目赶，这些口语化表达必须在 embed_text 中显式覆盖。
- 歧义和多意图是两件事。查一下这个任务是歧义，同实体多种查询方式，不是多意图如建项目加拉群。歧义选最优，多意图走编排。
- 很多识别错误不是识别层的错。可能是缺上下文，分析一下不知道分析谁；可能是缺对话状态管理，好的不知道是接受提议还是新话题。归因到意图识别之前，先检查上下游。
- 缓存不是锦上添花，是第一天就该设计的东西。ToB 场景里用户表达高度重复，完全匹配缓存的命中率比你想象的高。我后悔没在第一阶段就加上。
- 单一信号一定有盲区，多信号融合才是出路。embedding 和 LLM 各有擅长和不擅长的场景，没有一个能覆盖全部 case。与其追求单一方案的完美，不如让多个不完美的信号互相补位。
第七阶段：扔掉意图这个词
写完上面这些之后，我遇到了一条让我重新审视整个方案的评论。
原话是：意图是个过时的概念了，不要在 LLM 上用 BERT 时代的东西。
我当时回了一段关于阶段选择的解释，但那几天脑子里一直在转这件事。后来想明白了，他说得对。
我做的这套系统，从第一天起就叫意图识别，但实际上做的事情从头到尾都是工具路由。用户说帮张三建个项目，系统不是要把它分到取消任务这个类别里，而是要决定调哪个 API、传什么参数。这个区别不是咬文嚼字。
意图分类和工具路由，在 BERT 时代可以是同一件事，因为在那个范式下你能做的就是把文本映射到预定义标签。但在 LLM 时代，这两个是不同的问题。
所以我把整个系统重新审视了一遍，发现其实不需要改什么架构。
双通道融合里的 embedding 通道，原来召回的是意图候选，现在召回的是工具候选。
意图树推理通道，原来 LLM 在意图树上遍历，现在在工具树上遍历。
融合评分、三态判决、缓存、waterfall，全部复用。
变的只有一件事：定义方式。
原来定义意图：
IntentEntry(name="create_task",domain="项目管理",embed_text="建任务, 排期, 分配, 创建任务, 帮我建",tree_text="用户想给某个客户创建任务。区分：查任务→check_task；取消任务→cancel_task",)现在定义工具：
ToolEntry(name="create_task",description="给指定成员创建任务，需要成员信息和排期",parameters={"customer_name":{"type":"string","description":"客户名称"},"timeline":{"type":"string","description":"排期时间"},},embed_text="建任务, 排期, 分配, 创建任务, 帮我建",tree_text="用户想给某个客户创建任务。区分：查任务→check_task；取消任务→cancel_task",)多了参数 schema，LLM 不仅能选工具，还能直接填参数。参数提取那一步不用单独跑一次 LLM 了，工具选择的时候顺手把参数带出来。
这个改动的实际收益比想象的大。
第一，加新能力变简单了。原来加一个意图要纠结放哪个域、跟哪些意图语义冲突、embed_text 够不够全。现在加一个工具就是写一段描述加参数 schema，LLM 自己判断适用范围。
第二，长尾表达覆盖更好。原来总有口语化表达匹配不到对应意图，因为你怎么定义都定义不全。现在 LLM 看了工具描述，自己推理这个工具能不能处理这句话。不需要你预判所有说法。
第三，跨域问题自然解决。原来的架构里一个意图只能属于一个域，但现实中有很多跨域表达。比如帮我分析一下这个项目的进度然后给出建议，涉及项目查询、进度分析、任务推荐三个域三个工具。用工具路由的话 LLM 直接返回三个 tool_call，编排层串起来执行，不需要在意图层纠结分类。
关键洞察是：这六个阶段搭起来的架构，双通道融合、三态判决、缓存 waterfall、结构化校验，这些不是意图识别专用架构。它们是通用的选择加路由架构。把被选择的对象从意图换成工具，整个系统零改动就能跑。
所以我在 intent-fusion 里加了一个 ToolRouter 模式。用法几乎一样：
from intent_fusion import ToolRouter,ToolEntry tools=[ToolEntry(name="create_task",description="给指定成员创建任务",parameters={...},embed_text="建任务, 排期, 分配, 帮我建",tree_text="创建任务。区分：查任务→check_task；取消任务→cancel_task",),]router=ToolRouter(tools)result=await router.fuse("帮张三建个项目",your_llm)#result.selected_tool →"cancel_task"#result.parameters →{"order_id":"xxx"}回头看，这个演进路径其实是必然的。意图识别是 BERT 时代留下的思维惯性，先分类再执行。LLM 时代应该直接映射到执行。但搭建这套映射系统需要的工程能力，召回、推理、排序、缓存、降级，跟我前面六个阶段积累的东西完全重合。
所以如果你现在从零开始做类似的事，我建议直接上工具路由，跳过意图识别这一步。但如果你已经有一套意图识别系统在跑，迁移成本很低，把意图定义改成工具定义，加参数 schema，其他不动。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
 评测：复古外壳下的现代嵌入式系统逻辑)
