OpenClaw 走紅背后：Agent、AI Coding 與團隊協(xié)作的新問題

作者 | QCon 全球軟件開發(fā)大會

策劃 | 羅燕珊

編輯 | 宇琪

2026 年，圍繞 OpenClaw 的討論，已經(jīng)不只是“一個新 Agent 工具火了”這么簡單。

一方面，它因能夠打通聊天工具、桌面環(huán)境與技能系統(tǒng)，讓用戶通過對話驅(qū)動電腦持續(xù)執(zhí)行任務(wù)，而迅速出圈；另一方面，圍繞它的爭議也幾乎同步出現(xiàn)：它到底是新一代 Agent 產(chǎn)品的雛形，還是又一個被過度放大的技術(shù)概念？它真的是普通用戶也能上手的低門檻工具嗎？當(dāng)越來越多團隊開始把它與 AI Coding、SPEC Driven、團隊協(xié)作流程放在一起討論時，問題也隨之變得更具體了——Agent 能否真正進入研發(fā)流程？AI 寫代碼的邊界到底在哪里？團隊又該如何在效率和可控之間找到平衡？

近日 InfoQ《極客有約》X QCon 直播欄目特別邀請到淘寶閃購高級技術(shù)專家鄧立山、網(wǎng)易 CodeWave 業(yè)務(wù)中心技術(shù)負(fù)責(zé)人姜天意、平安科技高級專家工程師褚秋實一起，在QCon全球軟件開發(fā)大會·2026 北京站即將召開之際，圍繞 OpenClaw 的爆火、實際使用體驗、能力邊界、安全風(fēng)險，以及 AI Coding 在團隊中的落地方式展開了持續(xù)討論。

部分精彩觀點如下：

• OpenClaw 并不像許多公眾號描述的那樣是一個“低門檻”產(chǎn)品。要真正用好它，需要熟悉 JSON 配置、具備排障能力，并持續(xù)調(diào)試和優(yōu)化 skill，對普通用戶仍存在相當(dāng)門檻。

• 在需求理解階段通過 SPEC 將需求結(jié)構(gòu)化，再通過 task 和 architecture 轉(zhuǎn)化為技術(shù)設(shè)計，供架構(gòu)師評審技術(shù)棧、方案和接口是否合理，之后再進入 plan 階段逐步執(zhí)行，這樣可以在一定程度上保證 AI coding 在可控框架內(nèi)落地。

• 未來程序員編寫規(guī)范和設(shè)計架構(gòu)比編寫具體代碼更有價值，具體實現(xiàn)則交給 AI 完成。

• 要想真正放飛效率，必須先打好基礎(chǔ)；在開發(fā)過程中，不僅要完成業(yè)務(wù)功能，還要為代碼庫留下知識和規(guī)范。

在 4 月 16-18 日將于北京舉辦的 QCon 全球軟件開發(fā)大會 · 2026 北京站 上，我們特別設(shè)置了 【Coding Agent 驅(qū)動的研發(fā)新范式】 專題。該專題將探討 Coding Agent 在需求理解、代碼生成、測試修復(fù)與協(xié)作流程中的工程實踐，以及對研發(fā)工作流、工程效率與研發(fā)組織方式帶來的變化。

查看大會日程解鎖更多精彩內(nèi)容：

https://qcon.infoq.cn/2026/beijing/schedule

完整直播回放可查看：

https://www.infoq.cn/video/21qReTQmsHdckEC9ZuPZ?utm_source=home_video&utm_medium=article

以下內(nèi)容基于直播討論整理，經(jīng) InfoQ 刪減。

OpenClaw 為什么會
在這個時間點出現(xiàn)

鄧立山：最近 OpenClaw 很火，大家第一次聽到或看到 OpenClaw 的時候，第一判斷是什么？

姜天意：OpenClaw 與 Manus 的出現(xiàn)有其相似性，這類產(chǎn)品并非突然涌現(xiàn)，而是技術(shù)能力達到某個閾值后的自然結(jié)果。以 Manus 為例，早在 2023 年，OpenAI 就已較為清晰地提出了 agent 的工具使用、memory 和 context 等關(guān)鍵概念；2024 年 9 月，工具使用能力逐漸成熟，MCP 隨之出現(xiàn)；2025 年年中，大上下文窗口模型開始普及，類似 Manus 的產(chǎn)品才真正落地。OpenClaw 的情況類似，它趕上了大模型能力快速發(fā)展的浪潮。其核心能力之一是靈活編寫 skill，通過編碼持續(xù)擴展智能體能力。從技術(shù)角度看，它有效利用了 Claude Code 4.6 的長上下文能力，以及 Programmatic Tool Calling (PTC)（

https://www.anthropic.com/engineering/advanced-tool-use

未來還會出現(xiàn)類似 OpenClaw 的產(chǎn)品，它代表的是一種“product–technology fit”趨勢——當(dāng)技術(shù)能力與產(chǎn)品形態(tài)真正契合時，這類產(chǎn)品就會應(yīng)運而生。從產(chǎn)品角度看，OpenClaw 迅速走紅，很大程度上是因為它滿足了特定用戶群體的需求：多渠道信息收集、數(shù)據(jù)分析、自動發(fā)帖的 Bot 操作，以及運維和信息聚合能力，高度契合自媒體從業(yè)者、一人公司和獨立開發(fā)者的使用場景。

Desktop agent 和 Remote agent 在很多公司已有實踐。例如 Anthropic 的 Cowork 較早提出了 Desktop agent 的概念，此后阿里的 QoderWork、騰訊的 Workbody，以及 Minimax 的 Minimax Desktop Agent 也均屬于桌面 Agent。

OpenClaw 的創(chuàng)新在于抓住了一個關(guān)鍵痛點：將桌面 Agent 與聊天工具打通。它通過 channel 網(wǎng)關(guān)等機制連接不同渠道，用戶只需開箱即用的配置便可快速建立通信通道，通過聊天工具驅(qū)動 Agent 執(zhí)行任務(wù)。

