每月110美元的自优化流水线（5分钟阅读）

# 每月110美元的自改进流水线 | Andy Widjaja 来源：https://andywidjaja.com/blog/110-pipeline 我厌倦了手动在笔记本电脑上用Claude Code实现自己的待办事项列表。于是我搭建了一个循环，让系统自己进行分诊，如果任务太大就拆解，然后实现、运行测试，并创建PR。我只需在手机上合并。这套系统已经运行了两周：27次合并，1次失败，平均每个问题花费1.61美元。 它已经运行了两周。数字可能会变化。我仍在积极收集数据。随着系统成熟，我会更新这篇文章。但这个模式效果不错，我想现在就分享出来，而不是等完美数据集。 ## 成本 ``` $100.00/月 Claude Max 5x（通过Claude Code CLI进行分诊和实现） $ 9.99/月 VPS（Hostinger，2 vCPU，8GB内存，Ubuntu） $ 0.00/月 GitHub ───────── $109.99/月 总计 ``` ## 配置 这个系统是autoloop（https://github.com/Sanctum-Origo-Systems/autoloop）。一个配置文件来配置循环： ``` # autoloop.toml repo = "your-org/your-repo" triage_model = "sonnet" impl_model = "claude-opus-4-6" verify_cmd = "uv run pytest" max_retries = 3 protected_paths = ["autoloop/", "autoloop.toml"] ``` 三个systemd定时器。没有Kubernetes。没有编排框架。没有花哨的队列服务。 ``` OnCalendar=*-*-* 00:00:00 UTC # 分诊 OnCalendar=*-*-* 02:00:00 UTC # 实现 OnCalendar=*-*-* 04:00:00 UTC # 更新日志 ``` ## 一个问题会发生什么 Autoloop流水线：GitHub Issue → 分诊 → 依赖图 → 构建器 → 测试 → 拉取请求 一个GitHub issue进入队列。无人值守： **分诊**（Sonnet，约0.10美元）：读取issue，验证它，估算故事点数，分配优先级。如果issue太大，它会被拆解为带有依赖顺序的子issue，并对每个子issue进行分诊。它会递归拆分，直到每个部分都能一次性构建完成，并生成一个足够小、便于我在手机上审查的PR。 **实现**（Opus，约1.50美元）：选择依赖顺序中下一个准备就绪的issue，创建分支，用Claude运行issue规范和仓库上下文，运行测试和lint，检查是否添加了测试文件，然后打开PR。 **验证关卡**：当测试失败或没有添加测试文件时，最多重试3次，将错误反馈回去，为下一次尝试提供上下文。如果所有重试都失败，则会将该issue标记为`needs-human`，然后继续。 我审查手机上的待办PR并合并。这就是我对循环的贡献。PR合并可以自动完成吗？可以，但这是一个刻意的架构决策——让我作为PR关卡。 ## 当它出问题时 **第8天**。Issue #40（https://github.com/Sanctum-Origo-Systems/patina/issues/40）是重复的。它描述的问题已经实现。系统仍然尝试了3次生成变更，发现没有可变更的内容，因为没有diff导致验证失败。它将该issue标记为`needs-human`，然后继续处理队列中的下一个任务。 我查看了该issue并阅读了失败说明。我关闭了它。这是正确的结果。人类看到了，意识到是重复的，关闭了它。系统当时无法知道。它只知道它无法生成有效的PR。所以它让路了。 **第12天**。Issue #159（https://github.com/Sanctum-Origo-Systems/patina/issues/159）被拆分为3个子issue。第二个子issue产生的PR破坏了第一个PR引入的导入路径。合并冲突。我在Claude Code远程会话中（VPS上的tmux）从手机修复了它，只用了4分钟。 **模式：**当它失败时，几乎总是因为我的issue描述模糊，或者假设了构建器没有的上下文。更好的issue → 更好的PR。系统暴露我草率的需求规格，比任何代码审查都快。 ## 让它安全的约束 系统不能修改自身。 ``` protected_paths = ["autoloop/", "autoloop.toml"] ``` 如果一个issue的目标文件在`protected_paths`下，分诊会将其路由到`needs-human`。构建器永远不会触碰自己的逻辑、流水线或配置。这个安全检查在分诊（主要关卡）和实现（安全网）两个阶段都进行。 ***无需自我修改的自我改进。***它改进的是*产品*。它不能改进*流程*。这个边界就是我相信它能无人值守运行的基础。 ## 它构建了什么 Patina（https://github.com/Sanctum-Origo-Systems/patina）：7200行Python，9200行测试，31个MCP工具。 我交互式地构建了初始核心架构。一旦基础稳固，autoloop就接管了待办事项。在最近合并的40个PR中，有27个是自主完成的。 流水线本身有3500行。最初嵌入在Patina的仓库中，后来提取为独立的包（https://github.com/Sanctum-Origo-Systems/autoloop），可以用一条命令应用到我的其他仓库： ``` autoloop init --repo your-org/your-repo --verify-cmd "pytest" autoloop triage autoloop implement ``` ## 哪里有效，哪里无效 我想诚实地说明这个方案的适用范围。 **这适用于：**独立开发者、小团队、一个人或一个团队能掌握完整上下文的仓库。非关键路径系统，可以接受24小时修复周期。 **这（目前）不适用于：**受监管环境、多团队代码库、面向客户的、有SLA要求的生产系统（这个设置目前不提供回滚机制）。该模式在任何规模都适用，但这个实现假设只有一个人把关。 两周时间并不能证明任何长期效果。我将在3个月和6个月时再次更新这篇文章。如果效果下降，我会分享发现。我只是分享这个模式，并非宣告胜利或声称解决了所有实际用例。 ## 我学到的东西 瓶颈不是模型或基础设施，而是issue的质量。模糊的issue产生糟糕的PR。带有明确验收标准和文件路径提示的特定issue会产生一次审查即可合并的PR。 一年前这需要一个团队。如今只需要一个VPS和编写issue的品味，就让我感到惊叹。 --- *代码：github.com/Sanctum-Origo-Systems/autoloop (https://github.com/Sanctum-Origo-Systems/autoloop)。下一篇文章：我将解释为什么观察者和构建者是分离的实例。*