Claude Code 全自动执行：从 Spec 到完成不中断的实战技巧

Claude Code 全自动执行：从 Spec 到完成不中断的实战技巧

前几篇讲完了概念、规划、Spec-Kit。但真正让人难受的是——计划都做好了，Tasks 也拆好了，结果 AI 执行到一半卡住了、跑偏了、忘了前面的要求、或者每改一个文件就问你一次"可以吗"。这篇文章解决的就是这个：Spec 和 Tasks 就位后，怎么让 Claude Code 从头执行到尾不中断。

---

核心矛盾：为什么 AI 执行到一半就"不行了"

先理解问题根源，才能对症下药。

上下文衰减曲线

一个 7 阶段功能开发的真实上下文消耗:

Phase 1 (数据层):
  ████░░░░░░░░░░░░░░░░  上下文占用 ~15%
  输出质量: 🟢 最佳

Phase 3 (核心逻辑):
  ████████░░░░░░░░░░░░  上下文占用 ~45%
  输出质量: 🟡 良好，但前半年的 tool output 已堆积

Phase 5 (API 层):
  ██████████████░░░░░░  上下文占用 ~75%
  输出质量: 🟠 AI 开始忽略早期 Spec 中的约束，跳过边缘情况

Phase 7 (测试和收尾):
  ████████████████████  上下文占用 ~95%
  输出质量: 🔴 自动压缩已丢弃早期决策，"忘记"了 Constitution 规则

根因：Claude Code 是有状态会话。每轮对话的文件读取、命令输出、纠错历史都堆积在上下文中。后期 AI 能用来"思考"的空间只剩不到 20%。

三大中断源

中断源 1: 权限弹窗 ─────────────────
  每写一个文件 → "Allow this edit? [y/n]"
  一个 27 Task 的项目可能要弹 80+ 次
  → 你不能离开电脑，AI 在等你点确认

中断源 2: AI "完成"后停下来 ──────────
  AI 完成当前 Task → 停下来等你
  你不回复 → AI 就等着
  → 每个 Task 之间都需要你手动推进

中断源 3: 上下文退化导致跑偏 ────────
  AI 在前 10 个 Task 表现完美
  第 11 个 Task 开始忽略约束 → 你发现问题 → 纠错
  → 纠错又消耗更多上下文 → 恶性循环

---

内置方案：/goal 命令——Claude Code 原生自主执行

前面说了这么多"怎么绕过中断"，但 Claude Code 其实已经内置了直接的解决方案。

Claude Code v2.1.139（2026 年 5 月 12 日） 开始内置了 /goal 命令。这是目前最直接、最省力的全自动执行方式——不需要外部循环脚本，不需要手动推进 TODO，一次设定目标，AI 自己跑到完成。

/goal 解决了什么问题

回想三大中断源：

中断源 1: 权限弹窗     → /goal 在受信任的工作区运行，消除弹窗
中断源 2: AI 完成后停下 → /goal 自动判断是否完成，未完成自动继续
中断源 3: 上下文退化    → /goal 每轮后由轻量级评估模型检查状态，防止跑偏

工作原理

你设定 Goal:
  /goal 实现 specs/001-user-points/tasks.md 中的所有 Task
  until 所有 Task 标记为 [x] 且 pytest 全部通过
  without 修改现有 API 接口签名

AI 第 1 轮: 读 tasks.md → 实现 T001 → 标记 [x]
  → 评估模型检查: ❌ 还有 26 个 Task 未完成 → 自动继续

AI 第 2 轮: 实现 T002, T003 → 标记 [x]
  → 评估模型检查: ❌ 还有 24 个 Task 未完成 → 自动继续

...（多轮自主执行）...

AI 第 N 轮: 实现 T027 → 标记 [x] → 跑 pytest → 全部通过
  → 评估模型检查: ✅ 所有 Task [x] + 测试全绿 → Goal 达成
  → 控制权归还给你

关键机制——评估模型（Evaluator）：每轮 AI 执行完毕后，一个轻量级评估模型会独立判断 Goal 是否达成。它不是 AI 自己说"我做完了"就算，而是由一个独立的检查器对照你设定的完成条件进行验证。

语法

/goal <目标任务> until <可度量的完成条件> without <约束条件>

三要素：

