為什么大多數(shù) Prompting 方法會失效

根據(jù) Anthropic 的 Context Engineering 研究，在 2025 年，真正重要的不是“prompt engineering”，而是“context engineering”。問題不再是“如何打造完美的 prompt”，而是“哪種 context 組合能引發(fā)期望的行為”。

我會帶你走一遍當前研究（Anthropic、OpenAI、Google、Wharton）對 AI agent prompting 的結(jié)論——以及如何在 n8n 工作流中具體落地。

你將學(xué)到：

• System Message vs User Prompt（以及為什么錯誤的分離會讓 token 成本翻倍）
• 2025 年真正有效的五大核心技巧（有研究背書）
• 高級模式（Chain-of-Thought、RAG、Structured Outputs、Tool Use）
• 為什么應(yīng)該與模型一起生成 prompt，而不是手工堆砌
• 模型相關(guān)注意事項（只講實際相關(guān)的）
• 生產(chǎn)級模式（測試、錯誤處理、token 優(yōu)化）

復(fù)制模板的陷阱

我經(jīng)常見到：有人在 Reddit 上找到一個“完美”的 prompt 模板，復(fù)制到 AI Agent Node 里，然后期待它“魔法生效”。

劇透：不會。

復(fù)制模板失敗的原因：

• Context mismatch：模板是為完全不同的用例、數(shù)據(jù)、工具寫的
• Model differences：模板對 Claude 3 有效，而你用的是 GPT-4o-mini
• Over-complexity：模板有 500 行，因為作者想覆蓋所有邊界情況
• Under-specification：模板過于通用，對任何事都不夠好

Anthropic 的 Prompt Engineering 指南強調(diào)“找到合適的高度”（right altitude）——對指導(dǎo)足夠具體，但又為推理留有空間。模板對你的特定場景來說，幾乎總是在錯誤的高度。

第二個問題：Prompt 過于復(fù)雜

“越多越好”的思路會帶來巨大問題：

• Ignored instructions：當 context 超過 800+ 行，模型會開始忽略指令——Context Engineering 研究顯示 LLM 有“有限注意力預(yù)算”
• Increased latency：更多 tokens = 更慢響應(yīng)
• Higher costs：每個額外 token 都要花錢
• Maintenance nightmare：800 行 prompt 幾乎無法調(diào)試或優(yōu)化

解決方案：與模型一起生成 prompt

真正的游戲規(guī)則改變者是：讓模型為你寫 prompt。

不要花數(shù)小時打磨 prompt，而是給模型：

• 你的目標（agent 要做什么）
• 示例（輸入/輸出對）
• 約束（不該做什么）

模型會生成為你場景優(yōu)化的 prompt。你測試、與模型迭代、再細化。

為什么有效：模型最了解自己的“偏好”。它知道哪種表述、結(jié)構(gòu)、示例最有效。

稍后我會展示具體做法。

基礎(chǔ)：n8n 中的 System Message 與 User Prompt

n8n 的 AI Agent prompting 中最基礎(chǔ)也最常見的錯誤：混淆 System Message 和 User Prompt。

在 AI Agent Node 中，有兩個不同的 prompt 區(qū)域：

System Message（Options → System Message）：

• 定義 agent 的持久“DNA”
• 每次請求都會發(fā)送
• 幾乎不變/不應(yīng)該頻繁更改
• 包含：role、tools、workflow、constraints

User Prompt（主輸入）：

• 只針對“本次請求”的具體任務(wù)
• 來自 Chat Trigger、Webhooks 或前置節(jié)點
• 每次請求都變化
• 只應(yīng)包含本次的具體任務(wù)

圖片

為什么重要：Token 經(jīng)濟學(xué)與 Prompt Caching

兩者都會隨每次 API 調(diào)用發(fā)送。但正確分離對成本和性能都至關(guān)重要：

錯誤做法（把一切都塞進 User Prompt）：

"You are Senior Support Engineer. Tools: search_docs, create_ticket.
Use search_docs first. Max 150 words. Friendly.
User question: {{$json.message}}"

若每天 1,000 次請求、每次 400 tokens： = 400,000 個冗余 tokens = 以 Claude Sonnet（$3/M）計：$1.20/天 = 每月 $36 的純?nèi)哂?context

正確做法：

System Message（只定義一次）：

You are Senior Support Engineer.
TOOLS:
- search_docs(query): Search Product Docs
- create_ticket(title, priority): Create Support Ticket
WORKFLOW:
1. FAQ → search_docs
2. Complex Issue → create_ticket
BEHAVIOR:
- Max 150 words
- When uncertain: Create ticket, don't guess

