最近，我把一份正在开发的需求文档，做成了一个需求答疑 Agent。
想让它代替我回答研发在开发过程中遇到的一部分问题。
许多问题其实在需求文档里已经说明，只是找起来需要花费一定的时间，最快的方法反而是直接对产品敲一句“在么”。
既然问我，我也是翻需求文档，那为何不让需求文档直接替我回答这些？
我使用了公司现成的智能体平台进行搭建，里面已经包含模型、知识库、应用配置、发布入口等功能。
类似的智能体平台还有阿里云百炼、百度千帆、腾讯云智能体开发平台，以及 Dify、FastGPT、Microsoft Copilot Studio。具体功能和接入方式各有差别，但思路是相同的：把资料喂给模型，配好流程，发布成一个能干活的应用。
所需的内容很简单：一个对话型 Agent，一个知识库，一份当前正式需求文档 Markdown 文件。
首先在知识库里上传 Markdown 文件，然后按照标题切分，保留标题和文件信息，检索采用混合检索和重排。可以单独做知识库的检索测试，看看能不能找到对应的内容，再进行下一步。
接着是提示词部分。
如果只写“你是一个需求答疑助手，请根据文档回答问题”，能说明任务，却没有说清楚回答时具体要做什么。所以我把提示词分成了角色、目标、知识依据、回答流程、输出格式、回答要求和范围限制几部分。
角色里写明服务对象：正在开发、测试和维护这个需求的项目成员。回答范围包括业务规则、计算口径、数据来源、功能逻辑、页面行为和数据处理规则。并且要求只能够根据当前正式需求文档的内容回答问题。
然后规定了，收到用户问题后的处理流程：
收到问题后：
- 先判断问题是否属于“某内部业务需求”范围。
- 查询知识库，寻找能够直接回答该问题的需求依据。
- 判断检索内容是否真正规定了用户所问事项，而不仅仅是主题相关。
- 根据证据情况分别处理。
再加上几条具体的要求，例如：能用一句话回答的问题，不要扩写成长篇说明；不要重复大段需求原文；不确定章节名称时，可以写文档名称和对应规则，不要编一个章节编号；用户带着自己的判断来问，也要在文档里进行核对。
这些要求都和使用场景有关。研发问完后，往往要继续写代码或补测试用例。他需要尽快知道结论、适用条件，以及在需求文档的哪里核对。
最后把输出格式固定下来，只使用三个状态：
【已确认】
直接回答结论，必要时说明适用条件。
依据：文档名称，以及对应章节或规则。
【当前需求未明确】
说明目前能够确认到什么程度。
有相关规则但不足以回答时，说明缺少哪部分依据。
需要时提示由产品进一步确认。
【存在冲突】
分别说明相关规则及冲突点。
需要产品确认最终口径。这样用户一眼就能看到结论。
不过，把需求文档做成 Agent，并不会自动把需求补充完善。这个答疑助手的职责是依据文档已有的内容回答问题，规则、边界是否写得清楚，仍然取决于需求文档本身。
如果需求文档本身就是千疮百孔，研发问一圈下来，只会收获一连串冷冰冰的“文档未提及，请找产品确认”。
除了提示词，我还增加了几项使用方面的设置。
首先是开场白。用户打开一个空白聊天窗口，不一定知道它能回答到什么程度。我在开场白里说明它负责哪份需求、可以问哪些问题、以什么作为依据：
你好，我是某内部业务需求答疑助手。
你可以向我询问某内部业务需求中的业务规则、计算口径、数据来源和功能逻辑。我的回答以当前正式需求文档为依据；文档未明确的内容，我会明确提示需要产品确认。
然后设置了三个开场问题，用户一看就知道：哦，原来可以这样问。
还有反馈标签，可以根据研发使用中反馈的问题调整需求文档、知识库和提示词。
另外关闭了文件上传。
如果用户在对话里再传一份旧需求或自己的解释材料，就可能把另一套口径带进当前上下文。
后面需求文档更新了也不用改 Agent 的设置，只要把知识库里对应的文件换掉、重新解析一遍，它就能按照新版需求文档进行回答。
模型配置这块，我也没把什么都拉满。
推理等级我选择 Medium，实测 Medium 足以，Temperature 影响生成的随机性设置为 0.2，Top P 通过核采样控制候选范围设置为 0.9，其他 Agent 平台也会有类似的选项和可调节参数。
与此同时，我开启了思考过程展示。
这个设置考虑的是用户等待时的体验。问题发出去，模型可能需要一些时间处理。窗口半天没动静，用户分不清它是在想还是卡死了，我用 TraeWork 就遇到过这个问题。展示处理中的内容，至少能让用户知道它还在工作。
配置就绪，我拉来 DeepSeek-V4-Flash 和 Qwen-3.8-Max，做了一轮控制变量的对照测试。两边推理等级都是 Medium，Temperature、Top P 等参数完全相同，知识库、Prompt、检索配置、测试题也保持一致——只换模型，其他一概不变。
出题也有讲究：有文档里白纸黑字写明的规则，也有换个说法来问的，有要结合好几个章节才能答的，也有文档压根没规定的。除了看结论对不对，还得看它有没有按约定格式回答、依据是否准确、解释是不是过于啰嗦。
我一共测了十几个问题，Agent 在这轮测试中全部答对了。
对比下来，Qwen-3.8-Max 的回答要更完整一些，在格式和边界说明上表现也更好。但是 DeepSeek-V4-Flash 配合中等推理等级，在这个场景上已经足够用了。
拿其中一道题来说，DeepSeek 约用了 8.2 秒、2870 Tokens，Qwen 约用了 17 秒、5827 Tokens，他们的回答都能够满足使用要求，也有的问题他们用时差不多。
选择哪个模型可以根据回答表现和等待时间、Token 费用综合考虑。
这次实验让我觉得，需求文档确实可以做成一个 Agent 的形式，写清回答流程和输出要求，把开场引导、反馈和输入范围配置好，再用真实问题进行测试，可以很好地承担需求答疑的工作。
大部分研发提出的问题他都能回答，并且远比我回答得详细和快速。
如果你对这个做法感兴趣，不妨也做一个类似根据文档知识解答问题的 Agent 试试。