framing-doc

从对话记录中提炼问题框架

从一份或多份对话记录中生成一份问题框架文档。框架要捕捉“为什么”——要解决什么问题，以及为什么优先解决这个问题，而不是其他问题。

---

开始之前

询问用户：

1. 哪些对话记录？ 获取具体的文件路径。按照用户指定的顺序阅读——对话顺序往往很重要，因为想法会在多次交流中逐步形成。
2. 主题领域是什么？ 大致了解这些对话的主题（例如“AI 功能”“新手引导改版”），以便知道要关注哪些内容。

---

问题框架文档包含什么

框架分为三个部分：

1. 来源 — 实际说过的话

从对话记录中摘录原话。这是事实依据。文档中的其他内容都是对这些材料的解读。

• 标明引文的发言者
• 提供足够的上下文，让引文脱离上下文也能读懂
• 必要时添加简短的衔接文字，但尽量少加入自己的表述

2. 前期梳理 — 出现了哪些选项，以及为什么选择这个

梳理各次对话中提到的选项。这不是背景介绍，而是说明为什么要围绕这个特定问题构建框架。

针对每个出现的选项：

• 这是什么？
• 谁会受益？
• 信号有多强？（有多少人独立提出了这个想法？其他人是进一步讨论，还是不再提及？）

然后说明为什么现在要推进其中一个选项：

• 为什么它比其他选项更紧迫或更重要？
• 为什么其他选项暂时不推进？（这是在解释“为什么现在不做”，而不是“为什么永远不做”——不要否定这些想法，只需说明它们为何不是当前优先事项。）

不要为其他选项编造路线图或推进顺序。 是否推进以及何时推进，都是未来的决定。你只需要说明：基于这些原因，优先推进这个选项。

3. 问题 / 结果 — 具体框架

问题： 哪些方面出了问题，存在哪些痛点。用项目符号列出，便于快速浏览。

结果： 成功是什么样的。同样用项目符号列出。保持高层次，不要绑定具体解决方案。

4. 少关注 / 多关注 — 为解决方案划定边界（可选）

用来引导读者选择合适的解决方案，并避免不合适的方向。它位于“问题 / 结果”之后，作为单独的部分。格式相同——两组对称的项目符号列表。

作用： 防止读者正确理解了问题和结果，却提出了错误类型的解决方案。例如，关于如何将训练计划引入系统的问题，很容易让人提出“用 AI 为教练提供训练计划建议”——这在技术上回应了问题，却完全偏离了重点。

适用情况： 当存在常见误解，或人们很容易走向某个显而易见却错误的方向时。如果对话中的人明确划定了界限——指出哪些内容不属于本问题——就说明可以加入这一部分。如果没有人觉得有必要划清界限，通常就不需要这一部分。

如何发现： 仅靠初次通读对话记录，可能不会自动发现这一点。它更可能在评审时显现——要么负责塑造框架的人注意到，大家反复表示“这不是关于 X”；要么有人阅读框架后提出了一个符合“问题 / 结果”、却偏离重点的方案。这时就会意识到，需要明确写出边界。

示例：

## Less about

- [What this project is NOT trying to solve]
- [The wrong direction people might naturally head toward]

## More about

- [What kind of solution actually fits]
- [The real nature of the problem being addressed]

无需引文或署名——这是综合归纳。只保留关键要点。

---

核心原则：依据证据，不加主观评判

写完“问题”和“结果”中的每一条后，都要问：是谁在什么场合说的？

• 如果能指出具体的人和具体的时刻 → 保留并标注出处
• 如果能从某人的话中直接推断出来 → 保留，并说明这是推断及其依据
• 如果无法追溯来源 → 删除

需要避免的常见陷阱

不要把推断当作事实来陈述。“教练在试用期间流失，是因为数据录入太难”听起来合理，但如果没人说过，就不要把它写成已证实的事实。

**不要为了生动而添油加醋。**添加没人提过的具体细节（“每项练习、组数、次数和百分比”），让问题听起来更具体，这属于主观发挥。

**不要把选项列表越写越长。**某个人提到过、但没人接着讨论的想法，不算“有一定支持的选项”。要如实反映支持力度。问问自己：是否有多人独立提出了这个想法？其他人是进一步展开了讨论，还是让它不了了之？

不要在 Problem 陈述中加入主观评论。“TB 必须证明更换的价值”或“最大的单一阻力点”之类的说法属于修辞，而非证据。根据大家说过的话来阐述。

**不要把你的表述说成是他们的原话。**将你的解读与实际说过的话区分开来。Source 部分记录的是他们的原话。Problem/Outcome 是你的提炼——而且应当能追溯到 Source。

---

审核 Frame

起草后，逐行检查 Problem 和 Outcome：

1. 阅读每条要点
2. 问问自己：这条主张的依据是什么？
3. 如果依据是直接引语——在括号中注明出处
4. 如果依据是隐含信息——明确说明这一点
5. 如果没有依据——删掉这条

对预备工作选项表也进行同样的检查。对于列出的每个选项，请确认：

• 它是否真的在对话中获得了支持？（是否有多人独立提出？）
• 还是只有某个人提出，其他人并未接着讨论？

要愿意精简选项列表。少一些真实的选项，胜过用选项凑数。

---

文档格式

---
shaping: true
---

# [Topic] — Frame

## Source

### [Speaker] ([Date])

> "Verbatim quote..."

> "Another quote..."

[Brief connective context where needed.]

### [Speaker] ([Date])

> "Verbatim quote..."

---

## Pre-work: [Topic] Options Landscape

[N] options surfaced with real traction across conversations:

| Option | What it does | Who benefits | Signal strength |
|--------|-------------|--------------|-----------------|
| **A. [Name]** | ... | ... | ... |
| **B. [Name]** | ... | ... | ... |

([Note on ideas that were mentioned but didn't get traction — dropped.])

**Why A now:** [Evidence-based argument for urgency/importance.]

---

## Problem

- [Bullet — traceable to source]
- [Bullet — traceable to source]

## Outcome

- [Bullet — high-level, not solution-specific]
- [Bullet — high-level, not solution-specific]

---

## Less about

- [What this is not]

## More about

- [What this is]

---

此 Skill 不会做什么

• **不会设计解决方案。**Frame 回答的是“为什么”。Shapes（即“如何做”）将在之后的独立 shaping 文档中讨论。
• **不会安排未来工作的顺序。**它只选出当前的一项优先事项，不会为其余工作制定路线图。
• **不会总结对话。**Source 部分记录关键引语。文档其余部分是提炼，而非总结。