「OpenClaw 項目每小時能收到上百個 pr，甚至很多 PR 的提交者自己都不知道這段代碼是怎么來的。代碼開始成為了一種負債?！?/p>

「當代碼都是 AI vibe 出來的，測試其實比真實代碼更值錢?！?/p>

「以前，工程師的核心能力是做 Feature Coding，但現(xiàn)在你會更注重整個 Platform Engineering 的事情?！?/p>

OpenClaw 已經(jīng)持續(xù)發(fā)酵了半個多月。

在這段時間里，我們看到的一個趨勢是，OpenClaw 正在從一個單純的極客「玩具」，逐漸在各種具體業(yè)務中被實際用起來、作為一個可落地的生產(chǎn)力工具來提效。國內(nèi)的幾家基模大廠，也陸續(xù)發(fā)布了類似產(chǎn)品或功能。

于是，在組織了第一場之后，我們決定找離 OpenClaw 最近的一群人：一線開發(fā)者、技術 founder、明星創(chuàng)企的核心工程師，聊聊在概念、熱度之外，他們在各種實際業(yè)務中是怎么用 OpenClaw 的，以及一些真實的思考與困惑。

這場閉門分享，很硬核，我們整理了部分精彩內(nèi)容。

PS：考慮到是閉門分享交流，我們對一些嘉賓進行了匿名化處理。

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

超 19000 人的「AI 產(chǎn)品市集」社群！不錯過每一款有價值的 AI 應用。

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

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

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

01Vibe Coding 時代，

代碼開始成為負債

「Code as Liability」

飛書 OpenClaw 插件維護者：先分享一個非?？鋸埖臄?shù)據(jù)。大家可以想一下，現(xiàn)在的 OpenClaw 項目主干，平均每小時會收到多少個 PR？這個數(shù)字現(xiàn)在是 30 到 60 個，高峰期甚至能超過 100 個?，F(xiàn)在隨時去看它官方倉庫，都可能看到 2000 多個待處理的 PR。這意味著，你的貢獻能被合并進去的概率，大概是兩千分之一。

回到工程視角來看。如果未來的開源項目都以這種方式維護，一個小時涌入幾十個 PR，怎么可能有人 review 得過來？即使 OpenClaw 現(xiàn)在有幾百個 contributor，但最終的 maintainer 數(shù)量也是極其有限的，這些 maintainer 的注意力非常稀缺。

為了應對這種情況，OpenClaw 社區(qū)甚至搞了一個專門的頻道，限制每個人 6 小時內(nèi)只能發(fā)一條消息。如果你覺得自己的 PR 特別重要，想讓維護者看到，就只能在這里「排隊」發(fā)言，才可能更優(yōu)先地獲得注意力。

整個狀態(tài)，就好像一個大企業(yè)每天收到幾千份內(nèi)推簡歷，最終誰的簡歷能被優(yōu)先看到，已經(jīng)變成了一個純粹的注意力爭奪問題。

這帶來了一個非常大的轉(zhuǎn)變。之前的開源項目里，如果看到一個新的 PR，第一反應是積極的：有人愿意讀我的代碼，有人愿意參與維護，那我可以降低一點這個項目的「公交車指數(shù)」，就是萬一我出門被公交車撞了，還有人能維護這個項目。

但現(xiàn)在，這個模式可以說被完全顛覆了。因為所有人都可以隨便提交，甚至很多 PR 的提交者自己都不知道這段代碼是怎么來的。維護者的心態(tài)更多地轉(zhuǎn)向了「Code as Liability（代碼是負債）」的角度。你每增加幾百行代碼，都可能引入一些意想不到的問題，讓項目在未來更難維護。在這種心態(tài)下，只能盡可能避免隨意合并。

開源的信任鏈條其實有些斷裂，我們似乎又回歸到了最原始的人際信任。

一方面是需要更多的人際信任來做背書，另一方面，我們需要探索自動化的 review 和測試。實際上，OpenClaw 自己已經(jīng)有了一套機制，它會自己識別出來那些很低質(zhì)量的、機器生成且你根本不 care 的 PR，關掉。

