準備 AI 任務脈絡：把資料、限制與完成條件放對位置

從可用的資料開始

這個「給了什麼」的學問，就是上下文工程（context engineering）：把模型完成任務所需要的資訊——指令、資料、範例、限制、工具——組織好、餵進去的能力。

想像一位能力頂尖、但每次會議開始都完全失憶的顧問。他不知道你的公司在做什麼、不知道上週開會的結論、不知道你老闆的地雷。你會怎麼跟他合作？你會準備一份完整的 briefing：背景、目標、限制、過去的嘗試、好與壞的範例。

上下文工程就是寫這份 briefing 的能力。模型每一次對話能處理的資訊量（上下文視窗）是它的「會議時間」——有限、而且塞太滿反而效果變差。你的工作是在有限的視窗裡，放進密度最高的正確資訊。

指令：你要它做什麼、產出什麼格式、扮演什麼角色。這是傳統提示詞的範圍，也是最不需要花俏的部分——清楚、具體、有驗收標準就夠了。
資料：任務相關的文件、數據、程式碼。與其問「幫我寫一封拒絕供應商的信」，不如附上對方的報價信和你們的採購政策。資料的品質直接決定輸出的上限。
範例：一到三個「好的長這樣」的示範，效果常常勝過三段形容詞。要 AI 模仿你的寫作風格？貼三段你寫過的文字，比描述「輕鬆但專業」有效十倍。
限制：不能做什麼、必須遵守什麼。字數上限、禁用詞、法規紅線、「不確定就說不確定」。限制寫得越明確，事後修改越少。
記憶與工具：進階場景裡，AI 可以連接你的知識庫（RAG，檢索增強生成——白話說就是「先查你的資料庫再回答」）或呼叫外部工具。原理相同：在對的時機，把對的資訊放進視窗。

把十份文件全部貼進去，以為資訊越多越好。實際上不相關的資訊會稀釋模型的注意力，長上下文的中段內容尤其容易被忽略。先自己篩選，只給任務需要的部分——你花三分鐘挑資料，換來的是輸出品質的等級差。

舊版規格和新版規格一起貼、三年前的數據和今年的混在一起。模型不會自動知道哪份是對的，它會挑一個、或更糟——混著用。餵資料前先自己對齊版本。

長對話累積的歷史會持續佔用視窗，前面的討論會污染後面的任務。換任務就開新對話，需要延續的結論用一段摘要帶過去，比拖著整串歷史乾淨得多。

「幫我寫好一點」不是標準。「目標讀者是完全沒碰過 AI 的長輩、全文不超過 800 字、每段不超過三行」才是。沒有驗收標準的任務，AI 只能猜，而你只能來回改。

背景：我是誰、這個任務為什麼存在。
任務:具體要產出什麼。
資料：（貼上經過篩選的相關資料）
範例：好的產出長這樣（貼一到三個）。
限制：格式、字數、紅線、「數字必須來自我給的資料，不要自己補」。
驗收：怎樣算完成。

這個模板的每一行都在回答同一個問題：那位失憶的天才顧問，需要知道什麼才能一次做對？

例如兩份活動資料出現不同時間，明確標示各自日期與來源，請工具列出衝突而非合併成單一答案。完成條件可以寫成「每個日期有來源；未知欄位標記待確認；不對外發送」。下次接續時保留這張卡與已確認結果，會比重新貼上全部對話更容易理解。

方案、可用功能與限制會更新，請以連結中的官方說明及帳號當下顯示為準。本文的練習是編輯設計的示例，不是工具效能實測。