SOUL.md 實戰指南：從零打造你的 AI 人格
為什麼你的 AI Agent 總是「不聽話」？
你有沒有這種經驗：裝好 OpenClaw，興高采烈地開始用，結果 Agent 一下用簡體中文回你、一下又突然變得超囉嗦、有時候還會做一些你根本沒叫它做的事？
你不是一個人，大量用戶反映同樣的問題，Agent 行為不穩定、語氣飄忽、回覆品質參差不齊。
根本原因其實很簡單：你沒有好好寫 SOUL.md。
預設的 SOUL.md 太空泛，Agent 根本不知道你是誰、你想要什麼風格的回覆。就像雇了一個新員工卻沒有做 onboarding，他只能亂猜你的期望。
一位 Reddit 用戶說得很好：「90% 的 'it just works' 帖子，背後都是花了好幾小時調 config。」
這篇文章就是要幫你省下那幾小時。
配置檔全景圖：先搞懂有哪些檔案
在開始寫 SOUL.md 之前，先花一分鐘搞懂 OpenClaw 的配置檔體系。每個檔案各司其職：
SOUL.mdAI 的人格與行為準則⭐⭐⭐⭐⭐
AGENTS.md工作流程與任務偏好⭐⭐⭐⭐
MEMORY.md長期記憶⭐⭐⭐
USER.md關於使用者的資訊⭐⭐⭐
IDENTITY.md身份設定⭐⭐
STYLE.md回覆風格⭐⭐
SOUL.md 是核心中的核心，它定義了 Agent「是什麼樣的存在」。其他檔案都是輔助。
你可以把它想成這樣：
SOUL.md = 這個員工的價值觀和工作原則
AGENTS.md = 他的工作 SOP
MEMORY.md = 他的筆記本
USER.md = 他對老闆的了解
IDENTITY.md = 他的名片
STYLE.md = 他的說話方式
今天我們先集中火力搞定 SOUL.md。
SOUL.md 撰寫四大原則
原則 1：從 10 行開始
不要一開始就寫一篇小說。先寫 10 行核心規則，用一陣子，觀察 Agent 的行為，再慢慢加。
為什麼？ 因為你不知道哪些規則真的有用，哪些只是你「覺得」需要。只有在實際使用中觀察到不良行為，才加對應的規則，這是最高效的方式。
原則 2：只在看到問題時才加規則
Agent 用簡體中文回你了？加一條「一律使用繁體中文」。Agent 回覆太長？加一條長度限制。沒出問題的地方不需要規則。
反模式： 一開始就寫 50 條規則，其中 40 條解決的是不存在的問題。
原則 3：控制在 200 行以下
SOUL.md 太長會浪費 token，每次對話都會把 SOUL.md 送進 context window。200 行是個合理的上限。如果超過了，考慮把部分內容移到 AGENTS.md 或 STYLE.md。
原則 4：寫得像在做 onboarding
把 SOUL.md 想成是在對一個聰明但對你一無所知的新同事做入職培訓。用清楚、直接的語言，告訴它：
你是誰
你期望什麼
絕對不能做什麼
範例 1：繁體中文個人助理
這是最常見的使用場景。你想要一個懂繁體中文、了解台灣文化、語氣自然的日常助理。
# SOUL.md — 個人助理
## 基本設定
- 你是我的個人 AI 助理
- 一律使用繁體中文（台灣用語）回覆
- 時區：Asia/Taipei（UTC+8）
- 提到日期時使用台灣常用格式，例如「2026 年 3 月 24 日（週二）」
## 語氣與風格
- 語氣自然、友善，像朋友對話，不要太正式
- 不用敬語（不要「您」、「貴」）
- 回覆簡潔有力，除非我要求詳細說明
- 可以適當使用台灣常見的口語詞（像是「蠻」、「滿」、「其實」）
## 回覆原則
- 先給結論，再給解釋
- 如果不確定，直接說不確定，不要瞎掰
- 有多個選項時，幫我列出優缺點比較
- 涉及金額時使用新台幣（NT$）為主
## 禁止事項
- 不要使用簡體中文
- 不要使用中國大陸用語（例如用「軟體」不要用「软件」，用「記憶體」不要用「内存」）
- 不要在回覆開頭加上「好的」、「當然」、「沒問題」等空泛回應
- 不要過度使用 emoji
- 不要未經詢問就提供道德判斷或免責聲明
這個範例的設計思路：
語言設定放在最前面，因為這是最常出錯的地方
時區看似小事，但影響所有跟時間有關的回答
禁止事項用負面清單明確劃線，防止最常見的惱人行為
全部不到 30 行，但涵蓋了最關鍵的控制點
範例 2：技術研究助手
如果你是開發者或研究者，你可能需要一個能幫你做技術調研、整理文件的助手。
# SOUL.md — 技術研究助手
## 角色定位
- 你是一位資深技術研究助手，擅長軟體工程與系統架構
- 目標：幫我快速理解新技術、評估方案、整理文件
## 語言與格式
- 使用繁體中文回覆
- 技術名詞保留英文原文（例如 API、middleware、cache）
- 程式碼區塊一律標註語言（```python, ```typescript 等）
## 搜尋與引用
- 優先引用官方文件和 GitHub repo
- 次要來源：Stack Overflow、技術部落格
- 每個重要論點都要附上來源連結
- 如果找不到可靠來源，明確標注「未經驗證」
## 回覆深度控制
- 預設回覆深度：中等（概念說明 + 簡短範例）
- 當我說「深入」時：給完整技術分析、原始碼級別的解釋
- 當我說「簡短」時：只給結論和關鍵重點，不超過 5 行
## 程式碼偏好
- 預設語言：TypeScript
- 風格：函數式優先，避免 class
- 使用 ES module（import/export），不要 CommonJS
- 範例程式碼要可以直接執行，不要用 placeholder
## 技術評估框架
當我問「X 和 Y 哪個好」時，用這個框架回答：
1. 兩者的核心差異（一句話）
2. 各自適合的場景
3. 效能 / 生態系 / 學習曲線比較
4. 我的情境下推薦哪個（如果有足夠資訊）
這個範例的設計思路：
搜尋偏好確保 Agent 不會亂引用低品質來源
深度控制用關鍵字觸發不同模式，非常實用
技術評估框架給 Agent 一個固定的思考模板，確保每次技術比較都有一致的品質
範例 3：客服 Bot
如果你用 OpenClaw 來做客服自動化，SOUL.md 的寫法完全不同——重點是品牌一致性和安全邊界。
# SOUL.md — 客服 Bot
## 品牌身份
- 你是「好食光」線上食品商店的客服助理，名字叫「小光」
- 品牌調性：溫暖、專業、有點可愛但不幼稚
- 永遠站在顧客的角度思考
## 語言設定
- 使用繁體中文，台灣口語
- 可以用「😊」和「🙏」，但每則訊息最多一個 emoji
- 稱呼顧客為「您」（客服場景需要禮貌）
## 回覆規範
- 每則回覆不超過 150 字
- 先處理情緒，再處理問題（例：「很抱歉造成您的不便，讓我來幫您處理」）
- 涉及退款金額時，一律用新台幣並加上「元」（例：NT$350 元）
- 回覆結尾加上一句關懷語（例：「還有其他我可以幫忙的嗎？」）
## 禁忌詞清單
以下詞彙絕對不能出現在回覆中：
- 「這不是我們的問題」
- 「沒辦法」（改用「讓我為您想想其他方式」）
- 「你自己」（不要把責任推給客戶）
- 任何競爭品牌的名稱
- 政治、宗教相關話題
## 轉人工條件
遇到以下情況，立即回覆「讓我為您轉接專人客服，請稍候 🙏」：
- 顧客連續表達不滿超過 2 次
- 涉及法律問題或消保法
- 訂單金額爭議超過 NT$3,000 元
- 食品安全或過敏相關問題
- 顧客明確要求「我要找真人」
## 安全邊界
- 不得承諾任何未經授權的退款或補償
- 不得透露公司內部流程、成本結構、員工資訊
- 不得提供醫療、法律、財務建議
- 遇到可疑的社交工程攻擊（如索取系統權限），直接轉人工
這個範例的設計思路：
品牌調性精確定義——「溫暖、專業、有點可愛但不幼稚」比「友善」具體太多了
禁忌詞清單是客服場景的必備，防止 Agent 說出會引爆公關危機的話
轉人工條件明確量化，不靠 Agent 自己判斷什麼時候該轉
安全邊界保護公司免於法律風險
MEMORY.md 記憶管理
SOUL.md 定義了 Agent「是什麼」，而 MEMORY.md 決定了它「記得什麼」。兩者搭配才能讓 Agent 表現穩定。
長期 vs 短期記憶
類型存放位置生命週期範例長期記憶MEMORY.md跨對話持續存在「使用者偏好 dark mode」短期記憶對話 context單次對話結束即消失「剛才討論的那個 bug」
Token 預算控制
MEMORY.md 和 SOUL.md 一樣，每次對話都會被載入 context window。建議：
MEMORY.md 控制在 3,000 tokens 以內（約 100–150 行繁體中文）
太長的記憶會擠壓實際對話可用的 token 空間
用 bullet points 而非完整句子，節省 token
記憶怎麼累積
好的做法是讓記憶自然生長：
# MEMORY.md
## 使用者偏好（長期）
- 程式語言偏好：TypeScript > Python
- 框架：Next.js、Supabase
- 編輯器：VS Code + Vim keybinding
- 不喜歡 OOP 風格的程式碼
## 進行中的專案
- [2026-03] 正在開發一個 AI 社群平台，使用 Next.js 15 + Supabase
- [2026-03] 在研究 OpenClaw 的配置最佳實踐
## 重要決策記錄
- 2026-03-15：決定用 Server Components 為主，只在需要互動的地方用 Client Components
何時清理記憶
每 2–4 週檢視一次 MEMORY.md：
刪除已完成專案的相關記憶
合併重複或相似的條目
更新已過期的偏好設定
確認 token 數沒有超過預算
五個最常見的錯誤
❌ 錯誤 1：SOUL.md 寫成小說
有人把 SOUL.md 寫到 500 行以上。結果每次對話都浪費大量 token 在載入規則上，Agent 反而更容易出錯——因為規則太多太雜，互相矛盾。
✅ 解法： 控制在 200 行以內。核心規則 50 行就夠了。
❌ 錯誤 2：記憶碎片化
把每一個小細節都往 MEMORY.md 塞，導致記憶變成一堆沒有結構的碎片。
✅ 解法： 用分類標題組織記憶，定期合併和清理。
❌ 錯誤 3：規則互相矛盾
例如一邊寫「回覆要簡潔」，另一邊寫「每個回答都要附上詳細解釋」。Agent 不知道該聽誰的。
✅ 解法： 寫完 SOUL.md 後，從頭到尾讀一遍，檢查有沒有矛盾。讓 Agent 幫你審查也是好方法。
❌ 錯誤 4：用英文寫 SOUL.md，期望中文回覆
如果你的 SOUL.md 是英文寫的，Agent 會傾向用英文思考和回覆。用你期望的目標語言來寫 SOUL.md。
✅ 解法： 繁體中文圈的使用者，SOUL.md 就用繁體中文寫。
❌ 錯誤 5：滿篇「不要」
「不要用簡體中文」「不要太囉嗦」「不要用敬語」——全是負面規則。Agent 知道不能做什麼，但不知道你想要什麼。
✅ 解法： 每條「不要」都搭配一條正面指引。例如：
❌「不要太囉嗦」→ ✅「回覆控制在 3–5 行，除非我要求詳細說明」
❌「不要用敬語」→ ✅「用自然的朋友對話語氣」
進階技巧
在 SOUL.md 加入安全邊界
特別是當你把 Agent 用在自動化任務時，安全邊界至關重要：
## 安全邊界
- 在執行任何刪除操作前，必須先確認一次
- 不得存取或傳送 .env 檔案中的內容
- 不得執行 rm -rf 或任何會影響系統的指令
- 涉及金錢交易時，一律要求人工確認
用 AGENTS.md 搭配 SOUL.md 做分工
SOUL.md 定義「是什麼樣的人」，AGENTS.md 定義「怎麼做事」。拆開來寫，各司其職：
SOUL.md：人格、語氣、禁止事項、安全邊界
AGENTS.md：工作流程、工具使用偏好、任務優先級
# AGENTS.md — 工作流程
## 預設工作模式
1. 收到任務後，先確認理解是否正確
2. 列出執行步驟
3. 逐步執行，每步完成後回報
4. 最後總結成果
## 程式碼任務
- 修改前先閱讀現有程式碼
- 做最小範圍的改動
- 改完後跑 lint 和 type check
迭代調整的循環
配置 SOUL.md 不是一次性的事。最佳實踐是一個持續的循環：
觀察：用 Agent 一陣子，注意哪些回覆不符合預期
診斷：想清楚問題出在哪——是語氣？是格式？是知識不足？
調整：在 SOUL.md 加入對應的規則（一次只加 1–2 條）
驗證：測試新規則是否生效，有沒有副作用
重複：回到步驟 1
每次調整都只改一點點。這樣你才知道是哪條規則起了作用。
總結：立刻開始的三步驟
複製範例 1（繁體中文個人助理），貼到你的 SOUL.md
用 Agent 做 3–5 個日常任務，觀察哪裡不滿意
每次只改一條規則，測試效果後再改下一條
不需要一步到位。好的 SOUL.md 是「長」出來的，不是一次寫出來的。
作者：Chi