在寫程式碼之前先要一份計劃
對於任何不平凡的事，把思考和打字分開。先讓 AI 勾勒出它的思路。這能在錯誤的假設變成 200 行錯誤程式碼之前就抓住它，而修一份計劃要比修一個 便宜得多。
我想給我的 API 加上限流。在寫任何程式碼之前，
給我一份簡短的計劃：限流器該放在哪裡、需要
什麼樣的儲存、達到上限時會發生什麼，以及有哪些
取捨。先別寫程式碼——我會先批准方案。
當計劃看起來對了，就說"好，實現第 1 步"。當它不對時，你花了三十秒糾正航向，而不是花一小時去解開一團亂碼。先做計劃，是最能把工程師式提示詞與一廂情願式提示詞區分開來的習慣。
計劃階段也是你抓住 AI 選了比所需更重的方案的地方——明明一個記憶體裡的 map 就夠，它卻伸手去夠 Redis；明明一行庫呼叫就能解決，它卻手搓一套。帶著一個問題去讀計劃：這是能跑通的最簡單做法嗎？ 如果這個思路聞著像過度設計，就在一行程式碼落地之前用大白話頂回去（"這是個單伺服器的業餘專案——能不能跳過分散式儲存？"）。