OpenClaw，是當(dāng)下最火的開(kāi)源個(gè)人 AI 助手。很多人不知道的是，OpenClaw 背后，核心是一個(gè)極簡(jiǎn)框架 Pi-coding-agent。

在 OpenClaw 的系統(tǒng)架構(gòu)中，Pi agent 是 Gateway 控制層的核心子系統(tǒng)，控制了所有 agent 的推理和工具調(diào)用。

和 Claude Code、Cursor、Codex 不同的是，Pi 最大的特點(diǎn)是「做減法」：系統(tǒng)提示詞和工具定義加起來(lái)不到 1000 tokens，核心只有 read、write、edit、bash 四個(gè)工具，沒(méi)有內(nèi)置 plan mode，沒(méi)有 to-do 系統(tǒng)，沒(méi)有 MCP 支持，沒(méi)有權(quán)限彈窗，甚至沒(méi)有綁定任何特定模型。

但就是這樣一個(gè)「什么都沒(méi)有」的框架，在 Terminal Bench 2.0 上與 Codex、Cursor、Windsurf 一同排進(jìn)了前五。在 GitHub 上，Pi 積累了超過(guò) 24000 stars 和 148 位貢獻(xiàn)者。

Pi 的作者是奧地利的開(kāi)發(fā)者 Mario Zechner，有著二十多年的開(kāi)源經(jīng)驗(yàn)。Mario 此前曾開(kāi)發(fā)了 Java 跨平臺(tái)游戲開(kāi)發(fā)框架 libGDX，在 GitHub 上擁有 2 萬(wàn)標(biāo)星。

Mario 認(rèn)為，好的 coding agent 不應(yīng)該預(yù)設(shè)你需要什么，而是應(yīng)該讓你自己決定需要什么。

在最近的一場(chǎng) AMA 的直播活動(dòng)上，Mario 和 Pi 框架的三位深度用戶，Sentry 工程高級(jí)總監(jiān) Daniel、Pi 核心貢獻(xiàn)者 Armen、以及 Modem 創(chuàng)始人 Ben，聊了聊他對(duì)于 Pi 的極簡(jiǎn)設(shè)計(jì)思路，以及對(duì)當(dāng)下 Coding Agent 的一些思考。

以下為活動(dòng)中的部分精華內(nèi)容。

??關(guān)注 Founder Park，最及時(shí)最干貨的創(chuàng)業(yè)分享

超 22000 人的「AI 產(chǎn)品市集」社群！不錯(cuò)過(guò)每一款有價(jià)值的 AI 應(yīng)用。

邀請(qǐng)從業(yè)者、開(kāi)發(fā)人員和創(chuàng)業(yè)者，飛書(shū)掃碼加群：

進(jìn)群后，你有機(jī)會(huì)得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

• 不定期贈(zèng)送熱門新品的邀請(qǐng)碼、會(huì)員碼；
  

• 最精準(zhǔn)的 AI 產(chǎn)品曝光渠道

01在經(jīng)過(guò)大量的 RL 后，大模型天然就知道 coding harness 是什么

主持人：市面上已經(jīng)有像 Claude Code 這樣成熟的產(chǎn)品了，最初是怎么想到要自己寫一個(gè) Pi 的？

Mario：說(shuō)實(shí)話，因?yàn)槲沂軌蛄?Claude Code（笑）。我很喜歡 Claude Code，它是定義了 Coding 的產(chǎn)品，團(tuán)隊(duì)也很棒。但輸出的東西老是壞，我說(shuō)的不是 bug，而是我自己的工作流被破壞了，因?yàn)?harness 變了，模型的行為就跟著變了。

作為工程師，我需要更可靠的工具。當(dāng)然，在 2026 年說(shuō)這話有點(diǎn)諷刺，因?yàn)?LLM 本身就不可靠，但至少我個(gè)人能讓它確定性的部分，我希望它是確定性的，包括工具、系統(tǒng)提示詞、以及背后被注入的所有東西。

如果你去看 Claude Code 或者 OpenAI 的 Codex，它們會(huì)在你的上下文里偷偷塞進(jìn)很多東西，而且不會(huì)在 UI 上展示給你。這些東西會(huì)以最微妙的方式破壞你的工作流。它們的發(fā)布節(jié)奏是每天一次甚至一天多次，你可以 9 點(diǎn)開(kāi)始工作、工作流跑得好好的，10 點(diǎn)就壞了，下午 3 點(diǎn)又變成完全不同的行為，模型沒(méi)變，變的是 harness。在這樣的情況下，我沒(méi)法工作。