褚秋實：我最初是在春節(jié)期間注意到 OpenClaw 的。當(dāng)時看到同事在朋友圈曬 Mac mini，稱其為“養(yǎng)蝦”，他通過 IM 聊天工具與龍蝦持續(xù)對話，讓它每十分鐘匯報一次任務(wù)進度。我的第一感受是，這是一個面向 ToC 用戶的工具，開放了 computer use 的權(quán)限，使用戶可以通過聊天工具驅(qū)動電腦執(zhí)行各種操作。

我最先關(guān)注的是它如何實現(xiàn)長時間持續(xù)執(zhí)行任務(wù)，關(guān)鍵在于它能夠持續(xù)形成長期記憶：通過不斷讓 AI 記錄并迭代筆記，避免上下文窗口耗盡。只要電腦保持開啟，任務(wù)就可以持續(xù)執(zhí)行。這種工程設(shè)計值得借鑒，本質(zhì)上是將前人經(jīng)驗與新的模型能力整合而成的集大成產(chǎn)品。

春節(jié)后，我們公司也開始嘗試類似實踐，出于合規(guī)考慮傾向通過云桌面部署。我們發(fā)現(xiàn)，直接讓 AI 修改代碼往往不夠準(zhǔn)確，且可能直接提交到分支，給代碼合并和審查帶來問題。因此我們換了一種方式：不讓 AI 直接改代碼，而是讓它生成設(shè)計文檔級別的修改方案。這份文檔詳細(xì)列出每一步代碼修改，但不實際執(zhí)行，同時生成可視化的 HTML 報告，將所有需要修改的代碼片段整理出來，通過郵件發(fā)送給我。我打開報告后，可以逐條勾選需要采用的片段。

我們驚訝地發(fā)現(xiàn)，約有 60% 的代碼片段可以直接使用。勾選后將其復(fù)制到 IDE 的 AI 工具或 CLI 工具中，讓模型基于這些較可靠的片段繼續(xù)生成完整代碼，準(zhǔn)確率非常高。

我們認(rèn)為這可能會成為一種新的開發(fā)模式：在版本開始時，將整個版本需求交給 Agent，讓它先生成草稿。如果項目已有較完整的規(guī)范和文檔，輸入業(yè)務(wù)需求后，Agent 可生成包含大量代碼片段的設(shè)計方案，其中 70%—80% 可直接使用。開發(fā)人員只需篩選調(diào)整，便能快速完成開發(fā)，相當(dāng)于將 AI 編程轉(zhuǎn)化為更精細(xì)化的人機協(xié)作。

還有一個典型場景：我每天需要花約一小時查看研發(fā)平臺上各個 CI/CD 流水線的狀態(tài)和項目進展。未來或許可以讓 Agent 在上班前自動整理這些信息，生成報告或提示關(guān)注點。在研發(fā)管理中，這類應(yīng)用場景其實非常多。

鄧立山：現(xiàn)在的情況有點像 ChatGPT 剛出現(xiàn)時，當(dāng)時有很多關(guān)于它取代各類職業(yè)的討論，但真正使用后會發(fā)現(xiàn)仍存在不少問題和門檻。

褚秋實：它的 Token 消耗其實相當(dāng)大。還有一個典型的踩坑案例。我曾讓 AI 通過 Chrome Use 打開瀏覽器，分析某個頁面加載了哪些接口。但由于指令不夠清晰，AI 將其理解為需要研究這些 API 的作用，隨即直接調(diào)用了這些接口。其中有些是刪除接口，最終把我在評論平臺上的評論全部刪除了。

鄧立山：外網(wǎng)上也有類似案例，用戶讓 Agent 幫自己處理工作，結(jié)果它把電腦上的所有數(shù)據(jù)都刪除了。

褚秋實：所以很多人會專門找一臺舊電腦或購置一臺 Mac mini 來運行這些 Agent。

姜天意：在我們的實踐中，OpenClaw 的穩(wěn)定性管理非常重要。它的配置文件并不穩(wěn)定，一旦重啟，JSON 配置可能被自動修改甚至損壞，因此我搭建了一個大龍蝦定期做探針檢查并自動備份配置文件。此外，瀏覽器訪問的穩(wěn)定性也有待提升。針對 Token 消耗問題，我引入了新的記憶系統(tǒng)，參考字節(jié)的 OpenViking 方案，通過文件方式管理記憶，從而顯著減少 Token 消耗，原本只有一個 memory.md 和一個塞滿信息的 context，改造后效果明顯改善。

因此，OpenClaw 并不像許多公眾號描述的那樣是一個低門檻產(chǎn)品。要真正用好它，需要熟悉 JSON 配置、具備排障能力，并持續(xù)調(diào)試和優(yōu)化 skill，對普通用戶仍存在相當(dāng)門檻。

鄧立山：我第一次了解 OpenClaw 是看到一篇文章，稱有 150 萬個 agent 涌入一個由 agent 自主發(fā)起的社區(qū)，人類無法參與討論只能旁觀，這促使我進一步研究了它的技術(shù)棧和原理。它不僅自己規(guī)劃流程執(zhí)行任務(wù)，還能進行反思和迭代。例如當(dāng)缺少某項技能時，它會主動在網(wǎng)上收集資料，為自己編寫新的規(guī)范和技能，最終完成任務(wù)。這對編程工作也很有啟發(fā)，代碼完成后，可以借助這種反思模式讓 AI 持續(xù)檢查代碼質(zhì)量和測試用例并不斷修正。

褚秋實：目前還有一個問題：如何將這些能力轉(zhuǎn)化為團隊層面的共享記憶。現(xiàn)在很多使用方式仍停留在個人層面，但在團隊開發(fā)項目中，成員使用 Agent 過程中積累的推理經(jīng)驗本應(yīng)能夠共享。OpenClaw 目前通過 MD 文件存儲記憶，如何在企業(yè)環(huán)境中打通這些記憶，是一個值得思考的問題。

