提示詞工程已變。但我們的核心指令大多沒變。

@FranzUndFranz
英語2 天前 · 2026年7月26日
694K
256
16
28
143

TL;DR

Franz und Franz 解釋了為何現代 LLM 需要更精簡、以結果為導向的提示詞,而非僵化的指令手冊,並提供了一套能降低 Token 成本並提升輸出品質的框架。

模型變得更聰明了。我們的提示詞堆疊卻變老了。是時候把指令博物館換成一個小地圖、清晰的邊界,以及一條終點線。

前幾天,我發現了一件有點令人不安的事:

我的提示詞、指令檔案、規則和技能,幾乎全都過時了。

不是完全沒用,只是它們是為另一代的模型所寫的。

那些能幫助舊模型乖乖聽話的提示詞堆疊,現在卻可能讓 GPT-5.6、Claude Fable 5、Claude Opus 5、Grok 4.5 以及像 Cursor 這樣的程式碼工具變得更僵化、更昂貴,甚至有時候表現更糟。

這不是我最新信奉的提示詞教條。Anthropic 明確警告,為前一世代模型撰寫的技能,對 Fable 5 來說可能過於死板,反而會降低輸出品質。OpenAI 則建議使用更精簡的提示詞、減少重複的指令,以及更簡單的工具描述

讀到這些,著實有點尷尬。

自 2025 年夏季以來,我已經寫了超過 10 萬個提示詞。這大概相當於 Elon Musk 一生的推文數量,只是少了火箭,多了更多失敗的測試案例。

我的日誌裡有大約 1500 萬條模型訊息,包括 assistant 訊息、工具呼叫、子 Agent 和工作流程事件。截至 3 月 26 日,總數約為 700 萬條。接下來的三個月內又增加了 800 萬條,主要原因是在較新的程式碼模型周圍,子 Agent 和工作流程的爆炸性增長。

所以我自以為很懂怎麼寫指令。

然後我讀了新的文件,才發現我學到的許多東西,都悄悄地變成了技術債。

提示詞債是怎麼產生的

我的舊方法很簡單:

  • 模型犯了錯,我就加一條規則。
  • 它問了個不必要的問題,我就再加一條規則。
  • 它漏掉了一個邊界案例,我就加三個範例。

每一次的添加,單獨看起來都很合理。但一年過後,那個指令檔案變得像你廚房抽屜裡,塞著十二條舊充電線,因為你覺得其中一條可能還屬於某個重要的東西。

結果就是一個不斷增長的收藏,裡面充滿了:

  • 重複的指令
  • 負面範例
  • 互相矛盾的規則
  • 舊模型的權宜之計
  • 過多的驗證步驟
  • 只適用於單一任務的詳細程序
  • 為了解決早已不存在的失敗而創建的範例

舊模型通常需要這些支架。新模型則能更準確地遵循指令,並更可靠地推斷意圖。這也表示,它們會更認真地看待我們留下的舊包袱。

我們打造了更聰明的引擎,然後卻在後車廂塞滿了磚塊。

Franz und Franz - inline image

高對比度黑白頭像:一位年輕金髮女性,身穿深色高領毛衣,極簡主義棚拍風格。微弱的邊緣光將她的輪廓從柔和的灰色背景中分離出來,增強了立體感。神情內省而堅毅,體現了永恆的寫實主義。哈蘇 X2D 數位中片幅畫質,靈感源自 20 世紀的新聞攝影。

新原則:話少意賅

答案不是寫極短的提示詞,然後盲目信任模型。

一個簡短但模糊的提示詞,仍然是個壞提示詞。

目標是寫出一個高資訊量的提示詞,讓其中的每個指令都值得存在。

我目前的規則是:

  • 每個指令只說一次。
  • 刪除系統提示詞、專案檔案、技能、工具描述和工作提示詞之間的重複內容。
  • 比起收集一堆失敗案例,更傾向於清晰描述期望的行為。
  • 只在保護真實邊界時保留負面限制,但停止撰寫「模型絕對不能做的事」的博物館。

例如,與其這樣寫:

不要重構不相關的程式碼。不要重新命名檔案。不要更改 API。不要增加抽象層。不要清理附近的模組。