我的感覺是，在 OpenClaw 這種大家用 Vibe Coding 寫 PR 的「惡性通脹」產(chǎn)能下，傳統(tǒng)的開源信任鏈條是斷裂的。我們合并一個 PR，不是因為我讀了你所有代碼，可能是信任你作為一個 engineer 的工程能力，和你對這個東西持續(xù)維護的 credit。

我們還不知道如何迎接上萬個高質(zhì)量PR的涌入

Agent 創(chuàng)業(yè)者：我很喜歡把代碼庫比作「膠水」。在 Agent 時代，我們可以重新審視代碼的本質(zhì)：它不就是連接邏輯的膠水嗎？現(xiàn)在的 Coding Agent 就像手里的一把「熱熔膠槍」，它可以源源不斷地噴出膠水。每個人手里都拿著一把熱熔膠槍，對著一個「泡泡瑪特」玩具說，「誒，這個不錯，我也來噴點膠水」。每個人都想按照自己的意愿把它粘成合適的形狀。但最終，這個玩具是被粘得更奇怪，還是更圓潤？我覺得這是一個很深的問題。

OpenClaw 這個項目其實讓我看到了這個問題被推向了一個更瘋狂的層面。

所以我一直在思考一個問題：未來如果過了半年或一年，GitHub 上一定會涌現(xiàn)出一批這樣的倉庫，無數(shù)的人和 Agent 都在瘋狂地往里提交代碼。在 OpenClaw 這個項目上，現(xiàn)在很多提交代碼的已經(jīng)不是人了，而是 Agent。未來這個情況只會推演得更加瘋狂。

到了那時候，假如以小時甚至分鐘為單位，都有海量高質(zhì)量的 PR 被提交進來。從 review 的角度看，每一個 PR 單獨拿出來，可能都有在某個角度上的合理性。那么，當這些中上水平的 PR 涌入時，會發(fā)生什么？

首先，人工測試顯然已經(jīng)是不太現(xiàn)實了。其次，也是我更關心的問題：當一分鐘有上萬個高質(zhì)量PR涌入時，我們那個時代的 Git 基礎設施、整個軟件倉庫的演進生態(tài)，以及相應的治理規(guī)范，會是什么樣？這可能是我覺得目前還沒有明確答案的地方。

Vibe Coding 進入到了一個「快消費」的時代

AI4S Agent 創(chuàng)業(yè)者：我覺得 Vibe Coding 的 Impact 我們才剛剛感知到一部分，但它對社會的長期 Impact 才剛剛開始。我寫了十幾年代碼，也研究了兩三年代碼生成，現(xiàn)在發(fā)現(xiàn) Vibe Coding 進入到了一個非?！缚煜M」的時代。

這種「快消費」跟傳統(tǒng)的硬核開發(fā)，比如寫 Linux Kernel、數(shù)據(jù)庫 Planning，形成了鮮明對比。一邊是非?？焖?、用后即拋的使用方式，另一邊是支撐整個互聯(lián)網(wǎng)的最基礎架構，可能還是需要那 20 個人去寫最核心的維護代碼。

這兩種情況下如何協(xié)作？如何維持兩者之間的 Tension？普通人能不能去寫 Linux Kernel？我覺得這非常有趣。

就像前邊提到的「膠水」比喻，很早以前鑄造一個東西需要做模型、找工匠，現(xiàn)在可能直接 3D 打印就出來了。當代碼變成一個用后即拋的東西之后，它真正的價值和意義到底是什么？非常需要我們思考。

02當代碼都是 AI vibe 出來的，

測試變得異常重要

測試，其實比你真實的代碼更值錢

Agent Infra 創(chuàng)業(yè)者：我們的項目——Agent 運行時的 Sandbox 基本就是 Vibe Coding 出來的，Claude Code 是我們項目的第一貢獻者，它的 Commit 數(shù)量是我們剩下 4 個人加起來的總和。這個項目非常依賴測試。

但如果你放手讓 Claude Code 去寫測試的話，你會發(fā)現(xiàn)他寫大量那種我們叫「瞎 Mock」的東西。他可能在一個測試里把所有外部環(huán)境全 Mock 一遍，裝模作樣測一下，告訴你通過了，實際上真實代碼一行都沒跑。這種測試是無效的。

