research-decision-room

研究决策室技能

创建一个单页 HTML 决策材料，帮助产品或设计团队将杂乱的证据转化为清晰的下一步行动。输出不是装饰性的研究演示文稿，而是供团队讨论的工作空间：证据、主题、置信度、权衡和建议实验都应同时呈现。

资源映射

research-decision-room/
├── SKILL.md
├── example.html
└── references/
    ├── checklist.md
    └── evidence-model.md

综合分析前，先阅读 references/evidence-model.md；生成材料前，先运行 references/checklist.md。

何时使用此技能

当用户提供以下任意组合的信息时，使用此技能：

• 访谈笔记、可用性测试观察、支持工单、销售通话记录、应用商店评论、NPS 评论、问卷开放文本、分析数据片段或产品决策背景。
• 需要证据支持的决策：“我们应该开发 X 吗？”“我们应该尝试哪种引导流程？”“用户为什么会中途退出？”“客户说的‘慢’究竟是什么意思？”
• 需要与不会阅读长篇研究报告的利益相关者分享发现。

不要将此技能用于纯粹的视觉灵感、营销活动构思或品牌情绪板。

工作流

步骤 1 - 明确决策框架

根据用户的提示确定决策范围。如果用户没有提出决策，则从证据中推导，并标注为推断。

用简短的框架说明：

• 决策问题。
• 受众或细分群体。
• 时间范围。
• 已知限制。
• 此材料不会决定的事项。

如果缺少关键信息但任务仍可继续，请使用明确标注的假设，而不要提出宽泛的问题。

步骤 2 - 建立证据台账

根据 references/evidence-model.md 中的模型，将所有有用信号规范化为台账条目。

每个台账条目必须包含：

• id：简短且稳定的 ID，例如 I-03、T-14、M-02。
• source_type：访谈、可用性测试、支持、问卷、分析、销售、实地笔记或利益相关者。
• segment：用户类型或“未知”。
• signal：一句话描述观察结果。
• quote_or_metric：直接引语、指标或“未提供”。
• strength：强、中或弱。
• limitations：说明此证据可能存在偏差或不完整的原因。

绝不要编造引语、参与者人数、日期、收入影响或指标。如果用户未提供数字，请使用“未提供”，并说明需要哪些证据才能提高置信度。

步骤 3 - 综合主题与矛盾点

将证据归纳为 4 至 6 个主题。对每个主题：

• 用通俗易懂的语言为主题命名。
• 列出支持该主题的证据 ID。
• 解释背后的行为，而不只是 UI 层面的问题。
• 将置信度标为高、中或低。
• 说明矛盾之处或细分群体之间的差异。

优先使用动词而非名词：“当第一个空白状态要求过多时，团队会放弃设置”胜过“引导流程问题”。

步骤 4 - 评估机会

创建一个包含 3 至 5 个选项的机会矩阵。为每个选项按 1 至 5 分评分：

• 证据强度。
• 用户痛点。
• 业务杠杆作用。
• 实施风险，其中 5 表示低风险，1 表示高风险。

显示总分，但不要用分数取代判断。用一句话说明为什么最高优先级的建议胜出。

步骤 5 - 起草决策备忘录

撰写一份决策备忘录，包含：

1. 建议采取的行动。
2. 为什么是现在。
3. 支持该行动的证据。
4. 可能出错的地方。
5. 下一步要衡量的内容。
6. 可撤回的下一步。

备忘录应足够简短，让人能在一分钟内读完。

第 6 步 - 创建 HTML 成品

生成一个独立的 index.html。使用当前生效的 DESIGN.md 中的字体排印、 间距、颜色角色和组件风格，同时保持信息架构稳定：

1. 标题区域，包含决策问题、置信度和最后更新时间标签。
2. 执行摘要，包含建议、风险和下一项实验。
3. 证据清单，包含筛选标签。
4. 主题图，包含证据 ID 和置信度。
5. 机会矩阵。
6. 决策备忘录。
7. 实验队列，包含负责人、指标和成功阈值。
8. 假设与局限。

成品应具备交互性，同时保持稳定。可以使用简单的原生 JavaScript 来筛选证据、切换视图或突出显示相关 ID。无需依赖框架。

第 7 步 - 自检并输出

运行检查清单。然后输出一句简洁的导览说明和一个 HTML 成品：

<artifact identifier="research-decision-room" type="text/html" title="Research Decision Room">
<!doctype html>
<html>...</html>
</artifact>

结束的 </artifact> 之后不得有任何内容。