683 次运行、62.6 亿 token、20 次纠正
6 篇系列的第 1 篇:我用 Codex 和 Claude Code 重建 williamliu.ai,共用了 683 次智能体运行、62.6 亿 token、20 次人工纠正,以及代价最高的 5 次绕路。
《用智能体重建 williamliu.ai》6 篇系列的第 1 篇。面向读者的新网站导览在这里。
要点
- 🧮 15 天,683 次智能体运行,62.6 亿 token(Codex 45.9 亿,Claude Code 16.6 亿),我发了 162 条消息。
- 🔁 其中 97% 是再次读取的缓存上下文;智能体总共写出了约 1,900 万 token。
- 🛡️ 超过一半的 Codex 运行专门用于审查(630 次中有 347 次),但只使用了 Codex token 的 17%。
- 🧑⚖️ 按我的分类,我纠正了智能体 20 次:5 次针对产品或网站外观,15 次针对工作方式。
- 💵 按 API 公开价格折算,这些 token 共计 $3,691(Codex $2,473,Claude Code $1,218);两者我都使用订阅。
- 💥 改版在准备就绪之前一直没有进入生产环境,但一次预发布错误仍让生产数据库约 2 小时无法写入。
我在 Claude Design 中重新设计网站,再让 AI 编码智能体负责构建;这些数字清楚说明了智能体擅长什么,又在哪里仍然需要人。 网站已经上线,采用新的编辑式设计,每个页面都有中文版,比过去多出 139 个页面。整个过程用了两套智能体栈,历时 15 天(9 月 2 日至 16 日),审查运行多于构建运行。这组文章是我的项目账本:下文每个数字都来自我机器上的会话日志,并在发布前由另一个智能体对照日志核验。
本文是总览。后续 5 篇分别深挖一个主题,而不是按天记流水账。

🧮 核心数据一览
一个小型个人网站用了 683 次智能体运行和 62.6 亿 token,其中几乎全是智能体重新读取已经见过的上下文。 下面逐一解释这些数字。
- 683 次智能体运行。 一次运行,是一个拥有独立上下文的智能体会话:它可能负责构建、审查,也可能是自动安全检查。Codex 占 630 次,Claude Code 占 53 次。
- 62.6 亿 token,97% 来自缓存。 智能体每执行一步,都会重新发送整段对话。提供商会以大幅折扣从缓存中提供大部分内容。整个项目中,智能体写了约 1,900 万 token,重读约 60.7 亿,写出 1 个 token 对应约 318 个读取 token。有 2 次短暂的 Codex 运行完全没有记录用量,所以本文所有总数都是下限。
- 按 token 计算,Codex 完成了近四分之三的工作:45.9 亿,Claude Code 为 16.6 亿。 Codex 负责构建和大部分实现;Claude Code 编排第二阶段,并完成大部分部署和上线工作。
- 按 API 公开价格折算为 $3,691:Codex $2,473,Claude Code $1,218。 这是按 OpenAI 和 Anthropic 公布的 API 费率计算的金额,其中缓存 token 采用折扣费率。两种工具我都使用订阅,因此应把它看作价格比较,而不是我实际支付的账单。
- 我发了 162 条消息,其中 20 条按我的分类属于纠正。 其余是新请求、问题、批准,以及另外 3 条消息。
- 93 次提交、226 个文件、新增约 56,000 行。 9 月 16 日上线时,网站已从 135 个页面增至 274 个,其中 137 个是中文页面。
这些数字覆盖整个项目,包括改版引发的部署修复。只计算改版本身,则是 441 次运行、43.2 亿 token,按 API 价格折算为 $2,303。第 6 篇会按阶段、角色和绕路逐项拆解 token 去向。
🔀 两个阶段,两套智能体栈
Codex 用 5 天完成改版构建;随后 Claude Code 指挥 Codex 逐项修复,完成部署并让网站对齐设计。 工作清楚地分成两个阶段。

