"提示词工程"在 2024 年达到顶峰。OpenAI 发布新模型带动了一波又一波的提示词技巧热。企业急着给员工培训 few-shot 示例和思维链技术。提示词工程课程成了新的营收品类。
从业者早已转移了注意力。不是因为提示词不再重要，而是因为他们发现提示词根本不是正确的抽象层级。
2025 到 2026 年间，真正形成的工程学科是 AI 原生工作流设计，它横跨三个完全不同的层级，每个层级需要不同的技能、不同的组织结构、不同的投入优先级。
这篇文章给出三层框架，解释各层如何组合成生产系统，以及为什么你的组织很可能投错了方向。
提示词工程的陷阱
先说陷阱，再说框架。
提示词工程聚焦于写好单次模型交互的指令。优化系统提示词。增加示例。调整温度。追求更好的响应。这项工作并非无用——好的提示词仍然重要。但它只针对整体系统性能中很窄的一个波段。
真正的问题在于：在生产环境的 AI 工作流中，单次提示词交互几乎从来不是瓶颈。真正的瓶颈是：
- 上下文选择：模型在推理时实际看到了什么信息，是不是该看的信息？
- 多步骤一致性：当一个任务需要连续调用模型五次，如何维持状态、如何避免错误传播、如何确保每一步都正确地建立在前一步的基础上？
- 人工介入：人什么时候提供指导、什么时候审批决策、什么时候处理模型无法解决的边界情况？
- 组织嵌入：AI 工作流如何与团队结构、决策权限、业务流程对接？
这些问题在完全不同的抽象层级，和写提示词不是一回事。它们需要的是架构思维，而不是语言调优。它们才是真正的工程杠杆所在。
Anthropic 的上下文工程框架把这一点说得很清楚。核心命题是：上下文是一种有限资源，工程问题是找到最小的高信号 token 集合，以最大化达到预期结果的概率。上下文工程不是在上下文窗口里塞更多信息，而是对系统每一层进行无情筛选。
Addy Osmani 从 Google 视角给出了类似的转变描述。在他的 AI 原生工程师 playbook 中，他把从"执行者"到"编排者"的转变描述为根本性的心态变化。把 AI 当作协作者而非计算器的工程师，会发展出完全不同的直觉——他们用工作流思考，而不是用提示词思考。
微软的 AI 原生工程流研究给这个结论提供了数据支撑。三个月的真人 AI 智能体团队实验发现，前期共同规划占用的 22% 工程时间是防止下游返工的最重要因素。在写代码前投入工作流设计的团队，虽然开头感觉更慢，但交付的系统更干净、速度更快。
这些发现指向同一个方向：工作流架构的投资回报率远高于提示词调优。
三层框架
AI 原生工作流设计横跨三个水平抽象层级。每层有自己的工程学科、自己的失败模式、自己的优化策略。
┌─────────────────────────────────────────────────────────────┐
│ 第三层：组织整合层 │
│ AI 工作流如何嵌入人类团队和业务流程 │
├─────────────────────────────────────────────────────────────┤
│ 第二层：工作流编排层 │
│ 多步骤智能体过程如何串联、路由和管理 │
├─────────────────────────────────────────────────────────────┤
│ 第一层：模型交互层 │
│ 如何配置、约束和与模型通信 │
└─────────────────────────────────────────────────────────────┘
三层是水平分离的，因为每层运行在不同的抽象层级。第一层处理单次模型调用的微观层面。第二层处理多步骤过程的中间层面。第三层处理组织嵌入的宏观层面。某一层的变化不会自动级联到其他层，这意味着每层可以独立优化——但系统要正常运行，三层必须被一起设计。
第一层：模型交互层——调用级别的上下文工程
第一层governs如何在与模型的单次调用中进行交互。这是上下文工程所在的位置，也是目前公开最佳实践最成熟的层级。
上下文工程是提示词工程的后继
Anthropic 的框架给出了明确区分。提示词工程聚焦于指令中的措辞。上下文工程更宽泛——它包含推理时进入上下文窗口的所有 token，包括系统提示词、工具定义、检索到的文档、对话历史，以及任何任务特定的指令。
核心原则是最小可行上下文：找到产生预期输出所需的最小高信号 token 集合。任何不直接服务于任务的 token 都是噪声，它和信号竞争，并消耗你的注意力预算。
这有直接的实践含义。系统提示词应该在正确的高度上写——足够具体以有效引导行为，但足够抽象以提供强力启发而非脆弱规则。Anthropic 描述了两种失败模式：提示词过低（在过度指定的硬编码 if-else 逻辑中变得脆弱且难以维护）和提示词过高（过于模糊，错误地假设模型无法推断的共享上下文）。
最优系统提示词居于中间。它清晰定义角色、行为边界和输出预期，但为模型的判断留出空间。它将内容组织成独立区块——角色定义、行为约束、工具指导、输出格式——而不是把一切埋进长篇文字。
系统提示词即契约
把系统提示词想成工程师和模型之间的契约。契约规定模型应该做什么、它可以访问什么信息、预期输出是什么。和任何契约一样，清晰比长度重要。契约中的歧义导致争议；系统提示词中的歧义导致不可预测的行为。
契约思维改变了写提示词的方式。不是写"有帮助且专业"，而是写"你是一个代码审查助手。审查 Pull Request 时，识别最关键的三个问题，每个问题用一句话解释。除非违反团队已确立的代码风格指南，否则不要评论风格偏好。"
努力校准和 token 预算管理
每次模型调用都有 token 成本，每个上下文窗口都有有限容量。第一层工程必须同时考虑两者。
努力校准意味着将模型的处理与任务实际复杂度相匹配。简单分类任务不需要和复杂推理问题一样的上下文深度。Anthropic 的研究显示，许多工程师在简单案例上过度工程化，在复杂案例上工程化不足——这和产生好结果的做法正好相反。
Token 预算管理将这种思维扩展到完整上下文窗口。如果你构建一个需要数十次调用的长周期智能体，必须规划上下文如何随时间增长，以及何时压缩或重置。Addy Osmani 在 Google 的 AI 原生工程研究同样指出了这一点：忽视 token 预算的团队在中途遇到能力上限，模型开始丢失对早期上下文的跟踪。
结构化输出 schema
当模型输出进入下游系统时，需要可预测的结构。JSON 模式、XML 标签和约束解码是第一层工具，用于让输出可被机器读取，而不是依赖对自由文本的脆弱解析。
这里的纪律是：在开始写提示词之前先定义输出 schema。决定你需要哪些字段、每个字段应该是什么类型、有哪些约束。然后提示模型产生完全符合该结构的内容——并利用模型自身的错误响应和工具返回格式来强化契约。
第二层：工作流编排层——串联、路由和管理多步骤智能体
第二层governs多个模型调用如何组合成连贯的过程。这是智能体架构所在的位置，也是大多数未解决的工程问题所在。
智能体链 vs. 智能体群
多步骤 AI 过程有两种主要模式：链和群。
智能体链是顺序的：步骤 A 的输出成为步骤 B 的输入，步骤 B 产生步骤 C 的输入，以此类推。每一步在序列上是确定的（如果不在内容上）。链更容易推理、更容易调试、更容易测试，因为数据流是线性的。它们适合有清晰程序结构的任务——提取、转换、验证、输出。
智能体群是更分布式的拓扑：多个智能体并行工作，彼此通信，汇聚到共享输出或决策。群更具韧性，可以并行探索解空间，但更难调试，需要明确的协调协议。
微软的 AI 原生工程流研究在贷款处理参考项目中使用了多智能体群。他们发现，对于复杂、多维问题，群比链产生了更稳健的解决方案，但需要在智能体协调协议和"人工升级"路径上进行更多前期投入。
链和群之间的选择是架构性的，不是战术性的。当问题有清晰顺序时从链开始。当问题需要并行探索，或单个智能体处理一切会造成 token 瓶颈时，迁移到群。
人工介入检查点
没有任何自主智能体系统在生产中应该完全无人值守。第二层设计必须指定人在哪个环节进入流程。
人工介入检查点有多个用途：在错误传播之前捕获错误、为模型无法解决的模糊情况提供判断、为影响决策的后果创建问责。
关键设计问题不是是否包含人，而是哪里放人。微软的研究识别了升级模式——智能体标记不确定性而不是猜测的场景。建立了明确升级路径的团队比试图让智能体完全自主的团队获得了更好的结果。智能体学会了说"我需要更多信息"而不是猜测。
有效的检查点设计意味着识别工作流中错误成本超过人工审查成本的决策点。对于代码审查助手，这可能是每个安全相关变更。对于贷款处理智能体，这可能是每个超过货币阈值的申请。检查点对人类来说应该快速且清晰——一个带有足够决策上下文的有重点问题，而不是对整个系统状态的开放式审查。
多模型路由
工作流中的每一步不需要最强大——也最昂贵——的模型。第二层设计包含哪个模型处理哪个步骤的决策。
路由逻辑可以简单或复杂。简单路由将分类任务发送给快速便宜的模型，将复杂推理任务发送给前沿模型。复杂路由可能根据估计的任务难度动态路由，通过模型自身置信信号或从过去性能中学习的启发式方法来衡量。
Addy Osmani 的编排模式描述了一个"模型选择矩阵"，团队在其中将任务类型映射到模型能力和成本，然后构建尊重该矩阵的路由逻辑。纪律是根据数据而非假设来衡量每种任务类型的实际性能和成本，然后迭代路由规则。
工具使用定义和错误恢复
工具是智能体与模型外部世界交互的方式。第二层工程包括工具接口的设计——每个工具做什么、需要什么输入、返回什么输出、错误如何传达。
Anthropic 关于为智能体编写工具的指导强调清晰优于完整。工具描述应该描述工具做什么，面向有新团队成员但不了解该工具特定知识的人。避免歧义。避免列出每个边界情况。提供输入输出示例。
错误恢复是大多数智能体工作流崩溃的地方。当工具调用失败时，智能体需要一个策略：用修改后的参数重试、尝试替代工具、请求人工指导、或通过产生带有明确错误标记的最佳努力输出来优雅降级。
微软的"通过提示构建"发现具有指导意义：他们观察到循环loop——智能体在失败方法的变体之间循环——需要明确的人工干预协议。修复不是更好的提示词，而是一个结构化的"重置并思考"模式，智能体识别循环并暂停等待人工输入。
第三层：组织整合层——将 AI 工作流嵌入人类系统
第三层governs AI 工作流如何连接到团队、流程、决策权限和治理结构。这是讨论最少的层级，也是大多数组织 AI 计划停滞的层级。
AI 原生团队结构
传统工程团队每个技术负责人带 8 到 12 名工程师。AI 原生团队看起来不同。微软的研究发现，最有效的人机团队配置使用更小的人类团队——3 到 5 人——支持多个各有专长的 AI 智能体。
这是结构性变革，不只是工具变革。一个 3 人小组加三个专精 AI 智能体可以处理以前需要 10 人团队的工作量。但 3 人小组需要不同的管理、不同的沟通模式、不同的问责结构。
人类的角色从执行者转变为质量负责人的和升级处理者。智能体在其专长范围内处理常规实现。人类处理模糊性、战略决策和跨智能体协调。
变革管理和技能重定价
组织不能简单地把 AI 智能体螺栓到现有流程上就期望有结果。第三层整合需要重新思考工作如何完成——哪些流程改变、哪些角色演变、哪些技能变得更有价值、哪些变得不那么相关。
Addy Osmani 标记了技能侵蚀作为真实风险。当 AI 处理常规编码任务时，从未建立扎实基础的工程师可能会失去批判性评估 AI 输出能力。答案不是限制 AI 使用，而是投资 AI 无法替代的互补技能——系统思维、架构、批判性评估。
组织也应该明确技能重定价：纯实现技能的市场价值正在下降，而工作流设计、质量判断和系统架构的价值正在上升。培训预算应该跟随这个转变。
治理和审计追踪
做出影响决策的 AI 工作流需要治理结构。当 AI 工作流产生坏结果时，谁负责？如何审计发生了什么？如何证明符合法规？
第三层治理设计包括：决策日志（每个影响决策的模型调用及其输出都被记录）、责任分配（每个工作流的结果有明确负责人）、定期审查流程（抽样 AI 决策进行质量和偏见审计）。
微软的共同创作伙伴关系框架将治理作为内置而非后加的。他们的"共同创作伙伴关系八要素"模板包含问责和升级的明确章节。该模板为人机协作设计，但其问责原则适用于在组织内运行的任何 AI 工作流。
衡量 AI 原生团队生产力
传统工程指标——代码行数、故事点数、Pull Request 数量——无法捕捉 AI 原生的生产力。一个团队通过 AI 辅助在每个 sprint 交付 40 个功能，但其中 30% 被标记为严重 bug，并不比一个交付 20 个功能且无需热修复的团队更有生产力。
第三层衡量必须发展。AI 原生团队的有用指标包括：任务完成率（分配的任务有多少百分比到达生产且不需要重大返工）、错误传播率（某一步的 AI 错误在后续步骤中引起错误的频率）、人工介入频率（工作流需要人工解决模型无法处理的问题的频率）、以及从分配到生产部署的周期时间。
这些指标比传统指标更难收集。但它们才是决定 AI 原生团队是否有效的实际因素。
各层如何组合：生产案例
三层是抽象。在生产中，它们必须一起工作。下面是实际运作的方式。
以一个跨越全部三层的 AI 原生代码审查系统为例。
第一层（模型交互）：代码审查助手使用结构化系统提示词，指定其角色（安全审查助手）、行为约束（未经批准不重写代码，标记但不修复风格问题）和输出格式（带严重级别的结构化 JSON）。工具定义最小且精确：一个用于搜索代码库的 tool，一个用于读取文件内容。Token 预算按审查设置——如果上下文增长超过预算，助手收到相关文件历史的压缩摘要而不是完整 diff。
第二层（工作流编排）：审查工作流是一个链：接收 PR → 获取 diff → 分析安全问题 → 分析正确性问题 → 分析性能问题 → 汇总发现 → 格式化输出。每步使用相同模型但配合不同上下文窗口和不同输出 schema。人工介入检查点放在安全分析步（任何严重发现都会触发强制人工审查，然后才能发送报告）和汇总步（人工在报告发布前审查最终报告）。如果模型在任何步产生低于阈值的置信度分数，工作流路由到更有能力的模型或暂停等待人工审查。
第三层（组织整合）：审查系统集成到团队的 Pull Request 流程中。结果由 bot 账户以内联评论形式发布，而不是来自人类的消息。团队已约定，所有安全严重发现都需要指定的人类审批人才能合并 PR。审查质量每月衡量：标记的问题有多大比例被人类审查员确认，有多大比例的严重问题被遗漏？这个指标反馈到第一层提示词优化和第二层路由逻辑。
系统之所以有效，是因为每层都考虑了其他层进行设计。第二层的检查点策略尊重第一层的 token 预算。第三层的治理规则定义第二层存在哪些检查点。第一层的输出 schema 设计时就考虑了第二层汇总步骤和第三层审计日志系统的消费。
与现有框架对比：Naresh 的 6 层模型
你可能见过 Naresh 的 6 层 AI 工程模型，它在开发者社区中获得了很多关注。它描述垂直流程层：数据层、检索层、提示层、推理层、评估层和服务层。每层代表处理 AI 请求的一个阶段。
本文提出的三层框架不是替代品——而是一个互补的视角。
Naresh 的模型描述单个 AI 请求如何流经系统——这是管道视角。三层框架描述AI 原生组织如何运作——这是组织视角。
两者互补，因为 Naresh 模型中的管道阶段映射到三层的特定设计决策。检索层映射到第一层上下文选择。提示层映射到第一层系统提示词设计。推理层映射到第二层编排选择。服务层映射到第三层基础设施和集成决策。
当你在调试特定 AI 请求或设计特定处理管道时，用 Naresh 的模型。当你在思考组织能力、团队结构或投资优先级时，用三层框架。
FAQ
提示词工程现在完全没用了吗？
不是。提示词质量在第一层仍然重要。但它是更大系统的一个组件，不是整个游戏。一个出色的提示词无法弥补设计糟糕的工作流或没有弄清楚如何将 AI 整合到其流程中的组织。作为整体工作流设计工作的组成部分投资提示词，而不是作为独立计划。
我怎么知道先投哪一层？
从诊断你当前的 AI 计划在哪里失败开始。如果你的模型在孤立时产生良好输出，但在多步骤任务中崩溃，这是第二层问题。如果你的 AI 工作流技术上是健全的但没有改变业务成果，这是第三层问题。如果单次模型调用不可靠或不可预测，这是第一层问题。大多数组织发现第三层改进空间最大，因为那里组织惯性最高。
可以跳过某些层吗？
可以试试，但你会撞墙。在第一层混乱之上构建复杂的第二层编排会产生不可靠的系统。在脆弱的第二层工作流之上做第三层整合会产生被法律、安全或运营团队阻挠的 AI 计划。各层是抽象，但层之间的依赖是真实的。
第二层"编排工程师"实际上做什么？
他们设计并维护智能体工作流：链、路由逻辑、检查点策略、错误恢复协议和智能体健康监控。他们与第一层工程师密切合作以确保模型交互被良好指定，并与第三层利益相关者合作以确保工作流满足组织需求。这个角色正在兴起——还没有标准 job description，但它处于软件工程和 AI 产品管理的交叉点。
如何衡量三层的投资回报率？
第一层 ROI 通过每次任务模型成本和任务成功率衡量。第二层 ROI 通过端到端工作流完成率、错误传播频率和人工介入频率衡量。第三层 ROI 通过 AI 工作流设计影响的业务成果指标衡量——周期时间减少、缺陷率、客户满意度。正确的指标取决于你在解决什么问题。在干预发生的层级衡量，但在成果重要的层级评估。
结语：投资工作流设计能力，而不是提示词工程课程
AI 做得好的组织，不是提示词写得最好的，而是弄清楚如何跨三层设计和运营 AI 原生工作流的。
这需要不同的投资命题。不要送工程师去提示词工程研讨会，而是在内部建设工作流架构能力。雇用或培养能在编排层面和组织整合层面思考的人，而不只是模型交互层面。
不要通过提示词质量衡量 AI 成功，而是通过工作流完成率和业务成果衡量。构建连接第三层性能数据回到第一层和第二层改进的反馈循环。
提示词工程时代没有结束——但它是更大 discipline 的一个子集。如果你仍然把 AI 工程当作提示词写作问题，你是在用工具包的子集解决一部分问题。
三层框架给了你完整地图。现在的工作是在全部三层上建设运营能力。
相关文章
- Harness 工程：从珍妮纺纱机到 AI 的组织革命 — AI 系统扩展思维的基础框架
- Token 预算是能力上限，不是消费预算 — 第一层上下文经济的深度分析
- MCP vs CLI：为什么命令行正在赢得 AI Agent 的接口之争 — 第二层工具接口设计的决策参考