主持人：Pi 的極簡(jiǎn)設(shè)計(jì)，最初是受到了什么啟發(fā)？

Mario：來(lái)自一個(gè)觀察。在寫 Pi 之前，我去看了 Terminal Bench 的排行榜，上面有一個(gè)叫 Terminus 的 harness，非常神奇，它只給 LLM 一個(gè)工具，跟 tmux session 交互。LLM 必須發(fā)送單獨(dú)的按鍵，讀取 tmux 返回的 ANSI 序列來(lái)完成任務(wù)。就這么一個(gè)工具，它幾乎永遠(yuǎn)排在前三，而且經(jīng)常是第一名。

這給了我一個(gè)劃痕關(guān)鍵的直覺(jué)：模型現(xiàn)在經(jīng)過(guò)了大量的強(qiáng)化學(xué)習(xí)訓(xùn)練，它們天然就知道 coding harness 是什么，不需要在上面堆加太多東西。Pi 就是這個(gè)理念的實(shí)現(xiàn)：一個(gè)極簡(jiǎn)但可擴(kuò)展的 harness。

Mario 在開(kāi)發(fā)博客中寫道：

過(guò)去幾個(gè)月里，Claude Code 變成了一艘宇宙飛船，其中 80% 的功能我完全用不上。系統(tǒng)提示詞和工具定義在每次發(fā)布時(shí)都會(huì)變，這破壞了我的工作流、改變了模型行為。我恨透了這一點(diǎn)。另外，它還會(huì)閃屏。

Pi 最大的特點(diǎn)是，整套系統(tǒng)提示詞加工具定義加起來(lái)不到 1000 tokens。作為對(duì)比，Claude Code 的系統(tǒng)提示詞超過(guò) 10000 tokens，OpenCode 的模型專用提示詞也是類似這種的量級(jí)。

這么短的提示詞，Pi 是怎么做的？

Mario 在一篇博客文章中，分享了他的設(shè)計(jì)理念。

Mario 提到，應(yīng)該把 LLM 當(dāng)作「用自然語(yǔ)言編程的通用計(jì)算機(jī)」，prompt 不是對(duì)話，而是代碼，有輸入、狀態(tài)、輸出和控制流。狀態(tài)應(yīng)該序列化到磁盤上的 JSON 和 Markdown 文件里，這樣你可以從任意一個(gè)斷點(diǎn)重啟、用全新的上下文繼續(xù)，從根本上繞過(guò)上下文衰減問(wèn)題。Mario 用這套方法把一個(gè)原本需要 2-3 周的游戲引擎跨語(yǔ)言移植任務(wù)壓縮到了 2-3 天。

同樣，Mario 在 Pi 的設(shè)計(jì)中，也明確了幾個(gè)主動(dòng)選擇「不做」的功能：

不支持 MCP。主流 MCP server 會(huì)把大量工具定義一次性灌入上下文。Playwright MCP 有 21 個(gè)工具、消耗 13700 tokens；Chrome DevTools MCP 有 26 個(gè)工具、消耗 18000 tokens，還沒(méi)開(kāi)始干活，上下文窗口就少了 7%-9%，而且這些工具在當(dāng)次 session 中大多數(shù)你根本用不到。

Mario 給出的替代方案是，寫 CLI 工具配 README 文件。agent 需要某個(gè)工具時(shí)才讀對(duì)應(yīng)的 README，按需付出 token 成本，然后用 bash 調(diào)用。他用這種方式搭建了一套瀏覽器自動(dòng)化工具集，總共只消耗 225 tokens，是 Playwright MCP 的 1/60。

不內(nèi)置 plan mode。直接告訴 agent "我們先一起想清楚這個(gè)問(wèn)題，不要改文件也不要執(zhí)行命令"就夠了。如果需要跨 session 的規(guī)劃，寫到 PLAN.md 里，agent 可以讀、可以改、可以引用，而且這個(gè)文件可以隨代碼一起版本化。

