给已有产品加一个聊天入口，用户马上就会问：“这个参数为什么不能选？”通用模型很容易解释参数的概念，却未必知道页面处于只读状态，也未必知道用户用的是哪个版本。
我想做的产品助手，要能把说明书里的规则和眼前的状态对上。它答不出来时，能说出缺什么；需要操作时，能给出明确提议，而不把一段建议写成已经完成的结果。
同一个入口接住不同问题
“导出在哪”需要定位入口；“为什么不能导出”需要读状态与规则；“帮我导出”已经要求执行。都走文档检索，再拼一段答案，只有第一类可能勉强够用。
我会从团队常被问的问题里选一批，标记需要的资料、状态和动作。分类不必依赖复杂模型，频繁出现的情况可以用明确规则处理。入口查找、功能解释、状态诊断和操作请求，各自有不同的完成条件。
产品知识和运行状态不混成一个库
资料保存适用版本、功能、更新时间和原文位置。状态由只读接口提供，例如当前页面模式、组件绑定、角色允许的动作。说明书告诉我有哪些限制，当前状态告诉我哪条限制在这里发生。
把动态状态也写进知识文档，很快就会过期；把整份页面配置扔进提示词，也不等于找到了决定问题的条件。上下文按问题选择，只读取当前用户有权访问且解释所需的字段。
例如导出不可用，页面给出资源引用和 revision，只读接口返回只读模式与导出策略。检索取回对应版本的规则，回答便能说明是模式限制还是角色限制，并给出可申请的入口。为了确认原因而直接试着调用导出，不是合适的诊断方式。
回答应能被逐项核对
应用内部记录问题类型、已读取事实、采用的规则版本、回答状态和动作提议。用户不用看这份内部记录，研发却能据此分清：状态读错了、资料找错了，还是证据正确但解释错误。
资料缺版本就询问版本；状态接口失败，只解释通用规则，不断言当前原因。规则相互冲突时保留冲突信息，不能让模型按语言流畅程度挑一个答案。
引用在助手内部仍有用途，用来回到证据原文核对；这不意味着回答要塞满资料，更不意味着证据存在就自动正确。关键判断是否被原文支持，需要针对题集检查。
建议与执行采用不同回执
解释告诉用户能怎么做，提议说明将修改哪个对象、哪些字段、有什么影响。用户确认后，执行侧按当前身份校验参数与权限，通过原产品接口处理。返回成功以后，还要读取真实状态，判断变化是否已经生效。
若其中一项失败，区分未执行、部分完成与结果未知。不能用“已为你调整”盖住一次接口超时，也不能因助手知道按钮位置就默认获得修改权限。
第一版怎样交付
范围可以从十几类高频问题开始，每类配正常、缺状态、版本冲突和无权限样例。查入口要能定位，解释状态要覆盖前提，要求操作要落到明确回执。资料不足的题，也要检查它是否真的停下来询问。
每轮失败保存输入事实、证据版本、输出与实际状态。这样一次修正可以回到明确环节，而不是在提示词末尾继续叠“请准确回答”。助手能稳定解释这批问题，也能清楚拒答范围，才有依据扩展更多功能。