所以我們在文檔里寫了非常多的 Testing 規(guī)則，還寫了一些 Skill。當它開發(fā)完代碼，我們會主動 @ 這些規(guī)則，讓他去修改代碼。

我覺得測試其實比真實代碼更值錢。像 Claude 前段時間號稱寫了個 C 編譯器，其實 C 編譯器的 Test Case 這么多年已經(jīng)非常完善了。你在一個快速反饋的環(huán)境下去燒 Token，是能燒出來的。但在一個比較開放的開發(fā)任務里，讓 Coding Agent 去做事就非常困難。

所以我的觀點是，Coding Agent 寫的代碼我可以不看，但他寫的測試我一定會看，而且一定會嚴格要求他按照我們的 Pattern 去重寫。

這里有一個很重要的 Mock 規(guī)則，只有第三方的庫你可以 Mock，但是你所有的內(nèi)部 Library、內(nèi)部 Service 都不能 Mock。

在我們的通用測試框架里，除了三方的東西 Mock 之外，所有內(nèi)部 Service 調(diào)用都是真實的。驗證的時候，我們只驗證 API 的請求和結果，不做任何手工數(shù)據(jù)庫插入和讀取的斷言。這在以往算集成測試，但我們會把它定義成最小粒度的單元測試。

對于 UI 測試，我們有兩種。一種是我們寫的最多的，就是 React 的 UI 測試。我們會把整個頁面渲染出來，在模擬環(huán)境中做用戶界面操作，比如點擊按鈕，斷言 UI 結果。這里面沒有真實瀏覽器，是模擬的 DOM。

還有一類是 Playwright 那種 E2E 測試，那個測試很慢，我不太喜歡寫。一般只測 Happy Pass（主流程），比如登錄注冊能進首頁，寫一兩個就行。大部分還是 React Mock DOM 的測試。

飛書 OpenClaw 插件維護者：Playwright E2E 其實很重，維護成本也很高。但測試有一個黃金準則：你的測試越接近實際使用的方式，你就越能帶來實際的信心，你就越確信這個東西不會壞。

我們的實踐是，會更多投人力去維護 E2E 測試。因為它雖然容易壞，但真正抓到線上問題還是靠它。

但 Agent 公司的迭代速度非?？欤覀兙陀辛艘粋€準則，我們還是用 Playwright 寫很多很多的 E2E，但分類兩類：

• 冒煙測試：往主干合代碼時，比較激進，只跑 50 個以內(nèi)的 Case，允許 Mock 后端，保證 5 分鐘內(nèi)能合進去。

• 巡檢：面向線上的場景，低頻地跑，比如半小時一次，用線上端到端的鏈路驗證。

這里有個簡單的實踐技巧：給業(yè)務應用加測試時，先用一個 Skill 去掃描 UI 組件，加上 test-id。然后讓 AI 寫測試用例，只驗證打開 UI 時 test-id 都在。以此為起點，你可以封裝一些能力，這樣就不需要每次都依賴多模態(tài)模型，成本低且快。

模型就像「抽卡」建立一個自己的 benchmark很重要

基模公司核心工程師：測試這件事情其實很重要?，F(xiàn)在的模型每次更新后，權重和訓練數(shù)據(jù)都會變，模型公司是不對這個負責的。這跟做工程不一樣，模型類似于「抽卡」。今天抽到 80 分，下次可能是 60 分，波動非常大。

比如 GPT-4o 剛發(fā)布時，很多人說缺少了 GPT-4 的「人味兒」。模型公司自己不一定測得出來，因為他們只關注自己的 Benchmark 指標。這件事情其實對 AI 從業(yè)者來說，是一個非常疲憊的事情。因為，每天都像是在跟一個新的人聊天。我今天教的東西，明天到底會不會？

所以我的一個建議是，去造一些屬于你們自己的 Benchmark，驗證它到底能干什么。用這件事情從概率里找到準確性，保證你的東西能持續(xù)往前走。

