上周有位读者私信我，说去面一家中厂的AI工程师岗位，面试官开口问：“你了解Prompt Engineering吗？”他很自然地答了上来，把怎么写好提示词、Few-shot怎么用、Chain of Thought怎么做都讲了一遍。面试官听完点点头，说了声“不错”。
然后他反问了对方一个问题：“那您了解Loop Engineering吗？”面试官明显愣了一下，说：“这个……是新的概念吧？我不太清楚，要不你说说看……”他当时有点哭笑不得，心想你面AI工程师，连Loop Engineering都不知道？就没忍住小声嘀咕了一句：“你们这些概念都不追的吗？”然后索性给面试官反向补了一课，从Prompt Engineering讲到Context Engineering，再到Harness，最后落脚到Loop Engineering。面试官听完沉默了一会儿，说：“你这个理解挺深的。”
说实话，在AI这个圈子里，新概念确实需要追一追。提出这些概念的，几乎都是深耕行业很久的人，梳理清楚它们的演化脉络，本身就能给我们带来不少启发。今天就把这四个概念的关系一次理清。
AI圈有个很明显的规律：新概念的迭代速度，一点不输底层模型的参数爆炸。但把它们拆开看，会发现每个词都精准标记了一个历史节点，清晰勾勒出AI从“被动作答的工具”走向“主动完成任务的Agent”这条演化路径。
不如换个视角来理解。把大模型想象成一位刚入职的 “天才实习生”——学历惊艳、智商极高，但缺实战经验，具体怎么干活，得看你怎么带。
1. Prompt Engineering（提示词工程）：教实习生读懂黑话
最早一批人的做法，是把指令说得足够好。设定角色、提供示例（Few-shot）、逼它逐步推理（Chain of Thought）……本质上，这些都是在优化一次对话的质量。就像用一张备忘录向新员工交代工作——备忘录写得漂亮，对方才不会交出一堆垃圾作业。
可这层优化的天花板很明显。提示词再精妙，也只能决定“开场白”写得多漂亮，解决不了模型手里“没有足够信息”的问题。
值得一提的是，Prompt Engineering大约在2022到2024年间达到全盛，随后迅速走向商品化。模型越来越聪明，会说话的人也越来越多，写提示词的壁垒自然越来越低。
2. Context Engineering（上下文工程）：给实习生准备详尽的背景资料
单靠一条指令不够，问题自然转移到“模型到底能看到什么”上。
Shopify创始人Tobi Lütke在2025年6月给出了一个被广泛引用的定义：把任务所需的全部背景，塞进模型在推理时能看到的位置，让它至少有机会把活干成。Andrej Karpathy的说法更具画面感，他说这是“把对的信息塞进上下文窗口的精细艺术”。具体手段包括RAG检索、Prompt Caching、对抗“Lost in the Middle”现象的信息密度控制等。
做法上，Prompt Engineering并没有消失，它只是降了一级，变成了Context Engineering的一个子集。
3. Harness（基准/治理框架）：给实习生定KPI和质检标准
进入多步骤自主任务之后，新问题随之出现：谁来验证模型的输出是否达标？
Harness的本意是“挽具”，套在马身上让它听使唤。放到AI工程里，它指的是围绕模型运行的整套脚手架——测试工具、输入输出约束、格式校验、评估框架，都算在内。这一层的核心不是“怎么问”，而是“怎么判断答得对不对”。
如果说Prompt Engineering是让AI接受任务，Context Engineering是让AI看清任务，那Harness就是防止AI交出一份“看起来没问题，其实跑不通”的作业。
LangChain、LlamaIndex这类框架本质上都是Harness层的工程化封装。Anthropic在2024年12月发布的《Building Effective Agents》里提出的“评估者-优化者”和“编排者-执行者”模式，也是在同一个维度上做设计。
4. Loop Engineering（循环工程）：让实习生在挨打中学会自我进化
到了这一层，思维方式发生了根本性转变。前三个阶段，人依然是那个在循环外面等待结果的人。而Loop Engineering把这个位置腾了出来——让系统自己去转：执行 → 观察结果 → 判断是否达标 → 如果没有，重新规划 → 再次执行。人退到了更外面的一层，变成了“设计循环本身”的人。
这个概念在2026年6月正式成形。Claude Code的创建者、Anthropic的Boris Cherny在一场小型活动上说了一句话，触发了整个社区的讨论，他说：“我不再写提示词了。我写的是循环。是循环在提示Claude，决定下一步干什么。”
OpenAI工程师Peter Steinberger随后跟进，指出不应该再手动提示AI编程助手了，而应该设计让AI自己提示自己的循环。Google工程师Addy Osmani将整个模式整理成文章，“Loop Engineering”这个词也就此定型。
这当然不是凭空冒出来的。学术层面上，2022年ReAct论文已提出“让模型在推理与行动之间交替循环”的框架；2023年Reflexion论文进一步把“语言强化学习”引入Agent的自我修正过程。从学术到实践，中间隔了几年的工程摸索。
Cherny本人的工作记录提供了一个很典型的实证案例。2025年11月他卸载了自己的IDE，过去一整月没打开过。仅上个月，他团队在Claude Code上提交了259个Pull Request、497次commit，没有一行代码是手动敲下去的。
这不只是个人习惯的变化，而是整个工程生态的位移。截至2026年初，GitHub上约4%的公开commit已经由Claude Code生成，SemiAnalysis预计到2026年底这一比例可能超过20%。
从这条演化路径往回看，你会发现每一步都是对上一步的“包裹”，而非替代：
Prompt Engineering解决的是“怎么开口”，Context Engineering解决的是“看到什么”，Harness解决的是“怎么验收”，Loop Engineering解决的是“谁来持续驱动”。每一层都没有消失，只是下沉成了基础设施。
不过这里有一个值得思考的反例：Loop Engineering并不适用于所有场景。
对于高度不确定的探索性任务，或者需要实时人类判断的工作流，一个全自动的闭环反而可能带来风险——它会在错误的方向上越跑越远，直到你发现问题时已经积累了大量偏差。LangChain的实践中明确提出，在敏感操作或关键节点引入“人在回路”（Human-in-the-Loop），是设计良好Loop的标配，而非降级选项。
所以说，Loop Engineering的真正门槛不是“会写循环”，而是知道在哪里设终止条件、在哪里留一个人工卡点。
如果未来最值钱的AI工程师不再是“会写最好的提示词”的人，那会是谁？大概率是这样一类人：他们设计的循环，能在没有人盯着的情况下，自己把活干完，自己发现错误，自己重新规划。而一旦撞上只有人才能判断的岔路口，又知道该在哪里停下来等一下。
听起来，这更像是“系统设计”，而不是“和AI对话”。
在云栈社区里，也有很多朋友在讨论类似的AI工程化话题——从RAG的落地细节，到Agent的循环控制策略，这种工程层面的探索，或许比追逐单个新概念本身更有价值。
发表于 昨天 23:54
|
查看: 2|
回复: 0
