第 12 课：调用链追踪 — 从 Command 到执行

王小酱
7 阅读7分钟

所属阶段：第三阶段「工作流实战」（第 12-20 课） 前置条件：第 4-11 课（所有组件已掌握） 本课收获：能追踪任意命令的完整调用链，理解组件如何串联

一、本课概述

学完六大组件之后，最关键的一步是理解它们如何串联。ECC 不是一堆独立的零件，而是一条精密的流水线。

本课回答三个问题：

  1. Command 是什么角色？ — 它正在被 Skill 替代，为什么？
  2. 一个命令从输入到执行经历了哪些节点？ — 追踪三条完整调用链
  3. 79 个命令怎么分类记忆？ — 建立全局地图，重点记 5 个

理解调用链之后，你遇到任何 ECC 命令，都能快速定位它背后的 Skill、Agent 和 Rule。

二、Command 的角色定位

2.1 Legacy Slash-Entry Shim

打开任意一个 Command 文件（如 commands/tdd.md），你会看到这样的描述：

---
description: Legacy slash-entry shim for the tdd-workflow skill. Prefer the skill directly.
---

关键词：Legacy Slash-Entry Shim（遗留的斜杠入口垫片）。

这意味着 Command 的定位正在发生变化：

阶段Command 的角色说明
早期主要入口用户通过 /tdd 触发完整工作流
当前兼容性垫片工作流逻辑已迁移到 Skill，Command 只是转发
未来可能淘汰Skill 成为主要入口，Command 保留向后兼容

2.2 为什么迁移到 Skill

Command 是一个扁平的入口 — 它只能定义"做什么"，但不擅长承载"怎么做"的详细知识。

Skill 是一个结构化的知识包 — 它包含 When to Use、How It Works、Examples 等完整的上下文。

Command（旧）：/tdd → 直接内嵌工作流步骤（维护困难，容易过时）
Skill（新）：/tdd → commands/tdd.md → skills/tdd-workflow/SKILL.md（逻辑集中维护）

迁移的好处：

  • 单一来源：工作流逻辑只在 Skill 中维护，Command 只做转发
  • 可复用：Agent 也可以直接引用 Skill，不需要通过 Command
  • 可测试：Skill 的结构化格式更容易验证正确性

三、调用链追踪 — 三个实例

3.1 调用链一：/tdd

这是最完整的调用链，涉及所有组件类型：

用户输入：/tdd

    │
    ▼
commands/tdd.md                    ← Command（入口垫片）
    │ "Apply the tdd-workflow skill"
    ▼
skills/tdd-workflow/SKILL.md       ← Skill（工作流知识）
    │ "Use tdd-guide agent"
    ▼
agents/tdd-guide.md                ← Agent（执行者）
    │ model: sonnet
    │ tools: Read, Write, Edit, Bash, Grep
    │ "Enforce RED-GREEN-REFACTOR"
    ▼
rules/common/testing.md            ← Rule（约束条件）
    │ "80% coverage, AAA pattern"
    ▼
rules/common/coding-style.md       ← Rule（代码质量）
    │ "Immutability, <50 lines per function"
    ▼
执行完毕 → 代码 + 测试 + 覆盖率报告

关键观察：

  • Command 不做任何实质工作，只是一个路由器
  • Skill 承载完整的工作流定义
  • Agent 是实际的执行者，带有模型配置和工具权限
  • Rule 是 Agent 执行时必须遵守的约束

3.2 调用链二：/plan

用户输入：/plan

    │
    ▼
commands/plan.md                   ← Command（入口）
    │ "Invokes the planner agent"
    ▼
agents/planner.md                  ← Agent（执行者）
    │ model: opus             ← 注意：用最强模型
    │ tools: Read, Grep, Glob ← 注意：只读不写
    │ "Requirements → Architecture → Steps → Order"
    ▼
rules/common/development-workflow.md ← Rule（流程约束）
    │ "Research & Reuse → Plan → TDD → Review → Commit"
    ▼
输出：结构化实施计划（等待用户确认后才执行）

关键观察：

  • Planner 的工具只有 Read/Grep/Glob — 只读不写，这是 Plan Before Execute 原则的落地
  • 使用 Opus 模型 — 规划需要最强的推理能力
  • 必须等待用户确认 — "WAIT for user CONFIRM before touching any code"

3.3 调用链三：/code-review

用户输入：/code-review

    │
    ▼
commands/code-review.md            ← Command（入口）
    │ 判断模式：PR 模式 or 本地模式
    ▼
agents/code-reviewer.md            ← Agent（执行者）
    │ model: sonnet
    │ tools: Read, Grep, Glob, Bash
    │ "Gather → Understand → Read → Apply → Report"
    ▼
rules/common/security.md           ← Rule（安全检查清单）
    │ "8 项 CRITICAL 安全检查"
    ▼
rules/common/coding-style.md       ← Rule（代码质量清单）
    │ "7 项质量检查"
    ▼
输出：分级审查报告（CRITICAL / HIGH / MEDIUM / LOW）

关键观察：

  • Code-reviewer 有 Bash 工具 — 它可以运行 git diff 获取变更
  • 审查结果分级，有明确的 Approve / Warning / Block 标准
  • 置信度过滤：只报告 >80% 确信是真实问题的发现

四、命令分类速览表（79 个）

79 个命令看起来很多，但按类别分组后结构清晰：

4.1 核心工作流（必须掌握）