User Prompt 僅為：{{$json.message}}

= 每次 50 tokens 而非 400 = 節(jié)省：每天 350K tokens = 每月約 $31.50（以 Claude Sonnet 計）

Prompt Caching：為什么 System Message 應(yīng)盡量保持靜態(tài)

Anthropic 和 OpenAI 提供 Prompt Caching——System Message 會被緩存，不必每次都重新處理。可將延遲降低 50–80%，對已緩存的 tokens 成本最高可降至 10%。

但：一旦你更改 System Message，緩存就會失效。因此：

• 設(shè)計 System Message 為靜態(tài)：基礎(chǔ)角色、工具、工作流邏輯
• 用 User Prompt 承載可變信息：動態(tài)數(shù)據(jù)、具體任務(wù)
• 僅在出現(xiàn)重大變更時更新 System Message：新增工具、工作流邏輯改變

緩存影響示例：

無緩存： 請求 1：500 tokens 的 System Message = $0.0015 請求 2：500 tokens 的 System Message = $0.0015 請求 1000：500 tokens 的 System Message = $0.0015 總計：1,000 次請求 $1.50

有緩存（System Message 保持穩(wěn)定）： 請求 1：500 tokens 的 System Message = $0.0015（寫入緩存） 請求 2：500 tokens 緩存命中 = $0.00015（便宜 90%） 請求 1000：500 tokens 緩存命中 = $0.00015 總計：~$0.15/1000 次請求 = 90% 節(jié)省

Dynamic System Messages：強大但要謹慎

你可以用 n8n Expressions 讓 System Message 動態(tài)化——但要注意緩存：

You are Support Engineer for {{$('Get Config').item.json.company_name}}.

PRODUCT: {{$('Get Config').item.json.product_description}}
TONE: {{$('Get Config').item.json.support_tone}}

適用場景：多租戶系統(tǒng)——一個工作流，多個客戶配置。

工作流：Webhook（Customer ID） → DB Lookup → AI Agent（動態(tài) System Message） → Response

緩存權(quán)衡：動態(tài) System Message 會破壞緩存——僅在必要時使用。

五大核心技巧：2024–2025 年研究給出的答案

來自 Anthropic、OpenAI、Google 在 2024–2025 的研究顯示：有一些對所有模型都有效的基本技巧。以下五條最重要：

圖片

技巧 1：清晰與具體（“Altitude” 原則）

Anthropic 的 Prompt Engineering 指南稱之為“找到合適的高度”（right altitude）——既足夠具體以提供指導(dǎo)，又為推理保留靈活性。

“同事測試”：如果一個聰明的同事看不懂這條指令，AI 也不會懂。

反例：

Classify emails intelligently and accurately.

“intelligently” 是什么？有哪些類別？輸出格式是怎樣？

正例：

Classify emails into: sales, support, billing, general

URGENCY CRITERIA:
- high: contains "urgent", "asap", "immediately", "broken"
- medium: time-related request without extremity
- low: everything else
OUTPUT: JSON
{
  "category": "support",
  "urgency": "high",
  "confidence": 0.92
}

為何有效：

• 消除歧義（明確只有四類）
• 提供決策標準（非主觀）
• 明確輸出格式（無需猜測）
• 可度量（有 confidence 分數(shù)）

技巧 2：正向指令（質(zhì)量提升 57%）

Bsharat 等（2024）研究顯示，正向指令明顯優(yōu)于負向指令。將“不要做 X”改為“請做 Y”，平均帶來 57% 的質(zhì)量提升。

負向指令為何失效：

• 模型先要理解你“不想要”的
• 再推斷你“想要”的
• 這個兩步推理經(jīng)常失敗

負向反例：

Don't be too wordy.
Don't use technical jargon.
Don't make assumptions about customer intent.

正向改寫：

Keep responses under 150 words.
Use plain language that a non-technical customer understands.
When customer intent is unclear, ask clarifying questions.

實際影響：

在生產(chǎn)環(huán)境的郵件分類 agent 中，負向指令（“不要誤判緊急請求”）造成 31% 的漏判。正向改寫（“凡含時間限制的請求一律標記為 urgent”）將漏判降至 8%。

技巧 3：Few-Shot Learning（示范勝于告知）

Few-shot 示例非常有效——但大多數(shù)人用錯了。

研究共識：