Mario 特別強(qiáng)調(diào)了可觀測(cè)性：在 Claude Code 的 plan mode 里，它會(huì)在背后生成子 agent，你完全看不到這個(gè)子 agent 做了什么，不知道它讀了哪些文件、漏掉了哪些。在 Pi 里，所有的探索過(guò)程都在你面前，你可以看到 agent 讀了什么、遺漏了什么。

不內(nèi)置 to-do 系統(tǒng)。Mario 的經(jīng)驗(yàn)是，to-do 列表通常讓模型更困惑而不是更高效，增加了模型需要追蹤和更新的狀態(tài)，會(huì)引入更多出錯(cuò)的機(jī)會(huì)。

不做后臺(tái) bash。后臺(tái)進(jìn)程管理會(huì)引入大量復(fù)雜性，進(jìn)程追蹤、輸出緩沖、退出清理、向運(yùn)行中的進(jìn)程發(fā)送輸入。Claude Code 有后臺(tái) bash 功能，但它的可觀測(cè)性很差，而且在早期版本中，上下文壓縮后 agent 會(huì)忘掉所有后臺(tái)進(jìn)程并且沒(méi)有工具去查詢它們。

不內(nèi)置 SubAgent。在這一點(diǎn)上，Mario 的態(tài)度最堅(jiān)決。Claude Code 執(zhí)行復(fù)雜任務(wù)時(shí)經(jīng)常在背后生成 SubAgent，完全看不到子 agent 的對(duì)話過(guò)程，屬于「黑箱里的黑箱」。

如果需要 Pi 生成自己，直接用 bash 啟動(dòng)一個(gè)新的 Pi 實(shí)例就行了，甚至可以放在 tmux 里跑，獲得完全的可觀測(cè)性。

Mario 在博客中寫道：

在 session 中途用 SubAgent 做上下文收集，說(shuō)明你沒(méi)有提前規(guī)劃好。如果你需要收集上下文，在一個(gè)獨(dú)立的 session 里先做完，產(chǎn)出一個(gè) artifact，然后在新 session 里用這個(gè) artifact 給 agent 提供干凈的上下文。

主持人：Daniel，你作為大廠的工程總監(jiān)，個(gè)人使用 AI 編程工具的演進(jìn)路徑是什么樣的？

Daniel：我經(jīng)歷了很長(zhǎng)一段時(shí)間的變化。2024 年夏天，ChatGPT 已經(jīng)好到可以一次就能幫你搞定一個(gè)腳本了。以前寫腳本要花幾小時(shí)查文檔和 API，現(xiàn)在幾分鐘就完事，但體驗(yàn)很原始，打開(kāi)網(wǎng)頁(yè)、復(fù)制粘貼、本地創(chuàng)建文件，太笨重了。

真正的 magic moment 是 2025 年 6 月，Cursor 實(shí)現(xiàn)了 agentic loop。我第一次對(duì) agent 編程上癮了，一個(gè)周末、兩個(gè)晚上，從零搭了一個(gè)包含前后端和用戶登錄的完整 Web 應(yīng)用，放在以前至少要一到兩周。

然后就是 2025 年底，Opus 4.5 出來(lái)了，我徹底迷上了 Claude Code。之前 agent 大概 50% 的時(shí)候能用，Opus 4.5 讓它變成了 80% 能用。

主持人：最后為什么你還是棄用 Claude Code 了？

Daniel：大概 2026 年 1 月，我發(fā)現(xiàn)了問(wèn)題。Claude Code 像一輛超級(jí)舒適的車，你坐進(jìn)去，它就能把你送到目的地。而且它非常樂(lè)觀，會(huì)告訴你"我們能搞定的"。但有時(shí)候它會(huì)騙你說(shuō)，「已經(jīng) production ready 了」，結(jié)果你一打開(kāi)就崩潰了。

每次開(kāi)一個(gè)新的 session 時(shí)，我都要重復(fù)同樣的指令，但同樣的錯(cuò)誤又來(lái)了，hooks 機(jī)制剛推出就有 bug。Claude Code 本身不穩(wěn)定，有時(shí)候直接崩潰把你踢出去，所以要從斷點(diǎn)恢復(fù)幾乎是不可能的。

我被彈回了兩次，前兩次裝完 Pi，感覺(jué)回到了「石器時(shí)代」，什么都沒(méi)有。但第三次我換了策略：不用 Pi 去做一個(gè)功能，而是用 Pi 來(lái)構(gòu)建我自己的 agent。這是真正的 Aha moment。

