最近我一直在推进 A Tour of Go 多语言翻译项目。
项目仓库为 go-tour-i18n，第一阶段先完成简体中文 zh-CN。到目前为止，103 个正式发布页面的自动翻译和结构校验已经全部完成，接下来开始进入发布前的正文质量审核。
这一阶段，我原本还是按照之前的协作方式：
- Codex 负责读取仓库、执行命令、修改代码和运行测试；
- ChatGPT 负责分析方案、审核译文和判断是否需要调整；
- 如果 ChatGPT 需要了解仓库中的实际内容，我再把 Codex 的输出复制到 ChatGPT。
这种方式能够正常工作，但当审核范围从几个代表页面扩大到 103 个完整课程页面之后，一个问题越来越明显：
如果 ChatGPT 本身不能直接读取 GitHub 仓库，那么大量时间都会花在我手工转发 Codex 输出上。
刚好在这次审核过程中，我发现当前使用的 ChatGPT 已经可以直接连接 GitHub。
于是我决定先暂停正文审核，试着把 GitHub 接进来。
一、为什么这时候才想到连接 GitHub
之前开发 go-tour-i18n 时，Codex 一直很适合处理仓库级任务。
例如：
- 搜索源码；
- 修改 Go 代码；
- 调整保护规则；
- 运行测试；
- 检查 Git diff；
- 提交代码。
而 ChatGPT 更适合做另一类事情：
- 判断中文翻译是否自然；
- 对比英文原文与中文译文；
- 分析一个失败究竟属于模型问题还是校验器问题；
- 讨论项目架构；
- 整理 Codex 下一步应该执行的任务。
两者的分工其实一直比较清楚。
问题在于，当 ChatGPT 要审核仓库里的真实内容时，我过去经常需要经过这样一层：
GitHub / 本地仓库
↓
Codex
↓
Codex 输出结果
↓
我手工复制
↓
ChatGPT
对于单个页面，这没有多大问题。
但发布前我要逐页审核 103 个页面，如果每一批都先让 Codex 输出完整内容，再由我复制回来，整个过程会明显变得繁琐。
所以当 ChatGPT 提示可以连接 GitHub 时，我决定先把这个问题解决掉。
这里我的目标并不是让 ChatGPT 接管 Codex。
恰恰相反，我希望保留原来的职责分工，只是让 ChatGPT 多获得一种能力：
在需要审核时，可以直接读取 GitHub 中的真实仓库内容。
二、连接过程中先遇到了 MFA
点击连接以后，并没有立即进入 GitHub 仓库授权。
我的这次连接流程首先提示：
需要启用多因素身份验证（MFA）
我之前没有为这次连接准备好多因素身份验证，所以这里又多了一步身份验证器配置。
完成这一步以后，才能继续后面的 GitHub 授权流程。
不同账号原来的 GitHub 安全设置不同，实际连接时看到的步骤也可能并不完全一样。因此这里记录的主要是我这次实际操作时遇到的流程，而不是说所有账号连接 GitHub 时都会经历完全相同的步骤。
三、进入 GitHub 的安装和授权页面
完成前面的身份验证以后，进入 GitHub 的应用安装和授权页面。
这里才是我认为整个连接过程中最值得认真看的一步。
页面中可以选择：
All repositoriesOnly select repositories
也就是：
允许访问全部仓库，还是只允许访问指定仓库。
我这次截图中选择的是全部仓库，这是我当时实际操作的状态。
不过如果只是希望 ChatGPT 协助分析某一个项目，其实也可以根据自己的实际需求，只开放需要使用的仓库。
除了仓库范围之外，页面中还能看到应用申请的具体权限。
所以在授权时，我认为比较值得留意的并不只是“能不能连接成功”，还有：
- 它能够访问哪些仓库；
- 它申请了哪些权限；
- 当前选择的授权范围是否符合自己的实际需求。
这也是我觉得这次操作值得单独记录下来的原因。
连接一个开发工具并不只是：
点“连接” → 完成。
中间实际上还包含了一次比较具体的权限选择。
四、连接完成
授权完成以后重新回到 ChatGPT，原来的 GitHub 卡片已经从：
连接
变成：
已连接
到了这里，我没有马上让 ChatGPT 修改任何仓库内容。
我的第一反应反而是：
先验证它到底能不能正确读取
go-tour-i18n。
因为“界面显示已连接”和“实际能够准确读取当前项目仓库”，是两件不同的事情。
而且我这次连接 GitHub 的目的，本来就不是为了增加一个新的自动改代码入口。
我最需要的是：
让 ChatGPT 能够直接看到它正在审核的真实材料。
这刚好也和我目前实际采用的分工比较吻合。
五、连接 GitHub 以后，项目协作方式发生了什么变化
连接之前，我的工作流更接近：
Codex 读取仓库
↓
输出文件内容和结果
↓
我复制给 ChatGPT
↓
ChatGPT 审核
↓
再整理指令给 Codex
连接以后，可以简化成：
GitHub 仓库
↙ ↘
Codex ChatGPT
修改执行 直接只读审核
↘ ↙
我做最终决策
这里最重要的变化并不是“少复制几次文字”。
更重要的是：
ChatGPT 可以直接依据仓库中的真实文件做判断，而不只是依据我从另一个工具复制回来的一小段结果。
例如这次 A Tour of Go 中文正文审核，我需要同时查看：
- 官方英文
.article； - 对应的 zh-CN candidate；
- glossary；
- protected token 规则；
- 不同页面之间的术语一致性。
如果这些内容都必须先通过 Codex 转述一次，再交给 ChatGPT，信息链条会比较长。
能够直接访问 GitHub 后，ChatGPT 可以自行读取需要的文件，我只需要决定：
下一批审核什么。
对于这种需要持续维护的长期项目，这一点尤其有用。
六、但我并不打算因此放弃 Codex
连接成功之后，我反而更加确定：
ChatGPT 和 Codex 没有必要互相替代。
至少在当前这个项目里，我更喜欢这样的职责划分。
ChatGPT
负责：
- 翻译质量审核；
- 英文与中文语义比较；
- 术语判断；
- 架构讨论；
- 异常原因分析；
- 修改方案审核；
- 给 Codex 整理受控执行指令。
Codex
负责：
- 仓库级搜索；
- 精确修改文件；
- 执行 Go 测试；
- 运行 validator；
- 检查 Git diff；
- 提交和推送。
GitHub 连接解决的只是两者之间过去存在的一道信息传递障碍。
它并没有改变一个我一直比较重视的原则：
负责判断的工具和负责执行修改的工具，可以各自发挥最擅长的能力。
七、连接后的第一次实际用途：审核 A Tour of Go 中文译文
完成 GitHub 连接之后，我没有先拿它测试一个无关的小仓库。
下一步直接回到了正在进行的 go-tour-i18n：
逐页审核 103 个中文课程页面。
这也是这次连接 GitHub 最直接的一次实际验证。
以前如果要做这种审核，我通常需要让 Codex 先读取英文源码和中文 candidate，再把结果返回，我复制给 ChatGPT。
这一次，ChatGPT 可以直接从 GitHub 仓库读取冻结基线中的英文源码和对应中文译文，然后按页面逐批进行只读审计。
不过真正开始审核以后，又出现了两个很值得单独记录的问题。
第一个是：
channel到底应该翻译成“通道”“管道”“信道”，还是直接保留Channel？
原本只是一个页面中的术语问题，最后却演变成了一次比预想中更系统的 Go 中文技术术语校准。
第二个则是：
103 页全部检查完成以后，到底有多少页面真的值得修改？
结果也和我一开始想象的不太一样。
所以这两个主题我准备分别再写两篇文章：
- A Tour of Go 中文术语统一：为什么
channel最终选择“通道” - 103 页逐页审核后，只返修 16 页：A Tour of Go 中文正文发布前质量审计
这样本文只解决一个问题：
怎样让 ChatGPT 直接连接 GitHub，并把这种能力加入现有的项目协作流程。
八、总结
以前我更多把 ChatGPT 当成一个：
需要我把材料提供给它的审核者。
这次连接 GitHub 后，一个明显的变化是：
仓库里的材料可以由 ChatGPT 自己读取。
对于一次性的问答，这个变化可能没有多大感觉。
但对于 go-tour-i18n 这种需要长期维护、持续同步上游、反复审核翻译和代码的项目，它能够明显缩短原来的信息链：
仓库
→ Codex
→ 我
→ ChatGPT
与此同时，我暂时仍然不会让这种连接改变当前的基本分工：
ChatGPT 负责分析与审核，Codex 负责仓库级修改、测试和提交。
所以这次 GitHub 连接对我来说，更像是给 ChatGPT 补上了一双能够直接查看仓库的“眼睛”。
它仍然负责判断，但不再需要我把每一份材料都手工搬到它面前。
而连接完成之后进行的第一次完整任务，就是：
103 个 A Tour of Go 中文课程页面的发布前质量审计。
下一篇，我准备先从其中意外冒出来的一个问题开始：
channel，在中文 Go 世界里到底应该叫什么？
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复