• 大多數(shù)任務(wù) 2–5 個示例最優(yōu)（更多幫助不大）
• 示例要“多樣化”（avoid 相似堆砌）
• 應(yīng)包含 edge cases
• Label bias 重要：Zhao 等（2021）顯示示例順序會影響結(jié)果

糟糕的 few-shot（過于相似）：

EXAMPLES:
1."How do I reset my password?"→category:support,urgency:low
2."Where is the password reset option?"→category:support,urgency:low
3."I can't find password settings."→category:support,urgency:low

全是同一種問題。模型學(xué)不到邊界處理。

良好的 few-shot（多樣且含 edge cases）：

Example 1 (Standard):
Input: "How do I reset my password?"
Output: {"category": "support", "urgency": "low", "confidence": 0.95}

Example 2 (Urgent):
Input: "URGENT: System down, can't access customer data!"
Output: {"category": "support", "urgency": "high", "confidence": 0.98}

Example 3 (Mixed Intent):
Input: "I want to upgrade my plan but also report a billing error."
Output: {"category": "billing", "urgency": "medium", "confidence": 0.78, "note": "Multiple intents detected"}

Example 4 (Edge Case - Unclear):
Input: "help"
Output: {"category": "general", "urgency": "low", "confidence": 0.45, "action": "request_clarification"}

為何有效：

• 覆蓋不同場景（標準、緊急、混合、不清楚）
• 示范如何處理邊界（低置信度 → 追問澄清）
• 展示一致的輸出格式
• 讓模型學(xué)習(xí)決策模式，而非僅做類別匹配

技巧 4：Constraints & Grounding（對抗幻覺）

AI agents 的大問題之一：hallucination（幻覺）。找不到答案時它們會編造。

解決方案：顯式約束，將 agent “落地”。

糟糕做法（無約束）：

Answer customer support questions based on our documentation.

后果：找不到信息時 agent 會胡編。

良好做法（顯式約束）：

Answer customer support questions using ONLY information from the documentation you can access via search_docs tool.

CONSTRAINTS:
- If information is not in docs: "I don't have that information in our current documentation. I'll create a ticket for our team to help you."
- Never make assumptions about features or functionality
- Never provide workarounds that aren't documented
- If multiple solutions exist: Present all documented options
ESCALATION CRITERIA:
- Customer mentions "urgent", "broken", "down" → create ticket immediately
- Question requires account-specific data → create ticket with details
- Documentation is incomplete/contradictory → create ticket noting the issue

為何有效：

• 清晰邊界（ONLY 文檔中的信息）
• 明確兜底行為（不確定時怎么做）
• 升級標準（何時轉(zhuǎn)人類）
• 不留“自由發(fā)揮”的空間

生產(chǎn)影響：

在每月處理 2000+ 詢問的客服 agent 中，加入約束將幻覺率從 23% 降至 3%。升級的人工工單質(zhì)量顯著提升，因為工單會包含具體的文檔缺口信息。

技巧 5：Context Engineering（最小高信號 token 集）

Anthropic 的研究很明確：不是“更多 context”，而是“正確的 context”。

原則：Smallest High-Signal Token Set

• 你的 context 中每一個 token 都應(yīng)提供價值
• 冗余信息會稀釋關(guān)鍵信號
• 更多 context ≠ 更好表現(xiàn)（往往適得其反）

糟糕的 context（冗長、重復(fù)）：

You are a helpful AI assistant designed to help customers with their questions and concerns. You should always be polite, professional, and courteous in your responses. Make sure to read the customer's question carefully and provide a thorough and complete answer that addresses all of their concerns. If you're not sure about something, it's better to say you don't know than to provide incorrect information...

350 個 token 的空話，幾乎沒有可執(zhí)行指導(dǎo)。

良好的 context（密度高、具體）：

You are Support Agent.

RESPONSE REQUIREMENTS:
- Max 150 words
- Plain language (non-technical)
- Structure: Problem acknowledgment → Solution → Next steps
TOOLS:
- search_docs(query) → search product documentation
- create_ticket(title, priority, details) → escalate to human team
WORKFLOW:
1. Search docs for relevant information
2. If found: Provide answer with doc reference
3. If not found OR customer mentions "urgent"/"broken": Create ticket

110 個 token，信號密度很高。每行都有可執(zhí)行信息。

Token 審計：

對 prompt 中每個句子問一句：“刪掉它，agent 會變差嗎？”如果不會，就刪。

高級模式：何時用（何時別用）

核心技巧適用于所有場景。下面這些高級模式非常強，但要“對癥下藥”。

