wwas

wwas 技能概览

wwas 是一款用于把产品待办事项写成 Why-What-Acceptance 格式的提示词技能。需要一条不只是“功能摘要”的 backlog item 时，就用 wwas：它应该说明业务原因，清楚描述变更内容，并定义团队可以测试的验收标准。

这项技能非常适合产品经理、分析师、设计师，以及需要把零散功能想法转成可直接进入冲刺的工作项的 AI agent。它真正要解决的任务，是在保留战略上下文的同时，让条目保持独立、可交付、可协商。wwas 尤其适合你希望团队使用统一的 backlog 表达方式、又不想把实现细节规定得过死的时候。

wwas 最适合什么场景

wwas 最适合用于功能拆解、渐进式产品交付，以及跨职能规划——在真正写代码之前，团队先需要把意图说清楚。它在原始输入比较杂乱时尤其有用，比如会议纪要、设计链接，或者只有半成型诉求的一句话。

wwas 的差异在哪里

和通用提示词相比，wwas 会强制模型把 Why、What 和 Acceptance Criteria 分开。这能减少模糊不清的 ticket，控制范围更小，也让结果更适合在规划会上评审。它还会鼓励生成可以排序、估算和测试的条目，而不会把提示词写成一份完整规格说明。

什么时候适合安装 wwas

如果你的工作流依赖 backlog 整洁度、稳定的 ticket 质量，或者 AI 辅助需求规划，那么就适合安装 wwas。它最有价值的场景，是团队需要一套共享的 Requirements Planning 格式，而不是临时写几段说明文字。

如何使用 wwas 技能

安装 wwas 并找到源文件

使用 npx skills add phuryn/pm-skills --skill wwas 安装该技能。然后先阅读 SKILL.md，因为里面包含了决定 wwas 用法的工作流、条目模板和参数列表。如果你打算把它改成符合自己流程的版本，也建议顺手查看更大的 skill 目录，确认相邻技能里有没有可沿用的约定。

传给 wwas 的内容是什么

wwas 最适合接收四类输入：产品或系统名称、功能或能力描述、设计链接（如果有）、以及假设或战略上下文。像“改进 onboarding”这种弱输入，通常只会产出含糊的验收标准。更好的输入会明确写出：产品名称、目标用户、期望结果和约束条件。

如何写出更好的提示词

一条好的 wwas 提示词，会把交付单元和业务原因都说清楚。例如：“为 mobile checkout flow 创建一个 WWA 条目。Why：降低回访用户的购物车放弃率。What：基于 Figma 链接增加已保存支付方式选择。Assumptions：仅限已认证用户，不引入新的支付 provider。” 这样给到的上下文足够，技能就能产出可直接使用的 backlog item，而不是一段好看的说明文字。

Requirements Planning 的实用工作流

在你已经有了功能方向、但还没进入详细规格阶段时，用 wwas 最合适。第一步，收集粗略需求和任何设计或调研笔记。第二步，运行 wwas，生成 Why-What-Acceptance 结构。第三步，检查这个条目是否独立、范围是否合适、是否可测试。如果它仍然把多个结果打包在一起，就拆开，再对更小的单元重新运行 wwas。

wwas 技能常见问题

wwas 只适合产品经理吗？

不是。只要你需要工程和设计团队都能直接使用的 Requirements Planning 输出，wwas 就很有用：产品经理、业务分析师、创始人、交付负责人，以及使用 AI 辅助文档工作流的人都适合。

wwas 和普通提示词有什么不同？

普通提示词可能只会生成一段功能说明。wwas 更聚焦：它会强制输出带战略上下文、简洁功能描述和可观察验收标准的 backlog item 结构。通常这意味着生成后需要的整理工作更少。

使用 wwas 一定要有设计文件吗？

不一定，但设计链接会提高准确度。如果没有设计稿，也要提供足够的上下文，说明用户需求、工作边界和预期行为。否则，这个技能很可能产出范围过大的条目。

什么时候不该用 wwas？

当你需要详细技术设计、实现任务或发布说明时，不要用 wwas。它是 Requirements Planning 工具，不是代码规格生成器。

如何改进 wwas 技能

给它更明确的问题陈述

最好的 wwas 输出，通常从一个具体的用户或业务问题开始。把“加筛选”改成“帮助支持坐席在高峰队列中更快找到未关闭工单”。这种输入会让 Why 部分更扎实，也能避免产出泛泛而谈的验收标准。

早点说明边界

当你明确说明哪些内容不在范围内时，wwas 的表现会更好。如果功能只是 mobile-only、internal-only，或者只面向某个用户细分，最好一开始就说清楚。这样可以防止验收标准跑偏到无关场景。

检查独立性和可测试性

wwas 使用中最常见的失败方式，是一个 backlog item 混进了多个交付内容。如果输出把 UI、analytics 和 permissions 全塞进一条里，就应该把这些关注点拆开，再重新运行该技能。也要确认验收标准描述的是可观察到的结果，而不是实现细节。

用第一版继续迭代

把第一版 wwas 输出当作规划草稿来用。如果 Why 太弱，就把业务目标反馈回去；如果 What 太大，就缩小功能范围；如果验收标准太模糊，就补上角色、触发条件和预期结果。通常，这样的迭代循环，比一开始堆更多上下文，更能提升最终的 Requirements Planning 产出质量。