如何用AI寫程式：降低風險的工作流程

AI可以提案，但決定權在你的程式碼庫

用AI寫程式最好的方式，是在用猜的很危險的那些關鍵時刻，刻意讓它慢下來。AI可以解釋不熟悉的程式碼、把錯誤轉成假設、起草測試、審查差異，並提出重構建議。但它也可能捏造API、漏看隱藏的相依性、對貼上的片段過度擬合，或產出一份看起來乾淨、實際上卻改變了你原本想保留的行為的修補。

用這個原則：AI可以提案，但決定權在你的程式碼庫。真理的來源是程式碼庫本身、可重現的失敗案例、測試套件、執行期記錄、產品需求，以及人工審查。一個好的AI結對夥伴，應該幫你根據這些依據去推理，而不是取代它們。

原則	為什麼重要	該問模型什麼
先重現	避免亂槍打鳥式的修補	「在建議程式碼之前，先重述失敗的行為和證據。」
保持範圍小	降低回歸風險	「提出最小且安全的變更，並列出動到的檔案。」
保留行為	保護使用者和契約	「指出這項變更不能破壞的不變條件。」
要求測試	讓答案能被驗證	「寫出修復前會失敗、修復後會通過的測試。」
合併前先審查	抓出看似篤定卻出錯的地方	「審查這份差異的正確性、安全性，和漏掉的邊界情況。」

這一點在不同模型之間確實有差異，各模型的成本和涵蓋範圍也真的不一樣。根據Whizi的模型成本指數（OpenRouter標價，擷取於2026-08-20），一則1,000輸入加500輸出token的標準答案，在Claude Sonnet 4.6上大約$0.0105，在GPT-5.6 Terra上大約$0.008，在DeepSeek V4 Flash上大約$0.00028，最高和最低之間的差距大約37倍，而這三者都能讀取1M token的上下文。實務上的路由原則是：把「解釋這段程式碼」和記錄檔分診這類問題交給DeepSeek V4 Flash或Gemini 3.7 Flash這類便宜的模型，把Claude Sonnet 4.6或GPT-5.6 Terra留給審查階段和你輸不起的程式碼的重構計畫。OpenAI和Anthropic的能力文件會告訴你一個模型能嘗試什麼，但它們不能取代上面這套工作流程。評判模型的方式，就像評判一位隊友一樣：它會不會要求缺少的背景資訊、會不會降低不確定性、會不會尊重限制條件，並留下你能查核的軌跡？

分五個階段除錯：先重現再動手修補

一套可靠的AI除錯工作流程有五個階段：重現、隔離、假設、修補、驗證。不要一開始就說「幫我修這個」。要從證據開始。給模型失敗的指令、確切的錯誤訊息、預期行為、觀察到的行為、相關程式碼、環境細節，以及任何可能導致這個問題的近期變更。

第1階段：捕捉重現步驟。對後端程式碼，附上請求、回應、狀態碼、記錄檔和失敗的測試。對前端程式碼，附上路由、使用者操作、瀏覽器主控台錯誤、網路回應、元件狀態，以及相關的話再附上螢幕截圖描述。對建置問題，附上指令、套件管理工具、Node版本，以及第一個失敗點周邊的完整錯誤訊息。

第2階段：在寫程式碼之前先要求假設。一個謹慎的模型應該為可能的原因排序，並說明各自有什麼證據支撐。如果它無法區分不同原因，就要求最小的診斷步驟。可能是一則記錄、一項聚焦的測試、一次型別檢查，或多讀一個檔案。

第3階段：要求最小的修補。告訴模型除非能說明理由，否則不要重新命名變數、改寫周邊程式碼、引進新的相依套件，或改變公開行為。要求它回傳根本原因、修補概要、動到的檔案、測試，和風險。

第4階段：在本機執行測試。AI的輸出不是驗證步驟。驗證步驟是那個能證明行為正確的指令或使用者路徑。如果沒有自動化測試存在，先請模型建立一個回歸測試，再實作修復。