要素	作用	示例
目标任务	让 AI 知道要做什么	“实现 tasks.md 中所有 Task”
完成条件	可被评估模型验证的硬标准	“pytest 全部通过，ruff 零错误”
约束条件	防止 AI 越界	“不修改现有 API 签名”

实战：用 /goal 执行整个项目

# 示例 1: 执行 Spec-Kit tasks.md
/goal 实现 specs/001-user-points/tasks.md 中的所有 Task
until 每个 Task 标记 [x] 且 pytest tests/ -q 全部通过且 ruff check src/ 零错误
without 修改 specs/ 目录下的任何文件、不引入新的第三方依赖

# 示例 2: 修复所有测试
/goal fix every failing test
until npm test 退出码为 0 且无 skipped 测试
without 修改 src/models/ 下的数据模型定义

# 示例 3: TypeScript 迁移
/goal 将 src/auth/ 目录迁移到 TypeScript strict mode
until tsc --noEmit 零错误且所有测试通过
without 修改任何业务逻辑行为

你可以随时查看和控制

/goal              # 查看当前 Goal 状态
                   # 输出: ◎ /goal active | 第 8 轮 | 已用 45K tokens | 耗时 12min
                   #       完成条件: "所有 Task [x] + pytest 全绿"
                   #       上次评估: ❌ Task 19/27 完成, 2 个测试失败

/goal clear        # 取消当前 Goal（AI 立刻停止）

/goal 的实时状态指示器

执行期间界面上会持续显示：

◎ /goal active | round 12 | 67K tokens | elapsed 22m
  Condition: "All tasks [x] AND pytest exit 0"
  Last eval: ❌ 23/27 tasks done, 1 test failing (test_expire_batch)

每轮评估模型都会给出简短的原因说明，让你知道 AI 跑到哪了、卡在哪了。

/goal vs 其他方案的对比

┌──────────────┬──────────────┬──────────────┬──────────────┐
│              │   /goal      │  TODO 自驱   │  外部循环     │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ 实现方式      │ 内置命令      │ Prompt 指令   │ Bash 脚本     │
│ 自动继续      │ 评估模型判断  │ 靠 AI 自觉    │ 无限循环      │
│ 完成验证      │ 独立评估器    │ AI 自判断     │ grep 关键字   │
│ 上下文管理    │ 原生支持      │ 手动 /compact │ 每轮重启      │
│ 失速检测      │ 评估器可发现  │ 无            │ git diff 对比 │
│ 上手难度      │ 一行命令      │ 中等          │ 较高          │
│ 灵活度        │ 中            │ 高            │ 高            │
└──────────────┴──────────────┴──────────────┴──────────────┘

/goal 不能做什么

❌ 不能跨会话持久——关掉终端 Goal 就没了（不像 Codex CLI 的 /goal 能持久化）
❌ 不能同时运行多个 Goal——一个会话只能有一个
❌ 不能处理"无法验证"的任务——"让代码更优雅"这种没有硬标准的任务不适合
❌ 不能在 disableAllHooks 模式下工作

/goal 的最佳拍档：/plan + /goal

第 1 步: /plan 实现用户积分系统...
  → AI 分析项目 → 提出方案 → 你确认

第 2 步: /goal 按上述方案实现
  until 所有测试通过且 ruff 零错误
  without 修改现有 API 接口
  → AI 自主执行全部 Task

这是目前最丝滑的全自动流程：Plan 对齐方向 → Goal 自主执行。

/goal 使用铁律

1. 完成条件必须可度量
   ✅ "pytest 退出码 = 0"     ❌ "代码质量好"
   ✅ "ruff check 零错误"     ❌ "大概没问题"
   ✅ "28 个测试全部通过"     ❌ "测试通过得差不多了"

2. 约束条件防止越界
   ✅ "without 修改 src/models/" （保护数据模型）
   ✅ "without 引入新依赖"         （防止依赖膨胀）
   ✅ "without 改 .env 文件"      （防止破坏配置）

3. 加上兜底限制
   /goal ... until ... or stop after 30 turns
   → 防止无限循环烧 Token

4. 搭配 .md 清单效果更好
   /goal 基于 @specs/001-user-points/tasks.md 执行
   → 评估模型有明确的检查清单，判断更准

国产模型使用 /goal 特别注意

国产模型作为后端时:
  → /goal 的评估模型仍然是 Claude 的轻量模型（不受你的后端模型影响）
  → 但执行模型是你的国产模型——上下文退化问题仍然存在
  
