← 所有文章

提示工程的OODA循環：五次失敗教會我的事

3分鐘閱讀

John Boyd上校的OODA循環是在1960年代為戰鬥機飛行員的決策而開發的，在空戰中，能更快完成觀察-定向-決策-行動循環的飛行員將獲得決定性優勢，無論飛機性能如何。我發現同樣的原則適用於提示工程——在五次代價高昂的失敗教會我，撰寫提示本身其實是最不重要的步驟之後。1

TL;DR

OODA循環（觀察、定向、決策、行動）為提示工程提供了一套系統性框架，能防止最常見的失敗模式：在觀察（理解完整脈絡）之前就行動（撰寫提示）。在建構了44個技能——每個都是具備自動啟動邏輯的結構化提示——之後，我了解到提示本身大約只佔成果的20%。其餘80%來自觀察（模型需要什麼脈絡？）、定向（這個任務屬於什麼類型？）以及決策（什麼提示模式適合這個任務類型？）。下方的互動建構工具將引導您走過完整的OODA循環。結果是：提示在第一次嘗試就能成功，而非需要反覆迭代修正。

失敗了五次的提示

在我學會先觀察再行動之前，我寫提示的方式就像開發者寫程式碼一樣：直接跳到解決方案。

失敗1：部落格評估器。 我第一次嘗試撰寫部落格品質評估提示：「評估這篇部落格文章，給它1到10分。」模型回傳了一段含糊的段落，寫著「7/10」，卻沒有任何可執行的回饋。我迭代了四次才意識到問題不在提示的措辭——問題在於我沒有定義「品質」的意涵。

OODA修正： 我花了30分鐘觀察自己的評估流程。我找出了六個我在意的具體維度：讀者價值（25%）、技術準確性（20%）、教育品質（20%）、寫作品質（15%）、事實完整性（15%）、以及SEO效果（5%）。這套加權評分標準成為了blog-evaluator技能，此後每次評估都能產出一致且可執行的分數。2

失敗2：程式碼審查器。 我的第一個審查提示：「審查這段程式碼的錯誤和安全問題。」模型回傳了15項發現，其中12項是風格上的瑣碎挑剔。訊號與雜訊的比例使得這次審查毫無用處。

OODA修正： 我將任務定向為三個獨立的子任務（正確性、安全性、規範性），並建構了三個專門的審查子代理，每個都有受限的工具存取權限和特定的評估標準。正確性審查器只標記邏輯錯誤。安全性審查器只標記OWASP漏洞。規範性審查器只標記模式偏差。雜訊幾乎降至零，因為每個提示都被精確限縮在單一維度上。3

失敗3：翻譯提示。 「將這篇部落格文章翻譯成韓文。」模型翻譯了，但遺失了所有markdown格式、剝除了腳註引用，還改寫了應該保留英文的技術術語。

OODA修正： 我觀察了「翻譯」對於我的使用情境到底意味著什麼：保留markdown結構、保留腳註編號、保持程式碼區塊不翻譯、保持專有名詞使用英文、改寫慣用語而非逐字音譯。約束條件清單比翻譯指令本身還要長。每項約束都消除了「翻譯這個」所會產生的一種失敗模式。4

OODA循環應用於提示工程

階段1：觀察

在撰寫提示的任何一個字之前，先觀察問題空間：

實際的任務是什麼？ 不是表面的請求，而是底層的需求。「摘要這份文件」實際上可能意味著「提取這次會議中做出的三個決定，以便我能跟進待辦事項。」

模型需要知道什麼？ 列舉產生正確回應所需的脈絡。缺少脈絡會導致幻覺。過多脈絡會浪費token並可能分散模型的注意力。

輸出應該長什麼樣？ 在撰寫提示之前，先定義期望輸出的格式、長度、語氣和結構。模糊的輸出期望會產生模糊的輸出。5

觀察檢查清單： - [ ] 已識別實際任務（非表面請求） - [ ] 已列舉所需脈絡 - [ ] 已定義輸出格式 - [ ] 已指定成功標準 - [ ] 已預期失敗模式

