研究完OpenClaw源碼后，我的10條使用原則

從'任務系統而非聊天助手'的定位重構，到模型分層策略、上下文注入控制，再到技能設計的SOP化，這些原則揭示了Agent工具從'能用'到'好用'的關鍵跨越。本文為真正希望將AI融入工作流的用戶提供了系統化操作框架。

———— / BEGIN / ————

理解系統原理的真正意義，是它會改變你使用系統的方式。如果只是知道 OpenClaw 的內部結構，但在使用方式上依然和別人一樣，那這種理解其實價值并不大。

換句話說，如果你已經知道它的運行機制，那你在使用 OpenClaw 時，理應比別人更有優勢。

你應該更清楚它的邊界在哪里，更知道哪些能力來自模型，哪些來自工具，哪些來自上下文工程，也更知道怎么使用才能真正發揮這套系統的能力。

所以，這篇文章我基于對源碼的理解，嘗試為你總結出十條 OpenClaw 的最佳使用原則。

下面我們就開始吧：

第一條：不要把OpenClaw當萬能助理，把它當任務系統

很多人第一次用 OpenClaw，很容易把它當成一個更強的聊天機器人，習慣性地去想讓這條龍蝦幫自己做點什么。比如去搜個信息、去看個文檔等等。

但從系統結構來看，OpenClaw并不是一個單純的聊天助手，而更像一個任務調度系統。它背后有消息路由、Agent運行環境、工具系統和會話上下文。如果你給它的任務是模糊的，它就會在一個很大的空間里亂跑，最終輸出的結果也往往會比較發散。

更有效的方式，是把每次會話都當成給它下一張任務單，去定義清楚它在這個會話里到底該負責什么。

也就是說，你每一次和龍蝦的對話，最好先想清楚：

• 它服務的是哪個場景。

• 它能調用哪些工具。

• 它要讀哪些資料。

• 它要輸出成什么結果。

• 它什么時候該停。

因此，從這個角度看，更適合你的做法，是把 OpenClaw 用在這幾類事上：

一類是有明確輸入輸出的知識類工作，比如資料搜集、文檔整理、方案初稿、文章提綱、代碼排查。

一類是需要工具參與的半自動執行任務，比如批量讀文件、搜索項目文檔、匯總多個目錄下的信息。

當任務邊界清晰時，Agent的行為就會更穩定。

第二條：模型選型，要按任務分層

從源碼中可以發現，OpenClaw的任務效果，是由模型能力、上下文長度、工具調用穩定性三者綜合決定的。

而很多人用 OpenClaw 時，對模型選型這件事會比較“一刀切”，要么就是用云端一鍵部署的默認模型，要么就直接懟到Claude Opus 4.6，代價就是不好用 or 賬單爆掉。

因此更實用的思路，是“按任務類型分層選擇模型”。

復雜規劃、長鏈路推理、關鍵決策，用更強的模型。

比如你要寫個多步驟的Skill、要做復雜流程的深度研究、完成一條工作流（比如視頻創作、長文撰寫），這類任務對推理要求高，寧可貴一點，也要上更強的模型。比如Claude Opus 4.6。

資料整理、改寫潤色、常規問答、輕量執行，用成本更低、速度更快的模型。

比如DeepSeek系列。 因為這類任務真正的瓶頸不在智力，而在上下文組織和任務邊界。

工具密集型任務，優先考慮工具調用穩定、上下文容忍度高的模型，而不只是紙面上的智商高。

比如GPT?5.4、Kimi K2.5。 因為在 OpenClaw 里，模型不是只回答，它還要理解工具說明、決定是否調用工具、消化 tool result，再繼續下一輪。這里穩定性比一次驚艷的輸出更重要。

所以在實際使用時，建議你按任務類型，多養幾只接不同模型的龍蝦：

• 專門跑研究型任務的龍蝦，接重推理模型

• 專門跑執行型任務的龍蝦，接工具響應穩定的模型

• 專門做內容理解、摘要提取、數據格式化的龍蝦，接性價比高模型

當這樣分層使用模型時，龍蝦跑得就會更穩，也更省錢~

第三條：指令不要寫成聊天，要寫成任務說明

