業州愚公撰寫的《AI 工具實操與提示詞》系列文章中提到，一位轉職的朋友在使用 AI 工具幫助優化程式碼時遇到問題。朋友將一支爬資料的腳本貼進 AI 對話框，要求「幫我優化一下」，結果 AI 交回的版本雖然看起來更漂亮，但卻偷偷改掉了空資料的處理，導致程式碼報錯。為了避免此類問題，業州愚公提出使用三個提示詞，將重構與除錯拆成可驗收的流程：先讓 AI 只讀不改，講清它看到什麼；再讓它一輪只動一處並寫出理由；最後讓它先立假設，然後給出能執行的驗證步驟。這樣可以確保 AI 的修改是可控和可驗證的，避免類似的錯誤發生。
菜鳥之友系列：《AI 工具實操與提示詞》・模板篇作者：業州愚公
上週幫一位轉職的朋友看他接的小案子。他要改一支爬資料的腳本，於是開新對話，把檔案貼進去，寫了五個字：「幫我優化一下」。AI 很快回了一份改好的版本，加了型別註解、把迴圈改寫成串列推導式、函式拆得更短，看起來漂亮很多。他貼回去跑，第一次就報錯，改了半天才發現有一處邊界條件被改掉了——原本遇到空資料會跳過，改完變成整支停掉。
問題不在 AI 會不會寫程式。它會寫，而且寫得不差。問題在你交出去的是一道沒有驗收標準的題目。「優化」不是需求，是一個形容詞；它不知道你要的是跑得快、看得懂、還是以後好改，也不知道哪些行為是你絕對不能動的。它只能按自己的偏好選，而它的偏好是「讓 diff 看起來很專業」。
要讓它改得你放心，得把這件事拆成三步：先讓它只讀不改，講清楚它看到什麼；再讓它分開動刀，一次只做一件事，並且講出理由；最後給它驗證條件，讓它自己回答「怎麼證明沒改壞」。三個模板就按這個順序排。
AI 改程式的主要風險不是寫錯語法，語法錯誤還算好消息——馬上就報錯。真正貴的是靜默的行為改變：函式簽章動了、回傳型別從陣列變成物件、空值處理換了寫法、例外從拋出改成吞掉、預設參數值被「順手」改了。這些改動不會報錯，跑起來也像對的，等到上線某個少見的輸入進來才炸。
第二個風險是範圍失控。你貼了 200 行讓它修一個 bug，它還你 400 行——順便幫你把命名改了、把註解刪了、把兩個檔案合併了、還把你不認識的相依套件引進來。你想 review，但改動面已經大過你能一眼看完的量，最後只能憑感覺按接受。
這兩個風險有共同的來源：你把「診斷」和「治療」放在同一句話裡，它就只能一邊猜病因一邊開刀。所以模板一是把診斷單獨切出來。
適用場景：任何一段你不太熟、或別人寫的程式碼。你要先確認它「看懂了沒有」，再決定讓不讓它動手。這一輪它一行都不准改。
【只讀不改・可直接複製】
下面是一段程式碼。這一輪你只做閱讀與說明，不要輸出任何修改後的程式碼，不要提出重寫版本。
請按四段回答：
1. 它做什麼：用不超過 5 句話說明這段程式的整體功能，以及它的輸入與輸出（含型別、可能的空值情況）。
2. 資料怎麼流：列出主要的執行步驟（編號），標出每一步會改變哪個變數；如果有多個函式，標出呼叫關係。
3. 可疑點：列出你認為可能有問題的地方，每條寫成「位置 → 症狀 → 你為什麼這麼懷疑」，並標注你的信心程度（高／中／低）。不要下結論說一定是 bug。
4. 我不確定的地方：如果你對某段邏輯的意圖（例如某個判斷條件為什麼這樣寫）無法從程式碼本身確認，直接列出問題問我，不要猜。
以下是程式碼：
```
【貼上你的程式碼】
```
為什麼這樣寫：第 1、2 段是逼它把理解外顯出來。這一步的價值不在答案，在你能立刻看出它哪裡理解錯了——如果它把「跳過空資料」講成「中斷處理」，你當場就知道不能把後續工作交給它。第 3 段的格式要求是為了把「可能是 bug」和「確定是 bug」分開，並附上信心程度；模型很愛用確定的語氣講推測，你把信心欄位寫進格式，它就必須自己標一次。第 4 段是最省事的一條：它看不懂設計意圖時，問你比猜你便宜一百倍。
落地細節：貼程式碼時連同檔案路徑與語言版本一起寫（例如「Python 3.11，Django 4.2」），模型對版本差異很敏感；如果這段程式有已知的業務規則（例如「金額一律以分為單位」），在第 4 段下面補一行寫明，否則它會按通用常識理解。
適用場景：你已經知道要改什麼了（可能是模板一給的清單，也可能是你自己發現的 bug）。重點是控制範圍，讓每一輪改動小到你真的能 review。
【單一目標重構・可直接複製】
請對下面的程式碼做且只做一項修改：【在這裡寫下唯一一個目標，例如：修正當 items 為空陣列時會拋出例外的問題】。
規則：
1. 先寫計畫，再寫程式碼。 計畫用編號列出你要動哪幾行、改成什麼、為什麼。計畫寫完停下來等我確認，不要直接給改好的檔案。
2. 不准順手改別的。命名、排版、註解、無關的寫法，一律保持原樣。如果你認為附近有一處也該改，寫在末尾的「建議但未執行」清單裡，不要動手。
3. 不准新增外部相依。只能用這段程式已經引入的函式庫。
4. 保持對外行為不變，除了你這次要修的那一點。特別注意：函式名稱與參數、回傳值的型別與結構、例外處理方式、預設值——這些都不要動。
5. 輸出格式：先給「改動摘要」（一行講完）、再給計畫、再給完整的可複製程式碼（不要只給片段，不要用「此處省略」），最後給「建議但未執行」。
以下是我的程式碼：
```
【貼上你的程式碼】
```
為什麼這樣寫：第 1 條的「先寫計畫再停下來」是整段的核心。模型預設會一次交到底，因為它假設你要的就是結果；讓它交計畫，等於把一個可控的小關卡插在破壞發生之前——計畫讀起來很便宜，讀一段錯的程式碼的替代方案是把它跑起來、出錯、再找原因。第 2 條處理範圍失控：把「順手」變成一個必須分開呈現的欄位，它就不會混在主改動裡。第 5 條要「完整程式碼」是因為片段最容易出事，你會漏看它偷偷改掉的另一處；「不要用此處省略」這句一定要留著，否則它很愛省。
第 4 條是重構這件事的定義本身：重構的目標是改變結構而不改變行為，所以「對外行為不變」不是可選項。把它列成具體清單（簽章、型別、例外、預設值），是因為「行為」太抽象，列出四個具體項目它才好對照。
要替換的變數：那個唯一的目標；如果目標本身比較大（例如「把這個 300 行的函式拆成三個」），就拆成幾輪做，一輪只拆一個，並且在每輪第 4 條補一句「外部呼叫這個函式的地方不要改」。語言的差異也可以寫進規則，例如「不要用 JavaScript 的箭頭函式」或「符合 Pylint 預設規則」。
落地細節：改完一輪，把新版本當成新的輸入，回到模板一重跑一次只讀檢查。這聽起來多花一輪，但它攔下的正是那種「改 A 弄壞 B」的靜默問題，而那種問題在你自己跑測試之前不會現形。
適用場景：程式已經出錯了，你手上有錯誤訊息，但看不出成因。這跟模板二不同：模板二是你指定要改什麼，模板三是讓它先定位再修，而且要用你給的證據定位。
【除錯定位與修復・可直接複製】
我的程式出了問題。請按下面的流程處理，每一步做完先停下來，等我回覆再進行下一步。
證據如下：
- 預期行為：【我本來以為會發生什麼】
- 實際行為：【實際發生了什麼】
- 錯誤訊息（原文貼上，不要改寫）：
```
【貼上完整錯誤訊息與堆疊】
```
- 重現步驟：【1. … 2. … 3. …】
- 環境：語言與版本【如 Python 3.11】、作業系統【如 Windows 11】、相關套件版本【如 pandas 2.2.0】
- 相關程式碼：
```
【貼上出錯的函式與它的呼叫處】
```
流程：
1. 複述與定位：用自己的話複述這個錯誤是什麼類型（語法／型別／狀態／環境／邏輯），並指出你認為最可能的 3 個位置，按可能性排序。這一步不要給修好的程式碼。
2. 提出驗證方法：針對可能性最高的那一個，給我一句可以立刻執行的指令或一行 print，讓我跑完告訴你結果。不要叫我做大範圍改動。
3. 收到我的結果後，再判斷假設是否成立；不成立就回到第 2 步換下一個假設。
4. 確認成因後，再給修復方案：先寫一行成因，再給最小改動的完整程式碼，最後說明「為什麼這個改動不會影響其他行為」。
如果我提供的資訊不足，直接問我缺哪一項，不要猜測後繼續。
為什麼這樣寫：這個模板把除錯常見的錯誤做法倒過來了。一般人的做法是把錯誤訊息貼上去，問「這怎麼修」，然後拿到一段猜出來的修改——因為模型在手上一無所有的時候，最合理的策略就是給你一個涵蓋多種可能性的補丁，於是你會得到一堆「順便也加了防禦性檢查」的改動。這個模板逼它先講假設，再要一個能驗證假設的最小動作，你跑完回報，它才推進；這樣每一輪都建立在事實之上，而不是在猜測之上疊猜測。第 2 步那句「不要叫我做大範圍改動」是關鍵限制：除錯最貴的成本是你按建議改了五個地方，最後發現真正的原因在第六個地方，而前五個改動現在都成了新的變數。第 4 步要求說明「為什麼不會影響其他行為」，等於把模板二的紀律搬過來——修得對還不夠，得說得出為什麼沒有副作用。
要替換的變數：「證據如下」那六項要照實填，缺一項它的準確率就明顯下降，尤其是版本號——很多 bug 是特定版本的行為差異；重現步驟愈小愈好，如果只能描述而無法穩定重現，就寫「出現頻率約十分之三」而不是編一個步驟。
落地細節：把每次的假設與驗證結果留在對話裡不要刪，這份紀錄就是你下次遇到類似錯誤的線索。
| 你要做的事 | 用哪個模板 | 產出 | 什麼時候用 |
|---|---|---|---|
| 不確定 AI 有沒有看懂這段程式碼 | 模板一：只讀不改 | 功能說明＋可疑點清單（含信心程度） | 每次動刀之前，先跑這一輪 |
| 已經確定要改什麼 | 模板二：單一目標重構 | 計畫＋完整程式碼＋「建議但未執行」清單 | 一輪只做一件事，改完重跑模板一 |
| 程式已經出錯，原因不明 | 模板三：除錯定位與修復 | 假設清單＋可執行驗證步驟＋最小修復 | 有錯誤訊息時，先定位再修 |
一句話記住：先讓它讀懂，再讓它小口改，最後讓它先立假設再動手。 三件事混在一起做，你拿到的就是最開頭那個故事——一份看起來很專業、跑起來會炸的 diff。
回到開頭那位朋友。後來我們把那支腳本重跑了一次模板一，它列出的「可疑點」裡有一條正是空陣列的處理，信心程度標的是「中」——也就是說，它其實看到了，只是沒人問它。重構與除錯交給 AI，真正省下的不是打字時間，是你自己去找線索的時間；而前提是那條線索必須先被講出來、列成清單、被你確認過。流程寫對了，它交回來的東西你才敢用。
工具推薦隨身機器人（新用戶免費試用 7 天）
除錯往往發生在你最不方便開電腦的時候——看到錯誤訊息、想先問一句。SY 視野的「隨身機器人」把手機裡的 AI 助理帶著走，隨時問、隨時用，新用戶免費試用 7 天。入口見 SY 視野（sylogs.com）首頁。
下一篇預告： 程式碼靠規則關住，翻譯卻沒有編譯器幫你檢查。下一篇換個場景——多語翻譯保真：怎麼用提示詞把「意思對但味道跑掉」的譯文逼回來，以及為什麼要求它一次給兩版，比要求它「翻得準一點」有用得多。
業州愚公 ｜ SY 視野（sylogs.com）原創內容，轉載請註明出處。
編輯評論 / Editor's Note
隨著人工智慧技術的發展，編程工作中也逐漸引入了AI的協助，但這也帶來了一些挑戰和隱憂，尤其是在程式碼優化和除錯的過程中。透過設定明確的提示詞和流程，可以更好地控制AI的修改內容和過程，從而確保程式碼的安全性和可靠性。這種方法不僅能提高編程效率，也能減少AI修改所帶來的風險。