兄弟们，粗大事了！
发现没有？Codex 现在脑子是越来越好使了，写代码、盘架构那叫一个神仙下凡。
但你查额度的时候有没有两眼一黑？Token 烧得速度越来越离谱！
穷则思变，富则...算了，咱是穷鬼，富哥就不用往下看了！
为了守护我们钱包，这套穷鬼工作流横空出世！
以前是你 PUA Codex。
现在你 PUA Codex，让 Codex 再 PUA Claude Code，先让 AI 自己内卷一波！你再做Codex验收结果的验收！
以前你让 Codex 一个人硬扛大项目，它要读代码、拆需求、找调用链、改文件、跑测试、看失败日志、再回头修。主线程越塞越胖，token 越烧越猛，这就好比你花重金请了马斯克，结果让他去通下水道？！暴殄天物啊！
现在？欢迎来到 AI 黑心包工队！
Codex 稳坐老板椅发号施令，子代理排队领活干，Claude Code 披着 DeepSeek 的皮疯狂下场搬砖。什么长上下文探索？什么大范围重构？什么无限死循环排错？不再往主线程里硬灌，直接扔给执行层干，AI包工队不配有双休！
这才是多代理最该有的嘴脸：老板负责统筹大局，验收结果，打回重做！牛马疯狂内卷抢活，脏活累活全被外包，最后功劳全是老板的！把这套玩明白了，你的 Codex 才能真正爽到飞起！
当然了，作为指挥Codex的你，才是真正的大资本家！
这一切都基于 DeepSeek 的离谱低价！在加上缓存命中价格百万token俩分钱！长任务、多代理、大范围代码探索，给我往死里造！反正苦力便宜，Token 成本四舍五入等于不要钱！
人民的 DeepSeek，小 D 的恩情还不完😭
一句话安装工作流
前置条件很简单：
- 安装 Claude Code。
- 安装 CC Switch。
- 在 CC Switch 里把 Claude Code 的后端 API 切到 DeepSeek。
- 准备一个你想接入这套工作流的目标项目。
- 打开 Codex。
没有 Codex？那不好意思，本项目不适合你。这里就是给 Codex 当 leader、子代理当打工人的。
然后，把安装提示词发给目标项目里的 Codex（拉取更新工作流，也是下面的提示词）：
请把 https://github.com/xdd666t/codex_with_cc 调度子线程工作流集成或更新到当前项目。
接入之后，核心心法只有一句：
让 Codex 做 leader，让子代理当大头兵。
这句话不是装酷，它决定了你后面怎么下命令，也决定了这套东西为什么能把 Codex Plus 用出另一种爽感。
你不要再对 Codex 说“帮我把这个大需求做完”，然后让它在一个主线程里从需求分析、代码阅读、方案设计、文件修改、测试失败、返工修复一路扛到底。这当然能跑，但上下文会越来越肿，日志会越来越多，主线会越来越散。
更好的姿势是：让 Codex 拆任务，让子代理执行，让 Claude Code/DeepSeek 去啃高 token 苦活，让主 Codex 审核和兜底。
效果
- 提示词
你现在委派三个子代理，让他们深度分析项目，给出项目中的优化计划书，对于三份计划书中矛盾的点，需要反复打回让他们再去验证再去制定，直到一致，然后你汇总出一份优化计划书。 你作为leader，能力强，需要统筹好全局，你要对你的结果负责！
- 创建子代理
- 子代理执行Claude cli
- 结果打回，重新验证
这样使唤 Codex
最基础的派工方式长这样：
你拆解 xxx 任务，安排给多个子代理实现。你负责审核子代理结果，不符合要求就打回让他们重改，直到符合要求为止。
如果你想把责任链说得更硬一点，可以直接这样下命令：
你负责拆解、派工、审核和最终交付。子代理负责执行。结果不合格就返工，直到符合我的要求。
如果是大任务拆分，可以这样：
你先阅读项目，拆成 3 个互不冲突的实现任务，分别交给子代理处理。每个子代理必须给出变更文件、验证命令和风险说明。你最后统一 review、整合，并跑最终验证。
如果你还没确定技术路线，可以让多个子代理先分别出方案：
请启动多个子代理分别提出 xxx 的实现方案。每个方案需要说明优缺点、复杂度、风险和迁移成本。你汇总后给出推荐方案，不要直接照抄任何一个子代理。
如果你担心代码质量，可以让一个代理写，一个代理专门挑刺：
安排一个子代理实现 xxx，再安排另一个子代理专门做代码审查和边界情况攻击。你负责判断 review 是否成立，成立就打回实现代理修改，不成立就说明理由。
如果你只是想查一个大模块，不想让主线程被所有噪音淹掉，可以这样：
请把项目里的 xxx 模块交给子代理做深度调查，要求输出调用链、关键文件、潜在风险和建议修改点。你只保留结论，别把所有噪音塞回主上下文。
这几类提示词的共同点很清楚：Codex 主线程不负责苦哈哈地把所有活都亲手干完，它负责把活拆清楚，把标准讲明白，把结果审回来。
人话说，就是别让老板亲自搬砖。老板该做的是派活、验收、打回返工，以及最后对交付负责。
为什么这东西香
如果你重度用 Codex 做项目，大概率已经见过这种场面：
一个复杂需求丢进去，Codex 先读项目，再找调用链，再改三五个文件，再跑测试。测试一炸，开始读日志。读完日志再改。改完又跑。跑完又发现另一个边界。最后主线程里塞满了代码片段、失败日志、中间判断、修复尝试和各种“我再检查一下”。
前面看起来还行，后面就开始不对劲了。
上下文越来越胖，token 越烧越猛，主 Codex 的注意力被中间噪音拖着走。它本来应该做架构师、项目经理、审稿人和最终责任人，结果被迫变成全栈苦力、测试工、日志分析员和临时救火队。
这时候最痛的不是“AI 不够聪明”，而是聪明的主线程被脏活拖住了。你花钱买的是 Codex 的判断力，结果它一半精力在翻日志，一半精力在重复读文件，最后还要从一堆上下文碎片里把主线捞回来。
而 DeepSeek 的快乐就在这里：让它去啃那些高 token、长上下文、重复阅读的体力活。缓存命中率一旦吃起来，体感上就像给多代理协作装了省钱外挂。不是说成本从此不存在，而是那种“每多试一次方案都心疼 token”的心理压力，会明显被按下去。
最难受的是，大项目里很多工作不是“聪明”就能省掉的。
你要读陌生模块，要扫文件，要比较方案，要看失败日志，要补测试，要查边界，要做 review。这些都是必要劳动，但它们不一定都该塞进主线程。
这就是codex_with_cc的切入点：把高 token、高噪音、高重复的执行型任务委派出去，让主 Codex 保持清醒，让小 D 去干它最适合干的苦活。
Codex 不是不能干活，Codex 是太适合当 leader 了。让它一直埋头搬砖，反而浪费它最值钱的能力：全局判断、任务拆解、风险裁决和最终验收。
这套工作流的爽点也在这里：
- 主线程不用吞下所有代码阅读和日志噪音。
- 子代理可以承接长上下文探索、实现、审查和返工。
- Claude Code CLI 负责执行具体任务。
- DeepSeek 负责消化大量重复上下文和高 token 工作。
- Codex leader 最后统一 review，结果不行就打回重改。
你真正想要的不是“多开几个 AI 看起来很热闹”，而是让每一层都有自己的职责。
主线程保持判断力，执行层负责燃烧体力。
这不是提示词玩具
很多所谓多代理工作流，其实只是把提示词写得更像公司制度。
“你是 A 代理，你负责开发。”
“你是 B 代理，你负责审查。”
听起来很正规，落地一看，全靠 AI 自觉。没有 session 管理，没有任务指纹，没有租约，没有审计产物，没有链路约束。任务怎么发出去的、用了哪个会话、有没有复用上下文、有没有跑验证、结果从哪里来，全都糊成一团。
codex_with_cc不是这个路子。
它做的事情更朴素，也更工程化：把一套Codex -> Codex 子代理 -> Claude Code CLI的委派工作流复制进任意项目，让 Codex 当 leader，Claude Code/DeepSeek 当执行层。脏活累活、长上下文探索、大范围改代码、互相找茬，都扔给子代理；主 Codex 只管拆解、调度、验收、打回重改。
这就不是“请 AI 自觉点”的玄学了，而是把多代理委派做成有状态、有产物、有边界、有验证的工作流。
真正的含金量，藏在后半段。
工作流拆解
这套链路可以写成一行：
Codex 主线程 -> Codex 子代理 -> Claude Code CLI -> Claude Code 后端模型
每一层的职责不一样。
Codex 主线程负责理解需求、拆任务、创建子代理、审核结果、打回返工和最终交付。它是 Codex leader，是架构师，也是最后背锅的人。
Codex 子代理负责作为可追踪的对话树节点，调用委派脚本，把具体实现、调查、审查这些高 token 消耗任务交给 Claude Code CLI。它不是随便开的聊天窗口，而是主线程派出去的任务节点。
Claude Code CLI 负责执行被委派的具体任务。它可以做调查、改文件、运行验证，并输出结构化报告。
如果 Claude Code 后端通过 CC Switch 接到 DeepSeek，那么大量读代码、改代码、跑验证的苦活就可以交给 DeepSeek 去消化。README 里提到的重点体验，是 DeepSeek 的缓存命中率很夸张，重复阅读、重复建模、重复烧 token 的部分能少一点是一点。
所以这个链路的本质不是“让多个模型一起聊天”，而是分层：
- Codex 主线程负责判断。
- Codex 子代理负责承接任务节点。
- Claude Code CLI 负责执行。
