寫程式的 Prompt 技巧：怎麼問 AI 才能得到對的、會除錯、好維護的程式碼

同一個 AI、同一個需求，有人三分鐘拿到能跑、有測試、好讀的程式碼，你卻在貼錯誤訊息、來回十幾次還是兜不攏。差別幾乎不在模型，而在你怎麼描述這個程式問題。

這篇要解決的問題：教你一套寫程式專用的 Prompt 方法，讓 AI 的產出從「貼上去就報錯」變成「能跑、會自己除錯、未來好維護」。 適合誰讀：工程師、接案者、用 AI 學寫程式的初學者、需要寫一點自動化腳本的行銷與營運人員。 讀完你會得到：一套四層 Prompt 結構、可複製的程式 Prompt 範本、一張除錯 Workflow 流程圖，以及台灣團隊的真實導入前後對比。

為什麼你請 AI 寫的程式碼總是不能用？

把這件事拆開看，問題幾乎都出在同一個地方：你給 AI 的資訊，不足以讓任何一個工程師寫出正確答案。

想像你在公司丟一句話給新來的工程師：「幫我寫個上傳檔案的函式。」他一定會反問你一串：用什麼語言？哪個框架？檔案要存哪？大小限制多少？要不要驗證副檔名？失敗怎麼處理？——沒有這些答案，他寫出來的東西十之八九不是你要的。

AI 的差別只在於：它不會反問，會直接猜。它會挑一個最常見的語言、最熱門的框架、最標準的寫法，然後給你一段「在某個世界裡正確」的程式碼。對不上你的實際環境，當然跑不起來。

所以寫程式的 Prompt 跟一般 Prompt 最大的不同是：你必須把那些工程師會反問的問題，全部主動先答完。資訊密度，決定程式碼品質。

核心概念：寫程式 Prompt 的四層結構

一般 Prompt 講「角色＋任務＋格式＋護欄」，寫程式時要把它具體化成四層。你可以把它記成上下文 → 目標 → 限制 → 驗證。

下面這張表，是把「會反問的工程師」翻譯成 Prompt 該寫的東西：

少了上下文，程式碼對不上你的環境；少了目標，AI 猜錯你要的行為；少了限制，你拿到能跑但難維護的程式碼；少了驗證，你只能盲信，出事才發現。四層缺一不可。

關鍵心法：寫程式的 Prompt 不是要 AI「給答案」，而是要 AI「給一個你能快速驗證的答案」。 能驗證，你才敢用；不能驗證，再漂亮都是負債。

實際教學：五個步驟問出對的程式碼

Step 1：先給技術上下文，別讓 AI 亂猜

開頭就把技術棧講清楚。一句話的差別：

• 差：「幫我寫一個讀 CSV 的程式。」
• 好：「我用 Python 3.11，環境是後端排程腳本，沒有 pandas（不想加依賴）。請用標準函式庫 csv 模組，讀取一個 UTF-8、含標頭的 CSV。」

如果是改既有程式碼，把相關片段一起貼上，並說明它現在的行為與你想要的行為。AI 看得到現況，才不會給你一段風格、命名都對不上的孤兒程式碼。

Step 2：把目標、輸入、輸出與邊界情況講死

不要只說「處理使用者資料」。要說：輸入是什麼結構、預期輸出是什麼、空值與重複值與超大檔案怎麼辦。邊界情況是初學者最常漏、也最常出 bug 的地方，主動列出來，AI 就會幫你 cover。

例如：「輸入是一個 list of dict，每筆有 email 欄位。輸出去重後的 list，email 比對要忽略大小寫與前後空白。遇到沒有 email 欄位的資料要跳過而非報錯。」

Step 3：設限制，讓程式碼好維護

這一步決定你拿到的是「能跑就好」還是「半年後還看得懂」。明確寫上你的規範：

請遵守：函式單一職責、變數與函式用語意清楚的英文命名、加上型別註記、不要硬寫魔術數字（抽成常數）、關鍵邏輯加一行註解說明「為什麼」而非「做什麼」。優先可讀性，不要過度精簡成看不懂的一行。

