前言

前兩天我們談了心態(把 AI 當產線員工)和目標(追求穩定性與可重複性)。今天要開始動手拆解一個實際的問題:一份能重複使用的範本,內部到底該怎麼切分結構?

答案的關鍵,在於分清楚兩種完全不同性質的內容:System Prompt(系統指令) 和 User Prompt(使用者輸入)。

一、先搞懂這兩者本質上的差異

用最白話的方式理解:

• System Prompt:你「這個人」對 AI 下的長期指令,規定它該扮演什麼角色、遵守什麼規則、輸出什麼格式。這段話你只需要寫一次,之後每次使用都不太需要改動。
• User Prompt:你每一次實際想請 AI 處理的「這一次」的具體內容——例如這週的監控資料、這次要整理的事件清單。這段話每次使用都會不一樣。

回到 Day 1 的比喻:如果把整套範本想像成一份規格書,System Prompt 就是規格書裡「不管做哪一批產品都適用」的製造標準,User Prompt 則是「這一批要用的原料」。標準只訂一次,原料每次替換。

二、為什麼一定要把兩者分開?

如果你把「規則」和「這次的資料」混在一起寫,每次要用範本時,你都得重新把規則講一次、順便夾帶資料進去——這其實就是回到 Day 2 提到的「每週重新發明輪子」的陷阱。

把兩者分開之後,你會得到一個關鍵的好處:範本可以真正被「重複使用」,而不是「重複參考、每次修改」。 你之後要做的事情,理想上只剩下「把新資料貼進 User Prompt 的位置」,骨架完全不用碰。

這也是為什麼公司的 AI 工具會強調「先建立一個 .md 範本,之後只要丟資料進去就好」——本質上就是在幫你把 System Prompt 固定下來,你只需要處理 User Prompt 的部分。

三、System Prompt 該放哪些內容?(骨架)

一份完整的 System Prompt,通常要交代清楚以下幾件事:

1. 角色設定:AI 現在要扮演什麼身分?(例如:「你是一位資安治理單位的分析師,負責整理週報」)
2. 任務範圍:它要做的事情具體是什麼、不是什麼?(例如:「只整理已提供的事件資料,不進行資料以外的推測」)
3. 輸出格式:章節結構、標題層級、使用 Markdown 的哪些語法
4. 語氣與風格:正式或口語、詳細或精簡
5. 例外處理規則:資料缺漏、格式異常時該怎麼辦(這部分 Day 12 會深入談)

這五件事一旦寫定,理論上可以套用在「每一週」的報告產出上,不需要每次重新講。

四、User Prompt 該放哪些內容?(血肉)

User Prompt 相對單純,核心就是:這一次任務實際要用到的原始資料。例如:

• 這週從監控平台匯出的事件清單
• 需要特別註記的異常狀況
• (如果有的話)本次跟平常不同、需要臨時調整的地方

這裡有個容易忽略的細節:如果你的資料格式本身不固定(例如有時候欄位順序不一樣、有時候某個欄位是空的),建議在 System Prompt 裡就先講清楚「資料大概會長什麼樣子、可能有哪些變化」,而不是每次都在 User Prompt 裡臨時解釋一遍——不然 User Prompt 也會慢慢變得又臭又長,失去「血肉」該有的單純性。

五、實務上的切分練習

拿你手上已經在用、或正在設計的範本,試著把內容分成兩欄:

如果你發現自己在 User Prompt 裡反覆寫著類似的說明文字(例如每次都要提醒「請用正式語氣」),這就是一個訊號:這段話應該搬到 System Prompt 裡,而不是每次手動貼上。

小結

今天的重點很單純:一份好範本,骨架跟血肉要分清楚。 骨架決定了範本的穩定性(呼應 Day 2 的核心目標),血肉則是每次任務真正變動的部分。這個切分做得越乾淨,你之後「套公式」的效率就越高,也越不容易因為忘記講某個規則而讓輸出品質忽好忽壞。

下一篇,我們會往下一層走:當骨架和血肉都確定之後,怎麼找出你工作流程裡「真正該變動」和「絕對不該變動」的元素——這是設計出「即插即用」範本的關鍵一步。