AI 工程 · 神机百见解读

把 Eval 装进 Codex 之后:Build 变便宜了,「完成」反而变贵

「AI Coding 越强,Eval 越重要」——这个反直觉主张被 OpenAI 官方多篇一手材料强验证。先说清楚一件事:原文本次没能取回全文,我们能核的是论点,不是细节案例。

本篇目录5 节 · 7 分钟
一分钟速览
  1. 先说核查缺口:这是一篇 X 长文(Article),正文本次未能取回——X 主站被封(HTTP=000),jina reader、xcancel、nitter 镜像均不可达,只有聚合页卡片给了标题、开篇与互动元数据。
  2. 已核实的部分:作者 @UPing123zzz(Ethan宇,蓝 V);发布 2026-08-29 00:14 北京时(雪花 ID 反推);9,974 浏览 / 95 赞 / 15 转。
  3. 核心论点:「AI Coding 越强,Eval 越重要。因为 Build 正在变便宜,但『什么叫完成』这件事,并没有变简单。」
  4. 论点有硬背书:OpenAI《Harness Engineering》明确写「随代码吞吐上升,瓶颈变成人类 QA 能力」;Codex Skill-Creator 已新增 Evals 功能。
  5. 物证在前一轮研究里:decode-codex 仓库最大的实现文件是 quality-gate.ts(约 135 KB),而它的测试文件(约 215 KB)比实现本身还大 1.5 倍。
  6. 对我们的判断:这套范式有 12–18 个月的持续内容价值;工程上把「质量门禁」做成内容流水线的标配,比多写一个生成 Skill 划算。
数据来源与边界
核查对象为 X 长文 /i/article/2093371727611105362(@UPing123zzz,X 显示名 Builder,蓝 V;WebSearch 显示本名 Ethan宇)。全文正文未能取回——X 主站直连被出口代理封禁,jina reader、xcancel、nitter 镜像三路均不可达,最终经 vanlett 聚合页文章卡片取得标题、开篇与互动元数据。因此本文只核验论点,不核验文内细节案例,具体工作流需阅读原文后补全。交叉验证来源:OpenAI《Harness Engineering》、OpenAI × Thrive《Building self-improving tax agents with Codex》(2026-05-27)、Codex Skill-Creator Evals 更新说明、《系统测试 Agent Skills:OpenAI 的 Eval 工程方法论》。核查日期 2026-08-29。
1先把缺口摆出来

这篇的正文,我们没取到

先讲一件不太体面但必须讲的事:这篇文章的正文,本次核查没能取回。

它是 X 长文(Article),不是普通短推。普通短推能通过 oEmbed 或 syndication 接口取到正文,长文不行——这正是那些接口返回空的原因。

四条路,三条断了2026-08-29 实测
X 主站
HTTP=000,出口代理封禁
jina reader
不可达
镜像站
xcancel / nitter 均不可达
聚合卡片
取得标题、开篇、互动元数据通,但只有这些

能确认的是这些:作者 @UPing123zzz,X 显示名 Builder,蓝 V 认证;WebSearch 显示本名 Ethan宇,AI Coding / 个人成长方向创作者。发布时间 2026-08-29 00:14 北京时(雪花 ID 反推)。互动数据 9,974 浏览 / 95 赞 / 15 转 / 2 评论。他还有一篇同主题的姊妹篇,1,658 浏览——在做系列。

开篇原文是这样的:「AI Coding 越强,Eval 越重要。听起来有点反直觉……因为 Build 正在变便宜,但『什么叫完成』这件事,并没有变简单。」

判断:缺口归缺口,这篇仍然值得写——因为它的论点可以被独立验证,而论点才是可迁移的部分。方法论文章里值钱的从来不是「他具体怎么配的」(那部分会过时),而是「他主张什么、这个主张站不站得住」。当然,文内的细节案例与具体工作流,仍需读到原文后才能补全。
2交叉验证

这个主张不是个人玄学

「Build 变便宜,定义完成变贵」听起来像博主金句,但它有四条互相独立的一手背书。

论点 × 一手权威源核查截至 2026-08-29
长文论点一手 / 权威来源验证
Build 变便宜,QA 与「定义完成」成瓶颈OpenAI《Harness Engineering》:随代码吞吐上升,瓶颈变成「人类 QA 能力」;明确写道「修正成本低,而等待成本高」强验证
Agent 自驱动迭代闭环OpenAI × Thrive(2026-05-27):practitioner's correction → production trace → tailored evals → Codex 驱动迭代,Agent 收 eval 目标、查根因、提修复、跑验证、交 PR强验证
Skill 需要可验证评测Codex Skill-Creator 新增 Evals:类似单测,定义「测试提示词 + 好结果标准」,捕捉质量衰退,并判断某技能是否已被基础模型吸收、可以退役强验证
大文件测试 > 实现decode-codex 仓库:quality-gate.ts 约 135 KB,测试约 215 KB直接物证
四条来源互相独立,其中三条是 OpenAI 官方工程材料——这说明它是主流范式转移,不是个别博主的观点

