一份 Markdown 可以是開會筆記，也可以決定 agent 能不能讀 production database、什麼情況可以呼叫工具、遇到哪種要求必須拒絕。
如果這兩種檔案都用同一套方式維護：打開、改字、存檔、貼進後台，那就有點可怕了。
很多團隊的 agent prompt 一開始只有幾段。後來加上安全規則、工具說明、domain knowledge、例外處理、語氣和 escalation policy，檔案慢慢長到沒有人敢從頭讀完。每次修改看起來都只是多一條規則，實際上卻沒有人說得準它會影響哪些行為。
到了這個規模，光討論「prompt 寫得好不好」已經沒什麼用。你面前其實是一個缺少 build pipeline 的 production artifact。
把所有規則放在同一份 prompt，最先出現的是 blast radius 不透明。
你改了一段客服退款規則，可能不小心碰到共用的權限描述；你調整工具選擇順序，可能改變原本的拒絕條件。Git diff 當然看得見文字變了，但很難看出最後送進 model 的完整指令到底變成什麼樣子。
接著是 copy-paste drift。
團隊有客服 agent、coding agent、資料分析 agent。三份 prompt 都需要同一套安全邊界，大家最快的做法通常是複製一份再改。幾個月後，其中一份補了新規則，另外兩份沒有；有人修了 typo，卻順手改掉一句關鍵限制。每一份單獨看都說得通，放在一起卻已經不是同一套政策。
最後，很多錯誤要到 runtime 才會被發現。引用的片段不存在、變數沒有值、兩個模組互相依賴，甚至 deploy 的 artifact 根本不是 repo 裡那一版。這些都不是模型能力問題，是交付流程根本沒檢查。
很像早期的前端開發：把幾支 script 手動照順序貼進頁面，平常能跑就算了。等依賴一多，大家自然會開始需要 module、compiler、lockfile 和 CI。
Prompt 也正在走到這一步。
比較能維護的做法，是把「人要改的來源」和「model 最後收到的 artifact」拆開。
例如 repo 裡可以長這樣：
ryanvale
prompts/
identity.md
safety.md
tools/
search.md
database.md
domains/
billing.md
account.md
escalation.md
dist/
support-agent.system.md
工程師平常修改 prompts/ 裡的小模組。Build 工具負責解析 import、帶入明確允許的變數，再用固定順序產生 dist/support-agent.system.md。
不用為了這件事另造一套複雜 DSL，每個團隊也未必需要自己寫 transpiler。先把來源和產物的責任分清楚，已經能解決不少問題。
Source fragment 要方便人類理解、分工和 review；compiled artifact 要能重現 production 實際載入的內容。兩者混在一起，久了就會有人直接手改部署檔，下一次 build 又被蓋掉，或是 source 明明更新了，production 還在跑舊版本。
只要 prompt 已經會控制真實工具和權限，這種差異就不該靠記憶處理。
Prompt build 至少應該擋住幾種很無聊、但真的會發生的錯誤：
這些檢查不需要理解自然語言有沒有「寫得漂亮」。它們只是在回答：這份東西組不組得起來？依賴是否完整？同一個 commit 能不能重建出同一份 artifact？
我會把 build command 做到本機和 CI 都能跑，例如 pnpm prompt:build。PR 開出來時，CI 重新 build，再把產物和 repo 裡的 golden file 比對。只要不一致就 fail。
這個 drift check 很樸素，卻能回答一個平常很難追的問題：
「現在 production 應該跑的 prompt，真的是這個 commit 產生的嗎？」
當然，golden file 不能只交給機器看。Prompt PR 最好同時呈現 source diff 和 compiled diff。前者讓 reviewer 知道哪個模組被修改，後者讓人看見這次變更放進完整 control plane 後，實際移除了什麼、增加了什麼、順序有沒有變。
只看其中一邊都不夠。
這裡很容易產生另一個誤會：既然 prompt 可以 deterministic build，是不是 agent 行為也變得 deterministic？
不是。
Deterministic build 只保證同一組來源會產生同一份指令 artifact。它不能保證 model 每次都選同一個工具，更不能證明權限、拒絕和 escalation 行為一定正確。
所以 static validation 後面還是要接 eval。
不要只看一個混在一起的 agent quality score。對真正不能錯的行為，保留獨立案例比較有用。例如：
每次 prompt PR 都跑同一批 cases，比較 before 和 after。Static check 負責抓「組裝錯誤」，eval 負責抓「行為退步」。這兩件事不能互相代替。
大家遇到 agent 做錯事時，很直覺的反應是把 Spec 或 prompt 寫得更完整。
這招偶爾有效，但很快會碰到上限。iThome 最近報導的一個本地 AI Coding 案例，曾經把 Spec 寫到約 5,000 行，產出的系統仍然很難 debug。後來採用的方式不是再補一千行，而是把系統切成小模組，每個模組用範圍較小的 Spec 個別生成、測試，最後再整合。
這個經驗放到 prompt 維護也成立。
一份巨型規則寫得再完整，只要失敗時無法定位是哪個片段、哪個依賴、哪次變更造成的，團隊就只能繼續靠猜。模組切小以後，最直接的好處就是除錯範圍跟著縮小。
而且，不是所有內容都該永遠塞在 system prompt。
Identity、安全邊界、工具權限這類 stable control plane 可以固定載入。特定 framework 的操作方法、某個 domain 的處理細節，則可以做成 task-specific skill，在需要時才讀。這種 progressive disclosure 不只省 context，也讓共用政策和任務知識不必綁在同一個 release cycle。
如果 prompt 已經是 production infrastructure，我會要求它走 PR，而且至少交付以下資訊：
Agent 當然可以協助提出這種 PR。GitHub 的 custom agents 已經可以放在 .github/agents/ 裡，讓團隊共享重複的工作流程。真正的界線是：agent 可以提議修改自己的 instructions，但不能在 runtime 悄悄改掉目前約束它的規則。
這聽起來很保守。其實只是把我們早就熟悉的軟體交付原則，用回 agent 的 instruction layer。
一開始做 agent，大家最常討論的是句子怎麼寫、語氣怎麼調、該不該加一句「請仔細思考」。這些細節不會消失，但當系統開始碰 production，它們不再是最重要的問題。
更重要的問題反而很無聊：
現在跑的是哪一版？
它從哪些 source build 出來？
這次 diff 改了什麼？
CI 驗了哪些結構？
Eval 證明了哪些行為沒有退步？
壞掉時能不能回滾？
能穩定回答這些問題，才表示 prompt 不再是某個人電腦裡的神祕咒語，而是團隊真的維護得動的工程產物。
所以，prompt 當然可以先從一份 Markdown 開始。
只是當它開始控制 production，就不能只停在 Markdown。
看影片追技術