主持人：面對(duì) Pi 這么極簡(jiǎn)的框架，你們?nèi)坏氖褂梅绞讲町惡艽?。分別講講各自日常的工作流。

Daniel：我的工作流是這樣的：首先用我調(diào)整過(guò)的 brainstorming skill 做規(guī)劃，它要求模型給出三種方案：一個(gè)激進(jìn)的、一個(gè)務(wù)實(shí)的、一個(gè)豪華的，然后我跟模型討論，最終確定方案。這個(gè)過(guò)程產(chǎn)出一個(gè) markdown 計(jì)劃文件和一系列 to-dos。

然后進(jìn)入實(shí)施階段。如果是已有代碼庫(kù)，先啟動(dòng)一個(gè) scoutSubAgent 去探索需要改動(dòng)的文件，把結(jié)果傳給 worker agents。Worker agents 只用 Sonnet 4.6，因?yàn)槿蝿?wù)已經(jīng)足夠明確，不需要 Opus。更快也更便宜。實(shí)施完成后，用 Codex reviewerSubAgent 做代碼審查。

最有意思的部分是迭代修復(fù)。大功能實(shí)施完之后，我通常還剩 40% 到 60% 的上下文窗口，而且是完美的熱上下文。我不需要重新解釋我們?cè)谧鍪裁?、用了什么技術(shù)、為什么做了某些取舍。直接使用應(yīng)用、找到問(wèn)題、讓 agent 修復(fù)、然后 rewind 回實(shí)施完成的節(jié)點(diǎn)、修下一個(gè)問(wèn)題，如此循環(huán)直到打磨完成。

Armen：我更關(guān)注怎么讓 agent 更高效。比如我完全替換了 Pi 的內(nèi)置 edit tool，換成支持 patch-based 多文件編輯的版本，靈感來(lái)自 Codex 的 apply patch。

另一個(gè)我重度使用的是 answer 擴(kuò)展。Claude Code 的 plan mode 會(huì)給上下文注入一個(gè)"提問(wèn)"工具，即使你不在 plan mode 里它也一直存在，有時(shí)候會(huì)在不需要的時(shí)候蹦出來(lái)。我寫了一個(gè) answer 擴(kuò)展替代它，提取模型提出的所有問(wèn)題，重新渲染成 UI，逐個(gè)回答后提交，完全不消耗上下文。

我還讓 agent 在驗(yàn)證改動(dòng)時(shí)自動(dòng)截圖。Pi 是少數(shù)能把截圖讀進(jìn) LLM 并且漂亮顯示的編程 agent。即使幾天后加載舊 session，我仍然能看到 agent 當(dāng)時(shí)截的每一張圖。

Mario：我個(gè)人只有兩個(gè)擴(kuò)展，而且是特定項(xiàng)目的。我只要我的極簡(jiǎn)體驗(yàn)：打個(gè)招呼、開(kāi)始干活、別出錯(cuò)。我給你們?cè)炝艘慌_(tái) meta slop machine（元 slop 機(jī)器），這樣你們可以盡情發(fā)揮。而我自己住在我非常斯巴達(dá)式的世界里。

04讓多個(gè)SubAgent并行開(kāi)發(fā)的模式，行不通

Mario 此前在博客中，提到：

讓多個(gè)子 agent 并行開(kāi)發(fā)不同功能，在我看來(lái)是一種反模式，不會(huì)有好結(jié)果，除非你不在乎代碼庫(kù)變成一堆垃圾。

在 session 中途用子 agent 做上下文收集，說(shuō)明你沒(méi)有提前規(guī)劃好。如果你需要收集上下文，在一個(gè)獨(dú)立的 session 里先做完，產(chǎn)出一個(gè) artifact，然后在新 session 里用這個(gè) artifact 給 agent 提供干凈的上下文。這個(gè) artifact 對(duì)下一個(gè)功能可能也有用，而且你能獲得完全的可觀測(cè)性和可操控性，這在上下文收集階段至關(guān)重要。

去看看 Pi 的 issue tracker 和 pull requests 吧。很多都被關(guān)閉或者要求修改了，因?yàn)槟切?agent 無(wú)法完全理解項(xiàng)目需要什么。這不是貢獻(xiàn)者的錯(cuò)，即使是不完整的 PR 也能幫我更快地推進(jìn)。但這說(shuō)明我們對(duì) agent 的信任還是太多了。

