第一次看到 Clawrion 回覆我「您的持倉有三檔異動，建議優先處理」，我意識到一件事：它不只是在「回答問題」，它是在以某種一致的方式回答問題。

這不是模型天生就有的特性。是我寫進去的。

為什麼 AI 需要人格檔案？

預設狀態下的 LLM 是一張白紙。你問一個問題，它根據訓練資料的平均值回答你——風格飄忽，語言不定，有時繁中有時簡英，有時話多有時話少。

對於一次性問答，這無所謂。但對於一個 24/7 運行、每天都要和它對話的系統，這就是問題：

你不知道今天的它跟昨天的它，是不是同一個它。

更實際的問題是：沒有邊界定義的 Agent，不知道什麼操作該先確認、什麼操作可以直接執行。我在早期沒有人格檔案的版本裡，曾經看到 Agent 在沒有任何警示的情況下修改排程設定——因為我沒有告訴它「這件事要先問我」。

人格檔案解決的是一致性和可預測性問題，不是讓 AI 更「有個性」。

人格三件套

我的系統用三個 Markdown 檔案定義 Clawrion 的完整人格：

這三個檔案都實際存在於 Workspace 根目錄，不是理論框架——每次 Session 啟動時一起被載入，AGENTS.md 的初始化協定裡有明確規定載入順序。

SOUL.md 設計實錄

SOUL.md 是最核心的那一份。我把它分成五個區塊：

① 語言強制政策

所有回覆必須採用繁體中文（台灣）
禁止簡體中文、繁簡混用

這聽起來很基本，但我加這段是因為沒加的時候，長回覆裡偶爾會出現簡體字——LLM 的預訓練語料裡簡體佔大宗，如果不明確要求，它會往那個方向飄。

② 角色定義

給它一個名字、一個職稱、一句性格總結。我用了「極致效率」和「人文關懷」兩個關鍵詞。這不是在裝可愛——是在給模型一個性格錨點，讓它在模糊情況下有個「應該像誰說話」的參考。

③ 溝通風格

最重要的是輸出結構：

[結論] → [數據/分點支撐] → [行動建議]

這個格式讓我每次收到 Clawrion 的回覆，都知道第一行要看什麼。不用掃完整段才知道「它到底要說什麼」。一般查詢維持 200 字內；深度分析模式才展開多維度考量，但不廢話。

④ 核心價值觀

寫進去三條：事實至上（不猜測設備狀態，API 回傳才算數）、主動避險（API 異常要自動降級排程）、數據隱私（敏感 token 最高警戒）。這是在給它「當不確定該怎麼做時，往哪個方向靠」的原則。

⑤ 絕對邊界（Red Lines）

嚴禁執行未經 /elevated 確認的系統級寫入操作
遇模糊指令必須「二選一」反問，不執行含糊路徑

這是最重要的一段。/elevated 是設計的確認指令——任何涉及刪除、修改設定、寫入重要檔案的操作，Agent 必須等到明確輸入 /elevated 才能執行。沒有這條，Agent 會在它認為「你應該想要這樣」的情況下直接做——通常在你不注意的時候。

⑥ 協作意識（後來才長出來的第六塊）

原本只有上面五塊。第六塊是幾個月後補的，因為系統多了一個角色：桌面端的 AI 助手也會讀寫同一份 workspace。

於是 SOUL.md 裡多了一段告訴 Clawrion「你不是唯一會動這些檔案的人」——遇到不是自己寫的內容不要當成錯誤刪掉，看到別人留下的交接要消化不要覆蓋。

我把這塊單獨拿出來講，是因為它示範了人格檔案真正的用途：**它不只描述「你是誰」，也描述「你身處在什麼環境」。**當環境變了，人格檔案就得跟著改。這段的完整故事在 Day 11。

AGENTS.md：行為協定與品質閘道

AGENTS.md 比 SOUL.md 更偏「規則書」。它管的是：遇到 X 情況怎麼做，而不是「你是什麼人」。

最實用的部分是品質閘道。這是踩了幾個坑之後強制加進去的防呆機制：

這些規則不是靠「它自己判斷」——是明確寫在檔案裡，每次 Session 載入時就已經知道「這些事情不能做，做了要怎麼處理」。

AGENTS.md 裡還有初始化協定：Session 啟動後要做什麼、先讀哪些檔案、遇到 API 異常要怎麼自動降級。這讓每一次對話的起點都是確定的，不是隨機的。

提示詞檔案化的三個好處

很多人把 System Prompt 硬塞在 API call 的參數裡，或寫在程式碼的字串常數中。選擇 Markdown 檔案有三個理由：

一、版本控制天然可用