应对:
  → /goal 的 until 条件加一条: "or stop after 15 turns"
  → 15 轮后自动停止 → 检查进度 → 如有需要 /goal clear 后重新设定
  → 分段 goal 比一个超长 goal 更可靠

---

技巧一：TODO 自主驱动——让 AI 自己管理进度

当 /goal 不适用时（比如需要更灵活的流程控制），TODO 自驱是基础技巧。不要让每个 Task 都靠你手动说"下一步"。

标准做法

👤: 基于 @specs/001-user-points/tasks.md，从 Phase 1 开始实现。
    规则:
    1. 从 T001 开始，逐个 Task 执行
    2. 每完成一个 Task，标记 [x] 并继续下一个
    3. 遇到错误自己尝试修复（最多 2 次）
    4. 修复不了标记 ⚠️ 并继续下一个
    5. 所有 Task 完成后输出"✅ ALL TASKS COMPLETE"
    6. 不要停下来问我"是否继续"——除非遇到无法自动处理的阻塞

关键细节

❌ 错误说法:
  "帮我实现 tasks.md 里的所有任务"
  → AI 可能一次尝试做 3 个 Task，或者做完一个就停

✅ 正确说法:
  "逐个执行 tasks.md 中的 Task。规则:
   - 严格的顺序执行（T001 → T002 → ...）
   - 完成标记 [x]，失败标记 ⚠️
   - 自动进入下一个 Task
   - 只在真正阻塞时停下"

如果你想逐步审阅

不是所有人都放心让 AI 全自动跑完所有 Task。折中方案——按 Phase 批量执行：

👤: 执行 Phase 1（T001-T004）的所有 Task。逐个完成，完成后停下来等我审阅。

🤖: [完成 T001-T004]
    Phase 1 完成。T001 ✅ T002 ✅ T003 ✅ T004 ✅
    等待你的审阅。

👤: [审阅 diff] → Phase 1 通过。继续 Phase 2（T005-T008）。

🤖: [继续 Phase 2...]

每个 Phase 之间审阅一次，Phase 内部的 Task 自动连续执行。既保持控制力，又减少中断。

---

技巧二：权限管理——消除"是否允许"弹窗

权限模式对比

模式                  Security   Interruption  适用场景
─────────────────────────────────────────────────────
default (默认)        高         高（每次弹窗）   不信任 AI 时
acceptEdits           中         中（编辑不弹窗）  信任 AI 改代码
plan                  中         低（Plan内不弹窗） 规划阶段
auto                  低         极低             全自动执行
Bypass Permissions    无         零               完全自主（仅限隔离环境）

渐进式放权策略

第 1 阶段: 建立信任（前 3-5 个 Task）
  → 使用 default 模式
  → 每次 AI 操作你确认
  → 观察 AI 是否按你的规范写代码

第 2 阶段: 编辑放权（中间 10-15 个 Task）
  → 切换到 acceptEdits 或 auto 模式
  → AI 写文件不再弹窗，但危险命令（rm/git push）仍拦截
  → 你只在大方向偏了时介入

第 3 阶段: 全自动（最后 5-10 个 Task）
  → 切换到 auto 模式
  → AI 完全自主完成测试、lint、格式化
  → 你只在收到"完成"通知后审阅整体 diff

实操

# 方法 1: 启动时指定模式
claude --enable-auto-mode

# 方法 2: 会话内切换
# 按 Shift+Tab 循环: default → acceptEdits → plan → auto

# 方法 3: 预批准特定操作（精确控制）
/permissions
# 然后批准:
#   Bash(pytest *) → 自动允许
#   Bash(ruff *)   → 自动允许
#   Edit(src/**)   → 自动允许
#   Bash(git push *) → 仍需确认

国产模型特别注意

国产模型在 auto 模式下:
  → 对"是否该停下来问你"的判断不如 Claude Opus 准
  → 可能在不该停的时候停下，或者在该停的时候继续

应对:
  → 不要用完全的 auto 模式
  → 用"预批准特定操作"的方式（精确控制哪些操作自动允许）
  → 或者按 Phase 执行（每个 Phase 之间你确认一次）

---

技巧三：Stop Hook——完成≠通过

这是 Anthropic 内部团队认为最重要的一条。AI 说"完成了"不代表真的做对了。用 Stop Hook 在 AI 退出前自动验证。

