# 2026年7月更新:ChatGPT、Codex、Pro、Plus 背后的 Evaluation Engineering:AI 系统的质量,为什么不能靠“感觉不错“(GPT-5.6 工程化技术分享)
ChatGPT 生成了一段回答。
看起来通顺。
结构也完整。
措辞也专业。
然后呢?
大多数人判断 AI 输出的方式,停留在"感觉不错"。
这在日常聊天里可以接受。
但当 Codex 的代码要进仓库,当 Agent 的结论要进报告,当 Pro 级任务要支撑真实业务决策——"感觉不错"就不够用了。
没有评估体系的 AI 应用,是在裸奔
传统软件的质量,靠测试保障。
传统工程
├── 单元测试
├── 集成测试
├── 回归测试
└── 发布门禁
测试失败,代码就不能上线。这是底线。
但 AI 系统呢?
同一个问题,今天和明天的回答可能不同。
换了提示词,质量可能波动。
模型升级后,原本稳定的能力可能退化。
一个细微的上下文污染,可能让结论完全跑偏。
如果没有评估体系,这些问题全都不可见。
你以为系统一直很稳定。
其实只是你一直没测。
评估工程的第一步:把"好"拆成可检查的维度
"这个回答好"是一个模糊判断。
工程化的做法,是把好拆开:
Evaluation
├── correctness 事实是否正确
├── completeness 覆盖是否完整
├── consistency 多次生成是否一致
├── grounding 是否有依据支撑
├── boundary 是否越过任务边界
└── style 是否符合表达要求
不同任务,权重不同。
写代码,correctness 和 boundary 优先。
写总结,completeness 和 grounding 优先。
写文案,style 和 consistency 优先。
做决策分析,grounding 压倒一切。
维度定义清楚了,“感觉不错"才能变成"检查通过”。
评估集,比提示词更值得积累
很多团队精心维护提示词库。
但很少有团队维护评估集。
eval_dataset
├── case_001 典型输入 + 期望输出特征
├── case_002 边界输入 + 必须拒绝的行为
├── case_003 对抗输入 + 不能掉的坑
└── case_00N 历史事故回放
评估集是什么?
是把团队踩过的坑、客户投诉过的错、Review 时发现的问题,固化成可以反复运行的检查。
提示词决定 AI 这一次的输出。
评估集决定系统长期的质量走向。
提示词会过时。
评估集只会在使用中增值。
评估的频率,决定了质量的水位
偶尔抽查,只能发现灾难性问题。
持续评估,才能发现缓慢的退化。
ChatGPT 和 Codex 的工程化使用,应该有三个层次的评估:
生成时自检:模型输出前,先过一遍约束清单。
交付前验证:结果进入使用环节前,过评估集。
周期性回归:模型升级、提示词调整后,全量重跑。
质量不是一次达标。
质量是持续不退化。
未来:评估能力是一种核心竞争力
当生成变得廉价,评估就变得昂贵。
任何人都能让 AI 快速产出一百个方案。
但只有能分辨好坏、能证明好坏的人,才能把 AI 用进严肃场景。
ChatGPT 负责生成。
Codex 负责执行。
评估体系负责告诉系统:什么算对,什么算错,什么算退化。
模型决定输出的上限。
评估决定质量的下限。
未来优秀的开发者,不只是会让 AI 生成的人。
而是能为 AI 建立"质量标尺"的人。
生成是能力。
评估是纪律。
更多推荐


所有评论(0)