廣東
最近直播和社群里，被問到頻率最高的一個問題：
提示詞工程、上下文工程、Harness 工程……
這些「XXX工程」到底啥區別？產品經理要學哪個？
先回答：所謂「XXX工程」，就是更規范做 XXX 的方式。
? 提示詞工程 = 更規范地寫提示詞；
? 上下文工程 = 更規范地為模型構造上下文；
? Harness 工程 = 更規范地為 Agent 搭建運行環境。
三個概念不是替代關系，是遞進關系。它們共同回答一個核心問題：如何讓 LLM 產出更好的結果？
今天這篇文章，幫你一次搞清楚。
提示詞工程：一切的起點
prompt-engineering 為什么需要"提示"？
所有 LLM 都有一個共同特征：它不會主動行動。
不管模型多聰明，你不給它輸入，它就只是參數文件里沉睡的幾十 GB 權重。"提示"（Prompt）是一切的起點 — 沒有提示，就沒有輸出。
而如何"提示"、"提示"什么，直接決定了 LLM 能為你創造多大的價值。
這就是 提示詞工程（Prompt Engineering） 存在的意義：一套讓"提示"更好地指導 LLM 工作的方法。
提示詞工程的本質是什么？
聽起來高大上，但提示詞工程的核心其實就兩件事：
1）把事情的背景信息交代全面
你得告訴模型：你是誰、你要解決什么問題、當前是什么場景、有哪些約束條件。
模型不了解你的業務、你的用戶、你的上下文 —— 你不交代，它就猜。
2）把事情的要求約束清楚
你得告訴模型：輸出什么格式、面向什么受眾、用什么風格、長度多少、哪些是必須包含的、哪些是絕對不能出現的。
你不約束，它就自由發揮。
發現沒有？這兩件事，產品經理天天在干。
前者是需求分析、需求挖掘、問題定義 —— 這是產品經理的基本功之一。
后者是功能描述、功能拆解、邊界界定 —— 這是產品經理的基本功之二。
提示詞工程，本質上就是在寫 PRD。
只不過這次的"開發人員"是大模型，而且它不需要你用技術語言，用自然語言就夠了。
怎么真正掌握提示詞工程？
背模板、抄別人的提示詞，只能解決表面問題。
真正掌握提示詞工程最好的方式，是理解大模型運行的底層原理。
關于 LLM 的底層原理，確保你理解了：LLM 生成的每一個 Token，都來自對前文的分析，但最終的選擇是概率性的。
這意味著什么？
? 前文越清晰，生成越精準。 模型會"模仿"前文的風格和邏輯。你給它一個結構化的提示，它就傾向于輸出結構化的內容。
? 約束越明確，隨機性越小。 概率選擇意味著模型有"跑偏"的可能。你要求越嚴格，它跑偏的空間就越小。
? 示例比描述更有效。 與其用一千字描述你想要什么，不如直接給它一個例子。模型最擅長"模仿"。
一旦理解了這些特性，你就知道該怎么寫提示詞了 —— 因為你理解了要打交道的對象。
這就是提示詞工程。
為 LLM 提供上下文最簡單、最直接的方式，也是一切 AI 工程的基礎。
一句話總結：
提示詞工程 = 用 PRD 思維給模型交代清楚背景和要求，讓它的概率輸出更可控。
上下文工程
context-engineering
提示詞工程解決了"怎么寫好一條提示"的問題，隨著 AI 應用越來越復雜，你會發現：一條提示詞遠遠不夠。
為什么提示詞工程不夠用了？
一個場景：你讓 AI 客服回答用戶問題。
如果只靠提示詞，你得在提示里塞進產品文檔、用戶歷史、FAQ、話術模板、合規要求……
很快，提示詞就膨脹到幾萬字，模型的注意力被稀釋，效果反而變差。
更麻煩的是，很多信息是動態的 —— 用戶的訂單狀態在變、庫存數據在變、最新的政策在變。
你不可能每次都把全量信息塞進提示詞。
這時候，你需要的是上下文工程（Context Engineering）。
上下文工程是什么？
所有為 LLM 提供作業支撐信息的方式，都是上下文工程的一部分。
實際上，提示詞工程本身就是上下文工程的一個子集 —— 它是最簡單的那種：把所有信息直接寫在提示里。
但上下文工程的范圍遠不止于此。
它要回答的問題是：在每次模型調用前，什么樣的信息組合，最有可能讓模型產出期望的結果？
這個問題的難點在于：
1）信息太多，窗口有限
大模型的上下文窗口就像人的工作記憶 —— 容量有限。
塞太多信息，模型反而"走神"。
隨著上下文中的 Token 數量增加，模型準確回憶信息的能力會下降。這不是 bug，是架構限制。
所以，上下文工程的第一原則是：信息充分但緊致 —— 用盡可能少但高信號密度的 Token，最大化獲得期望結果的概率。
2）信息來源多樣，需要編排
隨著 LLM 通過 Function Calling 調用工具的能力越來越強，模型可以獲取信息的方式越來越多：
? 從內部知識庫檢索（RAG）
? 調用搜索引擎獲取實時信息
? 查詢數據庫獲取結構化數據
? 讀取文件獲取本地資料
? 調用 API 獲取第三方服務數據
每種方式產出的信息格式不同、可信度不同、時效性不同。
如何編排、組織這些信息源，讓 LLM 高效高質量地獲取更多支撐信息，就值得"工程"一下了。
3）信息是動態的，需要管理
在長時間的 Agent 工作流中，上下文會不斷膨脹。
每一輪工具調用都會產生新的信息，但上下文窗口就那么大。這時候就需要一些工程手段：
? 壓縮整合：當對話接近窗口上限時，讓模型對歷史信息做高保真總結，用摘要替換原始內容，保持連貫性的同時釋放空間。
? 結構化筆記：讓 Agent 把關鍵信息寫到上下文之外的持久化存儲（比如一個 Mermory.md 文件），需要時再拉回來。就像人做筆記一樣 —— 你不需要把所有東西記在腦子里，但你得知道去哪里找到它。
? 子代理分工：把復雜任務拆給多個子代理，每個子代理在自己干凈的上下文窗口里工作，最后只把結論匯報給主代理。
因為上下文工程的本質是信息架構設計 —— 決定什么信息在什么時候以什么方式進入模型的視野。
這和產品經理做的事情一模一樣：
? 設計產品時，你要決定什么信息展示在首頁、什么信息放在二級頁面
? 寫需求時，你要決定什么背景先交代、什么細節后補充
? 做用戶研究時，你要判斷什么數據是關鍵信號、什么數據是噪聲
上下文工程，就是把這種信息架構的能力，用在了給 LLM 構造輸入上。
一句話總結：
上下文工程 = 在有限的注意力預算內，為模型策劃最優的信息組合，不只是寫提示詞，更是管信息流。
Harness 工程
harness-engineering
前兩個"工程"解決的是怎么跟模型溝通的問題。當 AI 從"對話助手"進化到"自主 Agent"，光會溝通就不夠了 —— 你需要給它一個能行動的環境。
這就是 Harness 工程。
什么是 Harness？
Harness 這個詞，直譯是"挽具" —— 就是套在馬身上的那套裝備，讓騎手能駕馭馬匹。
用在 AI 領域：模型是大腦，Harness 是身體。
沒有身體，大腦再聰明也只能"想"，不能"做"。
或者說：模型以外的一切，都是 Harness。
它包括什么？我們可以把它拆成三層：
第一層：執行能力層 —— 給模型裝上"手"
Agent 需要工具來執行任務。核心工具有三類：
1. 文件系統工具 —— 增刪、讀寫、搜索文件。這是最基礎的能力，95% 的 Agent 任務都離不開文件操作。
2. 瀏覽器工具 —— 訪問和操作用戶世界的系統，獲取實時信息。
3. 語言解釋器 —— 能寫代碼，還得能運行代碼、驗證結果。
這三類工具配齊，就能覆蓋絕大多數場景。
但配工具不是越多越好 —— 工具要和 Agent 的角色綁定。
一個負責"探索代碼庫"的 Agent，應該只配只讀工具，限制它寫文件、刪文件的能力。給錯工具，比不給更危險。
第二層：上下文環境層 —— 給模型裝上"記憶"
模型的工作記憶是有限的（上下文窗口），但 Agent 的任務可能是長期的。如何讓 Agent 在長時間工作中保持連貫性？
這層的核心是記憶系統。目前主流有三種方案：
? 規則式：按固定規則存取信息，比如"每次對話結束自動保存關鍵信息到文件"
? 半規則式：Agent 自己決定什么值得記、什么時候查記憶，但存儲結構是預定義的
? 完全模型驅動式：讓模型自己決定記什么、怎么存、怎么查
以 Claude Code 和 Hermes Agent 為例，它們都有兩個精妙的記憶機制：
? 交互后 Hook：每次對話結束，自動 fork 一個 Agent，帶上系統提示詞和交互上下文，把需要保存的信息更新到結構化的 Markdown 文件里。
? "悄悄做夢"：每隔一天，自動對最近的會話信息進行整理和更新 —— 就像人在睡眠中整理白天的記憶一樣。
當任務復雜到一個 Agent 搞不定時，你需要多個 Agent 協作。這就涉及：
? 任務分配：誰負責什么？怎么把大任務拆成小任務？
? 權限治理：哪些 Agent 能寫文件？哪些只能讀？哪些能訪問網絡？
? 信息隔離：不同 Agent 之間的上下文要不要互通？互通多少？
這一層解決的不是"單個 Agent 怎么工作"的問題，而是"一群 Agent 怎么協作"的問題。
產品經理為什么要了解 Harness？
有人可能覺得：Harness 不是工程師的事嗎？
是，也不是。
Harness 的設計決策，直接影響產品的用戶體驗、成本結構和能力邊界：
? Agent 能調用哪些工具，決定了它能做什么事（功能邊界）
? Agent 的記憶系統怎么設計，決定了它的對話體驗好不好（用戶體驗）
? 多 Agent 怎么協作，決定了系統能處理多復雜的問題（能力上限）
? 每次調用消耗多少 Token，決定了產品的運營成本（成本結構）
Koji 采訪新璐的播客里，新璐給了一個非常棒的說法：
在技術變化的周期里，產品經理如果不了解變化的內核和本質，就很難構建真正貼合紅利和變化的產品。
Harness 工程目前還處于早期 —— 范式變化快，沒有公認的"最佳實踐"。但正因如此，現在理解它的人，就能在下一波 AI 產品浪潮中占據先發優勢。
一句話總結：
Harness 工程 = 為 Agent 搭建完整的運行環境（工具 + 記憶 + 協作），讓模型從"能想"進化到"能做"。
三者的關系：不是替代，是遞進
看到這里，你應該能感受到三個"工程"之間的關系了：
工程
核心問題
作用對象
產品經理的對應能力
提示詞工程
怎么寫好一條提示？
單次模型調用
需求分析、PRD 寫作
上下文工程
怎么為模型編排最優信息？
多次模型調用的信息流
信息架構設計、數據決策
Harness 工程
怎么為 Agent 搭建運行環境？
Agent 的完整工作流
產品架構設計、系統思維
提示詞工程是基礎 —— 不會寫提示詞，后面的都不用談。
上下文工程是進階 —— 當你的 AI 應用不只是單輪對話，就需要管理信息流。
Harness 工程是全貌 —— 當你要打造真正的 AI Agent 產品，就需要理解整個運行環境。
三者不是非此即彼的選擇，而是隨著 AI 應用復雜度遞增，你依次需要掌握的能力棧。
五、產品經理怎么學？
回到最開始的問題：產品經理要學哪個？
答案是：都要學，而且你能學得比你想象中快。
因為這三個"工程"的本質，都在產品經理的能力射程之內：
? 提示詞工程 = 寫 PRD 的能力
? 上下文工程 = 信息架構的能力
? Harness 工程 = 產品架構的能力
你缺的不是能力基礎，而是把這些能力遷移到 AI 語境下的方法論和實踐機會。
這也是我做《AI 產品經理轉崗特訓營》的初衷。
課程經過了 2 年 + 7 輪迭代，核心邏輯是：先讓你理解 AI 的底層原理，再讓你掌握工程化的實踐方法，最后用實訓項目把這些能力固化成肌肉記憶。
具體來說：
1. 建立全局認知 —— AI 行業的生態圖景、業務類型、崗位職責，先找到方向
2. 4 節課搞定底層原理 —— 只要你會玩狼人殺就能聽懂，但學完你會站在比大部分人更高的認知維度
3. 13 節課講透核心技能 —— 提示詞工程、RAG 知識庫、Dify、微調，四大實戰必學
4. AI 產品設計全流程 —— 從需求到產品設計上線，包括我專門寫的 4 萬字 AI 產品專屬 PRD
5. 手把手求職輔導 —— 篩 JD、改簡歷、準備面試，還有 100 道 AI 面試真題解析
6. 5 個實訓項目 + 5 個企業級項目 —— 可以寫進簡歷，直接增加面試通過率
技術和玩法在高速迭代，機會窗口不會太久。
小步快跑加入進來，進來就不怕技術迭代；不進來，門檻只會越來越高。
詳細課程大綱和學習計劃，掃碼聯系班主任獲取
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
