当前状态：尚未实测。本文基于公开资料、OpenAI 官方文档和作者后续实验做静态分析；我还没有在自己的具体项目中安装相关 Skill、创建题库或运行 Eval。
我为什么关注这套方法
我关注这篇文章，是因为它点中了 AI Coding 最容易制造的错觉：代码出来了、测试绿了、页面打开了，于是我们自然地说“完成了”。但如果被修改的是 Prompt、RAG、Agent 路由或工具调用，程序能跑和业务做对其实是两件事。
原帖作者把这句话说得很直接：Testing 解决“系统有没有坏”，Eval 解决“结果到底好不好”。我认为这个区分基本成立，而且不仅是个人经验。OpenAI 的官方评估指南也建议采用 eval-driven development，尽早、持续地在任务特定案例上评估，并用人工反馈校准自动评分。
这套流程到底改变了什么
作者原来的流程是
Build → Tests Passed → Done，后来改为 Baseline → Build → Test → Eval → Analyze → Fix → Re-Eval → Release。这里最关键的一步不是多跑一个工具，而是先写清楚“什么叫做好”。传统测试仍然负责确定性合同：API 是否返回成功、JSON 是否可解析、字段类型是否正确、工具参数是否合法。Eval 则负责业务结果：检索是否找对资料、回答是否有依据、分类是否符合业务规则、Agent 是否完成了用户真正的任务、关键错误是否会误导人。
我很认同先跑 Baseline。没有旧版本在同一题库、同一评分方式和同一配置下的成绩，修改后的“感觉更好”几乎没有证据价值。模型输出可能更长、更顺、更自信，却不一定更准确。Baseline 把讨论从印象变成了可比较的版本差异。
失败分类也比单一总分更有用。假设 22 个失败里 9 个来自 Retrieval、5 个来自 Tool Selection，最值得修的可能不是 Prompt，而是召回、查询改写、工具选择或空结果处理。只看总分会告诉我错了多少，Trace 和失败类型才会告诉我下一步应该改哪里。
作者还要求修改后完整重跑题库，并把 Improved、Regressed、Unchanged、New Failures 分开。这一点尤其重要。修好“查不到订单时不要编造”之后，Agent 可能在正常订单查询里变得过度谨慎；提高 Top-k 可能增加无关上下文，反而让生成结果变差。只重跑刚修好的题，最容易把局部成功误认为整体成功。
最后是 Release Gate。作者给出的 92% 总体通过率、98% 高风险通过率、2% 幻觉率等只是示例，不能照搬。真正有价值的是：门槛必须在运行前定义，而且高风险错误不能被平均分掩盖。一个版本从 79% 提升到 91%，可能明显变好，却仍然不够上线。
作者后续实验提供了什么证据
原帖发布时，文章中的数字都是示例，也没有公开
eval-engineering Skill、Runner 或 Golden Set。所以只看这篇，我只能判断方法合理，不能判断作者的实现有效。不过作者次日又发布了一个后续实验。他从真实 GEO 视频工作流中隔离出语义素材检索模块，建立 24 个 Case 和 24 个素材条目，用本地 BGE embedding 跑 Baseline。第一次 Top-1 通过 19 个，5 个失败都被归为 Retrieval。
作者没有换模型、没有改权重，也没有删题，只增加了一层确定性的 Query Rewrite。完整重跑后，22 个 Case 通过，3 个改善、0 个回归、0 个新失败。数据对比如下：
指标 | Baseline | V2 | 门禁结果 |
Overall Pass Rate | 79.17% | 91.67% | PASS |
High-Risk Pass Rate | 80% | 80% | FAIL |
Critical Failure | 1 | 1 | FAIL |
Regression Cases | — | 0 | PASS |
最终 Release Decision | — | — | FAIL |
这个实验很好地展示了方法如何工作：先基线，按错题找根因，只做最小修改，完整回归，最后让门禁而不是“看起来不错”决定是否结束。
但我不会把它写成通用成功案例。24 个 Case 太小，一条就是约 4.17 个百分点；普通 Case 的 Ground Truth 被作者标为
synthetic_unverified，高风险 Case 只是 human_review_required；仓库、数据集、命令和原始报告没有公开，我无法独立复算；被测的也只是离线 Top-1 检索模块，不是完整生产视频系统。作者自己也明确承认这些限制。把 Eval 装进 Codex，不等于装一个万能 Skill
作者把实现分成两层：全局
AGENTS.md 负责声明哪些改动必须进入 Eval Workflow，eval-engineering Skill 负责封装 Golden Set、Rubric、规则评分、LLM-as-a-Judge、Regression、RAG Eval、Trace Eval 和 Release Gate。这在机制上可行。OpenAI 官方文档确认 Codex 会读取全局和项目级
AGENTS.md，也会在任务匹配时加载包含 SKILL.md、脚本和参考资料的 Skill。但指令不是硬门禁。真正可靠的完成条件，必须落到一个可以运行、可以失败、可以进入 CI 的命令。否则 Codex 即使知道“应该 Eval”，也可能面对没有 Runner、案例路径错误、依赖缺失、数据过期、评分器漂移或报告不可复查的问题。
我更愿意先从项目级开始。在一个具体项目中写清楚：哪些文件变化会影响 AI 行为；Baseline 命令是什么；完整 Eval 命令是什么；门禁失败时不得声明完成。等这套流程在多个项目中稳定复用，再把真正通用的部分抽成 Skill。直接把一套过于宽泛的规则放进全局
AGENTS.md，可能让普通确定性修改也承担不必要的成本。Eval 自己也需要被评估
题库不是越大越好，而是要代表真实分布，覆盖典型、边缘、对抗、高风险和历史失败。更重要的是，不能让 Codex 一直看到全部题目再围绕同一套题优化。至少应该把案例拆成可用于分析的开发集、长期回归集、迭代过程中不可见的 holdout，以及单独的高风险集。否则分数上涨可能只是对题库过拟合。
Ground Truth 也不能完全交给 AI。模型可以帮助生成候选 Case 和边界条件，但进入正式门禁的答案需要人工或明确来源确认。高风险业务尤其如此。招聘、医疗、法律、金融和客户准入中的“正确”不是模型根据常识就能决定的。
LLM-as-a-Judge 同样不是裁判真理。它可能偏好更长的回答，受候选顺序和措辞影响，也可能随着评分模型版本变化。能用规则判定的字段、格式、引用存在性和工具参数，应优先用规则；开放式语义再用模型评分，并持续抽样与人工结论对照。高风险、争议和低置信度案例必须进入人工复核。
一次运行也不能证明稳定性。开放式生成至少需要固定模型快照和参数，并对关键案例重复运行；延迟应报告中位数、P95、运行次数和环境，成本应记录输入、输出 Token 与单价版本。作者在后续实验中也承认，单次延迟下降不能包装成性能提升。
它适合谁，又不适合谁
这套方法最适合已经有可运行 AI 功能、但团队仍靠“试几个问题感觉不错”验收的人。分类、检索排序、结构化提取、带来源问答、客服草稿和工具调用，都容易先从几十个高信号案例开始。它也适合模型、Prompt、知识库或路由即将变化，需要在合并前检查回归的团队。
如果产品行为还没有定义清楚、没有人能确认什么算对，Eval 不会替团队补出业务真相。对于一次性、低风险、结果可立即人工检查的任务，建立复杂平台可能得不偿失。对于高风险系统，离线 Eval 更不能替代灰度、监控、人工审批、事故响应和线上失败回流。
我的当前判断
这篇文章最值得带走的，不是某个 Skill 名称，也不是 92% 或 98% 这些示例阈值，而是一个更严格的 Definition of Done：代码能运行只是底线；代表性业务案例达到预先定义的标准、没有不可接受的回归，并留下可复查证据，才接近交付线。
我目前还没有在自己的项目里实测这套流程，所以不会把它写成“我的效率提升了多少”。下一步如果要验证，我会选择一个低风险、边界清楚的 AI 行为，先做项目级的最小 Eval：30–50 个脱敏或合成 Case，人工确认正式门禁所用的 Ground Truth，保留 holdout，跑 Baseline，只修一个主要失败来源，再完整跑 Test、Eval 和 Regression。整个过程先不安装全局 Skill、不调用付费 API、不碰生产数据。
如果这个小实验能稳定产生比主观验收更清楚的失败证据，再考虑把成熟流程封装成项目 Skill。对我来说，这才是对原帖最诚实的验证方式：不因为理念正确就宣布工具有效，也不因为一次分数上涨就宣布系统完成。