行业出新黑话的速度永远比出新技术快。继 prompt engineering、vibe coding 之后，本月开发者圈的高频词换成了两个：context engineering 和 loop engineering。Pragmatic Engineer 连发两期专题，一期对谈 context engineering 的代表人物 Dex Horthy，一期直接发问"什么是 loop engineering"。
每次看到新词我的第一反应都是警惕：又来收智商税了？但认真读完这两期，结论是这次的词虽然新，指向的问题是真的，而且是当下用 AI 写代码的人每天都在撞的墙。
值得花十分钟搞清楚。
Context Engineering：喂什么，比怎么问更重要
Prompt engineering 关心"怎么问"，context engineering 关心"模型在回答之前，看到了什么"。
用过 AI 编程工具的人都有体感：同一个问题，有时答得神了，有时蠢得离谱。差别往往不在提示词，在上下文窗口里装了什么。装了对的文件，一步到位；装了不相关的历史对话和错误代码，模型顺着垃圾往下长。
Context engineering 就是把这件事从碰运气变成工程：
| 实践 | 说人话 |
|---|---|
| 上下文预算 | 窗口是稀缺资源，每个 token 都要值回票价 |
| 主动供给 | 别等模型乱猜，把架构文档、约定、示例主动喂进去 |
| 及时清场 | 长对话跑偏了就开新会话，别在污染过的上下文里挣扎 |
| 外置记忆 | 项目约定写进 CLAUDE.md / AGENTS.md 这类文件，让每次会话都自带背景 |
一句话总结：AI 的表现上限由模型决定，实际表现由你给它的上下文决定。
Loop Engineering：设计循环，而不是盯着每一步
Loop engineering 更进一步。它的出发点是：既然 agent 已经能自主跑几十步，人的角色就该从"每步都看着"变成"设计一个能自我纠错的循环"。
一个合格的循环长这样：agent 改代码，跑测试，测试挂了自己读报错，自己修，再跑，直到绿灯或者触发上限求助。人要设计的是这个循环的四个件：
- 目标信号：什么算成功？测试通过、类型检查干净、性能达标，必须机器可判定
- 反馈通道：报错信息、日志能不能完整回流给 agent
- 护栏:哪些文件不许动，哪些操作要人批准
- 熔断：循环多少轮没进展就停下来喊人
本周有个热帖是绝佳注脚：Bun 团队用 AI 辅助快速把大量代码重写成 Rust。这种项目靠的就不是某一次神级对话，是"改写、编译、测试、修复"这个循环被设计得足够扎实，AI 在里面转几千圈也不出轨。
新词背后的真信号
剥掉包装，这两个词共同宣告了一件事：瓶颈换位置了。
2024 年的瓶颈是模型不够聪明。2026 年的模型已经强到"给对上下文就能干对活"，于是瓶颈变成了人：你会不会组织信息、会不会设计流程。这跟管理学的老道理一模一样：下属能力越强,管理者越该管目标和机制,而不是管动作。
所以别被黑话吓到，也别急着买课。这两样"工程"的核心实践，你今天就能开始：
- 给项目写一份 AI 看的说明文件（约定、架构、常见坑）
- 让测试快起来、报错清晰起来，这是 agent 循环的地基
- 复杂任务先让 AI 出计划，确认了再放手跑
- 跑偏就换新会话，别恋战
我的看法
Prompt engineering 当年被嘲笑是"新时代的搜索技巧"，后来它的精华沉淀进了产品，这个词就退役了。Context engineering 和 loop engineering 大概率走同一条路：词会消失，实践会变成默认。
真正的分水岭不是你会不会用新词，是你的项目对 AI 友不友好。两年后回头看，“有没有为 agent 重构过工作流"会像今天"有没有上 CI"一样，成为团队工程水位的分界线。