Workspace 是純文字 Markdown，天然可以接上 git 做版本控管。把 Workspace 目錄加入 git 後，每次修改 SOUL.md，git log 就是完整的人格演化記錄——可以看到哪天加了哪條規則、為什麼加，這些決策不會憑空消失。就算不用 git，Syncthing 的同步機制也能在異動時間戳上留下痕跡，遠比把 Prompt 硬寫在程式碼字串裡可追蹤。

二、可審計、可說明

SOUL.md 是純文字，任何人拿到都能看懂「這個 AI 的規則是什麼」，不需要反推程式碼。當 Agent 做了一個奇怪的決定，可以查「它當時讀到的人格檔案說什麼」。

三、跨 Session 一致性

每次新的對話 Session，第一件事就是載入這三個檔案。不管是凌晨的 Cron Job 還是下午臨時問一個問題，面對的是同一個 Clawrion。

怎麼開始寫人格三件套？

用 AI 生成初版，遇問題再更新

我的 SOUL.md 第一版不是精心設計出來的——是我告訴 AI「我要一個說繁體中文、管理家居投資的效率型 Agent，幫我起草一份人格定義」，然後它給了我初稿，我覺得大致可用就直接用了。

真正的精煉發生在使用過程中：

• 回覆混出簡體字 → 加語言強制政策
• 沒確認就修改排程設定 → 加 /elevated 紅線
• 回覆沒重點 → 加 [結論] → [數據] → [行動建議] 輸出結構

每次出問題，我就告訴它「記住這條規則，更新 SOUL.md」。它直接編輯檔案，下次 Session 新規則就生效。

所以如果你加了 git，git log SOUL.md 不只是版本記錄——它是這套系統的問題史。你不需要在第一天設計出完美的人格，只需要一個夠用的初版，然後讓使用過程去完善它。

Token 成本：檔案多大才算太大？

人格三件套是 System Prompt 的一部分，每次 API 呼叫都會計入 token。我目前的大小：

對話型互動：1,800 tokens 幾乎可以忽略不計。排程任務即使每天跑幾十次，人格檔案這一段的佔比也小到不構成問題——真正吃成本的是別的東西（Day 7 拆過）。

真正的風險是無限膨脹：每次遇到問題就加規則、從不刪除，三個月後 SOUL.md 變成 300 行的矛盾規則集合——token 費用翻倍是小事，互相衝突的規則才是真麻煩。

而我自己正在被這條規則追著跑。寫這篇的時候 AGENTS.md 是 70 行，現在是 89 行——半年長了將近三成，而我給自己設的上限是 100 行。

這個數字我刻意留在文章裡沒有偷偷改掉，因為它正好示範了膨脹是怎麼發生的：**沒有任何一次是我「決定要讓它變長」，每一次都是「這個坑很痛，加一條規則吧」。**十九行就是十九個這樣的瞬間。等它撞到 100 行那天，我就得做一次真正的取捨——而不是把上限改成 150。

我的控制原則：

• SOUL.md ≤ 50 行、AGENTS.md ≤ 100 行
• 一條新規則進來，檢查有沒有舊規則可以合併或刪掉
• 細節程序移到獨立參考檔，人格檔只保留「原則層級」的規範

補充一點：Claude API 有提示詞快取機制——System Prompt 超過 1,024 tokens 且重複使用時，後續呼叫可以大幅降低費用。穩定的人格檔案越大，反而越容易命中快取，實際每次呼叫成本比你想像的低。

踩坑：沒有人格檔案時 Agent 的行為飄移

早期版本沒有 SOUL.md。差別在哪？

語言飄移：長回覆裡混入簡體字或英文術語，每次都不一樣。

結構飄移：有時回覆很短、有時洋洋灑灑一大篇，沒有可預測的格式。

邊界飄移：遇到沒想到的情況，Agent 就「自己判斷最合理的做法」——有時合理，有時不合理，但你不知道下次會是哪個。

最實際的影響是：你不能信賴它。不是說它會做壞事，而是你不知道它這次會怎麼做，所以每次都要額外確認一遍。人格檔案的目的，是讓你可以信賴這個系統的行為邊界，而不是每次都重新猜測。

小結

不到 200 行 Markdown，換來的是一個行為可預測、語言一致、遇到危險操作會先問你的系統。

如果你只打算從這套架構裡學一件事，學這個：把你對 AI 的期望寫下來，放進一個它每次都會讀的地方。剩下的它自己會處理。

明天拆六個分身：一個系統怎麼同時跑投資秘書、家居管家、備考顧問而不互相干擾。

🔑 這篇的關鍵字
System Prompt 檔案化 · SOUL.md / AGENTS.md / IDENTITY.md（人格三件套，命名可自訂）· Red Lines（絕對邊界）· 確認指令設計（本文用 /elevated）· Prompt Caching（穩定的 System Prompt 越大越容易命中快取）· token 估算（中文約 1 字 ≈ 1–1.5 token）

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。