teacher

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

Align Architect — 架构对齐 Skill

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

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

第一步：读取架构上下文

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

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

阅读重点：

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

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

第二步：设计问题集

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

问题质量要求：

• 每道题有唯一正确方向，不是"都可以"的开放题
• 问题基于项目真实设计，不考抽象理论
• 难度分布：约 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 或读取的架构文档中找到支撑，不能凭感觉评判。

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

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

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