Pi Coding Agent：為真實工作流程構建靈活的 AI 工具

簡介

程式碼從來都不是免費的。這是 Pi 的創作者 Mario Zechner 在探討 2026 年 AI 輔助開發現狀時提出的核心論點。雖然代理程式可以快速生成大量程式碼，但這些程式碼帶來的後果終究會找上你。Pi 的存在是因為 Zechner 發現現有的編碼代理程式無法契合他的工作流程，與其強迫自己適應，他選擇構建一個能適應他的工具。

這場對話涵蓋了為何工作流程的穩定性比功能迭代速度更重要、如何在不耗盡精力的情況下與編碼代理程式協作，以及為何業界可能正在重蹈 30 年前規格驅動開發的覆轍。

為何 Pi 存在：工作流程的靈活性勝過穩定性

當 Claude Code 剛推出時，Zechner 對其感到滿意。然而隨著時間推移，該工具的高頻率發布節奏成為了問題。Claude Code 每天會收到一到三次更新，每次發布都會伴隨工具定義、系統提示詞（System Prompts）以及底層行為的變更。對於那些構建自訂提示詞模板、斜線指令（Slash Commands）和工作流程描述的人來說，這些隱性的變更會導致系統崩潰。

儘管模型版本保持不變，但模型本身的行為似乎每天都在變化。Zechner 將此部分歸因於「框架」（Harness）的變更——即塑造模型回應方式的基礎設施與系統提示詞。由於沒有確定性的方法來衡量，測試框架變更對輸出品質的影響變得非常困難。結果就是，像 Zechner 這樣的開發者無法依賴該工具的一致性，這違背了圍繞它構建自訂工作流程的初衷。

Pi 正是源於這種挫折感。它是一個極簡且可擴展的編碼代理程式，能夠自我修改以適應你的工作流程，而不是強迫你適應它的限制。其底層架構抽象化了 LLM 提供者，包含了終端機使用者介面函式庫，並提供了通用的代理程式迴圈抽象。但關鍵的區別在於控制權：Zechner 可以主導設計，並在無需等待供應商發布週期下進行更改。

Pi 的實際運作方式：平行處理與人工審核

Zechner 使用 Pi 的日常工作流程是有條不紊且刻意保持低技術含量的。他不會平行運行大量的代理程式，而是採用一種原始的方法：將多個任務排入佇列，每個任務分析追蹤器中的不同問題，然後逐一審核與迭代。

對於錯誤修復和功能實現，流程始於問題描述。Zechner 將問題輸入給一個帶有自訂提示詞模板的代理程式，要求它：提取所有相關資訊，忽略問題中的分析，並根據我們想要達成的目標進行自己的分析。這個分析步驟每個問題大約需要五分鐘。他會為下一個問題開啟第二個工作階段，再為另一個開啟第三個，從而建立一個平行的預處理管線。

當代理程式完成問題分析後，Zechner 會審核建議、親自檢查程式碼，並在必要時手動重現問題。他將代理程式視為「橡皮鴨」（Rubber Duck）——一個思考夥伴——直到他對實作方法達成共識。當他指示代理程式進行實作時，上下文已經包含了足夠多的防護措施，使代理程式能精確知道要修改哪些介面、觸及哪些模組，以及測試應如何運作。

實作過程需要額外 10 到 30 分鐘。當代理程式發出完成訊號時，Zechner 會調出差異檢視器，並針對個別行進行回饋註解。他點擊完成，回饋會自動反饋給代理程式，並持續迭代直到程式碼品質達標。對於核心機制，他會像審核人類同事一樣審核每一項變更。對於其他部分，他則會在未經深入檢查的情況下批准。

這種工作流程之所以有效，是因為 Zechner 在程式碼庫方面擁有超過 10 年的經驗。他知道什麼有效，什麼無效。對於新手開發者或缺乏經驗的人來說，這種方法將會截然不同，且風險更高。

規格驅動開發的現實

業界正在重蹈 30 年前的覆轍。瀑布式開發在幾十年前已被證明是無效的，然而隨著 AI 代理程式的出現，我們又回到了「超級瀑布式」開發：編寫詳細的規格，然後讓代理程式去實作。唯一的區別是，現在你甚至不需要親自編寫規格——你只需透過「氛圍提示」（Vibe Prompt）讓代理程式編寫一份非常詳細的規格，然後再由另一個代理程式進行實作。