Agent系統和聊天助手的一個重要區別，在于 OpenClaw 不是普通的對話助手，它背后有工具、文件、會話歷史、系統提示詞，它會根據上下文和工具去執行操作。

因此，當你給它指令時，如果只是自然聊天，很容易讓他產生過度解讀，不僅輸出不是你想要的，回復效率也沒那么高。

舉個極端的例子，你跟他說“今天天氣真好”，他可能會先分析你的潛臺詞，是要圍繞天氣來產生后續行為，然后他會主動找有沒有天氣Skill能查天氣，如果沒有可能會自己寫一個，然后再基于天氣規劃你今天的日程等等。但其實你可能只需要一句“看起來你心情不錯”的回復……

所以，在有明確目標的前提下，就還是少用這樣的表達方式：“幫我看看這個東西怎么弄”、“你研究一下這個”、“你幫我搞定這個”……

建議把你的指令，寫成結構化的任務說明。明確目標、輸入材料、執行步驟、輸出格式以及限制條件。

比如讓它分析一個開源項目，不要只說：“幫我看懂這個項目源碼”，而是要這樣表達：

請只從以下3個地方的文件進行分析：README.md、ARCHITECTURE.md、src/auto-reply 目錄下的Markdown文件。先回答系統入口在哪里，再回答消息鏈路如何流轉。不要泛泛總結，不要猜測未讀到的內容。最后輸出一份 5 段式分析，包含關鍵文件名和職責。

這種寫法相當于在給 Agent 發一張工單，輸出會更穩定。

第四條：少寫人格設定，多寫工作邊界

很多人用 OpenClaw，最愛往 SOUL.md里堆大量人格設定，比如“你是一位嚴謹的專家”、“你是一個經驗豐富的工程師”。 但你現在已經知道，這東西價值有限。

真正有效的，不是人格描述，而是工作邊界的說明。

你更應該寫的，是要求他只允許讀取哪些目錄、優先使用哪些工具、什么情況下必須先提問、什么情況下禁止直接執行、輸出必須包含哪些字段、引用結論時必須給出處、遇到上下文不足時先詢問而不是瞎猜。

這類會影響模型行為路徑的規則，比任何人格設定都更有效。

因為模型真正吃的是操作約束，不是人格夸獎。

第五條：控制上下文注入，不要讓系統變成一鍋粥

上篇文章中你已經看到了，buildEmbeddedSystemPrompt 會把很多東西拼進去，包括工作目錄、可用工具、項目文檔以及記憶文件等。這也是為什么 Agent 在某些場景下看起來非常懂你。

但這同時也是一把雙刃劍。上下文越長，token消耗越高，而且模型注意力會被稀釋。如果再額外塞入大量無關資料，很容易導致推理質量下降。

因此我的建議是：最小必要上下文原則。即：

• 長期規則文件只保留真正穩定的原則。

• 一個文件只寫一類事情。

• 背景材料盡量摘要化，不要整篇原文硬塞。

• 和當前任務無關的 README、歷史筆記、記憶文檔，盡量別默認全帶。

• 每次任務只給最小必要上下文。

總之就是只提供當前任務真正需要的信息，其余資料盡量不帶入會話。

很多時候，讓模型知道得更少，反而會更聰明。

第六條：不要把Skill當能力清單，而要設計成標準作業流程

很多人對Skill的態度，是多多益善，恨不得把Clawhub上的全部Skill都搞下來，美其名曰“讓龍蝦自我進化”。

但從實際使用來看，刨除掉安全風險，如果只是無腦堆Skill能力，反而會讓系統越來越亂、過度輸出、頻繁消耗token。

更有效的方式，是把 Skill 設計成 SOP。讓每個 Skill 都面向一個固定任務，有固定輸入、固定步驟和標準輸出，也有精確的停止條件。

舉個例子，比起安裝一個“企業AI顧問專家 Skill”，你更應該把它拆成：

• 客戶需求紀要整理 Skill。

• 調研訪談提綱生成 Skill。

• 公眾號選題診斷 Skill。

• 項目結構拆解 Skill。

• 競品資料比對 Skill。