沒有這段，AI 預設會給最短解；有了這段，它才會給可維護解。

Step 4：要求可驗證的產出

請 AI 一併交付：測試案例、執行說明、它做了哪些假設。

請附上：(1) 三到五個測試案例，含正常、邊界與錯誤輸入；(2) 怎麼跑這段程式；(3) 你做的假設清單；(4) 你不確定或可能出錯的地方，明確標出來。

最後一項特別重要。要求 AI 主動標出不確定處，等於請它幫你劃出 review 的重點，把幻覺風險攤在陽光下。

Step 5：出錯時，給足回饋再請它修

這是來回次數的分水嶺。不要只丟「還是錯」。要給：

1. 完整錯誤訊息（整段 traceback，不是只截一行）。
2. 重現步驟：你怎麼跑的、輸入是什麼。
3. 相關程式碼：報錯那一段與它呼叫到的部分。
4. 明確指令：「先說明這個錯誤的根本原因與你的假設，再給修正版，並說明改了哪裡、為什麼。」

要求「先解釋再修」能擋掉 AI 亂槍打鳥式的瞎改——逼它先想清楚，命中率高很多。

範例：Prompt 與除錯 Workflow

可複製的「寫新函式」Prompt 範本

你是一位資深的 [語言] 工程師，重視程式碼的可讀性與可維護性。

【技術上下文】
- 語言與版本：Python 3.11
- 環境：後端排程腳本，無 Web 框架
- 限制：不使用第三方套件，僅用標準函式庫

【目標】
寫一個函式 dedupe_users(users)：
- 輸入：list of dict，每筆可能含 "email" 欄位
- 輸出：去重後的 list，email 比對忽略大小寫與前後空白
- 邊界：沒有 email 欄位的資料跳過；輸入為空回傳空 list

【限制與規範】
- 單一職責、語意清楚的英文命名、加型別註記
- 不寫魔術數字、關鍵邏輯註解說明「為什麼」
- 優先可讀性

【請一併交付】
1. 函式程式碼
2. 3-5 個測試案例（正常／邊界／錯誤輸入）
3. 你做的假設清單
4. 你不確定或可能出錯的地方

把方括號換成你的實際情況即可。這個範本之所以好用，是因為它一次補滿了四層結構，AI 幾乎沒有「靠猜」的空間。

除錯用的 Prompt 範本

以下程式碼執行時出現錯誤，請先說明根本原因再修正。

【我做了什麼】
（重現步驟與輸入）

【完整錯誤訊息】
（整段貼上，不要省略）

【相關程式碼】
（報錯片段與它呼叫到的部分）

請回答：
1. 這個錯誤的根本原因是什麼？你的判斷依據？
2. 修正版程式碼
3. 改了哪裡、為什麼這樣改
4. 如何驗證已經修好

除錯 Workflow 流程圖（文字版）

當 AI 一次沒修好，照這個流程走，避免無限鬼打牆：

拿到報錯
   ↓
完整貼上：錯誤訊息 + 重現步驟 + 相關程式碼
   ↓
要求 AI：先說明根本原因 + 假設，再給修正
   ↓
跑修正版 ──→ 通過？
   │              │
   │ 沒過          是 → 補測試 → 合併
   ↓
回貼新的錯誤訊息（不是說「還是錯」）
   ↓
連續 2 次沒進展？
   ↓
換策略：請 AI 列出 2-3 種可能原因，逐一加 log 排除
   ↓
仍卡住 → 縮小到最小可重現範例，重新問

這張流程圖的核心觀念：每一輪都要餵新資訊。如果你每次給的資訊都一樣，AI 每次也只會給差不多的答案，來回十次也是白搭。

常見錯誤

