夜雨聆风前言
两年间，AI 开发从精心打磨提示词，到系统化管理上下文，再到构建五层安全框架。这篇文章梳理了这条演进路径，帮你判断自己处于哪个阶段，以及下一步该往哪里走。
本文由 5 分钟新知精选，今日前端早读课文章由 @Sarath Chandra Vidya Sagar Machupalli 分享，@飘飘编译。
译文从这开始～～
我想聊聊一件正在悄然改变那些认真对待 AI 工具的开发者们的构建方式的事情。
这并非一夜之间发生的。没有哪篇博客文章或哪场技术演讲一声令下就引爆了它。它是渐进式发生的，就像软件领域里大多数好想法的诞生过程一样。开发者们一次又一次撞上同样的问题，摸索出更好的解决办法，而这些更好的办法最终有了自己的名字。
这些名字是：提示工程、上下文工程和框架工程。
如果你在过去几年里用 AI 构建过任何东西，你很可能三者都做过，只是自己没意识到而已。这篇文章要做的，就是让这一演进过程变得清晰可见、有章可循，让你能更从容地决定把精力花在哪里。
"框架工程" 这个名字，在 2026 年初短短六周之内，从一个小众实践者的习惯，变成了软件开发圈里最热门的概念。Mitchell Hashimoto 在 2026 年 2 月 5 日写了相关文章，OpenAI 紧随其后于 2 月 11 日跟进，Martin Fowler 不久后也发表了一篇分析。这个术语就此流行起来。
但要理解框架工程为何重要，你得先看看我们是怎么一路走到这里的。故事要从两年前说起 —— 从提示词开始。
提示工程
它是什么
当 AI 语言模型变得触手可及时，开发者们最先注意到的一件事是：你提问的方式，对答案的质量有着巨大的影响。
如果你问 "修复这段代码"，你会得到一种答案。
询问 "修复这段代码，解释哪里出了问题，并确保修复方案兼容 Python 3.10"，你会得到一个有用得多的答案。
这个观察结果在成千上万的开发者中被重复了成千上万次，最终凝结成了一门学科。人们开始称之为 "提示工程"，并分享各自的心得。
措辞为何如此重要
语言模型读取你的提示词，和人类阅读一句话的方式完全不同。它做的是 —— 基于训练中学到的一切，预测你这段文字最有用的后续内容是什么。当你加入更多细节、更多约束、更清晰的目标时，你实际上是在收窄它可能给出的答案空间。这通常意味着，你会得到更接近你真正想要的东西。
用一种简单的方式来理解：
提示工程
写一条提示词、阅读回答、调整提示词 —— 这个循环基本就是提示工程的全部工作。概念简单，但知道如何调整，里面大有学问。
【第3572期】JSON 提示词：打造完美 AI 输出的终极指南
主要技巧
零样本提示（Zero-shot）
意味着你直接提问，不给任何示例。"把这句话翻译成法语。" 干净直接。对于模型在训练中大量见过的任务，效果很好。
少样本提示（Few-shot）
意味着在正式提问之前，你先给模型两三个示例。如果你希望模型以特定格式输出结果，直接展示输出应该长什么样，远比用文字描述可靠得多。就像带新同事时，直接给他看 "做完是什么样"，比写两页规格说明书管用得多。
少样本提示结构
思维链提示（Chain-of-thought）
意味着你让模型逐步推理问题，而不是直奔答案。只需加上一句 "在给出最终答案前，请一步步想清楚"，就能显著提升模型在数学、逻辑和推理任务上的准确率。当模型展示自己的推理过程时，它更容易发现自己的错误。
思维树提示（Tree-of-thought） 则更进一步。它不是沿着一条推理链走到底，而是让模型探索多种可能的路径，逐一评估，然后选出最优解。速度更慢，消耗的 token 更多，但对于真正棘手的问题，往往能给出更好的结果。
下面是思维树探索与直线式思维链的对比示意：
思维树处理过程
提示工程力所不及之处
提示工程在处理一次性任务时表现出色。写一条好提示词，得到一个好答案，然后继续做别的事。
问题出在于，当你试图构建可复用的东西，或者把 AI 工具嵌入日常工作流的时候。每次新对话都是从零开始的。模型不记得你上次说了什么。如果有些规则需要模型遵守，你每次都得重新交代。如果你的问题依赖于变化中的信息 —— 比如代码库的当前状态或最新的日志输出 —— 你得自己手动粘贴进去。
提示工程也解决不了团队一致性的问题。如果六个开发者在使用同一个 AI 工具，他们很可能写着六个不同版本的提示词，得到六种参差不齐的输出质量。
这些问题，正是上下文工程应运而生要解决的。
【早阅】复杂代码库中的AI提效秘籍：如何通过上下文工程避开大模型的“愚蠢区”
上下文工程
它是什么
上下文工程关注的是模型能获得哪些信息，而不仅仅是你如何措辞提问。
模型只能基于你提供的内容来工作。它不知道你私有代码库里有什么，不知道你的团队上周会议上做了什么决定，也不知道今天早上你的日志里出现了什么错误。如果这些信息中有任何一条与当前任务相关，你就得自己把它放进对话里。
上下文工程，就是把这件事做得深思熟虑、有条有理的实践。
上下文如何构建
给模型提供所需上下文，有几种方式。
系统提示词是位于对话之上的指令，在每一条消息中始终生效。你可以在这里放置诸如 "你是一位专注于 Python 的代码审查员"、"始终用通俗语言回答，绝不使用技术术语" 或 "在未征得确认之前，绝不建议删除数据" 之类的规则。把它们想象成常备命令。
对话历史是当前会话中所有已说内容的记录。当你在新请求中包含过往消息时，模型就能回溯之前的决定，保持前后一致。没有这些，模型对之前讨论过什么一无所知。
检索文档是一种技术 —— 你从知识库中搜索与当前问题相关的信息，并将其粘贴到提示词中。这通常被称为 RAG，即检索增强生成（Retrieval Augmented Generation）。其核心思想是：与其让模型凭借通用训练知识去猜测，不如让它阅读你从特定来源拉取的真实、最新的信息。
整体流程如下：
整体上下文流程
工具调用是让模型在对话过程中主动获取信息或执行操作的一种方式。你不必事先准备好所有上下文，模型可以自己索取它需要的东西。它可能调用一个天气 API、查询数据库或读取文件。这种方式更加动态，对于你无法预知确切需要哪些信息的任务尤为适用。
【第1046期】JavaScript 中的执行上下文和调用栈是什么？
模型上下文协议
MCP 正是在这里登场的。Anthropic 将 MCP 作为一个开放标准发布，用于连接 AI 工具与外部数据源及服务。在 MCP 出现之前，每个 AI 工具都必须为每个数据源单独构建定制连接器。有了 MCP 之后，你只需构建一次连接器，任何支持 MCP 的工具都能直接使用。
这就像 USB 改变了硬件世界一样。USB 之前，每种设备都有自己的接口。USB 之后，一个标准接口几乎通吃一切。MCP 试图为 AI 的数据连接做同样的事。
MCP 之前
MCP 之后
上下文工程力所不及之处
上下文工程是一大进步。拥有良好上下文的模型比仅靠精心措辞提示词的模型更稳定、更准确、更有用。
但一个拥有良好上下文的模型，终究只是一个模型。它无法判断自己即将做的事情是否有风险。它在即将搞坏什么东西时不会犹豫。它不知道什么时候该停下来。正如 Louis Bouchard 在 2026 年 3 月关于框架工程的文章中一针见血地指出的那样："更大的上下文窗口并不能神奇地把一个不靠谱的智能体变成一个可靠的系统。"
如果你只是用模型完成一次性任务，上下文工程就够了。但如果模型在执行多步骤的任务 —— 编写并运行代码、调用工具、在长时间会话中运行并需要断点续接 —— 仅靠上下文工程，是挡不住事情走向失控的。
这时候，你需要的是一个框架。
框架工程
它是什么
在现实世界中，harness（安全带 / 安全装置）是一组绑带和连接件，让人或物体在危险环境中工作时保持安全。攀岩者穿戴安全带，高架脚手架上的建筑工人穿戴安全带。安全带不做具体的活儿，人来做活儿。安全带确保的是 —— 万一出了差错，后果被控制在有限范围内。
框架工程将同样的理念应用于 AI 工具。
你围绕 AI 模型构建一套规则、检查机制和安全保障。模型仍然负责干活。框架确保的是：如果模型做错了什么，问题能被及早捕获，不会蔓延扩散。
Mitchell Hashimoto 对此有一个我觉得特别清晰的表述：当 AI 犯了一个错误时，你的任务是构建某种机制，确保这个特定的错误永远不会再次发生。不是仅仅修正这次的输出，而是改变整个系统，让模型下次不可能再犯同样的错。
这是一种完全不同于 "反复调整提示词直到得到好答案" 的思维方式。
框架的五个层次
一个精心构建的框架有五个层次。每个层次提供不同类型的安全保障。你不需要从第一天就把五层全部建好，但理解它们有助于你判断，对于你正在构建的东西而言，哪些层次最为关键。
框架工程的五个层次
第一层：边界限制
你首先要定义的是：AI 工具被允许做什么，以及它绝对不允许做什么。
这里说的不是指令或指南，而是硬性的结构限制。你不是在请求模型小心行事，你是在搭建环境，使得某些事情根本不可能发生。
一些常见的例子：
沙箱环境。 你在容器或虚拟机中运行 AI 工具，它只能看到特定文件，无法触及工作区之外的任何东西。即使模型生成了试图删除范围之外文件的代码，环境也不会让它得逞。
只读访问。 对于系统中某些敏感部分，你只授予 AI 工具读取权限，不给写入权限。它能看，但不能动。
网络规则。 你可以限制工具能够调用的外部地址。这能防止 AI 智能体向它不应该通信的地方发起意料之外的 API 调用。
限定文件访问范围。 你告诉工具它被允许在哪些目录中工作。如果你要求它修复支付服务的一个 bug，即使认证服务在同一个代码仓库里，它也不应该去碰。
这个层次之所以排在第一位，是因为它不依赖于模型做出正确的行为。它不依赖好的提示词或精心的指令。这些限制由环境本身来强制执行。这使得它们具有一种指令所不具备的可靠性。
框架工程 —— 边界限制
第二层：指令
第二层是你告诉工具应该做什么、遵循什么约定、避免哪些错误的地方。
这不同于一次性的提示词。这些是适用于工具处理的每一项任务的常备指令。它们存放在一个随项目一起的文件中，通常命名为 AGENTS.md 或 CLAUDE.md 之类，取决于你使用的工具。
【第2415期】Vue Directive指令的详细使用原理
这个文件可能包含：
你的团队使用的编码风格 哪些库是经过审批的，哪些不是 如何处理错误（记录日志，不要默默吞掉） 任务不明确时该怎么做（询问而非猜测） 过去曾导致问题的模式 文件、函数和变量的命名约定
Hashimoto 的核心洞见是：每次 AI 犯错时，你都应该更新这个文件。 不只是修正输出，而是更新文件。这样，教训就被记录下来了，工具的下一次运行从一开始就内置了这条教训。
随着时间推移，这个文件会变成你的团队在特定项目中与 AI 协作所积累的一切经验的日志。它是机构知识 —— 以模型能够真正读懂的形式记录下来。
指令
当我遇到 Secrets Manager 的 DNS 解析问题时，修复的关键不仅仅是改代码，而是理解为什么旧模式是错的，并把这种理解写下来，让错误不再重演。你的 AGENTS.md 就是那份总结，只不过是写给你的 AI 工具看的。
第三层：检查验证
第三层是你验证 AI 产出的东西是否真正能用、是否符合你的标准的地方。
对大多数开发者来说，这是最熟悉的一层，因为 CI/CD 流水线一直在做的就是这件事。区别在于，现在你需要把这些检查变成 AI 工具无法跳过的硬性关卡。
你需要关注的检查包括：
代码规范检查（Linting）。 代码是否遵循了格式和风格规则？Linter 能自动捕获这些问题，而且每次给出的结果完全一致。你不需要人工去逐行审视缩进。
类型检查。 如果你使用的是强类型语言，代码是否通过了类型检查器？这能在代码运行之前就拦截整整一类 bug。
单元测试。 现有的测试还能通过吗？AI 有没有破坏之前正常运行的东西？这些必须每次都跑。
集成测试。 被修改的代码与系统的其余部分能否正确协作？这更难自动化，但能捕获单元测试遗漏的问题。
安全扫描。 AI 是否引入了明显的安全隐患？有自动化工具可以做这件事。它们并不完美，但能捕获常见错误。
这一切中最关键的词是 "关卡"。AI 工具在这些检查通过之前不能继续推进。这不是建议，而是硬性要求。
检查验证
一个能够自我监视并对问题做出反应的系统，远比一个依赖人类去发现异常的系统可靠得多。验证层对于 AI 生成的输出而言，正是如此。
有一点值得注意：这些检查是确定性的。同样的代码输入，每次都会得到同样的结果。无论你用的哪个模型、提示词怎么写、今天星期几，结果都不会变。正是这种一致性，赋予了这一层如此重要的价值。
第四层：恢复
第四层回答的是一个听起来显而易见、却常常被忽视的问题：检查失败了怎么办？
如果没有恢复层，你只剩下两个糟糕的选项：AI 工具陷入死循环，不断试图修复一个它解决不了的问题；或者每次出了问题都需要人工介入。当你试图构建可靠的系统时，这两种情况都不可接受。
恢复层为你提供结构化的失败处理方式。
带次数限制的重试。 如果检查失败，把失败信息反馈给 AI，让它再试一次。但要设上限。如果连续失败三次，就停下来升级处理。一个不断重试又不断失败的 AI 既浪费时间，还可能把事情越搞越糟。
回滚。 如果 AI 做了一系列更改，系统状态反而比之前更差了，你需要一种方式把一切撤回到上一个已知的正常状态。如果你事先设置得当，版本控制就能实现这一点。
缩小范围。 有时候任务太大，AI 做到一半就迷失了方向。把任务拆成更小的片段，逐个单独重试，往往比重试整个任务效果更好。
升级给人类。 有些失败超出了自动化系统的处理能力。你需要一条清晰的路径，让这些情况摆到能够决定下一步怎么做的人面前。
框架工程 —— 恢复
恢复层是区分演示品和生产系统的分水岭。演示品可以承受有人盯着每次运行的代价。生产系统则需要在常规情况下自行处理故障。
第五层：审查
第五层是审查步骤，由另一个独立的 AI 工具或人类来完成。
【第3692期】告别基础设施焦虑：用Claude托管代理轻松构建代码审查工具
关键词是分离。完成工作的 AI 不应该是审查工作的那一个。有充分记录表明，模型倾向于认可自己的输出，即使它能看到其中的问题。它们对自己过于乐观。
一个独立的审查者，被赋予 "你唯一的任务就是找出这个输出中的问题" 这样的提示词，能够捕获原始工具遗漏的东西。它对已做出的决定没有任何执念，是用全新的眼光在审视。
有些团队设置了三步流程：一个工具规划方案，另一个工具执行工作，第三个工具审查成果。每个工具扮演不同角色，接收不同的指令集。
关于审查工具有一个值得了解的细节：Anthropic 自己的工程团队发现，在他们审查机制的早期版本中，评估者即使发现了问题，也倾向于通过输出。他们花了额外的功夫才让审查者真正对它检测到的问题坚持立场。即便是审查层本身，也需要精心调校。
为了让审查输出真正有用而非沦为噪音，按严重程度对发现进行分级是很有帮助的：
框架工程中的审查流程
对于涉及安全的系统，最后的人工审查步骤不是可选项，而是任何东西上线前的最终关卡。前面的 AI 层所做的是缩小需要人类关注的范围，但最终拍板的仍然是人。
在 SSL 中，信任不是一个简单的 "是或否" 的决定，而是一条链 —— 每个环节都必须经过验证，你才能信任下一个。框架的工作方式如出一辙。每一层验证某个具体的方面。最终输出之所以值得信赖，是因为链条中的每一环都经受住了考验。
三种方法如何协同
提示工程、上下文工程和框架工程不是相互竞争的理念，而是同一事物的三个层面。如果你想构建可靠运行的 AI 工具，三者缺一不可。
提示 + 上下文 + 框架工程的层次关系
下面是一个简单的方法，帮你判断自己目前处于哪个阶段，以及接下来该把重心放在哪里：
如何起步而不过度工程化
我是一个务实的开发者。除非复杂度能解决真实问题，否则我不愿意增加它。
所以，以下是我会根据风险大小来构建框架的方式：
如果你在探索或构建个人项目： 只从第二层开始。为你的项目写一份好的 AGENTS.md，AI 每次犯错时就更新它。仅此一项就能大幅提升一致性。个人项目不需要沙箱或审查流水线。
如果你要在团队工作流中引入 AI： 加上第三层。把现有的代码规范检查和测试接入，作为 AI 无法跳过的关卡。这能给你信心 ——AI 不会在暗处悄悄搞坏东西。确保对人类编写的代码运行的检查，同样也对 AI 编写的代码运行。
如果 AI 会执行影响数据或服务的操作： 加上第一层和第四层。锁定工具能触及的范围。设置好回滚机制。在问题发生之前就定义好出了问题该怎么办。
如果 AI 在处理涉及安全或面向客户的系统： 加上第五层。内置审查步骤。至少，任何进入生产环境的东西都要经过人工审查。其他层级负责缩小需要人工关注的范围，人工审查负责做最终决定。
关于信任的一点思考
在同时与传统软件系统和 AI 工具打交道的过程中，有一件事始终萦绕在我心头：信任是你逐步建立的，一层一层来。
当你部署一个新的微服务时，你不会从第一天就完全信任它。你监控它，加上告警，观察它在真实负载下的表现。随着时间推移，当它证明了自己，你才更多地依赖它。
AI 工具也是一样。框架就是你系统性地建立信任的方式，而不是心存侥幸地等着最好的结果。
框架的每一层都是一个检查点。你每增加一个检查点，就多了一个理由可以说："我信任这个输出，因为我知道它通过了这些特定的测试，经过了第二个工具的审查，并且它能尝试做的事情本身就被严格限定了。"
这比 "我看了一下输出，看起来还行" 要坚实得多。
结语
从提示词到上下文再到框架的演进，是任何新技术从新奇走向生产应用的自然路径。
早期，兴奋点在于这项技术到底能做什么。你发现精心编写的提示词能得到比随意提问好得多的答案。太棒了。你分享有效的做法。
然后你开始用它做正经工作，你意识到，对一个问题得到一个好答案，和构建一个可靠的系统，是两回事。你开始思考上下文、一致性，思考模型需要知道什么才能做好它的工作。
然后你把它放进生产环境，你意识到可靠性不仅仅取决于好的输入。它取决于出了问题时会发生什么。它取决于确保错误被捕获、故障被处理、输出可以被信赖。
这就是框架工程。它不光鲜亮丽，不是出现在演示中的那部分。但它是区分 "有时能用的工具" 和 "你真正能依赖的系统" 的关键所在。
关于本文译者：@飘飘作者：@vidyasagarmsc原文：https://hackernoon.com/from-prompts-to-harnesses-how-ai-engineering-has-grown-up
