20 個讓 AI 不再亂猜的寫程式提示詞

多數糟糕的 AI 程式碼,都是因為模型自己填補了你留下的空白。這裡的每個提示詞都補上一個空白:模型先讀再寫,先測試再修正,還會把自己的猜測依可能性大聲排序。

請把[方括號]裡的內容換成你自己的程式碼、錯誤訊息或目標。

01. 動手前先畫出影響範圍

要修改不是你寫的程式碼之前。

請閱讀下面的程式碼。目前先不要撰寫或修改任何程式碼。

請告訴我:
1. 它在做什麼,最多三句話。
2. 它對輸入、呼叫端和執行環境做了哪些假設,請全部列出。
3. 如果我要[描述你想做的修改],會有什麼壞掉,壞在哪裡。

如果需要看另一個檔案才能回答,請指出檔名然後停下來。

[貼上程式碼]

02. 先排出可能的原因,再來寫修正

遇到一個你還解釋不了的錯誤。

這是一則錯誤訊息和它周圍的程式碼。

請列出三個最可能的原因,最可能的排第一。每個原因都請給我一行日誌或一個測試,用來確認或排除它。

先不要提出修正方案。我會執行檢查,再告訴你是哪個原因。

錯誤訊息與堆疊追蹤:
[貼上錯誤訊息]

程式碼:
[貼上相關程式碼]

03. 先寫會失敗的測試,然後停手

在你要求新程式碼或修正之前。

請使用[測試框架],為[函式或功能]撰寫測試。

涵蓋一般情況、這些邊界情況:[列出你已經知道的],以及至少兩個你認為我沒想到的情況。請用一行說明這兩個情況各自為什麼重要。

每個測試對目前的程式碼或尚未實作的部分都應該失敗。不要撰寫實作。

免費解鎖其餘 17 則提示詞

訂閱 Whizi 電子報,即可閱讀這個提示詞包的其餘內容。

  1. 以半夜被叫起來處理的人的角度審查 diff
  2. 重構時不改變任何行為
  3. 挑出最先該讀的五個檔案
  4. 對著你真實的資料表結構寫查詢
  5. 取得附上驗證案例的正規表示式
  6. 移植程式碼,讀起來像原生寫的
  7. 從真實的效能分析結果找出時間花在哪
  8. 追蹤不受信任的輸入,從來源到落點
  9. 寫一份陌生人也能看懂的 README
  10. 根據 diff 寫出 commit 訊息
  11. 用你自己的程式碼學一個觀念
  12. 先設計 API,再攻擊這個設計
  13. 規劃一個不會讓網站停機的遷移
  14. 讓模型來問你問題
  15. 列出會讓它出錯的輸入
  16. 找出相依套件升級會弄壞你程式碼的地方
  17. 請第二個模型為第一個模型打分數