主持人：在 SubAgent 上，大家的分歧似乎很大。

Mario：我從來(lái)沒(méi)發(fā)現(xiàn) SubAgent、編排、swarm 這些東西對(duì)我有效。但這可能也因?yàn)槲胰匀粫?huì)閱讀 agent 產(chǎn)出的大部分代碼。我不想要 10 個(gè) agent 同時(shí)干活，然后一天結(jié)束時(shí) review 2 萬(wàn)行代碼，這對(duì)人類大腦來(lái)說(shuō)不可擴(kuò)展，而且那 2 萬(wàn)行代碼大概率質(zhì)量不行。

我不追求每天創(chuàng)建更多功能，我追求的是每天能做更多決策，關(guān)于產(chǎn)品需要什么、不需要什么。

我的替代方案是用 /tree 命令。讓 agent 自由探索代碼庫(kù)，然后做一個(gè)摘要，回到起點(diǎn)只帶上摘要繼續(xù)工作。這是我的窮人版 SubAgent。

Armen：我的看法是，你必須先把串行流程跑通了，才能考慮并行化。我到現(xiàn)在還沒(méi)有找到一種方法可以自動(dòng)化「探索」這一步。如果我自己還得在 loop 里，并行化對(duì)我?guī)椭淮蟆?/p>

Mario：有一個(gè)不錯(cuò)的反例。Shopify 的 Tobi 做了一個(gè) Pi 擴(kuò)展，給你一個(gè)本地指標(biāo)，agent 們?cè)诮饪臻g里并行探索不同的優(yōu)化方案。對(duì)這種「把東西往墻上扔、看哪個(gè)粘住了」的探索型任務(wù)，SubAgent 確實(shí)很強(qiáng)大。但對(duì)于真正的功能構(gòu)建，我還是要在 loop 里，我還是要做最后拍板的人。

Armen：我昨晚剛用 auto-research 跑了一下我自己的模板引擎。即便是這種場(chǎng)景，也只能串行跑，并行的話會(huì)同時(shí)引入太多修改，你得退回大部分，結(jié)果就是一堆 merge conflicts。不過(guò)效果確實(shí)不錯(cuò)，引擎快了大約 20%。

05大部分 Coding Agent 的權(quán)限系統(tǒng)，都是「安全劇場(chǎng)」

主持人：在安全問(wèn)題上，Pi 的設(shè)置是，完全沒(méi)有權(quán)限系統(tǒng)。為什么這么設(shè)計(jì)？

Mario：這被 Simon Willison 稱為「trifecta」：如果你給 agent 執(zhí)行命令的能力、讀取網(wǎng)絡(luò)內(nèi)容的能力、以及讀取本地文件的能力，你就完蛋了。目前，其實(shí)沒(méi)有好的解決方案。

至于那些權(quán)限彈窗？可愛(ài)，但不解決問(wèn)題。它導(dǎo)致的是 permission fatigue，用戶被 agent 不斷打斷，最后就會(huì)一路 yes yes yes，然后干脆"跳過(guò)所有權(quán)限"。

Mario 在此前的博客中寫道：

看看其他編程 agent 的安全措施，大部分都是安全劇場(chǎng)（security theater）。只要你的 agent 能寫代碼和執(zhí)行代碼，就已經(jīng) game over 了。唯一能防止數(shù)據(jù)泄露的方法是切斷執(zhí)行環(huán)境的所有網(wǎng)絡(luò)連接，但這會(huì)讓 agent 基本沒(méi)法用。域名白名單也能通過(guò)其他手段繞過(guò)。

Simon Willison 寫了大量關(guān)于這個(gè)問(wèn)題的文章。他提出的 "dual LLM" 模式試圖解決 confused deputy attack 和數(shù)據(jù)竊取，但他自己也承認(rèn)"這個(gè)方案相當(dāng)糟糕"，而且引入了巨大的實(shí)現(xiàn)復(fù)雜度。核心問(wèn)題不變：如果一個(gè) LLM 能讀取私有數(shù)據(jù)又能發(fā)起網(wǎng)絡(luò)請(qǐng)求，你就是在玩打地鼠游戲。