除錯提示詞：

扮演一位謹慎的除錯夥伴。先不要寫程式碼。先重述重現步驟、預期行為、觀察到的行為，以及三個最可能的根本原因。依證據為每個原因排序。接著建議最小的診斷步驟。錯誤：[描述]。指令或使用者操作：[貼上]。錯誤訊息／記錄檔：[貼上]。相關程式碼：[貼上]。限制條件：[技術堆疊、不能動的檔案、必須保留的行為]。

修復提示詞：

根據已確認的根本原因，提出最小且安全的修復方案。回傳：根本原因、要變更的檔案／函式、修補概要、修復前會失敗修復後會通過的測試、邊界情況，以及回滾風險。不要重構無關的程式碼。背景：[貼上]。

AI審查差異比它自己寫程式碼更擅長

AI擔任審查者往往比擔任第一作者更出色。當你請它審查一份差異時，它能找出漏掉的邊界情況、安全問題、過時的假設、測試缺口，以及行為變更。關鍵在於讓審查要求變得具體。如果你問「這樣看起來好嗎？」你會得到客氣的認可。如果你問正確性上的風險，你比較可能得到有用的異議。

給模型差異、預期行為、相關測試，以及任何限制條件。要求它忽略不影響可維護性的次要風格問題。你要的是讓審查優先處理真正的錯誤，而不是表演式的挑毛病。

審查領域	AI該回答的問題
正確性	這份差異真的滿足需求嗎？
回歸風險	有哪些既有行為可能意外被改變？
安全性	輸入、驗證、機密資訊、權限或注入風險有被處理嗎？
錯誤處理	遇到null值、逾時、重試、錯誤回應或部分狀態時會發生什麼？
測試	有哪些行為上的說法沒有被涵蓋？
可維護性	這是否遵循了當地既有的模式，並讓這項變更容易理解？

程式碼審查提示詞：

像一位嚴格但務實的維護者一樣審查這份差異。專注在正確性、回歸風險、安全性、邊界情況，和缺少的測試上。忽略不會造成真正維護風險的次要風格問題。回傳一張表格，包含問題、優先順序、來自差異的證據、建議的修復方式，以及需要的測試。預期行為：[貼上]。差異：[貼上]。既有測試：[貼上]。

對高風險的變更，在Whizi裡使用比較模型修補的工作流程。把同一則審查提示詞跑過兩到三個模型。如果其中一個模型找到一個可能的問題，不要盲目接受，先確認這個問題在程式碼庫裡是不是真的存在。重點是在合併之前擴大審查的範圍，讓每一項異議都能追溯回程式碼本身，而不只是被當成一票。

在AI動手重構之前先指出不變條件

用AI重構有風險，因為很多重構的好壞，取決於哪些地方沒有改變。模型可能讓程式碼變得更漂亮，卻悄悄改變了行為、錯誤處理、時序，或公開契約。更安全的重構工作流程，是在動手實作之前先定義不變條件。

第1步：描述重構目標。例如：減少重複、拆分一個過大的元件、隔離資料存取、簡化分支邏輯、遷移一個API包裝器，或提升可測試性。接著說明哪些東西必須維持不變：公開函式簽章、路由行為、事件名稱、回應格式、分析追蹤、權限，以及無障礙行為和效能預期。

第2步：要求一份分階段計畫。一份實用的AI重構計畫應該是可逆的。每個階段都該只動到一小塊範圍、包含測試，並產出一個能正常運作的中間狀態。除非程式碼很小且測試涵蓋完整，否則避免一次性的整個重寫。

第3步：寫特徵化測試。在改動程式碼之前，請AI辨識目前的行為，並起草測試把重要案例鎖定下來。這種測試對意圖不清楚的舊有程式碼特別有用。它們應該包含正常輸入、邊界輸入、失敗路徑，以及一個和重構理由相關的回歸案例。

