jiantw83andClaude Opus 5
549bd29313
四份規則正本，各自列出要對著需求議題回答的檢查項，回答不出來的就是一個要問 使用者的問題。每份末尾都交代「問題怎麼問」——檢查項只說要查什麼，不說怎麼把 它變成一句能收斂的提問，那才是實際卡住的地方。 四份各自點出一個最該先問的：架構問落點與循環相依，邏輯問既有功能是不是已經 做過同一件事（這條能整個取消工作），資料問 schema 與遷移（答案通常不在議題裡）， 時程問未知數最大的一項（它決定整體估算的可信度）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1.1 KiB
1.1 KiB
邏輯可行性檢查
問的是「這件事是不是已經有人做過、或者根本不必做」。
檢查項
- 重複 — 既有功能裡有沒有已經在做同一件事的？若有，是要沿用、擴充，還是取代？
- 相近但不同 — 有沒有看起來很像但語意不同的既有功能？兩者的差別是什麼、 會不會讓使用者混淆？
- 真正的需求 — 使用者描述的是解法還是問題？若是解法，背後要解的問題是什麼？ 有沒有更直接的做法？
- 邊界情境 — 空值、極大量、並行操作、重複執行，各自該怎麼表現？ 需求議題的驗收標準有沒有把這些寫進去？
- 失敗時的行為 — 這件事做到一半失敗會怎樣？要回滾、要留下半成品，還是要能續跑？
- 誰會消費 — 產出的東西給誰用？那個消費者現在是怎麼取得同樣資訊的？
問題怎麼問
「既有功能已經做過同一件事」是最值得先問的一條——它能整個取消這次工作。 先查再問：能在程式碼裡查證的就不要拿去問使用者。