• 只丟一句話需求：「幫我寫個爬蟲」——沒有目標網站、沒有要抓什麼、沒有反爬限制，拿到的一定是教科書範例，套不進你的情境。
• 把錯誤訊息翻成中文或只截一行：AI 對不上原始的例外類型與行號，等於蒙眼除錯。錯誤訊息照原文整段貼。
• 不附既有程式碼就要求改：AI 看不到現況，給你一段風格、命名全不一致的程式碼，整合反而更費工。
• 盲信能跑就合併：能跑不等於正確。沒測過邊界情況、沒做 review，AI 的隱性 bug 會在上線後爆給你看。
• 一錯就重開新對話：丟掉前面累積的上下文，等於從零開始猜。同一個問題請在同一串對話裡迭代。
• 要求過度精簡：硬要 AI「寫短一點」常換來看不懂的一行式炫技程式碼，半年後維護的人（很可能是你自己）會崩潰。可讀性優先。

最佳實務

• 小步快跑：一次只請 AI 解一個明確的小問題，跑通再往下，不要一口氣要它生一整個系統。錯了也好定位。
• 永遠要測試：請 AI 附測試，自己再加一兩個它沒想到的刁鑽案例。測試是你對 AI 程式碼唯一可靠的信任機制。
• 要求它標不確定處：把「你哪裡不確定」設成固定問句，等於免費取得一份 review 重點清單。
• 建立你自己的 Prompt 範本庫：把好用的程式 Prompt 存起來重複用，團隊共用更省事。需要現成起點可參考 AgentAI 智庫的 Prompt 產生器 與 AI Skills 食譜庫。
• 讓 AI 接上你的工具再進階：當你要 AI 讀你的程式碼庫、跑指令、查文件，可以了解 MCP 與 AI Agent 怎麼把 AI 從「聊天框」變成「會動手的助手」。
• Code review 不能省：AI 寫的程式碼一律當「實習生交的初稿」看待，過了你的眼睛才算數。

實際案例：台灣電商團隊的後台腳本維護

台中一家中型電商，後台有不少 Python 排程腳本（對帳、撈報表、同步庫存），長期由一位工程師維護。常見痛點是：請 AI 改腳本時只貼片段、只丟一句「修一下」，AI 給的程式碼風格亂、常漏掉邊界情況，上線後才發現對帳數字對不上，平均一支 bug 要來回問五六次才搞定。

導入做法：團隊把上面的「四層結構」做成內部的程式 Prompt 範本，規定三件事——(1) 改腳本一律連既有程式碼一起貼；(2) 一律要求 AI 附測試與假設清單、標出不確定處；(3) 除錯一律完整貼 traceback、要求先解釋根本原因再修。同時把常用範本存進共用文件，新進同事直接套。

導入前後對比：

成果數據：腳本相關的開發與除錯時間整體約減少四成，對帳類腳本上線後的錯誤幾乎歸零（因為一律附測試與邊界案例）。團隊的結論很實在——AI 沒有變強，是他們問問題的方式變強了。把工程師會反問的問題先答完、把驗證機制內建進流程，AI 才真的省到時間。

此案例為彙整台灣中小企業常見導入情境的示意，數據為說明用途，實際成效依團隊既有流程與技術棧而異。

結論

寫程式的 Prompt，跟交辦工作給一位很強但剛報到的工程師沒兩樣：你交代得越完整，他做得越好。把它收斂成一句話——上下文 → 目標 → 限制 → 驗證，四層補滿，AI 就沒有靠猜的空間。

最後三個帶得走的原則：第一，資訊密度決定程式碼品質，把工程師會反問的全部先答完；第二，要的是能快速驗證的答案，一律請 AI 附測試與假設、標出不確定處；第三，AI 是加速器不是免責牌，能跑不等於正確，review 過了才算數。從今天起，把這套結構套進你下一個程式 Prompt，你會立刻感覺到來回次數明顯變少、拿到的程式碼也更耐用。

❓ 常見問題 FAQ

🔗 延伸閱讀

• ChatGPT Prompt 教學：高效指令公式
• AI Agent 是什麼？從入門到實戰
• 什麼是 MCP？讓 AI 接上你的工具
• Prompt 產生器：上百種任務填空即生
• AI Skills 食譜庫