看到这个技巧，我第一时间在自己的项目里试了一把。核心思路其实很简单：让Codex做‘项目经理’，Claude Code当‘执行者’。技术上的关键在于利用Codex的规划能力和Claude Code在代码生成上的细腻度，配合Fable的拒答机制做fallback。实测下来，在重构一个遗留Python模块时，原本需要手动拆分任务、反复调试的流程，现在由Codex自动生成步骤清单，Claude Code逐块生成代码，遇到边界情况（比如复杂异步逻辑）自动切回GPT处理，整体耗时减少了约40%。
个人经验是，这种双模型协作最怕的是‘上下文割裂’。我试过让Claude Code独立处理一个长流程，结果它中途跑偏；而Codex+Claude Code的组合，由于Codex持续维护高层计划，Claude Code只管执行，反而很少出错。这其实提示了一个趋势：未来AI编程工具的核心竞争力，可能不是单一模型的能力，而是编排多个模型的‘调度器’设计。
想问两个问题：1）有没有人试过把其他模型（比如DeepSeek或本地LLaMA）也塞进这个流程？2）当两个模型对同一任务给出不同方案时，你们是手动仲裁还是让Codex自动投票？期待讨论。
对行业而言，这种低成本的模型集成方案，可能会加速‘模型即服务’的落地——开发者不再绑定单一API，而是像搭积木一样组合模型，针对不同子任务选择最优解。这或许比单纯追求单一模型参数膨胀更有工程价值。