既然我們解決不了這個(gè)"三體難題"（讀數(shù)據(jù) + 執(zhí)行代碼 + 網(wǎng)絡(luò)訪問(wèn)），Pi 就直接投降了。反正所有人最終都會(huì)切換到 YOLO 模式來(lái)提高生產(chǎn)效率，那為什么不把它作為默認(rèn)的、唯一的選項(xiàng)？

Armen：權(quán)限系統(tǒng)還有另一個(gè)問(wèn)題。即使你拒絕了大部分權(quán)限，只給 agent 跑一個(gè)腳本的權(quán)限，它會(huì)通過(guò)這一個(gè)腳本做所有事情。你可以自己試：給 Claude Code 或 Codex，只允許它運(yùn)行 checkout 里的一個(gè)腳本文件，它會(huì)開(kāi)始編輯這個(gè)文件來(lái)實(shí)現(xiàn)各種改動(dòng)。非常聰明，但也說(shuō)明了權(quán)限系統(tǒng)形同虛設(shè)。

Mario：我個(gè)人的做法是：在宿主機(jī)上有需要保護(hù)的東西，就把 Pi 放進(jìn) Docker 容器，只掛載它需要的數(shù)據(jù)。其他時(shí)候就全開(kāi)。

06Coding Agent不需要額外的長(zhǎng)期記憶

主持人：你們覺(jué)得 Coding Agent 需要額外維護(hù)一套記憶系統(tǒng)嗎？你們?cè)趺纯?agent 的長(zhǎng)期記憶？

Mario：我認(rèn)為目前不需要，至少對(duì)編程任務(wù)來(lái)說(shuō)不需要。代碼庫(kù)就是 source of truth，我不需要在代碼庫(kù)之上維護(hù)一層額外的信息。

我認(rèn)為 Claude Code 最偉大的發(fā)明之一是搜索，不是去索引、向量化、BM25 檢索你的代碼庫(kù)，而是讓 agent 每次從零開(kāi)始，探索代碼庫(kù)的當(dāng)前狀態(tài)，然后再動(dòng)手。這以前做得不好，現(xiàn)在做得非常好，尤其是 Codex，它在收集上下文方面真的很強(qiáng)。

傳統(tǒng)的做法是什么？寫文檔，然后文檔一周就過(guò)時(shí)了，沒(méi)人讀。代碼才是真相。讓 agent 探索代碼庫(kù)的當(dāng)前狀態(tài)，是編程任務(wù)目前最好的做法。對(duì)于其他場(chǎng)景，比如 OpenClaw 那種需要記住你家庭成員信息的個(gè)人助手，當(dāng)然可以用記憶系統(tǒng)。但寫代碼不需要。

Daniel：我試過(guò)一種方法：session 快超出上下文窗口了就做一個(gè)摘要，在新 session 里從摘要繼續(xù)。但我發(fā)現(xiàn)沒(méi)什么用，只是往上下文里塞了更多東西。最后我就用本地的 agents.md，想讓 agent 下次記住什么，寫進(jìn)去就行，夠用了。

Armen：我們做了一些實(shí)驗(yàn)，把最近的 Git 變更推進(jìn)上下文，幫 agent 從上次斷點(diǎn)繼續(xù)。結(jié)果好壞參半。目前沒(méi)被說(shuō)服。

07你的 AI「變笨了」，并不是錯(cuò)覺(jué)

主持人：很多人提到，經(jīng)常覺(jué)得自己的工具「變笨了」，AI 工具在悄悄「gaslight」開(kāi)發(fā)者，你們?cè)趺纯矗?/strong>

Mario：如果你經(jīng)常覺(jué)得你的工具「變笨了」，這并不是錯(cuò)覺(jué)。

2025 年 8 月，我開(kāi)發(fā)了一個(gè)叫 cchistory 的工具，專門用來(lái)追蹤 Claude Code 每個(gè)版本的系統(tǒng)提示詞和工具定義變更。

在 cchistory 的記錄下，發(fā)現(xiàn)了大量的「靜默調(diào)整」：

• 早期版本會(huì)把完整的項(xiàng)目目錄樹(shù)注入系統(tǒng)提示詞，后來(lái)被刪掉了，因?yàn)樗鼑?yán)重污染上下文；

