問題描述三層素材

方法論 Three-layer Requirement Articulation、需求描述三件組 2026/5/5

替代「貼 AI 程式碼給工程師」的需求溝通方法，由文字描述、截圖、期望 vs 實際三層組成。對應 [[腦補解法|ai-solution-bias]] 的解方端。

三層素材

不需要寫得像 spec，用日常語言講一遍即可。

範例：

客人在後台下完訂單後，店家手機沒收到通知，我希望每筆訂單成立時 LINE 都能推一則訊息給我。

為什麼有用： 30 秒就能寫完，但提供的資訊比 50 行 AI 程式碼還多——它包含了「使用者（店家）」「動作（下訂單）」「期望（推訊息）」「管道（LINE）」「現況（沒通知）」。

bug 回報的最快溝通方式。截圖會帶出客戶自己沒注意到的線索：

對應 [[screenshot-driven-development|截圖驅動開發法]] 的核心原則——視覺資訊比文字描述精準，套在需求溝通上同樣成立。

這是最有效的反腦補解法句型。對比示範：

解法描述（AI 容易給的）	現象描述（這裡要的）
❌「我覺得應該要在 functions.php 加一個 add_filter 處理」	✅「結帳時運費應該按照購物車總金額分級，現在不管金額多少都收 100 元」
❌「請改用 transient 快取 API 回應」	✅「商品列表頁載入要 8 秒，希望 2 秒內」
❌「在 wp-config.php 加 WP_DEBUG_LOG」	✅「結帳按鈕按下去沒反應，後台訂單也沒進來」

第一欄是解法（且通常是 AI 給的），第二欄是現象。現象描述清楚之後，解法是工程師的工作，那才是客戶付錢請工程師做的事。

不要禁用 AI，把使用點移位即可。

反模式： 把問題丟給 AI → 拿 AI 給的程式碼 → 貼給工程師

正模式： 把想做的事描述給 AI → 讓 AI 幫忙整理問題說明、列關鍵情境、釐清期望差異 → 把整理過的「問題說明」貼給工程師

差別是 AI 的角色從「代寫程式」變成「整理需求」，後者是 AI 真正擅長且不會出錯的事。