核心思路

AI 完成 Task → 准备停止 → Stop Hook 触发
  → 自动运行测试
  → 自动运行 lint
  → 自动检查关键约束
  → 通过 → AI 真正停止 ✅
  → 不通过 → AI 被"弹回来"继续修复 🔄

实现：Stop Hook 配置

在 .claude/hooks.json 中添加：

{
  "Stop": [
    {
      "matcher": "",
      "hooks": [
        {
          "type": "command",
          "command": "cd \"$CLAUDE_PROJECT_DIR\" && python -m ruff check src/ --quiet || (echo '❌ Ruff check failed. Fix lint errors.' && exit 1)"
        },
        {
          "type": "command",
          "command": "cd \"$CLAUDE_PROJECT_DIR\" && python -m pytest tests/unit/ -x -q 2>&1 || (echo '❌ Tests failed. Fix and retry.' && exit 1)"
        }
      ]
    }
  ]
}

工作原理：Hook 返回非零 exit code → Claude Code 阻止停止 → AI 看到错误信息 → 继续修复。

进阶：分阶段验证

不同 Phase 验证不同东西：

{
  "Stop": [
    {
      "matcher": "",
      "hooks": [
        {
          "type": "command",
          "command": "python -c \"\nimport json, os\nphase = os.getenv('CURRENT_PHASE', '')\nif phase in ['1','2']:\n    # Phase 1-2 数据层: 只要求模型可创建，不要求测试全过\n    import subprocess\n    r = subprocess.run(['python', '-c', 'from src.quant_personal.data.models import Base; print(\"OK\")'])\n    exit(r.returncode)\nelif phase in ['3','4','5']:\n    # Phase 3-5 业务层: 要求单元测试全过\n    import subprocess\n    r = subprocess.run(['python', '-m', 'pytest', 'tests/unit/', '-x', '-q'])\n    exit(r.returncode)\n\""
        }
      ]
    }
  ]
}

---

技巧四：断点续传——Checkpoint/Resume 模式

当 Task 数量 > 15 个时，一场对话绝对不够。你需要主动分段执行 + 精确恢复。

4.1 内置神器 /rewind + “Summarize from here”

使用方式:
  1. 当对话超过 ~20 轮，感觉 AI 开始"忘记" → 按 Esc+Esc
  2. 选择当前 checkpoint
  3. 选择 "Restore conversation only + Summarize from here"
  
效果:
  → 旧对话被压缩为 AI 生成的摘要（~2K tokens）
  → 当前代码状态不变
  → 上下文空间释放 60-80%
  → AI "恢复记忆"——重新读取 Spec 文件后继续

4.2 手动 Checkpoint 三步法

不用任何插件，纯靠文件管理：

Step 1: 每个 Phase 完成后，生成 checkpoint 文件

👤: Phase 2 完成了。生成 cp-002.md 记录当前状态:
    - Phase 2 完成了哪些 Task
    - 你做了哪些关键决策
    - 下一个 Phase 从哪里开始
    - 过程中发现的注意事项

AI 生成的内容如：

# Checkpoint: Phase 2 完成

## 完成状态
- [x] T005: award_points() —— 已实现，测试通过
- [x] T006: spend_points() —— FIFO 扣减逻辑，测试通过
- [x] T007: expire_points() —— APScheduler 定时任务，测试通过
- [x] T008: refund_points() —— 退款回退积分，测试通过

## 关键决策
1. spend_points() 用 batches 表做 FIFO——每次消费先扣最早过期的 batch，不可部分扣
2. expire_points() 用 APScheduler，每天凌晨 3 点执行
3. 积分获取时机：支付成功即获取（不是确认收货）

## 注意事项
- batches.remaining 字段更新要在同一个事务中（否则并发会超扣）
- refund_points() 回退时，如果原 batch 已过期，积分回退到新 batch（有效期重置）

## 下一步
- Phase 3: API 层（T009-T011）
- 起点: 运行 /speckit.implement T009
- 注意: GET /api/points/balance 需要关联 points_accounts 表

Step 2: 开新对话，从 Checkpoint 恢复

👤: 继续用户积分系统的开发。先读 @specs/001-user-points/cp-002.md 了解当前状态。
    然后从 Phase 3 开始。这是新的对话，重新读一下 @specs/001-user-points/spec.md
    和 @specs/001-user-points/tasks.md。

