前言

Day 3 我們把範本切成了 System Prompt(骨架)和 User Prompt(血肉)。今天要更進一步:就算在血肉、甚至骨架內部,其實也還藏著「固定」跟「變動」兩種東西混在一起。今天要學的,是一種更細緻的拆解能力——變數化思維。

這個能力,是讓範本從「堪用」進化到「真正好用、好維護」的關鍵分水嶺。

一、為什麼骨架內部也需要再拆一次?

Day 3 的切分是「大範圍」的:整段規則歸骨架,整份資料歸血肉。但實務上你會發現,即使是骨架裡的規則,也不是每一條都「永遠不變」。

舉個例子,你的 System Prompt 裡可能寫著:

「請將報告分成『事件摘要』、『處理狀況』、『待辦事項』三個章節。」

這句話裡,「分成三個章節」這個結構幾乎不會變,但「章節該叫什麼名字」——如果哪天主管希望多加一個『風險評估』章節,這句話就得跟著改。這代表:同一句規則裡,其實同時包含了「穩定的邏輯」和「可能調整的具體內容」。

二、變數化思維:把「內容」和「邏輯」拆開看

變數化思維的核心,是寫程式時很基本的一個習慣:任何可能重複出現、或未來可能需要修改的具體值,都不要寫死在邏輯中間,而是獨立出來,用一個「名稱」代表它。

套用到我們的範本設計上,可以用這個方式檢查每一條規則:

「如果這條規則裡的某個具體內容,未來有可能因為公司政策、主管要求、或資料來源改變而需要調整——那這部分就該被『標記出來』,跟旁邊不太會變的邏輯分開放。」

實際操作上,不用真的寫程式語法的變數,用簡單的標記方式就夠了,例如:

請將報告分成以下章節(章節清單可依需求調整):
- 事件摘要
- 處理狀況
- 待辦事項

這樣寫的好處是:未來要加減章節時,你很清楚該改哪一行,而不用重新讀一遍整段規則、擔心改到不該改的地方。

三、三種變動頻率,決定你怎麼安排位置

在你的工作流程裡,「會變動的東西」其實不是只有一種變動速度。建議分成三個層次來看:

這個分層,其實就是把 Day 3 的「骨架/血肉」二分法,再往下切出一層「骨架裡的活關節」。你會發現,範本設計做得好的人,通常都對這三層的分界線很敏感——他們一看到一條規則,幾乎能立刻判斷「這句話大概多久會改一次」。

四、一個實用技巧:用「假設情境」測試你的變數化夠不夠

檢查自己有沒有拆對的簡單方法,是問自己幾個假設情境:

• 如果主管突然說「以後週報要多一個章節」,我要改的地方多不多?散不散?
• 如果監控平台換了一套新系統,匯出的欄位名稱變了,我要改的地方是集中在一處,還是要翻遍整份範本找出所有寫死的欄位名稱?
• 如果換一個同事接手這份範本,他能不能一眼看出「這裡是可以調整的地方」,還是得靠你口頭交接才知道?

如果這三個情境的答案都是「要改的地方很集中、很好找」,代表你的變數化做得不錯。如果答案是「要東找西找,還怕漏改」,代表目前規則和內容還黏得太緊,值得回頭重新拆解。

五、今天的行動練習

回到你目前手上的範本草稿(或者 Day 1 練習時寫下的筆記),挑出其中 3-5 條規則,對照上面的三層變動頻率分類表,標記出每一條分別屬於哪一層。如果發現有規則其實混雜了兩層的內容(例如「固定的邏輯」裡包著「可能會改的細節」),試著把它們拆開來寫。

小結

今天的核心觀念是:「固定不變」和「每次變動」不是只存在骨架與血肉之間的一刀切,骨架內部同樣需要用「變動頻率」再細分一次。 拆得越細緻、標記得越清楚,你的範本未來要修改、要交接、要應付需求變化時,成本就越低——這正是 Day 2 談的「可重複性」在實務設計上真正落地的樣子。

下一篇,我們要開始討論一個更根本的問題:在動手寫任何格式規則之前,你怎麼定義「什麼是一份好報告」?先有人類的標準,才談得上讓 AI 產出符合標準的內容。