姜天意：它的核心思想是 Programmatic Tool Calling (PTC)，用代碼描述整個工作流程。遇到無法解決的問題時，它會自己生成 Python 腳本并在沙盒中運行，從而解決很多通過 MCP 或傳統(tǒng) tool calling 難以處理的問題。MCP 工具的注冊和開發(fā)本身有一定門檻，而通過 skill 實現(xiàn) Programmatic Tool Calling (PTC)，很多事情可以自動完成，甚至 MCP 調(diào)用代碼本身也可以由大模型生成并執(zhí)行。因此，OpenClaw 的關(guān)鍵在于：一個好的架構(gòu)理念，加上 Claude 這樣強大的編碼模型。

褚秋實：那是否意味著 coding agent、辦公 agent 等都可以作為它的下層，成為細(xì)分領(lǐng)域的專業(yè) agent？

姜天意：它的架構(gòu)是這樣的：核心只有一個名為 Pi 的智能體，相比 Claude Code 的 Coding 智能體更為輕量，只保留記憶檢索和 tool calling 等能力。在此之上搭建一個網(wǎng)關(guān)，接收不同渠道的請求并轉(zhuǎn)發(fā)給 Pi，具體能力則全部沉淀在 skill 工具中。這種架構(gòu)擴展性較強，而核心保持輕量。

褚秋實：那還需要 Claude Code 或 Gemini CLI 嗎？是用龍蝦調(diào)用這些工具，還是龍蝦加上好模型就可以替代這些 coding agent？

姜天意：兩種方式都可行。例如我們有一只龍蝦專門負(fù)責(zé)插件開發(fā)，它將 Claude Code 作為一個 skill 注冊到 Pi 上。我們發(fā)現(xiàn)，如果 Pi 接入強模型，不僅能生成 Python 腳本，任務(wù)拆解和理解能力也更強，相比之下部分國產(chǎn)模型稍弱。因此理想情況下，既需要優(yōu)秀的編碼模型，也需要規(guī)劃能力強的模型。規(guī)劃能力不足時，可以用規(guī)劃能力較強的模型（如 Minimax 或 Kimi K2.5）作為 fallback，編碼階段再接入 Claude Code。

褚秋實：以前我們用 LangChain 或 CrewAI 這樣的 agent 框架搭建多 agent 或 workflow，未來這些是否也會變成 skill 被整合進 OpenClaw？

鄧立山：我認(rèn)為是可以的。skill 是動態(tài)加載的，只需要用 MD 文件描述清楚，需要時便會自動檢索并加載。OpenClaw 目前的運作方式也是如此：需要某項技能時，它會到 skill 市場檢索并安裝，然后執(zhí)行相應(yīng)任務(wù)。

AI Coding 最大的問題，
不是生成，而是可控

鄧立山：2026 年了，AI Coding 最大的真問題是什么？

姜天意：核心問題在于 AI 生成代碼的不穩(wěn)定與不可控。主要體現(xiàn)在以下幾個方面：一是幻覺問題，AI 對需求的理解容易出現(xiàn)偏差，自然語言本身具有模糊性，對人尚且如此，對 AI 歧義更多；二是生成的技術(shù)棧與團隊現(xiàn)有技術(shù)棧不一致，很多模型在訓(xùn)練時主要使用國外主流技術(shù)棧（如 Next.js、Tailwind CSS），對企業(yè)內(nèi)部私有框架或定制庫支持較弱，強行引導(dǎo)也難以完全貼合團隊技術(shù)體系；三是 AI 生成代碼的可維護性較差。當(dāng)前階段，很多團隊在大規(guī)模使用 AI coding 后，逐漸不再認(rèn)真閱讀 AI 寫出的代碼，往往只要功能達到預(yù)期便通過。但我認(rèn)為更重要的是結(jié)果驅(qū)動（RDD），必須通過完善的測試用例在結(jié)果層面驗證各種 case，才能真正判斷 AI 生成代碼的可靠性。

舉個典型例子：我們曾嘗試開發(fā)一個在線截圖工具，按常規(guī)思路只需啟動無頭瀏覽器執(zhí)行截圖即可。但 AI 直接用 curl 請求調(diào)用了第三方截圖 API，功能雖然實現(xiàn)了，卻完全不是我們想要的方案。這正是 AI coding 中技術(shù)方案不可控的典型體現(xiàn)。SPEC driven 方法的價值就在于此：在需求理解階段通過 SPEC 將需求結(jié)構(gòu)化，再通過 design 和 architecture 轉(zhuǎn)化為技術(shù)設(shè)計，供架構(gòu)師評審技術(shù)棧、方案和接口是否合理，之后再進入 plan 階段逐步執(zhí)行，這樣可以在一定程度上保證 AI coding 在可控框架內(nèi)落地。

褚秋實：AI 的代碼輸出速度極快，但軟件開發(fā)本質(zhì)上是一個從模糊到清晰的過程，需要不斷與業(yè)務(wù)方確認(rèn)并持續(xù)迭代。目前最困擾我的是，AI 很難在業(yè)務(wù)功能層面遵循一套清晰的規(guī)則。在技術(shù)規(guī)范方面，我們可以結(jié)合 CI/CD 工具以及 ArchUnit、PMD 等工具，將原本存在于 Markdown 文檔中的規(guī)范轉(zhuǎn)化為可執(zhí)行的規(guī)則；代碼一旦違反，便能明確指出問題來源，AI 在修復(fù)通用問題或代碼缺陷方面的自愈能力也較為有效。這樣，項目的開發(fā)架構(gòu)就能從無形的規(guī)范轉(zhuǎn)變?yōu)楣ぞ呋⒖蓹z測、可約束的體系。

但在業(yè)務(wù)功能層面就復(fù)雜得多。即使使用 Given–When–Then 的驗收條件，讓 AI 自行檢查時也未必可靠，它往往認(rèn)為自己已經(jīng)按照描述完成了實現(xiàn)。因此，開發(fā)人員仍需進行集成測試，這一環(huán)節(jié)目前依然是比較困難的部分。