你會發現，一旦 Skill 變成 SOP，效果會穩定很多，也更適合復用。

第七條：復雜任務采用兩段式調用

在很多復雜任務中，最容易出現的問題是讓 Agent 一次完成探索和總結兩件事情。這樣往往會導致輸出內容冗長且結構混亂。

而更好的方式是分多輪執行。

第一輪，讓 OpenClaw 做探索。

比如搜集、掃描、初步歸類、列出可能路徑。

第二輪，再讓它做收口。

比如只基于第一輪的結果，輸出判斷、摘要、對比、結論。

不要一上來就讓它直接給最終答案。因為 Agent 一旦同時承擔探索和定稿兩個任務，就容易又長又散。

我們寫文章、做方案、做項目分析判斷，都很適合用這套方法。

第八條：對要穩定交付的任務，增加檢查點

如果只是你自己研究、試驗，可以放開讓 OpenClaw 自由發揮。

但如果是一些要穩定交付的確定性工作，比如讓它寫一個Skill、生成一套PPT、給客戶出最終方案，最好在關鍵步驟增加檢查點。

比如：

• 先讓它列計劃，不直接執行。

• 先讓它展示將讀哪些文件。

• 先讓它給出目錄和證據來源。

• 先給你中間稿，再決定是否繼續。

• 在工具執行前先確認一次。

因為 OpenClaw 的背后是個大語言模型，而大語言模型是會騙人的。

我就有過無數次，讓 OpenClaw 寫個記日程的 Skill ，告訴我寫完了，結果workspace文件夾里啥都木有；讓 OpenClaw 幫我記日程，也是虛晃一槍，第二天告訴我昨天什么事都沒做。

后來我學聰明了，讓它干完活兒自己檢查，結果幻覺率大大減少。

對高價值任務，半自動協作，往往比全自動更可靠。

第九條：把 OpenClaw 當放大器，而不是演示工具

很多人使用 OpenClaw，只是為了展示 Agent 能做什么。但從長期來看，它更適合用作研究工具。

我自己在用 OpenClaw 時，覺得下面三個場景最能幫到我：

第一類，產品研究。

OpenClaw 很適合做文檔掃描、模塊梳理、關鍵文件抽取、問題定位。

第二類，多源雜亂內容的預處理。

比如幫你讀會議紀要、項目資料、訪談記錄，先做結構化整理，再由你做判斷。

第三類，內容創作前的系統性調研。

不是直接幫你寫終稿，而是先幫你拆結構、找證據、梳理觀點、比較差異。這些工作往往需要大量閱讀和整理，正是 Agent 系統擅長的領域。

如果把它當作研究放大器，它的價值會比單純演示能力高得多。

第十條：為自己建一套使用手冊

當你使用 OpenClaw 一段時間后，最有價值的沉淀，其實不是某個具體的 Skill，而是一套自己指揮龍蝦的方法。

建議你給自己沉淀一份個人龍蝦使用手冊，內容大概可以分成下面四塊：

1. 什么任務適合用 OpenClaw。

2. 什么任務不適合。

3. 不同任務用什么模型。

4. 不同任務的指令模板怎么寫。

比如這樣的一套組合技：

• 源碼解讀：Code大蝦 + 限定目錄 + 證據輸出。

• 資料匯總：Speed大蝦 + 指定文件夾 + 固定摘要格式。

• 文章選題：Speed大蝦 + 探索Skill + 修正方向 + 終稿生成Skill。

• 客戶方案：Smart大蝦 + 音頻轉錄解讀工作流Skill + 信息補充 + 方案生成Skill。

當這些經驗形成一份簡短的個人手冊時，你使用 OpenClaw 的效率就會越來越高。

系統本身并不會自動變得更聰明，但使用者會。

結語

回頭看這段時間對 OpenClaw 的研究，我最大的感受是：理解系統原理，并不會立刻讓你能設計出同樣的工具，但它會改變你使用工具的方式。

很多時候，真正和其他人拉開差距的，是使用工具的方式。

本文來自公眾號：互聯網悅讀筆記 作者：申悅

想要第一時間了解行業動態、面試技巧、商業知識等等等？加入產品經理進化營，跟優秀的產品人一起交流成長！