← 返回文章列表

从提示词到循环工程：AI交互的四代演进

2026-07-01 AI提示词工程上下文工程约束工程循环工程产品经理

封面

最近刷X的时候，一组术语反复出现在我的时间线上：Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering。中文对应的叫法是提示词工程、上下文工程、约束工程、循环工程。

一开始我以为又是一批自媒体造的新词。后来认真去查了一圈，发现不是。这四个概念背后有一条清晰的演进脉络，从2022年到现在，AI的交互方式差不多换了四轮。每一轮变化，对应的能力要求都在往产品经理本来擅长的方向靠。

这篇文章就是这次调研的复盘。写给跟我一样，听说过这些概念、但还没深入研究过的产品经理。

四个概念总览：一条演进线

先把全貌放在这里，后面逐个展开。

阶段 中文名称 英文名称 时间 关注问题
第一阶段 提示词工程 Prompt Engineering 2022–2024 怎么跟AI说话？
第二阶段 上下文工程 Context Engineering 2025 给AI看什么信息？
第三阶段 约束工程 Harness Engineering 2026 建什么环境让AI可靠工作？
第四阶段 循环工程 Loop Engineering 2026 设计什么循环让AI自主运行？ 

timeline
    title AI交互方式的四代演进
    2022-2024 : 提示词工程 — 优化指令表达
    2025 : 上下文工程 — 设计信息环境
    2026初 : 约束工程 — 构建可靠运行环境
    2026中 : 循环工程 — 设计自动驱动Agent的循环

一句话串联：从“怎么说话”到“给什么信息”到“建什么环境”到“设计什么循环”。每一步都在往外扩展，每一步都把前一层包含进来。

提示词工程：怎么跟AI说话

什么时候出现的

提示词工程这个词在2022年底GPT-3和ChatGPT爆火之后开始大规模流行。OpenAI在官方文档里专门有Prompt Engineering的指南，教你怎么通过设计指令来引导模型输出更好的结果。到2023年，它几乎成了AI领域最热门的技能，网上到处都是“提示词工程教程”，连招聘市场上都出现了“Prompt Engineer”这个岗位。

为什么出现

早期大模型有一个很直接的特点：你怎么问，它就怎么答。同样一个问题，换个说法，输出质量可能差好几倍。比如你问“写一个客服回复”和“你是一个电商客服，请用亲切的语气回复用户的物流问题，包含查询订单号和安抚话术，50字以内”，后者的输出质量明显高一个档次。

这不是模型变聪明了，是你给的指令更精确了。提示词工程解决的就是这个核心问题：怎么把你的意图准确传达给模型。

它有什么用

提示词工程的常用技巧包括：

技巧 作用 举例
角色设定 给模型一个身份框架 “你是一个资深供应链产品经理”
示例引导 用样例告诉模型期望的输出格式 “比如：商品编码、SKU、单位”
思维链 让模型展示推理过程 “请一步步分析这个需求”
约束条件 限制输出范围和格式 “只基于以下文档回答，不超过200字”
输出格式 指定结构化输出 “以JSON格式返回，包含title和content字段”

对产品经理的启发

提示词工程的核心能力是描述需求，把模糊的想法变成精确的指令。这恰恰是产品经理每天都在做的事。写PRD、写需求文档、跟开发沟通需求，本质上都是在“提示”另一个执行者。

很多PM其实已经在无意识中使用提示词工程了。你在ChatGPT里描述一个产品需求让它帮你写文档，在Claude里让它帮你分析竞品，在Cursor里让它帮你改代码，每一条消息都是在写提示词。区别只在于，有的人凭直觉写，有的人知道背后的方法论。

含金量在哪

入门门槛最低，但天花板不低。大部分人写几句提示词就能用起来，但要把提示词写到能稳定控制输出质量、能复用、能团队共享的程度，需要很多实践。

不过也得说实话，到2026年，纯提示词工程的“技术含量”在被稀释。Karpathy说过，提示词工程是上下文工程的一个子集。模型越来越聪明，对提示词措辞的敏感度在下降。以前要精心设计的提示词，现在直接说大白话模型也能理解。这个趋势会继续，所以只会写提示词是不够的。

