兄弟们粗大事了发现没有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 当 leaderClaude 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 负责执行。