03大眾還在接受過程中，

少數(shù)人已經(jīng)玩成了「超級個體」

Pro User 玩出了花，普通用戶卻有點恐懼

AI4S Agent 創(chuàng)業(yè)者：因為在灣區(qū)，我們離 OpenClaw 這邊非常近，也從第一方的視角實際參與進去了。我們跟 OpenClaw 官方組織了一個用戶的 Workshop，幫 50 個人配置了 OpenClaw。發(fā)現(xiàn)了一些很有趣的東西，在普通人和專業(yè)工程師之間，大家對于 OpenClaw 的認知差有點大。

對于工程師、PM 來說，安裝 OpenClaw 可能很容易。但對于普通用戶時，大部分人其實都不知道怎么弄，他們完全不知道 Terminal 是什么。而且 OpenClaw 很多代碼是 Vibe Coding 出來的，有一些不太穩(wěn)定的地方，在 Mac 或 Linux 上會有各種環(huán)境配置問題，所以最終跑通的成功率其實并不高。

但是，一旦跑通了，那種感覺真的有點像「Feel of AGI」。當他把 OpenClaw 跟 WhatsApp、Gmail 連起來，再去操作的時候，那個體驗是非常不一樣的。

還有一點，大家其實非常恐懼。印象很深，我?guī)鸵晃慌b Mac mini 上的 OpenClaw，她之前從來沒有接觸過編程。裝 Gmail 插件時需要去 Google Cloud Console 建一個 App，把 API Key 和 Secret 復制到 Terminal 里。她當時整個人都傻了，有點像被扔到了太平洋正中間。當我離開的時候，出了問題她完全不知道該怎么繼續(xù)。這個視角非常有趣。

但我跟那些所謂的 AI Native 的朋友，也就是 OpenClaw 的 Pro User 去聊，發(fā)現(xiàn)真正跑起來后，對某些行業(yè)的效果其實是非常好。比如當公司的 Workflow 已經(jīng)數(shù)字化，且不需要太多人工審核時，整個公司都可以搬到 OpenClaw 上。

我有個 Creator 朋友，買了兩三臺 Mac Mini，裝了 Gemini Ultra 的 Plan。他們公司不光是做內(nèi)容，連互聯(lián)網(wǎng)上的 API 調(diào)用都自動化了。比如以前他們覺得很復雜的廣告投放分析、SEO 優(yōu)化，現(xiàn)在直接跟 OpenClaw 或 Claude Code 聊，AI 會建議一個方案，人只需要去 Developer 網(wǎng)站把 Key 拿過來驗證一下就行。

所以他們都不需要 UI 了，基于 API 把一整套業(yè)務都跑起來了，甚至連招人都是自動化的。我有個朋友的 Stack 是：在 LinkedIn 上 Reach 200 個人，收簡歷和 Portfolio，用 AI Review 結果，再進行 AI Monitor 的面試。從 200 人篩選到 2 人的過程完全自動化，省了大量時間。

Power User 跑起來之后，你會非常 Surprise。他們一行代碼不寫，純動嘴就把我們花很多年才學會的 GitHub、前后端開發(fā)、甚至各種 Developer Tool 全都跑起來了，而且特別熟練。這個事讓我覺得非常 Surprising。

文科生，一行代碼都不會寫，但被 merge 了 9 個 PR

金融投資從業(yè)者：我是個文科生，做金融投資出身的。到現(xiàn)在為止，我仍然是一行代碼都不會寫。算是一個 Vibe Coder。

但是這兩天我開始給 OpenClaw 寫代碼，提交了十幾個 PR，然后被通過了 9 個。所以我現(xiàn)在基本上已經(jīng)是 OpenClaw 全球貢獻者里面前 50 名了。

我發(fā)現(xiàn)，正是因為我沒有技術背景，反而更依賴、也更天然地接受 AI 技術。傳統(tǒng)搞技術的朋友可能更喜歡確定性，比如輸入 1+1 必須等于 2。但 AI 編程很多時候是在「抽卡」，可能抽 10 次只有 2 次能用。這種路徑差異，可能是很多人使用 AI 的限制。

