人资 Q&A 智能体：不是所有问题都值得走大模型

第一件事不是想功能，是给问题排序

我做的第一步是分层调研员工和 HR 的疑问，然后按 「高频刚需 > 流程复杂 > 补充疑问」排序，输出一份覆盖入转调离四大模块的《需求清单》。

这份清单的作用不是罗列需求，而是划定范围—— 它决定了智能体先做什么、什么不做、哪些问题根本不值得进这一期。先排序再设计，后面所有争议都有依据可以回到这张表上来。

智能体答得准不准，绝大部分取决于喂给它的内容准不准。我参与设计飞书 wiki 的标签体系，把它适配成 Dify 可以导入的结构，并制定内容同步机制——这一步很关键，因为制度一更新而知识库没同步，智能体就会开始一本正经地胡说。

这部分我同时输出了高保真原型和 PRD，并每周联动 HR 与开发对齐内容与排期。

我对智能体做单轮和多轮对话测试，然后逐条对照知识库去查：这个回答是有依据的，还是它自己编出来的。

测试做得越多我越确定一件事：让大模型去回答「入职材料交哪些」这种每天被问十遍、答案完全固定的问题，是浪费。于是我提出并落地了「猜你想问」建议问题模块和高频问题点击直达——常见问题直接命中确定答案，只有真正长尾的问题才交给模型。

这个改动同时省下 token、让响应更快，也减少了对 HR 的打扰。 需要说明的是：这里的提升幅度我当时只有定性判断，没有留下精确的量化记录，所以我不会给一个自己都验证不了的数字。

有一个差旅报销的问题，智能体答错了。我没有直接去改提示词，而是先查 Dify 的运行日志，确认知识检索这一步其实是命中的—— 也就是说问题不在「没找到」，而在模型拿到内容之后的输出环节。

这个区分很重要：检索没召回和检索召回但答错，是两类完全不同的问题，修法也不一样。如果不去看日志，很容易把两种情况混在一起，结果就是反复调提示词却不见效。

上面这些是我在实习期间实际落地的事。但「控制上下文」—— 也就是切分粒度、召回数量、多轮对话历史累积带来的干扰—— 是我事后复盘才想明白的，不是我在实习当时提出的方案。

我把这个区别写在这里，是因为面试时如果把复盘结论说成当时的决策，一追问细节就会露馅。这也是我后来做自己项目时，最先要解决的问题。

这个项目横跨人资行政组和开发组。我负责链接两边沟通，推动 HR 审核知识库内容的准确性，并在每周例会上同步内容与排期。

我会更早建立回归评测集。当时我是逐条人工比对来核查回答，问题在于每次改动都要重跑一遍，而人是记不住之前哪些 case 本来是好的——很容易修好一个、弄坏一个。

复盘之后我把这件事补进了自己的下一个项目：40 多条评测用例，每次改动全量回归。那个项目就在下面。