上周，我无意间组建了一支特别的开发团队。这支“团队”由我、Claude Code 和 Codex 组成，我们分坐在屏幕两侧，像两位彼此挑剔但又不得不合作的工程师。
说实话，效果堪称神奇。如果你想在不崩溃的情况下将开发速度提升一个数量级，这套组合可能是目前最接近真人结对编程体验的 AI 方案。
下面我将展示它的实际工作流程——不夸大，全是实战经验。
步骤 1：从 Claude Code 开始
Claude Code 就像那种不写完完整设计文档就不肯动手的工程师。事实证明，这是个好习惯。
当我向 Claude Code 提出需求：
“给我做一个 Flask 应用，可以上传 PDF 并生成摘要。”
它不会直接写代码。它会先进行规划。例如：
# Claude 的规划
1. 搭建 Flask 项目结构
2. 添加 /upload 文件上传端点
3. 使用 PyPDF2 提取文本
4. 通过 OpenAI API 进行文本摘要
5. 将摘要返回给用户
它的条理性有时令人抓狂，但这正是关键——Claude 提供了清晰的方向。它就像一个真正理解需求的项目经理。
步骤 2：将计划交给 Codex 评审
精彩的部分来了。将这份清晰的计划直接交给 Codex。
Codex 不会粉饰太平。它会给出直白的反馈：
“第 3 步：PyPDF2 对某些 PDF 编码处理不佳。建议改用 pdfplumber。”
“第 4 步：需要注意 API 调用频率限制。建议增加批处理或限流逻辑。”
Codex 扮演着那位“经验丰富、直言不讳”的工程师角色，而且它的建议通常很中肯。我将它的反馈复制给 Claude，就像项目经理转述评审意见一样。
于是，Claude 根据反馈更新计划，Codex 再次评审。循环往复。
步骤 3：旁观一场高效的 AI 辩论
很快你会发现，你不再是在写代码，而是在调解一场高效的 AI 辩论。
Claude 的代码优雅但可能不够健壮。Codex 会这样点评：
# “这里没有处理空文件上传的情况。”
# “缺少 API 密钥的环境变量校验，这是常见的安全疏漏。”
接着，Claude 会（以最温和的方式）进行“辩解”并改进：
def summarize_pdf(file):
text = extract_text(file)
if not text:
raise ValueError("PDF 文件为空，无法生成摘要。")
api_key = os.getenv("OPENAI_API_KEY")
if not api_key:
raise EnvironmentError("缺少 OpenAI API 密钥。")
return call_openai_api(text, api_key)
然后，代码就真的可以运行了。
整个闭环就是：Claude 规划 -> Codex 评审 -> Claude 改进 -> Codex 再评审 -> 完成。
步骤 4：让修复者主导
我遵循一条简单的经验法则：
谁修复了最后一个关键问题，谁就暂时主导开发——直到它遇到下一个障碍。
有时需要 Claude 的结构化思维，有时则依赖 Codex 的务实经验。你在两者之间动态切换，直到终端里不再出现错误信息。
这感觉就像在管理两位才华横溢但风格迥异的天才——但这是良性的、高效的“混乱”。
成果：构建速度提升 10 倍
我已经用这套方法完成了多个项目——从小工具、API 到 React 仪表盘。毫不夸张地说，它能将构建时间减少 70% 到 80%。
你不再是一个人在思考。你是在驾驭一个永不停止、从不抱怨的反馈回路（除非你把 Claude 偶尔的“抱歉，我似乎理解错了”也算作抱怨）。
关键技巧：像与人对话一样使用它们
这听起来有些奇怪，但确实有效——你的指令越口语化、越具体，它们的响应就越好。
示例：
# 避免模糊指令：
"Rewrite the code."
# 使用具体、对话式的指令：
“嘿 Claude，Codex 认为你的错误处理不够健壮。能根据它的反馈改进一下吗？”
它们会在彼此的上下文基础上持续构建，就像真正的队友在互相挑战和补充。最终代码质量的提升，非常显著。
总结
如果你只把 AI 工具当作“增强版的自动补全”，那就错过了真正的潜力。真正的力量在于协同，而不仅仅是生成。
让 Claude 负责规划和架构。
让 Codex 负责评审和挑刺。
而你——负责最终决策和方向把控。
你的开发速度会更快，学习曲线更陡峭，而且说实话……编程重新变得有趣了。
这套组合与其说是“在使用 AI”，不如说是在管理一支永不停歇、高度互补的开发团队。
试试看——结果很可能会让你惊喜。
关注“鲸栖”小程序，掌握最新AI资讯
本文由鲸栖原创发布，未经许可，请勿转载。转载请注明出处：http://www.itsolotime.com/archives/13736