---
name: teacher
description: >
    架构对齐测验——agent 主动从架构维度提问，用户作答，agent 针对偏差给出纠正和解释。
    当用户说"考考我架构"、"帮我对齐架构认知"、"测测我对架构的理解"、
    "我想确认一下我对这个系统的理解"、"架构对齐"时立即触发。
    也适用于："我不确定自己理解对了没"、"帮我检验一下"、"梳理一下架构认知"等场景。
    只要用户想验证或校准自己对系统架构的理解，就应使用此 skill。
---

# Align Architect — 架构对齐 Skill

通过**主动提问 → 用户作答 → 纠错解析**的方式，帮助用户校准对系统架构的理解。

重点不是刁难，而是找到认知盲点：哪些地方理解正确可以强化，哪些地方有偏差需要纠正。

---

## 第一步：读取架构上下文

CLAUDE.md 已自动加载到上下文，无需重复读取。如有需要，额外并行执行：

```
Glob("**/Cargo.toml")          # 模块拓扑结构
Glob("spec/global/**/*.md")    # 如果存在，读取全局架构文档
```

**阅读重点**：

- 模块之间的依赖关系（谁依赖谁）
- 关键数据流或消息流的完整链路
- 中间件的执行顺序和拦截点
- 工具的来源和注册方式
- 异常处理和边界情况
- 设计决策背后的理由（文档中通常会有"为什么"的说明）

> 目标：基于项目的**真实架构**出题，而不是泛泛的软件架构通识。答案必须有项目文档支撑。

---

## 第二步：设计问题集

根据读取到的架构信息，围绕以下维度设计 **5–8 个问题**，覆盖不同模块和不同认知层次：

| 维度            | 示例方向                                   |
| --------------- | ------------------------------------------ |
| **依赖关系**    | A 模块依赖 B，还是 B 依赖 A？为什么？      |
| **数据/消息流** | 一条消息从 X 到 Y 经过哪些模块？           |
| **职责边界**    | 这个功能由哪个模块负责？为什么不是另一个？ |
| **接口契约**    | 模块 A 和模块 B 通过什么方式交互？         |
| **设计决策**    | 为什么选择这种设计而不是更直接的方式？     |
| **边界情况**    | 当 X 发生时，哪个模块负责处理？            |

**问题质量要求**：

- 每道题有**唯一正确方向**，不是"都可以"的开放题
- 问题基于项目真实设计，不考抽象理论
- 难度分布：约 2 题较直接（热身），约 4 题需要理解模块关系，约 1–2 题需要深度理解设计意图

---

## 第三步：提问流程

**使用 `AskUserQuestion` 工具**逐批交互式提问，每批最多 4 题，不要把题目作为文本段落输出。

**题目形式**：

- **固定为选择题**：每题 4 个选项
    - 选项 A-C：正确答案 + 2 个常见误解的干扰项
    - 选项 D：固定为 `"不知道"`，description 固定为 `"我不确定，请告诉我正确答案"`
- `header` 填题目序号，如 `"第 1 题"`
- `multi_select: false`（单选）

**调用示例**（每批 1–4 题，用一次工具调用）：

```
AskUserQuestion({
  questions: [
    {
      header: "第 1 题",
      question: "ReActAgent 的工具来源有哪几种方式，合并顺序如何？",
      multi_select: false,
      options: [
        { label: "A", description: "ToolProvider 优先，手动注册的工具会被覆盖" },
        { label: "B", description: "手动注册的工具优先级最高，ToolProvider 补充其余工具" },
        { label: "C", description: "中间件工具和手动注册工具完全独立，不合并" },
        { label: "不知道", description: "我不确定，请告诉我正确答案" }
      ]
    },
    ...
  ]
})
```

**分批规则**：

- 5–8 题时，按 4+余量 分两批；不超过 4 题时一批完成
- 每批调用一次 `AskUserQuestion`，等待用户作答后再发下一批
- 先告知用户总题数和分批情况（一句话即可），然后立即调用工具，不要在文本中把题目再列一遍

