半夜 3 點，你跟 AI 苦戰許久，橫跳在 ChatGPT、Claude、Gemini 等各個平台，輾轉反側。
結果，硬是沒讓它寫出一封理想中的郵件——這不是段子，而是很多人的經歷。
一位開發者嘗試用 ChatGPT 寫一封不那麼「機器人腔」的銷售郵件，結果連改帶問連試了 147 次，每次輸出的內容依然死板空洞，一點不像人寫的。
最終，在第 147 次，他崩潰般地敲出一句：「你就不能問問我需要什麼嗎？」
沒想到這句吐槽意外成了靈感火花：如果 AI 能主動提問、索要完成任務所需的細節，會怎樣？ 接下來，他用 72 小時開發出一個叫「Lyra」的元提示（meta-prompt）。
簡單說，Lyra 相當於給 ChatGPT 換了個人設，讓它回答請求前先反過來採訪用戶，拿到關鍵資訊再動筆。比如：以前你對 ChatGPT 下命令「寫一封銷售郵件」，它乾巴巴吐出個模板。
用了 Lyra 後，同樣請求換來 ChatGPT 連連追問產品、目標客戶、痛點等關鍵細節，然後根據你的回答寫出一封真正貼合需求的郵件。
這則帖子在 Reddit 上迅速爆火，收穫了近萬按贊和上千評論。有不少網友稱讚這是個「很棒的點子」，也有人吐槽：「折騰 147 次 Prompt，那還不如直接自己寫封郵件快」。
「都試了一百多次了，有那功夫早就寫完了。」
荒誕之餘，這場「147 次失敗召喚 GPT」的喜劇折射出一個現實：讓 AI 辦成一件看似簡單的事，有時比我們想像的要複雜得多，也滑稽得多——prompting，也是時候要發生變化了。
AI 協作的新路線：講「氛圍」、給「上下文」
Lyra 的誕生看似偶然，實則反映了提示詞技術演進的一種思路。曾經，大家都熱衷於在提示詞上做文章，儘可能來保證輸出效果。有時候，提示詞的長度都超過了 AI 的產出。
而 Lyra 受到的質疑，也是對這種舊做法的反思。背後正是 AI 社區近來興起的新趨勢，比如 context engineering。
1 for "context engineering" over "prompt engineering".
— Andrej Karpathy (@karpathy) June 25, 2025
People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window… https://t.co/Ne65F6vFcf
Context engineering，本身是一種編程與系統設計的活動，被視為 AI 系統設計中的「下一代基礎能力」。它是在 AI 應用場景中搭建背景、工具、記憶、文檔檢索等全流程體系，讓模型在可靠上下文支持下執行任務。
這裡面包括：
-記憶結構：如 chat history、用戶偏好、工具使用歷史；
-向量資料庫或知識庫檢索：在生成之前檢索相關文檔；
-工具調用指令 schema：如資料庫訪問、執行代碼、外部 API 格式說明；
-系統提示/system prompt：給 AI 設置的角色、邊界、輸出格式規則；
-上下文壓縮與摘要策略：長期對話內容壓縮管理，保證模型高效訪問。
好比你寫 prompt 時，是在一個已經填好了歷史、主題文件、用戶偏好等資訊的環境中操作——prompt 就是「指令」，context 是「指令背後的材料與背景」。
這部分活兒是工程師的工作，雖然借鑑了一些 prompt engineering 的一些理念和技巧，但應用場景還是在軟體的工程和架構系統設計上。相比於 prompt 的微調，context 更適用於實際生產中，做到版本控制、追蹤錯誤、模塊復用等效果。
什麼？工程師的活兒，跟用戶有什麼關係？
簡單來講，如果說 prompt 是點火鍵，那麼 context engineering 就是在設計整個打火機，保證一點就能冒出火苗來。
複雜一點看，context engineering 為構建、理解和優化那些面向未來的複雜 AI 系統，提供了所需的規範化系統框架。它將關注點從 prompt 的手藝，轉向資訊流通與系統優化的技藝。
中科院的一篇論文指出了兩者的關鍵差別：
目前，業界把 context engineering 當作 agent 建構的重要實踐。尤其是上下文和工具調用等等，能有效提升模型的表現。
更輕易的 prompt，更清晰的結果
不過，還是得回到那個問題：工程師的活兒，跟我一個普通的用戶有什麼關係？
當你是普通用戶在寫 prompt時，Context Engineering 與 Prompt Engineering 雖然不完全相同，但在實質上存在深刻關聯——理解它們的關係，有助於你寫出更有效、上下文更貼切的 prompt。
傳統 Prompt 方法為什麼常常失敗，還依賴抽卡？因為很多人用 AI 還像用搜尋引擎，幾句指令就想要滿分答案。但大模型生成內容要靠理解上下文和模式匹配，如果提示含糊、資訊匱乏，模型只能硬猜，往往產出千篇一律的套話或答非所問。
這可能是因為 prompt 寫的模糊、需求不夠清晰，但是也可能是因為 prompt 被放在不夠結構化 context 的環境裡。比如被冗長的歷史聊天、圖片、文檔、格式混亂掩蓋，模型很可能「抓不到重點」或「回答跑題」。
就拿 Lyra 裡面寫郵件的場景來說，一個被結構化得完善的窗口中，包含了用戶之前的溝通歷史、語氣偏好，模型就能夠通過這些資訊，組織出更貼合用戶口吻的郵件草稿——甚至都不需要用戶寫很複雜的 prompt。
不過，即便用戶只是停留在 prompting 層面，無法展開 context engineering，也可以借鑑當中的一些思路。
比如，來自 Reddit 社群 ChatGPTPromptGenius 的一種形式「Synergy Prompt」，就是在 prompting 的層面結構化上下文。
它提出了三個核心構件：
- 元框架 Metaframe：每個元框架都會為對話添加一個特定的視角或焦點，是對 AI 構建的「基礎認知模塊」（如角色設定、目標說明、數據來源說明等）
- 具體資訊 Frames：每個上下文模塊中的具體內容
-對話地圖 Chatmap：記錄整個對話的動態軌跡，捕捉每次互動和語境選擇。
簡單來說，就是不斷地整合碎片化的資訊，成為一個個模塊，最後化為一個圖譜。當使用時，就可以整體性地調用這些已有模塊。
當 AI 掌握從主幹到細枝末節的完整語境結構時，它就能精準調取你所需的資訊，給出精確的針對性回應。
這也正是 context engineering 想做到的，誰說這不是一種互相成就呢？
