先说结论：这玩法能抄，但抄的是权限设计，不是工具清单。
先把丑话说前头：这次没法上手，我没有博主那套环境，这篇是把公开信息摊开做的纸面拆解，不是本人实跑，所以下面出现的每一步都是我按描述推演出来的，你照着搭的时候以实际环境为准。
一个人的两条流水线
背景先交代。X 博主卡兹克（@Khazix0918）在 X 上分享了他的一人团队分工：Claude 做指挥，负责对话、规划、前端开发和验收；成块的重活，交给本机跑的 Codex 去干。
据他自己的说法，这套流程是日常真在用的，不是演示。
一人团队怎么开双线？双就体现在这里：一条是人和 Claude 的对话线，负责想清楚要干什么；另一条是脚本派给 Codex 的执行线，负责把东西真做出来。两线并行，人只站在几个关键节点上，其余时间不用全程盯着。对话线慢但灵活，执行线快但只能干整块任务，正好互补。
分工表：Claude管嘴，Codex干活
先把 Claude 这侧摊开：对话、规划、前端开发、验收，四件事全归它。说白了，凡是要来回沟通、要改来改去的活儿，都压在指挥这条线上，它不碰那些成块的硬活。
成块的后端、算法、数据处理任务，Claude 不自己干，而是通过博主自建的脚本 codex-worker 派给本机的 Codex。据博主分享，本机 Codex 跑的是 GPT-6.1 Sol 模型。
还有个容易漏看的环节：合并前的代码审查也由 GPT 完成，属于 Claude 侧流程的一部分。等于说，代码进主仓库之前，已经先过了一轮机器审查，人接手时看到的基本是预审过的东西。
codex-worker：任务怎么派进沙箱
codex-worker 是博主自建的脚本，一句话说明白：把 Claude 规划出来的成块任务打包，投给本机的 Codex 去执行。人在中间不下场，只定规则、收结果。
我按公开描述，把这条线在脑子里跑了一遍时间轴：任务进来，Claude 先跟你对话、拆规划；需要写码的部分变成任务，codex-worker 接住，投给 Codex；Codex 在自己能碰的目录里干活；干完先过 GPT 预审；预审过了，任务才回到人手上。
注意 Codex 执行时能碰的地方只有两块：工作树（worktree）和临时目录。它不能提交，也不能联网。这听起来是两条限制，其实是同一条：它被关在沙箱里。为什么这么卡，下一节单独拆。
还有个细节：这套流程里 Codex 从头到尾没有对话环节，只接收任务、交回代码。对话权在 Claude 手里，执行权在 Codex 手里，谁也不越界。时间轴拉完你会发现，人真正动手的环节只有末尾两步，中间全是模型在跑，人的角色从写代码变成看 diff 和按提交键。
为什么Codex不能提交不能联网
这一节是全文最值钱的部分。先回答最容易被问到的：为什么要拦着干活的模型？难道不拦它，活干得更快吗？
提交权在谁手里，最终审查权就在谁手里。Codex 一旦能提交，它写的东西直接进仓库历史，你连拦一下的机会都没有。让它只能写工作树和临时目录，等于把它关进一个随时可以整个删掉的沙箱，出事了删目录就完事。
不能联网是同一个逻辑：干重活的模型一旦能上网，它的动作就跳出你可预测的范围了。把不可全信任的模型关在沙箱目录里，人保留提交权，这就是这套玩法的安全核心，也是整套分工里含金量最高的一条。
我的判断：工具会一代代换，沙箱边界这条线不会换。明年大家换什么模型跑活，这条权限设计大概率还在，因为它防的不是某个具体模型，是所有你不敢完全放手的模型。谁先想通这一点，谁抄这套流程就不会抄偏。
一台电脑就能抄：最低成本版
我就想问一句：我电脑没两台，能这么玩吗？能。这套流程里 Codex 本来就跑在本机，靠的是 git 的工作树机制，一台电脑一个仓库切出多个工作树就够了，根本不需要双机，笔记本也扛得住。
最低成本版本长这样：规划和对话用你手头的主模型；写个脚本当你的 codex-worker，把任务打包丢给本地 agent；给它划一个专用工作树，在配置里写死两条：不能提交，不能联网。博主的权限规则就写在他 Claude 的配置里，你照着写进自己的配置就行。
人这边的活一件都别省：读 diff、跑测试、装依赖、提交推送，四件事全留给自己。这一步偷懒，前面所有的沙箱设计就白搭了，因为流程的最后一道闸门，就是你自己的手。
判断：这套玩法的门槛不在设备，在你敢不敢把提交权一直攥在自己手里。工具都是现成的，卡住人的往往是自己不放心。
收尾：值得学的就两条
回头盘一下。值得学的是两条：规划和执行分离，重活扔进沙箱；提交权留给人。这两条跟具体工具无关，换什么模型组合都成立，抄之前先想清楚这两条是不是你要的。
别学的是照抄工具清单。Claude 加 Codex 加自写脚本，是他的配置，不是标准答案。你的预算、你的项目类型，可能更适合别家的模型组合，照抄工具名只会把自己绕进去。
至于要不要抄，我的标准很朴素：你愿意为省时间让出多少控制权。让得少，这套设计就稳；让得多，再漂亮的工具清单也救不了你的仓库。
留个问题给你：如果你的模型永远不犯错，你还需要沙箱吗？反正我需要，因为我知道它哪天会犯错，而那天你希望仓库是干净的。
