第二章
怎麼跟 LLM 下指令
你給 AI 的每一句話叫 Prompt（提示詞）。學會怎麼寫好 Prompt，就是學會怎麼寫「讓員工一次做對的工作交辦事項」。
Prompt 和 Prompt Engineering
先搞清楚兩個詞：
- Prompt：你給 AI 的「工作交辦事項」。你打的每一句話，每一段指令，都是 Prompt。
- Prompt Engineering：學會怎麼寫出「讓 AI 一次做對」的交辦事項。不是什麼高深技術，就是「把話說清楚」的學問。
比喻：交辦事項寫得好不好
你請一個新來的助理幫你買咖啡。
你說：「幫我買咖啡。」——他可能買了一杯美式、一杯拿鐵、或是三合一即溶。因為你沒講清楚。
你說：「去樓下 7-11 買一杯大杯冰美式，不要加糖。」——他一次搞定，不用再打電話問你。
Prompt Engineering 就是學會寫出第二種交辦。
你請一個新來的助理幫你買咖啡。
你說：「幫我買咖啡。」——他可能買了一杯美式、一杯拿鐵、或是三合一即溶。因為你沒講清楚。
你說：「去樓下 7-11 買一杯大杯冰美式，不要加糖。」——他一次搞定，不用再打電話問你。
Prompt Engineering 就是學會寫出第二種交辦。
三層溝通模型：目標、邊界、情境
每一次跟 AI 溝通，你需要想清楚三層東西：
- 目標（要什麼）——你希望 AI 產出什麼結果
- 邊界（不要什麼）——你不希望 AI 做什麼、哪些是禁區
- 情境（在什麼狀況下）——目前的背景、限制條件、已有的東西
很多人只講了第一層（我要一個購物車功能），然後 AI 就自由發揮了。你收到的東西可能完全不是你要的，但你也不能怪 AI——因為你沒告訴它不要什麼。
核心觀念
「不要什麼」比「要什麼」更重要。因為「要什麼」的範圍是有限的，但「AI 可能自作主張做的事」是無限的。你沒說不要，它就可能會做。你得用邊界把它框住。
比喻：裝潢師傅
你跟裝潢師傅說：「幫我裝潢客廳。」
師傅很認真，做了天花板造型、電視牆、木地板、間接照明、訂製書櫃。
但你只是想刷白漆、換一盞燈。
師傅做錯了嗎？沒有。他做了「裝潢客廳」這件事。是你沒說清楚你的邊界：不要動天花板、不要做電視牆、不要換地板。
跟 AI 溝通也一樣：不說清楚邊界，它就會「好心幫你多做」。
你跟裝潢師傅說：「幫我裝潢客廳。」
師傅很認真，做了天花板造型、電視牆、木地板、間接照明、訂製書櫃。
但你只是想刷白漆、換一盞燈。
師傅做錯了嗎？沒有。他做了「裝潢客廳」這件事。是你沒說清楚你的邊界：不要動天花板、不要做電視牆、不要換地板。
跟 AI 溝通也一樣：不說清楚邊界，它就會「好心幫你多做」。
你不知道可能有什麼問題
三層模型的「情境」這一層最容易被忽略，因為——你不知道你不知道什麼。
比喻：蓋房子的故事
有個台灣人要蓋房子，找了三國的建築師來：美國人、日本人、台灣人。
美國人蓋了一棟漂亮的木造房子。日本人蓋了一棟鋼骨結構的建築。台灣人也蓋了鋼筋混凝土的房子。
結果地震來了。
美國人蓋的房子倒了——因為美國很多地方沒地震，他不知道要考慮耐震。
日本人和台灣人蓋的都沒事——因為他們的「情境知識」包含了「這裡會地震」。
重點不是技術差，而是「情境」不同。你跟 AI 講「幫我蓋房子」，它不一定知道你在台灣、台灣會地震、需要耐震結構。你得主動告訴它。
有個台灣人要蓋房子，找了三國的建築師來：美國人、日本人、台灣人。
美國人蓋了一棟漂亮的木造房子。日本人蓋了一棟鋼骨結構的建築。台灣人也蓋了鋼筋混凝土的房子。
結果地震來了。
美國人蓋的房子倒了——因為美國很多地方沒地震，他不知道要考慮耐震。
日本人和台灣人蓋的都沒事——因為他們的「情境知識」包含了「這裡會地震」。
重點不是技術差，而是「情境」不同。你跟 AI 講「幫我蓋房子」，它不一定知道你在台灣、台灣會地震、需要耐震結構。你得主動告訴它。
這就是為什麼很多人覺得「AI 好笨」——不是 AI 笨，是你沒給它足夠的情境。它不知道你的產業、你的客戶、你的限制條件。你得像跟一個外國新員工交接工作一樣，把所有背景交代清楚。
新手 vs 有效的指令
來看幾個實際的對比，你就知道差異有多大：
新手的說法
「幫我做一個網站。」
有效的說法
「用 Next.js 做一個單頁式產品介紹頁，
內容包含：Hero 區塊、三個功能特色、
價格方案比較表、聯絡表單。
風格參考 Linear.app，深色主題。
不需要後端、不需要資料庫。」
內容包含：Hero 區塊、三個功能特色、
價格方案比較表、聯絡表單。
風格參考 Linear.app，深色主題。
不需要後端、不需要資料庫。」
新手的說法
「登入功能壞了，幫我修。」
有效的說法
「登入頁面按送出後，console 顯示
401 Unauthorized。
後端是 Express + JWT，
token 有正確產生但前端沒存到
localStorage。
可能是 CORS 問題或 response
header 沒設對。」
401 Unauthorized。
後端是 Express + JWT，
token 有正確產生但前端沒存到
localStorage。
可能是 CORS 問題或 response
header 沒設對。」
新手的說法
「加一個搜尋功能。」
有效的說法
「在商品列表頁加搜尋框，
用前端過濾就好，不用打 API。
搜尋範圍只包含商品名稱，
不搜描述。打字時即時過濾，
不用按送出按鈕。
沒結果時顯示『找不到相關商品』。」
用前端過濾就好，不用打 API。
搜尋範圍只包含商品名稱，
不搜描述。打字時即時過濾，
不用按送出按鈕。
沒結果時顯示『找不到相關商品』。」
先後順序陷阱：先講跟後講，成本差 10 倍
除了「說什麼」，「什麼時候說」也很重要。很多需求如果在一開始就提出來，AI 會自然地把它融入架構。但如果你等到做完了才補充，AI 就得把原本的東西拆掉重做。
比喻：水電管線
蓋房子的時候，水電管線要在砌牆之前就埋好。如果牆都砌好了，你才說「欸，這裡加一個插座」——那就得打牆、埋管、補牆、重新粉刷。
本來只要 100 塊的事，變成 1000 塊。
跟 AI 溝通也一樣。在開始動工前就把需求說完整，改起來只是調整設計圖。動工後才補需求，就是打牆重來。
蓋房子的時候，水電管線要在砌牆之前就埋好。如果牆都砌好了，你才說「欸，這裡加一個插座」——那就得打牆、埋管、補牆、重新粉刷。
本來只要 100 塊的事，變成 1000 塊。
跟 AI 溝通也一樣。在開始動工前就把需求說完整，改起來只是調整設計圖。動工後才補需求，就是打牆重來。
案例：i18n 國際化
i18n 是 internationalization 的縮寫（i 和 n 之間有 18 個字母）。白話說就是：讓你的網站支援多種語言。
一開始就說（成本 1x）
「做一個產品介紹頁，
要支援中文和英文切換，
用 i18n 架構，文字都放在
語言檔案裡，不要寫死在 HTML。」
AI 從第一行程式碼就會用正確的架構。
要支援中文和英文切換，
用 i18n 架構，文字都放在
語言檔案裡，不要寫死在 HTML。」
AI 從第一行程式碼就會用正確的架構。
做完才說（成本 10x）
（網站已做完，30 個檔案，
所有文字都寫死在 HTML 裡）
「欸，加一個英文版。」
AI 要翻遍 30 個檔案，
把每一段文字抽出來，
建立語言檔，重寫引用方式。
可能改一改還會改壞其他功能。
所有文字都寫死在 HTML 裡）
「欸，加一個英文版。」
AI 要翻遍 30 個檔案，
把每一段文字抽出來，
建立語言檔，重寫引用方式。
可能改一改還會改壞其他功能。
記住這個原則
在動工前，把你「可能會要的東西」都先列出來。就算不確定要不要做，先告訴 AI「可能會有 XX 需求」，讓它預留空間。砌牆前埋管線是 100 塊，砌完牆才打洞是 1000 塊。
案例：搜尋功能的邊界比你想像的複雜
你跟 LLM 說「加一個搜尋功能」，聽起來很簡單，但搜尋其實有很多種：
| 搜尋類型 | 白話 | 例子 |
|---|---|---|
| 精確搜尋 | 打什麼找什麼，一字不差 | 搜「iPhone 16」只找到 iPhone 16 |
| 模糊搜尋 | 打錯字也能找到 | 搜「iPhoen」也能找到 iPhone |
| 範圍搜尋 | 在某個範圍內搜 | 價格 1000-5000 元 |
| 過濾 Filter | 用條件篩選 | 只看紅色、只看 XL |
| 全文搜尋 | 搜內文，不只標題 | 搜「退貨」會找到文章裡提到退貨的 |
| 即時搜尋 | 打字的同時就跑出結果 | Google 搜尋的自動建議 |
注意
如果你只說「加搜尋功能」，LLM 可能只做精確搜尋。但你的使用者期待的是模糊搜尋 + 過濾。這就是為什麼邊界要講清楚。
下指令的 Checklist
每次下指令前，過一遍這個清單，可以幫你大幅提高品質、減少來回修改：
目標面（要什麼）
- 我要的最終產出是什麼？（一個頁面？一支 API？一段分析？）
- 它給誰用的？（一般使用者？管理者？我自己？）
- 成功的標準是什麼？（能登入就好？還是要有忘記密碼流程？）
- 有沒有參考範例？（像 XXX 網站那樣）
邊界面（不要什麼）
- 哪些功能不要做？（不要社群登入、不要第三方套件）
- 哪些技術不要用？（不要 jQuery、不要 class component）
- 複雜度上限在哪？（先做最簡單的版本就好）
- 有什麼已經做好了，不要動的？（資料庫結構已定，不能改）
情境面（在什麼狀況下）
- 目前用什麼技術棧？（Next.js + Supabase + Tailwind）
- 現有的檔案結構長什麼樣？（列出主要資料夾）
- 有什麼已知的限制？（免費方案、流量限制、手機要能用）
- 這是全新專案，還是要加進現有系統？
- 團隊有幾個人？只有你自己？（影響程式碼複雜度的決定）
不用每次都寫這麼多
小任務不需要寫完整個 checklist。但大任務（做新功能、開新專案、改架構）一定要盡量涵蓋。養成習慣之後，你會自然知道哪些該講。
CLAUDE.md：你的「邊界文件」
如果你用 Claude Code，有一個非常重要的檔案叫 CLAUDE.md。它是放在你專案根目錄的一個文字檔，AI 每次啟動時都會自動讀取。
比喻：新員工的 SOP 手冊
想像你請了一個新員工。他第一天上班，你會給他一本公司 SOP：「我們用什麼工具」、「我們的命名規則」、「客戶的忌諱」、「出包了找誰」。
想像你請了一個新員工。他第一天上班，你會給他一本公司 SOP：「我們用什麼工具」、「我們的命名規則」、「客戶的忌諱」、「出包了找誰」。
CLAUDE.md 就是 AI 的那本 SOP 手冊。你把專案的規則、偏好、禁忌、架構說明全部寫在裡面。這樣你不用每次開新 Session 都重複講一遍——AI 每次都會先讀這本手冊。
一個 CLAUDE.md 裡通常會寫什麼：
- 這個專案用什麼技術（Next.js 14 + App Router + Supabase）
- 程式碼風格（用 TypeScript、用 functional component、不用 any）
- 檔案放哪裡（元件放 components/、API 放 app/api/）
- 不能做什麼（不要動 database schema、不要改 auth 邏輯）
- 常見的坑（這個專案的 API 有 rate limit，一分鐘最多 60 次）
CLAUDE.md 的好處
寫一次，每個 Session 都有效。前一章講過 Context Window 的問題——每次開新 Session，AI 都會忘記之前的對話。但 CLAUDE.md 是持久的。你寫進去的東西，AI 每次啟動都會讀。這是對抗 Context 遺失最有效的方法之一。
本章小結
這一章你學到了以下幾件事：
- Prompt 就是你給 AI 的工作交辦事項，Prompt Engineering 就是學會怎麼寫讓 AI 一次做對的交辦。
- 三層溝通模型——目標（要什麼）、邊界（不要什麼）、情境（在什麼狀況下）。大部分人只講了目標，忘了邊界和情境。
- 「不要什麼」比「要什麼」更重要——裝潢師傅的故事：不說不要，AI 就會好心多做。
- 你不知道你不知道什麼——蓋房子的故事：情境知識（地震、法規、限制）要主動告訴 AI。
- 先後順序影響巨大——水電管線的故事：先講成本 1x，後講成本 10x。
- CLAUDE.md 是你的邊界文件——寫一次，每個 Session 都有效，是對抗 Context 遺失的最佳武器。
現在你知道怎麼「說話」了。但光會說話還不夠——你還需要知道正確的「做事順序」。下一章我們來講工作流程。