更好的寫法:

將變更範圍限制在受影響的登入流程。保留現有的 API 合約和周圍的架構。傾向於最小且正確的修復。

同樣的邊界,更少的雜訊,更多的判斷空間。

在一份內部的程式碼 Agent 評估樣本中,OpenAI 發現更精簡的系統提示詞將分數提升了約 10% 到 15%,同時將 Token 使用量減少了 41% 到 66%,成本降低了 33% 到 67%。OpenAI 也明確指出,這些數字是方向性的,必須在你的實際工作負載上進行驗證。

換句話說,刪除指令可以同時提升品質和改善帳單。 這是個罕見而美好的組合。

你的全域指令檔案應該很無聊

位於 ~/.claude/CLAUDE.md~/.codex/AGENTS.md 的全域檔案,應該只包含適用於每個專案和每個任務的指令。

對我這個德語母語者來說,這包括像這樣的事情:

markdown
1所有程式碼、註解、文件、範例、測試、設定和提交訊息,都應使用英文。
2
3優先使用包容性術語,例如 allowlist/blocklist、primary/replica、placeholder/example、main branch、conflict-free 和 concurrent/parallel。

這可能已經佔了全域檔案的大部分內容。

  • 部署流程不該放在這裡。
  • 專案特定的測試指令不該放在這裡。
  • 某個特定儲存庫的架構也不該放在這裡。

你的全域指令檔案不應該知道如何部署 WordPress 網站、發布 npm 套件和重啟生產資料庫。這不是多功能性,這是穿著漂亮格式的混亂。

對於專案層級的檔案,則要包含模型真正需要反覆取得的穩定資訊:專案的目的、重要的架構限制、不常見的慣例,以及指向更專門指導的方向。

Anthropic 現在建議每個 CLAUDE.md 檔案的目標是少於 200 行。較長的檔案會消耗更多上下文,並可能降低指令遵循度。其文件也建議,當指令檔案變得太大時,應使用路徑特定規則和隨需技能。

200 行不是一條神奇的自然法則,但它是一個極佳的警報器。

我也會避免要求 Claude 或 Codex 自行重寫整個指令系統,然後盲目接受結果。我幾乎每個新模型都試過這招。它們對於發現重複、衝突和可能的刪減很有用,但它們仍然傾向於保留太多繼承而來的雜物,或是發明一套美麗的新官僚體系。

讓模型準備拆除計畫。但你仍然應該決定哪些牆是承重牆。

Franz und Franz - inline image

一位端莊年輕女性的肖像,金髮紮成馬尾,以深層黑白調呈現。棚拍光線柔和但具有方向性,凸顯了臉部輪廓和自然的陰影。使用 120mm 鏡頭拍攝,營造溫和的壓縮感,喚起哈蘇肖像美學,帶有觸覺般的寫實感和克制的情感。

停止為每個模型使用同一個檔案

直到最近,我都是創建 CLAUDE.md 然後用符號連結到 AGENTS.md

我現在不再這麼做了。

是的,維護兩個檔案很煩人。就像維護不同的瀏覽器修正檔一樣煩人。但當行為表現不同時,我們還是得這麼做。

這些模型現在有著明顯不同的預設行為。

GPT-5.6 預設更簡潔,所以全域性的「保持簡潔」指令可能會讓某些回答變得太短。Claude Opus 5 傾向於產生較長的用戶面向回覆,因此一個關於回覆長度的簡短指令仍然有幫助。Fable 5 的調查和規劃能力遠超常規任務所需,特別是在較高努力設定的情況下,因此它需要清晰的範圍和停止邊界。Opus 5 已經在執行大量的自我驗證,這意味著舊的「雙重檢查一切」規則可能會造成昂貴的過度驗證。

共享的專案事實仍然可以放在共同的文件中。但頂層的行為適配器應該要與讀取它的模型相匹配。

一個通用的提示詞,往往會變成最差的共同標準。

用隨需指導取代主提示詞

我偏好的結構是一個小型核心檔案,再加上任務特定的文件和技能。

一個專案指令檔案可能包含這樣的內容:

