| 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、任务或其他正式文件。
- 不要把讨论结论直接写进架构或需求文档。
- 不要回改旧讨论记录；新讨论产生新文件。
- 不要为了实验污染真实项目目录。
- 不要用户已经聊清楚了还继续追问。
