為什麼提示詞越寫越長，結果卻沒有越來越好？

很多人學習使用 AI 的第一步，是研究如何寫 Prompt。

你開始加入角色：

「你是一位有十年經驗的行銷顧問。」

接著補充任務：

「請幫我寫一篇社群貼文。」

再加入格式、語氣、字數、受眾與限制條件。提示詞愈來愈完整，AI 的回答通常也會有所改善。

但當任務變得複雜，你很快會遇到另一個問題：

AI 不知道你的品牌過去寫過什麼、不知道目前的專案進度、不知道哪些規則已經確認，也不知道哪些方法曾經嘗試過但失敗了。

它不是不會做，而是缺少背景。

就像你找來一位能力很好的新同事，只交給他一句工作指令，卻沒有提供品牌資料、過往案例、客戶需求與公司規範，再聰明的人也只能一邊猜、一邊做。

Prompt 解決的是「你怎麼說明任務」。

Context 解決的是「AI 根據什麼理解任務」。

Context Engineering 到底是什麼？

Anthropic 將 Context Engineering 視為 Prompt Engineering 的自然延伸。

Prompt Engineering 關注的是：如何寫出清楚、有效的指令。

Context Engineering 關注的則是：在 AI 回答或執行任務的當下，應該讓它取得哪些資訊，又應該排除哪些不相關、過時或彼此衝突的內容。

這些資訊可能包括：

• 系統規則與角色定位

• 使用者目前的需求

• 品牌背景與專案資料

• 過去的對話與決策紀錄

• 正確的輸出範例

• 可以使用的工具

• 最新的外部資料

• 當前任務的執行狀態

• 不能違反的限制條件

因此，Context Engineering 不是把所有資料全部丟給 AI。

真正的重點是：

在正確的時間，提供完成當前任務真正需要的資訊。

資料太少，AI 只能猜。

資料太多，重要內容反而可能被埋沒。

資料互相衝突，AI 就不知道應該遵守哪一套規則。

Prompt 與 Context，有什麼不同？

假設你要 AI 幫忙撰寫一封課前通知。

只有 Prompt 時，你可能會這樣說：

「請幫我寫一封專業、親切的實體課程課前通知。」

這個指令沒有錯，但 AI 並不知道：

• 課程名稱是什麼

• 上課日期與地點

• 學員需要先安裝哪些工具

• 是否需要購買付費方案

• 幾點可以提早抵達

• 品牌平常使用什麼語氣

• 過去的課前通知長什麼樣子

加入 Context 後，任務會變成：

「以下是課程資料、學員背景、安裝清單、交通資訊、過去通知範例與品牌語氣。請依照固定結構，撰寫一封新的課前通知；若資料中沒有出現的資訊，不要自行補充。」

兩者的差異，不只是提示詞長短。

第一種是要求 AI 憑經驗生成。

第二種是要求 AI 根據真實資料完成任務。

建立有效 Context 的 6 個步驟

第一步：先定義這次真正要完成的成果

不要一開始就蒐集一大堆資料。

先問自己：

「這次希望 AI 最後交付什麼？」

例如：

• 一封可以直接寄出的 Email

• 一份完整的活動企劃

• 一張社群圖文的文字架構

• 一份網站需求文件

• 一個可以實際操作的系統功能

• 一份根據指定資料產生的分析報告

成果愈明確，AI 才愈容易判斷哪些背景重要、哪些資訊可以忽略。

錯誤方式：

「幫我整理一下這些資料。」

較好的方式：

「請將資料整理成提供給新進員工使用的一頁式操作 SOP，包含準備事項、操作步驟、常見錯誤與異常處理方式。」

第二步：補上必要背景，而不是所有背景

背景資訊的功能，是減少 AI 猜測。

你可以優先提供：

• 這件事為什麼要做

• 使用者或讀者是誰

• 目前進行到哪個階段

• 已經確認哪些決策

• 過去遇過什麼問題

• 這次最重要的判斷標準

例如，請 AI 規劃課程內容時，「課程受眾是完全沒有程式經驗的初學者」就非常重要。

但公司的成立年份、辦公室地址或與這堂課無關的品牌故事，可能暫時不需要放進來。

Context Engineering 的第一項能力，不是增加資料，而是判斷資料是否相關。

第三步：把規則、偏好與事實分開

很多 AI 任務失敗，是因為不同類型的資訊混在一起。

建議將 Context 分成三區：

事實

不能自行改變的資訊。

例如課程日期、價格、地址、產品功能、人物姓名與已確認的專案決策。

規則

AI 必須遵守的要求。

例如使用台灣繁體中文、不能虛構數據、標題不得超過 20 字、不得更改品牌名稱。

偏好

可以依情況調整的風格。

例如語氣親切但專業、少用艱澀術語、段落簡短、避免過度誇張的行銷詞。

把三者分開後，AI 會更清楚哪些內容不能動、哪些只是方向參考。

第四步：提供範例，讓 AI 看見你要的標準

