我用 GitHub 把 Codex 和 ChatGPT 的上下文打通了。

这件事表面上只是一个工具连接问题，实际上让我对“个人 AI 工作台”有了一个更清楚的理解。

以前我更多是在单独使用不同 AI 工具。ChatGPT 是一个入口，Codex 是一个入口，Claude Code 或其他 coding 工具又是另一个入口。每个工具都很强，但它们之间有一个很大的断点：上下文不连续。

工具越多，断点越多。

一、真正卡住我的不是模型能力，而是上下文断裂

现在很多工作我都已经放到 Codex 里做。

写代码、改项目、梳理文件、推进一个工程任务，Codex 都很适合。它更像一个实际干活的 AI 工程工作台。

但有些事情，我还是更愿意回到 ChatGPT 里处理。

比如：

• 重新判断项目方向；
• 梳理下一步怎么推进；
• 把做过的事情总结成复盘；
• 把一次工具实践沉淀成方法论；
• 把项目过程转成公众号、小红书、博客内容；
• 对一个方案做更高层次的拆解和取舍。

这些事情不是单纯写代码，而是理解、抽象、总结和表达。

ChatGPT 在这类任务上更顺手。

问题也随之出现：

Codex 知道我刚刚做了什么，但 ChatGPT 不知道。

每次从 Codex 切回 ChatGPT，我都要重新解释一遍：这个项目是什么、现在做到哪一步、改了哪些文件、卡在哪个地方、我现在想让它帮我判断什么。

有时候还要复制代码、粘贴文件、补充背景。

这件事非常低效。

因为真正浪费时间的不是问 AI 问题，而是反复搬运上下文。

二、解决思路其实很简单：用 GitHub 做中间层

后来我发现，这个问题不需要很复杂的方案。

程序员每天都在用 GitHub 做版本管理、协作和代码沉淀。既然 Codex 的很多工作本来就围绕代码仓库进行，那完全可以让 GitHub 承担另一个角色：上下文桥。

我的做法是：

1. Codex 负责推进项目和修改文件。
2. 关键工作现场同步到 GitHub。
3. ChatGPT 通过 GitHub 读取相关仓库内容。
4. ChatGPT 基于这些真实上下文继续做总结、拆解、复盘和内容沉淀。

这样，ChatGPT 就不再是一个完全孤立的聊天窗口。

它可以接上我在 Codex 里的工作现场。

当然，这不是说 ChatGPT 可以“实时读取 Codex 本地工作区”。更准确的说法是：我把 Codex 的关键工作现场同步到 GitHub，再让 ChatGPT 通过 GitHub 读取这些上下文。

这个区别很重要。

它不是魔法，也不是完全实时的远程控制，而是一种更可控、更稳定的上下文同步方式。

三、GitHub 不只是代码仓库，也可以是 AI 上下文层

过去我对 GitHub 的理解主要是代码仓库。

现在我开始把它看成个人 AI 工作台里的“上下文层”。

因为 AI 真正要帮你持续工作，必须知道几件事：

• 这个项目的目标是什么；
• 当前做到哪一步；
• 最近发生了什么变化；
• 哪些决策已经做过；
• 哪些问题还没有解决；
• 接下来希望 AI 帮你判断什么。

如果这些信息只存在你的脑子里，或者散落在聊天记录里，AI 每次都要重新理解。

但如果这些信息被结构化写进仓库，任何一个能读取仓库上下文的 AI，都能更快进入现场。

所以我现在倾向于在每个重要项目里增加一个专门给 AI 看的目录：

1
2
3
4
5
6
7

_ai_context/
  PROJECT_BRIEF.md
  CURRENT_STATE.md
  DECISIONS.md
  TASKS.md
  CHANGELOG_FOR_AI.md
  ASK_CHATGPT.md

每个文件的作用很简单：

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”，而是“把关键上下文结构化”。

八、我接下来会继续完善什么

这次只是第一步。

接下来我会继续完善几件事：

1. 给重要项目建立统一的 _ai_context/ 目录。
2. 让 Codex 在阶段性完成任务后，自动更新当前状态和变更摘要。
3. 让 ChatGPT 读取这些上下文后，继续做复盘、选题和方法论提炼。
4. 把可沉淀内容同步进入 Obsidian。
5. 定期从 Obsidian 里筛选内容，发布到博客、公众号和小红书。

这会形成一条完整链路：

1
2
3
4
5
6

Codex 工作现场
→ GitHub 上下文同步
→ ChatGPT 思考复盘
→ Obsidian 知识沉淀
→ 博客/公众号/小红书发布
→ 反馈再回到项目