Step 3: 循环

每完成一个 Phase → 更新 checkpoint → 视上下文情况决定是否开新对话。

4.3 Commit 作为 Checkpoint

每完成一个 Phase → Git commit:
  Phase 1 完成 → git commit -m "feat(points): Phase 1 数据层"
  Phase 2 完成 → git commit -m "feat(points): Phase 2 核心服务"
  Phase 3 完成 → git commit -m "feat(points): Phase 3 API 层"

好处:
  → git log 就是 checkpoint 链
  → 出问题可以精准回滚到某个 Phase
  → 新对话中 git log 即可了解进度

4.4 国产模型的断点续传特别注意

国产模型在恢复对话时:
  → 长对话恢复后，早期 Spec 信息的权重会明显下降
  → AI 可能"知道"之前做了什么，但"忘记"了为什么那样做

应对:
  → 不要依赖对话恢复
  → 开新对话 + checkpoint 文件（把关键决策显式写出来）
  → 新对话中说: "先读 @specs/.../spec.md 理解完整需求，
                再读 @specs/.../cp-002.md 了解当前进度，
                然后从 T009 开始"

---

技巧五：外部循环驱动——Ralph Loop 和任务队列

当内置的 TODO 驱动不够用时（比如 Claude Code 还是会停），用外部脚本强制循环。

5.1 最简方案：Bash While 循环

#!/bin/bash
# run_autonomous.sh —— 最简单的自动循环执行器

MAX_ITERATIONS=30
ITERATION=0

while [ $ITERATION -lt $MAX_ITERATIONS ]; do
  echo "=== Iteration $(($ITERATION + 1))/$MAX_ITERATIONS ==="

  claude --dangerously-skip-permissions -p "$(cat <<'PROMPT'
    你的任务是执行 specs/001-user-points/tasks.md 中所有未完成的 Task。

    规则:
    1. 从第一个未完成的 Task 开始
    2. 完成当前 Task（包括写代码 + 写测试 + 跑通测试）
    3. 更新 tasks.md，标记完成
    4. 如果所有 Task 都完成了，输出 "ALL_DONE"
    5. 如果遇到无法自动解决的阻塞，输出 "BLOCKED: <原因>"
    6. 如果 Task 执行失败（测试不通过），最多重试 3 次

    重要的上下文文件（每次执行都要读）:
    - specs/001-user-points/spec.md （完整需求）
    - specs/001-user-points/plan.md （技术方案）
    - specs/001-user-points/tasks.md （任务列表 + 进度）
PROMPT
  )" 2>&1 | tee "logs/iter_$(printf '%02d' $ITERATION).log"

  # 检查是否全部完成
  if grep -q "ALL_DONE" "logs/iter_$(printf '%02d' $ITERATION).log"; then
    echo "✅ 所有任务完成！"
    break
  fi

  # 检查是否被阻塞
  if grep -q "BLOCKED:" "logs/iter_$(printf '%02d' $ITERATION).log"; then
    echo "⚠️  任务被阻塞，请检查日志。"
    grep "BLOCKED:" "logs/iter_$(printf '%02d' $ITERATION).log"
    break
  fi

  ITERATION=$(($ITERATION + 1))
done

echo "执行了 $ITERATION 轮迭代。"

5.2 增强版：加入失速检测

#!/bin/bash
# 增强版：检测 AI 是否"假装在工作"（stall detection）

PREV_GIT_HASH=$(git rev-parse HEAD)
STALL_COUNT=0
MAX_STALL=3

for i in $(seq 1 30); do
  claude --dangerously-skip-permissions -p "$(cat PROMPT.md)" 2>&1 | tee "logs/iter_$i.log"

  CURRENT_GIT_HASH=$(git rev-parse HEAD)

  if [ "$CURRENT_GIT_HASH" == "$PREV_GIT_HASH" ]; then
    STALL_COUNT=$(($STALL_COUNT + 1))
    echo "⚠️  失速检测: $STALL_COUNT/$MAX_STALL 轮没有新提交"
    if [ $STALL_COUNT -ge $MAX_STALL ]; then
      echo "🔴 连续 $MAX_STALL 轮无进展，可能卡住了。退出。"
      break
    fi
  else
    STALL_COUNT=0  # 有进展，重置计数
    echo "✅ 检测到新提交: $(git log -1 --oneline)"
  fi

  PREV_GIT_HASH=$CURRENT_GIT_HASH

  if grep -q "ALL_DONE" "logs/iter_$i.log"; then
    echo "✅ 全部完成！"
    break
  fi
