只有人类发现的问题：162 条消息里的 20 次纠正

《用智能体重建 williamliu.ai》6 篇系列的第 4 篇。请从总览开始阅读。

要点

• 💬 15 天里，我发出 162 条消息：67 个新请求、38 个问题、34 次批准、20 次纠正，以及 3 条其他消息。
• 👀 我发给 Codex 的 43 条消息中，有 20 条在问进展。
• 🎨 5 次纠正属于视觉或产品判断，其中没有一项是现有检查能替我决定的。
• 🧭 15 次纠正针对智能体的工作方式：节奏、优先级、范围，以及由谁审查计划。
• 🗑️ 我喜欢设计里的音频播放器，但经过 14 轮审查后做出来的那个和它相差很远；构建再移除，共用了至少 1.14 亿 token。
• 🧑‍⚖️ 智能体停下来问了我 23 次；任何可能触及生产环境的操作都等待明确批准。

智能体几乎包办了构建和审查；它们需要我提供的是品味、节奏和优先级，再多审查也无法替代这 3 件事。 截至上线，我统计并分类了自己输入 Codex 和 Claude Code 的全部 162 条消息。本文聚焦其中纠正问题的 20 条，以及它们的共同点：5 条是对网站或产品的判断，15 条改变了智能体的工作方式。现有检查没有发现其中任何一类问题。

👀 我发给 Codex 的消息，近一半在问进度

按我的分类，在 Codex 阶段发出的 43 条消息中，有 20 条是进度问题。 "what is the progress"（进展如何）出现了 3 次，"show me the progress"（给我看进展）出现 1 次。"have you started parallel implementation of the tasks?"、"did you start parallel tasks subagents"、"are you using multiple subagents to work at the same time?"，以及另外 2 个类似问题，说明我一共问了 5 次工作是否真的在并行执行。另有 5 条消息只有 "continue" 或 "resume"（继续）。

构建第一天，我要求它 "regularly show me the progress (which milestone is being implemented and what are the subagents beingexecuted in parallel)"（定期展示进度：正在实现哪个里程碑，哪些子智能体正在并行执行）。可我还是不断追问。智能体记录的状态使用它们自己的语言：候选哈希、审查轮次、修复轮次。我想知道的是，网站离完成还有多远。

我得到的教训是：自主运行需要一个写给付费者看的进度视图。已经完成多少里程碑，还剩多少，卡在哪里，谁负责解除阻塞。唯一视图如果是智能体自己的日志，人就会变成轮询循环。

🎨 现有测试没找过的 5 次视觉或产品纠正

这一组里的每次纠正，都在判断读者如何体验产品；其中 4 次改变了网站，第 5 次纠正了我为什么放弃播放器的说法。 前 4 次都来自实际使用预发布网站：

1. "There is also another small bug that the title has a '.' at the end"（还有一个小 bug：标题末尾有一个句点。）页面标题显示为 "Technical podcasts." 和 "About."。设计原型本身带有这些句点，生产环境也采用同样风格（"Technical podcasts."、"Blog."）。智能体忠实复制了设计，但我决定不要句点，品牌规范也随这次修复一起改变。
2. "The media player's style is still wrong. Revert the media player style back to the one before the redesign"（媒体播放器的样式仍然不对，恢复成改版前的样式。）已经做出来的播放器和设计里的相差很远，所以这次纠正推翻了已批准的规格文档，后者原本要求使用自定义播放器。下文会详述。
3. “with the 3 episode displayed, it is hard for user to know that there are more episodes. add a clear indication like "View all xxxx episodes" there.”（只显示 3 集时，用户很难知道还有更多内容，请添加 "View all xxxx episodes" 之类的明确提示。）播客页严格按设计为每个系列显示 3 集。对于有 60 集的系列，页面完全没有提示其余 57 集的存在。文案检查认为我的措辞超过了网站按钮长度规范，但最终仍按我的原话上线。
4. "The + sign shall fill the cirle in the top right corner. now it is too small"（右上角的加号应该填满圆圈，现在太小了。）展开按钮达到 44 像素的尺寸要求，也通过了测试，但里面的加号很小。
5. "I uploaded two screenshots of what the media play looks like in the design. I like that design. But the implemented player is very far from the design. So I have to give up that. make sure when you talk about the media player used many tokens and I decided to revert it."（我上传了设计中媒体播放器的两张截图。我喜欢那个设计，但实际做出来的播放器和设计相差很远，所以只能放弃。写到播放器用了很多 token 时，要说明是我决定回退。）这次没有再次改动网站，而是纠正了故事：我喜欢设计，放弃的是实现，而不是那个想法。