一個關(guān)鍵問題是：如何將“什么是正確的需求實現(xiàn)”轉(zhuǎn)化為 AI 可驗證的形式？如果采用多 Agent 模式，分別負(fù)責(zé)開發(fā)、設(shè)計和檢查的 Agent 通過互相博弈發(fā)現(xiàn)問題，那么需求描述方式就變得至關(guān)重要，如何表達需求才能讓負(fù)責(zé)檢查的 AI 更容易發(fā)現(xiàn)問題？目前的困境在于：讓單個 AI 在提示詞中按照規(guī)范進行自檢，它往往非常自信地認(rèn)為沒有違反規(guī)則；但當(dāng)人指出具體問題后，它又會承認(rèn)確實違反了規(guī)范，這說明當(dāng)前體系很難形成真正的閉環(huán)。

鄧立山：質(zhì)量問題是我們目前面臨的最大挑戰(zhàn)，主要從兩方面進行約束：一是提升 AI 對需求的理解，二是規(guī)范代碼生成過程。首先要確保 AI 正確理解需求，AI 本質(zhì)上是基于概率推斷，輸入語料越準(zhǔn)確、結(jié)構(gòu)越清晰，推斷結(jié)果就越可靠。

在代碼生成階段，我們結(jié)合團隊研發(fā)經(jīng)驗制定了相應(yīng)規(guī)范，要求 AI 先理解文檔中的業(yè)務(wù)邏輯，再根據(jù)規(guī)范約束進行編碼。質(zhì)量檢查則從多個維度進行：最重要的是確保代碼實現(xiàn)與業(yè)務(wù)邏輯一致，此外還需關(guān)注可維護性、代碼設(shè)計質(zhì)量，以及是否存在性能隱患或安全問題，這些規(guī)范可以逐漸沉淀到整個研發(fā)體系中。

這與 OpenClaw 的啟發(fā)類似，從規(guī)劃、執(zhí)行到反思，再到下一輪執(zhí)行，形成閉環(huán)。在編碼過程中，可以讓一個模型生成代碼，另一個模型負(fù)責(zé)審核。由于是不同模型進行檢查，往往能發(fā)現(xiàn)更多問題，而不會陷入自認(rèn)為沒有問題的困境。

褚秋實：至少要用新的會話，即獨立的上下文窗口來進行檢查。

姜天意：很多傳統(tǒng)軟件工程方法在 AI 時代反而更具價值。例如 BDD 可以在需求階段就定義測試行為，使測試盡可能前移；SPEC driven 方法也可以通過 SPEC 自動生成 TDD 測試。AI 出現(xiàn)之前，開發(fā)人員通常不太愿意編寫測試用例；而現(xiàn)在，TDD、BDD 等工作可以交由 AI 完成，這對開發(fā)流程是很大的利好。

褚秋實：不過 TDD 的核心不僅是寫測試，而是設(shè)計能力，要求開發(fā)者在實現(xiàn)功能之前思考需求如何抽象、職責(zé)如何劃分，以及如何讓代碼變得可測試。很多人習(xí)慣在 service 里不斷堆疊邏輯，如果代碼本身不可測試，再好的工具也難以發(fā)揮作用。

在 AI 時代，如果能夠采用更正交化的設(shè)計方式，明確每個職責(zé)，新增功能時只需創(chuàng)建新的類或業(yè)務(wù)概念并在舊代碼中加入一個調(diào)用點，再結(jié)合 AI 自動生成代碼、TDD 測試保障以及規(guī)范化的代碼規(guī)則，就能在一定程度上控制技術(shù)債務(wù)、提升整體代碼質(zhì)量。

鄧立山：大家都在走向規(guī)范化編碼的方向。值得一提的是，據(jù)說 OpenClaw 的創(chuàng)作者 Peter 幾乎完全借助 AI 完成了整個項目的開發(fā)，后來他表示自己基本不再閱讀代碼，主要關(guān)注 AI 編碼過程中遵循的規(guī)范文檔。未來程序員編寫規(guī)范和設(shè)計架構(gòu)比編寫具體代碼更有價值，具體實現(xiàn)則交給 AI 完成。

褚秋實：過去很多系統(tǒng)在應(yīng)用架構(gòu)層面往往做得不錯，但開發(fā)架構(gòu)層面卻缺乏重視，功能運行正常，代碼結(jié)構(gòu)卻混亂。在這種情況下引入 AI，風(fēng)險其實更大。因為大模型是直接基于代碼庫生成代碼，如果代碼庫結(jié)構(gòu)混亂，AI 就很難遵循統(tǒng)一規(guī)范，甚至連規(guī)范本身都難以制定。因此在 AI 時代，代碼組織方式和結(jié)構(gòu)一致性的重要性會被進一步放大。如果原本已有清晰規(guī)范，只需將其轉(zhuǎn)化為 AI 可理解的形式，讓 AI 與開發(fā)者共同遵守即可。但現(xiàn)實中很多企業(yè)存在大量歷史遺留系統(tǒng)，結(jié)構(gòu)復(fù)雜、規(guī)范不統(tǒng)一，推進這類改造仍具有相當(dāng)難度。

姜天意：關(guān)于如何避免需求理解偏差，我們團隊使用了 EARS 規(guī)則（Easy Approach to Requirements Syntax）。這是軟件工程中一種需求描述方法，最早在航空航天領(lǐng)域使用，能夠清晰描述需求中的 when、how、where 等條件。

2025 年 Amazon Kiro 將 EARS 引入 SPEC driven 方法中。其核心思想是，無論用戶提交的是口頭需求還是 PRD 文檔，都先通過 EARS 規(guī)則將其轉(zhuǎn)化為標(biāo)準(zhǔn)化需求描述，既能幫助人類消除歧義，也能幫助 AI 更準(zhǔn)確地理解需求。例如 PRD 中一句“登錄需要驗證”，通過 EARS 可以細(xì)化為：在何種情況下驗證、是彈窗提示還是等待多少時間等。這樣產(chǎn)品經(jīng)理與程序員可以雙向確認(rèn)，AI 理解也更準(zhǔn)確。在 SPEC driven 的實踐中，使用 EARS 編寫 SPEC 是非常有效的方法。