模式 1：Chain-of-Thought（CoT）——用于復(fù)雜多步推理

沃頓商學(xué)院 2025 年 6 月的研究給出了迄今最全面的分析：CoT 對復(fù)雜推理有幫助，但對簡單任務(wù)效果參差。

何時使用 CoT：

• 需要多步邏輯推理
• 數(shù)學(xué)計算
• 有依賴關(guān)系的復(fù)雜決策樹
• 中間步驟重要的任務(wù)

不該用 CoT 的場景：

• 簡單分類（增加負擔無益）
• 模式匹配型任務(wù)
• 對速度極其敏感（CoT 會增加延遲）

圖片

在 n8n 中的實現(xiàn)：

TASK: Analyze customer request and determine best resolution path.

REASONING PROCESS (think step-by-step):
1. IDENTIFY: What is the core issue? (Quote specific parts of message)
2. CLASSIFY: Which category? (sales/support/billing/general)
3. ASSESS URGENCY: Time-sensitive keywords? Tone indicators?
4. CHECK PREREQUISITES: Can we resolve with available tools?
5. DECIDE: Route to appropriate handler with reasoning
Think through each step explicitly before providing your final answer.

性能影響：

• 準確度提升：復(fù)雜推理任務(wù)提升 2–5%
• 延遲增加：20–40%（模型輸出更多 tokens）
• 成本增加：與輸出 token 增長成正比

結(jié)論：只有當準確度提升能抵消成本和延遲的權(quán)衡時，才使用 CoT。

模式 2：RAG（Retrieval-Augmented Generation）——用于外部知識

當你的 agent 需要：

• 動態(tài)/頻繁更新的內(nèi)容（產(chǎn)品目錄、文檔）
• 體量巨大、放不進 context 的知識庫
• 客戶特定數(shù)據(jù)（訂單記錄、賬戶詳情）
• 訓(xùn)練語料之外的專有信息

RAG 就是必需的。

n8n 中的 RAG 基本流程：

Webhook/Trigger
  ↓
