从繁琐开发中解脱：Claude Code自动化流程的探索与挑战

简介作者既非AI狂热者也非AI悲观论者其对AI的复杂情感可在之前文章中了解。作者热爱创造但也明白创造前会经历混乱过程。AI辅助开发尤其是Claude Code需实际使用才能了解其可能性、局限性找到适合自己的使用方式。很多人已写过关于用好Claude Code的文章作者想分享自己最初使用Claude Code的经历及现在的使用情况以免进入自动化“隧道”后遗忘细节。阶段0多终端窗口并行起初作者在本地与Claude Code进行简单“同步”会话一起头脑风暴、实现想法、审查结果PR并合并。期间产生大量Claude.md文件和其他记录重要信息的.md文件。技能、MCPs、子代理等对特定任务有帮助。等待时作者打开多个窗口并行开发功能利用worktree甚至同时处理不同项目。[Superpowers]插件在工作流程中有用配备子代理可实现不错的自动化。但上下文切换带来疲劳作者只能专注两三个功能且不信任AI需频繁手动确认。此时OpenClaw/Clawdbot/Moltbot出现作者因安全问题未尝试后来AWS在Lightsail上实现一键部署很多人开始使用。作者与Sergey Rysev交谈后决定尝试“让自己解脱出来”创建EC2实例建立SSM连接仅使用Claude Code的原生方式。阶段1脱离本地机器第一步进展不顺利作者想将手动确认工作自动化将项目迁移到单独的EC2实例上。迁移暴露出不同仓库上下文干扰、文件关联混乱等问题Claude变得“愚蠢”工作效率降低。但自动化虽开始变慢却让作者安心影响范围被限制在单个项目内。沙盒模式使用有问题凭证泄露问题仍令人担忧很多人致力于开发“Agent - env - as - a - service”环境和安全虚拟环境。最终形成工作流程好处是无需盯着Claude实现内容开发环境更整洁。阶段2实现独立运行作者尝试通过手机远程终端与EC2实例交互会话但不理想。一是希望Claude Code按预定计划运行解脱自己二是不想在不使用电脑时工作。作者想要“checkpoint式”沟通方式即Claude完成部分工作后留下成果和问题自己第二天早上处理。这需要持久存储位置、让调度程序知道下一步的方法和明确的“停止点”。当时Claude需监督才能工作作者需要完整“流程”。阶段3使用GitHub作为任务板作者尝试多种方法后决定使用GitHub问题跟踪器。GitHub问题跟踪器有标签适合状态机管理、评论可作提示信息、Web UI简洁、CLI可脚本化操作等优点。作者将工作流程迁移到GitHub待办事项仓库存储问题标签代表阶段规格/计划文档存放在特定目录。技能具备多种功能且各阶段有独立上下文窗口。但所有操作仍需手动输入命令。阶段4守护进程的第一版作者得出需要一个tick.sh脚本的结论。该脚本每15分钟在EC2实例上通过cron运行执行加锁、刷新令牌、重置问题、认领问题、启动Claude子进程、根据结果更新问题标签等操作。脚本简单智能实现主要在Claude子进程中脚本起监督作用。阶段5实际应用作者的工作模式是与Claude头脑风暴、编写规格文档、制定计划问题状态变为ready后合上笔记本电脑第二天早上查看工作进展。早上检查标记为needs - attention和branches - ready的问题为满意问题添加merge标签安排下一批任务。这种方式与以往不同晚上代码实现白天审查思考。但处理安全问题和开发流程花费时间精力虽清理了积压小任务但感觉未更高效且方式不能无限扩展瓶颈转移。阶段6预上下文收集丰富信息头脑风暴阶段占用早上时间多Claude问的问题可通过阅读代码和文档找到答案。作者增加守护进程的信息丰富步骤在GitHub创建标记为needs - enrichment的问题守护进程启动Claude会话扩展描述标记为enrichment:needs - review等待处理。作者早上阅读描述后决定推进或头脑风暴该步骤将上下文收集工作转移到后台时间。阶段7尝试自动头脑风暴这是作者谨慎的步骤因头脑风暴关键不愿委托。自动头脑风暴步骤仅在通过标签启用时运行产生冻结的基线规格、可编辑的工作规格和“头脑风暴日志”。日志让作者有信心可选择接受规格或编辑。标签改为批准后守护进程提炼编辑内容起草计划和计划审查。自动流程还剩三个需要人工干预的环节实现和合并由守护进程驱动。阶段8当前状态完整的理想流程现在只有五个需要人工干预的点作者感觉安全。出现问题时守护进程停止标记问题为needs - attention并留下评论作者通过早上问题筛选得知问题。未来展望作者不确定这种实现功能的方式是否更耗时和成本高虽有人说复制工作流程会有生产力但作者不信。未来有一些趋势明显QA成为下一个瓶颈需围绕测试设计开展工作需要更多审查/清理代理如技术债务建议器、架构审查器、安全审查步骤编排器应更好分类功能可能需单独的bug修复流程可拓展元功能但进入“传话游戏”领域。在过度自信之前的提醒作者坚信不能将思考能力委托给AI此流程会产生技术债务不能取代静态代码分析等工作甚至让这些工作更重要。作者会继续探索不知委托工作的界限在哪预计会越过再调整。如果有人自信告知开发中如何使用AI不可轻信。