第4步：一次實作一個階段。每個階段結束後，執行測試並要求一次聚焦的審查。如果模型提出一個廣泛的抽象化，要求它證明這個抽象化確實消除了真正的重複或風險。否則，就讓程式碼保持平實、局部。

重構規劃提示詞：

建立一份分階段的重構計畫。目標：[目標]。目前的程式碼：[貼上]。限制條件：保留公開行為、盡量減少變動、遵循既有模式、避免新增相依套件、讓每個階段都可測試。回傳：不變條件、相依性地圖、階段、動到的檔案、每個階段的測試、回滾風險，和審查查核清單。

單元測試提示詞：

在實作變更之前先寫測試。使用這裡展示的既有測試風格：[貼上]。必須保留的行為：[貼上]。要測試的程式碼：[貼上]。回傳測試名稱、設定、輸入、預期結果，以及每個測試為什麼重要。包含正常路徑、邊界情況、錯誤情況，和回歸情況。

消除模糊性的提示詞範本

強力的寫程式提示詞，長度恰好足以消除模糊性，不多也不少。模型需要角色、任務、背景、限制條件、輸出格式，和驗證標準。把有效的提示詞存下來，讓AI變成一套可重複的工程工作流程，而不是一次性的聊天。下面這張表，把每項寫程式任務配上該先要求的東西，以及能證明答案正確的檢驗方式。

寫程式任務	該先要求什麼	什麼能證明答案正確
除錯	排序過的根本原因，附上各自的證據	一項在修復前失敗、修復後通過的回歸測試
程式碼審查	正確性、回歸風險、安全性、邊界情況，和測試缺口	每個問題都能追溯到差異裡的具體一行
重構	不變條件，以及實作變更前的分階段計畫	每個階段結束時特徵化測試仍然通過
寫測試	正常路徑、邊界、錯誤，和回歸案例	每個測試都對應到一項你能指出的行為說法
解釋程式碼	目的、輸入、輸出、資料流、相依性，和失敗模式	程式碼裡可見的事實和推測被清楚分開

程式碼解說提示詞：

為一位剛加入這個專案的開發者解釋這段程式碼。涵蓋目的、輸入、輸出、資料流、相依性、失敗模式，以及能提升信心的測試。把程式碼裡可見的事實和推測分開。程式碼：[貼上]。

安全程式碼提示詞：

審查這段程式碼的安全風險。專注在驗證、權限、注入攻擊、機密資訊、輸入驗證、不安全的重新導向、檔案處理、相依套件風險，和敏感資料外洩上。只回傳附有證據、影響、建議修復方式，和測試或人工檢查方式的問題。程式碼／差異：[貼上]。

比較模型修補提示詞：

我正在為一項寫程式任務比較AI模型。只使用提供的背景資訊。回傳根本原因、最小且安全的修復方案、測試、風險、假設，和問題。用1到5分為信心程度打分，並列出什麼證據會改變你的答案。任務：[貼上]。背景：[貼上]。

接受AI產生的程式碼之前的品管查核清單：

• 模型正確重述了任務。
• 這份修補比問題本身還小，而不是更大。
• 公開行為和契約都已指名。
• 測試直接涵蓋了這個錯誤或重構目標。
• 邊界情況和失敗路徑都已列出。
• 安全敏感的輸入已經被審查過。
• 這份差異遵循既有的專案模式。
• 你已經執行過相關的測試、程式碼檢查、建置，或人工重現。
• 有真人審查過最終的差異。

誠實說一個限制：Whizi是一個聊天工作區，不是IDE外掛。對於邊打字邊自動完成這種功能，一個專屬的IDE助理會更好用。Whizi真正發揮價值的地方是在檢查點上：把同一則除錯或審查提示詞貼進Claude Sonnet 4.6、GPT-5.6 Terra和DeepSeek V4 Pro，再依證據、範圍、測試和風險為輸出打分。如果你想要一份選模型的指南，可以從寫程式用的ChatGPT替代方案開始，到價格頁比較方案，或建立帳號在你自己的程式碼上跑這套工作流程。