第一阶段,我给 Codex 目标模式(goal mode)设置了一个长期目标:实现设计、保护生产环境、并行使用子智能体,并持续审查每项变更,直到不存在严重问题。根智能体规划了 16 个编号里程碑;算上它自己,随后 5 天共运行 333 个智能体,同一时间有多个智能体分别在自己的 git 工作树(worktree)中工作。规则是:每项变更必须先通过发现者(Finder)、质疑者(Adversary)和裁决者(Referee)的审查才能提交;少数例外也必须如实记录。9 月 7 日,最后一个里程碑完成提交。
随后工作停滞了。预发布部署连续失败 6 次,原因有 4 种。我让 Codex 把已经发现的全部信息交给 Claude Code,由后者接手部署。第二阶段,Claude Code 修复了部署路径,把改版放到一个预发布 URL 上,对照设计做审查,并完成 12 轮修复。修复由 Codex 运行实现,Claude Code 也亲自做了一些小修正;每项修复都由 Claude Code 审查、截图并运行完整测试关卡。第 3 篇会比较这两种工作方式。
🛡️ 多数智能体都在做审查
超过一半的 Codex 运行专门负责挑错,却只使用了 Codex token 的 17%;单个消耗最多的是协调原始构建的根智能体。 在 630 次 Codex 运行中,347 次是专职审查:132 次发现者、111 次质疑者、104 次裁决者。它们共使用 7.90 亿 token,占 Codex 总量的 17%,按 API 价格折算为 $527。审查者只读取一份冻结的 diff 及其周边文件,因此每次运行都很小。Claude Code 启动的另外 47 次审查和审计运行使用了 2.25 亿 token。Codex 构建的根智能体使用 13.9 亿 token,占 Codex 总量的 30%,主要花在协调另外 332 个智能体时反复读取自己不断增长的对话。

