wwas

wwas 技能概覽

wwas 是一個用來撰寫 Why-What-Acceptance 格式產品待辦項目的 prompt skill。當你需要的不是只有功能摘要，而是要把商業原因說清楚、明確描述變更內容，並定義出可供團隊驗證的驗收標準時，就適合使用 wwas 技能。

這個技能很適合產品經理、分析師、設計師，以及需要把模糊功能想法轉成可進入 sprint 的工作項目的 AI agents。它真正要完成的工作，是在保留策略脈絡的同時，讓項目維持獨立、具價值且可協商。wwas 技能特別適合你想在團隊內維持一致的待辦語言，又不想把實作細節寫得過度具體的情境。

wwas 最適合的用途

wwas 最適合用在功能拆解、漸進式產品交付，以及跨部門規劃；這些情境都需要團隊先對意圖有清楚理解，再進到程式碼層面。當你的原始輸入很雜亂時，例如會議紀錄、設計連結，或只完成一半的需求，wwas 也很有幫助。

wwas 為什麼不一樣

和一般的 prompt 相比，wwas 會強迫模型把 Why、What 和 Acceptance Criteria 分開。這樣能減少含糊不清的票卡，讓範圍更小，也讓輸出在規劃會議中更容易審查。它同時也鼓勵產出可排序、可估算、可測試的項目，而不會把 prompt 變成一份完整規格書。

什麼情況適合安裝 wwas

如果你的工作流程仰賴待辦品質整理、可重複的票卡品質，或 AI 協助的需求規劃，那就適合安裝 wwas。當你的團隊需要一套共享的 Requirements Planning 格式，而不是一次性生成散文式內容時，它的價值最高。

如何使用 wwas 技能

安裝 wwas 並找到來源檔案

使用 npx skills add phuryn/pm-skills --skill wwas 安裝這個技能。接著先閱讀 SKILL.md，因為裡面包含了 wwas 的工作流程、項目模板與參數清單，這些內容會直接影響它的使用方式。如果你打算依照自己的流程做調整，也建議一併檢視更大的 skill directory，看看相鄰技能是否有共同慣例。

要提供給 wwas 的內容

wwas 最好搭配四種輸入：產品或系統名稱、功能或能力、如果有的話提供設計連結，以及假設或策略脈絡。像「改善 onboarding」這種薄弱輸入，通常只會得到很空泛的驗收條件。較好的輸入會包含：產品名稱、目標使用者、期望結果，以及限制條件。

如何寫出更好的 prompt

一個好的 wwas prompt 會直接點出交付單位與商業理由。比如說：「為 mobile checkout flow 建立一個 WWA 項目。Why：降低回訪使用者的購物車放棄率。What：加入已儲存付款方式選擇，並使用 Figma 連結。Assumptions：僅限已驗證使用者，不新增支付服務商。」這樣的脈絡足夠讓技能產出可用的待辦項目，而不只是修飾過的段落。

Requirements Planning 的實際工作流程

當你已經有功能方向，但還沒進入細部規格時，就可以使用 wwas。第一步，收集粗略需求和任何設計或探索紀錄。第二步，執行 wwas 產出 Why-What-Acceptance 結構。第三步，檢查是否具獨立性、範圍是否合理、以及是否可測試。如果項目仍然把多個結果綁在一起，就把它拆開，針對較小的單位再跑一次 wwas。

wwas 技能 FAQ

wwas 只適合產品經理嗎？

不是。只要你需要能讓工程與設計直接採取行動的 Requirements Planning 產出，wwas 都很有用：產品經理、商業分析師、創辦人、交付主管，以及 AI 輔助的文件工作流程都適用。

wwas 和一般 prompt 有什麼不同？

一般 prompt 可能只會產出一段功能說明。wwas 的範圍更明確：它會強制輸出帶有策略脈絡、簡潔功能描述，以及可觀察的驗收條件的待辦項目結構。這通常代表生成後需要的整理更少。

使用 wwas 一定要有設計檔嗎？

不一定，但設計連結可以提升精準度。如果你沒有設計檔，至少要提供足夠的脈絡來定義使用者需求、工作範圍邊界，以及預期行為。少了這些，技能可能會產出過於寬泛的項目。

什麼時候不該用 wwas？

當你需要的是詳細技術設計、實作任務，或 release notes 時，不要用 wwas。它是 Requirements Planning 工具，不是產生程式實作規格的工具。

如何改進 wwas 技能

把問題陳述說得更尖銳

最好的 wwas 輸出，通常都從具體的使用者或商業問題開始。把「新增篩選器」改成「幫助客服在大量案件佇列中更快找到未結案件」。這類輸入能改善 Why 區塊，也能避免驗收條件變得千篇一律。

先把邊界講清楚

當你先說明哪些內容不在範圍內，wwas 的表現會更好。如果功能只限 mobile、只限內部使用者，或只針對某個使用者群組，就應該一開始講明。這樣可以避免驗收條件往不相關的案例發散。

檢查獨立性與可測試性

wwas 最常見的失敗模式，是一個待辦項目混進了多個交付內容。如果輸出把 UI、分析追蹤與權限控制全塞進同一個項目，就應該把這些面向拆開，再重新執行技能。也要確認驗收條件描述的是可觀察的結果，而不是實作細節。

用第一版持續迭代

把第一次的 wwas 輸出當成規劃草稿來看。如果 Why 不夠強，就回填商業目標。如果 What 範圍太大，就把功能縮小。如果驗收條件太模糊，就補上角色、觸發條件與預期結果。這種迭代循環，通常比一開始再多塞一些脈絡，更能提升最後的 Requirements Planning 成果。