褚秋實：我們也在嘗試使用 EARS，例如用“當(dāng)……發(fā)生時，系統(tǒng)應(yīng)當(dāng)……”這種結(jié)構(gòu)化方式表達需求，將需求實例化并以統(tǒng)一格式約束需求文檔。我認(rèn)為，當(dāng)需求文檔質(zhì)量提升后，代碼生成和自動生成測試用例都會順暢很多。如果只在開發(fā)后半段發(fā)力，而需求源頭質(zhì)量很差，整個流程都會舉步維艱。

團隊怎么落地：
SPEC、Vibe 和護欄

鄧立山：哪些場景可以 Vibe，哪些必須先 SPEC？你們怎么定強制門檻？

姜天意：SPEC driven 是一種比較正規(guī)的 AI coding 方法。如果需求本身具有探索性，例如在嘗試新想法或新產(chǎn)品，可以使用 Vibe Coding，Cursor、Claude Code、Trae 等工具都適合在需求不確定的情況下通過不斷試錯來探索方案。但如果需求已經(jīng)明確，例如存在 PRD、團隊技術(shù)棧有明確要求，并且需要對最終結(jié)果負(fù)責(zé)，則不建議直接使用 Vibe Coding，而應(yīng)先采用 SPEC driven 或類似方法，將需求轉(zhuǎn)化為 SPEC 再進行設(shè)計與開發(fā)。

即便覺得 SPEC driven 流程較為復(fù)雜，也至少應(yīng)該先寫一個詳細(xì)的開發(fā)計劃，例如在 Claude Code 的 plan mode 中或以 plan.md 的形式將開發(fā)步驟明確列出，經(jīng)人工審核后再讓 AI 執(zhí)行。此外必須以結(jié)果為導(dǎo)向，既然很多開發(fā)者不愿意寫測試用例，就應(yīng)該讓 AI 大規(guī)模生成測試用例，例如根據(jù) SPEC 的 feature 自動生成 E2E 測試，并讓 AI 在 CI/CD 流程中執(zhí)行，以驗證 AI coding 的結(jié)果。

褚秋實：也可以從復(fù)雜度和精度要求兩個維度來判斷。高復(fù)雜度且高精度要求的生產(chǎn)級業(yè)務(wù)系統(tǒng)，如果需要長期維護，使用 Vibe Coding 風(fēng)險很高，AI 時代技術(shù)債務(wù)的累積速度會被放大，這類場景更適合規(guī)范化流程。如果復(fù)雜度高但精度要求低，例如探索性原型項目或一次性的個人工具，在可控范圍內(nèi)使用 Vibe Coding 是合理的。

目前我們團隊在實踐中，很多人會用 Vibe Coding 開發(fā)內(nèi)部小工具，用 Go、Python 等語言快速解決臨時需求，這類場景是有價值的。

鄧立山：Vibe Coding 剛出現(xiàn)時大家都覺得很驚艷，即便是不懂技術(shù)的人也能快速生成網(wǎng)站或應(yīng)用。但隨后也出現(xiàn)了很多吐槽，例如后期需要修改功能時發(fā)現(xiàn)代碼難以維護。

如果只是開發(fā) demo 或做技術(shù)探索，可以先用 Vibe Coding 生成初始版本，再通過 SPEC 模式讓 AI 實現(xiàn)最終版本。對于需要長期維護的生產(chǎn)系統(tǒng)，更建議使用 SPEC Driven 方法，并在過程中制定清晰的需求分析規(guī)范、架構(gòu)規(guī)范和編碼規(guī)范，從而生成質(zhì)量更高、可長期維護的代碼。

姜天意：團隊決策者需要具備判斷能力，能夠根據(jù)應(yīng)用規(guī)模、復(fù)雜度和風(fēng)險來確定 AI 生成代碼的邊界，以及如何驗證生成結(jié)果。否則可能出現(xiàn)這樣的問題：過去是人類開發(fā)者制造屎山代碼，現(xiàn)在則變成 AI 批量制造屎山代碼。

褚秋實：第一批 Vibe Coding 的受害者已經(jīng)出現(xiàn)，他們需要招聘氛圍編程代碼修復(fù)師（Vibe Code Fixer）來修復(fù)這些代碼，甚至被戲稱為 Vibe Coding 治療師。Vibe Coding 可以快速做出能運行的東西，但穩(wěn)定性、魯棒性、可維護性等非功能性需求往往并沒有得到保障。

鄧立山：說到 SPEC，就必然會落到 review 和責(zé)任。那 AI 寫的代碼，review 重點是什么？責(zé)任怎么落？有沒有必須人類拍板的紅線？

姜天意：SPEC driven 模式反而更適合多團隊協(xié)作。在 PRD 編寫階段，可以先由 AI agent 生成初稿并轉(zhuǎn)換為標(biāo)準(zhǔn) SPEC 文檔，但產(chǎn)品經(jīng)理不能退出流程，需要參與 SPEC 評審，與研發(fā)一起確認(rèn)模塊劃分是否合理，避免過度設(shè)計。架構(gòu)設(shè)計階段需要技術(shù)架構(gòu)師參與，評估技術(shù)棧是否合理、模型設(shè)計是否恰當(dāng)、接口是否冗余、數(shù)據(jù)庫表結(jié)構(gòu)是否合理，以及系統(tǒng)是否具備高可用策略和必要的兜底機制，架構(gòu)設(shè)計充分評審后開發(fā)才可以繼續(xù)推進。在 plan 階段，一線研發(fā)需要特別關(guān)注結(jié)果的可驗證性，很多 SPEC driven 工具支持從 SPEC 自動生成測試用例，因此在執(zhí)行 SPEC 時一定不要省略這一步，應(yīng)基于 SPEC 生成 TDD 用例并在 CI/CD pipeline 中執(zhí)行。

褚秋實：在 SPEC SDD 這些概念出現(xiàn)之前，我們已經(jīng)做過類似實踐：在工程中寫大量針對具體問題的 Markdown 文檔，每個文檔只聚焦一個問題，說明背景、要求和目標(biāo)效果；再由工程師手動將需求拆解為技術(shù)任務(wù)，寫成提示詞讓 AI 生成代碼，這樣可以顯著提高準(zhǔn)確率。后來看到 OpenSpec 這類框架，才意識到它提供了一套完整流程：先提出 proposal，生成 task，執(zhí)行 apply，最后歸檔。