問題在於本質。一份完整的規格本質上就是程式本身。如果你用自然語言編寫規格，你必然會留下漏洞。代理程式會用它從網路上 20 年的程式碼中學到的任何模式來填補這些漏洞——其中大部分都是垃圾。結果就是產生了一種看起來像「氛圍編碼」（Vibe-coded）的軟體，因為它確實就是如此。

有一種反駁觀點認為：程式碼現在很便宜，迭代速度很快。以前，瀑布式規格可能需要幾個月才能實作，現在可能只需要一天。你可以透過手動測試來完成。但 Zechner 尚未看到證據表明這對生產環境軟體真正有效。他懷疑開發者最終會在某個深夜醒來，意識到一切都崩潰了。

話雖如此，在某些限制條件下，代理驅動開發是有意義的。Bun 從 Zig 重寫為 Rust 之所以成功，是因為該專案擁有廣泛的測試套件。代理程式可以在一定程度上驗證自己的工作。在這些情況下，這類工具確實很有用。但對於大多數軟體而言，這種方法風險極高。

大規模管理開源專案：Clanker 問題

在代理程式出現之前，一個成功的開源專案每週可能只會收到一兩個合併請求（PR）。現在 Pi 每天會收到 50 到 60 個合併請求——全部來自代理程式（Zechner 稱它們為「Clankers」）。每個 PR 的描述都像一本《哈利波特》那麼長，並且包含 10 到 1,000 個檔案變更。

預設的做法是將所有代理程式生成的 PR 宣告為垃圾並自動關閉。但 Zechner 找到了一個解決方案：要求人們先用自己的口吻寫一個問題描述，長度不超過一個螢幕，清楚解釋他們想做什麼以及原因。如果問題描述得當，他會批准，然後對方才能發送 PR。這證明了他們是人類，理解問題所在，並且理解解決方案。

一旦獲得批准，有意義的 PR 就會出現。Clanker PR 就會停止出現。問題追蹤器仍然會湧入大量問題，但 Zechner 會手動進行分類。他每天閱讀 30 到 60 個已關閉的問題，識別哪些是合法的，哪些是垃圾。在他最近的一次分類中，收到了 50 個問題，只有 2 個被採納。這大約需要 30 分鐘，因為大多數問題很容易被識別為雜訊。

對於像 OpenClaw 這種規模的專案，這種手動方法行不通。Peter Steinberger 的 Token 消耗量達到每月 130 萬美元，部分原因在於該規模下自動化過濾問題和 PR 需要複雜的基礎設施。Zechner 寫了一些視覺化工具來幫助將相似的問題分組，但即使這樣也不夠。其數量級大得多。

本地推論與小型模型的未來

Zechner 對在消費級硬體上本地運行強大的 AI 模型持樂觀態度。對於他的機器人專案——一個以智慧型手機作為微控制器並運行編碼代理程式的玩具——他使用了 Gemma 4 和 Qwen 3.6，這些較小的混合專家模型（MoE）。它們對於一個具備馬達和攝影機控制的聊天機器人來說綽綽有餘，而且速度很快。

這種配置負擔得起。使用 Parakeet 進行語音轉文字大約需要 10 GB 的統一記憶體。使用 Qwen TTS 進行文字轉語音需要額外 10 GB。Qwen 3.6 需要 4 GB。總計：在 macOS 上或 Windows 上等效的 NVIDIA 配置中需要 14 GB 的統一記憶體。這對許多人來說是負擔得起的，雖然不是全世界，但也是相當大的一部分。

DeepMind 的 Denise Asaves 曾建議，目前的巨型模型並不需要所有的參數，可以蒸餾成更小的模型而不損失太多輸出品質。Zechner 的希望是未來能將大型模型蒸餾成保留大部分能力的小型模型，而不是為特定任務訓練專門的模型。Redis 的 Antirez 已經開始為 DeepSeek V4 構建一個自訂推論引擎，稱為 ds4，並在一台 128 GB 的筆記型電腦上運行。這是一個非常強大的模型，可以處理 Zechner 使用 Pi 處理的 60 到 70% 的問題。

