产品功能规格技能：把模糊需求变成可评审、可验收的 PRD
核心结论速览：
- 一句话定位：product-feature-spec 是一个专注于「写产品需求文档（PRD）」的 AI 技能，把口头需求、零散聊天记录，转成包含问题陈述、目标、非目标、用户故事、分级需求、成功指标、开放问题的结构化文档。
- 最强的地方在「结构」而不是「文采」：它内置了 8 段式 PRD 模板、MoSCoW 优先级框架、用户故事质量标准，输出的文档可以直接拿去评审，而不是再返工重写。
- 对产品经理最实用的两个细节：一是强制写「非目标」，防止范围蔓延；二是强制区分 P0/P1/P2，避免「什么都要」导致排期不可控。
- 上手门槛极低：只要能安装技能，用一句自然语言描述需求就能触发，无需学习新的模板语法。
- 适用边界要说清楚：它帮你把思路组织成文档结构，但用户研究数据、商业判断、技术成本仍需你提供真实输入，否则输出的只是「看起来很专业」的空壳。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能基本信息：
| 项目 | 内容 |
|---|---|
| 技能中文名 | 产品功能规格技能Skill |
| 技能英文名 | product-feature-spec |
| 技能 ID | 13781 |
| 技能类型 | 文档写作 / 产品管理类技能 |
| 触发时机 | 指定新功能、编写 PRD、定义验收标准、优先排序需求、记录产品决策 |
它到底解决什么问题？
产品团队最常见的浪费不是「写不出文档」，而是「写了没人能用的文档」。一份不能评审的 PRD 通常长这样：只有一段功能描述，没有说清用户在什么场景下遇到什么问题，没有说清这次不做什么，没有说清上线后用什么指标判断成功。结果是评审会上反复讨论「这到底算不算做完」，开发做到一半需求膨胀，上线后没人能证明这个功能有没有价值。
product-feature-spec 的思路是把这些「隐形标准」显性化：它不替你决定做什么功能，但会逼着你把问题陈述、可衡量目标、非目标、用户故事、P0/P1/P2 需求、验收标准、成功指标、开放问题全部写出来。文档结构对了，讨论才能收敛。
一键安装的思路与步骤：
技能详情中未提供具体的安装命令、技能市场链接与定价信息，以下为通用流程，具体入口与命令 以官方说明为准。
- 确认安装前提：你使用的 AI 工具需支持「AI 技能（Skill）」的加载机制，通常表现为技能市场安装、技能目录注册、或本地技能文件夹加载三种形式之一。
- 找到技能：在技能市场或技能仓库中按技能 ID 13781 或英文名 product-feature-spec 检索；若为本地加载方式，则需将技能目录放入平台约定的技能目录下。
- 执行安装/启用：点击安装或启用开关，确认技能状态变为「已安装 / 已启用」。若平台支持项目级与全局级开关，建议先在单个项目中启用，便于验证效果。
- 验证是否生效：新建一个会话，直接说「我要为一个新功能写 PRD：给团队管理员做单点登录配置」，观察输出是否自动出现「问题陈述 / 目标 / 非目标 / 用户故事 / 需求分级 / 成功指标」这类结构化小标题。若没有出现，说明技能未加载，检查是否在当前会话中启用了该技能。
- 固化使用习惯：把「写 PRD 前先调这个技能」写进团队的需求流程，避免只有部分人用、文档风格再次分裂。
这种「一键安装」的价值在于：团队无需自建一套 PRD 模板规范、无需培训每个人记住八个小节，规范被封装进技能里，安装即对齐。
该技能的主要功能和特点
核心功能：
- 标准 PRD 八段式结构输出：问题陈述、目标、非目标、用户故事、需求、成功指标、开放问题、时间线考虑，一次生成完整骨架，避免「想到哪写到哪」。
- 问题陈述的强制追问：要求用 2-3 句话说明用户问题、谁在经历、频率、不解决的代价，并强调基于证据（用户研究、支持数据、指标、客户反馈）。
- 目标与输出的严格区分：明确要求目标写成结果而非输出，例如「把首次价值时间减少 50%」而不是「做一个引导向导」。
- 非目标（Non-goals）生成：列出 3-5 件这个版本明确不做的事，并解释原因（影响不够、太复杂、单独计划、过早），用于对齐利益相关者预期。
- 用户故事规范化：按「作为[用户类型]，我想要[能力]以便[好处]」格式生成，并要求用户类型足够具体（如「企业管理员」而非「用户」）、覆盖错误状态与空状态等边缘情况、按优先级排序。
- 需求分级（P0/P1/P2）与 MoSCoW 双框架：必须有 / 最好有 / 未来考虑，对应 MoSCoW 的 Must / Should / Could / Won’t，并为每个需求附带验收标准、技术约束、跨团队依赖标记。
- 用户故事质量校验：按 INVEST 特征（独立、可协商、有价值、可估计、小、可测试）审视故事是否合格，并主动指出常见错误（太模糊、规定实现方案、无收益、粒度过大、内部任务冒充用户故事）。
- 开放问题与阻塞标记：区分「必须在开发前回答」的阻塞问题与「可在实施中解决」的非阻塞问题，并标注应由工程、设计、法律、数据还是业务方回答。
和普通文档工具、通用聊天 AI 比强在哪？
- 普通文档模板只给空表格，不会追问「你不做什么」；该技能会把非目标、开放问题作为必填项推到你面前。
- 通用 AI 写 PRD 容易写成「功能说明书」，把需求描述成 UI 组件；该技能明确禁止「我想要一个下拉菜单」这类解决方案先行写法。
- 它内置优先级纪律：「如果一切都是 P0，那就什么都不是」，并提示随着工程成本明朗要重新评估优先级，一个便宜的 P1 可能比昂贵的 P0 更值得做。
- 它带「时间线考虑」小节，会主动提示硬截止日期、跨团队依赖，以及功能过大时建议分阶段交付。
如何使用该技能？
以下为通用使用流程，具体交互入口与调用语法 以官方说明为准。
步骤 1：用一句话交代背景与目的
不要一上来就写功能，先给上下文。例如：
我们是一个 B 端协作工具，最近企业客户在采购评审中反复要求单点登录（SSO）能力，销售侧因此丢了 3 个单子。请帮我写一份 SSO 配置功能的 PRD。
输出预期：技能会先给出「问题陈述」草稿，并提示你补充证据来源（客户访谈、销售丢单记录、支持工单等）。
步骤 2：补齐目标与非目标
接着输入你的业务判断，例如：
目标：企业客户采购评审通过率提升，管理员配置时间控制在 10 分钟内。这次不做 SCIM 自动同步，也不做多 IdP 并行。
输出预期：技能会把「不做 SCIM 同步」写成非目标并解释原因（复杂度高、可后续版本单独规划），同时提醒你补充可量化的成功指标。
步骤 3：让技能生成用户故事
涉及角色：团队管理员、普通成员、IT 审计。请按角色分别写用户故事，并补上配置失败、凭据过期这类边缘情况。
输出预期：得到类似「作为团队管理员，我想为我的组织配置 SSO，以便我的团队成员可以用企业凭据登录」「作为团队成员，我想自动跳转到公司的 SSO 登录，以便不需要记住单独密码」「作为团队管理员，我想查看哪些成员通过 SSO 登录，以便验证部署是否有效」这样按角色分层、含验证类故事的一组条目。
步骤 4：做需求分级并写验收标准
帮我把需求分成 P0/P1/P2，每个 P0 都给出验收标准。
输出预期：P0 通常是「管理员可完成一次成功的 SSO 登录验证」这类最小可行集；P1 可能是登录统计面板；P2 可能是多 IdP 支持。每个条目附带验收标准与技术依赖标记。
步骤 5：收尾处理开放问题与时间线
我们有一个合同承诺在季度末交付，帮我整理开放问题和时间线风险。
输出预期：技能会区分阻塞问题（如「是否支持 SAML 1.1」需在开发前由业务方确认）与非阻塞问题，并标注责任方；若判断功能体量过大，会建议分阶段发布。
步骤 6：人工复核
这一步不能省。重点检查三件事：证据是否真实、成功指标是否可测量、非目标是否与业务方达成一致。技能负责结构，你负责事实。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| product-feature-spec（本技能） | 专注 PRD 与功能规格的结构化写作技能 | 八段式 PRD 模板、MoSCoW/P0-P2 分级、用户故事规范与常见错误校验、非目标与开放问题管理 | 低，安装后在对话中自然语言触发，无需学新语法 | 新功能立项、需求评审前成稿、验收标准定义、产品决策留痕 | 优势：结构纪律强，强制补非目标与指标，输出可直接评审；不足：不提供用户研究数据与商业判断，需人工补事实 |
| 通用大模型对话（不装技能） | 通用写作与问答助手 | 可写任意文档，自由度高 | 极低，开箱即用 | 快速起草、头脑风暴 | 优势：灵活；不足：PRD 结构不稳定，容易写成功能说明书，缺少优先级与非目标的强制约束，团队内风格难统一 |
| 文档协作平台的 PRD 模板 | 协作文档中的静态模板 | 提供标题骨架与占位提示 | 低，复制模板即可 | 团队文档归档、轻量需求记录 | 优势：便于多人协作评论与版本管理；不足：模板不会追问，缺内容也不会提醒，优先级与验收标准靠人自觉 |
| 需求管理/项目管理工具 | 需求条目化与流程跟踪 | 需求池、看板、状态流转、关联任务 | 中，需配置项目与字段 | 研发流程管理、迭代排期 | 优势：与开发流程打通，可追踪；不足：擅长「管理条目」，不擅长「写出有逻辑的需求论证」，前置论证仍需文档能力 |
选择建议：如果你缺的是「把想法写成能评审的文档」，用本技能；如果你缺的是「文档存哪里、谁批的、什么时候做完」，那是协作或项目管理工具的活，两者是互补关系而不是替代关系。
该技能的典型应用场景与实际体验情况
场景一：B 端产品的企业能力立项（产品经理）
痛点：销售催着要功能，但说不清具体客户诉求和影响面，PRD 容易写成「销售要什么就写什么」。使用方式：把销售丢单记录、客户访谈要点丢给技能，让它先产出问题陈述与目标，再逐段补全。实际体验：最容易卡在「证据」环节——技能会反复要求说明谁在经历这个问题、频率如何，这会倒逼 PM 去找数据，这恰恰是最有价值的一步。注意事项：如果只给一句「客户要 SSO」，输出会显得单薄，输入质量决定输出质量。
场景二：需求评审会前的自查（产品经理 / 评审主持人）
痛点：评审会上争论「这个需求到底做不做」「P0 是不是太多」。使用方式：让技能按 MoSCoW 与 P0/P1/P2 重排需求，并逐条给出「如果我们砍掉这个，功能是否仍能解决核心问题」的判断依据。实际体验：上手难度低，效果立竿见影——把「什么都是 P0」拆开后，评审时间明显收敛。注意事项：优先级重排会触及各方利益，技能只给逻辑，最终取舍仍需业务负责人拍板。
场景三：跨团队依赖与合规类功能的规格梳理（技术负责人 / 平台团队）
痛点：涉及法务、数据、其他团队的依赖散落在聊天记录里，容易漏。使用方式：让技能生成开放问题清单并标注责任方（工程、设计、法律、数据、利益相关者），区分阻塞与非阻塞。实际体验：这类场景下「开放问题」小节比「用户故事」小节更有用，能把隐性协作风险显性化。注意事项：技能不了解你公司的组织架构，责任方标注需要人工修正。
场景四：新成员理解「为什么做这个功能」（产品团队协作）
痛点：功能上线半年后，没人记得当初为什么这么设计。使用方式：把技能产出的 PRD 连同非目标、决策背景一起归档。实际体验：长期价值大于短期价值——非目标和开放问题的记录，成为后续复盘与「为什么不做 X」的最佳答案。注意事项：需团队约定统一归档位置，否则文档还是会散。
该技能能为用户带来的价值
效率层面： 把「从空白文档开始写 PRD」变成「补全八个已就位的模块」。以往一份完整 PRD 从零起草到可评审，往往需要数小时甚至跨天反复修改；使用技能后，骨架和追问一次性给出，PM 的主要精力从「想结构」转移到「填事实」，起草环节的时间显著压缩（具体节省幅度因团队与需求复杂度而异）。
质量层面： 强制补齐三个最容易被省略、却最影响评审效率的模块——非目标、验收标准、成功指标。这三项到位后，需求返工率和评审争议都会下降，因为「做到什么程度算完成」在开工前就已写清。
协作层面： 统一的八段式结构让产品、设计、工程、业务方在同一套语言下讨论。非目标用于对齐预期，开放问题用于明确谁在什么时候回答什么，减少了「会上没结论、会后各自理解」的情况。
门槛层面： 对没有系统学过需求工程的产品新人，技能内置的用户故事质量标准与常见错误清单（太模糊、规定实现方案、无收益、粒度过大、内部任务冒充用户故事）本身就是一份可随时调用的写作教练，降低了写出合格 PRD 的经验门槛。
长期价值： 每份 PRD 都记录了决策背景与非目标，形成可追溯的产品决策档案。当团队需要复盘、交接或回答「当初为什么不做这个」时，这些文档就是最直接的依据。
常见问题 FAQ
Q1：这个技能怎么安装？安装后怎么确认生效？
A：技能详情中未提供具体安装命令与入口，请 以官方说明为准。通用流程是：在技能市场或技能仓库按技能 ID 13781 或英文名 product-feature-spec 检索，执行安装或启用；若为本地加载形式，则将技能目录放入平台约定的技能目录。验证方式最简单：新建会话，直接说「帮我写一份新功能的 PRD」，观察输出是否自动带上问题陈述、目标、非目标、用户故事、需求分级、成功指标等结构化小节。
Q2：收费吗？
A：技能详情中未包含任何定价信息，是否收费、是否有免费额度 以官方说明为准。建议在安装前先确认所在平台对技能调用的计费方式。
Q3：它会不会替我做产品决策？
A：不会，也不应该。它的定位是「PRD 与功能规格的写作专家」，负责结构、追问和规范校验；做什么功能、优先级怎么排、成功指标定多少，仍由你和业务方基于真实证据决定。如果输入只有一句模糊需求，输出会是一份结构完整但内容单薄的文档，需要你补齐事实。
Q4：适合谁用？
A：最适合产品经理、产品负责人，以及需要撰写功能规格的技术负责人和平台团队；承担需求评审、验收标准定义职责的项目经理同样适用。对完全没有需求文档需求的纯执行岗位，价值有限。
Q5：和通用 AI 写 PRD、或公司现成的文档模板怎么选？
A：看你要解决的是「结构纪律」还是「协作存储」。本技能解决结构纪律——内置八段式模板、MoSCoW 与 P0/P1/P2 分级、用户故事质量校验、非目标与开放问题强制项，适合需要频繁产出可评审 PRD 的团队；协作文档模板解决「存哪里、谁评论、版本怎么管」；项目管理工具解决「条目追踪与排期」。三者互补，实践中常见做法是：用技能生成与打磨内容，再落到团队统一的协作平台归档。