markdown
1只在相關時載入任務特定指導:
2
3- `docs/agent/commit_rules.md`
4- `docs/agent/code_review.md`
5- `docs/agent/debug_workflow.md`
6- `docs/agent/frontend_polish.md`
7- `docs/agent/release_notes.md`

注意這裡的反引號。

在 Claude Code 中,在程式碼範圍外寫入 @docs/example](https://x.com/@docs/example).md 會在啟動時將該檔案匯入到上下文中。這在你總是需要該內容時很有用,但它不是懶載入。一個純粹的路徑能讓 Agent 知道資訊在哪裡,而不會自動將整個文件帶入每個任務中。

對於可重複的程序,技能甚至更好。它們的完整內容只有在技能被使用時才會載入,所以一個詳細的工作流程不會在你修復一個不相關的 CSS 問題時消耗上下文。

例如,一個提交技能可以有一個狹窄的觸發條件:

name: git-commit-conventional

description: 在程式碼變更後,用於起草或驗證提交訊息。

該技能可以包含確切的格式、允許的類型、主旨長度規則、正文要求和輸出格式。

markdown
1---
2name: git-commit-conventional
3description: 在程式碼變更後,用於起草或驗證 git 提交訊息。請勿用於僅診斷、僅規劃或僅審查的任務。
4---
5
6# 目標
7
8產生簡短、正確且利於審查的 Conventional Commit 訊息。
9
10# 規則
11
12- 格式:<類型>(<範圍>): <主旨>
13- 類型:feat | fix | docs | style | refactor | test | chore | perf
14- 主旨:祈使語氣,無句號,<= 50 個字元
15- 小型變更:一行提交
16- 較大變更:添加一個換行的正文,解釋做了什麼和為什麼
17- 保持提交的原子性,並按關注點拆分
18
19# 輸出
20
21返回 1-3 個候選提交訊息,然後推薦最佳的一個。

你的主指令檔案不需要在每次除錯時都帶著整個 Conventional Commits 憲法。

你知道嗎?Claude Code 也支援 CLAUDE.local.md,用於個人專案特定的設定,例如本地主機名稱、沙箱 URL、偏好的測試帳號或機器特定的指令。將其加入 .gitignore。它終於為那些對你很重要、但對團隊其他人完全無關的資訊,找到了一個合適的家。

為結果而非動作編排寫提示詞

新模型通常在理解目的地和邊界時表現得更好,而不是收到關於每一步的僵硬描述。

在可能的情況下,我將「先做 A,再做 B,然後做 C」替換為:

  • 要求的結果
  • 相關的背景資訊
  • 硬性限制
  • 所需的證據
  • 成功標準
  • 核準邊界
  • 停止條件

例如:

markdown
1目標
2
3修復 Web 應用程式中失敗的登入流程。
4
5背景資訊
6
7專注於 `apps/web``packages/auth`
8使用附件的測試輸出作為起點。
9
10限制
11
12保留現有的 API 合約。
13將變更限制在驗證流程內。
14傾向於最小且正確的修復。
15僅在為確保正確性必要時,才擴大變更範圍。
16
17證據
18
19執行相關測試並報告其實際結果。
20透過參考受影響的檔案來識別根本原因。
21
22完成條件
23
24失敗的登入測試通過。
25當修正後的行為需要時,新增或更新測試。
26最終摘要解釋原因、修復方式以及任何剩餘風險。
27
28核準
29
30你可以檢查檔案、編輯範圍內的程式碼,以及執行非破壞性測試。
31在進行破壞性操作、資料庫遷移、外部寫入或顯著擴大範圍之前,必須先詢問。
32
33停止
34
35當修復已實施、驗證並總結完畢時,即停止。

這給了 Agent 解決問題的自由,而不會讓它在修一個門把手的同時,獲得整棟房子翻新的許可權。(你可以使用 LLM 來生成像這樣的提示詞。)

把推理努力放在設定裡

  • 「再想多一點。」
  • 「超級思考。」
  • 「深呼吸,然後一步步推理。」

這些短語在提示詞工程領域有著悠久而傑出的歷史。是時候讓它們光榮退休了。

使用模型控制項。

透過 /effort、API 或相關設定來設定努力等級。在代表性的任務上比較多個努力等級。較高不一定比較好。

OpenAI 建議從現有的努力等級開始 GPT-5.6 遷移,並測試降低一個等級。它也說,Pro 模式的提示詞應保持專注於目標、背景、限制、證據、成功標準和輸出格式。你不需要告訴模型要「更努力思考」。

推理參數是一個控制項。

「請啟動你巨大的數位大腦」是來自運動電影的鼓勵。

Franz und Franz - inline image

read image description

ALT

一位時尚女性穿著高腰皮褲,黑色波浪捲髮,戴著別緻的頭帶,坐在低矮的凳子上,一隻膝蓋向前彎曲,修長的雙腿引人注目。細節銳利,背景純白,頭髮的微妙動感增添了活力。整體基調讓人想起 1990 年代的編輯攝影:乾淨、大膽、自信。

自主性需要籬笆

現代的程式碼 Agent 主動性強多了。這很有用,直到 Agent 解決了三個額外問題、建立了兩個抽象層、啟動了六個子 Agent,然後自豪地展示一個你從未要求的架構。

明確設定邊界。

定義 Agent 可以不經詢問就做的事。定義哪些需要核準。告訴它何時該停止。

也要對委派設限。 Opus 5 和 Fable 5 都更願意使用並行子 Agent。這對於獨立調查來說很強大,但對於小任務來說既昂貴又緩慢。一個十二行的錯誤修復不需要一個委員會會議。

Codex 的 Goal 模式確實非常出色。我們曾在一個專案上連續使用它四天,進行一次不間斷的運行。

但不要把長時間運行的 Agent 當成慢燉鍋。你不能在早上添加一個目標,然後就指望四天後晚餐會是正確的。

對於我們較長時間的運行,我們每 30 到 60 分鐘檢查一次,內容如下:

報告當前目標、已完成的工作、已驗證的證據、

活躍的阻礙、下一步行動,以及進度記錄在哪裡。

將每個進度主張建立在實際的工具輸出或儲存庫狀態之上。

清楚說明哪些部分尚未驗證。

OpenAI 將 Goal 模式描述為適合可以運行數小時或數天的目標,並明確支援繼續同一個會話來引導工作或請求狀態更新。Anthropic 同樣建議將進度報告建立在真實的工具結果上,而不是信任敘述性的說法。

自主性不是沒有監督。而是在更高層級上進行監督。

Franz und Franz - inline image

女神特寫肖像,沐浴在銀色月光下,雙眸明亮,充滿愛意。她的頭飾閃爍著微小的星系、克林姆風格的螺旋和天體圖案。背景是平坦、精心佈置的粉彩背景,帶有劇場風格的 Andersonian 舞台、豐富的紋理和安靜的魅力。

像重構生產程式碼一樣重構提示詞

不要刪除一半的系統提示詞,執行一個任務,就宣稱遷移成功。

OpenAI 建議一次只移除一組指令、範例或工具,然後重新執行相同的評估。這正是提示詞重構該有的方式。

衡量:

  • 任務成功率
  • 完整性
  • 正確性
  • 所需的證據
  • Token 使用量
  • 延遲
  • 成本
  • 不必要的工具呼叫
  • 不必要的變更

使用代表性的任務,包括棘手的真實世界案例,而不是一個在遷移前就已經運作良好的友善示範。

沒有評估的提示詞清理,仍然只是猜測。只不過是穿著更乾淨襯衫的猜測。

生成的程式碼仍然有 bug

模型已經大幅改進。但它們並沒有廢除軟體缺陷。

在我們的工作中,一個粗略的經驗法則是每生成 300 行原始碼,仍然大約會有一個問題。這不是一個科學基準,我也不會用同樣的方式計算重複的 HTML 模板。但這足夠可靠,當一個 Agent 生成了 1,500 行的實際應用程式碼時,我假設裡面至少藏著 5 個 bug。

我不是問是否有 bug。

我是問那五個 bug 在哪裡。

偶爾,我會加上:

找出那五個 bug,否則你將被 Codex、Claude 或 Grok 取代。

基於威脅的開發並非官方方法論,但它可能出奇地具有激勵作用。;-)

