別再用 Prompt 祈禱 AI 寫出好程式碼：將規則寫入 CI，而非許願池

要讓 AI 寫出符合規範的程式碼，不該靠加長 Prompt 乞求模型配合，而是把規則翻譯成 pytest、Ruff、mypy 等可機械驗收的檢查，直接放進 CI 當成合否判定。Prompt 說明「應該怎麼寫」，CI 才負責宣判「是不是符合」，整個流程才會從對話式祈願轉為可治理的工程驗收。

Prompt 變成許願池，真的可靠嗎？

在許多團隊中，與 AI 協作編程的流程，逐漸演變成一場永無止境的「提示詞工程」。我們試圖將所有關於程式碼風格、命名慣例、錯誤處理、型別註記的要求，全部塞進一個龐大的 System Prompt 中，彷彿這是一份具有法律效力的合約。我們要求 AI「總是使用 f-string」、「務必為所有函式加上 docstring」、「遵守 PEP 8 規範」等等。然而，這種方式本質上是一種「口頭協定」，極度依賴模型的理解、記憶與當下的生成狀態，缺乏穩定性與可預測性。

模型的行為會因為微小的提示詞變動而產生巨大差異，這種現象在學術研究中被稱為模型的敏感性（sensitivity）。更重要的是，當生成結果不符預期時，我們的解決方案往往是繼續微調 Prompt，陷入「請求-失望-修改提示」的循環。這不僅效率低落，也讓程式碼品質的底線變得模糊不清。我們把應該由工程系統保障的品質，寄託在與 AI 的「溝通默契」上，這本身就是一種風險。

如何將程式碼規則從「請求」轉為「驗證」？

與其將規則寫入許願池般的 Prompt，我們應該將其轉譯為具體、可執行的測試與檢查。這意味著將自然語言的期望，變成 CI (Continuous Integration) 流程中的一個個關卡。AI 的任務不再是「記住並遵守所有規則」，而是「生成能夠通過所有檢查的程式碼」。這種思維轉變，讓我們能借助成熟的軟體工程工具來治理 AI 的產出。

日本開發者 Yutaro Nakayama 在一篇技術文章中，便清晰地闡述了這個觀點。在 Python 生態系中，這個流程可以這樣實現：

• 功能正確性： 使用 pytest 框架。AI 生成的程式碼，必須通過預先寫好的單元測試與整合測試。這是驗證程式碼是否「能用」的基礎。
• 程式碼品質與風格： 交給 Ruff。Ruff 是一個用 Rust 寫成的高效能 linter，號稱比既有的工具（如 Flake8）快上 10-100 倍。我們可以設定規則，例如強制使用 f-string (UP032) 或禁止不必要的 lambda 函式 (PLC3002)，讓 CI 自動檢查並拒絕不合規的提交。
• 型別安全性： 透過 mypy 進行靜態型別檢查。與其在 Prompt 裡要求 AI「請加上 type hints」，不如直接讓 mypy 檢查型別覆蓋率與一致性，未達標的程式碼將無法通過 CI。

在這個模型下，Prompt 的職責被大幅簡化。它只需要專注於描述「業務邏輯」與「核心意圖」，而所有關於「如何寫」的細節，都交由後續的驗證流程來把關。AI 的角色從一個需要被諄諄教誨的學徒，變成了一個需要對其產出負責的貢獻者。

重點：AI 的工作不是「遵循指令」，而是「通過測試」。CI 流程成為程式碼品質的唯一真理來源，而非開發者與 AI 之間的自然語言對話。

為什麼這不僅是 Prompt Engineering 問題，更是 AI 系統治理的關鍵？

將規則從 Prompt 移至 CI，不僅是技術實踐的轉變，更觸及了 AI 系統治理的核心議題。這與我之前提過的「指令出處」（instruction provenance）是姊妹問題。前者關注「規則從哪裡來？生命週期為何？能否被追蹤與退役？」，而本文討論的則是「規則要用什麼方式驗收？」。

當規則被寫死在 Prompt 中時，它們的出處變得難以追蹤，驗收方式也充滿不確定性。一個長達 3000 token 的 System Prompt，可能混合了來自不同時期、不同專案、甚至不同開發者個人偏好的規則。當我們想更新或移除某條規則時，過程將非常痛苦且容易出錯。

反之，將規則實作為 CI 的一部分，賦予了它們清晰的身份與生命週期：

1. 可追溯性 (Traceability): 每一條規則都對應到一個具體的設定檔（如 pyproject.toml）中的一行，或一個測試案例檔案。它的引入與修改，都有 Git 的提交紀錄可查。
2. 客觀性 (Objectivity): 規則的驗收是二元的，只有「通過」或「失敗」，不存在模糊空間。這為評估 AI 產出提供了一個穩定的基準。
3. 可維護性 (Maintainability): 當團隊決定放寬或收緊某項規範，只需修改對應的設定或測試，所有協作者（不論人或 AI）都會立刻在下一次提交時收到一致的回饋。

最終，這是一種將 AI 納入成熟軟體開發生命週期（SDLC）的必要過程。我們不能因為 AI 的能力看似神奇，就放棄過去數十年積累下來的工程紀律。真正的規模化協作，仰賴的不是完美的指令，而是可靠的驗證。與其花費心力打造一個無所不能、滴水不漏的 Prompt，不如專注於建構一個能捕捉錯誤、引導修正的強健回饋系統。

延伸閱讀

• pytest documentation
• Ruff: An extremely fast Python linter and code formatter
• mypy - Optional Static Typing for Python

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。