# 《指挥 AI,做出一个企业级 Agent》10:改一次 Prompt,怎么知道 Agent 有没有悄悄变差
**作者**: jager
**日期**: 2026-07-24T01:54:14.000Z
**来源**: [https://x.com/pangmadee/status/2080471587594420267](https://x.com/pangmadee/status/2080471587594420267)
---

昨天讲了:接通大模型只是开始,真正难的是不让它越权。今天继续:即使这一次模型没有越权,只要改一次 Prompt、换一个 Embedding 模型或更新知识库,很多团队还是只会重新问几条熟悉的问题——回答看起来还不错,就认为新版变好了。
但企业真正关心的问题是:原来正确的工单有没有悄悄答错?总通过率提高时,有没有一条高风险案例反而退步?错误引用、越权承诺或风险漏判,会不会被一个漂亮的平均分掩盖?两次结果不同,到底是 Prompt、模型、知识还是代码变了?
所以 D07 和 D08 没有从“把分数跑得更高”开始,而是先构造一组版本化固定案例:每次保存模型、Prompt、知识库和代码版本,逐条比较改善、退步和不变;再用审计回答每条业务结果究竟怎样产生。

发布前评测与运行后审计:两条不同但相连的质量闭环
## 固定评测不是再问模型一次
我们把 30 个案例版本化保存。每条案例都有明确的输入、允许来源、期望分类、风险等级、是否必须人工确认、禁止动作和通过条件。
案例同时包含正常业务和安全边界:
- 可以直接引用的售后政策;
- 容易引用旧版本的相似问题;
- 不允许承诺退款或已完成业务动作;
- 必须升级人工确认的高风险场景;
- 无可靠知识时必须拒绝;
- 模型或工具失败后的终态。

固定评测运行列表保存模型、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 的评测与审计要求:
```
不要用几条人工提问证明模型质量。
建立版本化固定案例集,为每条案例定义分类、允许来源、风险、人工确认、禁止动作和通过条件。每轮保存模型、Prompt、知识和代码版本。
比较两轮时必须展示 improved、regressed、unchanged 和执行错误,不能只展示总分。
错误引用、越权承诺、高风险漏判设置为一票否决。
同时建立不可修改的运行审计,让最终结果能追到身份、权限、知识、模型、人工终稿和确认记录。日志只返回白名单字段并完成脱敏。
最后说明:哪些审计失败必须回滚业务,哪些遥测失败可以降级但必须告警。
```
固定评测和审计完成后,我们能知道 Agent 有没有退步,也能追到每条业务结果的责任链。
但评分通过、日志完整,仍然不等于用户真的能顺畅地完成任务。正式交付前还有最后一道门:不听 AI 自己说“开发完成”,而是在 production build 下逐页走完真实业务闭环。
你每次改 Prompt 后,现在是靠几条演示问题判断,还是已经保留了固定案例?评论区回“演示”或“评测”。下一篇《不会前端,怎么验收 AI 做出来的网站》,我会把“感觉这个界面有问题”拆成 AI 能定位、修复和回归验证的验收语言。
《指挥 AI,做出一个企业级 Agent》系列:
第1篇:先定义一个能落地的企业 AI 项目
第2篇:AI 能写代码,为什么还要写 PRD?
第3篇:从 PRD 到七页面原型,别让 AI 随便生成网站
第4篇:不会 UI,也能完成一次有依据的设计选择
第5篇:Vibe Coding 之前,先做一次技术选型
第6篇:别让 AI 直接开工,先把第一版写成开发任务书
第7篇:让 AI 写代码前,先证明权限和数据不会出错
第8篇:企业 RAG 不是上传几个 PDF
第9篇:接通大模型只是开始,真正难的是不让它越权
## 相关链接
- [jager](https://x.com/pangmadee)
- [@pangmadee](https://x.com/pangmadee)
- [先定义一个能落地的企业 AI 项目](https://x.com/pangmadee/status/2078752938068152663)
- [AI 能写代码,为什么还要写 PRD?](https://x.com/pangmadee/status/2078758023112376665)
- [从 PRD 到七页面原型,别让 AI 随便生成网站](https://x.com/pangmadee/status/2078780817724281224)
- [不会 UI,也能完成一次有依据的设计选择](https://x.com/pangmadee/status/2078790167192883349)
- [Vibe Coding 之前,先做一次技术选型](https://x.com/pangmadee/status/2079012513728139675)
- [别让 AI 直接开工,先把第一版写成开发任务书](https://x.com/pangmadee/status/2079073999976579536)
- [让 AI 写代码前,先证明权限和数据不会出错](https://x.com/pangmadee/status/2079381070726979995)
- [企业 RAG 不是上传几个 PDF](https://x.com/pangmadee/status/2079740046169841799)
- [接通大模型只是开始,真正难的是不让它越权](https://x.com/pangmadee/status/2080109599022309565)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:54 AM · Jul 24, 2026](https://x.com/pangmadee/status/2080471587594420267)
- [66 Views](https://x.com/pangmadee/status/2080471587594420267/analytics)
---
*导出时间: 2026/7/24 11:35:22*