to-spec-for-pm

这个技能获取当前对话的上下文，产出一份面向产品经理的业务需求规格文档。文档的目标读者是不懂技术但熟悉业务的 PM，因此所有内容都应从业务视角和用户视角出发，使用通俗易懂的语言，避免技术术语。

不要访谈用户——只综合你在对话中已经确认过的需求。

issue tracker 与分诊（triage）标签词汇应当已经提供给你——如果没有，运行 /init_goder_harness。

流程

1. 回顾对话：梳理当前对话中已经讨论和确认的所有需求决策点。如果有些关键问题在对话中没有明确，在文档中标注为「待确认」。

2. 探索现有系统：了解当前系统中相关功能的现状，以便在文档中清楚地说明「现在是什么样」和「要变成什么样」。

3. 用下面的模板编写规格文档，然后把它发布到项目的 issue tracker。打上 spec-for-pm 分诊标签。

需求背景

用 1-2 段话说清楚：

• 现在系统里这个功能是什么样的？
• 用户遇到了什么问题或不便？
• 为什么现在要做这个改动？

用 PM 能理解的语言，避免任何技术术语。

使用场景

描述用户在什么情况下会使用这个功能。用讲故事的方式，让 PM 能脑补出具体画面。

示例格式：

小明每天早上打开健康 App 查看昨晚的睡眠数据。昨晚他忘了戴手表，App 里没有昨晚的睡眠记录。他希望在 App 里手动补录一下昨晚大概睡了几个小时。

需求决策清单

把对话中已经确认的所有业务决策整理成表格：

序号	决策项	结论	备注
1	xxx	xxx

如果有尚未确认的事项，在备注列标注「待确认」。

用户故事

列出与本次需求相关的用户故事，格式如下：

1. 作为一名 <角色>，我想要 <功能>，以便 <收益>
2. 作为一名 <角色>，当我 <某个情况> 时，我希望系统 <某个行为>，以便 <收益>

用户故事应覆盖本次需求的所有方面，包括正常流程和异常情况。

业务规则

列出本次需求涉及的业务规则，每条规则用一句话说清楚：

• 规则 1：xxx
• 规则 2：xxx

示例：

• 用户只能选择今天及之前的日期，不能选择未来日期
• 如果同一天已有记录，新保存的记录将覆盖旧记录
• 质量评分为可选项，不填时系统不记录质量分数

页面与交互设计

入口说明

说明用户从哪里进入这个功能。如有需要，用简单的 ASCII 示意图标注入口位置。

页面布局

用 ASCII 框图画出页面/弹窗/卡片的布局，让 PM 能直观看到最终效果。

示例：

┌─────────────────────────────────────┐
│         Add Sleep              [X]  │
├─────────────────────────────────────┤
│                                     │
│  Date                               │
│  ┌─────────────────────────────┐    │
│  │ 2026-08-11                  │    │
│  └─────────────────────────────┘    │
│                                     │
│  Duration (hours)                   │
│  ┌─────────────────────────────┐    │
│  │ 7.5                         │    │
│  └─────────────────────────────┘    │
│                                     │
│  Quality (optional)                 │
│  ┌─────────┐ ┌─────────┐ ┌───────┐ │
│  │  😊 好   │ │  😐 中   │ │ 😫 差 │ │
│  └─────────┘ └─────────┘ └───────┘ │
│                                     │
│          [Cancel] [Save]            │
└─────────────────────────────────────┘