AI 不是在回答你，而是在猜下一個字

生成式 AI 做的事其實只有一件：根據你給的文字，預測接下來最可能出現的內容。

它沒有你的工作背景，也不知道你為什麼問。當你打出「幫我寫一封信」，它面前展開的是幾百萬種合理的可能，只能挑一條最平均、最無聊的路走。

所以 Prompt 設計不是話術，也沒有什麼神奇咒語。它只有一個目的：把 AI 面前那片過大的可能性，縮小到你真正要的那一小塊。

Prompt 需要一副骨骼

在《詠唱者》這門課，最主要的核心概念是「骨骼驚奇」：設計 Prompt 的時候，需要有一個架構。

這副骨骼是一個 Prompt 最重要的本體——把資訊分門別類，讓模型知道哪句是指令、哪段是資料、哪裡是限制。有了本體，接下來的一切都只是變形。

Prompt 的設計指南有很多的討論，大家可能還聽過另一套講法，包含 Persona（人物設定）、Task（任務）、Context（情境脈絡）、Format（格式）。它跟《詠唱者》裡談的內容，底層邏輯是相同的：

# 任務        →  Task
# 任務說明    →  Context
# 輸出限制    →  Format
# 角色  →  Persona

名字不同、寫法不同，做的事一樣。

也因為是骨骼而不是必填表格，這些元素本來就是拿來調用的。 我們今天要針對不同的場景設計 Prompt，需要提供的內容自然也不一樣：

• 「這句英文的語氣會不會太強硬？」——這個問題，可能一句話就夠。
• 「幫我整理這份會議紀錄的待辦事項」——這個任務，補上格式（條列、含負責人）可能就夠。
• 要產出一份對外提案——小孩子才選擇！角色、任務、背景、格式、參考資料、限制，全上。

判斷標準不是「模板填滿了嗎」，而是：有什麼是 AI 猜不到、但會影響答案的？我講了嗎？

你心裡要先有輸出的想像

這是我覺得最容易被跳過、卻最關鍵的概念。

在寫 Prompt 的過程中，其實我們對輸出已經有一個想像——大概知道自己要的東西長什麼樣子，是一張表、一段對客戶的說明、還是三個可以拿去開會的選項。

有這個想像，前面那副骨骼才有東西可以填；沒有這個想像，寫再漂亮的結構也只是把模糊丟給模型，然後拿回一份同樣模糊的答案。

Prompt 寫不好，很多時候不是不會下指令，而是自己也還沒想清楚要什麼。

Zero-shot 與 Few-shot

理解了底層之後，可以再往外延伸一些技巧。

Zero-shot 就是直接下指令，不給任何範例。Few-shot 則是附上一到幾個範例，告訴模型「照這個樣子做」。

請將以下客戶回饋分類。

範例：
「出貨很快，但包裝有點壓壞」→ 物流：正面／包裝：負面
「客服回覆很慢」→ 客服：負面

現在請分類：（貼上你的資料）

這兩者的作用，都是讓模型更好地遵循我們期望的輸出樣貌。你說「專業一點」、「格式整齊一點」，模型不知道你的標準在哪；直接給一個你認可的範例，效果會差非常多。

CoT 思維鏈在兩個方向都能用

Chain of Thought（思維鏈） 最常見的用法，是在問題後面加一句「請一步一步說明你的推理過程」，讓模型不要一步跳到答案。

它的價值在於：你看得見它的脈絡。 當這件事沒有絕對的標準答案——策略判斷、風險評估、方案取捨——你真正該檢查的不是結論，而是它憑什麼這樣想。脈絡攤開來，你才知道它是哪一步歪掉，或哪個前提跟你的認知不同。

但這個概念也可以反過來用：把它套進我們自己的 Prompt 設計裡，告訴模型「你在執行這個任務時，需要遵循哪些步驟、有哪些規範、先後順序是什麼」。

請依以下順序處理：
1. 先閱讀全文，列出所有提到的風險項目
2. 針對每一項標註影響範圍
3. 最後才排序並給出建議

一邊是讓模型把步驟講出來，一邊是我們先把步驟講給它聽。方向相反，但骨子裡是同一件事：讓推理過程被明確地拆開。

有趣的 prompting 方法分享：ToT 思維樹（很像什麼 emoji 吧XD）

之前在一篇論文中看到 Tree of Thought（思維樹） 的概念，趁機跟大家分享！

如果 CoT 是一條線走到底，ToT 就是同時展開幾條路再互相比較。最簡單的觸發方式：

「想像有三位不同領域的專家在回答這個問題，請分別寫出他們的思路，最後比較並整合出結論。」

適合用在你想從比較平行、多樣的維度去看同一件事的時候：這個定價策略有哪些風險、這場活動有幾種做法、不同角色會怎麼看這份提案。

它的價值不在算得更準，而在把「我只想到一種答案」的盲點打開。

設定邊界（rails）

最後補一個在 AI Agent 時代很常被提到的概念：邊界。

前面的技巧都在說「我要什麼」，Rails 可以反過來規定 「你不可以做什麼」。它的類型非常多，這裡簡單舉三種使用場景：

1. 不要離題

「你的分析必須圍繞產品功能與特性，避免討論無關內容。」

2. 不要亂編

「只使用我提供的資料回答，資料中沒有的請直接說『資料中未提及』。」

3. 守住底線

「文案中不得包含任何基於性別、年齡、種族的歧視性用語。」

其實概念很簡單：你交辦事項給同事時，會順口補一句「這份是對外的，別提還沒公開的價格」，那句話，就是你的限制條件（也就是我這邊稱的邊界）。

結語：幾個最小知識點

1. 有結構的輸入、有品質的輸入，會帶來更好的輸出。

而且這件事的好處會複利。當你手上有了這套底層方法論，就能泛用到各種不同的場景，把相同的架構快速套用到不同的對象，或是相似的任務情境中。

骨骼一副，變形無數。

2. 掌握底層邏輯，比記住技巧更耐用。

模型一直在進步，未來或許不再需要這麼複雜的設計。但只要你理解了底層在做什麼，就會更清楚該如何迭代——知道這次為什麼沒拿到想要的答案、下一輪該補哪一塊。這才是在跟 LLM 互動的過程中，能持續拿到好結果的原因。

3. 適當的添加限制能讓結果更貼近你的想像。

透過限制一定程度的條件、設立相關規則，可以讓輸出收在你預期的範圍內，而不是每次都要從一堆偏離的內容裡撈。

最後，也是最重要的：

不要盲目相信模型的輸出。

我們依然需要去校正、判斷與思考，再採用模型協助我們加速產出的內容。AI 是加速器，不是替你負責的人。

在 nuvaClub 的首發，希望大家不嫌棄我的文章！！如果有不完整之處，也請大家不吝指教><

我是 Ken，一起在 AI 時代下衝浪吧🏄