Extract Query (user's question)
  ↓
Vector Search (retrieve relevant chunks from knowledge base)
  ↓
AI Agent (answer using retrieved context)
  ↓
Response

關(guān)鍵 RAG 要點（基于 kapa.ai 的分析）：

• Chunk size：每塊 500–800 tokens（大多任務(wù)的最佳區(qū)間）
• Overlap：塊間重疊 50–100 tokens（避免邊界信息丟失）
• Number of chunks：返回 3–5 個最相關(guān)塊
• Reranking：向量召回后做語義重排以提升相關(guān)性
• Metadata：包含來源、時間戳、置信度

RAG Prompt 示例：

Answer the customer's question using ONLY the information provided below.

CONTEXT FROM DOCUMENTATION:
{{$json.retrieved_chunks}}
CUSTOMER QUESTION:
{{$json.user_message}}
INSTRUCTIONS:
- Base answer strictly on provided context
- If context doesn't contain the answer: "I don't have that information in our current documentation."
- Include source reference: "According to [doc_title]..."
- If multiple relevant sections: Synthesize information from all
CONFIDENCE ASSESSMENT:
- High confidence: Answer directly stated in context
- Medium confidence: Answer can be inferred from context
- Low confidence: Context is incomplete → escalate

模式 3：Document Repacking——順序比你想的更重要

Wang 等（2024）研究發(fā)現(xiàn)：context 的“順序”影響顯著。

發(fā)現(xiàn)要點：

• Primacy bias：模型更注意開頭的信息
• Recency bias：也更注意結(jié)尾的信息
• Middle neglect：中間的信息更容易被忽略
• 性能影響：通過最優(yōu)排序可提升 5–10% 準確度

最優(yōu)排序策略：

1. 最相關(guān)/最重要的信息放最前
2. 次要的支持信息放中間
3. 約束與提醒放最后（利用近因效應(yīng)）

示例（RAG context）：

MOST RELEVANT DOCUMENTATION:
[Chunk with highest relevance score]

ADDITIONAL CONTEXT:
[Supporting chunks]
CONSTRAINTS (IMPORTANT):
- Answer only from provided context
- If uncertain: Escalate to human team

模式 4：Structured Outputs——為數(shù)據(jù)抽取提供 100% 可靠性

OpenAI 的 Structured Outputs（GPT-4o）及其他模型的類似能力，解決了一個大問題：獲得一致、可解析的輸出。

傳統(tǒng) prompting 的問題：

Output format: JSON with fields category, urgency, confidence

模型可能會輸出：

• 合法 JSON
• 帶多余字段的 JSON
• 缺字段的 JSON
• 格式錯誤的 JSON
• 先文字解釋再給 JSON

你得為這些情況全部做兜底。

Structured Outputs 的方案：

定義 JSON schema，配合 Structured Output Parser 節(jié)點攔截異常即可。

示例 schema：

{
  "type":"object",
"properties":{
    "category":{
      "type":"string",
      "enum":["sales","support","billing","general"]
    },
    "urgency":{
      "type":"string",
      "enum":["low","medium","high"]
    },
    "confidence":{
      "type":"number",
      "minimum":0,
      "maximum":1"
    },
    "reasoning": {
      "type": "string"
    }
  },
  "required": ["category", "urgency", "confidence"]
}

好處：

• 不再有解析錯誤
• 保證 schema 合規(guī)
• 下游處理更簡單
• Enum 約束（只允許有效值）

何時使用：

• 非結(jié)構(gòu)化文本的數(shù)據(jù)抽取
• 固定類別的分類
• 需要特定格式的 API 集成
• 任何對輸出格式一致性要求高的任務(wù)

元技能：與模型一起生成 prompt

我構(gòu)建 AI agents 的方式就此改變：別再手寫 prompt，讓模型來生成。

流程：

1. 定義需求（agent 要做什么）
2. 提供示例（能代表期望行為的輸入/輸出對）
3. 指定約束（絕不該做什么）
4. 讓模型生成“優(yōu)化后的”prompt
5. 測試并迭代（基于實際表現(xiàn)微調(diào)）

Meta-prompt 示例：

I'm building an AI agent for customer support email classification. Help me create an optimal system message prompt.

REQUIREMENTS:
- Classify emails into: sales, support, billing, general
- Assess urgency: low, medium, high
- Output format: JSON with category, urgency, confidence
- Must handle edge cases: unclear intent, multiple topics, spam
TOOLS AVAILABLE:
- search_docs(query): Search documentation
- create_ticket(title, priority, description): Escalate to humans
EXAMPLES OF DESIRED BEHAVIOR:
[Include 3-5 diverse examples with input and expected output]
CONSTRAINTS:
- Never make up information
- When uncertain (confidence < 0.7): Escalate
- Response under 150 words for direct answers
- Include reasoning in output
Generate an optimized system message that will consistently produce these results.

模型會生成一個：

• 結(jié)構(gòu)與措辭最優(yōu)
• 融合有效技巧
• 在具體與靈活間取得平衡
• 針對你用例的 prompt

為何有效：

• 模型了解自己的“偏好”
• 它會采用最優(yōu)結(jié)構(gòu)和表述
• 你能省下大量試錯時間

模型相關(guān)注意事項：哪些真的重要

大多數(shù)“模型特定技巧”并不靠譜。但有些差異確實重要：

Claude（Anthropic）：

• 優(yōu)勢：復(fù)雜推理、長 context（200K tokens）
• 劣勢：有時過度謹慎，會拒絕無害請求
• 最佳實踐：明確寫清 constraints，再讓其自由推理
• Prompt caching：對 >1024 tokens 的 System Messages 啟用

GPT-4o（OpenAI）：

• 優(yōu)勢：Structured Outputs（100% schema 合規(guī)）、速度快
• 劣勢：context 較短（128K），較少“深思熟慮”
• 最佳實踐：數(shù)據(jù)抽取使用 Structured Outputs，配合精確指令
• Prompt caching：對 System Messages 自動啟用

GPT-4o-mini：

• 優(yōu)勢：便宜（$0.15/M vs $3/M），適合簡單任務(wù)
• 劣勢：復(fù)雜指令魯棒性較弱
• 最佳實踐：使用具體、結(jié)構(gòu)化的 prompts，配 few-shot 示例

Gemini（Google）：

• 優(yōu)勢：多模態(tài)（圖像、視頻）、超長 context（2M tokens）
• 劣勢：tool-use 支持較弱，有時不穩(wěn)定
• 最佳實踐：用于多模態(tài)場景，避免復(fù)雜工具編排

選型經(jīng)驗法則：

• 復(fù)雜推理 + 長文檔 → Claude Sonnet
• 數(shù)據(jù)抽取 + Structured Outputs → GPT-4o
• 簡單分類 + 預(yù)算敏感 → GPT-4o-mini
• 多模態(tài)（圖/視頻）→ Gemini

生產(chǎn)級模式：測試、錯誤處理、優(yōu)化

好 prompt 遠遠不夠——你需要生產(chǎn)級工作流。

測試策略

用真實的 edge cases 測，別只測“快樂路徑”：

Test cases for email triager:
? Standard support request
? Angry customer (caps, exclamation marks)
? Sales inquiry with technical questions (mixed intent)
? Very short message ("help")
? Wrong language (if only English supported)
? Spam/irrelevant content

錯誤處理

AI agents 可能失敗——要有兜底：

n8n workflow:
AI Agent Node
  → IF Error OR confidence < 0.7:
     → Fallback: Route to Human
  → ELSE:
     → Continue with automated workflow

帶 confidence 的 System Message 約定：

If you're uncertain (confidence < 70%):
Set "needs_human_review": true in output

Token 優(yōu)化

高并發(fā)下，每個 token 都很寶貴：

• 移除冗余：例如 “Please”、“Thanks”、“I think”
• 合理縮寫：“Maximum”→“Max”，“Information”→“Info”
• 使用符號：“→” 代替 “then”，“?” 代替 “correct”
• 用 JSON 替代散文：結(jié)構(gòu)化數(shù)據(jù)優(yōu)于長句

4. 監(jiān)控與日志

跟蹤關(guān)鍵指標：

• Latency：agent 響應(yīng)耗時
• Token usage：每次請求的輸入 + 輸出 tokens
• Error rate：失敗頻率
• Confidence distribution：置信度分布

在 n8n 中：用 Webhook → Google Sheets 進行輕量記錄：

After AI Agent Node:
→ Set Node (Extract Metrics):
   - latency: {{$now - $('AI Agent').json.startTime}}
   - input_tokens: {{$('AI Agent').json.usage.input_tokens}}
   - output_tokens: {{$('AI Agent').json.usage.output_tokens}}
   - confidence: {{$('AI Agent').json.confidence}}
→ Google Sheets (Append Row)

上線檢查清單

上線前：

Prompt 質(zhì)量：

• System Message 與 User Prompt 是否正確分離？
• System Message 是否穩(wěn)定以利用 prompt caching？
• 是否使用正向指令（而非“避免 X”）？
• 是否有含 edge cases 的 few-shot 示例？
• 約束是否清晰？
• 輸出格式是否明確？

測試：

• 是否用 10+ 個真實測試用例？
• 邊界情況（短輸入、錯別字、混合意圖）是否覆蓋？
• 錯誤處理是否有效？
• 不確定時是否有 fallback 策略？

性能：

• Token 是否優(yōu)化（無冗余）？
• 是否啟用 prompt caching？
• 延遲是否可接受（< 3s）？
• 單次請求成本是否核算？

監(jiān)控：

• 是否記錄 token 使用？
• 是否實現(xiàn)錯誤跟蹤？
• 是否啟用置信度評分？
• 是否有關(guān)鍵指標儀表板？

迭代：

• 是否有 A/B 測試策略來改進 prompt？
• 是否建立基于真實用戶數(shù)據(jù)的反饋回路？
• 是否規(guī)劃定期復(fù)盤？

總結(jié)：2025 年真正有效的是什么

五大通用核心技巧：

• Clarity & Specificity：合適的“高度”——具體且保留推理空間
• Positive Instructions：質(zhì)量提升 57%（Bsharat 等，2024）
• Few-Shot Learning：多樣示例 + 邊界情況
• Constraints & Grounding：以清晰邊界對抗幻覺
• Context Engineering：最小高信號 token 集

情境性高級模式：

• Chain-of-Thought：僅用于復(fù)雜多步推理（提升 2–5%）
• RAG：應(yīng)對外部/更新知識（chunk 500–800 tokens）
• Document Repacking：通過排序提升 5–10% 準確度
• Structured Outputs：數(shù)據(jù)抽取 100% 可靠（GPT-4o）

元結(jié)論：

• 復(fù)制模板會失敗——與模型一起生成 prompts
• 保持 System Message 穩(wěn)定以發(fā)揮 prompt caching（可省 90% 成本）
• Token 經(jīng)濟學(xué)比“完美措辭”更重要
• 用 edge cases 做測試比“再加幾個 few-shot”更關(guān)鍵

圖片

你的下一步：挑一個現(xiàn)有的 n8n AI Agent 工作流，套用以上五大核心技巧。對比前后 token 使用。通常你會看到成本大幅下降，同時輸出質(zhì)量不降反升。

這就是“勉強可用”的 prompting 與“可規(guī)模化、可上生產(chǎn)”的 prompting 的區(qū)別。