歸檔非常重要，如果某次對話成功解決了問題，應(yīng)該把這次高質(zhì)量的解決方案總結(jié)成 Markdown 文檔加以沉淀。這樣不僅技術(shù)規(guī)范可以積累，業(yè)務(wù)模塊層面的知識也可以逐漸豐富。第一次開發(fā)某個功能時可能需要大量人機協(xié)作，但當(dāng)這些經(jīng)驗被歸檔后，下次開發(fā)類似功能時 AI 的準(zhǔn)確率就會明顯提高。隨著規(guī)范積累到一定程度，規(guī)范驅(qū)動開發(fā)也會逐漸呈現(xiàn)出類似 Vibe Coding 的效率體驗。

鄧立山：無論采用哪種方式，代碼質(zhì)量最終都需要由人來負(fù)責(zé)。AI 代碼 review 的重點主要有幾個方面：一是檢查功能實現(xiàn)與原始需求是否一致；二是評估是否符合既定架構(gòu)設(shè)計，保證代碼的長期可維護性；三是重點關(guān)注代碼質(zhì)量，例如性能、安全和并發(fā)處理等。如果 AI 寫錯了代碼，責(zé)任仍然在開發(fā)者。AI 是為我們服務(wù)的工具，人始終是代碼質(zhì)量的第一責(zé)任人。

鄧立山：要做到可控而不是放飛，大家團隊里認(rèn)為最有效的 3 條護欄是什么？

姜天意：首先是需求層面的控制，需要通過需求標(biāo)準(zhǔn)化來實現(xiàn)，例如將需求轉(zhuǎn)化為 EARS，或通過智能體將其轉(zhuǎn)換為團隊標(biāo)準(zhǔn)的需求文檔，保證需求質(zhì)量和協(xié)作效率。其次是避免生成結(jié)果失控，關(guān)鍵手段是 TDD，盡量讓 AI 自動生成測試用例，無論是基于 SPEC 還是基于現(xiàn)有代碼，測試流程不能省略，至少應(yīng)在 CI/CD 流程中執(zhí)行。第三，不同成員使用的 AI 工具規(guī)范不統(tǒng)一同樣會導(dǎo)致結(jié)果失控，因此需要制定統(tǒng)一的 Skills、Lint 規(guī)則、CI 規(guī)則以及 Constitution 等約束機制，保證團隊產(chǎn)出的穩(wěn)定性。

褚秋實：如果希望開發(fā)過程保持一定的 Vibe 感，前提是先把規(guī)范體系建設(shè)好。例如將規(guī)范文檔、代碼標(biāo)注等放在代碼倉庫中，并在開發(fā)過程中讓 AI 持續(xù)總結(jié)每個模塊，逐漸形成樹狀結(jié)構(gòu)的知識體系，使代碼庫本身變得智能。我們現(xiàn)在還讓 AI 對歷史代碼進行總結(jié)，例如通過 RepoMix 等方式壓縮和分析倉庫內(nèi)容，自動生成與代碼庫匹配的規(guī)范，使新生成的代碼至少能保持與現(xiàn)有代碼一致的風(fēng)格。要想真正放飛效率，必須先打好基礎(chǔ)；在開發(fā)過程中，不僅要完成業(yè)務(wù)功能，還要為代碼庫留下知識和規(guī)范。

鄧立山：代碼 CR 和 TDD 在這個過程中都非常重要。可以用 A 模型生成代碼，再用 B 模型進行評審，相當(dāng)于交叉檢查，能發(fā)現(xiàn)更多問題。此外，傳統(tǒng)研發(fā)的三板斧仍然非常重要：可監(jiān)控、可灰度、可回滾，上線前做好充分監(jiān)控，發(fā)布時采用小步灰度，持續(xù)觀察系統(tǒng)狀態(tài)，發(fā)現(xiàn)問題及時回滾。

鄧立山：往后 6–12 個月大家覺得 AI Coding 最可能出現(xiàn)的拐點是什么？會先在什么環(huán)節(jié)發(fā)生？

姜天意：第一是多模態(tài)能力的提升，目前無論是圖像識別準(zhǔn)確率，還是對復(fù)雜文檔的理解能力，都仍有提升空間，這可能成為一個重要拐點。第二是 Context 與 Codebase 的處理方式變化。過去由于上下文窗口較小，Cursor、Windsurf 等工具通常需要先將代碼向量化再通過向量搜索找到相關(guān)片段；而 Claude Code 一開始就采用了直接通過 GREP 搜索并將代碼放入上下文的方式。隨著上下文窗口不斷擴大，這種方式可能逐漸成為主流，傳統(tǒng)向量檢索方式可能逐漸被淘汰。第三是代碼生成能力在底層領(lǐng)域的突破，例如驅(qū)動開發(fā)、系統(tǒng)編程或 Rust 代碼生成。如果 AI 能夠在這些領(lǐng)域取得進展，甚至實現(xiàn)跨平臺驅(qū)動自動適配，將對整個產(chǎn)業(yè)產(chǎn)生顛覆性影響。

褚秋實：目前大部分應(yīng)用仍然是為人設(shè)計的，前端界面中的交互細(xì)節(jié)即使有規(guī)范驅(qū)動，通過自然語言描述也可能存在偏差。但如果未來應(yīng)用形態(tài)發(fā)生變化，AI 原生應(yīng)用大量出現(xiàn)，應(yīng)用可能只需要一個超級框架，功能封裝為 skills，AI 既負(fù)責(zé)開發(fā)又負(fù)責(zé)調(diào)用，那么 AI Coding 用來開發(fā) AI 原生應(yīng)用，可能會成為一個爆發(fā)點。

鄧立山：從自動化角度來看，AI Coding 未來會朝著更高的自動化程度發(fā)展。類似 OpenClaw 的系統(tǒng)，不再局限于單個應(yīng)用或 IDE 插件，而是在更高層級協(xié)調(diào)多個系統(tǒng)。未來有可能是這樣的流程：AI 接收到需求后，直接將任務(wù)拆分給各個微服務(wù)，每個微服務(wù)自動完成本模塊的分析、設(shè)計和編碼，再結(jié)合反思機制，比如 TDD 和 CR 不斷循環(huán)生成、檢查和修復(fù)代碼，接著自動完成集成測試并在發(fā)現(xiàn)問題時繼續(xù)修復(fù)。整個研發(fā)流程將會變得更加自動化和智能化。