X上@alex_prompter总结得很到位：“提示词工程意味着写对一句话。上下文工程意味着给模型喂对信息。循环工程意味着把Agent包在一个程序里让它跑到测试通过。标签一直在换，底下的技能从来没变。”

上下文工程：给AI看什么信息

什么时候出现的

2025年6月18日，Shopify CEO Tobi Lütke在X上发了一条推文，说“我喜欢'上下文工程'这个词胜过'提示词工程'，它更好地描述了核心技能：为任务提供所有上下文，让LLM能合理地解决它”。这条推文在一周内引爆了整个AI社区，Andrej Karpathy、Simon Willison等大佬纷纷跟进背书。

Tobi Lütke 在X上说：“I really like the term 'context engineering' over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.”

Simon Willison（知名AI评论人）在博客里写道：“每次工业级LLM应用中，上下文工程都是填充上下文窗口的精妙艺术和科学。大多数人对提示词工程的印象是'给聊天机器人打字'，上下文工程这个叫法更接近真实含义。”

为什么出现

提示词工程解决了“怎么问”的问题，但Agent出现后，一个新的问题暴露了：模型在执行多步骤任务时，需要的不仅是好指令，还需要大量的背景信息。

比如你让AI Agent帮你分析一个竞品网站，它需要的上下文包括：你之前分析的竞品列表、你的产品定位、竞品的功能模块截图、你的分析框架、历史对话中确定的对比维度。这些东西光靠一条提示词塞不进去。

Anthropic在2025年9月的工程博客里把上下文工程定义为“在推理过程中策划与维护最优token集合的一整套策略”，并明确指出提示词工程是上下文工程的一个子集。

它有什么用

上下文工程关注的是模型在生成回答之前看到的所有信息。这些信息包括：

上下文类型 说明 举例
系统提示 定义AI的角色和行为规则 “你是供应链产品分析助手”
对话历史 当前会话中之前的交互记录 之前讨论过的需求、确定的方案
检索信息（RAG） 从外部知识库动态拉取的相关文档 产品文档、设计规范、历史案例
工具调用结果 AI调用外部工具后获得的数据 API返回的数据、搜索结果
长期记忆 跨会话持久化的用户偏好和历史 “这个用户偏好简洁回复”
可用工具定义 告诉AI它有哪些工具可以调用 搜索、代码执行、文件读写

Philschmid（Google前AI工程师）在博客里举了一个很好的例子：同样是帮用户回复一封会议邀请邮件。

没有上下文工程的Agent，只看到用户的消息，输出很机械：

“感谢您的消息。明天可以，请问您方便几点？”

做了上下文工程的Agent，会先拉取日历（发现明天排满了）、历史邮件（判断语气风格）、联系人列表（识别对方身份），然后输出：

“嘿Jim！明天我这边排满了，整天都有会。周四上午有空，你看合适吗？我已经发了邀请，到时见。”

区别不在模型，在上下文。

对产品经理的启发

做产品需求评审的时候，你不会只给开发一句话就去干活。你会准备PRD、设计稿、竞品分析、用户反馈、技术约束，这些就是开发理解需求的“上下文”。

上下文工程跟这个逻辑一模一样。你给AI准备什么样的信息环境，直接决定了它的输出质量。产品经理本来就擅长“组织信息”这件事，把散落在各处的信息汇总、筛选、排优先级，然后以合适的格式给到执行方。上下文工程就是把这个能力用在AI身上。

含金量在哪

从“写一句话”升级到“设计一个信息系统”，含金量的提升是质变。提示词工程是点状的，写好一条指令；上下文工程是系统级的，构建一个动态的信息供给体系。

对于产品经理来说，这一层最值得投入。因为这里需要的能力不是写代码，而是理解业务场景、判断哪些信息是必要的、设计信息供给的时机和格式。这些都是PM的核心能力。

四层嵌套：不是替换，是套娃

约束工程：给AI套上缰绳

什么时候出现的

2026年2月，HashiCorp联合创始人Mitchell Hashimoto提出了Harness Engineering这个概念。X上@dotey（宝玉）发了一条推文，用“马具”的类比解释了这个概念，获得了大量转发。

