自动化开发：我是如何把自己从开发流程中“剔除”的

背景

作者并非极端的 AI 拥护者，也不是 AI 末日论者。他承认自己与 AI 的关系充满矛盾，但核心驱动力在于“创造”。他接受一个事实：在创造出任何东西之前，必须先经历混乱。对于 AI 辅助开发（特别是 Claude Code），他认为必须通过实际使用来探索其可能性、局限性，并找到属于自己的工作流。

此前已有许多文章介绍如何高效使用 Claude Code，本文旨在记录作者从最初尝试到逐步将自己从开发循环中“移除”的演变过程。作者指出，一旦进入自动化的“隧道视野”，人们往往会忘记中间经历的复杂步骤，因此记录这一过程至关重要。

核心内容

文章以日记的形式，详细描述了作者利用 Claude Code 逐步实现开发自动化、将自己从日常执行中解脱出来的三个阶段。

阶段 0：终端标签页的混乱同步

起初，作者采用了一种“同步”模式：在本地终端与 Claude Code 进行活跃会话，共同头脑风暴，实施代码，审查 PR（拉取请求），最后由自己决定何时合并。这一阶段涉及大量的 Claude.md 文件以及用于记录笔记、记忆、技能、MCP（模型上下文协议）和子代理的配置。

随着并行处理多个功能的需求增加，作者打开了多个终端窗口，利用 worktrees（工作树）甚至在不同项目间切换，导致出现了 meme -worthy 的“多标签页疯狂”状态。虽然 Superpowers 插件和 Lina Edwards 提出的“守门人”理念（即头脑风暴、规范制定、计划、实施、审查需要独立的上下文以避免相互干扰）帮助建立了一定的自动化流程，但作者很快遇到了上下文切换疲劳。

由于不信任 AI 的自动判断，作者不得不在实施过程中频繁手动确认（按回车）。此时，OpenClaw/Clawdbot/Moltbot 等工具出现，但因安全顾虑作者起初持排斥态度，直到 AWS 在 Lightsail 上提供一键部署才缓解了部分信任危机。在与 Sergey Rysev 的对话后，作者意识到无法长期承受监控多个终端窗口细节的压力，决定尝试“将自己从方程中剔除”，即在保持尽可能安全的前提下，让 AI 独立工作。为此，他租用了一台 EC2 实例，通过 SSM 连接，并坚持使用 Claude Code 的原生方式（以符合使用凭证的法律合规性）。

阶段 1：脱离本地机器

第一步是将项目特定的内容隔离到单一的 EC2 实例上，以减少“爆炸半径”（即出错时的影响范围）。虽然为了追求速度反而需要思考安全策略从而在初期变慢，但这带来了心理上的安宁。

这一迁移暴露了之前本地环境中上下文泄露的问题：不同仓库的上下文混杂，CLAUDE.md 等记忆文件过于互联且混乱。由于未迁移之前的对话上下文，Claude 在新环境中显得“愚蠢”。此外，沙盒模式下的凭证泄露风险仍让作者感到不安，但这并非本文重点，重点在于通过亲身体验理解机制。

最终形成的工作流优势在于：作者不再需要盯着 AI 实施已规划好的内容，且环境状态被清理并隔离在本地机器之外。

阶段 2：实现独立运行

作者曾尝试通过手机远程终端保持与 EC2 的交互式会话，但这并不符合“脱离循环”的目标。原因有二：

1. 调度需求：作者希望 Claude Code 能按计划运行，而不是需要像保姆一样随时照看。
2. 工作与生活界限：作者不希望下班后还通过 Slack 式的消息流被 AI 打断。

因此，作者转向了“检查点式”的沟通模式：AI 完成一部分工作，留下清晰的工件和问题，作者次日早晨再按需处理。这需要三个要素：

• 在运行之间持久化存储状态。
• 让调度程序知道“下一步做什么”，无需人工干预。
• 明确的“停止点”，AI 在此处交还工作并提供足够上下文，以便作者在 5 分钟内即可回复，而非重新加载整个问题。

阶段 3：以 GitHub 作为看板

在尝试通过 .md 文件和守护进程实现自动化失败后，受 Sergey Rysev 启发（他提到给代理提供“规划看板”），作者将任务管理转移到了 GitHub Issues 上。

作者曾考虑 JIRA，但 Atlassian MCP 过于沉重，且 GitHub 应用程序允许使用短期凭证，有助于进一步降低爆炸半径。GitHub Issues 被证明是一个出人意料的合适选择，因为它们天然具备状态追踪、评论历史和任务分解的能力，完美契合了作者所需的“检查点式”工作流。

(注：原文在此处截断，但根据上下文逻辑，后续内容应涉及如何利用 GitHub Issues 作为 AI 与人类之间的异步协作界面，实现真正的自主开发循环。)

关键要点

• 自动化初期的反直觉性：为了获得长期的自动化效率，初期必须投入时间进行安全隔离、上下文清理和流程重构，这会导致短期内的效率下降。
• 上下文隔离的重要性：不同功能、不同仓库的上下文必须严格隔离，避免相互干扰。Claude.md 等配置文件需要精简且针对性强。
• 从“同步”到“异步”的转变：高效的 AI 辅助开发不应是持续的交互式对话，而应是基于“计划-执行-检查点”的异步模式。AI 完成阶段性任务后留下清晰工件，人类在特定时间点介入。
• 降低爆炸半径：通过隔离环境（如 EC2）和使用短期凭证（如 GitHub App），将 AI 出错的影响限制在最小范围，从而建立信任。
• 工具选择的权衡：对于轻量级任务管理，GitHub Issues 比 JIRA 等重型工具更适合与 AI 代理集成，尤其是在结合 MCP 和短期凭证使用时。
• 人类角色的重新定义：开发者的角色从“代码实施者”转变为“流程设计者”和“关键决策者”。需要学习如何像管理人类员工一样，将任务分解、委派并设定明确的验收标准。

意义与影响

这篇文章为开发者提供了一条从“AI 辅助编码”向“AI 自主开发”过渡的实用路径。它揭示了当前 AI 编程工具（如 Claude Code）在实际生产环境应用中面临的真实挑战：上下文管理、安全性、以及人机协作模式的重构。

其核心启示在于，真正的自动化不是简单地让 AI 写代码，而是建立一套可预测、可审计、低摩擦的异步协作系统。通过引入 GitHub Issues 作为“看板”和状态存储，作者展示了一种低成本、高灵活性的解决方案，使得开发者能够从繁琐的执行细节中解脱出来，专注于架构设计和关键决策。这对于希望利用 AI 提升研发效能、同时保持对代码质量和安全控制的团队具有重要的参考价值。