Codex with ChatGPT：让ChatGPT做大脑，Codex当双手的AI结对编程神器

> 一个将ChatGPT的规划能力与Codex的执行能力结合的AI编程工具，实现真正的思考-编码分离协作。 ## 项目定位：为什么需要这个项目？ 在AI辅助编程的浪潮中，我们面临一个尴尬的现状： - **ChatGPT**（尤其是GPT-4系列）拥有极强的代码理解、架构设计和问题拆解能力，但它无法直接在你的终端里执行命令、修改文件、运行测试。你只能复制粘贴，来回切换上下文，效率大打折扣。 - **OpenAI Codex CLI**（或Codex harness）是一个终端原生的编码代理，它能读写文件、执行shell命令、运行测试，但它的“思考”能力相对较弱——它更像一个勤奋但缺乏战略眼光的执行者，容易在复杂任务中迷失方向，或者做出短视的决策。 **Codex with ChatGPT** 正是为了解决这个割裂而生。它创建了一个**双智能体协作架构**： - **ChatGPT** 作为“规划大脑”（Planner），负责理解用户需求、拆解任务、设计技术方案、生成步骤清单。 - **Codex** 作为“执行双手”（Worker），严格按照ChatGPT给出的计划，在本地环境中逐步执行：创建文件、修改代码、运行命令、验证结果。 这就像让一位资深架构师（ChatGPT）和一位高效的工程师（Codex）结对编程。架构师不碰键盘，但给出精确的蓝图；工程师不思考大局，但保证每一次落笔都精准无误。 ## 核心痛点：现有AI编程工具的短板 ### 1. 纯ChatGPT的痛点 - **上下文断裂**：每次复制代码到ChatGPT，再复制回来，上下文丢失严重。 - **无法执行**：ChatGPT不知道你的环境变量、依赖版本、编译错误，它只能“猜”。 - **缺乏反馈循环**：代码出错后，你需要手动把错误信息贴回去，再等它修正，循环极慢。 ### 2. 纯Codex的痛点 - **规划能力弱**：面对“重构整个模块”或“实现一个新功能”这类复杂任务，Codex容易陷入局部优化，忽略全局架构。 - **缺乏高层抽象**：它倾向于直接写代码，而不是先想清楚数据结构、接口设计、边界条件。 - **难以处理模糊需求**：如果用户说“让这个应用更快”，Codex可能只会改几个循环，而不会想到缓存策略、数据库索引或异步化改造。 ### 3. 现有“双模型”方案的痛点 有些方案尝试在同一进程中交替调用GPT和Codex，但存在两个问题： - **上下文共享混乱**：两个模型共享同一对话历史，导致ChatGPT的“思考”和Codex的“行动”混杂在一起，容易产生幻觉。 - **缺乏结构化交接**：没有明确的“计划-执行-反馈”协议，往往ChatGPT说一套，Codex做另一套。 ## 项目架构与工作原理 ### 整体流程 用户输入需求 ↓ [ChatGPT Planner] —— 生成结构化任务清单（JSON格式） ↓ [Codex Worker] —— 逐条执行任务，调用本地工具（文件读写、shell命令） ↓ [执行结果反馈] —— 错误信息、测试输出、git diff 回传给ChatGPT ↓ [ChatGPT 再规划] —— 根据反馈调整计划，进入下一轮迭代 ### 关键技术点 1. **任务清单协议**：ChatGPT输出的是严格的JSON数组，每个元素包含`action`（如`write_file`、`run_command`、`edit_file`）、`path`、`content`或`command`等字段。这种结构化设计避免了自然语言带来的歧义。 2. **双向上下文管理**：ChatGPT只看到“计划”和“反馈”，不直接接触Codex的原始输出；Codex只收到“具体指令”，不接触用户的高层意图。这种隔离防止了模型间的相互干扰。 3. **错误回传机制**：当Codex执行失败时，项目会将完整的错误堆栈、退出码、当前工作目录信息打包，作为新的上下文发送给ChatGPT，让它能基于实际环境重新规划。 4. **增量执行**：Codex每完成一个任务项，就会暂停并等待下一项指令，而不是一次性执行完所有计划。这允许ChatGPT在中间介入调整方向。 ## 安装与快速上手 ### 环境要求 - Node.js 18+（项目使用TypeScript编写） - 已安装并配置好OpenAI CLI（`codex`命令可用） - 有效的OpenAI API Key（同时支持ChatGPT API和Codex API） ### 安装步骤 bash # 1. 克隆仓库 git clone https://github.com/XiaoDuoYa/codex-with-chatgpt.git cd codex-with-chatgpt # 2. 安装依赖 npm install # 3. 配置环境变量 cp .env.example .env # 编辑 .env，填入： # OPENAI_API_KEY=你的API密钥 # OPENAI_MODEL=gpt-4-turbo-preview （或你使用的模型） # 4. 构建项目 npm run build # 5. 运行（以交互模式为例） npm start ### 代码示例：一个实际任务 假设你想让AI帮你重构一个Python脚本，使其支持并发下载。 bash $ npm start > 请输入你的需求： > 重构 download.py，将原来的串行下载改为使用 asyncio 并发下载，并添加重试机制。 [ChatGPT Planner] 正在分析需求... 计划生成： 1. 读取当前 download.py 的内容 2. 分析现有代码结构，识别串行下载部分 3. 设计新的并发架构（asyncio + aiohttp） 4. 重写文件，保留原有函数签名 5. 添加重试逻辑（指数退避） 6. 运行测试验证 [Codex Worker] 正在执行任务 1/6：读取文件... ✓ 已读取 download.py（120行） [Codex Worker] 正在执行任务 2/6：分析代码... ✓ 识别出 3 处串行下载点 [Codex Worker] 正在执行任务 3/6：设计新架构... [ChatGPT Planner] 收到架构建议，确认方案... [Codex Worker] 正在执行任务 4/6：重写文件... ✓ 已生成新版本（145行） [Codex Worker] 正在执行任务 5/6：添加重试逻辑... ✓ 已添加 retry 装饰器 [Codex Worker] 正在执行任务 6/6：运行测试... ✗ 测试失败：async 函数中使用了同步 requests 库 [ChatGPT Planner] 分析错误，调整计划... 新计划： - 将 requests 替换为 aiohttp - 修改所有 await 调用点 [Codex Worker] 执行修正... ✓ 测试通过（2个用例） 任务完成！最终代码已保存。 ## 核心亮点深度解析 ### 1. 真正的“思考-执行”分离 这不是简单的“两个模型串联”，而是通过严格的协议层实现了角色隔离。ChatGPT永远不会直接操作文件系统，Codex永远不会收到模糊的自然语言需求。这种设计带来了三个直接好处： - **减少幻觉**：ChatGPT不会因为“猜测”文件内容而编造代码，它只能基于Codex回传的真实内容做规划。 - **提高可解释性**：每一步都有明确的“计划-执行-验证”记录，你可以随时介入，查看当前AI在做什么，为什么这么做。 - **方便调试**：如果AI走偏了，你可以只修改ChatGPT的计划，而不需要重新生成整个执行过程。 ### 2. 自适应错误处理 传统的AI编程工具遇到错误时，要么直接失败，要么尝试“硬改”。本项目实现了**闭环反馈**： - 当Codex执行失败，错误信息会作为新的输入发送给ChatGPT。 - ChatGPT会重新审视计划，可能改变策略、调整参数、甚至推翻之前的方案。 - 这种“从失败中学习”的能力，使得它能够处理多轮迭代的复杂任务，而不是一次性的代码生成。 ### 3. 轻量级且可定制 项目本身只有约2000行TypeScript代码，没有复杂的框架依赖。这意味着： - 你可以轻松阅读源码，理解其工作原理。 - 你可以修改协议（比如增加新的action类型），扩展其能力。 - 你可以替换底层的“Planner”或“Worker”，比如用Claude替代ChatGPT，或者用其他编码代理替代Codex。 ### 4. 透明的成本控制 由于每次调用都明确区分了“规划”和“执行”，你可以精确控制API调用次数。例如： - 对于简单任务，可以跳过ChatGPT规划，直接让Codex执行。 - 对于复杂任务，可以限制ChatGPT的迭代轮数，防止无限循环。 ## 适用场景 ### 最合适的场景 1. **大型代码库重构**：需要理解全局架构，同时进行大量机械性修改。ChatGPT负责设计重构方案，Codex负责逐文件修改。 2. **跨文件功能实现**：比如“添加一个用户认证模块”，涉及后端路由、前端页面、数据库迁移、测试用例。ChatGPT规划模块间接口，Codex逐层实现。 3. **技术债务清理**：面对遗留系统，ChatGPT分析依赖关系，Codex执行替换和删除。 4. **教学与学习**：你可以观察ChatGPT如何拆解问题，Codex如何执行，学习AI的编程思维。 ### 不太适合的场景 - **单文件小修改**：直接用Codex或Copilot更快，引入这个项目反而增加开销。 - **需要强交互的调试**：如果问题需要频繁人工确认（比如“这个API返回什么？”），目前的自动化流程可能不够灵活。 - **离线环境**：必须依赖OpenAI API，无法完全本地化。 ## 与同类项目对比 | 项目 | 架构 | 核心优势 | 局限性 | |------|------|----------|--------| | **Codex with ChatGPT** | 双模型，严格协议分离 | 规划能力强，错误反馈闭环 | 需要两个API，延迟较高 | | **OpenAI Codex CLI** | 单模型 | 简单直接，执行速度快 | 复杂任务规划弱 | | **Cursor** | IDE集成，多模型 | 交互体验好，上下文丰富 | 封闭生态，不易定制 | | **Aider** | 单模型+Git管理 | 版本控制集成好 | 规划能力取决于底层模型 | | **AutoGPT** | 多代理，自主循环 | 全自动，目标驱动 | 容易失控，成本不可控 | **关键差异**：大多数工具试图让一个模型“既思考又行动”，而本项目刻意分离了这两个角色。这种设计哲学在工程上更接近“主从架构”——主控负责决策，从机负责执行，通过明确定义的接口通信。 ## 实际使用体验与注意事项 ### 优点体验 - **任务拆解清晰**：你能看到ChatGPT是如何把“重构下载脚本”分解为6个具体步骤的，这种透明度有助于建立信任。 - **错误恢复能力强**：在测试中，当Codex遇到Python版本不兼容问题，ChatGPT能快速识别并调整方案，而不是盲目重试。 ### 需要注意的坑 1. **API成本**：每次任务可能消耗2-5次ChatGPT调用和5-10次Codex调用，复杂任务成本更高。建议设置预算上限。 2. **上下文窗口限制**：ChatGPT的上下文窗口（如8K或16K token）可能不足以处理超长代码文件。项目目前没有自动截断或摘要机制，需要手动分块。 3. **Codex的权限控制**：Codex可以执行任意shell命令，这意味着如果提示词注入恶意指令，可能有安全风险。建议在隔离的容器或虚拟机中运行。 4. **版本兼容性**：项目目前依赖OpenAI的特定API版本，如果API更新，可能需要手动调整。 ## 未来展望与改进方向 从项目代码中可以看出，作者留了一些扩展点： - **支持更多Planner**：目前硬编码了ChatGPT，但接口设计可以轻松接入其他LLM。 - **支持自定义工具**：Codex的action类型是开放的，可以添加`git_commit`、`docker_build`等新动作。 - **持久化会话**：目前每个任务是一次性的，未来可以保存对话状态，支持断点续跑。 ## 总结：值得一试吗？ 如果你已经熟悉Codex CLI，并且觉得它在复杂任务上“力不从心”，那么这个项目值得你花一小时尝试。它提供了一种**优雅的工程化思路**——不是让AI更强大，而是让多个AI各司其职，通过协议协作。这种“组合式AI”的哲学，可能是未来AI编程工具的重要方向。 当然，它目前还处于早期阶段（GitHub Stars 514），文档和社区支持有限。但作为一个技术原型，它展示的架构思想远比其当前功能更有价值。 **适合人群**： - 对AI Agent架构感兴趣的开发者 - 需要处理复杂重构任务的专业程序员 - 愿意折腾开源工具的技术爱好者 **不适合人群**： - 追求开箱即用的普通用户 - 对API成本敏感的个人开发者 - 需要GUI界面的非技术用户 --- **项目链接**：https://github.com/XiaoDuoYa/codex-with-chatgpt