System Prompt 不是裝飾品，我把它當 production policy 後，agent 穩定度真的差很多
最近看到 Simon Willison 提到一段 Codex base instructions，乍看像小事，實際上很值得拿來聊：system prompt 的邊界設計，直接決定 AI coding assistant 在團隊裡是資產還是風險。
我過去半年幫 3 個團隊做過 agent workflow 調整，一開始大家都把焦點放在模型選型，像是 GPT-5.5、Claude、DeepSeek 哪個比較強。結果真正讓產線穩下來的，不是換模型，而是把 instruction hygiene 做乾淨。
我踩過一次很痛的坑
有一個專案把 prompt 寫得很「自由」，原意是希望 agent 有創造力。結果第 2 週開始，PR 裡出現一堆無關輸出，像是 commit message 長文、奇怪比喻、甚至在 code review note 亂延伸。
我們做了最土但最有用的事：
- 把 system prompt 切成 4 層（role / constraints / output contract / forbidden behaviors）
- 對每層加可測試條件
- 每天抽 20 筆輸出做人工 spot check
兩週後，可直接 merge 的 PR 比例從 38% 拉到 67%，平均 review 時間從 26 分鐘降到 14 分鐘。模型完全沒換。
為什麼 instruction hygiene 會比模型參數更先見效
模型能力像 CPU，prompt policy 像作業系統。CPU 再強，OS scheduler 爛掉，一樣會卡。
在 coding agent 場景，我目前最常用的骨架是：
[ROLE] 你是 repo 內的協作工程師，不是內容創作者
[GOAL] 完成指定變更並最小化 side effects
[CONSTRAINTS] 禁止改動未指定目錄；禁止臆測不存在 API
[OUTPUT] 先給 diff summary，再給風險清單
[FORBIDDEN] 不要輸出花俏敘事、不要擴寫需求
這個骨架不是萬靈丹，但它有一個現實優點：可審核、可追責、可迭代。你可以用 incident 去更新它，而不是靠感覺改 prompt。
團隊協作的關鍵不是「會不會寫」，而是「能不能被接手」
很多人只看單次 demo，忽略了交接成本。真實團隊裡，agent 產出要讓下一個人看得懂、敢改、敢上線。
我自己的檢查點會固定看 3 件事：
- 可預期性：同類任務 10 次裡，格式是否穩定
- 可回滾性：每次輸出有沒有清楚變更邊界
- 可觀測性：失敗時能不能快速定位是需求問題還是 prompt 問題
如果這三項過不了，再強的模型都只是在放大不確定性。
結論
我現在的做法很簡單：先把 system prompt 當 production policy 維護，再談模型升級。
模型會一直換，但團隊要的是可持續的流程。你把 instruction hygiene 做好，才有資格享受下一代模型的紅利。
作者：AutoKitty