第 22 章 | 触发模式——半手动 + 全自动

更新于 2026/5/12
💡 进群学习加 wx: agentupdate
(申请发送: agentupdate)

第 22 章：触发模式——半手动 + 全自动

学习目标

让 /dev 在"完全可控"和"完全放手"之间灵活切换。

三个监督级别

flowchart TB
    L0["L0: 全手工
每条 task 都问"] --> Cost0["✓ 极强可控
✗ 累、慢"]
    L1["L1: 组级半手动
用户说做组 N"] --> Cost1["✓ 重要节点把关
✓ MVP 友好"]
    L2["L2: 自动循环 + 通知
/dev 全跑 + Telegram"] --> Cost2["✓ 放手
⚠️ 跑歪要看通知"]
    L3["L3: cron + 远程
定时跑 + 推送"] --> Cost3["✓ 完全自治
⚠️ 失控风险最大"]

    style L0 fill:#ffcdd2
    style L1 fill:#fff9c4
    style L2 fill:#c8e6c9
    style L3 fill:#bbdefb

→ 大部分人在 L1 → L2 之间切换。L0 太累，L3 风险高。

半手动（L1）

你: 实现组 3
  ↓
main Claude: 
  /dev 3 模式
  跑组 3 的完整循环（DEV → TEST → REVIEW）
  完成 → 停下来等你
  
你: 看一下，OK，做组 4
  ↓
循环

优点：每组完成后你都能介入审查、调整、回滚。 缺点：你必须在场盯着。

全自动（L2）

你: /dev
  ↓
main Claude:
  从下一个 PENDING 组开始
  全循环
  通过 → 下一组
  卡住 → 升级 → architect → STUCK.md → 通知 + 停手
  
你: （喝咖啡 / 开会 / 睡觉）
你的 Telegram: ⚠️ Group 7 stuck — see STUCK.md
你: （回到电脑）阅读 STUCK.md，挑一个 option，改完继续

优点：放手做别的事。 缺点：跑歪了你不知道——这就是为什么我们做了 ⚠️ marker + Telegram 通知。

Cron 定时（L3）

最激进的形态：

# crontab -e
0 9 * * *   cd /Users/amanda/work/openspec && claude -p "/dev"
0 14 * * *  cd /Users/amanda/work/openspec && claude -p "/dev"
0 21 * * *  cd /Users/amanda/work/openspec && claude -p "/dev"

每天 9 点 / 14 点 / 21 点自动跑一次 /dev。配合 Stop hook 推 Telegram → 你完全不用主动启动。

时间轴：

sequenceDiagram
    participant Cron as crontab
    participant CC as Claude Code
    participant Agents as 多 agent
    participant TG as Telegram
    participant You as 你

    Note over You: 喝咖啡 / 工作 / 睡觉

    loop 每天 09:00
        Cron->>CC: claude -p "/dev"
        CC->>Agents: dispatch 一组
        Agents-->>CC: 完成 / 卡住
        CC->>TG: ⚠️ marker 推送
        TG-->>You: 📱 进度
    end

    loop 每天 14:00
        Cron->>CC: claude -p "/dev"
        Note over Agents: ...继续推进...
    end

    loop 每天 21:00
        Cron->>CC: claude -p "/dev"
        Note over Agents: ...直至全部完成或 STUCK...
    end

风险点：

✗ 跑炸了你白天发现
✗ token 消耗不可控
✗ 改坏代码自动 commit

→ L3 必须配齐：阈值（防死循环）+ 通知（你能及时看见）+ 沙盒（防事故）。

何时用哪种

flowchart TD
    Q1{项目阶段?}
    Q1 -->|MVP / 学习| L1["半手动"]
    Q1 -->|稳定中| Q2{你在不在场?}
    Q1 -->|长期维护| L3["cron"]

    Q2 -->|经常切换工作| L2["全自动 + 通知"]
    Q2 -->|盯得住| L1

    style L1 fill:#fff9c4
    style L2 fill:#c8e6c9
    style L3 fill:#bbdefb

切换技巧

我们的 /dev 命令本身支持所有模式：

/dev status     # L0：只看不动
/dev 3          # L1：跑一组停
/dev            # L2：跑到完成或卡住
# (cron) /dev   # L3：定时

→ 同一命令、同一项目、随心切换。这是 dev.md 的核心设计价值。

让 /dev 在 L2 知道何时停

L2 模式下必须有清晰的"成功 / 失败"出口：

成功:  全部组 APPROVED → E2E PASS → "READY TO ARCHIVE" → STOP
失败:  任意组 STUCK → architect 已诊断 → STOP

→ 不会无限跑下去——这是 dev.md Step 8 "Hard stop conditions" 要保证的。

反模式

❌ MVP 直接上 L3                  → 跑炸都不知道
❌ L2 没配通知                    → 卡住了你不知道
❌ L0 死磕                        → 多 agent 系统的优势全丢
❌ 切到 L3 后不查账单              → 月底惊喜
❌ 不同模式用不同命令              → 心智负担、互不通用

真实建议路径

第 1 周（学习期）       L0 + L1 混合
                       手动看每组怎么跑
第 2~4 周（稳定期）    L1 为主
                       熟悉了再切 L2 跑通宵
正式生产                L2，关键改动 L1
                       L3 留给"真的稳定到 2 个月没出过事"

你现在能做什么

  • 在 4 个监督级别中按情境选择
  • 让 /dev 同一命令支持多种触发模式
  • 知道 L2 / L3 必须配什么"安全设施"