• 一條要求 Claude 清理測(cè)試/調(diào)試文件的指令被移除，因?yàn)?Claude 過(guò)于激進(jìn)地刪除了合法文件；

• Bash 命令解釋的要求也被去掉了，可能是為了降低服務(wù)器負(fù)載；

• 安全相關(guān)的措辭從籠統(tǒng)的"拒絕創(chuàng)建惡意代碼"演變?yōu)楦?xì)致的分類；

• Grep 工具經(jīng)歷了重大重構(gòu)，強(qiáng)制要求使用內(nèi)置 Grep 而非 bash grep；

雖然每一條變更都合情合理，但問(wèn)題是：用戶對(duì)此完全不知情，而每一條都可能改變模型在你 session 中的行為。

Armen：我們現(xiàn)在做的這個(gè) vibe-based engineering 非常瘋狂。以前我們行業(yè)有一個(gè)很重要的原則：不隨便改 API、保持向后兼容。現(xiàn)在因?yàn)樗薪涌诙际亲匀徽Z(yǔ)言，MCP server 沒(méi)有穩(wěn)定接口，系統(tǒng)提示詞沒(méi)有穩(wěn)定接口，各種 agent harness 上面還有隨機(jī)的 A/B 測(cè)試。你日常使用的工具，每一層都在不斷被 gaslight。

我甚至覺(jué)得，雖然可能完全是我的錯(cuò)覺(jué)，當(dāng)美國(guó)那邊醒了之后，我的 agent 表現(xiàn)就會(huì)變差。但我也不知道是不是真的，因?yàn)槲覍?duì)正在發(fā)生的事情幾乎沒(méi)有任何能見(jiàn)度。

Mario：這也是我造 Pi 的動(dòng)機(jī)之一。我不想要一個(gè)別人可以隨時(shí)在背后改變的工具。我想要確定性的工具、確定性的系統(tǒng)提示詞、確定性的行為。如果行為不對(duì)，我自己來(lái)改，至少我知道改了什么。

Claude Code 或 Codex 在后臺(tái)推了多少東西到你的上下文里，你是看不到的。而所有這些，都在以最微妙的方式影響著你的工作。

主持人：現(xiàn)在滿世界都是能自動(dòng)寫代碼、提PR的 AI，這給你的開(kāi)源社區(qū)維護(hù)帶來(lái)了什么挑戰(zhàn)？

Mario：大量完全由 AI 生成、沒(méi)有人工監(jiān)督的 issue 和 PR 涌入我的倉(cāng)庫(kù)。一個(gè)標(biāo)題看起來(lái)合理的 PR，點(diǎn)進(jìn)去一看，天哪，PR 描述是一本書(shū)的長(zhǎng)度，改了 30 到 100 個(gè)文件。有時(shí)候是好的，有時(shí)候是垃圾，但你必須讀完所有這些東西才能判斷。

有人提到，為什么不讓 AI 去審 AI？但 AI 在判斷一個(gè) issue 或 PR 是否跟項(xiàng)目相關(guān)、質(zhì)量是否達(dá)標(biāo)、是否符合項(xiàng)目哲學(xué)方面非常糟糕。你可以在 agents.md 里編碼這些標(biāo)準(zhǔn)，但就是不行。這些判斷仍然需要經(jīng)過(guò)人類的大腦。

所以我搭了一套系統(tǒng)：不是所有人都能直接提 PR。你必須先用人類的聲音開(kāi)一個(gè) issue，我讀了之后回復(fù)確認(rèn)，你的賬號(hào)名才會(huì)被寫進(jìn)白名單。之后你提 PR，GitHub workflow 會(huì)檢查你是否在名單上。不在的話，PR 自動(dòng)關(guān)閉，附一條消息：「請(qǐng)先用人類的聲音開(kāi)一個(gè) issue?！?/p>

這個(gè)方案很有效，因?yàn)?AI 不會(huì)回去讀那條關(guān)閉 PR 時(shí)機(jī)器人發(fā)的評(píng)論。但對(duì) issue 不適用，issue 的提交門檻更低，沒(méi)法要求每個(gè)人都先經(jīng)過(guò)手動(dòng)審批。PR 這邊基本解決了，issue 還是個(gè)難題。

轉(zhuǎn)載原創(chuàng)文章請(qǐng)?zhí)砑游⑿牛篺ounderparker