Closing the Loop：讓 AI 能自我驗證，是 AI 時代開發的核心能力

本文整理自 The Pragmatic Engineer Podcast 2026 年 1 月 28 日播出的單集，訪談 PSPDFKit 創辦人 Peter Steinberger。

{{< youtube 8lF7HmQ_RgY >}}

{{< spotify "episode/5Ie6QtG7V0KLK4BZBtiT7j" >}}

---

AI 為什麼擅長寫程式，卻寫不好創意文案？

這個問題，我一直覺得很有趣。用過 Claude 或 GPT 寫程式的人都知道，這些模型在 coding 上表現驚人，但要它寫一篇有靈魂的文章，往往就是一股「AI 味」。

PSPDFKit 創辦人 Peter Steinberger 給了一個很簡潔的解釋：「程式可以編譯、可以 lint、可以執行、可以驗證輸出。但創意寫作？沒有簡單的方法可以驗證對不對。」

這個觀察看起來很直覺，但背後藏著一個更深的洞見——AI 輔助開發的核心，不是模型有多強，而是你有沒有設計一個系統，讓 AI 能夠自我驗證、自我修正。

Peter 把這個原則叫做「Closing the Loop」。

什麼是 Closing the Loop？

所謂「關閉迴圈」，就是讓 AI agent 有辦法知道自己做得對不對。如果你寫 code，AI 可以跑編譯、跑 linter、跑測試、看輸出。這些都是客觀的回饋訊號。AI 寫錯了，編譯會噴錯；邏輯有問題，測試會失敗。它不需要你告訴它哪裡錯，它自己就能發現，然後修正。

但如果你要 AI 寫一段行銷文案，怎麼驗證？「寫得好不好」這件事沒有客觀標準，沒有 compiler 可以跑。AI 沒有回饋訊號，就只能猜。猜對了是運氣，猜錯了也不知道錯在哪。

Peter 在訪談中舉了一個例子。他在開發 Clawdbot（他的個人 AI 助理專案）時，遇到一個 bug：Mac App 找不到遠端 gateway，但同一段邏輯用 TypeScript 跑就沒問題。Mac App 的除錯很麻煩——要編譯、啟動、看畫面、手動確認有沒有問題。這個 loop 太慢了。

他的解法？「我直接告訴 AI，你幫我建一個 CLI，呼叫跟 Mac App 一樣的 code path，但可以讓你自己跑、自己 debug。」AI 就真的建了這個 CLI，然後用它來自我除錯。一個小時後，AI 回報：「找到問題了，這裡有 race condition，那裡有 misconfiguration。」

Peter 連 code 都沒看。因為他信任這個迴圈——AI 能自己驗證，代表輸出是可信的。

為什麼這會讓你變成更好的開發者？

這裡有一個反直覺的結論：用 AI 寫 code，會讓你變成更好的 coder。

Peter 說：「我現在不自己寫 code 了，但我寫出來的 code 品質比以前更好。而我以前寫的 code 就很好了。」

為什麼？因為當你的開發方式是「讓 AI 自己驗證自己」，你就必須認真思考架構。什麼樣的架構容易測試？什麼樣的設計能讓 AI 快速 loop？這些問題，在傳統開發裡你可能會偷懶跳過——反正手動測一測就好。但現在，如果你不設計好這個迴圈，AI 就會原地打轉，產出一堆沒用的東西。

換句話說，Closing the Loop 強迫你做好架構設計。而好的架構設計，本來就是工程師的核心能力。

Peter 提到，他現在每設計一個新 feature，腦袋裡第一個問題就是：「這個要怎麼讓 AI 驗證？」如果答案是「不太好驗證」，他就會退一步想，能不能換一種設計方式，讓驗證變得可行。這個思考習慣，反過來讓他的系統架構變得更乾淨、更模組化。

實戰技巧：怎麼設計可驗證的系統？

Peter 在訪談中提到幾個實作心法：

第一，盡量讓你的邏輯可以用 CLI 執行。GUI 的 loop 很慢——你要啟動 app、點點點、看結果。但 CLI 可以讓 AI 自己呼叫、自己看輸出。Peter 甚至連 Clawdbot 的核心邏輯都設計成可以用 CLI 跑，因為「browser loop is insanely slow（瀏覽器的迴圈慢到瘋掉）」。

第二，讓 AI 自己寫測試。Peter 說他現在有很好的文件，而且他「沒有自己寫過一行」。每次設計新 feature，他會跟 AI 討論：「這個要怎麼測？」然後讓 AI 去寫測試、跑測試、根據結果修正。因為 AI 寫測試的成本低到可以忽略，他終於可以做到以前嫌麻煩的事——全覆蓋的測試。

第三，引用其他專案的解法。Peter 有一個習慣，當他要解決某個架構問題，會讓 AI 去看他其他專案裡類似問題的解法。「這些專案裡已經有我之前的思考。AI 很擅長讀 code、理解我的想法，然後套用到新的情境。」這種「跨專案的知識轉移」，靠人腦做很累，但 AI 做起來輕鬆。

我的觀察：驗證能力是新的護城河

聽完 Peter 的分享，我有一個很強烈的感覺：未來開發者的核心競爭力，不再是「寫 code 的速度」，而是「設計可驗證系統的能力」。

這話聽起來很抽象，讓我換個說法。以前，我們說一個工程師厲害，可能是因為他寫 code 快、bug 少、架構乾淨。這些能力當然還是重要，但 AI 會慢慢把「寫 code」這件事變成 commodity。當寫 code 的成本趨近於零，能讓 AI「寫對 code」的能力就變得更稀缺。

而讓 AI 寫對 code 的關鍵，就是給它一個可以自我驗證的環境。這需要的是系統思考——你要理解整個系統的邊界在哪、哪些部分可以自動化驗證、哪些地方需要人工判斷。這種能力，不是花時間 prompt engineering 就能學會的，而是多年架構經驗的累積。

Peter 說他現在「不寫 code，但寫出來的 code 品質更好」，這不是在炫技。這是因為他過去十幾年在 PSPDFKit 累積的架構經驗，讓他知道怎麼設計一個對 AI 友善的系統。

對新手來說，這可能是一個警訊：如果你只學會用 AI 寫 code，卻沒學會怎麼設計系統，你很可能會卡在一個尷尬的位置——AI 可以幫你寫出「能跑」的 code，但你不知道怎麼讓它寫出「對」的 code。

而對資深開發者來說，這反而是一個機會。你過去累積的架構能力、系統思考、測試策略，這些「軟實力」現在變成了真正的護城河。AI 會寫 code，但它不會設計 loop。這件事，還是得靠人。

結語：先問「怎麼驗證」，再動手做

如果只能從這篇文章帶走一個觀念，我會說是這個：下次你要讓 AI 幫你做一件事之前，先問自己——「這個任務，AI 要怎麼知道自己做對了？」

如果你答不出來，那你可能還沒準備好把這件事交給 AI。或者，你需要先花時間設計一個驗證機制，再開始動工。

Closing the Loop，就是這麼簡單的一個原則。但真正做到，需要的是多年的架構功力。