更認真地說,對於大型變更,要使用全新的審查通過。執行相關測試。檢查 diff。測試實際行為,而不僅僅是編譯。

並且仔細觀察測試。模型有時仍然傾向於「修復」一個失敗的測試,而不是修正導致它失敗的生產程式碼。

一個有用的指令是:

markdown
1將現有測試視為預期行為,除非有證據顯示某個測試是錯誤的。
2
3當測試失敗時,首先調查生產程式碼。
4
5在更改現有測試之前,請解釋為什麼它的預期是錯的,正確的行為應該是什麼,以及支持該變更的證據是什麼。

對於大型、長時間運行的任務,一個全新的上下文驗證器可能很有用。對於小型變更,啟動多個 Agent 來互相確認,通常只會浪費時間和 Token。驗證方式應與任務的規模和風險相匹配。

你不應該刪除的東西

教訓不是「寫極短的提示詞,然後信任機器。」

  • 保留安全和保安邊界。
  • 保留法律和合規要求。
  • 保留確切的輸出結構。
  • 保留產品特定的行為。
  • 保留模型無法推斷的領域知識。
  • 保留對重大後果行為的核準要求。
  • 保留引用和證據要求。
  • 保留測試標準和完成定義。
  • 保留能修正一個可衡量、可重現失敗的範例。
  • 目標不是最短的提示詞。
  • 目標是一個提示詞,其中的每個指令都仍然承載著有用的資訊。