宝玉在X上说：“Harness字面意思是'马具'，套在马身上让人能控制马匹方向和力量的那套装备。AI Agent就像一匹动力十足但不太守规矩的马，Harness就是让它既能跑得快又不会跑偏的缰绳和马鞍。”

为什么出现

上下文工程解决了“给AI什么信息”的问题，但一个新的问题暴露了：Agent开始连续行动了，但会失控。

华为开发者社区有一篇文章举了个真实案例：某企业的无人监控Agent因为没有约束，陷入无限循环，API账单累积了5万美元才被发现。模型本身没问题，上下文也给够了，但没有人管住它的行为边界。

这就是约束工程要解决的核心问题：不只是给AI好的信息和指令，还要给AI建一个可靠的运行环境。包括工具权限、行为约束、反馈循环、错误恢复、状态持久化等。

它有什么用

约束工程关注的是AI运行的整体环境。用一句最能说明问题的话来概括：

OpenAI Codex团队的首席工程师Ryan Lopopolo说过：“Agent不难，Harness难。”

他的团队7个工程师用一个GPT-5 Agent，5个月内生成了大约100万行代码和1500个PR。没有一行代码是人写的。能做到这一点，靠的不是模型有多强，而是他们给Agent建了一套极其严密的Harness，

Stripe的“Minions”系统更极端，每周自动合并超过1300个PR，完全不需要人工审核。它的Harness有一个“两次失败规则”：Agent第一次修CI失败没成功，任务直接升级给人，防止无限重试烧钱。

对产品经理的启发

约束工程的核心是流程设计和权限管控。定义AI能做什么、不能做什么、出错了怎么办、什么时候升级人工，这不就是产品经理做系统设计时天天干的事吗？

你在设计一个审批流程：什么金额自动通过、什么金额需要主管审批、什么金额要走VP。现在同样的逻辑要应用到AI Agent上：什么操作Agent可以自动执行、什么操作需要人工确认、什么情况直接熔断停止。

产品经理在“定义规则边界”这件事上有天然优势。开发工程师擅长实现约束，但“应该约束什么”这个决策，更多是产品判断。

含金量在哪

约束工程是2026年最前沿的话题之一。YouTube上Cole Medin做了一期“Harness Engineering: What Separates Top Agentic Engineers”的视频，6万多播放。他提到一个数据：有人拆解了Claude Code的架构，发现大约98%是Harness，只有2%是模型本身。

这意味着什么？意味着在AI Agent领域，竞争力的来源正在从模型能力转移到系统设计能力。而系统设计能力，恰恰是产品经理可以深度参与的层面。

约束工程：给AI套上缰绳

循环工程：设计驱动AI的循环

什么时候出现的

2026年6月，OpenClaw项目作者Peter Steinberger在X上发了一条推文，核心观点是：别再手动提示你的编码Agent了，去设计自动提示它的循环系统。这条推文获得了大约650万次浏览。

Boris Cherny（Claude Code团队，Anthropic）说了一句很有冲击力的话：“我已经不提示Claude了。”

第二天，Google工程师Addy Osmani发表了“Loop Engineering”的完整文章，给了这个实践一个名字和解剖结构。tosea.ai的指南把它定义为“设计提示、检查、记忆、重跑AI Agent的系统，而不是你手动打每一条指令”。

为什么出现

到2026年中，编码Agent已经能长时间自主运行了，能自己读代码、改代码、跑测试、看报错、再改。瓶颈从“提示词写得好不好”转移到了“循环设计得好不好”。

一句话概括变化：你不再是在聊天框里打字的那个人了，你是设计那台驱动聊天的机器的那个人。

它有什么用

循环工程的核心是把AI的工作变成一个自动循环：Agent采取行动→收到环境反馈→判断下一步→继续行动，直到达成目标或触发停止条件。

Addy Osmani把一个设计良好的循环拆成了几个组件：

组件 作用 说明
自动触发器 启动循环 定时器、事件监听、代码提交触发
工作树隔离 并行不冲突 每个Agent在一个独立git worktree里工作
技能包 复用能力 把常用操作封装成可复用的Skill
连接器 对接外部系统 API、数据库、监控等
子Agent 分解大任务 把复杂目标拆成多个子任务分给不同Agent
外部状态 跨循环记忆 把中间状态写到文件或数据库，不靠上下文窗口记住一切

