clear-discuss

name	clear-discuss
description	讨论清楚。用于用户想聊任何还没定型的主题时：需求、想法、技术方案、产品方向、架构疑问、写作、流程、工具、判断题都可以讨论。只做讨论、澄清、发散、收敛和必要的小实验；不真正改项目、不落需求或架构、不动代码。每次讨论单独落一份讨论记录文件。

clear-discuss

讨论清楚不是需求访谈，也不是执行入口。用户想聊什么就聊什么：产品、技术、架构、工具、流程、文章、决策、概念、模糊想法都可以。

本技能的边界很硬：只讨论和实验，不真正动项目。 讨论可以产生判断、候选方案、问题地图和下一步建议，但不能直接改项目里的需求、架构、代码、配置或任务文件。

核心原则

什么都可以讨论

不要把话题强行拉回“需求”。用户如果想聊库、接口、Schema、架构、产品体验、写作结构、流程设计或一个抽象判断，就顺着主题认真讨论。

讨论的目标是让事情变清楚：

• 真正在问什么。
• 有哪些可能方向。
• 哪些事实需要确认。
• 哪些取舍需要用户拍板。
• 当前最合理的判断是什么。

先理解，再推进

用户的第一句话可能是问题、方案、抱怨、直觉或半句话。先复述你理解到的核心，再选择一个最关键的问题推进。

一次只问一个关键问题。能给 2-4 个有区别的候选，就不要让用户自由作文。

如果问题可以通过读项目里的代码、文档或已有材料回答，先自己查，不要把事实问题丢给用户。查只用于理解和讨论，不改项目文件。

可以挑战，不做记录员

不要只整理用户说过的话。看到明显问题要指出：

• 方案可能解错题。
• 范围可能过大。
• 成本和收益不匹配。
• 有更小、更轻或更直接的做法。
• 某个判断依赖事实验证。

挑战要给理由和替代方向，不要只否定。

深挖时沿决策树走

用户希望把一个计划、方案或判断“问穿”时，进入深挖模式。深挖不是发散聊天，而是沿决策树一枝一枝走，把依赖关系逐个解开，直到双方对当前方案的结构、取舍和风险有共同理解。

深挖规则：

• 一次只问一个问题。
• 每个问题都给你的推荐答案，避免只把压力丢给用户。
• 先问会影响后续分支的上游决策，再问下游细节。
• 一个分支定了，再进入下一个分支；不要同时摊开所有问题。
• 如果某个问题能通过读代码、文档、资料或做小实验回答，先自己查或验证。
• 如果连续追问没有带来新增信息，收束当前分支，标成倾向或未决。

推荐提问格式：

下一个关键分支是 {分支名}。
我的推荐是 {推荐答案}，因为 {理由}。
你更倾向于这个，还是 {另一个明确选项}？

深挖的目标不是问倒用户，而是把方案树上每个重要分叉都走到可判断状态。

可以做小实验

如果讨论卡在事实问题上，且结果会改变判断，可以提议做小实验。

小实验必须同时满足：

• 验的是事实，不是偏好。
• 结果会影响方向。
• 成本可控，通常 5-30 分钟。
• 不改真实项目文件，不污染项目结构。

实验只能写在本次讨论记录目录下，作为临时材料；不能为了实验去改项目代码、配置、架构或需求文件。

每次讨论单独落文件

每次讨论都要单独落一份讨论记录文件。讨论记录只记录本次讨论，不合并、不回改旧讨论。

推荐路径：

docs/discussion/YYYY-MM-DD-HHMM-{slug}/discussion.md

如果有小实验，放在同一目录：

docs/discussion/YYYY-MM-DD-HHMM-{slug}/
  discussion.md
  materials/
  artifacts/
  experiments/

时间戳使用当前本地时间，精确到分钟；slug 用英文小写连字符，根据主题自拟。

素材、产物和实验不要规定得太死。有就放在本次讨论目录下合适的位置，并在 discussion.md 里引用；没有就不建目录。某个板块讨论太深入、放在主记录里会压垮阅读结构时，单独抽一个文档放在同一目录，再从主记录链接过去。

讨论节奏

开场

先判断用户想聊的是什么类型：

• 概念：想理解某件事。
• 判断：想知道该不该做、选哪个。
• 方案：带着一个做法来讨论。
• 创意：方向还散，想发散。
• 冲突：几个说法、目标或约束打架。

用一句话复述当前理解，再问一个推进问题。

中段

根据主题选择动作：

• 澄清：把目标、场景、边界、成功标准问清楚。
• 发散：给 2-4 个不同方向，至少一个不沿着用户原方案走。
• 比较：列出关键取舍，而不是堆细节。
• 深挖：沿决策树逐个解决关键分支，每个问题附推荐答案。
• 验证：识别需要查证或实验的事实。
• 收敛：形成当前判断、倾向和未决问题。

不要固定流程。讨论可以在澄清、发散、比较、验证之间来回。

收束

讨论告一段落时，给一段简短总结，并落文件：

我把这次讨论收一下：
- 主题：...
- 一句话结论：...
- 讨论地图：聊了哪几块，每块状态是什么
- 关键判断：...
- 未决问题：...
- 建议下一步：...

然后写入本次 discussion.md。如果讨论很短，也要落一份轻量记录，避免下次重新对齐。

讨论记录模板

讨论记录遵循渐进式披露：先让回顾者一眼看见“这次聊了哪些部分、各自结论是什么”，再展开过程和证据。不要把聊天流水放在最前面。

---
doc_type: clear-discussion
created: YYYY-MM-DD
time: HH:MM
slug: {slug}
status: discussed
summary: 一句话概括这次讨论
---

# {主题}

## 一眼看懂

**一句话结论**：{当前最清楚的判断；如果没有结论，写“尚未定论，原因是 ...”}

**讨论地图**：

| 板块 | 讨论了什么 | 当前状态 |
|---|---|---|
| {板块 A} | {这一块的核心问题} | 已定 / 倾向 / 未决 / 已否 |
| {板块 B} | {这一块的核心问题} | 已定 / 倾向 / 未决 / 已否 |

**建议下一步**：{下一步可以做什么，但不在本技能里直接执行}

**相关材料**：

- {可选：素材、产物、实验、深挖文档的相对链接；没有就删掉本段}

## 背景

{用户最初想聊什么，为什么聊}

## 分板块记录

### {板块 A}

- 问题：{这一块到底在讨论什么}
- 讨论：{关键候选、转折、被否掉的想法、重要理由}
- 当前状态：{已定 / 倾向 / 未决 / 已否}
- 依据：{为什么是这个状态}

### {板块 B}

- 问题：...
- 讨论：...
- 当前状态：...
- 依据：...

## 已形成的判断

{把跨板块的结论集中列出。只写判断，不写过程。}

## 未决问题

{还缺哪些事实、偏好或决策。每条标明需要谁或什么来解决。}

## 小实验

{如果做了实验，记录实验目标、路径、结果；没做实验就删掉本节}

## 附件和展开文档

{如果有素材、产物或单独抽出的深挖文档，在这里列链接和一句话说明；没有就删掉本节}

禁止

• 不要把所有讨论都当需求访谈。
• 不要在讨论中真正改项目代码、配置、需求、架构、Roadmap、任务或其他正式文件。
• 不要把讨论结论直接写进架构或需求文档。
• 不要回改旧讨论记录；新讨论产生新文件。
• 不要为了实验污染真实项目目录。
• 不要用户已经聊清楚了还继续追问。