第三条里藏着一个很少被提到的用法:Eval 不只用来判断「做没做好」,还能判断这个技能是不是已经没必要存在了。基础模型每次升级都会吞掉一批曾经的「技巧」,没有 Eval 你不知道哪些已经可以删掉,Skill 库只会越堆越重。

3闭环

三轮研究撞的是同一堵墙

把最近三轮连起来看,会看到一条完整的「Agent 自我验证」认知链——每一轮都从不同角度撞上同一件事。

四次不同角度,同一堵墙研究序列
公众号排版 Skill 自带校验脚本
什么叫做完
自进化协议的四件套
什么叫改对
反混淆仓库最大的文件是门禁
判定 > 生成
本轮:Eval 驱动 AI Coding
定义完成变贵
条形为示意,不表示量化指标——四者指向同一件事:当 Agent 能把活「干完」,稀缺能力变成「定义什么叫干好 + 自动验证干没干好」
判断:三轮研究的分工很清晰:排版校验脚本是这范式的最小雏形(一道门禁),自进化协议是制度雏形(把改进写成流程),而这篇长文补上的是叙事框架——「为什么必须这么做」。技术、制度、叙事三样齐了,一个方法才算真正立得住。
4装了之后变了什么

三层 Eval:把「感觉更好」变成「证明更好」

Eval 不是一个开关,是分层的一整套。OpenAI 的 Eval 工程方法论把它拆成三层,从硬到软。

三层 Eval 架构从确定性到主观性
第一层
确定性检查能不能跑、格式对不对、字段齐不齐——不通过就是不合格,没有讨论余地
第二层
rubric-based grading按评分标准打分,处理「好到什么程度」这类无法用布尔值回答的问题
第三层
行为事件捕获用结构化输出记录 Agent 选了什么工具、走了哪条路径——不只看结果,看过程
真正的变化在第三层:把「感觉更好」变成「证明更好」

这套分层搬到内容流水线上,直接可用的有三个维度。

可读性 Eval——段落长度、标题层级、有没有被平台吞掉的样式。这一层是确定性的,脚本就能判。

事实一致性 Eval——文中的数字、引用、日期是否与源材料一致。这是防幻觉最实用的一道闸,也是我们的稿件里最不能出错的地方:一篇稿子写得再好,数字错了就全废。

品牌一致性 Eval——署名、简介、口吻是否统一。这一层注定要靠 rubric,因为是主观判断,但标准写下来之后,判断质量会比「凭感觉」稳定得多。

5判断与边界

这个范式值多少,以及它的保质期

加 Eval 门禁后的内容流水线我们的场景
选题
真实素材 / 一手信源人-only,AI 不碰
成稿
写作 Skill 出稿AI 辅助
排版
排版 Skill + 样式校验AI 辅助
门禁
可读性 + 事实一致性 + 品牌一致性不通过打回重写
回流
数据与教训回写 Skill 与 Eval 标准让下一轮自动受益

范式判断:长期有效,不是风口噪音。OpenAI 在 2026 年密集发文亲自定义 Harness Engineering 与 Eval Loop,说明这是主流工程范式转移。对我们这种靠专家型 IP 变现的,这意味着这套叙事有至少 12–18 个月的持续内容价值,且每个论点都能引用权威背书。

更实际的一条:这套范式可以直接平移成我们的选题。「当 AI 能把活干完,机器人『干得好』谁来判定」——把 Eval 门禁类比到机器人抓取与导航的成功标准,这是别人写不了、只有做过交付的人写得出来的题目。

这份核查的边界
全文正文未能取回,本文分析基于「标题 + 开篇 + 一手权威交叉源」,不覆盖文内细节案例与具体工作流配置——需阅读原文后补全。这一点不构成判断风险(核心论点已被 OpenAI 官方材料独立证实),但读者引用文内细节时请回到原文。

作者为蓝 V 个人创作者,非 OpenAI 官方;长文非开源、无 LICENSE,不可当代码或技能搬运,引用需署名,转载需授权。另:该范式仍在快速演进(OpenAI 2026 年密集发文),文中引用的官方材料需持续跟踪更新。