如果AI能24小时不间断地给你的代码"做体检"，它会找到多少性能漏洞？
一位开发者把这个问题变成了现实。他用Claude Code的Routines功能，设置每两小时自动运行一次性能优化任务，最终让自己维护的命令行工具Repomix运行速度提升了约2.4倍。更关键的是，整个过程不需要他盯着屏幕，AI在云端独立完成，结果推送到独立分支，等他有空时Review就行。
这套玩法的核心洞察很朴素：性能优化是"可量化"的——"有没有变快"能用数字回答，"有没有改坏"能用测试验证。一旦基准测试（benchmark）就位，剩下的模式识别工作（换依赖、懒加载、砍I/O）完全可以交给AI反复试错。
下面是他完整的配置思路和Prompt设计，以及为什么这套机制能跑通。
为什么是"性能调优"最适合自动化
作者一开始也纠结：Routines能定时跑Prompt，但到底该让它干什么？
他的筛选标准很实际——这件事必须满足四个条件：第一，结果可量化，不能是"代码更优雅了"这种主观判断；第二，有自动化测试兜底，改坏了能立刻发现；第三，工作发生在独立分支，不影响主分支稳定；第四，优化手段相对模式化，不需要太多创造性设计。
性能调优完美契合。基准测试给数字，测试套件保回归，分支隔离控风险，而常见的性能 wins（替换依赖、延迟加载、减少I/O）都是结构化操作。
相比之下，功能开发太开放，Bug修复太依赖上下文，文档更新又太轻量。性能优化是少数AI可以"闭卷考试"还能拿高分的场景。
Routines的工作机制：与本地Loop的本质区别
Claude Code有两个容易混淆的功能：/loop和Routines。
/loop在本地运行，你关掉电脑就停。Routines在云端运行，配置一次后持续执行，不管你笔记本开没开。作者选的是后者，在claude.ai/code/routines的Web界面配置，设置为每两小时触发一次。
流程是：Routines指向GitHub仓库 → 按Prompt执行 → 结果自动推送到指定分支 → 可选地创建或更新PR。整个过程无人值守，作者只在有值得看的成果时才介入。
这种"异步AI协作"模式，把开发者从"盯着AI干活"的焦虑中解放出来。不是实时Pair Programming，而是"布置作业→验收成果"的管理逻辑。
Prompt拆解：如何把性能优化变成可执行指令
作者的Prompt结构值得逐层拆解。这不是简单的"帮我优化代码"，而是一套完整的自动化工作流定义。
首先是环境配置：工作分支定为perf/auto-perf-tuning，基于main分支，目标文件夹是src，PR标题固定格式，改进阈值明确为"1-2秒的CLI运行，忽略几毫秒波动，要求总执行时间至少降低2%"。
这个阈值设计很精细。太敏感会陷入微优化噪音，太宽松会错过真实机会。2%对1-2秒量级的工具来说，是"人类能感知"和"统计显著"的平衡点。
其次是资源分配：启用5个调查子代理（sub-agent），模型用sonnet。多代理并行调查，相当于让AI从多个角度同时审视代码，避免单一路径的思维盲区。
核心策略约束只有两条：只改性能不改功能，保持现有行为 intact。这是自动化安全的底线——宁可不做，不能做错。
八步工作流：从分支准备到PR提交
Prompt里的Progress checklist把任务拆成八个阶段，每个都有明确验收标准。
分支准备阶段处理版本同步：如果工作分支不存在，从最新main创建；如果存在，检查main是否超前，超前就合并并推送。冲突处理原则很务实——优先考虑"该改动可能已在别处被采纳"，避免重复劳动。
检查现有PR阶段让AI先读历史上下文。如果已有PR，看描述和Review评论，确保新工作不脱节。这是长期自动化运行的关键——AI需要"记忆"自己之前干过什么。
调查规划阶段是重头戏。AI先理解仓库结构和处理流程，然后定义调查范围。5个子代理并行工作，各自从不同切入点深挖。
实现阶段后紧跟基准测试验证。不是"感觉快了"，是跑benchmark拿数字对比。没过阈值就回滚，过了才进入提交流程。
本地Review阶段设计得很克制——AI不直接合并，而是把成果摆出来等人看。Create/update PR是最后一步，保持工作流的开放性。
Repomix案例：2.4倍加速从何而来
Repomix是一个将代码库打包成单一文件的CLI工具，典型场景是处理中等规模项目。作者没透露具体优化了哪些点，但从Prompt设计和"模式化改动"的描述可以推断：依赖替换（比如更快的解析库）、懒加载（延迟初始化非核心模块）、I/O削减（减少文件读写次数）是主要手段。
这些正是AI擅长的——识别热点路径，匹配已知优化模式，验证数字提升。不需要架构级重构，在现有结构内榨取性能。
2.4倍的最终成果，是多次2%改进的复利效应。每两小时一轮，持续累积，人类只需在关键节点做决策。
这套机制的边界与启示
作者强调"现在足够可复现，值得分享"，暗示这仍是实验性玩法。它的有效运行依赖几个前提：测试覆盖足够、基准测试稳定、代码结构相对清晰、优化空间以"模式化改动"为主。
对于高度耦合、缺乏测试、或需要架构级重构的遗留系统，自动化性能调优可能频繁撞墙——AI会提出改动，但测试通不过，或改动引发连锁问题，需要人类介入解局。
更深层的启示是工作流设计：把AI从"对话工具"重新定位为"后台进程"。不是问AI"这段代码怎么优化"，而是配置好规则让AI持续探索，人类只在有成果时验收。这种"异步AI"模式，可能是未来人机协作的主流形态之一。
作者最后放出了完整的Prompt和配置，等于开源了一套"性能优化自动化"的参考实现。对于维护CLI工具、追求极致启动速度的开发者，这是可直接套用的模板。
下一步会是什么？也许是安全漏洞的自动化扫描修复，或者是依赖更新的自动化验证。凡是"可量化、可测试、模式化"的工程任务，都可能被Routines这类机制接管。开发者的角色，正在从"亲手写每一行代码"转向"设计AI的工作规则并验收成果"。
热门跟贴