指明輸入、輸出和邊界情況

一個任務在它的邊界被定義之前都不算被定義。資深工程師以"什麼進去、什麼出來、出錯時會發生什麼"的方式思考。把這些烤進提示詞裡。

寫一個解析日期字串的函式。

寫一個函式 parseDate(input: string): Date | null。

輸入：ISO 8601 字串（"2026-06-14"、"2026-06-14T10:30:00Z"）。
輸出：一個 Date 物件，若字串無效則返回 null。

需要處理的邊界情況：
- 空字串或僅有空白 -> null
- 格式合法但日期不可能（2026-02-30）-> null
- 末尾有垃圾字元（"2026-06-14xyz"）-> null

不要 throw。對所有無效輸入都返回 null。

當你點名說出邊界情況時，AI 就會處理它們。當你不說時，它寫順利路徑，然後你在生產環境裡發現那些缺口。同樣的紀律也適用於純函式之外：對一個端點，要指明成功響應以及錯誤響應（重複的郵箱返回什麼狀態碼？請求體格式錯誤時呢？）。對一個 UI 元件，要指明空狀態和載入狀態，而不只是有資料的狀態。大多數軟體有意思的行為都住在它的邊緣，所以你的提示詞也應當在那裡花筆墨。

如果你不確定邊界情況有哪些，就先問 AI："一個日期解析器應該處理哪些邊界情況？"——然後把答案當作約束喂回去。這把模型從一個程式碼生成器變成了一個清單生成器，而審查一份清單，比除錯你忘掉的那些情況要快。