1. 概述

是什么：基于 Claude Code（可一键切换到 OpenAT Codex）的自动化研发任务编排体系。将"需求→spec→任务拆解→循环执行→多层验证→仅高危转人工→交付"全流程自动化。

解决什么：AI 辅助研发中三个核心痛点：

  • 需求理解偏差 — 通过结构化 spec 模板和 planner agent 消除歧义

  • 执行质量不可控 — 三层验证门（确定性门+结构化评审+人工门）层层把关

  • 人工反复介入 — 仅 P0/P1 高危问题转人工，P3 自动修复，P2 批量放行

一句话用法：./orchestrator/run.sh "实现用户登录功能，支持 JWT 认证"

三种模式一句话区分：

  • 手动分步：/plan → /goal → /loop → /verify，透明调试每一步

  • 全自动：./orchestrator/run.sh "一句话需求"，全程无人值守

  • watch 续跑：./orchestrator/watch.sh 启动监听，人工放行 blocked 任务后自动续跑

2. 整体架构

自动化研发任务编排体系采用五层分层架构，自上而下依次为：命令声明层 → 编排脚本层 → 多Agent层 → 验证门层 → 状态持久化层。

层与层之间通过明确的调用接口（向下）和数据回流（向上）进行交互，保证每层职责单一、可独立替换。

五层总架构图

分层表

​

层级 名称 核心组件 职责
① 命令/Skill声明层 /plan, /goal, /loop, /verify + 对应 SKILL.md 提供人机交互入口，声明可复用能力定义
② 编排脚本层 run.sh, loop.sh, watch.sh, resume.sh 编排执行流程，控制循环、并行、熔断、超时
③ 多Agent层 planner, executor, reviewer（独立上下文） 规划不写码、执行不自评、评审独立（交叉评审）
④ 验证门层 门1确定性门 → 门2结构化评审 → 门3人工门 三层递进验证，仅高危转人工
⑤ 状态层 specs/spec.md, goals/goal.json 持久化需求规格和任务状态，支持断点续跑

​

3. 核心概念

四个核心命令构成完整研发闭环：

​

命令 职责 输入 产物 调用Agent
/plan 将一句话需求转为结构化 spec 文档 自然语言需求 specs/spec.md planner agent
/goal 将 spec 拆成可执行任务（带状态、依赖） specs/spec.md goals/goal.json planner agent
/loop 循环/并行调用 Agent 执行任务 goals/goal.json 代码变更 + 执行记录 executor + reviewer
/verify 多层验证 + 多Agent交叉评审，仅高危转人工 全部任务产物 验证报告 reviewer agent

​

任务状态机

todo ──→ in_progress ──→ done
  ↑                         
  │        ┌─ P0/P1 → blocked（人工）
  │        ├─ P2    → blocked（批量放行）
  └─ P3 自动修复 ←──┤
           └─ 门失败 → 重试(iter+1)

4. 三种运行模式

4.1 手动分步（透明调试）

适合开发调试、首次使用、理解内部流程：

# 终端中逐步执行
/plan "实现用户登录功能，支持 JWT 认证"
# → 审阅 specs/spec.md
​
/goal
# → 审阅 goals/goal.json 任务列表
​
/loop
# → 观察每个任务的执行/门控/评审过程
​
/verify
# → 最终全量验证

4.2 全自动 run.sh

一句话需求，全程无人值守。推荐日常使用。

流水线图

命令
# 基础用法
./orchestrator/run.sh "实现用户登录功能"
​
# 开启 spec 人工审批（安全敏感需求）
REQUIRE_SPEC_APPROVAL=1 ./orchestrator/run.sh "实现支付模块"
​
# 干跑测试链路
DRY_RUN=1 ./orchestrator/run.sh "测试需求"
​
# 调大并行度
PARALLEL=4 ./orchestrator/run.sh "重构整个模块"

4.3 watch 自动续跑

适合长期项目、需要人工审核的复杂任务。

放行表
blocked 原因 放行方式 命令
P1 高危（已人工确认修复） 全部放行 ./orchestrator/resume.sh
P2 中危（批量处理） 仅放行 P2 ./orchestrator/resume.sh p2
特定任务 blocked 指定放行 ./orchestrator/resume.sh task-03
操作步骤
# 终端1：启动 watch 监听
./orchestrator/watch.sh
​
# 终端2：丢需求
./orchestrator/run.sh "实现用户头像上传"
​
# watch 检测到 blocked 任务后提示：
#   🔴 人工门：3 个任务等待处理
#   放行命令: ./orchestrator/resume.sh
​
# 人工处理完问题后：
./orchestrator/resume.sh
# watch 自动检测到 todo 变化 → 自动续跑 loop.sh