tosea.ai的指南里给了一个实际例子：目标是“让payments-refactor分支的CI变绿”。循环跑起来后，Agent拿到自己的git worktree、终端、测试运行器、类型检查器。它自己读失败的测试→定位原因→打补丁→重新跑测试→读输出。如果同一个测试连续失败3次，自动升级给人。你第二天醒来看到的是一个草稿PR和一条完整的操作记录。

对产品经理的启发

循环工程是四个层级里最高的一层。它要求的能力不是写提示词、不是组织信息、不是设计约束，而是编排一个自动运转的系统。

产品经理在做大流程设计的时候，实际上就是在做类似的事，设计一个端到端的业务流程，定义每个环节的输入输出、判断条件、异常处理、升级机制。循环工程把这些能力用在了AI Agent的流程编排上。

不过说实话，循环工程目前对非技术背景的PM来说门槛还是比较高的。它需要理解Agent的运行机制、状态管理、上下文压缩等技术概念。但理解它的思路和方向是有价值的，因为这就是AI Agent的发展方向，未来会越来越多的工具把循环设计变得可视化、低代码化。

含金量在哪

循环工程是目前最新、信息量最大的概念。它直接关系到AI Agent能不能真正自主工作，从“你给AI发指令”到“你设计一个系统自动给AI发指令”。理解了这一层，你看到的就是AI Agent架构的最前沿。

X上@alex_prompter提醒了一个现实：“一个循环跑一个任务可能烧掉50到100美元的API费用。循环工程是给有预算的玩家用的。”这也说明，循环工程目前还在早期阶段，但它代表的方向是确定的。

循环工程：你设计循环，AI在里面跑

对产品经理来说意味着什么

把这四个概念放在一起看，你会发现一件很有意思的事。


graph TD
    A["提示词工程
怎么说话？"] --> B["上下文工程
给什么信息？"]
    B --> C["约束工程
建什么环境？"]
    C --> D["循环工程
设计什么循环？"]
    
    A -.->|"包含于"| B
    B -.->|"包含于"| C
    C -.->|"包含于"| D
    
    style A fill:#f5f4ed,stroke:#c96442,stroke-width:2px
    style B fill:#f5f4ed,stroke:#c96442,stroke-width:2px
    style C fill:#f5f4ed,stroke:#c96442,stroke-width:2px
    style D fill:#f5f4ed,stroke:#c96442,stroke-width:2px
阶段 核心问题 对应的PM能力
提示词工程 怎么描述需求？ 需求描述能力
上下文工程 给什么背景信息？ 信息组织与编排能力
约束工程 什么规则和边界？ 流程设计与权限管控能力
循环工程 怎么编排自动流程？ 系统编排能力

这四个能力，产品经理本来就在用。写PRD是需求描述，做需求评审是信息编排，设计审批流是权限管控，做端到端流程是系统编排。区别只是，以前你把这些能力用在人和系统之间，现在要用在AI和系统之间。

有一个趋势对PM特别有利：AI越聪明，“会描述需求”就越值钱，“会写代码”的相对价值就在下降。当模型能自己写大部分代码的时候，决定AI产出质量的不再是编码能力，而是你能不能准确描述你想要什么、能不能给AI组织好正确的信息、能不能设计合理的约束和循环。

拓展学习

视频推荐

图文推荐

结尾

四个概念串成一句话：提示词工程解决“怎么说”，上下文工程解决“给什么”，约束工程解决“管什么”，循环工程解决“怎么自动跑”。

这四层不是替代关系，是嵌套关系。每一层都包含前面所有层，做约束工程的时候，你仍然要写提示词、组织上下文；做循环工程的时候，四样都要。

产品经理不需要会写代码，但需要理解这条演进方向。因为在AI时代，决定AI产出质量的越来越不是技术实现，而是需求描述、信息组织、流程设计、系统编排，这些恰好是产品经理的核心能力区。

文中引用的X推文、博客文章和YouTube视频均为原始来源，数据截至2026年7月。四个概念的英文术语目前尚无统一的中文翻译，本文使用的“提示词工程/上下文工程/约束工程/循环工程”为社区常见译法。