产品方案：从用户问题到可验收的功能
把用户研究、AI 适用性、需求文档与产品指标接起来，完整拆解一个知识查询功能。
01先还原任务，而不是先选择模型
以员工查询报销制度为教学案例。表面的需求是“做一个能回答问题的机器人”，实际任务可能是“在提交申请前，确认这笔费用能否报销，以及需要什么材料”。两种表述决定了不同的功能范围：前者容易停在聊天界面，后者需要处理适用地区、费用类型、制度版本和后续办理入口。
理解需求时，先了解用户最近一次怎样完成任务：在哪里找资料，遇到了哪一步障碍，最终如何解决。访谈可以获得用户的理解、动机和经历，但不能仅凭“我会使用”推断真实使用行为。让用户操作现有流程或原型，可以进一步观察找不到入口、误解提示或不信任答案的具体位置。
02需求记录需要保留条件
“资料不好找”还不够具体。更可用的描述是：“异地出差员工不知道应查总部制度还是当地补充规定，搜索结果没有展示适用地区，因此需要询问财务。”这段描述同时包含用户、场景、现有行为与障碍，才能推导出地区提示、资料标签或条件确认等方案。
访谈问题应尽量避免预设答案。比起问“你是不是需要一个 AI 助手”，询问“上次遇到这个问题时，你先做了什么”更容易得到具体经历。整理时把观察到的事实、用户自己的解释、产品团队的推测分别记录。少量访谈可以发现问题类型，但不能据此计算全部员工的需求比例。
03什么时候需要 AI，什么时候需要规则
自然语言表达多样、需要理解长文或组合资料时，语言模型可能有帮助。明确的身份校验、金额计算、制度适用条件，则通常需要可靠的数据和业务规则。产品设计可以把两者组合：模型帮助理解问题和组织说明，业务系统提供实际可报销金额与申请状态。
下图把模型输出与最终决策分成两层。A、B、C 表示不同模型输出，X、Y、Z 表示应用采取的决策。对知识客服而言，模型识别出“报销咨询”后，应用仍需判断是否缺少地区信息、是否允许展示资料、是否需要进一步询问。
04把功能写到可以讨论与验收
一份需求说明至少应让协作者知道输入、处理规则、结果和异常情况。只有“接入大模型，提高问答准确率”，开发无法确定要实现什么，测试也无法判断是否完成。可以先针对一个明确场景写出规则，再讨论它是否适用于其他问题。
| 环节 | 知识客服示例 |
|---|---|
| 输入 | 员工问题、可用身份信息、地区与查询时间 |
| 信息不足 | 问题缺少适用地区时，先询问或明确答案的适用范围 |
| 回答 | 给出结论、条件、制度出处和下一步办理入口 |
| 资料冲突 | 展示差异并提交业务复核，不自行拼出一个新规则 |
| 权限 | 仅检索并展示该员工有权查看的资料 |
| 验收 | 用有依据、无依据、资料冲突等样本分别检查结果 |
05产品结果与模型分数怎样连接
模型答对一道测试题，是系统质量的一部分；员工能否完成任务，是另一层结果。如果答案正确但入口难找、等待太久，产品仍可能不好用。可以分别观察任务解决情况、引用正确性、等待时间以及人工接入是否顺畅，不必强行把所有目标合成一个分数。
回答“为什么这样设计”时，可以按具体问题、观察依据、备选方案、取舍和验证方式展开。例如选用检索问答，是因为制度经常更新且需要展示出处；是否真正改善办事体验，还需通过实际任务测试和上线后的行为观察判断。这里的方案是教学案例，并不是某家公司已经取得的业务结果。