懶人包（TL;DR）
- Prompt Engineering 管理「今次要 AI 做甚麼，以及答案應該長怎樣」。
- Context Engineering 管理「AI 在每一步應該看到哪些資料、記憶、規則與工具資訊」。
- Harness Engineering 管理「AI 在甚麼環境工作、可以做甚麼、如何驗證、失敗時怎樣處理」。
- 三者不是新技術淘汰舊技術，而是由一次回答，逐層走向可重複、可執行、可監察的 AI 工作系統。
以前使用生成式 AI，大家最常問的是：「點樣寫一條更好的 Prompt？」但當 AI 開始讀取公司文件、搜尋網頁、使用工具，甚至代你完成多步驟任務，單靠一句寫得漂亮的指令已經不足以解決所有問題。
去到 2026 年，更實際的問題是：你有沒有給 AI 正確資料？它能否在合適時間調用工具？它做錯時會不會停下來？最終結果又有沒有經過檢查？這正是 Prompt Engineering、Context Engineering 與 Harness Engineering 三者需要分工的原因。
一條容易記住的公式：
可靠 AI 交付 ≈ 模型能力 × Prompt 清晰度 × Context 適配度 × Harness 可靠度
這不是數學定律，而是一個工作判斷框架：任何一環接近零，整體成果都會大幅下降。
一、Prompt Engineering 是甚麼？重點是把「工作指示」說清楚
OpenAI 將 Prompt Engineering 定義為撰寫有效指令，讓模型更穩定地產出符合要求的內容。換句話說，Prompt Engineering 處理的是單次互動的任務說明：目標、限制、輸入資料、輸出格式與評核標準。
例如，「幫我寫一份 proposal」太含糊；較完整的 Prompt 會交代：
- 任務：為一間香港零售企業撰寫 AI 培訓方案摘要；
- 對象：非技術背景的管理層；
- 限制：避免誇大成效，不使用未經核實數據；
- 格式：先列三個痛點，再提出方案、時間表與下一步；
- 完成標準：一頁內能讓決策者理解並作初步判斷。
Prompt Engineering 仍然重要，而且是所有 AI 應用的基本功。但它主要回答「今次要做甚麼」，未必能處理跨任務記憶、公司知識、權限、工具調用與結果驗證。
二、Context Engineering 是甚麼？不是給得愈多，而是每一步給得剛好
Context Engineering（上下文工程）關注的是：在模型有限的 context window 內，應該在甚麼時候放入哪些資訊。這些資訊可以包括系統規則、公司文件、過往對話、few-shot 示例、工具描述、搜尋結果、使用者偏好與任務狀態。
LangChain 將常見做法整理為四類：寫入（write）、選取（select）、壓縮（compress）與隔離（isolate）。核心並不是把所有資料一次過塞給 AI，而是讓它在下一步只看到最相關、足夠而且沒有互相衝突的內容。
Context Engineering 常見失敗
- 資料太少：AI 只能自行猜測公司政策或客戶背景；
- 資料太多：舊版本、無關文件與大量工具描述令模型分心；
- 資料互相衝突：不同 SOP 或價格表沒有版本與日期；
- 時機錯誤：AI 在不需要時讀取敏感資料，增加風險與成本。
RAG（Retrieval-Augmented Generation，檢索增強生成）是 Context Engineering 的其中一種做法：先找出相關文件片段，再把它們放入模型的當次 context。可是 Context Engineering 的範圍更闊，亦包括記憶管理、工具選擇、摘要、權限、狀態與不同 agent 之間的資訊交接。
三、Harness Engineering 是甚麼？可以理解成 AI 的「工作環境」
你可以將 Harness Engineering 理解為：為 AI 提供一個可工作的環境。但這個「環境」不只是一個介面或資料夾，而是包圍模型的一整套執行設計，包括工具、記憶、流程狀態、權限、重試機制、日誌、測試、guardrails（防護欄）與人工審批。
Harness Engineering 在 2026 年仍屬快速發展中的用語，業界未有單一統一定義。近期研究普遍把 agent harness 描述為模型外圍的系統層：它決定模型如何觀察環境、採取行動、接收回饋，以及用甚麼證據判斷任務已經完成。
Anthropic 建議企業從簡單、可組合的模式開始建立 agent；OpenAI 的 agent 實務指南亦把 instructions、tools、orchestration、guardrails 與 human intervention 視為可靠部署的重要部分。這些正是 Harness Engineering 需要處理的範圍。
三個概念，用辦公室比喻就最清楚：
Prompt＝你交給同事的工作指示；
Context＝同事桌面上今次需要的文件、數據與背景；
Harness＝整間辦公室的工具、權限、SOP、覆核制度與交付流程。
四、Prompt、Context、Harness Engineering 有何分別？
| 層次 | 主要問題 | 典型元素 | 最適合處理 |
|---|---|---|---|
| Prompt Engineering | 要 AI 做甚麼？ | 目標、指令、例子、格式、限制 | 單次寫作、分析、生成與問答 |
| Context Engineering | AI 今步要知道甚麼？ | RAG、記憶、文件、歷史、工具描述、任務狀態 | 公司知識、長對話、個人化與重複工作 |
| Harness Engineering | AI 如何安全完成及證明做妥？ | 工具、權限、迴圈、重試、測試、日誌、審批、交付 | Agent、多步驟流程、高風險或需驗證的任務 |
五、香港職場例子：由一句「幫我整 proposal」變成可靠交付
假設一間香港中小企希望 AI 協助準備客戶方案，三個層次會這樣分工：
第一層：Prompt
清楚說明客戶類型、方案目的、語氣、篇幅、輸出結構與不可作出的承諾。
第二層：Context
只載入今次需要的客戶 brief、最新價目、品牌語調、相關案例與合約限制；過期版本不應混入。
第三層：Harness
系統先搜尋資料，再計算預算、生成初稿、核對數字與禁用詞；如金額超過指定門檻或資料不足，就交回人手確認，最後才輸出可發送的文件並保存處理紀錄。
這個例子解釋了為甚麼換一個更強模型，不一定能解決企業 AI 的可靠性問題。錯誤可能不是模型能力不足，而是資料選錯、權限過闊、流程沒有檢查，或者根本沒有清晰的完成條件。
六、三者不是三揀一：先找出問題出在哪一層
Prompt、Context 與 Harness Engineering 不是三套互相競爭的方法。對同一個 AI 任務來說，三層往往會同時存在；分清楚它們的真正用途，是為了在結果出錯時，知道應該改哪裏，而不是每次都重寫 Prompt 或更換模型。
AI 結果不理想，可以先問三條問題：
- 答案方向或格式不對？先檢查 Prompt 有沒有說清楚目標、限制與完成標準。
- 答案缺資料、用錯版本或忽略背景？問題多數在 Context，應檢查文件、記憶、檢索結果與任務狀態。
- 工具用錯、步驟中斷或結果未經覆核？問題多數在 Harness，應檢查權限、流程、驗證、重試及人工審批。
例如 AI 寫錯報價格式，未必需要建立一套大型 Agent 系統；改善 Prompt 已可能足夠。相反，如果 AI 引用了過期價目表，即使 Prompt 寫得再仔細，也應該先處理 Context。若系統會自動發送報價、更新 CRM 或付款，則必須把重點放在 Harness 的權限、驗證與停止條件。
這個三層框架的價值，不是創造更多術語，而是令團隊可以更快定位問題：指示不清就改 Prompt，資料不對就改 Context，執行不穩就改 Harness。
七、應該先學哪一種？按任務成熟度選擇
- 一次性、低風險任務：先改善 Prompt。把目標、材料、格式與評核標準寫清楚。
- 重複、依賴文件的知識工作：加入 Context Engineering。整理資料來源、版本、檢索與記憶策略。
- 需要調用工具、跨系統或會產生實際行動：開始設計 Harness。加入權限、停止條件、驗證、日誌與人工審批。
最實際的做法：不要一開始便追求全自動 multi-agent。先選一個真實、重複、容易核對結果的工作，建立清晰 Prompt，再補 Context，最後才加入工具、權限與自動執行。
由「識問 AI」走向「設計 AI 工作」
Prompt Engineering 沒有過時；它只是從全部答案，變回其中一層。當工作由聊天升級成公司知識應用、Agent 或自動化流程，Context 與 Harness 會直接影響 AI 是否穩定、可追蹤及適合真正使用。
如果你正在比較不同模型，可以參考2026 最多人用的 5 大 LLM；但選完模型之後，更重要的是把指令、資料與執行環境一併設計。
由 Prompt 開始，建立可重用 AI 工作方法
人工智能應用績效實戰專業證書
課程由 Prompt Engineering 延伸至 RAG、AI 應用、Agent、Workflow、MCP 與多模態實戰，讓學員不只學工具名稱，而是練習如何把 AI 放入真實工作。課程已列入 CEF 可獲發還款項課程名單；實際資助須視乎個人資格、CEF 餘額及完成要求，並以最新官方條款為準。
常見問題
Prompt Engineering 是否已經過時？
不是。Prompt Engineering 仍是把任務、限制與輸出要求說清楚的基本功；只是當 AI 需要處理公司資料或執行多步驟任務，還需要 Context 與 Harness Engineering 配合。
Context Engineering 是否等於 RAG？
不等於。RAG 是 Context Engineering 的一種做法，負責檢索並加入相關知識；Context Engineering 還包括記憶、工具描述、對話歷史、任務狀態、壓縮與隔離。
Harness Engineering 是否等於建立 AI Agent？
不完全等於。AI Agent 是能使用工具並自主決定步驟的系統；Harness 是圍繞模型或 agent 的執行層，包括工具、權限、流程、測試、日誌、重試、guardrails 與人工審批。
沒有編程背景，可以學 Context 或 Harness Engineering 嗎？
可以。非技術使用者可以先由文件整理、知識庫、RAG 與可視化 Workflow 入手，理解資料、步驟、權限及覆核邏輯；需要更深度整合時再加入 API 或程式開發。
企業應該直接建立 multi-agent 系統嗎？
通常不應一開始便增加複雜度。先用單一模型或單一 agent 完成一個可量度、可核對的工作，再按需要加入更多工具、分工與 agent，會較容易評估成本、錯誤與實際價值。