與其用十句形容詞解釋「我要什麼風格」，不如直接提供一個正確範例。

你可以告訴 AI：

• 這是我們過去最滿意的文章

• 這是正確的標題格式

• 這是可以接受的輸出

• 這是不要出現的錯誤版本

• 請保留它的結構，但不要複製內容

範例的價值在於，它把抽象的偏好變成具體標準。

例如「語氣自然」每個人的理解不同，但一段真實的品牌文案，可以讓 AI 直接看見句子長度、用字習慣、段落節奏與銷售強度。

第五步：要求 AI 先檢查資料，再開始執行

不要每次都讓 AI 收到資料後立刻產出最後答案。

複雜任務可以拆成：

1. 整理目前取得的資訊

2. 找出缺漏與衝突

3. 說明準備採用的做法

4. 執行任務

5. 根據檢查標準重新審查

例如：

「請先列出你目前掌握的課程日期、地點、安裝工具與注意事項。若資料互相矛盾，請先標記，不要直接撰寫通知。」

這個步驟可以避免 AI 在錯誤資料上一路完成一份看似完整、實際卻不能使用的成果。

第六步：把成功做法保存成可重複使用的系統

一次成功的 Prompt，只能幫你完成一次任務。

一套整理好的 Context，才能持續使用。

你可以逐步建立：

• 品牌說明文件

• 固定語氣與用字規範

• 常見任務模板

• 正確成果範例

• 禁用詞清單

• 專案決策紀錄

• 客戶與產品資料

• 任務完成後的檢查表

下一次執行相似任務時，不必從頭解釋，而是讓 AI 讀取同一套基礎資料，再加入當次任務的新資訊。

這也是個人 AI 助理、企業知識庫與 AI Agent 能夠維持一致性的基礎。

一個可以直接使用的 Context 模板

你可以使用以下結構開始：

任務目標

這次需要完成什麼成果？成果會用在哪裡？

使用對象

誰會閱讀或使用？對方具備什麼背景？

必要背景

有哪些事實會影響這次任務？

已確認決策

哪些方向已經定案，不需要重新討論？

必須遵守的規則

有哪些內容不能修改、不能出現或不能自行補充？

參考範例

有哪些過去成果可以作為標準？

輸出格式

最後應該使用什麼結構、篇幅與格式？

檢查標準

完成後需要確認哪些項目？

不確定時的處理方式

資料不足時，是標記待確認、提出問題，還是保留空白？

這份模板看起來比一句 Prompt 多了一些準備時間，但對於會反覆進行的任務，後續可以大幅減少修改、重做與重新說明。

Context Engineering 最常見的 4 個錯誤

錯誤一：把所有資料一次塞進去

Context 不是資料倉庫。

大量無關資訊會增加干擾，也可能讓 AI 抓錯重點。真正需要的是與當前任務最相關的資料。

錯誤二：新舊規則同時存在

如果舊文件寫「使用正式語氣」，新指令卻要求「活潑口語」，AI 必須猜測哪一個優先。

更新規則時，要同步移除或標記舊版本。

錯誤三：只保存結果，沒有保存決策原因

只記錄「最後選擇方案 B」，未來的 AI 並不知道為什麼不能用方案 A。

重要專案最好同時記錄：

• 做了什麼決定

• 為什麼這樣決定

• 放棄了哪些方案

• 什麼情況下可以重新評估

錯誤四：把 AI 的記憶當成永遠正確

AI 的記憶、對話紀錄與摘要都可能不完整，也可能保留過時資訊。

真正重要的規則與事實，仍應該放在可以檢查、更新和管理的正式文件裡，而不是只存在某一段聊天紀錄中。

從「會問 AI」進階到「會設計 AI 的工作環境」

Prompt Engineering 教你把需求說清楚。

Context Engineering 則進一步要求你思考：

• AI 完成這件事需要知道什麼

• 資料從哪裡取得

• 哪些資訊應該長期保存

• 哪些資料只適用於這一次

• 規則衝突時該如何處理

• 怎麼確認 AI 沒有偏離目標

這也是從聊天工具進入 AI Agent、AI 工作流與 Agentic Coding 時，最重要的能力之一。

因為當 AI 開始執行多步驟任務，它需要的不只是一個聰明的指令，而是一個清楚、可信任、可以持續更新的工作環境。

寫在最後～

AI 不一定需要更多資訊，而是需要更正確的資訊

當 AI 的成果不理想，我們很容易立刻修改 Prompt，加入更多形容詞、更多要求與更多角色設定。

但很多時候，真正缺少的不是一句更厲害的指令，而是完成任務所需的背景、資料、規則與範例。

Prompt 決定 AI 這次要做什麼。

Context 決定 AI 能不能真正理解這件事。

而工作流決定這個成果能不能被穩定地重複。

當你開始把品牌資料、專案規則、正確範例與檢查標準整理成系統，你就不再只是「請 AI 幫忙」。

你正在建立一位能夠理解你的工作方式，並且持續參與真實任務的 AI 協作者。