done

5.3 复杂度警告

外部循环方案好用但有限制：

优点:
  ✅ Claude 停了也能自动唤醒
  ✅ 日志完整（每轮迭代都有记录）
  ✅ 失速检测防止死循环

缺点:
  ❌ 每轮迭代 Claude Code 重新启动 → 每次都要重新读文件（token 消耗大）
  ❌ 上下文不连续 → 每轮的 AI 都是"新"的
  ❌ 需要精心设计 Prompt（每轮都要告诉 AI 当前状态）

适用场景:
  → 简单、重复性的 Task（格式化、修 lint、补测试）
  → 不需要复杂上下文理解的机械性工作

---

技巧六：Spec-Kit /speckit.implement 的三种执行策略

策略对比

策略 A: 逐个执行（零信任模式）
  /speckit.implement T001
  /speckit.implement T002
  /speckit.implement T003
  ...
  
  每个 Task 你审阅 → 通过 → 下一个
  适合: 核心模块、安全相关代码、不信任 AI 时

策略 B: 按 Phase 批量（平衡模式）★ 推荐
  /speckit.implement T001-T004    # Phase 1: 数据层
  → 你审阅
  /speckit.implement T005-T008    # Phase 2: 核心逻辑
  → 你审阅
  /speckit.implement T009-T011    # Phase 3: API 层
  → 你审阅
  
  每个 Phase 内部 Task 自动连续执行
  Phase 之间你审阅一次
  适合: 大多数场景

策略 C: 全量执行（信任模式）
  /speckit.implement
  
  所有 Task 一口气执行完
  适合: 已验证过的 Pattern、简单的 CRUD、你完全信任 Spec 质量时

批量执行的关键：标记并行任务

在 tasks.md 中正确标记 [P]（可并行）：

## Phase 1: 数据层（全部可并行——互不依赖）
- [ ] T001 [P] 创建 points_accounts 表
- [ ] T002 [P] 创建 points_transactions 表
- [ ] T003 [P] 创建 points_batches 表
- [ ] T004 数据库 Session 依赖（依赖 T001-T003 完成）

## Phase 2: 核心服务
- [ ] T005 award_points()        ← 依赖 T001, T002, T004
- [ ] T006 spend_points()        ← 依赖 T001, T002, T003, T004
- [ ] T007 [P] expire_points()   ← 依赖 T002, T003（与 T005/T006 独立）
- [ ] T008 [P] refund_points()   ← 依赖 T002, T003（与 T005/T006 独立）

铁律：两个 Task 修改同一个文件 → 不能标记 [P]，必须串行。

---

技巧七：验证闭环——AI 的"眼睛"

Anthropic 内部团队反复强调：要给 Claude 验证自己工作成果的能力。没有验证的 AI 像蒙着眼睛写代码。

基础验证：测试 + Lint

在 prompt 中明确要求：

每个 Task 完成后:
1. 写对应的单元测试
2. 运行测试 → 必须全绿
3. 运行 ruff check → 必须零错误
4. 以上两步任一失败 → 自己修复 → 重试最多 3 次 → 仍失败标记 ⚠️

进阶验证：业务逻辑断言

对于积分系统，在每个 Phase 完成后运行验证脚本:

```python
# verify_points.py —— 业务逻辑验证（每次 Phase 完成后运行）
def test_积分获取():
    result = award_points(user_id=1, order_amount=100.50)
    assert result.earned == 1005  # 100.50 × 10 向上取整

def test_积分不能为负():
    result = spend_points(user_id=1, amount=99999)
    assert result.spent <= current_balance  # 不能超扣

def test_FIFO扣减():
    # 先创建两批积分：第一批 30 天后过期，第二批 60 天后过期
    # 扣减 100 积分 → 应该先扣第一批
    ...

前端验证：让 AI 打开浏览器看

# Claude Code 可以控制浏览器验证 UI
👤: 实现登录页面后，打开 http://localhost:3000/login
    检查: 表单是否居中、按钮颜色是否正确、输入框 placeholder 是否显示

---

技巧八：国产模型全自动执行的生存指南

国产模型（DeepSeek/Qwen/GLM）做全自动执行时有几个 Claude Opus 不会遇到的问题：

问题 1: 长上下文中"自驱动"能力衰减

症状: 前 5 个 Task 正常自动推进，第 6 个开始"发呆"——
      完成当前 Task 后停下来不说"下一个"，也不报错

原因: 国产模型在 >40K Token 后，"记住当前任务是什么"的能力显著下降

应对:
  1. 每个 Task prompt 中重复关键指令: "完成后自动进入下一个 Task"
  2. 使用外部循环（while 脚本）而非依赖 AI 自驱动
  3. 把长链拆成短链: 每 5 个 Task 开新对话

问题 2: 错误修复时容易"改错东西"

症状: AI 发现测试失败 → 尝试修复 → 修了不该修的地方 → 引入新 Bug

应对:
  1. 限定修复范围: "只修改 src/quant_personal/strategy/ma_cross.py，不要动其他文件"
  2. 限制重试次数: "如果 2 次尝试后测试仍未通过 → 标记 ⚠️ 并继续下一个 Task，不要死循环"
  3. 每个 Task 的代码改动用小步提交（方便回滚单次修改）

问题 3: 对"已完成"的判断不准

症状: AI 可能认为 Task 完成了，但实际上:
      - 测试文件没写
      - Edge case 没处理
      - 函数签名与 Spec 不一致

应对:
  1. 不要让 AI 自己判断"是否完成"
  2. 用硬性验证标准（测试通过 + lint 零错误）作为"完成"的条件
  3. 在 prompt 中明确列出"完成的定义":
     一个 Task "完成" = 代码就位 + 测试全绿 + ruff check 零错误 + 手动验证脚本通过

---

完整实战：从 Spec 到完成不中断

把前面所有技巧组合起来，这是一次实战的执行脚本。

准备工作（一次性）

# 1. 项目结构就绪
cd ~/projects/quant-personal
specify init . --ai claude  # 如果还没初始化 Spec-Kit

# 2. 创建 Phase checkpoint 目录
mkdir -p .checkpoints

# 3. 完成 Spec 三件套
# specs/001-quant-core/spec.md    ← /speckit.specify 生成并审阅
# specs/001-quant-core/plan.md    ← /speckit.plan 生成并审阅
# specs/001-quant-core/tasks.md   ← /speckit.tasks 生成并审阅

# 4. 创建全自动执行 Prompt（一次性写好，每次迭代通用）

全自动执行 Prompt 模板

保存为 AUTOPILOT.md：

# AUTOPILOT MODE

你是 Quant Personal 项目的实现 Agent。你正在执行 specs/001-quant-core/tasks.md 中的任务。

## 执行规则

### 流程
1. 读取 tasks.md，找到第一个状态为 [ ] 的 Task
2. 实现该 Task（写代码 + 写测试）
3. 运行测试验证
4. 运行 ruff check 验证
5. 标记 Task 为 [x]（通过）或 ⚠️（阻塞）
6. 自动进入下一个 Task
7. 重复直到所有 Task 完成

### 质量门禁（每 Task 必须通过）
- [ ] 单元测试全绿
- [ ] ruff check 零错误
- [ ] 类型标注完整
- [ ] 不违反 Constitution 中的任何原则

### 阻塞处理
- 测试失败 → 最多重试 2 次 → 仍失败标记 ⚠️ + 记录原因 → 继续下一个
- 需要你无法获取的信息 → 标记 ⚠️ + 明确说明需要什么

### 上下文
- 每个 Task 开始前，读 spec.md 中对应的需求章节
- 参考 plan.md 中对应的设计
- 参考 constitution.md 中的原则

### 完成信号
- 所有 Task [x] 或 ⚠️ → 输出 "✅ AUTOPILOT COMPLETE"
- 汇总: 完成 N/M 个 Task，X 个阻塞

## 当前状态
开始前先检查 tasks.md 的完成情况，汇报:
"发现 N 个未完成 Task，从 Task X 开始执行"

执行

# 方式 1: Claude Code 内执行（单次）
👤: 进入 AUTOPILOT 模式。按 @AUTOPILOT.md 的规则执行。

# 方式 2: 外部循环（自动重启）
for i in $(seq 1 20); do
  echo "=== AUTOPILOT Round $i ==="
  claude --dangerously-skip-permissions \
         -p "按 @AUTOPILOT.md 的规则继续执行。当前是第 $i 轮。" \
         2>&1 | tee "logs/autopilot_round_$i.log"

  if grep -q "AUTOPILOT COMPLETE" "logs/autopilot_round_$i.log"; then
    echo "✅ 所有任务完成"
    break
  fi

  # 每 5 轮做一次上下文压缩
  if [ $(($i % 5)) -eq 0 ]; then
    echo "📦 第 $i 轮: 建议 /compact 上下文"
  fi
done

Phase 间审阅点

即使全自动，建议在以下节点停下来审阅：

审阅点 1: Phase 1 完成（数据层）
  → 数据库表结构是否正确
  → 迁移脚本是否可回滚
  → 审阅 diff + 跑一遍迁移

审阅点 2: 第一个核心 Service 完成（T005）
  → 这是后续所有 Task 的样板
  → 函数风格、错误处理、日志格式是否正确
  → 如果 T005 的风格对，后续 Task 大概率也对

审阅点 3: 第一个 API 完成（T009）
  → API 响应格式是否正确
  → 错误码规范是否一致
  → 用 curl 手动测试

审阅点 4: 全部完成
  → 完整 diff 审阅
  → 集成测试全量跑一遍
  → 覆盖率报告

---

执行模式速查表

场景                          首选策略                        备选策略
─────────────────────────────────────────────────────────────────────
1-3 Task 的小改动              直接对话                        —
3-10 Task 的中等功能           /goal（一行命令全自动）           TODO 自驱
10-20 Task 的大功能            /plan → /goal（先对齐再自动）    Spec-Kit 批量
20+ Task 的大型项目            /goal 分段执行 + checkpoint     Checkpoint + 外部循环

你对 AI 的信任度:
  不信任 → /goal 设 5 turn 上限（每 5 轮自动停） 或 逐个 Task 执行
  半信任 → /goal + until 硬性验证（测试 + lint 作为门禁）
  全信任 → /goal without strict constraints（全自动跑到底）

当 /goal 不适用时（无法量化完成条件、需要灵活流程控制）:
  3-10 Task  → TODO 自驱（按 Phase 批量，Phase 之间审阅）
  10-20 Task → Spec-Kit 批量 + 外部循环（每 5 Task 审阅一次）
  20+ Task   → Checkpoint + 外部循环（每 Phase 开新对话）

上下文管理:
  每 5 个 Task → 生成 checkpoint
  每 Phase → commit + 考虑是否开新对话
  每 15 轮 /goal → /goal clear → 检查进度 → 重新设定
  每 20 轮对话 → /rewind + Summarize from here
  每 30+ 轮 → 强制开新对话，从 checkpoint 恢复

---

总结

这篇文章的核心交付：

1. /goal——内置原生方案：Claude Code v2.1.139 内置的自主执行命令。设定目标任务 + 可度量完成条件 + 约束，AI 自动运行到完成为止。独立评估模型每轮验证，防止"AI 觉得自己做完了但其实没做完"。

2. 自主执行的本质障碍：上下文衰减 + 权限弹窗 + AI 缺乏自驱力，三者叠加导致长任务不可持续。

3. TODO 自驱：当 /goal 不适用时的替代方案——给 AI 明确的"完成后自动下一个"指令，按 Phase 批量执行。

4. 权限放权：渐进式——default → acceptEdits → auto（或直接 /goal 在信任工作区运行）。

5. Stop Hook 验证闭环：AI 完成不等于通过，自动跑测试 + lint 作为停止条件。

6. 断点续传：每 Phase 一个 checkpoint 文件 + git commit，开新对话从 checkpoint 恢复。

7. 外部循环：Bash while 循环 + 失速检测，AI 停了也自动唤醒（当内置 /goal 无法使用时）。

8. 国产模型特别要点：/goal 分段使用（15 轮上限）、Prompt 中重复关键指令、用硬性标准而非 AI 自判断"完成"。

最终公式：

全自动执行成功 = 
    /goal（或等价的自主执行策略）
  × Spec 文档（AI 的外置大脑）
  × 可度量的完成条件（不让评估模型猜）
  × 自动验证门禁（测试 + lint）
  × 分段兜底（turn 上限 + checkpoint）

---

延伸阅读

• Claude Code 官方高级技巧
• Claude Code Checkpointing 文档