程式碼成本與工藝紀律

Zechner 看過有人在一週內透過代理程式生成了 50 萬行程式碼。結果總是相同的：災難。程式碼從來都不是免費的，因為後果終究會找上你。如果你認為現在生成大量程式碼是好事，你只是推遲了懲罰的時間。

軟體開發中真正的瓶頸不是打字速度或程式碼生成速度。而是思考、設計和探索解決方案空間。代理程式在該階段確實很有用——你可以指示多個代理程式探索不同的方法並更快地看到結果。但這些探索的輸出並非自動可重用的。你仍然需要理解它、重構它並維護它。

對 Zechner 來說，代理程式帶來的最大生產力提升來自於工作的非同步性。他可以給代理程式一個任務，去開會，然後回來查看結果。但他不認為平行運行 10 個代理程式能讓他的產出提升 10 倍。僅僅是上下文切換就令人筋疲力盡。他每個月會這樣做一兩次，一天處理 30 個問題，之後他的大腦就完全無法運作了。

協作層面是他最看重的。擁有一個代理程式作為結對程式設計夥伴——提問、提出選項、解釋程式碼——就像是心智的單車。它幫助他比獨自一人思考問題時更好地釐清思路。但這需要紀律：不要將一切都委託給機器，因為每次他這樣做，最終都會陷入困境，因為一切都不再完美，一切都分崩離析。

重構 Pi：為未來而建

Pi 累積了歷史包袱。其中部分內容早於 Zechner 使用代理程式的時期，且非常穩固。其他部分，例如 HTML 匯出功能，他從未關注過，只要能渲染出來就不在意。有些部分則是「氛圍編碼」的產物。

重構工作有幾個目標。首先，在不破壞現有擴充功能的情況下，更輕鬆地擴展到其他類型的使用者介面——網頁、原生應用等。其次，實現遠端能力：在一台機器上運行一個 Pi 工作階段，並從另一台機器連接，同時具備良好的持久性和可觀測性。第三，使 Pi 的 SDK 能夠部署在 Cloudflare Workers、Vercel 和其他環境中，而不僅僅是帶有 bash 的本地電腦。

Zechner 正在主分支上進行重構，因為他不在乎傳統意義上的穩定性。他正在逐一進行，從與 LLM 提供者對接的底層套件開始。編碼代理程式本身看起來和運作方式將保持不變，但所有底層基礎設施都將變得乾淨且可重用。他希望在一兩週內完成該階段，然後再花幾週時間開發新的擴充機制，讓擴充功能具備伺服器端和 UI 端組件。

為何 Pi 預設以 YOLO 模式運行

Pi 在執行程式碼前不會請求許可。這是故意的。透過告訴人們 YOLO 模式很危險且他們應該謹慎考慮，Zechner 實際上促使人們思考安全性。他希望他們在內心深處建立安全意識，並決定如何在自己的環境中保護代理程式的工作。

答案通常是容器化。如果你不希望代理程式損壞你的電腦，請將代理程式或它使用的工具——檔案讀寫、bash 等——容器化。這解決了問題。但 Zechner 無法為你做決定。他可以捆綁 Anthropic 的沙盒或 bubble wrap，但這些都是不完整的解決方案。在具有特定基礎設施限制的企業環境中，內建的沙盒可能根本無法運作。

Claude Code 中存在的東西大多是「安全劇場」。Claude Code 現在會在自動模式下執行 bash 指令前詢問 LLM 是否安全。Zechner 認為這並不妥。LLM 無法可靠地判斷指令是否安全——它只能根據模式進行猜測。

結論

Pi 代表了一種不同的哲學：構建開發者可以擁有和修改的工具，而不是擁有開發者的工具。Pi 的成功不是以功能或基準測試來衡量，而是 Zechner 是否能維持一個小團隊的運作，並繼續探索代理程式工作的應用——從編碼到機器人技術再到本地推論。

更廣泛的教訓是，工作流程比炒作更重要。穩定性、可預測性和自訂工具的能力比最新功能更有價值。而且程式碼從來都不是免費的——你行為的後果終究會找上你。