← 所有文章
AI工具

AI工具日常使用（二）— 项目协同（大纲与拓展思路）

**作者：**三行脚印

本文是「AI工具日常使用」系列第二篇的大纲与拓展思路。第一篇讲工具选型，这篇聚焦 「一个人用多个AI工具做项目时，怎么把代码、文件、进度、上下文管起来」。

一、GitHub 的作用（你已写的部分）

核心一句话：GitHub 不只是代码仓库，它是你所有AI工具之间的共享硬盘。

1.1 代码托管

所有代码放 Git 托管——这是基础。不赘述。

1.2 README = 进度条（重点展开）

传统 README 是给人看的文档，但在这个工作流里，README 首先是给 AI 看的指令文件。

  • 你在 README 里写的不只是”项目说明”，而是**“当前进度”**——做到哪一步了、下一个要让 AI 做什么、卡在哪
  • 这样不管切到哪个 AI（Claude / Codex / Cursor）、哪台电脑，打开 README 就知道接哪根线

推荐模板（HANDOFF 段落）：

## Handoff
Previous AI: [Claude Code / Codex / Cursor]
Last Action: [完成了什么，写到什么进度]
Next Action: [下一步要做什么]
Status: [功能A 80%｜测试 0%｜已知问题：XXX]
Constraints: [不要重构XXX，不要改XXX文件]

1.3 Git Commit = 状态存档点

  • 每次从一个 AI 切到另一个 AI 之前，先 commit。commit message 写清楚当前状态
  • 切过来先 pull，再读 README，再开干
  • 习惯养成了，你就永远不会问”刚才那个 AI 做到哪了”

💡 **实践建议：**如果觉得 commit 太频繁，可以用 git commit --allow-empty -m "wip: 说明"——commit 只作为存档点，后面 squash 再合并。

二、文件分仓策略（从群聊延伸）

你群聊里说的「代码放 git，项目文件放飞书，大文件放本地」——这个原则值得大书特书。

文件类型存放位置理由
代码GitHub所有 AI 工具原生支持 Git，API 读写最成熟
文档 / 表格 / 图片飞书 / Notion协作友好，AI 也能通过 API 读。而且飞书自带版本历史
长视频 / 大模型文件 / 数据集本地 / 网盘AI 用不上这些文件，不上传、不占额度、不污染 Git 仓库

**一个原则：**问自己”这个文件 AI 需不需要读？“——需要 → Git 或飞书；不需要 → 本地。

三、跨设备 / 跨 AI 的无缝接力（核心痛点）

这是群里晓东最感兴趣的部分，也是你这篇文章最有价值的地方——市面上几乎没人讲过。

3.1 跨终端：MAX 账户 ↔ PRO 账户

  • 你的 Claude Pro 额度用完了，但 MAX 账户还有余额——怎么办？
  • **解法：**Git 仓库是唯一真相源（Single Source of Truth）。谁有空谁接盘，接盘前先 git pull + 看 README
  • 关键不是账户切换，而是 上下文怎么不丢

3.2 跨电脑：工作电脑 ↔ 家里服务器

  • 公司写了一半回家继续，或者反之
  • **必要条件：**两边都能访问同一个 Git remote。SSH key 配好，GitHub CLI 装好
  • 可以顺便写一段基础配置指南（很多人卡在这一步）

3.3 跨 AI 平台：Claude ↔ Codex ↔ Cursor（最核心）

这是最大的卖点，也是最大的坑。

核心约束：AI 和 AI 之间不直接对话。它们只通过代码和 README 交流。

这意味着：

  • Claude 改完的文件，Codex 再来改——怎么避免冲突？
  • 一个 AI 创建了一个新文件，另一个 AI 不知道——怎么同步认知？
  • 一个 AI 有完整的项目理解，另一个 AI 从零开始——怎么传递上下文？