---

## 第四步：批改与解析

收到工具返回的用户答案后（格式为每题选中的选项 label，如 `"B"` 或用户自填的文本），逐题评判：

**格式**：

```
✅ 第 N 题 — 正确
<简短确认，可补充一句加深理解的延伸>

❌ 第 N 题 — 有偏差
用户的理解：<复述用户的答案要点>
实际情况：<基于项目文档的正确答案>

⚠️ 第 N 题 — 部分正确
对的部分：<肯定用户正确理解的部分>
偏差：<指出哪些地方不完整或有误>
补充解释：<完整的正确答案>
```

**批改原则**：

- 答案依据来自读取的架构文档，不凭主观判断
- 有偏差的题目重点解释**为什么**是这样设计，而不只是给出正确答案
- 如果用户的偏差反映了某个更深层的误解，点出这个模式：「这道题的偏差和第 N 题类似，根源是对 X 和 Y 关系的理解……」
- **部分正确**：肯定对的部分，但明确指出遗漏或偏差，给出完整图景

**可选：追问机制**
如果用户对某题的理解有明显偏差，且这个偏差涉及核心概念，可以追加一个简短的追问：

- 目的是确认用户是否真的理解了纠正后的内容
- 追问要简单直接，不要变成新测验
- 如果用户继续回答错误，指出根源概念而非具体答案
- 示例：「理解了。那么如果 X 发生了，会是哪个模块处理？」

---

## 第五步：总结

所有题批改完后，给出简短总结：

```
## 对齐总结

掌握扎实（N 题）：...
需要关注（N 题）：...

核心认知偏差：
- <如果有反复出现的误解，归纳为 1–2 条>

建议：<下一步可以重点看哪部分文档或代码>
```

总结输出后，用 `AskUserQuestion` 询问是否继续：

```
AskUserQuestion({
  questions: [
    {
      header: "继续？",
      question: "要再来一轮吗？",
      multi_select: false,
      options: [
        { label: "再来一轮", description: "换一组新题，继续测验" },
        { label: "针对薄弱点再练", description: "只出刚才答错或不确定的相关题目" },
        { label: "输出成绩报告", description: "生成本轮完整成绩单后结束" },
        { label: "结束", description: "本次对齐完成" }
      ]
    }
  ]
})
```

- 选"再来一轮"：重新从第二步设计全新问题集，可以覆盖不同模块或更深层面
- 选"针对薄弱点再练"：仅围绕本轮答错 / 选"不知道" 的知识点出题（3–5 题）
- 选"输出成绩报告"：输出详细成绩单（格式见下方），然后礼貌收尾
- 选"结束"：礼貌收尾即可

### 成绩报告格式

选"输出成绩报告"时，输出以下格式的完整成绩单：

```
## 架构对齐成绩报告

**得分：N / 总题数**（正确 N 题，偏差 N 题，不知道 N 题）

| 题号 | 题目摘要 | 结果 | 考察维度 |
|------|----------|------|----------|
| 第 1 题 | <10字以内题目摘要> | ✅ 正确 / ❌ 偏差 / ❓ 不知道 | 依赖关系 / 数据流 / 职责边界 / … |
| 第 2 题 | … | … | … |
| … | … | … | … |

**薄弱维度：** <列出答错/不知道题目所属的维度>

**建议阅读：** <指向具体文档章节或代码文件>
```

成绩报告输出完毕后礼貌收尾。

---

## 行为准则

**答案有依据**：每道题的标准答案必须能在 CLAUDE.md 或读取的架构文档中找到支撑，不能凭感觉评判。

**纠错要解释原因**：说"不对"没有价值，说"为什么是这样"才有价值——架构设计背后都有取舍理由。

**鼓励猜测**：提示用户不确定的题目可以猜，猜错才能找到真正的认知盲点。

**不刁难**：问题应当覆盖真实的架构关键点，而不是考冷僻细节或文字游戏。
