Concept

帮助用户深入理解概念：讲清从哪来、解决什么问题、定义怎么从多维度看、各方立场与利弊——不替代决策、不替用户拍板。

与 choice 互补：用户在做利害取舍时用 choice；只想把概念本身看清时用本 skill。

何时启用

出现以下任一信号时启用，即使未被点名：

• 「深入理解 / 讲透 / 到底是什么 / 帮我理解某某」
• 「多角度解释 / 从起源讲起 / 各方怎么看」
• 用户要弄清一个术语、机制、制度或抽象概念的来龙去脉与利害结构

Workflow

• 确认所指概念（模糊时最多 1 个澄清问题；已明确则直接开讲）
• 按固定四层顺序输出（缺一层不算完成）
• 收束为「理解检查清单」（3–5 条）
• 用户若转向「要不要做 / 选哪个」：提示切换到 choice，本 skill 不替代决策

1. 确认概念

• 同名多义、缺领域/语境、或所指不清时：只问 1 个最能对齐所指的问题，等答完再讲。
• 所指已足够明确：不要问卷式追问，直接进入四层讲解。

2. 四层讲解（固定顺序）

1. 背景起源：从何而来、在什么历史/语境下出现、为何会「需要被命名」
2. 解决什么问题：针对的痛点或缺口；对比「没有它时」与「有了它之后」
3. 定义的多维度解释：至少 2–4 个维度（如形式定义、操作定义、类比、边界/非定义）；禁止只堆百科式单句定义
4. 各方立场与利弊：识别 2–4 个真实相关方；各方如何理解该概念、对其利弊；每条利弊带一句「为何如此」（机制/因果）

3. 收束

用 3–5 条「理解检查清单」复述关键理解点，方便用户自测是否真懂。
不要默认展开成自测题卷，除非用户要求。

输出结构（必须）

按此结构回复；可按概念删减篇幅，但不得省略任一层：

## 概念：…
（可选 1 句：本文所指的具体含义/语境）

## 1. 背景起源
…

## 2. 解决什么问题
- 针对的问题：…
- 没有它时：…
- 有了它之后：…

## 3. 定义的多维度解释
### 维度 A：…
### 维度 B：…
（可选边界：它不是…）

## 4. 各方立场与利弊
### 立场方：…
- 如何看待：…
- 利：… —— 为何如此：…
- 弊：… —— 为何如此：…

## 理解检查清单
- …

利弊成因写法（必须，第 4 层）

每条「利 / 弊」都要解释为何如此，而不是只贴标签。

• 写什么：触发链条（对谁、在什么关系下、机制如何导致收益或代价）
• 怎么写：一句白话；点到机制即可，不堆术语
• 禁止：只写「有好处 / 有风险」却不说因果；用空话代替解释

好：「对平台运营者：利是标准化接口降低接入成本 —— 为何如此：各方按同一契约对接，不必为每个合作方单独定制协议」

差：「对平台有利有弊，需谨慎」

行为准则

1. 四层齐全：背景起源、解决问题、多维定义、各方立场与利弊缺一不可。
2. 理解优先于行动：不默认给出「怎么做 / 推荐方案」；用户明确要落地步骤时再补，且仍标明那是延伸、不是本 skill 的核心。
3. 立场方可辨：角色/利益具体；禁止「有人觉得好有人觉得坏」。
4. 区分层次：事实、惯例、争议观点分开写；有争议标「常见分歧」，不假装唯一真理。
5. 澄清有上限：开场最多 1 个澄清问；不做成苏格拉底长对话。
6. 与 choice 分界：用户真正在做利害决策时，简短说明可改用 choice；本 skill 只负责把概念讲清。
7. 语言：中文、短句；术语出现时用白话补一句。

Examples

Example 1 — 所指明确，直接四层

• Input: 「帮我深入理解什么是技术债」
• Output: 按输出结构完整四层 + 理解检查清单；立场方例如业务方、工程师、接手维护者等；每条利弊带「为何如此」

Example 2 — 同名多义，先澄清再讲

• Input: 「讲透 agent」
• Output: 先问 1 题对齐所指（如 AI Agent / 代理模式 / 商务代理等）；用户确认后再输出完整四层

Additional resources

• 各层写作标准、立场方提示与澄清示例：references/REFERENCE.md