我用 GitHub 打通 Codex 和 ChatGPT 上下文
最近我解决了一个很小，但对我很关键的问题：
我用 GitHub 把 Codex 和 ChatGPT 的上下文打通了。
这件事表面上只是一个工具连接问题，实际上让我对“个人 AI 工作台”有了一个更清楚的理解。
以前我更多是在单独使用不同 AI 工具。ChatGPT 是一个入口，Codex 是一个入口，Claude Code 或其他 coding 工具又是另一个入口。每个工具都很强，但它们之间有一个很大的断点：上下文不连续。
工具越多，断点越多。
一、真正卡住我的不是模型能力，而是上下文断裂
现在很多工作我都已经放到 Codex 里做。
写代码、改项目、梳理文件、推进一个工程任务，Codex 都很适合。它更像一个实际干活的 AI 工程工作台。
但有些事情，我还是更愿意回到 ChatGPT 里处理。
比如：
- 重新判断项目方向；
- 梳理下一步怎么推进；
- 把做过的事情总结成复盘；
- 把一次工具实践沉淀成方法论；
- 把项目过程转成公众号、小红书、博客内容；
- 对一个方案做更高层次的拆解和取舍。
这些事情不是单纯写代码，而是理解、抽象、总结和表达。
ChatGPT 在这类任务上更顺手。
问题也随之出现：
Codex 知道我刚刚做了什么，但 ChatGPT 不知道。
每次从 Codex 切回 ChatGPT，我都要重新解释一遍：这个项目是什么、现在做到哪一步、改了哪些文件、卡在哪个地方、我现在想让它帮我判断什么。
有时候还要复制代码、粘贴文件、补充背景。
这件事非常低效。
因为真正浪费时间的不是问 AI 问题，而是反复搬运上下文。
二、解决思路其实很简单：用 GitHub 做中间层
后来我发现，这个问题不需要很复杂的方案。
程序员每天都在用 GitHub 做版本管理、协作和代码沉淀。既然 Codex 的很多工作本来就围绕代码仓库进行，那完全可以让 GitHub 承担另一个角色：上下文桥。
我的做法是：
- Codex 负责推进项目和修改文件。
- 关键工作现场同步到 GitHub。
- ChatGPT 通过 GitHub 读取相关仓库内容。
- ChatGPT 基于这些真实上下文继续做总结、拆解、复盘和内容沉淀。
这样，ChatGPT 就不再是一个完全孤立的聊天窗口。
它可以接上我在 Codex 里的工作现场。
当然，这不是说 ChatGPT 可以“实时读取 Codex 本地工作区”。更准确的说法是：我把 Codex 的关键工作现场同步到 GitHub，再让 ChatGPT 通过 GitHub 读取这些上下文。
这个区别很重要。
它不是魔法，也不是完全实时的远程控制，而是一种更可控、更稳定的上下文同步方式。
三、GitHub 不只是代码仓库，也可以是 AI 上下文层
过去我对 GitHub 的理解主要是代码仓库。
现在我开始把它看成个人 AI 工作台里的“上下文层”。
因为 AI 真正要帮你持续工作，必须知道几件事：
- 这个项目的目标是什么；
- 当前做到哪一步；
- 最近发生了什么变化；
- 哪些决策已经做过；
- 哪些问题还没有解决；
- 接下来希望 AI 帮你判断什么。
如果这些信息只存在你的脑子里，或者散落在聊天记录里，AI 每次都要重新理解。
但如果这些信息被结构化写进仓库，任何一个能读取仓库上下文的 AI，都能更快进入现场。
所以我现在倾向于在每个重要项目里增加一个专门给 AI 看的目录：
1 | _ai_context/ |
每个文件的作用很简单：
PROJECT_BRIEF.md 记录项目目标、背景、约束和技术栈。
CURRENT_STATE.md 记录当前做到哪一步、最近改了什么、现在卡在哪里。
DECISIONS.md 记录关键决策，尤其是为什么选 A、不选 B。
TASKS.md 记录待办事项和优先级。
CHANGELOG_FOR_AI.md 不一定等同于普通 changelog，而是写给 AI 看的阶段性变化摘要。
ASK_CHATGPT.md 记录我希望 ChatGPT 接手思考的问题。
这样设计之后，仓库就不只是给人看的，也不是只给编译器看的，而是给 AI 接力用的。
四、我的 AI 工作台分成四层
这次打通之后，我对自己的 AI 工作台有了一个更清晰的分层。
第一层是执行层：Codex。
它负责具体工程任务，比如写代码、改文件、跑流程、实现一个 Demo。
第二层是上下文层：GitHub。
它负责保存项目现场、版本变化、关键文档和 AI 可读取的上下文。
第三层是思考层：ChatGPT。
它负责判断方向、拆解问题、总结复盘、提炼方法论、生成内容草稿。
第四层是资产层：Obsidian。
它负责把一次次项目实践、工具使用、内容选题、方法论沉淀成长期知识资产。
用一句话概括：
Codex 负责生产现场，GitHub 负责沉淀现场，ChatGPT 负责理解现场，Obsidian 负责长期资产化。
这个分层对我很重要。
因为它让我不再纠结“到底哪个 AI 工具更强”。
不同工具不是简单替代关系，而是承担不同职责。
如果所有事情都塞给一个工具，反而容易混乱。
五、这件事真正改变的是工作方式
打通上下文之后，最明显的变化是：我不需要每次从零开始解释。
以前我问 ChatGPT：
“帮我看看这个项目下一步怎么做。”
它没有足够上下文，只能给一堆泛泛建议。
现在我可以让它读取项目里的当前状态、决策记录和任务列表，再基于真实现场判断：
- 哪些事情应该继续做；
- 哪些事情已经偏离主线；
- 哪些内容适合沉淀成博客；
- 哪些内容适合发小红书；
- 哪些只是过程记录，不值得公开；
- 哪些可以继续包装成方法论或服务。
这和普通聊天的差别很大。
普通聊天是一次性的。
有上下文的 AI 工作台是连续的。
连续性，才是 AI 工具真正进入工作流的前提。
六、上下文打通之后，内容也更容易沉淀
这个方案对我的另一个价值，是内容沉淀。
我现在越来越觉得，内容不是坐在那里硬想出来的。
真正有价值的内容，应该从真实工作现场里长出来。
比如这次 Codex 和 ChatGPT 的上下文打通，本身就是一次真实问题的解决：
问题是真实的：不同 AI 工具之间上下文断裂。
场景是真实的：日常项目越来越多发生在 Codex 里。
方案是真实的：用 GitHub 做中间上下文层。
方法是可复用的：为每个项目维护 _ai_context/ 目录。
这就自然可以沉淀成一篇博客、一条小红书、一篇公众号，甚至是一套个人 AI 工作台方法论。
所以我现在做内容的逻辑也开始变化：
不是先想“我要写什么”，而是先问：
我最近真实解决了什么问题？
这个问题是不是别人也会遇到？
我的解决方案能不能抽象成一个流程？
这个流程能不能被复用？
如果答案是肯定的，它就值得沉淀。
七、这套方法的边界
这套方案并不是没有边界。
首先，它不等于实时同步。
GitHub 仓库更新、索引、读取都可能存在延迟，所以它更适合做阶段性工作现场同步，而不是秒级实时协作。
其次，它不适合放敏感信息。
公司代码、客户数据、接口信息、日志、数据库导出、API Key、Token、.env 文件，都不应该进入可被 AI 读取的上下文仓库。
即使是私有仓库，也要保持最小授权和脱敏原则。
再次，不能只把代码丢给 AI。
如果仓库里只有零散代码，没有项目目标、当前状态、决策记录和下一步问题，AI 依然很难理解你真正想做什么。
所以重点不是“把更多东西丢进 GitHub”，而是“把关键上下文结构化”。
八、我接下来会继续完善什么
这次只是第一步。
接下来我会继续完善几件事：
- 给重要项目建立统一的
_ai_context/目录。 - 让 Codex 在阶段性完成任务后，自动更新当前状态和变更摘要。
- 让 ChatGPT 读取这些上下文后，继续做复盘、选题和方法论提炼。
- 把可沉淀内容同步进入 Obsidian。
- 定期从 Obsidian 里筛选内容，发布到博客、公众号和小红书。
这会形成一条完整链路：
1 | Codex 工作现场 |
这条链路对我来说，比单独使用某一个 AI 工具更重要。
因为它解决的不是一次任务，而是长期工作方式。
九、结尾
现在很多人讨论 AI 工具时，仍然习惯问：哪个模型更强？哪个工具更便宜？哪个 coding plan 更划算？
这些问题当然有价值。
但对我来说，更关键的问题已经变成了：
我的工作现场能不能被持续记录？
不同 AI 能不能围绕同一个上下文接力？
每天做过的事情能不能沉淀成长期资产？
如果不能，那再强的工具也只是一次性使用。
如果可以，AI 才真正开始变成工作台。
这次用 GitHub 打通 Codex 和 ChatGPT，并不复杂。
但它让我意识到：
个人 AI 工作台真正升级的关键，不是多开几个工具，而是让工具之间共享同一个结构化工作现场。