视频摘要：Cloud Code 与 GitHub 的高效开发工作流

作者介绍了一套结合 Cloud Code 和 GitHub 的软件开发工作流，该流程遵循经典的软件开发生命周期（SDLC）：规划 (Plan) -> 创建 (Create) -> 测试 (Test) -> 部署 (Deploy)。

• 规划 (Plan): 为所有待办工作创建精细的 GitHub Issues。
• 创建 (Create): 在 Cloud Code 中使用自定义的 Slash Command，指示 AI 首先使用“草稿本”(Scratchpads) 来规划工作、拆分任务，然后再编写代码。
• 测试 (Test): AI 通过两种方式测试其工作：1) 运行项目已有的测试套件；2) 使用 Puppeteer 在浏览器中模拟点击，以验证UI变更。
• 部署 (Deploy): AI 将代码提交到 GitHub 并创建一个拉取请求 (Pull Request)，经过审查（人工或由另一个AI审查）后，合并到主分支，触发自动部署。

• AI时代的“旧瓶装新酒”: 作者坦言这套流程并非全新发明，而是将软件行业早已熟知的 GitHub Flow 工作模式应用于 AI 协作。 [00:02:26]
• 角色的转变: 在这个工作流中，作者的角色从“代码编写者”转变为“工程经理”。大部分时间用于编写详细的需求（Issues）、审查AI生成的代码，而不是亲自写码。 [00:04:27]
• 框架选择: 作者选择了 Ruby on Rails，因为它基于MVC（模型-视图-控制器）架构。 他认为这种模块化的代码库结构，比单一巨大的文件（如 `main.py`）更有利于 AI 编程助手理解和操作。 [00:05:35]

坚实的基础是高效迭代的关键。

• 创建极其具体的 Issues: 最初的失败经验表明，直接让 AI 处理宽泛的需求是行不通的。必须投入时间将任务分解成“粒度更细、更具体、更原子化”的 GitHub Issues。 [00:04:02]
• 安装 GitHub CLI: 这是 Anthropic 推荐的方式，让 Cloud Code 可以通过 Bash 命令 (gh) 与 GitHub 交互。 [00:03:19]
• 优先建立测试体系: 在开发功能前，先让 AI 建立起测试套件和持续集成 (CI)。作者使用 GitHub Actions 在每次提交时自动运行测试和Linter。 [00:05:10]
• 配置 Puppeteer: 设置 Puppeteer 本地 MCP 服务器，使 Cloud Code 能够控制一个真实的浏览器来测试UI，例如点击按钮或填写表单，这非常直观且有效。 [00:06:08]

• 自定义 Slash Command: 核心驱动力是一个自定义的斜杠命令（如 /process_issue），它本质上是一个高度优化的 Prompt 模版，详细指导 AI 如何分四步（规划、编码、测试、部署）处理一个 Issue。 [00:07:00]
• 利用草稿本 (Scratchpads): 在命令中，明确要求 AI 在正式编码前，先在特定目录（草稿本）中制定详细计划，并将大任务拆分为小步骤。 [00:07:51]
• 关于代码提交的责任: 作者引用了 Thomas Ptacek 的观点：“你永远要为你合并到主分支的代码负责”。 尽管如此，作者承认自己在这个项目中变得“懒惰”，会让 Cloud Code 自动完成代码提交 (commit)。 [00:09:42, 00:10:27]
• 测试的信心: 完备的测试让他有信心授权 AI 提交代码。目标不是100%的代码覆盖率，而是“高度自信”AI在开发新功能时不会破坏旧功能。 [00:11:03]

• 自动部署: 作者使用 Render 平台，它会监控 GitHub 主分支的变动，一旦有新的合并，就自动部署应用。因此，“合并PR”约等于“上线生产环境”。 [00:11:26]
• PR 是人类的关键介入点: 拉取请求 (Pull Request) 是你审查、评论和否决 AI 工作的最佳时机。 [00:12:07]
• 用 AI 审查 AI: 可以创建另一个 Slash Command（如 /review_pr）来让 Cloud Code 审查它自己或其他 AI 创建的 PR。作者会让 AI 模仿 Rails 社区英雄 Sandi Metz 的风格进行审查，以发现代码中可维护性和可读性的问题。 [00:12:33]
• 保持上下文纯净: 每个 Issue 处理完毕并合并PR后，作者会运行 /clear 命令彻底清空上下文窗口。 这能确保 AI 以“冷启动”状态处理下一个独立的任务，从而获得更好的结果并节省 Token。 [00:14:16]

• Cloud Code Console vs. GitHub Actions: 作者不常用 Anthropic 推出的 GitHub Actions 集成，主要原因是：1) 即使订阅了昂贵的 Claude Max 套餐，通过 Actions 调用仍需按 API 使用量额外付费。2) 他认为在 Console 中能获得更好的洞察和结果。 [00:15:01]
• 对 Git Worktrees 的看法: Git Worktrees 允许并行运行多个 Cloud Code 实例处理不同任务，就像打多桌扑克。 但作者尝试后发现：1) 早期项目任务依赖性强，难以并行。2) 每次创建新 worktree 都要重新授权，过程繁琐，感觉更像是在“带孩子”，因此放弃了。 [00:16:25]