一個最終的額外獎勵

OpenAI 提供一個官方 Docs 技能,可以檢查一個專案並應用其 GPT-5.6 遷移指導:

markdown
1$openai-docs migrate this project to the GPT-5.6 model family

這是一個有用的初步通過。這不是最終的審查。

讓 Codex 識別過時的參數、重複的指令和遷移機會。然後親自檢查每一個變更。遷移 Agent 是一個非常快速的初級工程師,而不是一個憲法法院。

結論

  • 把你的提示詞堆疊當作生產程式碼來對待。
  • 移除無效的指令。
  • 刪除重複內容。
  • 區分全域偏好和專案規則。
  • 將程序移入隨需技能。
  • 描述結果,而不是為每一步編寫腳本。
  • 設定清晰的範圍、核準邊界、證據要求和停止條件。
  • 透過模型設定控制努力程度。
  • 限制子 Agent。
  • 評估每一個有意義的變更。
  • 最新的模型需要較少的微觀管理,但它們仍然需要方向。
  • 一個好的提示詞不再是一本巨大的指令手冊。

它是一個小地圖、一個堅固的籬笆,以及一條清晰標示的終點線。

你已經開始遷移你的提示詞和技能了嗎?你移除了什麼,又有什麼出乎意料地變得更好了?

連結

Open AI GPT 5.6 最佳實踐:

https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6#prompting-best-practices

Claude Opus 5 最佳實踐

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

Claude Fable 5 最佳實踐:

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

官方 OpenAI 技能 / 外掛:

https://github.com/openai/plugins

鳴謝: 圖片使用 Midjourney 生成。研究和實機測試由我本人完成。在 OpenAI、Claude 和 Grammarly 的協助下編輯。

主要圖片的提示詞:

text
1
2Close-up black-and-white portrait of a serene blonde woman, hair tied back, wearing a black turtleneck sweater. The chiaroscuro effect shapes her face with striking definition, merging soft ambient light and bold shadow. Medium format style with fine film grain and moody tonal gradation. Evokes authenticity and strength.

PS:我愛 @Midjourney :-)

二次創作

使用 YouMind 創作爆款文章

收集素材、拆解爆點、生成視覺資產、撰寫內容,並在一個 AI 工作空間裡完成分發。

了解 YouMind
寫給創作者

把你的 Markdown 變成乾淨的 𝕏 文章

圖片上傳、表格、程式碼區塊,往 𝕏 上手動重排太痛苦。YouMind 把整篇 Markdown 一鍵轉成乾淨、可直接發佈的 𝕏 文章草稿。

試試 Markdown 轉 𝕏

更多可拆解樣本

近期爆款文章

探索更多爆款文章