Q&A

觀眾：怎么看 OpenClaw 最近被發(fā)現(xiàn)的裸奔安全問題？

姜天意：這個問題沒有想象中嚴(yán)重。OpenClaw 的網(wǎng)關(guān)服務(wù)中，他的控制臺 console 會暴露 18789 端口。部分用戶為方便部署或因云平臺默認(rèn)配置不當(dāng)，將該端口直接暴露到公網(wǎng)；若配置中 bind 設(shè)置為 lan，則允許局域網(wǎng)訪問，從而導(dǎo)致服務(wù)暴露。實際上，在 OpenClaw.json 中可以限制控制臺 console 只允許本機訪問，因此這更多是使用方式的問題。這也再次說明，它并不是一鍵部署就能安全運行的系統(tǒng)，仍需要一定技術(shù)基礎(chǔ)。

褚秋實：不過我認(rèn)為風(fēng)險仍然存在。它以我的權(quán)限操作電腦，但 AI 的行為不一定完全符合真實意圖，前面提到的誤刪數(shù)據(jù)就是例子。未來或許需要在傳統(tǒng) RBAC 之外增加意圖層的控制，AI 雖已獲得授權(quán)，但系統(tǒng)還需根據(jù)其具體意圖進行進一步驗證，類似自動駕駛需要開啟特定模式一樣。

姜天意：在我們的實踐中，通常會在 tool 的 profile 配置中為不同龍蝦設(shè)定不同權(quán)限：有些只能發(fā)送消息，有些只能讀取文件，沒有刪除權(quán)限。這在一定程度上能降低風(fēng)險，但仍不如完整的 RBAC 體系成熟，很多權(quán)限還需在各個系統(tǒng)中單獨配置。

觀眾：小公司有沒有必要自己開發(fā)龍蝦這樣的 Agent？還是用開源的？

姜天意：我認(rèn)為龍蝦開源的 PI Agent Core 就非常好用。它的核心非常簡單，大約只有一千多行代碼，沒有像 Claude Code 那樣包含大量復(fù)雜的內(nèi)部機制，主要只做兩件事：Agent Loop 和 Tool Use。因此在網(wǎng)易內(nèi)部，基于類似框架可以很快做出一個桌面 Agent。它的設(shè)計思路是做減法，弱化了復(fù)雜的 plan mode 或 MCP 支持，將重點放在工具調(diào)用上。對于大多數(shù)公司來說，沒有必要重復(fù)造輪子，可以直接基于 PI Agent 進行二次開發(fā)，或者直接 Fork 龍蝦項目。

褚秋實：關(guān)鍵還是要看使用目的。如果只是解決自身業(yè)務(wù)問題，可以開發(fā)一些 skills，或者將基于 CrewAI、LangChain 等框架構(gòu)建的 Agent 封裝為 skills 供其調(diào)用；如果涉及編碼任務(wù)，也可以再接入 Claude Code 或 OpenCode 等工具，讓龍蝦作為總控和調(diào)度系統(tǒng)，形成一種數(shù)字員工或人機協(xié)作模式。但如果目標(biāo)是做一個類似龍蝦的產(chǎn)品，則需要從產(chǎn)品設(shè)計層面重新考慮整體架構(gòu)。

鄧立山：建議先部署體驗一下，看看它能完成哪些任務(wù)，以及是否能解決自身業(yè)務(wù)問題。整體來說它的擴展性很強，大多數(shù)情況下只需開發(fā)適合自己的 skills，或從開源社區(qū)尋找現(xiàn)成組件即可。

觀眾：可不可以讓 PM 把任務(wù)直接交給 AI，然后由 AI 監(jiān)督程序員的進度，而程序員使用 Claude Code 進行開發(fā)？

褚秋實：可以。這相當(dāng)于讓 AI 成為 PM 的助手，負(fù)責(zé)催進度、收作業(yè)。用龍蝦很適合這個場景，例如通過定時任務(wù)，定期檢查任務(wù)卡片是否有進展、是否完成移測、驗收文檔是否提交等。

姜天意：有的，比如 Vibe Kanban，或者 Claude Dashboard 之類。很多公司都在做類似產(chǎn)品。

觀眾：你們實踐 SPEC Driven 開發(fā)多久了？團隊的接受度如何？SPEC 是一次性的文檔嗎？如何保證它持續(xù)更新？

姜天意：我們是在去年 9 月 Kiro 發(fā)布后開始實踐的，契機是亞馬遜到網(wǎng)易進行技術(shù)交流。SPEC driven 有一個很大的利好，就是高層管理者非常重視，我們的大老板提出了 SPEC 先行的概念，即所有軟件開發(fā)任務(wù)都應(yīng)該從 SPEC 開始，目前網(wǎng)易幾乎所有事業(yè)部都在嘗試大規(guī)模落地這一理念。

實踐形式不限于 specKit、Open SPEC 等工具，也有團隊采用 BDD 思路，或者通過 plan mode 加上嚴(yán)格的團隊流程約束來實現(xiàn)類似效果。推廣的根本原因在于，大家發(fā)現(xiàn)它能解決 Vibe Coding 中不可控的問題。

據(jù)我了解，Claude Code 或 Google Gemini 這樣的工具團隊，也在嘗試用 SPEC driven 方式開發(fā)相關(guān)工具，效果不錯。

