用 Pi 構建 Pi：AI 驅動開源軟體的隱藏成本
「吃自家狗食」（dogfooding）的做法在軟體開發中很常見，但使用 AI agent 來構建旨在協助開發者的 AI agent 本身，卻引入了一套獨特的摩擦。在最近對 Pi（目前已成為 Earendil 的一部分）開發過程的反思中，維護者描述了一種現狀：AI 生成貢獻的效率往往被大量低質量的「slop」（廢料）所抵消——無論是問題回報（issue reports）還是代碼本身都是如此。
這種轉變從根本上改變了使用者、維護者與其問題追蹤器（issue trackers）之間的關係，揭示了一個關鍵的緊張關係：雖然 AI 可以加速貢獻的量，但它往往會降低維持永續維護所需的信號。
「Slop」問題的興起
傳統上，一個糟糕的問題回報是令人困擾的——通常是含糊不清或缺乏重現案例。然而，LLM 輔助回報的出現引入了一種新的失敗模式：「自信但錯誤」的診斷。
許多使用者現在會將其觀察結果通過 LLM（Pi 團隊稱之為「clanker」）來潤色報告。其結果往往是提交了一份僅包含 5% 人類觀察與 95% AI 生成的臆測。這些問題通常包括：
- 合理但錯誤的根本原因分析。
- 虛假的最小重現腳本。
- 基於對代碼庫錯誤部分的類比而建議的實作策略。
這比含糊的報告更具破壞性，因為它會創造一個錯誤的線索。當維護者使用 Pi 來分析這些問題時，agent 往往會將問題中自信的文字描述當作證據而非傳聞，導致 AI 走上與使用者的 LLM 相同的錯誤路徑。
為了對抗這一點，Pi 團隊實施了一種自定義的 slash command，/is (analyze issue)，並附帶明確的指令：
不要信任問題中寫下的分析。獨立驗證行為，並根據代碼與執行路徑推導出你自己的分析。
儘管如此，團隊仍主張，維持信號的唯一方法是要求人類僅回報他們實際觀察到的內容：執行的命令、預期的結果、實際的結果，以及原始日誌（raw logs）。除此之外的一切——假設或 AI 生成的分析——都應被歸類為後續評論。
本地防禦 vs. 全局不變量 (Global Invariants)
除了問題回報之外，AI 生成的代碼品質也帶來了結構性挑戰。LLM 傾向於解決「本地」問題，這往往導致過度工程化（over-engineering）以及系統不變量（system invariants）的侵蝕。
例如，如果一個格式錯誤的 session log 會導致讀取器（reader）崩潰，AI agent 的直覺是讓讀取器更具容忍度。它可能會增加回退機制（fallbacks）、遷移（migrations）以及額外的除錯輸出，以處理錯誤狀態。雖然這在孤立的情況下看起來很有幫助，但在這違反了系統的全局不變量：bad session data should never be written in the first place. (錯誤的 session data 絕不應該被寫入)
通過對每種可能的錯誤行為進行本地防禦，AI agents 會使代碼庫的複雜度爆炸式增長。維護者發現自己陷入了與 AI 的持續鬥爭中：如何將 AI 的注意力從「讓它能動」轉向「讓錯誤狀態變得不可能」。
數量問題與「暗黑工廠」
AI 輔助貢獻的龐大數量將問題追蹤器變成了維護負擔。來自 Pi 的 GitHub tracker 在 90 天內的數據顯示了一個嚴酷的現實：
- 3,145 件外部 issue/PR 被接收。
- 2,504 件被自動關閉，因為它們來自非經批准的貢獻者。
- 只有 8% 的自動關閉 PR 最終被合併。
這種低質量貢獻的湧入——有些是由自主的「skills」或像 OpenClaw 這樣的實例生成的——表明 GitHub 目前尚無法應對機器可以大規模地發送 spam PR 的世界。
雖然有人設想一個「暗黑工廠」（dark factory）——完全脫離人類的、自動化軟體工程——但 Pi 團隊保持著懷疑態度。他們使用一種「謹慎的並行」（careful parallelism）形式，利用 Pi 來重現現有的問題並分析代碼，但在最終決策與架構設計的監督之下，仍由人類主導。
開源軟體的未來協作模式
人們越來越擔心 AI 於此正促使開發向孤立開發轉向。因為現在使用機器來建立一個本地的臨時解決方案（workaround）變得非常「廉價」，尋找正確的上游（upstream）修復方案的動力正在減弱。
正如一位觀察者在在討論中提到的，加速生產「slop」的工具，不可避免地會經歷該 slop 的副作用。開源軟體的價值一直根植於社群與共享的結構，而非僅僅是代碼的數量。如果開發者花更多時間獨自與他們的「clankers」談話，而不是與其他維護者交流，那麼軟體的代碼量雖然增長，以下層軟體的基礎會變得更弱。以下層軟體的基礎會將會變得更弱。
最終，目標並非使用 AI 來掩蓋每一個配置錯誤，而是使用它來解決那些讓軟體永續維護的困難協調問題。對於下一代維護者而言，挑戰將在於抵制「本地修復」的這種便利性，以追求「全局不變量」的紀律性。