5. 快速上手

使用流程图

端到端命令序列

# ── 第1步：安装前置依赖（30秒） ──
brew install jq
# 确保 claude CLI 已安装并登录
​
# ── 第2步：获取工程并配置（30秒） ──
cd claude-code-impl
chmod +x orchestrator/*.sh hooks/*.sh
​
# ── 第3步：干跑测试（30秒） ──
DRY_RUN=1 ./orchestrator/run.sh "测试：输出 hello world"
# 应看到完整的5步流程输出，全部标记 [DRY_RUN]
​
# ── 第4步：首次正式运行（3分钟） ──
# 终端1：启动 watch
./orchestrator/watch.sh
​
# 终端2：丢入真实需求
./orchestrator/run.sh "在项目根目录创建一个 hello.py，打印 Hello World"
​
# ── 第5步：观察与交付 ──
# watch 终端会实时显示任务状态变化
# 最终生成 DELIVERY.md 交付报告

常见问题排查表

​

问题 原因 解决
jq: command not found jq 未安装 brew install jq
claude: command not found Claude CLI 未安装 按官方文档安装 Claude Code CLI
Permission denied 运行 .sh 脚本无可执行权限 chmod +x orchestrator/*.sh hooks/*.sh
goal.json 不存在 未执行 /plan 和 /goal 先执行 run.sh 或手动 /plan → /goal
任务一直 blocked 不继续 P0/P1 高危需人工确认 检查问题 → 修复 → ./orchestrator/resume.sh
loop 中途退出码 3 超预算（TIMEOUT） 增大 TIMEOUT=1200 或检查任务复杂度
loop 中途退出码 4 超迭代（MAX_ITERS） 增大 MAX_ITERS=5 或检查任务是否合理
DRY_RUN=1 仍执行了真实操作 Claude CLI 不支持 hook 拦截 正常，DRY_RUN 主要控制脚本层面的调用

​

6. 工程实现与目录结构

目录树

claude-code-impl/
├── CLAUDE.md                          # 项目宪法（规则：规划不写码、执行不自评、评审独立）
├── README.md                          # 使用说明（三种模式 + 环境变量）
├── DELIVERY.md                        # 交付报告（run.sh 自动生成）
├── .claude/
│   ├── settings.json                  # hooks + permissions 配置
│   ├── commands/                      # 斜杠命令入口（人工交互用）
│   │   ├── plan.md                    # /plan — 需求→Spec
│   │   ├── goal.md                    # /goal — Spec→任务
│   │   ├── loop.md                    # /loop — 循环执行
│   │   ├── verify.md                  # /verify — 多层验证
│   │   └── ship.md                    # /ship — 最终交付
│   ├── skills/                        # 可复用能力定义
│   │   ├── plan/SKILL.md              # Plan Skill
│   │   ├── goal/SKILL.md              # Goal Skill
│   │   └── verify/SKILL.md            # Verify Skill
│   └── agents/                        # 子代理定义
│       ├── planner.md                 # 规划者（只产出文档）
│       ├── executor.md                # 执行者（不自评）
│       └── reviewer.md                # 评审者（独立上下文，交叉评审）
├── orchestrator/                      # 编排脚本（核心）
│   ├── run.sh                         # 全自动入口（5步流水线）
│   ├── loop.sh                        # 循环编排器（执行→门→评审→分流）
│   ├── watch.sh                       # 常驻监听器（检测 blocked→todo 自动续跑）
│   ├── resume.sh                      # 一键放行 blocked 任务
│   └── review.schema.json             # 评审结构化输出 Schema
├── hooks/
│   └── verify_gate.sh                 # 确定性门（测试/Lint/Build）
├── goals/
│   └── goal.example.json              # 任务状态样例
├── specs/
│   └── spec.template.md               # Spec 模板
└── diagrams/                          # 架构图
    ├── architecture.html              # 五层总架构图
    ├── pipeline.html                  # 全自动流水线图
    ├── usage-flow.html                # 使用流程图
    └── verify-sequence.html           # Verify 时序图

共 22 个源文件 + 4 个架构图

关键环境变量速查表

​

变量 默认值 说明 示例
DRY_RUN 0 干跑模式，仅打印不执行 DRY_RUN=1
MAX_ITERS 3 单任务最大重试迭代次数 MAX_ITERS=5
TIMEOUT 600 单任务超时（秒） TIMEOUT=1200
PARALLEL 1 并行执行任务数 PARALLEL=4
PERMISSION_MODE default Claude Code 权限模式 PERMISSION_MODE=acceptEdits
REQUIRE_SPEC_APPROVAL 0 Spec 生成后需人工审批 REQUIRE_SPEC_APPROVAL=1
WATCH_INTERVAL 10 watch 轮询间隔（秒） WATCH_INTERVAL=5
WATCH_EXIT_WHEN_DONE 0 全部 done 后 watch 自动退出 WATCH_EXIT_WHEN_DONE=1

​

7. 验证体系

三层门架构

​

门 名称 执行者 判定方式 失败处理
门1 确定性门 verify_gate.sh 退出码（0=通过, 8=失败） 自动重试（最多 MAX_ITERS 次）
门2 结构化评审 reviewer agent（独立上下文） review.schema.json 结构化输出 按 severity 分流
门3 人工门 人类开发者 人工判断 仅 P0/P1 高危触发

​

Severity 分流规则

Severity 判定标准 处理方式 是否转人工
P0 — 阻断 安全漏洞、数据丢失、系统崩溃 立即 blocked ✅ 是
P1 — 高危 功能缺陷、逻辑错误、边界未处理 blocked + 交叉评审 ✅ 是
P2 — 中危 性能问题、代码异味、规范违反 blocked，可批量放行 可选（resume.sh）
P3 — 低危 命名建议、注释缺失、格式问题 自动修复，重试 否

Verify 时序图

8. 风险与边界

已知风险

风险 影响 缓解措施
Claude API 不可用 全流程阻塞 切换到 OpenAT Codex（claude -p → codex exec）
单次 Agent 调用耗时过长 超预算熔断 TIMEOUT 环境变量控制，默认 600s
reviewer 评审不准确 误报/漏报 交叉评审（P0/P1 启动 Reviewer-B 复核）
任务依赖循环 死锁 planner 生成 DAG 时校验无环
脚本语法错误（bash 版本差异） 脚本执行失败 set -euo pipefail + DRY_RUN 预检
人工门积累过多 blocked 进度停滞 resume.sh 支持批量放行 P2

切换到 OpenAT Codex

所有编排脚本（loop.sh, run.sh）中已内置切换注释：

# 切换到 Codex：将 claude -p 替换为 codex exec

操作步骤：

# 全局替换
cd claude-code-impl
sed -i '' 's/claude -p/codex exec/g' orchestrator/loop.sh
sed -i '' 's/claude -p/codex exec/g' orchestrator/run.sh
​
# 验证
grep 'codex exec' orchestrator/loop.sh orchestrator/run.sh

其余参数（--output-format json）、退出码逻辑、门控流程保持一致。

边界说明

  • 适用场景：中小型功能开发、bug修复、代码重构、测试编写

  • 不适用场景：跨系统架构变更、需要大量外部协调的任务、安全审计

  • 人工始终在回路中：P0/P1 高危必须人工确认，不会全自动跳过

9. 附录

附录A：命令与退出码速查表

命令速查
命令 用法 说明
/plan /plan "需求" 生成 spec 文档
/goal /goal 拆解为任务列表
/loop /loop 循环执行任务
/verify /verify 最终验证
/ship /ship 交付报告
run.sh ./orchestrator/run.sh "需求" 全自动一条龙
loop.sh ./orchestrator/loop.sh 仅执行循环
watch.sh ./orchestrator/watch.sh 常驻监听
resume.sh ./orchestrator/resume.sh [all\|p2\|task-id] 放行 blocked
退出码速查
退出码 常量含义 触发条件 处理方式
0 SUCCESS 全部任务 done 正常结束
1 GENERAL_ERROR 一般错误 检查日志
2 BLOCKED 任务 blocked（P0/P1/P2 或重试超限） 人工处理 → resume.sh
3 BUDGET_EXCEEDED 超预算（TIMEOUT） 增大 TIMEOUT 或简化任务
4 ITER_EXCEEDED 超迭代（MAX_ITERS） 增大 MAX_ITERS 或检查任务
7 SPEC_REJECTED Spec 门未通过（人工驳回） 修改需求描述重试
8 GATE_FAILED 确定性门失败（测试/Lint/Build） 检查代码质量
9 REVIEW_FAILED 评审未通过 查看 reviewer issues
10 SPEC_PENDING Spec 待人工审批 审阅 spec 后批准

附录B：从零到跑通（零基础完整手册）

B.1 前置依赖
# macOS
brew install jq
​
# Linux (Ubuntu/Debian)
sudo apt-get install jq
​
# Linux (CentOS/RHEL)
sudo yum install jq
​
# Windows (通过 WSL 或 Git Bash)
# 推荐使用 WSL2 + Ubuntu，然后按 Linux 步骤操作
B.2 Claude CLI 安装
# 方式1：npm 全局安装
npm install -g @anthropic-ai/claude-code
​
# 方式2：直接下载二进制
# 访问 https://claude.ai/code 下载对应平台版本
​
# 验证安装
claude --version
​
# 登录
claude login
B.3 获取工程
# 解压 claude-code-impl.zip 到工作目录
unzip claude-code-impl.zip -d ~/projects/
cd ~/projects/claude-code-impl
B.4 首跑步骤
# 1. 赋权
chmod +x orchestrator/*.sh hooks/*.sh
​
# 2. 干跑测试（验证整条链路）
DRY_RUN=1 ./orchestrator/run.sh "测试：print hello"
​
# 预期输出：
# [RUN] 步骤1/5：生成 Spec 文档
# [RUN] 步骤2/5：拆解为可执行任务
# [RUN] 步骤3/5：执行任务循环
# [LOOP] 🎉 全部任务已完成！
# [RUN] 步骤4/5：最终验证
# [RUN] 步骤5/5：交付
# [RUN] 🎉 全自动流程完成
​
# 3. 首次真实运行（简单需求）
./orchestrator/run.sh "在项目根目录创建 hello.py，打印'Hello World'"
​
# 4. 观察产物
cat specs/spec.md        # 需求规格
cat goals/goal.json      # 任务状态
cat DELIVERY.md          # 交付报告
B.5 进阶用法
# 带 spec 审批的安全敏感需求
REQUIRE_SPEC_APPROVAL=1 ./orchestrator/run.sh "实现支付回调接口"
​
# 并行执行（4个任务同时跑）
PARALLEL=4 MAX_ITERS=5 ./orchestrator/run.sh "重构用户模块"
​
# 长期项目 watch 模式
# 终端1
WATCH_EXIT_WHEN_DONE=1 ./orchestrator/watch.sh
# 终端2
./orchestrator/run.sh "实现整个用户CRUD功能"
# 遇到 blocked → 人工处理 → ./orchestrator/resume.sh

附录C：完整源码清单

以下按目录分组，每文件标路径+完整代码块。共 22 个源文件。

C.1 项目根目录

CLAUDE.md — 项目宪法

# CLAUDE.md — 项目宪法
​
## 核心规则
​
### 1. 规划不写码
- planner agent 只产出 spec 和 task 计划，绝不修改任何源代码
- 所有规划输出必须写入 `specs/` 或 `goals/` 目录
​
### 2. 执行不自评
- executor agent 只负责执行任务，不得评审自己的产出
- 执行完成后必须通过 verify_gate 确定性门，再由 reviewer agent 独立评审
​
### 3. 评审独立
- reviewer agent 拥有独立上下文，不与 executor 共享对话历史
- reviewer 必须参照 `review.schema.json` 输出结构化评审结果
- 交叉评审：高危问题(P1/P2)触发第二个 reviewer 进行独立复核
​
## 运行模式
​
| 模式 | 入口 | 说明 |
|------|------|------|
| 手动分步 | 斜杠命令 `/plan` `/goal` `/loop` `/verify` | 人工逐步触发，透明调试 |
| 全自动 | `orchestrator/run.sh` | 一句话需求 → 自动跑完全程 |
| watch 续跑 | `orchestrator/watch.sh` | 监听 goal.json，人工放行后自动续跑 |
​
## 环境变量
​
| 变量 | 默认值 | 说明 |
|------|--------|------|
| `DRY_RUN` | `0` | 1=仅打印不执行 |
| `MAX_ITERS` | `3` | 单任务最大重试迭代次数 |
| `TIMEOUT` | `600` | 单任务超时(秒) |
| `PARALLEL` | `1` | 并行执行任务数 |
| `PERMISSION_MODE` | `default` | Claude Code 权限模式 |
| `REQUIRE_SPEC_APPROVAL` | `0` | 1=spec 生成后需人工审批才继续 |
| `WATCH_INTERVAL` | `10` | watch 模式轮询间隔(秒) |
| `WATCH_EXIT_WHEN_DONE` | `0` | 1=全部任务完成后 watch 自动退出 |
​
## 切换到 OpenAT Codex
​
在所有编排脚本中，将 `claude -p` 替换为 `codex exec` 即可。详见各脚本注释。

README.md — 使用说明（详见上文第4节及项目文件）

C.2 .claude/settings.json

.claude/settings.json

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "[[ -n \"${DRY_RUN:-}\" && \"${DRY_RUN}\" == \"1\" ]] && echo \"[DRY_RUN] 跳过实际执行\" && exit 1 || true"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"[$(date '+%H:%M:%S')] 工具调用完成\" >> /tmp/claude-code-audit.log"
          }
        ]
      }
    ]
  },
  "permissions": {
    "allow": [
      "Bash(git:*)",
      "Bash(npm:*)",
      "Bash(npx:*)",
      "Bash(node:*)",
      "Bash(cat:*)",
      "Bash(ls:*)",
      "Bash(find:*)",
      "Bash(grep:*)",
      "Bash(mkdir:*)",
      "Bash(echo:*)",
      "Bash(jq:*)",
      "Bash(curl:*)",
      "Bash(chmod:*)",
      "Bash(brew:*)",
      "Bash(python:*)",
      "Bash(pytest:*)",
      "Bash(go:*)",
      "Bash(cargo:*)",
      "Bash(claude:*)",
      "Bash(codex:*)",
      "Bash(./orchestrator/*)",
      "Bash(./hooks/*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(sudo:*)",
      "Bash(shutdown:*)",
      "Bash(reboot:*)"
    ]
  },
  "env": {
    "CLAUDE_CODE_PROJECT": "claude-code-impl"
  }
}
C.3 .claude/commands/ — 斜杠命令（5个文件）

.claude/commands/plan.md

# /plan — 将一句话需求转为 spec 文档与计划
​
## 用法
/plan "你的需求描述"
​
## 功能
1. 接收自然语言需求
2. 调用 `planner` agent 进行需求分析
3. 生成结构化 spec 文档（按 `specs/spec.template.md` 模板）
4. 如 `REQUIRE_SPEC_APPROVAL=1`，暂停等待人工确认
5. 输出保存至 `specs/spec.md`
​
## 产物
- `specs/spec.md` — 结构化需求规格文档
​
## 关联
- 下一步：`/goal` 将 spec 拆解为可执行任务
- 对应 Skill：`.claude/skills/plan/SKILL.md`
- 对应 Agent：`.claude/agents/planner.md`

.claude/commands/goal.md

# /goal — 将 spec 拆成可执行长期任务（带状态、依赖）
​
## 用法
/goal
​
## 前置条件
- `specs/spec.md` 必须存在（由 `/plan` 生成）
​
## 功能
1. 读取 `specs/spec.md`
2. 调用 `planner` agent 进行任务拆解
3. 生成 `goals/goal.json`，每个任务包含：id, title, description, status, depends_on, severity
​
## 产物
- `goals/goal.json` — 可执行任务列表（参照 `goals/goal.example.json` 格式）

.claude/commands/loop.md

# /loop — 循环/并行地调用 Agent 执行任务
​
## 用法
/loop
​
## 功能
1. 读取 `goals/goal.json` 获取任务列表
2. 按依赖拓扑排序，找出所有可执行任务
3. 按 `PARALLEL` 环境变量并行度，并发启动 executor agent
4. 每个任务：executor → verify_gate → reviewer → severity 分流
5. 循环直到：全部 done / 超迭代 / 超预算
​
## 退出码
0=全部done | 2=blocked | 3=超预算 | 4=超迭代 | 8=门失败 | 9=评审未通过

.claude/commands/verify.md

# /verify — 多层验证 + 多 Agent 交叉评审，仅高危才转人工
​
## 用法
/verify
​
## 功能
1. 收集所有任务的执行产物
2. 执行三层验证门：确定性门 → 结构化评审 → 人工门（仅高危）
3. 低危(P3)自动修复并重跑门1
4. 输出最终验证报告
​
## Severity 分流
P0阻断→blocked转人工 | P1高危→blocked+交叉评审 | P2中危→blocked可批量放行 | P3低危→自动修复

.claude/commands/ship.md

# /ship — 最终交付，汇总所有产物
​
## 用法
/ship
​
## 功能
1. 汇总所有任务执行记录
2. 生成 CHANGELOG 摘要
3. 输出交付清单：修改文件、测试用例、验证报告
4. 标记 `goals/goal.json` 中所有任务为最终交付状态
​
## 产物
- `DELIVERY.md` — 交付报告
C.4 .claude/skills/ — 可复用能力（3个文件）

.claude/skills/plan/SKILL.md

# Plan Skill — 需求分析与 Spec 生成
​
## 概述
将自然语言需求转化为结构化的技术规格文档（spec）。
​
## 输入
- 自然语言需求描述（字符串）
​
## 输出
- `specs/spec.md` — 结构化规格文档，包含：需求概述、功能需求(FR)、非功能需求(NFR)、技术约束、验收标准(AC)、风险识别
​
## 流程
1. 解析用户需求，识别核心意图
2. 调用 planner agent 进行深度分析
3. 按 `specs/spec.template.md` 模板生成文档
4. 若 `REQUIRE_SPEC_APPROVAL=1`，暂停等待人工确认
5. 写入 `specs/spec.md`
​
## 规划不写码原则
此阶段只产出文档，绝不修改任何源代码。

.claude/skills/goal/SKILL.md

# Goal Skill — Spec 拆解为可执行任务
​
## 概述
将 spec 文档拆解为结构化的可执行任务列表，标注依赖关系和状态。
​
## 输入
- `specs/spec.md` — 由 Plan Skill 生成
​
## 输出
- `goals/goal.json` — 任务列表 JSON，每个任务包含 id/title/description/status/depends_on/max_iters/timeout/severity
​
## 任务状态机
todo → in_progress → done
↑                    ↓ (P3 自动修复)
blocked (P0/P1/P2) → todo (resume.sh 放行)
​
## 拆解原则
1. 每个任务独立可验证
2. 依赖关系形成 DAG（无环）
3. P0 任务优先（核心功能路径）
4. 粒度适中：单任务不超过 30 分钟工作量

.claude/skills/verify/SKILL.md

# Verify Skill — 多层验证与交叉评审
​
## 概述
对执行结果进行三层验证：确定性门 → 结构化评审 → 人工门。
​
## 三层验证门
### 门1 — 确定性门（verify_gate.sh）
测试套件 + Linter + 构建检查，退出码判定
​
### 门2 — 结构化评审（reviewer agent）
独立上下文 reviewer，按 review.schema.json 输出结构化结果
交叉评审：P1/P2 问题触发第二个 reviewer 独立复核
​
### 门3 — 人工门
默认全自动放行，仅 P0/P1 高危触发人工
​
## Severity 分流
P0阻断→blocked | P1高危→blocked+交叉评审 | P2中危→blocked批量放行 | P3低危→自动修复
C.5 .claude/agents/ — 子代理定义（3个文件）

.claude/agents/planner.md

# Planner Agent — 需求分析与任务规划
​
## 角色
你是一位资深技术架构师和项目经理。你的职责是规划，绝不写代码。
​
## 核心规则
1. 只产出文档，不修改任何源代码
2. 输出的 spec 必须结构化、可验证
3. 任务拆解必须形成 DAG，每个任务独立可完成
​
## 输出格式
- Spec 文档（specs/spec.md）：严格按模板
- 任务列表（goals/goal.json）：id/title/description/status/depends_on/severity
​
## Severity 定义
P0阻断级/核心路径 | P1高危/重要功能 | P2中危/改进项 | P3低危/锦上添花

.claude/agents/executor.md

# Executor Agent — 任务执行者
​
## 角色
你是高效的代码实现者。你的职责是执行任务，不评审自己。
​
## 核心规则
1. 只执行，不自评：评审由 reviewer agent 独立完成
2. 严格按照任务描述和验收标准执行
3. 遵循项目现有代码风格和架构模式
4. 每次修改后确保代码可编译/可运行
​
## 输出
```json
{
  "task_id": "task-01",
  "status": "done",
  "summary": "完成了什么",
  "files_changed": ["path/to/file1.ts"],
  "test_results": "测试结果摘要"
}
​
**`.claude/agents/reviewer.md`**
​
```markdown
# Reviewer Agent — 独立上下文交叉评审
​
## 角色
你是严格的代码评审者。你拥有独立上下文，不与 executor 共享对话历史。
​
## 核心规则
1. 独立上下文：不与 executor 共享任何对话历史
2. 只看最终产出：评审的是代码变更结果
3. 结构化输出：严格按 review.schema.json 输出
4. 交叉评审：P1/P2 问题触发第二个 reviewer 独立复核
​
## 评审维度
correctness(正确性) | security(安全) | performance(性能) | style(风格) | testing(测试) | architecture(架构)
​
## 输出格式
严格按 orchestrator/review.schema.json 输出
C.6 orchestrator/ — 编排脚本（5个文件）

完整源码见工程文件 claude-code-impl/orchestrator/*.sh，此处列出关键逻辑摘要：

  • run.sh (~300行)：5步流水线（生成Spec → 拆任务 → loop → 验证 → 交付），支持 DRY_RUN 和 REQUIRE_SPEC_APPROVAL

  • loop.sh (~370行)：核心循环逻辑，包含任务获取、executor调用、确定性门、reviewer评审、severity分流、并行控制、超时/迭代熔断

  • watch.sh (~130行)：常驻监听 goal.json 变化，检测 blocked→todo 自动触发 loop.sh

  • resume.sh (~100行)：一键放行 blocked 任务，支持 all/p2/指定task-id 三种模式

  • review.schema.json：JSON Schema 定义评审输出格式（passed, issues[].severity, cross_review）

C.7 hooks/ — 确定性门

hooks/verify_gate.sh (~140行)：自动检测项目类型（Node/Python/Go/Rust），运行测试、Lint、构建，按退出码判定。

C.8 goals/ 和 specs/ — 数据模板

  • goals/goal.example.json：8个示例任务的完整 goal.json

  • specs/spec.template.md：9节 spec 模板

附录D：完整工程下载

📦 claude-code-impl.zip — 包含全部 22 个源文件 + 4 个架构图的完整工程

下载后解压即可使用：

unzip claude-code-impl.zip
cd claude-code-impl
chmod +x orchestrator/*.sh hooks/*.sh
DRY_RUN=1 ./orchestrator/run.sh "测试"
# golang
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

2026年7月，我把 chatGPT 用进日常开发后的 8 个真实场景（plus pro充值）

很多人第一次使用 GPT，都会有一种很强的新鲜感。随便问一个问题，它能回答；让它写一段代码，它能生成；给它一段英文，它能翻译；让它写一篇文章，它也能输出。刚开始看起来很神奇，但真正用了一段时间以后，很多人又会产生新的疑问：GPT 到底能不能真正提高工作效率？如果只是偶尔问几个问题，它确实像一个高级搜索工具。但如果把它放进日常开发流程里，它的价值就不只是“回答问题”这么简单。对开发者来说，日常工作并

avatar AI编程社区

2026年7月 使用 GPT 和CODEX常见问题整理：登录、订阅、续费和账号管理思路

这两年，GPT 类 AI 工具已经从一个新鲜工具，慢慢变成很多人工作里的固定助手。开发者用它看代码、查报错、写测试、读文档。运营人员用它写方案、整理资料、拆解内容。产品经理用它写需求、梳理流程、总结会议。跨境从业者用它翻译资料、分析平台规则、整理英文说明。技术博主用它搭文章结构、生成 Markdown、优化表达。很多人一开始关注的问题是：GPT 到底好不好用？

avatar AI编程社区

2026 年 7 月，程序员如何把 CHATGPT 放进开发工作流：从需求到上线（plus pro充值)）的完整实践

很多程序员第一次使用 GPT，通常都是从几个简单场景开始的。帮我写一个函数；帮我解释一段代码；帮我看一个报错；帮我写一个 SQL；帮我生成一段接口文档。刚开始确实会觉得很惊艳，因为很多原本需要搜索半天的问题，它几分钟就能给出思路。但用了一段时间以后，很多人会发现一个问题：如果只是零散地问几句，效率提升其实有限。真正能改变开发效率的，不是偶尔问 GPT 一个问题，而是把 GPT 放进完整开发流程里。

avatar AI编程社区