階段2：定向

將任務定向於模型的能力空間內：

任務類型分類。 該任務是提取（從提供的文本中拉取資訊）、生成（創造新內容）、轉換（在格式之間轉換）、分析（評估和推理內容），還是分類（將輸入歸類）？6

每種任務類型都有成熟的提示模式。我的44個技能反映了這個模式：blog-evaluator技能使用分析模式（加權評分標準、結構化評分）。blog-writer-core技能使用生成模式（風格規則、約束清單、範例結構）。citation-verifier技能使用提取模式（擷取主張、與來源比對）。

複雜度評估。 該任務能否在單一提示中完成，還是需要拆解？一個經驗法則：如果任務需要超過三個不同的認知操作，就進行拆解。

我的審議系統將拆解推得更遠：當信心度低（分數低於0.70）時，系統會產生多個代理獨立探索問題，然後按品質排序它們的回應。單一提示的複雜度閾值因情況而異，但我會拆解任何混合了研究、分析和生成的任務。

約束映射。 有哪些約束條件適用？Token限制、輸出格式要求、事實準確性需求、語氣要求、受眾考量。每項約束都成為提示中的一條明確指令。

階段3：決策

根據觀察和定向的結果，決定提示的架構：

提示模式選擇：

任務類型 建議模式 我的實際範例
提取 結構引導式提取 引用驗證器：提取主張，比對腳註
生成 約束清單 + 範例 部落格撰寫器：14條強制風格規則、語氣指南
轉換 輸入-輸出配對 + 保留清單 i18n翻譯器：保留markdown、程式碼、腳註
分析 加權評分標準 + 結構化輸出 部落格評估器：6個類別、加權評分
分類 標記範例 + 決策樹 內容深度檢查器：5個原創性訊號、0-5分

角色指派。 當任務受益於特定觀點時，角色就會發揮作用。我的security-reviewer子代理接收的角色是「資深安全工程師，審查程式碼中的OWASP Top 10漏洞」——這個角色將輸出聚焦在安全顧慮上。當角色與任務矛盾時，角色就會失效（例如在事實分析任務中指定「你是一位創意作家」）。7

階段4：行動

使用階段3的決策來撰寫提示。提示遵循一致的結構：

[ROLE] (if applicable)
[CONTEXT] (the information the model needs)
[TASK] (the specific instruction)
[FORMAT] (the expected output structure)
[CONSTRAINTS] (restrictions and requirements)
[EXAMPLES] (if using few-shot)

這個結構不是用來機械填入的範本。這個結構是一份檢查清單：觀察、定向和決策階段是否已經產生了足夠的清晰度來撰寫每個區塊？如果任何區塊不夠明確，就回到適當的前一階段。8

我的提示庫：44個技能作為結構化提示

我的Claude Code技能系統本質上是一個按任務類型組織的提示庫。每個技能都遵循OODA結構：

---
description: FastAPI backend development patterns and conventions
allowed-tools: [Read, Grep, Glob, Edit, Write, Bash]
---
# FastAPI Development Expertise

## Project Structure
[CONTEXT: expected file layout, naming conventions]

## Route Patterns
[CONSTRAINTS: response format, error handling, dependency injection]

## Database Patterns
[CONSTRAINTS: SQLAlchemy 2.0+ async, Pydantic v2 models]

技能描述處理了觀察（技能應該在何時啟動？）。allowed-tools欄位處理了定向（任務需要什麼能力？）。本體處理了決策和行動（模型應該遵循什麼模式？）。9

blog-writer-core技能編碼了14條強制風格規則——這些都是我透過失敗所發現的約束：

  1. 僅使用主動語態（「工程師安裝了」而非「被工程師安裝」）
  2. 不使用「這」作為主詞（始終指明所指對象）
  3. 每個主張都用腳註引用
  4. 程式碼區塊標記語言識別符
  5. 不使用破折號（改用逗號或分號）

