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

作者 | QCon 全球軟件開發大會

策劃 | 羅燕珊

編輯 | 宇琪

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

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

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

部分精彩觀點如下：

• OpenClaw 并不像許多公眾號描述的那樣是一個“低門檻”產品。要真正用好它，需要熟悉 JSON 配置、具備排障能力，并持續調試和優化 skill，對普通用戶仍存在相當門檻。

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

• 未來程序員編寫規范和設計架構比編寫具體代碼更有價值，具體實現則交給 AI 完成。

• 要想真正放飛效率，必須先打好基礎；在開發過程中，不僅要完成業務功能，還要為代碼庫留下知識和規范。

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

查看大會日程解鎖更多精彩內容：

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

完整直播回放可查看：

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

以下內容基于直播討論整理，經 InfoQ 刪減。

OpenClaw 為什么會
在這個時間點出現

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

因此，OpenClaw 并不像許多公眾號描述的那樣是一個低門檻產品。要真正用好它，需要熟悉 JSON 配置、具備排障能力，并持續調試和優化 skill，對普通用戶仍存在相當門檻。

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

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

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

褚秋實：那是否意味著 coding agent、辦公 agent 等都可以作為它的下層，成為細分領域的專業 agent？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果只是開發 demo 或做技術探索，可以先用 Vibe Coding 生成初始版本，再通過 SPEC 模式讓 AI 實現最終版本。對于需要長期維護的生產系統，更建議使用 SPEC Driven 方法，并在過程中制定清晰的需求分析規范、架構規范和編碼規范，從而生成質量更高、可長期維護的代碼。

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

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

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

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

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

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

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

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

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

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

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

鄧立山：往后 6–12 個月大家覺得 AI Coding 最可能出現的拐點是什么？會先在什么環節發生？

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

褚秋實：目前大部分應用仍然是為人設計的，前端界面中的交互細節即使有規范驅動，通過自然語言描述也可能存在偏差。但如果未來應用形態發生變化，AI 原生應用大量出現，應用可能只需要一個超級框架，功能封裝為 skills，AI 既負責開發又負責調用，那么 AI Coding 用來開發 AI 原生應用，可能會成為一個爆發點。

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

Q&A

觀眾：怎么看 OpenClaw 最近被發現的裸奔安全問題？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

鄧立山：在我們團隊，SPEC 開發從一開始就是默認的研發模式。我們最早制定了一套技術方案模板，基于 DDD 思想對業務實體、業務邏輯和接口服務進行領域劃分，采用表格形式引導開發者清晰描述業務邏輯和規則。模板本身可以復用和持續升級，每次變化的是需求內容，模板結構保持穩定，因此不會每次從零開始。

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

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

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

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

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

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

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

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

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

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

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

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

會議推薦

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

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