命令作用关联 Agent
/plan实施规划planner
/tdd测试驱动开发tdd-guide
/code-review代码审查code-reviewer
/verify验证循环（Skill 驱动）
/e2eE2E 测试e2e-runner
/build-fix修复构建build-error-resolver
/feature-dev完整功能开发多 Agent 协作

4.2 语言审查

命令语言
/go-review、/go-build、/go-testGo
/rust-review、/rust-build、/rust-testRust
/python-reviewPython
/cpp-review、/cpp-build、/cpp-testC++
/kotlin-review、/kotlin-build、/kotlin-testKotlin
/flutter-review、/flutter-build、/flutter-testFlutter/Dart

4.3 多代理编排

命令作用
/orchestrate级联执行（dmux-workflows + autonomous-agent-harness）
/multi-plan多模型协作规划（Codex/Gemini 双模型分析）
/multi-execute多模型协作执行（原型 → 重构 → 审计）
/multi-backend、/multi-frontend前后端分离开发
/multi-workflow多工作流编排
/devfleet开发舰队模式

4.4 会话管理

命令作用
/save-session保存当前会话
/resume-session恢复历史会话
/sessions查看会话列表
/checkpoint创建检查点
/context-budget上下文预算管理

4.5 学习与进化

命令作用
/learn从会话中提取模式
/learn-eval评估学习效果
/skill-create从 Git 历史生成 Skill
/evolve自动进化 Skill
/instinct-export、/instinct-import、/instinct-status直觉系统

4.6 工具与辅助

命令作用
/refactor-clean死代码清理
/update-docs更新文档
/update-codemaps更新代码地图
/quality-gate质量门禁
/prune清理无用文件
/harness-audit审计 Harness 配置
/prompt-optimize优化 Prompt

五、必记 5 命令

如果你只能记住 5 个命令，记这 5 个。它们覆盖了完整的开发循环：

/plan          → 开始前先规划（Plan Before Execute）
    │
    ▼
/tdd           → 按 RED-GREEN-IMPROVE 写代码（Test-Driven）
    │
    ▼
/code-review   → 写完后审查（Agent-First）
    │
    ▼
/verify        → 审查后验证（测试 + Lint + 类型 + 安全）
    │
    ▼
/learn         → 提交后学习（持续改进）

这 5 个命令恰好对应了五大原则的落地：

命令对应原则
/planPlan Before Execute
/tddTest-Driven
/code-reviewAgent-First + Security-First
/verifySecurity-First + Immutability
/learn持续改进（闭环）

六、调用链通用模式

观察三条调用链，可以总结出一个通用模式：

用户输入 /command
    │
    ▼
commands/xxx.md          ← 入口路由（Legacy Shim）
    │
    ▼
skills/xxx/SKILL.md      ← 工作流知识（可选，有些命令直接到 Agent）
    │
    ▼
agents/xxx.md            ← 执行者（模型 + 工具 + 角色定义）
    │
    ▼
rules/common/*.md        ← 约束条件（安全、编码风格、测试要求）
    │
    ▼
输出结果

不是每条链都经过所有节点。简单命令可能跳过 Skill 直接到 Agent，甚至直接执行。但核心工作流命令（/tdd、/plan、/code-review）通常是完整链路。

七、本课练习

练习 1：追踪调用链（20 分钟）

从以下 5 个不同类别的命令中各选一个，追踪其完整调用链：

  1. 核心工作流：/e2e
  2. 语言审查：/go-review
  3. 多代理：/orchestrate
  4. 会话管理：/save-session
  5. 学习：/learn

对每个命令：

  • 打开 commands/xxx.md，找到它引用的 Skill 或 Agent
  • 打开对应的 Skill/Agent，找到它引用的 Rule
  • 画出完整链路图
# 提示：用这个命令快速查看 Command 的内容
cat commands/e2e.md | head -20

练习 2：绘制流程图（15 分钟）

用文本或绘图工具，画出 /tdd 的完整调用链流程图。要求包含：

  • 每个节点的文件路径
  • 节点之间传递了什么信息
  • 每个节点的模型选择（如果有）

练习 3：分类记忆（10 分钟）

不看本课内容，尝试回忆 79 个命令的 6 大类别名称，并为每个类别写出至少 2 个代表命令。

练习 4（选做）：追踪一条新链

选择一个你没见过的命令（比如 /prp-implement 或 /gan-design），完全从零追踪其调用链。记录你遇到的困难和发现。

八、本课小结

你应该记住的内容
Command 定位Legacy Slash-Entry Shim，正在向 Skill 迁移
调用链模式Command → Skill → Agent → Rule → 输出
命令总数79 个，分 6 大类
必记 5 命令/plan、/tdd、/code-review、/verify、/learn
Planner 特点用 Opus 模型，只读工具，等待确认
迁移趋势工作流逻辑集中到 Skill，Command 只做路由

九、下节预告

第 13 课：TDD 全流程 — RED-GREEN-IMPROVE

下节课我们将完整体验一次 TDD 循环。你会亲手写一个失败的测试、实现最小代码让它通过、然后重构优化。这是 ECC 开发流程中最核心的技能 — 不会 TDD，后面的验证循环和多代理编排都无从谈起。

预习建议：阅读 rules/common/testing.md 和 agents/tdd-guide.md，理解 AAA 模式（Arrange-Act-Assert）。

avatar
文章
阅读
粉丝