第 27 章 · 七大生产循环模式
本章目标：掌握 Loop Engineering 生态中最实用的七个生产循环模式，理解每种模式的节奏、所需技能和 token 成本，能在实际项目中选型。
27.1 模式总览
官方认证的生产循环模式共七种，按复杂度与 token 成本递增排列：
| 模式 | 节奏 | 自主等级 | Token 成本 |
|---|---|---|---|
| Daily Triage | 1 天 – 2 小时 | L1 | 低 |
| PR Babysitter | 5 – 15 分钟 | L1 | 高 |
| CI Sweeper | 5 – 15 分钟 | L2（谨慎） | 极高 |
| Dependency Sweeper | 6 小时 – 1 天 | L2 | 中 |
| Changelog Drafter | 1 天 或 tag | L1 | 低 |
| Post-Merge Cleanup | 1 天 – 6 小时 | L1 | 低 |
| Issue Triage | 2 小时 – 1 天 | L1 | 低 |
27.2 Daily Triage：每日分诊
目标
每天开始时自动生成一份优先级排序的问题清单，让团队知道今天该做什么。
所需技能
loop-triage：读取 CI、issues、commits、chat，产出优先级发现minimal-fix（可选，第二阶段）：为明显失败起草最小修复- Reviewer 子代理或技能（可选）：验证提出的修复
状态管理
使用 STATE.md 作为记忆骨干：
markdown
# Loop State — Project X
Last run: 2026-06-09 08:15 UTC
## High Priority
- [ ] #1241 — flaky test in auth flow (CI red on main)
Loop action: Opened worktree. Fix proposed. Waiting for human PR review.
## Watch List
- PR #1238 open 4 days with no activity.建议节奏
- 晨间分诊：
/loop 1d - 活跃冲刺期：
/loop 2h - 团队无 TUI：GitHub Action cron
0 8 * * 1-5
27.3 PR Babysitter：PR 守护
目标
PR 打开后自动追踪，提醒久未处理的 PR，必要时自动评论或标记。
节奏与成本
- 每 5–15 分钟检查一次
- Token 成本高（频繁调用 LLM 判断状态）
- 建议 L1 仅观察，不自动操作
关键约束
- 不要自动关闭或合并 PR
- 不要替换人类 reviewer 的判断
- 只提醒、只标记、只总结
27.4 CI Sweeper：CI 扫雷
目标
CI 失败时自动诊断原因、尝试修复、开新 PR。
风险与约束
- Token 成本极高（涉及代码生成 + 测试运行）
- 必须 L2 起步：先有稳定的 L1 分诊记录 1–2 周
- 必须有独立验证者（verification sub-agent）
- 必须有尝试次数上限（如 3 次）
安全边界
yaml
# loop-budget.md
max_tokens_per_run: 50000
max_attempts: 3
denylist_paths:
- "config/prod-secret*"
- ".env"27.5 Dependency Sweeper：依赖扫描
目标
定期检查依赖安全漏洞与过期包，自动开 PR 升级。
节奏
- 每 6 小时至 1 天一次
- Token 成本中等
模式特点
- 适合 L2：可自动升级非破坏性依赖
- 破坏性升级需人工确认
27.6 Changelog Drafter：变更日志起草
目标
根据 git commits 自动生成 CHANGELOG.md 草稿。
节奏
- 手动触发（tag 时）或每日一次
特点
- Token 成本低
- L1 即可：只起草，不改 CHANGELOG
- 人类最终审批
27.7 Post-Merge Cleanup：合并后清理
目标
PR 合并后自动清理分支、删除临时文件、更新文档。
节奏
- 1 天 – 6 小时一次
特点
- Token 成本低
- L1：只做清理，不动业务代码
27.8 Issue Triage：Issue 分诊
目标
新 Issue 进来时自动分类、标记优先级、分配标签。
节奏
- 2 小时 – 1 天一次
特点
- L1：只建议，不自动分配
- 可结合项目历史 issue 学习分类规律
27.9 模式选型速查表
| 你的场景 | 推荐模式 |
|---|---|
| 团队每天不知道该干什么 | Daily Triage |
| PR 经常石沉大海 | PR Babysitter |
| CI 经常挂且没人修 | CI Sweeper（L2+） |
| 依赖漏洞堆积 | Dependency Sweeper |
| CHANGELOG 从不更新 | Changelog Drafter |
| 合并后分支乱七八糟 | Post-Merge Cleanup |
| Issue 标签混乱 | Issue Triage |
本章小结
- 七个模式各有定位，从 L1 到 L2 不等；
- Token 成本从低到极高，选型需权衡价值与成本；
- 安全原则：先 L1 证明看得准，再考虑 L2 允许动手；
- 可用交互式选择器（pattern picker）辅助决策。
🧪 随堂测验
点击你认为正确的选项。答错时会展示正确答案与原因解析。
1. 以下哪种循环模式的 token 成本最高？
2. 关于 CI Sweeper 的安全要求，以下哪项不是必须的？
3. Issue Triage 模式通常建议停留在哪个自主等级？
4. Daily Triage 的推荐节奏不包括以下哪个？
🛠️ 动手实践
- 用
npx @cobusgreyling/loop init . --pattern daily-triage --tool claude初始化一个 Daily Triage 循环，观察生成的文件结构。 - 为一个简单的 GitHub Actions CI 失败场景设计一个 CI Sweeper 循环（仅 L1 报告阶段），写出你的 STATE.md 模板。
- 对比 Changelog Drafter 和 Issue Triage 两种模式的 token 成本差异，解释为什么前者更低。
完成练习后，进入下一章：自主等级与 Loop Ready 评分。