我現(xiàn)在使用 AI 的方法很簡單，依靠三個「AI 員工」組成的團隊，部署在我的 MacBook Air 和 Mac Mini 上：

• 一個首席助理，負責安排和協(xié)調(diào)所有 Agent 的工作；

• 一個 CTO，負責實際的代碼編寫；

• 一個是 CMO 或者 Social Officer，在 CTO 提交完 PR 后，它會去評論區(qū)自動尋找最近活躍的、對這個 PR 感興趣的 Maintainer，主動 @ 他們。這樣可以加快我 PR 被合并的效率。

另外還有一個「需求發(fā)現(xiàn)師」，它會 24 小時不斷在 GitHub 上尋找 Issue，分析有哪些 Issue 需要被解決，有哪些是比較重要的，有哪些是目前更可能被合并的。

大概是這樣的一個工作流，Run 起來發(fā)現(xiàn)效果是出奇的好。

04Platform Engineering，

正在成為人類工程師的核心

從 Feature Coding 到 platform engineering

飛書 OpenClaw 插件維護者：結合我現(xiàn)在在公司里面的角度，我發(fā)現(xiàn)自己做的很多工作正在逐漸往兩個方向發(fā)展，所謂的「左移」和「右移」。

以前我們可能會很強調(diào)工程師的核心能力是做 Feature Coding，但現(xiàn)在你會更注重整個 Platform Engineering 的事情。

往左移，就是在代碼合并和發(fā)布之前，你要注重比如怎么給代碼一個容器化的隔離環(huán)境，怎么讓 AI 在你約束的 SPEC 下面去編碼。

右移部分是說，在代碼合并之后，如果有問題，我要能夠 Resilience，做一些可觀測性的建設，有問題能夠回退兜底。

因為你很難保證每天寫進來的幾千、幾萬行代碼在工程上是可靠的，它可能只是「It works」。那這個時候，傳統(tǒng)的軟件開發(fā)角色就變成了一個左移和右移結合的角色，有點類似于測試開發(fā)和平臺工程師。

中間的 Feature Coding 反而變得可能沒那么重要了，因為它越來越能像 AI 一樣能全自動生成。雖然現(xiàn)在無監(jiān)督的 AI 開發(fā)還有點離譜，比如 Claude 號稱寫了個 C 編譯器，但連 Hello World 都編譯不了。但再過兩年會變成什么樣？我覺得還是有非常多工程上可以做的方式，比如從 Platform Engineering 這個角度，或者是否會有新的組織和個體去做相應的質(zhì)量控制。

比如 Linux 社區(qū)就有不同的發(fā)行版：有的像 Arch Linux 非常激進，所有東西都往里合，體驗最新代碼；有的像 Debian 強調(diào)穩(wěn)定，會人工做很多測試才發(fā)出來，這種概念可能更適合企業(yè)的場景。同時，像這樣的概念是不是會得到一些商業(yè)上的機會？我覺得也是非常有可行性的。

Agent Computer，會是一種新的硬件形態(tài)

Agent 創(chuàng)業(yè)者：我看幾位嘉賓都聊到家里有不同的小主機在部署 Agent。其實 OpenClaw 相比于 Manus、GenSpark、Happycapy，雖然產(chǎn)品形態(tài)類似都是在云端起 Docker 跑 Agent，但 OpenClaw 走向了反面，它是深度結合你本地的，比如聯(lián)動蘋果的通訊錄、備忘錄。

我覺得 OpenClaw 這一波帶火了「個人助理」的意義，它相對于云端產(chǎn)品，跟本地智能結合得更緊密。

大家討論的形態(tài)，在計算機上裝 Agent，資源主要給 Agent 用，平時不插顯示器——其實是一個新的產(chǎn)品形態(tài)。我有個朋友在做叫「Pamir AI」的項目，他們提了一個概念叫「Agent Computer」。

*Pamir AI：一個售價 250 美元、計算器大小的硬件，能 24 小時保持在線，接管重復性工作，甚至能通過物理接口，直接介入物理世界。（內(nèi)容來自晚點報道）

