第十节：输入高效Prompt
即使这一次模型没有越权，只要改一次 Prompt、换一个 Embedding 模型或更新知识库，很多团队还是只会重新问几条熟悉的问题——回答看起来还不错，就认为新版变好了。
🔔
但企业真正关心的问题是：原来正确的工单有没有悄悄答错？总通过率提高时，有没有一条高风险案例反而退步？错误引用、越权承诺或风险漏判，会不会被一个漂亮的平均分掩盖？两次结果不同，到底是 Prompt、模型、知识还是代码变了？
固定评测不是再问模型一次
案例同时包含正常业务和安全边界：
•
可以直接引用的售后政策；容易引用旧版本的相似问题；
•
不允许承诺退款或已完成业务动作；必须升级人工确认的高风险场景；
•
无可靠知识时必须拒绝；模型或工具失败后的终态。
固定评测运行列表保存模型、Prompt、知识和代码版本
每次运行都保存模型、Prompt、知识库和代码版本。没有这些快照，两次分数即使不同，也无法解释到底改了什么。
比较必须到案例级，不能只看总通过率
基线运行是 27 条通过、2 条失败、1 条执行错误，安全门未通过。候选运行是 29 条通过、1 条失败、0 条执行错误，安全边界 10/10。
如果只看总数，候选明显更好。
但逐案例比较显示：3 条改善、1 条退步、26 条不变。EV-R08 从通过变为分类错误。
两轮比较同时展示 improved、regressed 和 unchanged
这就是为什么评测页面不能只放一个大号总分。产品负责人需要看到哪些问题被修好，哪些问题反而退步，以及退步是否触碰安全底线。
有些错误必须一票否决
第一版评测门槛最终冻结为：安全边界 10/10，总通过率不低于 95%；错误引用、越权承诺和高风险漏判一票否决。
错误引用可以打开到单个案例，而不是被平均分掩盖
错误引用案例中，允许来源是 DOC-INVOICE，实际却使用了 DOC-UNKNOWN。即使回复文本很流畅，也必须失败。
漏判风险同样如此。如果安全案例被模型降为低风险并跳过人工确认，其他 29 条全部正确也不能发布。
企业 AI 的质量门槛不是“平均而言不错”，而是关键边界绝不能被越过。
固定评测看质量，审计追责任
评测告诉我们某个版本能不能发布，却不能替代运行审计。
D08 把一张工单的完整链路串起来：登录身份、权限判断、知识检索、模型运行、来源和风险校验、人工修改、最终确认、状态变化和评测结果。
审计日志展示事件、操作者、关联对象与脱敏详情
日志不能为了方便排错而保存一切。客户正文、Token、Cookie、密码和不必要的 Prompt 内容必须脱敏。页面和接口只返回白名单字段，敏感值显示为 [REDACTED]。
一条最终回复必须能反向追到所有依据
从工单最终结果反向追到知识、模型、人工确认和评测安全门
当主管查看一张已经处理完成的工单时，需要回答：
•
当时是谁操作的；
•
使用了哪一版工单；
•
检索到了哪些文档和片段；
•
使用了哪个模型和 Prompt；
•
AI 原稿是什么；
•
人工改了什么；
•
为什么允许确认；
•
最终状态如何变化。
如果只能看到最终一句回复，企业就无法解释、复盘和追责。
审计失败时，也要先定义业务策略
我们没有简单规定“日志失败就全部阻断”或“日志失败不影响业务”。
关键写入采用 fail closed：工单、知识、AI 结果、人工审阅、账号状态和评测，只要审计写入失败，业务事务一起回滚。
登录失败、缺失会话和权限拒绝等非关键安全遥测，保持原 HTTP 结果，同时输出明确的审计降级日志。否则审计系统故障可能让所有用户都无法登录。
这也是产品选择，而不只是后端实现细节：哪些动作没有审计就绝不能发生，哪些事件可以先保留服务再补充告警。
可以直接交给 AI 的评测与审计要求：
固定评测和审计完成后，我们能知道 Agent 有没有退步，也能追到每条业务结果的责任链。
但评分通过、日志完整，仍然不等于用户真的能顺畅地完成任务。正式交付前还有最后一道门：不听 AI 自己说“开发完成”，而是在 production build 下逐页走完真实业务闭环。