20 個讓 AI 不再亂猜的寫程式提示詞
多數糟糕的 AI 程式碼,都是因為模型自己填補了你留下的空白。這裡的每個提示詞都補上一個空白:模型先讀再寫,先測試再修正,還會把自己的猜測依可能性大聲排序。
請把[方括號]裡的內容換成你自己的程式碼、錯誤訊息或目標。
01. 動手前先畫出影響範圍
要修改不是你寫的程式碼之前。
請閱讀下面的程式碼。目前先不要撰寫或修改任何程式碼。 請告訴我: 1. 它在做什麼,最多三句話。 2. 它對輸入、呼叫端和執行環境做了哪些假設,請全部列出。 3. 如果我要[描述你想做的修改],會有什麼壞掉,壞在哪裡。 如果需要看另一個檔案才能回答,請指出檔名然後停下來。 [貼上程式碼]
02. 先排出可能的原因,再來寫修正
遇到一個你還解釋不了的錯誤。
這是一則錯誤訊息和它周圍的程式碼。 請列出三個最可能的原因,最可能的排第一。每個原因都請給我一行日誌或一個測試,用來確認或排除它。 先不要提出修正方案。我會執行檢查,再告訴你是哪個原因。 錯誤訊息與堆疊追蹤: [貼上錯誤訊息] 程式碼: [貼上相關程式碼]
03. 先寫會失敗的測試,然後停手
在你要求新程式碼或修正之前。
請使用[測試框架],為[函式或功能]撰寫測試。 涵蓋一般情況、這些邊界情況:[列出你已經知道的],以及至少兩個你認為我沒想到的情況。請用一行說明這兩個情況各自為什麼重要。 每個測試對目前的程式碼或尚未實作的部分都應該失敗。不要撰寫實作。
免費解鎖其餘 17 則提示詞
訂閱 Whizi 電子報,即可閱讀這個提示詞包的其餘內容。
- 以半夜被叫起來處理的人的角度審查 diff
- 重構時不改變任何行為
- 挑出最先該讀的五個檔案
- 對著你真實的資料表結構寫查詢
- 取得附上驗證案例的正規表示式
- 移植程式碼,讀起來像原生寫的
- 從真實的效能分析結果找出時間花在哪
- 追蹤不受信任的輸入,從來源到落點
- 寫一份陌生人也能看懂的 README
- 根據 diff 寫出 commit 訊息
- 用你自己的程式碼學一個觀念
- 先設計 API,再攻擊這個設計
- 規劃一個不會讓網站停機的遷移
- 讓模型來問你問題
- 列出會讓它出錯的輸入
- 找出相依套件升級會弄壞你程式碼的地方
- 請第二個模型為第一個模型打分數