口径对账是前提
用已确认的报表与模型结果逐项对账，差异要能解释到具体规则。对不上账就不是精度问题，而是口径问题，必须先修语义层再谈其他指标，否则越调越乱，团队也会失去方向。先修口径再谈精度，否则越调越乱。
可复现才可信任
同一问题在不同时间、不同人提问应得到一致结果，差异要在可解释范围内。结果随提示词措辞大幅变化，说明系统还没到可上线状态，先补语义层比继续调提示词有效。措辞一变答案就变，说明底子还没打好。
用问题集做回归
建一组有标准答案的问题，覆盖常用指标、边界条件与易错口径，每次改模型、改提示词或换数据源都跑一遍。问题集由业务方出题，技术方只负责执行与记录，避免只测技术指标而漏掉真实争议。
权限与留痕一起验
越权提问是否被拦截、查询是否留日志、导出是否受控，这些属于验收项而非附加项。事故往往不是算错，而是数据被不该看的人看到，追责时也难以还原路径，补记录已来不及。权限问题看得太多。这一点在岗位说明书与流程文件里都要写清，避免执行时走样。
适用与不适用
适合谁
- 准备把分析问答开放给业务部门的企业
- 已有多套报表、需要验证口径一致性的团队
- 与服务方约定交付标准的项目负责人
不适合谁
- 尚无确认版报表、口径仍在变动中的企业
- 只做一次性专项分析、不需要长期系统的团队
典型场景
某集团在开放分析问答前，由财务与销售各出十道有标准答案的问题组成回归集。首轮运行发现三个指标口径不一致，修正语义层后重跑。上线后每次模型升级都先跑这套题，未通过不发布，业务方逐渐建立信任。未通过不进入试运行。
可执行步骤
- 用财务或业务确认过的报表建立对账基准，逐项记录差异与解释
- 由业务方出题，覆盖常用指标、边界条件与历史争议口径
- 约定结果容差与复现方式，避免同一问题在不同人手里有多个答案
- 验收越权拦截与查询留痕，并做一次导出审批演练确认权限生效
常见坑
- 只测技术指标：响应快、格式对，但数字与财报不一致，业务方不会用，系统很快闲置。
- 问题集由技术方单独出：覆盖不到真实口径争议，回归通过仍会在会上出错，返工更难看。
- 验收后不做回归：模型升级后口径漂移，问题在季度会上才被发现，补救成本很高。
自检与验收清单
- 是否有确认版报表作为对账基准，并保留差异记录
- 问题集是否覆盖边界条件与历史上的口径争议
- 是否约定结果容差与复现方式，并写入确认单
- 越权拦截与导出审批是否纳入验收清单，有演练记录
常见问题
问题集谁来做？
业务方出题与标准答案，技术方负责执行与记录。只由一方完成会漏掉真实争议点，尤其是跨部门口径不一致的指标，评审时要让两边都在场，否则各说各话。
对不上账怎么办？
先定位是取数范围、时间口径还是计算规则差异，逐条修正语义层。把差异当成模型精度问题去调参，通常越调越乱，还会延长上线时间，团队信心也受影响。
验收后模型升级要重验吗？
要，至少跑一遍回归集。升级可能改变措辞与推理路径，历史问题会重现；把回归写进变更流程，比事后救火便宜，也能让业务方放心继续使用。