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