审查者确实创造了价值。它们发现,一个浏览器测试辅助工具会在打开调试日志时打印真实凭据;共用的 cookie jar 也可能把预览访问 token 从一个测试服务器带到另一个。可它们在边际价值降低很久之后仍继续审查。自定义音频播放器经历了 14 轮审查,看起来仍与设计相差很远,我只好放弃。项目中途,我给这个循环加了一条停止规则:"non critical or high priority feedback do not block the milestone from moving forward."(既非严重、也非高优先级的反馈,不得阻止里程碑继续推进。)
🧑⚖️ 我做了什么:162 条消息,20 次纠正
我的工作最后变成了把握节奏和品味,而非代码审查:按我的分类,20 次纠正中有 15 次针对智能体的工作方式,5 次针对产品或网站外观。 在 Codex 阶段,我发出的 43 条消息里,有 20 条是不同版本的 "what is the progress"(进展如何)。多数流程纠正都针对节奏:"pause the execution"(暂停执行)、"never stop before you try again"(再试一次之前不要停)、"do not hang on the non-critical issues."(不要卡在非严重问题上。)
最初 4 次视觉纠正都是自动检查未覆盖的事情:章节标题末尾多了句号;媒体播放器的样式仍然不对;一个系列只显示 3 集,却没有提示还有更多;展开按钮里的 "+" 相对圆圈太小。每项问题都在大约 1.5 小时内修复并提交。扩展统计又加入了我后来针对“实现的播放器与设计相差很远”所做的纠正,以及 2 次对智能体工作方式的纠正。第 4 篇会逐一介绍全部 20 次纠正。
这正是我在《招聘 AI:流水线工人的时代正在结束》(Hiring AI: The Assembly Line Worker Era Is Ending)中写过的人与智能体分工:智能体负责执行,人决定哪些工作要委派、质疑、验证、发布或终止。
🚧 代价最高的 5 次绕路
高代价错误大多发生在设计之外:环境、部署,以及构建了一个与设计不符的东西。 按成本粗略排序如下:
- "Done" 并不代表真的完成。 所有里程碑通过关卡后,设计一致性审计仍发现 20 处与设计不符,其中 6 处严重。3 次复审把数量依次从 20 降到 6、2 和 1,第 9 轮修复才关闭最后一项。(第 2 篇)
- 始终无法部署的预览。 Codex 的 6 次尝试因 4 种原因失败,其中一次 Python 崩溃让旧版 CPU 固件成为合理嫌疑。随后 Claude Code 的首次尝试又遇到一个内存膨胀到超过 50 GB 的部署步骤,直到我的机器耗尽内存,只能由我手动终止。按 API 价格折算,两种工具在部署路径及相关基础设施上共计 $561;Claude Code 在这里的折算成本为 $447,高于改版本身的 $256。(第 5 篇)
- 一个始终没能做成设计样子的播放器。 自定义音频播放器经过 14 轮审查,构建再移除共用了至少 1.14 亿 token,最终和设计里的播放器相差很远。我的一句话删掉了其中 1,850 行代码。(第 4 篇)
- 预发布环境(staging)导致生产写入失败。 约 7 次预发布发布操作填满了一个与生产环境共用的数据库,所有写入因此失败约 2 小时。(第 5 篇)
- 用了错误的设计文件。 第一轮研究分析的是过期设计副本:一个 96 KB 的压缩包,而不是当前的 394 KB 版本。审查结论只能作废。(第 2 篇)
🧭 如果有人准备做同样的事,我会这样说
给智能体一份写明优先级顺序的规格文档(spec),设定审查停止规则,尽早验证部署路径,再安排一个人亲眼检查结果。 具体来说:
- 给输入留指纹。 任何人开始审查前,先用哈希记录准确的设计文件。
- 先部署一个最简单的东西。 这个项目风险最高的是通往预发布 URL 的路径,却被留到最后才测试。
- 按严重级别限制审查轮数。 严重和高优先级问题必须阻断。其他问题按优先级进入 backlog。
- 通过关卡后,对照设计审计。 测试能证明行为,却不能证明页面看起来与图片一致。
- 按容量隔离预发布环境,不能只隔离名称。 共用数据库里的独立 key 前缀,并不等于独立数据库。
- 自己亲眼看。 我的 5 次纠正,来自亲眼查看智能体做出的产品。
本系列其余文章:
- 第 2 篇:Claude Design 原型变规格,仍漏 20 处
- 第 3 篇:333 个智能体构建,Claude Code 收尾
- 第 4 篇:只有人类发现的问题:162 条消息里的 20 次纠正
- 第 5 篇:6 次失败部署后,预发布仍影响了生产
- 第 6 篇:AI 改版的 62.6 亿 token 去了哪里
如果是你的智能体工作流,你会先限制哪一个:审查轮数、并行智能体数量,还是部署步骤?
🚀 又用 4 天,然后上线
9 月 13 日至 16 日,工作重心从重建网站,转向完善发布系统、规划下一步,并最终上线。 首先是为博客增加内联视频,让设计演示可以直接在文章中播放。随后,真实的 7 篇系列文章暴露了博客索引页和文章页的设计对齐问题;较短的测试样例没有发现这些问题,后来才对照设计修正。名为“Writing”的版块改成了“Blog”,中文页面标题为“博客”,中文导航使用“文章”。网站定位语也改为:“Technical podcasts and a blog on language models, coding agents, and engineering practice.”(关于语言模型、编码智能体和工程实践的技术播客与博客。)
我还让智能体研究 AEO 和 SEO,并写出一份分为 7 个里程碑的计划。这份计划在审查后得到修正,但上线前并未实施。9 月 16 日,最终检查通过,改版完成合并,生产内容构建产物重新生成,williamliu.ai 以新设计正式上线。
本文写作方式:由 Claude Code 根据我本人的会话日志起草,另一个 Codex 智能体对照同一批日志核对事实,最后由我修改定稿。封面插图由 AI 生成;图表依据文中数字绘制。