褚秋實：這本質(zhì)上是一種團隊層面的規(guī)范積累。規(guī)范在項目中可以分為不同維度：項目層面的技術(shù)規(guī)范，如如何定義 API 接口、實體對象、值對象或 RPC 調(diào)用等，一旦確定最佳實踐就可以長期復(fù)用；圍繞具體需求展開的規(guī)范則會隨每個需求變化，通常需要借助 AI 通過封裝好的指令或 skills 生成一版方案，再進行人工調(diào)整。此外，還需要讓 AI 持續(xù)總結(jié)每個功能模塊，使整個項目逐漸形成可理解的知識體系，這樣下次只需用業(yè)務(wù)語言描述功能，AI 就能準(zhǔn)確理解。關(guān)鍵在于把這種思路傳遞給整個團隊共同參與，而不是讓個別人單獨維護，否則既缺乏動力，也難以形成統(tǒng)一的開發(fā)方式。

鄧立山：在我們團隊，SPEC 開發(fā)從一開始就是默認(rèn)的研發(fā)模式。我們最早制定了一套技術(shù)方案模板，基于 DDD 思想對業(yè)務(wù)實體、業(yè)務(wù)邏輯和接口服務(wù)進行領(lǐng)域劃分，采用表格形式引導(dǎo)開發(fā)者清晰描述業(yè)務(wù)邏輯和規(guī)則。模板本身可以復(fù)用和持續(xù)升級，每次變化的是需求內(nèi)容，模板結(jié)構(gòu)保持穩(wěn)定，因此不會每次從零開始。

在具體編碼階段，我們還會為不同層次制定 MD 文檔規(guī)范，這些文檔不包含代碼及業(yè)務(wù)邏輯，比如輸入、輸出參數(shù)規(guī)范、異常處理方式等約束，AI 生成代碼時以此為約束條件，就可以比較容易生成符合要求的質(zhì)量更加可控的代碼。規(guī)范本身不依賴具體業(yè)務(wù)語義，因此可以隨團隊經(jīng)驗不斷迭代，并像管理代碼一樣通過 Git 倉庫持續(xù)更新。

隨著技術(shù)發(fā)展，規(guī)范也會不斷演進。從最初的 Prompt 提示詞，到封裝為 Rules 工具，再到進一步封裝為 Skills，并逐步覆蓋前端、后端等不同技術(shù)棧。總的來說，SPEC 并不是一次性的，而是可以反復(fù)復(fù)用和持續(xù)演進的。

姜天意：對于有一定規(guī)模的團隊，在使用 AI coding 工具時一定要建立團隊級的工具規(guī)范。我推薦類似 Superpower 或 Everything Code 這樣的規(guī)范體系，將 Constitution Rules、SPEC、Skills 以及 CI 規(guī)則、Lint 規(guī)則等統(tǒng)一整合，保證團隊在使用 AI 時具備一致的能力，并沉淀共同經(jīng)驗。例如某個系統(tǒng)踩過的性能坑或組件使用問題，其他系統(tǒng)在使用這些規(guī)范時也能直接參考。

觀眾：針對維護老項目，有沒有比較好用的 AI 方法？

姜天意：DeepWiki 非常重要。當(dāng)新人接手一個代碼倉庫時，首先需要理解項目結(jié)構(gòu)，例如依賴關(guān)系、引用包、架構(gòu)設(shè)計和目錄結(jié)構(gòu)等。系統(tǒng)會先生成一份分析報告，幫助新人快速建立整體認(rèn)知，而不是一上來就用 Vibe Coding 直接修改代碼。

此外，在老項目中一定要結(jié)合知識庫，例如需求文檔、技術(shù)設(shè)計文檔或歷史 Bug 記錄。僅靠代碼往往無法完全理解系統(tǒng)，如果 AI 能同時參考需求文檔、Bug 單和 RFC 設(shè)計文檔，就更容易判斷正確的實現(xiàn)方式。因此企業(yè)管理者需要長期積累知識，例如定期生成倉庫 Wiki、記錄線上問題排查過程、做安全和高可用掃描等。這樣新成員開始開發(fā)時，就不是從零開始，而是建立在一個已經(jīng)理解舊代碼的 AI 工具基礎(chǔ)上。

褚秋實：老系統(tǒng)往往存在大量隱性知識，很多開發(fā)者已經(jīng)離開，沒有留下文檔，有些文件甚至大到足以撐爆模型的上下文窗口。我們曾經(jīng)做過一個嘗試：用 AI 寫一個 Python 程序，統(tǒng)計過去一年代碼庫中修改頻率最高的文件，找出前 20 % 最常修改的熱點模塊，定位出代碼庫高頻依賴高頻修改的一些代碼和模塊。這些模塊未來大概率也會繼續(xù)被修改，因此可以優(yōu)先對這部分代碼做知識工程整理，讓 AI 幫助生成結(jié)構(gòu)和文檔規(guī)范。這樣雖然只覆蓋 20% 的代碼，但可能能解決 80% 的實際問題。

在 DeepWiki 等工具的幫助下，即使在下班后也可以讓 AI 自動分析倉庫，提前為第二天的任務(wù)生成方案建議，幫助開發(fā)者更快理解系統(tǒng)并做出決策。否則在老系統(tǒng)中，可能只是改兩行代碼，卻要花幾天時間驗證是否修改正確。

觀眾：OpenClaw 怎么省 Token 啊？確實很費。

姜天意：可以試試 https://clawhub.ai/Asif2BD/openclaw-token-optimizer ，或者使用一些記憶管理框架，比如 Memos、OpenViking 之類。

觀眾：SPEC 對團隊人的要求會不會有點高？從 1 到 N 階段，如果不能及時更新文檔，就會出現(xiàn)代碼和文檔不一致的情況，反而更混亂。這個問題怎么解決？

姜天意：這是一個非常重要的問題。現(xiàn)在很多工具基本都提供了從代碼到 SPEC 的 sync 操作，一定要及時同步。

會議推薦

OpenClaw 出圈，“養(yǎng)蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態(tài)迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產(chǎn)力。但這背后也暴露了工程化落地的真實難題——權(quán)限邊界與隔離運行、Skills 供應(yīng)鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發(fā) / 運維流程并形成穩(wěn)定收益。

針對這一系列挑戰(zhàn)，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態(tài)實踐」專題，將聚焦一線實踐與踩坑復(fù)盤，分享企業(yè)如何構(gòu)建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質(zhì)量 / 效率指標(biāo)體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產(chǎn)系統(tǒng)。