你有没有过这种体验：对话里刚出现一句 git 命令、一段 CLI 操作、或者几行代码，你就条件反射地把活甩给 Codex，心里想着「这肯定更快」。

结果过了一段时间你发现，真正变多的不是执行速度，而是交接次数。先在 ChatGPT 里把需求讲清楚，再切到 Codex 里翻仓库，又回到 ChatGPT 改一个假设，然后再甩回 Codex。来回几趟，很多本来在桌前就能定下来的问题，也被你一起搬来搬去。

问题不在 Codex，在我的切分规则。我把「技术不技术」当成了「该不该交出去」的判断标准，而这两件事根本就不是一回事。

交接在传递什么，很多人没想清楚#

在这之前，我重度用过 Claude Code。它不只是代码补全，能读代码库、改文件、跑命令，我给它的是一个完整的长单元：研究、设计、实现、测试、git 收尾。

Claude Code 的 Hooks 是这个工作流里很重要的一环。Hook 是在特定生命周期节点触发的自定义命令，可以在编辑后格式化、在危险命令前刹车、或者启动一个验证步骤。说白了，Hooks 帮我把反复交代的话，变成了可复用的停靠点。

我从那里带走了一个底层观念：一旦把一个定义清晰的工作单元交给 AI，我就希望它自己完成调查、决策、执行、验证这整条链路。

后来认真用上 Codex 应用，我想把这套思路套到 ChatGPT 和 Codex 之间，但切分工作的规则很粗糙：「技术活就交给 Codex」。

这句话听起来天经地义，但「技术」并不是执行需求。定义目标读者、比较现成方案、选择约束、写验收标准，这些事全都可能带着技术语言，却并不需要真实的仓库。我混淆了「工作的主题」和「工作所需的证据」。

那么交接到底在传递什么？它不是复制一段 prompt，而是把足够多的信息交给下一个执行者，让它能接着同一个决策往下走。这个信息，就是上下文。

操作上，我把上下文当成一个交接包来对待：目标、当前状态、已经定下的决策、固定的约束、下一步动作、以及证明成功的证据。每移动一次，我就重建一次这个包。如果决策还没稳定，下一个 AI 可能重新研究同一个问题，或者基于不同的假设去动手。

所以更便宜的那个问题应该先问一句：这次交接，真的需要发生吗？

按「答案住在哪里」来路由#

我现在的新规则只有一条：

如果下一步决策能从已知目标和约束里安全地做出来，就留在当前界面继续；如果拿到答案必须接触真实环境，就交给 Codex。

「留在当前界面」不意味着所有事都自己写。恰恰相反，我在把基础工作往 AI 那边移，测试它到底能卸掉我多少负担：研究并比较现有信息、框定用户的真实问题、提出范围和非范围、搭大纲写初稿、提出验收条件和验证方法。

人类保留的是另一类决策：谁的问题值得解决、什么绝对不能变、发布、删除、花钱这些不可逆的边界在哪里、以及什么样的结果才算成功。

这不是「全丢给 AI」和「人肉审查一切」之间的折中，而是一种运营设计，让人和 AI 各自拥有不同性质的权限。

判断边界有一个很实用的对照表：

下一个问题答案住在哪里
这个改动该解决谁的问题？现有需求和人的判断
类似的实现是不是已经存在？真实仓库和 git 历史
这条命令在当前环境能不能跑通？CLI 输出
改动有没有破坏既有行为？测试、lint、构建
读者能不能真正用上这个页面？真实的浏览器界面

你看，边界并不在「思考」和「构建」之间，而在「基于已有信息做决定」和「从真实产物收集证据」之间。后者才需要 Codex 出场。

一个五字段的交接包#

边界一旦清楚，你就不需要写一份长篇说明书。在 Codex 启动前，我尽量固定一个最小的交接包：

goal:        谁有什么问题，做完之后会发生什么变化？
constraints: 哪些决策已经定死？什么不能改？发布、删除、花钱的门在哪里？
execution:   当前状态是什么？真实环境里还剩什么要查、要改？
done_when:   什么可观测的状态，意味着这件事完成了？
verify_with: 用哪条命令、哪个页面、哪个 URL、哪条测试、哪份 diff 来证明它？

这个模板的好处是，它保留了实现上的自由度，同时又固定住了语义边界。

拿「让一篇文章达到可评审状态」举例。在让 Codex 打开仓库之前，AI 可以先研究潜在读者、查和已有内容的重复、提出论点、搭大纲、定义封面图要传达什么。人决定的是论点是否符合真实体验、什么内容可以发布、以及「可评审」这三个字到底指什么。然后 Codex 再去定位规范文件、放置文章和图片、跑预览、在真实渲染出来的页面上检查目录、代码块、链接、图片和 frontmatter。

我自己的一个体会是：done_when 和 verify_with 这两个字段尤其值得较真。它们本质上就是可执行的验收标准。一个模糊的「做完就行」，会逼着 Codex 在收尾阶段反复回来问你「这样算不算完成」；而一句「pytest tests/test_api.py 全绿，且 curl -sI 返回 200」能一次性把话说明白，省掉好几轮返工。

要证据，不要例行决定#

交接之后，我不希望 Codex 在每个小的可逆选择上来问我。我希望它自己拥有这条循环：

检查 -> 决定 -> 修改 -> 测试 -> 修复 -> 验证真实产物

从 Codex 回到规划界面这件事，只有在执行产出了新事实时才值得做：我们预期的 API 根本不存在、某条测试推翻了一个需求假设、真实 UI 技术上正确但难读、或者已有实现让新代码变得多余。这些回程值回票价，因为它们带回了坐在桌前拿不到的证据。

反过来，「这个变量叫 A 还是 B」「这几个等价库选哪个」这类可逆的选择，通常不值得专门跑一趟回来。我在测试的是，把执行循环的所有权转移出去之后，人的负担到底能不能降下来。

我现在能承认和不能承认的#

我不能声称这套边界把交接次数或者完成时间降低了具体多少个百分点，因为还没测量。

我能承认的是可解释性变好了。当我习惯于把决策稳定到「真正需要真实环境」之前，就更容易说清楚：我要交给 Codex 什么、为什么现在交、什么证据能收尾。

接下来我打算测几个指标：每个工作单元的交接次数、交接之后被推倒重建的前提数量、返回给人的澄清请求数量、以及从开始执行到拿到验证产物的耗时。如果几周后我又改了这套边界，那不叫失败，只说明那个底层观念终于变成了一条可测量的假设。

写在最后#

这套方法的核心，从来不是「要不要用 Codex」，而是「在哪个时间点把工作交给 Codex」。

我从 Claude Code 那里保留的观念是让 AI 拥有一个足够长的自主工作单元；我为 Codex 调整的是这个自主单元从哪里开始。我现在更倾向的判断是：只把代码交出去，会让协调成本过多地留在人身上。所以我在试一种更宽的切分，把基础工作交给 AI、把语义边界留给人、在真实环境持有答案时才移交执行。

下一次做 AI 辅助任务，在你写下「技术活」三个字之前，先停一下，填好五个字段，然后问自己一句：

这个决定，能不能在不动真实仓库、CLI、测试结果、浏览器的情况下，安全地做出来？

能，就让 AI 留在当前界面继续打地基。不能，就把工作移到有答案的那个环境里，把执行和验证一起交出去。

参考来源：I Used Claude Code Heavily. Then Codex Changed How I Hand Off Work. by nomurasan，2026-08-12，Dev.to（原文改编自作者的日文 Zenn 文章）