编写规格说明
如果您看到不熟悉的占位符或需要检查已连接了哪些工具，请参阅 CONNECTORS.md。
编写功能规格说明或产品需求文档（PRD）。
用法
/write-spec $ARGUMENTS
工作流程
1. 了解功能
询问用户想要制定什么规格。接受以下任意形式：
- 功能名称（"SSO 支持"）
- 问题陈述（"企业客户一直要求集中式身份认证"）
- 用户请求（"用户希望将数据导出为 CSV"）
- 模糊的想法（"我们应该在引导流失问题上做点什么"）
2. 收集背景信息
向用户询问以下信息。采用对话方式——不要一次性抛出所有问题。先问最重要的，然后在过程中填补空白：
- 用户问题：这解决了什么问题？谁遇到了这个问题？
- 目标用户：这服务于哪个（些）用户细分群体？
- 成功指标：我们如何知道这成功了？
- 约束条件：技术约束、时间线、法规要求、依赖关系
- 先例：之前尝试过吗？是否有现有解决方案？
3. 从已连接工具中提取上下文
如果 ~~项目跟踪器 已连接：
- 搜索相关的工单、史诗或功能
- 提取任何现有的需求或验收标准
- 识别对其他工作项的依赖关系
如果 ~~知识库 已连接：
- 搜索相关的研究文档、先前的规格说明或设计文档
- 提取相关的用户研究发现
- 查找相关的会议记录或决策记录
如果 ~~设计 已连接：
- 提取相关的模型、线框图或设计探索
- 搜索与该功能相关的设计系统组件
如果这些工具未连接，完全依据用户提供的信息进行工作。不要要求用户连接工具——直接用现有信息继续。
4. 生成产品需求文档
生成包含以下部分的结构化产品需求文档。有关每个部分应包含内容的详细指导，请参阅产品需求文档结构。
- 问题陈述：用户问题、受影响人群以及不解决的后果（2-3
句话）
- 目标：3-5
个与用户或业务指标相关的具体、可衡量的成果
- 非目标：3-5
个明确排除在范围之外的事项，每个附简要理由
- 用户故事：标准格式（"作为[用户类型]，我想要[能力]以便[收益]"），按画像分组
- 需求：分类为必须实现（P0）、最好实现（P1）和未来考虑（P2），每个附验收标准
- 成功指标：领先指标（变化快）和滞后指标（随时间变化），带具体目标值
- 待解决问题：未解决的问题，标记谁需要回答（工程、设计、法务、数据）
- 时间线考虑：硬性截止日期、依赖关系和分阶段计划
5. 审查和迭代
生成产品需求文档后：
- 询问用户是否有任何部分需要调整
- 提供扩展特定部分的选项
- 提供创建后续产出的选项（设计简报、工程任务拆分、利益相关者提案）
产品需求文档结构
问题陈述
- 用 2-3 句话描述用户问题
- 谁遇到了这个问题以及频率如何
- 不解决的代价是什么（用户痛苦、业务影响、竞争风险）
- 基于证据：用户研究、支持数据、指标或客户反馈
目标
- 此功能应实现的 3-5 个具体、可衡量的成果
- 每个目标应回答："我们如何知道这成功了？"
- 区分用户目标（用户得到什么）和业务目标（公司得到什么）
- 目标应该是成果，而非产出（"将首次价值时间减少
50%"而非"构建引导向导"）
非目标
- 此功能明确不会做的 3-5 件事
- 在此版本范围之外的邻近能力
- 对每个非目标，简要说明为什么不在范围内（影响不够大、太复杂、单独的举措、为时过早）
- 非目标可防止实施过程中的范围蔓延，并向利益相关者设定预期
用户故事
以标准格式编写用户故事："作为[用户类型]，我想要[能力]以便[收益]"
指南：
- 用户类型应足够具体以有意义（"企业管理员"而非仅仅"用户"）
- 能力应描述他们想完成什么，而非如何完成
- 收益应解释"为什么"——这提供了什么价值
- 包括边界情况：错误状态、空状态、边界条件
- 如果功能服务于多个画像，包括不同的用户类型
- 按优先级排序——最重要的故事优先
示例：
- "作为团队管理员，我想为我的组织配置
SSO，以便我的团队成员可以使用他们的企业凭据登录"
- "作为团队成员，我想被自动重定向到公司的 SSO
登录，以便我不需要记住单独的密码"
- "作为团队管理员，我想查看哪些成员已通过 SSO
登录，以便我验证部署是否正常"
需求
必须实现（P0）：没有这些，功能无法交付。这些代表了功能的最小可行版本。问："如果我们砍掉这个，功能还能解决核心问题吗？"如果不能，就是
P0。
最好实现（P1）：显著改善体验，但没有它们核心用例也能工作。这些通常成为发布后的快速跟进项。
未来考虑（P2）：明确排除在 v1
范围之外，但我们希望以支持它们的方式进行设计。记录这些可以防止将来使它们难以实现的意外架构决策。
对每个需求：
- 编写清晰、无歧义的预期行为描述
- 包括验收标准（见下文）
- 注明任何技术考虑或约束
- 标记对其他团队或系统的依赖关系
待解决问题
- 在实施之前或期间需要回答的问题
- 每个问题标记谁应该回答（工程、设计、法务、数据、利益相关者）
- 区分阻塞性问题（开始前必须回答）和非阻塞性问题（可在实施过程中解决）
时间线考虑
- 硬性截止日期（合同承诺、活动、合规日期）
- 对其他团队工作或发布的依赖关系
- 如果功能太大无法一次发布，建议分阶段实施
用户故事编写
好的用户故事应该是：
- 独立的：可以独立开发和交付
- 可协商的：细节可以讨论，故事不是合同
- 有价值的：为用户提供价值（而不仅仅是团队）
- 可估算的：团队可以大致估算工作量
- 小型的：可以在一个冲刺/迭代中完成
- 可测试的：有明确的验证方式
用户故事的常见错误
- 过于模糊："作为用户，我希望产品更快"——具体什么应该更快？
- 指定解决方案："作为用户，我想要一个下拉菜单"——描述需求，而非 UI
控件
- 没有收益："作为用户，我想点击一个按钮"——为什么？它能完成什么？
- 过于庞大："作为用户，我想管理我的团队"——将其拆分为具体能力
- 内部视角："作为工程团队，我们想重构数据库"——这是一个任务，不是用户故事
需求分类
MoSCoW 框架
- 必须有：没有这些，功能不可行。不可商议。
- 应该有：重要但对发布不关键。高优先级的快速跟进项。
- 可以有：时间允许的情况下可取。如果被砍掉不会延迟交付。
- 不会有（这次）：明确排除在范围之外。可能在将来版本中重新考虑。
分类提示
- 对 P0 要严格。必须实现的列表越紧凑，交付和学习的速度就越快。
- 如果一切都是 P0，那就没有
P0。质疑每个必须实现："没有这个我们真的不能发布吗？"
- P1 应该是你有信心很快会构建的内容，而不是愿望清单。
- P2 是架构上的保险——它们指导设计决策，即使你现在不构建它们。
成功指标定义
领先指标
发布后很快（数天到数周）就会变化的指标：
- 采用率：符合条件的用户中尝试该功能的百分比
- 激活率：完成核心操作的用户百分比
- 任务完成率：成功达成目标的用户百分比
- 完成时间：核心工作流程需要多长时间
- 错误率：用户遇到错误或死胡同的频率
- 功能使用频率：用户回访使用该功能的频率
滞后指标
需要时间（数周到数月）才能显现的指标：
- 留存影响：此功能是否改善了用户留存？
- 收入影响：这是否推动了升级、扩展或新收入？
- NPS /
满意度变化：这是否改善了用户对产品的感受？
- 支持工单减少：这是否减轻了支持负担？
- 竞争胜率：这是否有助于赢得更多交易？
设定目标值
- 目标应具体："30 天内 50% 采用率"而非"高采用率"
- 目标值基于类似功能、行业基准或明确的假设
- 设定"成功"阈值和"拉伸"目标
- 定义测量方法：什么工具、什么查询、什么时间窗口
- 明确评估时间：发布后 1 周、1 个月、1 个季度
验收标准
以给定/当/那么格式或清单格式编写验收标准：
给定/当/那么：
- 给定[前提条件或上下文]
- 当[用户采取的操作]
- 那么[预期结果]
示例：
- 给定管理员已为其组织配置了 SSO
- 当团队成员访问登录页面
- 那么他们会被自动重定向到组织的 SSO 提供商
清单格式：
验收标准提示
- 覆盖正常路径、错误情况和边界情况
- 具体说明预期行为，而非实现方式
- 包括不应该发生什么（负面测试用例）
- 每个标准应可独立测试
- 避免模糊词语："快"、"用户友好"、"直观"——具体定义这些意味着什么
范围管理
识别范围蔓延
范围蔓延发生在以下情况：
- 在规格说明批准后不断添加需求
- "小"的添加累积成一个显著更大的项目
- 团队在构建没有用户要求的功能（"顺便……"）
- 发布日期间推移而没有明确的重新界定范围
- 利益相关者添加需求而不移除任何内容
防止范围蔓延
- 在每个规格说明中编写明确的非目标
- 要求任何范围添加都必须附带范围移除或时间线延长
- 在规格说明中清晰地区分"v1"和"v2"
- 对照原始问题陈述审查规格说明——每项内容是否都服务于它？
- 为调查设定时间限制："如果我们不能在 2 天内弄清楚 X，就砍掉它"
- 为不在范围内但好的想法创建一个"停车位"
输出格式
使用带有清晰标题的 Markdown
格式。保持文档可快速浏览——忙碌的利益相关者应能仅通过阅读标题和粗体文本就能抓住要点。
提示
- 对范围要有主见。紧凑、定义清晰的规格说明好过宽泛模糊的。
- 如果用户的想法太大无法用一个规格说明涵盖，建议将其分解为多个阶段并为第一阶段编写规格说明。
- 成功指标应具体且可衡量，而非模糊（"改善用户体验"）。
- 非目标和目标同样重要。它们防止实施过程中的范围蔓延。
- 待解决问题应该是真正开放的——不要包含你可以从上下文中回答的问题。