← 所有文章

提示工程的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：代码审查器。 我的第一个审查提示：”审查这段代码的bug和安全问题。”模型返回了15个发现，其中12个是风格上的吹毛求疵。信噪比使审查毫无用处。

OODA修正： 我将任务判断为三个独立的子任务（正确性、安全性、规范性），并构建了三个专用的审查子代理，每个都有受限的工具访问权限和特定的评估标准。正确性审查器只标记逻辑错误。安全审查器只标记OWASP漏洞。规范审查器只标记模式偏差。噪声降到了接近零，因为每个提示都被严格限定在单一维度上。3

失败3：翻译提示。 “将这篇博文翻译成韩语。”模型完成了翻译，但丢失了所有markdown格式，删除了脚注引用，并重写了本应保留英文的技术术语。

OODA修正： 我观察了”翻译”对于我的用例实际意味着什么：保留markdown结构、保留脚注编号、保持代码块不翻译、保持专有名词为英文、改编惯用语而非直译。约束条件清单最终比翻译指令本身还要长。每条约束都消除了”翻译这个”会产生的一种失败模式。4

将OODA循环应用于提示工程

第一阶段：观察

在编写提示的任何一个字之前，先观察问题空间：

实际任务是什么？ 不是表面的请求，而是底层的需求。”总结这份文档”实际上可能意味着”提取这次会议做出的三个决定，以便我跟进行动项。”

模型需要知道什么？ 列举正确回复所需的上下文。缺失的上下文会导致幻觉。过多的上下文会浪费token，并可能分散模型的注意力。

输出应该是什么样子的？ 在编写提示之前，定义期望输出的格式、长度、语气和结构。模糊的输出预期会产生模糊的输出。5

观察检查清单： - [ ] 已识别实际任务（非表面请求） - [ ] 已列举所需上下文 - [ ] 已定义输出格式 - [ ] 已指定成功标准 - [ ] 已预见失败模式

第二阶段：判断

在模型的能力空间中对任务进行定位：

任务类型分类。 任务是提取（从提供的文本中获取信息）、生成（创建新内容）、转换（在格式之间转换）、分析（评估和推理内容），还是分类（对输入进行归类）？6

每种任务类型都有成熟的提示模式。我的44个技能体现了这一模式：blog-evaluator技能使用分析模式（加权评分标准、结构化评分）。blog-writer-core技能使用生成模式（风格规则、约束清单、示例结构）。citation-verifier技能使用提取模式（抽取主张、与来源匹配）。

复杂度评估。 任务能否在单个提示中完成，还是需要分解？一个经验法则：如果任务需要超过三个不同的认知操作，就应该分解。

我的审议系统将分解推向了更深层次：当置信度较低（分数低于0.70）时，系统会生成多个代理独立探索问题，然后按质量对其回复进行排名。单提示的复杂度阈值因情况而异，但我会分解任何混合了研究、分析和生成的任务。

约束映射。 有哪些约束适用？token限制、输出格式要求、事实准确性需求、语气要求、受众考量。每个约束都成为提示中的一条明确指令。

第三阶段：决策

基于观察和判断，决定提示架构：

提示模式选择：

任务类型 推荐模式 我的实际案例
提取 模式引导的提取 引用验证器：提取主张，匹配脚注
生成 约束清单 + 示例 博客写作器：14条强制风格规则，语气指南
转换 输入-输出对 + 保留清单 i18n翻译器：保留markdown、代码、脚注
分析 加权评分标准 + 结构化输出 博客评估器：6个类别，加权评分
分类 标注示例 + 决策树 内容深度检查器：5个原创性信号，0-5分评分

角色分配。 当任务需要特定视角时，角色设定会发挥作用。我的security-reviewer子代理接收的角色是”负责审查OWASP Top 10漏洞的高级安全工程师”——该角色将输出聚焦于安全问题。当角色与任务矛盾时（例如为事实分析任务设定”您是一位创意作家”），角色设定则会失效。7

第四阶段：行动

使用第三阶段的决策编写提示。提示遵循一致的结构：

[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步骤使用提取（查找违规）。evaluate步骤使用分析（按评分标准评分）。critique步骤使用生成（产出改进建议）。fix步骤使用转换（在保留结构的同时应用更改）。这个链式处理比单一的整体式”改进这篇文章”提示产生更好的结果。12

关键要点

面向构建AI功能的工程师： - 在编写提示之前执行完整的OODA循环；5分钟的观察和判断可以节省30分钟的迭代式提示优化 - 在选择提示模式之前对任务类型进行分类（提取、生成、转换、分析、分类）；每种类型都有成熟的模式，其效果优于通用提示 - 构建按任务类型组织的提示库；我的44个技能代表了经过验证的提示模式，我在各个项目中复用它们

面向日常使用AI的产品团队： - 当AI输出令人失望时，诊断失败究竟出在观察（识别了错误的任务）、判断（方法不对）、决策（提示模式不对），还是行动（提示措辞不对）；每个阶段的修正方法各不相同 - 约束比巧妙的提示措辞能防止更多失败；我的博客写作器的14条强制规则比任何程度的”请写好”都能产出更一致的质量

参考文献

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

  2. 作者的评估器技能。通过迭代式提示失败开发的6类别加权评分标准。位于~/.claude/skills/。 ↩

  3. 作者的审查子代理架构。三个专用审查器（正确性、安全性、规范性），具有受限的工具访问权限和狭窄的评估标准。 ↩

  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. Prompt structure best practices. ↩

  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步评估-修正-再评估循环，每个阶段使用针对特定任务的提示。 ↩