這就好比蘋果誕生于 PC 將出未出的時代。我們想，以后大家可能每天不需要對著幾百個軟件界面，而是每個人有 100 到 500 個 Agent 來服務他。那時，我們的硬件設備形態(tài)可能也會發(fā)生很大的改觀。

05Heartbeat 機制，

讓 OpenClaw 更像是一位長期伙伴

OpenClaw更像是一個「長周期、永遠在線、有主動性」的陪伴型伙伴

Agent 創(chuàng)業(yè)者：過去一年，我們在做 Claude Code 的開源實現(xiàn)，從我的視角來看，OpenClaw 跟過去傳統(tǒng)的 Claude Code 這種 Agent 到底有什么區(qū)別？

Claude Code 的設計中，其實也有任務持久化和記憶機制，但不是那么凸顯。你跟它的對話很像是一種臨時性的對話。打開 Terminal，聊完 Task 就結束了，Terminal 一關，很多人甚至有「上下文潔癖」，用一半就 Clear 了。

那 OpenClaw 顯然走向它的反面。你跟它聊，隨便聊，你也不知道上下文窗口用得有多滿。它不會給你顯示 Session Window 占用了多少，但你提的任務它都給你完成。這個時候顯然不可能由人來手動管理上下文，它內(nèi)部必須保持長周期的連續(xù)運轉(zhuǎn)。

我覺得這是兩個相反的設計。Claude Code 是一個更加單元型的 Agent，關心原子性任務。而 OpenClaw 其實已經(jīng)不再是一個 Chatbot 或 Chat Agent，它是一個長周期、主動的陪伴，就像你身邊的一個同事。

你不會說你跟 OpenClaw 臨時開了一個會話，你會把它當做一個長周期的伙伴，因為它的記憶是始終 Online 的，任務是始終往前推進的。而且它有Heartbeat 機制，會周期性地提醒并喚醒自己做一些后臺任務，比如做文件的整理或數(shù)據(jù)的搜集。

我覺得這是兩個項目的一些核心差異。上層的產(chǎn)品哲學、心智還是非常不同的，我覺得這也是 OpenClaw 能引爆社區(qū)的主要原因。

現(xiàn)階段，用 OpenClaw 做SaaS還蠻難的

開源社區(qū)負責人：OpenClaw 出來之后，我就試著讓它把我過去幾年的發(fā)票處理一下：我要求它分門別類，按「故事」線整理，比如這趟是北京出差，那趟是深圳出差，把發(fā)票 Group 在一起，算明白里面的稅。跟它聊，給它 OCR 工具、Vision Language Model，把 API Key 給它，讓它自己上網(wǎng)學。

結果發(fā)現(xiàn)它做得還不錯。我當時想，是不是可以讓 OpenClaw 去做一些有實際商業(yè)價值的事情？但坐下來細聊需求后，我發(fā)現(xiàn)用 OpenClaw 做SaaS還是蠻難的。

首先是成本問題。因為它實際是一個數(shù)字助理，給我個人服務很方便。但做成會計 SaaS，假設一個月收二三十塊錢，如果每個人背后都綁一個 Claude 的套餐，哪怕是 Kimi，這筆賬也是算不過來的。我沒辦法用純 AI Native 的方式去交付這個服務。

其次是權限和安全問題。我想過把它包裝成帶 API 的服務，抽象一部分控制權。但權限控制很難搞。如果放在同一個 Server 上，客戶文件之間的隔離很難做。更擔心的是，用戶跟 OpenClaw 聊著聊著，可能會誘導它改代碼——因為 OpenClaw 權限太高了，甚至能改自己的代碼。

這就引出了供應鏈安全的問題。所以我覺得供應鏈安全這個東西還挺難搞的。結合最近的 SEO，如果未來有人通過 SEO 污染了一個常用 Tool 的搜索結果，Agent 下載了帶有惡意代碼的東西，那整個安全防線就徹底崩潰了。

最后是 Consistent 的問題。它很聰明，比如說它看到我這個發(fā)票的時間點，自動把兩張發(fā)票關聯(lián)起來，說這是一個從 A 到 B 再到 C 的 Trip。但當我下次找它做同樣的事時，它很難給我一個可復現(xiàn)的、非常 Consistent 的結果。