这条链路对我来说，比单独使用某一个 AI 工具更重要。

因为它解决的不是一次任务，而是长期工作方式。

九、结尾

现在很多人讨论 AI 工具时，仍然习惯问：哪个模型更强？哪个工具更便宜？哪个 coding plan 更划算？

这些问题当然有价值。

但对我来说，更关键的问题已经变成了：

我的工作现场能不能被持续记录？

不同 AI 能不能围绕同一个上下文接力？

每天做过的事情能不能沉淀成长期资产？

如果不能，那再强的工具也只是一次性使用。

如果可以，AI 才真正开始变成工作台。

这次用 GitHub 打通 Codex 和 ChatGPT，并不复杂。

但它让我意识到：

个人 AI 工作台真正升级的关键，不是多开几个工具，而是让工具之间共享同一个结构化工作现场。

我的经验是，先回答模型，往往会把问题带偏。真正该先想清楚的，通常是下面四件事。

一、先选场景，不先选模型

不是所有流程都适合 AI。真正值得先做的，通常具备几个特征：

• 结果可判断，不是纯主观工作；
• 业务频次足够高，有重复劳动；
• 输入信息相对稳定，能整理成规则或样本；
• 出错成本可控，能先做小范围验证。

如果场景本身不清楚，再强的模型也只是增加试错成本。

二、先看流程，再看能力

很多项目失败，不是模型不行，而是流程没整理好。

你需要先弄清楚：

• 这一步是谁在做；
• 这一步的输入是什么；
• 这一步输出给谁用；
• 这一步哪里最耗时、最容易错。

当流程图画清楚以后，AI 才知道应该插在哪一段，而不是一上来就追求“全自动”。

三、先准备数据，再谈效果

企业里最常见的问题不是“有没有模型”，而是“有没有能用的数据”。

数据不一定要很多，但至少要回答：

• 哪些信息能稳定拿到；
• 哪些内容是结构化的；
• 哪些历史结果可以作为参考；
• 哪些地方涉及敏感信息，需要先处理边界。

如果数据基础薄弱，最好的做法往往不是立刻上线，而是先把采集、整理和权限边界补起来。

四、先定义验证标准，再决定投入

AI 项目不能只看“感觉不错”，要看能不能验证。

我通常会建议团队先定义三个指标：

1. 是否能节省时间；
2. 是否能提升一致性；
3. 是否能降低关键错误率。

只要这三个方向里有一个明显改善，项目就值得继续推进。反过来，如果连验证标准都没有，后面很容易变成演示型项目。

结语

企业做 AI 落地，最重要的不是“先上什么”，而是“先把问题定义对”。

如果你把场景、流程、数据和验证标准先理顺，模型选择反而会简单很多。

我后面会继续写一些更偏企业实战的内容：怎么判断场景、怎么组织试点、怎么把 AI 方案写给业务团队看。

如果你的目标是让企业团队愿意看、愿意转发、愿意讨论，内容结构要换一套。

一、先写业务问题，再写技术方案

开头不要直接讲模型、参数、框架。

更有效的写法是先讲：

• 这类问题在企业里怎么出现；
• 现有做法为什么不够好；
• 如果继续拖着不改，会浪费什么。

先把问题说透，读者才愿意继续往下看。

二、把“能做什么”写成“适合谁”

企业团队最关心的不是“AI 很强”，而是“它适合我吗”。

所以你在写方案时，要尽量回答：

• 哪些团队适合先试；
• 哪些环节最容易出效果；
• 哪些情况不建议上；
• 需要多少配合成本。

这类表达会比单纯列功能更有说服力。

三、把步骤写清楚，但不要写成说明书

企业读者喜欢明确，但不一定喜欢冗长。

可以用下面这种结构：

1. 场景是什么；
2. 为什么值得做；
3. 怎么试；
4. 如何验证；
5. 下一步怎么扩。

这样既保留技术深度，又不会把文章写成配置说明。

四、留下决策入口

一篇好的方案分享，最后应该让读者知道下一步是什么。

你可以在结尾放这几类信息：

• 适合先从哪个环节开始；
• 试点周期大概多长；
• 需要哪些角色参与；
• 如果要做下一版，应该补什么材料。

这样文章不只是“分享观点”，而是能推动行动。

结语

面向企业的 AI 内容，核心不是把技术讲得最满，而是把判断讲得最清楚。

能帮助读者看懂价值、看懂边界、看懂下一步，这样的内容才更接近方案分享，而不是单纯的技术笔记。