我随第 1 次纠正发出的截图还显示了 4 个问题：首页单集行在实时更新后丢失单集编号；页脚少了一个链接，堆叠时字体也不对；页面标题下的分隔线比后面的分隔线窄；单集播放器的按钮被拉伸到整个页面。单集编号缺失只会发生在实时预发布网站上，而且是在脚本加载最新数据之后，已有的本地检查全都没有覆盖这种情况。

🗑️ 我不得不放弃的播放器

我喜欢设计里的音频播放器，但智能体做出来的那个和它相差很远，所以在 14 轮审查之后，我放弃了它；构建再移除，共用了至少 1.14 亿 token。 设计里有一个完整播放器，带可以点击跳转的细密波形；每个列表里还有一个纤细的小播放器：圆形播放按钮、一条细进度线和时间。智能体做出的播放器支持键盘、有原生播放器后备方案，全页面状态同步。它经历了 14 轮审查，看起来仍然不像设计。

按名称参与构建和审查它的智能体共用了 8,600 万 token，更早的轮次还不在这个统计里。我在预发布环境（staging）看到它后，要求换回网站原来的播放器。这次回退又用了 2,800 万 token，涉及 43 个文件，删除 1,850 行，其中 1,263 行是测试。网站现在处处使用浏览器原生音频控件，在单集页保留旧网站原有的吸底播放器栏，同时仍保证一次只播放一个单集。

教训在于审查检查的是什么。审查验证了播放器能否正常工作，答案是能。直到第 14 轮审查，才第一次拿它和设计对比；即使那一轮做了修正，它看起来仍和设计里的播放器相差很远。如果在第一版能用时就把它和设计并排看一眼，本来可以在大多数审查轮次开始前发现这个问题。

🧭 针对智能体工作方式的 15 次纠正

我的多数纠正，都在让智能体停止把一件已经不再重要的事做得更好。 按它们试图纠正的问题分类：

• 暂停。 "pause the process, I will resume it soon"（暂停这个流程，我很快会恢复）；"pause the execution"（暂停执行）。
• 停止打磨，继续推进。 "non critical or high priority feedback do not block the milestone from moving forward. just document the rest of the feedback into a backlog list and give them the proper priority."（既非严重、也非高优先级的反馈不得阻止里程碑推进；只需把其余反馈记录到 backlog，并赋予适当优先级。）2 天后，我又发出："why the webstie is still not moving on fast. what did you accomplished in the past 24 hours"（为什么网站推进得还不快，过去 24 小时完成了什么），接着是 "do not hang on the non-critical issues. you don't need to get 100% bug free or a perfect code."（不要卡在非严重问题上，不需要做到 100% 没有 bug，也不需要完美代码。）
• 也不要轻易放弃。 构建停下来等待时，我说："never stop before you try again"（再试一次之前不要停）。
• 改变优先级。 "given there is a big redesign pending deplyment. my first priority is to fix the deployment issue to be able to verify the redesign."（还有一次大型改版等待部署，我的第一优先级是修复部署问题，以便验证改版。）Claude Code 此前花了约 1 天研究和规划一次更大规模的网站媒体存储与部署改造。这个计划本身很好，却不适合那一周。我将它延期，部署修复在第二天早上完成。
• 纠正规划。 3 条消息纠正了上述延期计划的细节，另有 1 条要求停止工作，让我先审查。
• 报告失败。 "the previous staging deploy failed because the process run out of memory, debug the issue and fix it."（上一次预发布部署因进程内存耗尽而失败，请调试并修复。）
• 界定范围并选择审查者。 "we dont need specific code for my website redesign article drafts. also the website code can commite if clean"（我的网站改版文章草稿不需要专用代码；网站代码干净的话可以提交。）把网站专用的代码包移出了这个系列。"Using Fable to Review the plan one more time after you are done with the current edits"（完成当前修改后，用 Fable 再审查一次计划。）把最后一次计划审查从 Codex 改交 Claude。

规律很一致。智能体倾向于追求彻底：再来一轮审查、再做一次加固、再写一份更好的计划。我的消息始终指向同一个目标：先让我在预发布 URL 上看到一个可用的网站。严重级别规则改变了此后所有工作的审查政策。在它出现前，中等问题也必须修复或明确豁免，里程碑才能推进；之后，只有严重和高优先级问题可以阻断，其余问题按优先级进入 backlog。