我嘗試用 Prompt 控制它，效果都不太好。如果要把它變成一個 SaaS 服務交付給用戶，在現(xiàn)階段，那我可能還還沒有辦法完全相信這個 Agent。

06Token 稅：誰用得越多、試錯越多，

誰就越能理解 AI 的「思維模式」

Claude 4.5 Opus 之后，模型開始進化到「可用」的狀態(tài)了

基模公司核心工程師：直到半年之前，我覺得我還是一個「古法編程愛好者」。在那之前，其實我對模型是屬于完全不信任的狀態(tài)，不管是當時的 GPT-3.5 還是 4，我都試過，這東西沒辦法去解決在真實工程中看到的各種問題。

什么時候我的思維開始動搖了？其實是從 Claude 4.5 Opus 出來之后。在它之后，我明顯地能感知到一件事情，就是模型從我的視角下的「不可用」已經(jīng)進化到一個「可用」的狀態(tài)了。

因為我是古法編程，我真的很地道地把 OpenClaw 當時版本下的所有的代碼都讀了一遍。其實 OpenClaw 整體的架構并沒有超出設計的范疇，從頭拆解起來其實就三個東西：模型、Loop、Tool。

業(yè)界最近在探索一種新的 Agent 使用方式，叫 Proactive Agent。我的第一反應是這東西不就是把 ReAct 變成了后端熟悉的 Cron Job，不斷輪詢嗎？

如果真要做 Proactive Agent，我覺得最重要的因素是記憶。之前 Manus 爆火時我也猜測過它的記憶機制。后來逆向 Claude Code 發(fā)現(xiàn)，其實沒有什么黑魔法，其實就兩件事情：一是通過標注把所有代碼執(zhí)行一遍；二是在 Tool 上做了很多雕花工作，System Prompt，告訴它當前的執(zhí)行過程。僅僅靠這點東西就形成了魔法。

這件事情其實對我本身的沖擊有點大，因為它跟一個工程師的直覺是非常非常反過來的。工程師覺得我得知道一件事情到底是為什么，我才去用。但實際上這一波的模型能力迭代真的有一個分界線，可能就是 Claude 4.5 Opus 之后，模型在 Coding 領域真的從玩具的狀態(tài)變成了生產(chǎn)級可用。

「Token 稅」，是 Vibe Coding 時代的經(jīng)驗條基模公司核心工程師：最近感觸最大的是聽了翁家翌的采訪，里面有一句很重要的話：環(huán)境的穩(wěn)定性，或者叫迭代的速度，直接決定了當前模型能夠進化的效率。

大家覺得模型訓練是黑魔法，只要有神算法和神數(shù)據(jù)就行。但實際上，真正的算法研究員 90% 的時間都在「揉數(shù)據(jù)」，揉數(shù)據(jù)決定了能產(chǎn)生多少高質(zhì)量軌跡供模型學習。這需要快速試錯，像抽卡一樣，一旦抽中 SSR，就可以無限復制當前的所有軌跡。

這其實也是現(xiàn)在模型訓練中的一個最核心的點，就是把一切可被 Scalable 的事情作為第一性原理。

我現(xiàn)在重新反思，如果現(xiàn)在再去做應用的話，可能需要犧牲掉一部分「解耦」的執(zhí)念。實際上，你給模型一個完全可供自己探索的環(huán)境，讓它燒 Token 去試，直到發(fā)現(xiàn)一條路徑是模型一定能走對的時候，這條認知就變成了你自己的能力。

所以，這個時代有一個很嚴肅的問題，叫做「Token 稅」。就是誰用的 Token 越多，誰對于這個東西感知越多，誰能更理解所謂的模型的 AI Native 思維。

包括 OpenClaw 該怎么用？我覺得這件事情其實可能會有一個無聊的廢話，但是很正確的答案就是「試」，你不斷地試，找到一個它真的能夠幫你做哪一件事情，然后在這個過程中再去找那個軌跡，到底什么東西是對的。

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