一個常見陷阱：規定的是解決方案，而非問題

有一種失敗模式值得單獨拎出來說，因為它實在太容易掉進去了。當你坐下來寫規格時，誘惑在於去描述你腦中已經想好的那個解決方案——"一個帶標籤頁的側邊欄""一個彈出來的模態框""一張 Postgres 表"。但一份滿是解決方案的規格，會悄悄鎖定一些你還沒資格去做的決定。

對比這兩行：

差:  新增一個左側邊欄，每個書籍狀態有可摺疊的分割槽。
好:  讓我能按狀態分組檢視書籍，又不丟失完整列表。

第一句已經選定了一個側邊欄、可摺疊的分割槽，以及一種佈局——而這一切都在還沒人確認它們是不是正確的選擇之前。第二句陳述的是要完成的活，讓 AI（以及你）有自由去找到能滿足它的最簡單方案，而那也許只是三個篩選按鈕。描述你想要的結果；讓實現儘可能長久地保持可商量。解決方案在規格里改起來很便宜，在程式碼裡改起來卻很昂貴。