📐 9 月 12 日之后，真实内容突破了基线

上线阶段带来了更多修复，但并非每个提示或异议都因此算作一次人工纠正。 9 月 14 日，我上传预发布环境的博客页截图，并写道："uploaded how the blog page looks like, check if it aligns with the design"（上传了博客页面现在的样子，请检查是否与设计一致）。分类器仍将这条消息归为新请求，而不是纠正，尽管它最终带来了 5 个修复提交，涉及索引页和文章页布局。

当时每一道关卡都已通过。问题出在截图基线：固定样例里的文章标题短、摘要只有一行、没有封面，标签也少。这些内容让错误的版式看起来没有问题，随后基线又把它锁定下来。替换后的样例包含长标题、多句摘要、封面和多个标签。视觉基线的质量，取决于它冻结的案例。

文案也体现了同样的区别。把 Writing 改为 Blog 时，一个智能体把定位句改成 "podcasts and blog posts"。文案检查未接受这个说法。后来我的 "change the blogs." 被归为批准或决定，而不是纠正；它选定了最终文案："Technical podcasts and a blog on language models, coding agents, and engineering practice."（关于语言模型、编码智能体和工程实践的技术播客与博客。）这里统计的是我的消息各自发挥了什么作用，而不是修复了多少缺陷，也不是智能体提出了多少异议。

🧑‍⚖️ 智能体问我的问题

智能体以两种方式停下来问了我 23 次；凡是涉及生产环境、花钱或删除的操作，都等待我的明确同意。 Claude Code 发起了 18 次结构化 AskUserQuestion 调用，共包含 33 个问题；18 次调用全部得到了回答。Codex 主动阻塞自己 5 次，共等待我将近 6 小时：分别针对设计、修订后的规格文档、沙箱权限、将某个特定提交上传到某个特定预览项目，以及一个诊断步骤。

其中一些问题是整个项目最重要的决定：

• 生产写入失败期间，是否从生产环境共用的数据库中删除约 2,200 条过期预发布记录（第 5 篇）。
• 哪些现有 URL 在改版后必须原样继续有效。
• 是否让首页在大屏幕宽度下继续采用更宽布局（我选择保留）。
• 每一次可能进入生产环境的 push。改版在 9 月 16 日按我的明确指令上线。

🧭 哪些事情要留给自己

品味、节奏和优先级要留给自己，其余交给智能体。

• 尽早查看运行中的成品，并与设计对照。 审查可以证明它能工作；这次 14 轮审查里，只有最后一轮拿它和设计对比过。
• 视觉基线要放入真实内容。 过短的固定样例会让错误布局看起来正确，再把错误保留下来。
• 第一天就写下停止规则。 决定哪些严重级别会阻断，以及其余问题去哪里。
• 用自己的语言要求进度。 已完成和剩余的里程碑、阻塞项，以及由谁负责。
• 说清楚这周什么最重要。 放错星期的好计划，依然是一次绕路。
• 所有不可逆的同意都由你作出。 生产环境、删除、花钱。

我曾在《编码判断力成为新的护城河》（Encoded Judgment Becomes the New Moat）中提出：评估和升级处理模式可以成为基础设施，但并非所有判断力都可以。《真正的 AI 编码竞赛：哪种工具最能编码工程判断力》（The Real AI Coding Race: Which Tool Best Encodes Engineering Judgment）则列出了任务合同、边界、批准、验证和审查。这个项目印证了这一点：严重级别、重试、规划审查、视觉对照和代表性样例规则，以及 "View all" 提示和加号尺寸标准，下次都可以编码进系统。

有些决定无法从已有输入中推导出来：删除句点推翻了设计和生产环境的先例；放弃播放器推翻了规格文档；暂停，以及那一周部署优先，都依赖当下语境。不可逆操作的批准仍需要人。这也让《招聘 AI：流水线工人的时代正在结束》（Hiring AI: The Assembly Line Worker Era Is Ending）中我写的“品味成为基础设施”更精确：品味只有在人把它说清楚之后，才能成为基础设施。

第 5 篇会讲最重要的那些批准：预发布改版时如何保护生产环境，以及预发布导致生产写入失败的那一天。

你对智能体做过的哪些纠正，本可以在第一天就写成一条规则？

本文写作方式：由 Claude Code 根据我本人的会话日志起草，另一个 Codex 智能体对照同一批日志核对事实，最后由我修改定稿。封面插图由 AI 生成；图表依据文中数字绘制。