每條規則的存在，都是因為我曾發佈過違反該規則的文章。規則#1來自blog-quality-gate鉤子捕捉到7個被動語態的句子。規則#3來自發佈了一個未引用的McKinsey統計數據主張。OODA的觀察階段識別了失敗；提示中的約束防止了再次發生。10

迭代循環

OODA循環本質上是迭代的。在行動（發送提示）並觀察結果之後：

  1. 觀察輸出：什麼是正確的？什麼是錯誤的？什麼是遺漏的？
  2. 定向差距：問題出在脈絡（缺少資訊）、格式（錯誤的結構），還是能力（任務對單一提示而言太複雜）？
  3. 決策修正方式：增加脈絡、調整格式指令，或拆解任務。
  4. 用修訂後的提示行動。

每次迭代循環應該只改變一個變數。同時改變多個提示元素會使得無法識別哪個改變產生了哪個效果。11

我的部落格評估工作流程遵循完整的迭代循環：

1. Lint (deterministic) → fix structural issues
2. Evaluate (LLM) → score on 6 dimensions
3. Critique (LLM) → identify specific improvements
4. Fix (LLM) → apply surgical improvements
5. Re-evaluate → verify score improved

每個步驟使用針對其任務類型最佳化的不同提示。Lint步驟使用提取（找出違規）。評估步驟使用分析（依據評分標準打分）。批評步驟使用生成（產出改善建議）。修正步驟使用轉換（在保留結構的前提下套用修改）。這個鏈式流程產生的結果優於單一的「改善這篇文章」巨型提示。12

關鍵重點

給建構AI功能的工程師： - 在撰寫提示之前，先完成完整的OODA循環；5分鐘的觀察和定向能省下30分鐘的反覆提示修正 - 在選擇提示模式之前，先分類任務類型（提取、生成、轉換、分析、分類）；每種類型都有成熟的模式，表現優於通用提示 - 建構按任務類型組織的提示庫；我的44個技能代表了經過驗證的提示模式，可跨專案重複使用

給每天使用AI的產品團隊： - 當AI輸出令人失望時，診斷失敗是在觀察（識別了錯誤的任務）、定向（錯誤的方法）、決策（錯誤的提示模式），還是行動（錯誤的提示措辭）；每個階段的修正方式各不相同 - 約束條件比精巧的提示措辭能防止更多失敗；我的部落格撰寫器的14條強制規則所產出的品質一致性，勝過任何「請寫好一點」的要求

參考資料

  1. Boyd, John R., “Destruction and Creation,” unpublished paper, 1976. ↩

  2. 作者的evaluator技能。透過反覆的提示失敗所開發的6類別加權評分標準。位於~/.claude/skills/。 ↩

  3. 作者的reviewer子代理架構。三個專門審查器（正確性、安全性、規範性），具備受限的工具存取權限和精確的評估標準。 ↩

  4. 作者的i18n翻譯系統。約束驅動的翻譯，在6種語言中保留markdown結構、腳註、程式碼區塊和專有名詞。 ↩

  5. Anthropic，“Prompt Engineering Guide,” 2025。 ↩

  6. Wei, Jason et al., “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models,” NeurIPS 2022. ↩

  7. Shanahan, Murray et al., “Role Play with Large Language Models,” Nature, 623, 493-498, 2023. ↩

  8. Anthropic，“Prompt Engineering Guide,” 2025。提示結構最佳實踐。 ↩

  9. 作者的Claude Code技能系統。44個技能作為結構化提示庫，具備OODA對齊的結構。 ↩

  10. 作者的writer-core技能。14條強制風格規則，每條都源自一次已發佈的品質失敗。 ↩

  11. Zamfirescu-Pereira, J.D. et al., “Why Johnny Can’t Prompt: How Non-AI Experts Try (and Fail) to Design LLM Prompts,” CHI 2023. ↩

  12. 作者的品質管線。5步驟的評估-修正-再評估循環，在每個階段使用任務專用的提示。 ↩