解法（你可以展开的三个实操技巧）：

  1. README Handoff Block（刚才说的）——明确写 Last Action / Next Action / Completed / Blockers
  2. 约定文件所有权——比如”前端文件只用 Claude，后端文件只用 Codex”，减少冲突面
  3. 一个 AI 只做一个 Feature——按功能分支切分，AI-A 做完 feature-A 合并后，AI-B 再拉最新代码做 feature-B

💡 你可能会遇到的具体问题：

  • 同一个文件被两个 AI 同时改 → Git 冲突，你必须手动解决
  • AI-B 不知道 AI-A 新建的目录结构 → README 里写清楚目录结构
  • AI-B 不理解 AI-A 的编码风格 → 项目根目录放 CLAUDE.md / .cursorrules 统一约束

四、API Key = 遥控器

你在群里说了”GitHub / Vercel / Cloudflare 都可以让 Claude 通过 API Key 操作，大部分时候只需要申请一个 key”——这个点值得展开。

4.1 三个平台的实操场景

平台能干什么需要什么
GitHubAI 直接提 PR、Merge、创建 Issue、创建 RepoGitHub Token（经典 PAT 或 Fine-grained）
VercelAI 自动部署 Preview、查看日志、改环境变量Vercel Token（在 Settings → Tokens 创建）
CloudflareAI 管理 DNS、部署 Workers、操作 PagesCloudflare API Token

4.2 配置方式（写点实用代码）

Claude Code / Codex 都支持在项目根目录放一个配置文件，把 API Key 放进去。或者用环境变量也能做到。这里你可以在文章里给一个配置文件模板。

4.3 安全提醒

🔥 重要：

  • 不要把 Token 写进 Git 仓库（至少 .gitignore 掉）
  • GitHub Token 用 Fine-grained PAT，只给最小权限（比如只给一个 Repo 的读写权限）
  • Vercel / Cloudflare Token 也一样——需要什么权限给什么权限
  • 考虑用一个 .env.local 文件统一管理，.gitignore 里加好

五、你已暴露的”坑”（群聊里你说过”这个我文章忘记写了”）

这才是文章最有价值的地方——真实的经验。

你可以考虑写的坑：

  • **坑 1：**README 格式不对导致 AI 读错了进度——后来怎么统一格式
  • **坑 2：**跨 AI 时上下文不共享，AI 做了重复劳动——后来用 Handoff Block 解决
  • **坑 3：**文件太大 push 不上去——后来定分仓策略
  • **坑 4：**Git 冲突时 AI 不会解决，只能人肉来——所以约定”一个 AI 一个 Feature”
  • **坑 5：**Token 泄露了一次（如果你遇到过）——教训和经验

六、进阶方向（可以放在文末作为”未来预告”）

  • **AI + CI/CD：**让 Claude 自动提 PR → GitHub Action 自动测试 → Vercel 自动部署
  • **LLM 作为代码评审：**每次 PR 自动让 AI review，形成闭环
  • **自动化日报：**Cron job 每天拉 Git log，汇总前一天 AI 做了什么

但这些是第三篇的内容了，第二篇先讲明白上面五件事就够了。

七、文章建议

写作策略：

  • **一条主线：**GitHub 是中心 → 文件分仓 → 跨 AI 接力 → API Key 遥控 → 踩坑经验
  • 重点写「跨 AI 平台接力」——这是别人没写过的，也是群里晓东最感兴趣的部分
  • 每个 Section 用”我的做法 + 为什么这样 + 替代方案不香在哪”——就是你平时说话的风格
  • **结构清晰但不教条：**先给结论，再展开细节，跟你在群里说话一样

📝 总结：这篇文章的独特价值不在于”怎么用 Git”或”怎么配 API Key”，而在于它讲清楚了 一个人、多个 AI、多台设备、跨平台的协同框架。这个框架的核心是四个字：「以 Git 为信」——所有 AI 都通过 Git 交流，README 就是它们之间的黑话本。

评论