AI编程进入上下文工程时代

提示词不再是核心，循环和记忆才是

2026年6月，AI编程领域出现了三个看似独立、实则指向同一趋势的信号。

OpenClaw创始人Stanberg在X上发了一条推文："你不应该再给编程Agent写提示词了。你应该设计循环来提示词你的Agent。"这条推文获得了800万次浏览，评论区变成了混战。

同一天，Cursor发布了《2026年春季开发者习惯报告》，用18个月的真实数据揭示了AI编程的变化轨迹：开发者每周新增代码量同比增长一倍，每次提交的代码量增长2.5倍，AI生成的代码在被接受后60分钟仍然保留在代码库中的比例从76%上升到81%。

更早之前，开源项目context-mode登顶GitHub和Hacker News，声称能让AI编程成本降低98%，将大模型的有效编程时间从30分钟提升到3小时。

这三个信号的共同指向是：AI编程的竞争焦点，已经从"模型有多聪明"转移到了"上下文管理有多好"。

从提示词到循环：Stanberg的争议

Stanberg提出的"loop工程"概念，最早其实是Claude Code创始人Boris Cherny提出的。他在访谈中说："我现在已经不给Claude Code写提示词了，那些loop替我写。我的工作只有写loop。"

loop工程的核心思路很简单：传统编程里，循环执行的是明确的指令序列；AI Agent里的loop执行的是目标。你不需要把所有可能的情况都写死，只需要给Agent一个目标，提供必要的工具和上下文，然后让它在循环里自己摸索。

Agent loop的公式是：目标→行动→观察→评估→修正→下一轮行动。

这个公式的每一步都不是固定的。Agent需要观察当前状态，判断应该采取什么行动，执行行动后再观察结果，评估是否达到了预期，然后决定下一步怎么走。

澳洲放羊大叔Geoffrey Huntley在2025年7月发布的ralph项目，就是一个典型的Agent loop实践。它本质上是一个bash脚本，把同一个提示词文件反复输入给Agent。真正创新的地方在于纪律性——每次迭代都会重置上下文到一组固定的锚点文件，而不是让对话无限增长。用这个方法，他构建了一整个编程语言，花费约297美元。

到了2026年春天，Codex和Claude Code都推出了/goal命令，把ralph的产品化了。这个命令会一直运行循环，直到验证完成。

但Stanberg说的loop，已经不单单是"让一个Agent反复做某个任务"那么简单了。他把loop当成一种可以长期运行、互相协作、自动调度的AI工作系统。具体来说，loop是工作的基本单位。以前我们给AI下达的指令是"帮我修一个bug"，所有任务是一次性的，做完就结束。但loop虽然也是任务，它是一个持续运转的工作单元——比如每天检查GitHub issue，判断哪些需要修，自动分配给Agent，修完后跑测试，失败就继续改，成功就提交PR。

当你有了多个loop在同时运行时，新的问题就出现了：谁来协调它们？谁来决定优先级？谁来检查它们的工作质量？

Stanberg的设计是用loop去监督其他loop。一个总loop负责观察全局，发现有几个任务，分发给多个子loop，每个子loop自己跑，总loop检查它们的进度和结果。

争议也随之而来。有人质疑loop会消耗大量token，除非有无限token否则还得人工测试。有人讽刺这又是炒作新概念，"loop工程会取代harness工程"。从上一个新概念"harness"到现在也只不过才一两个月，大家还没来得及消化就要接受新知识。

Cursor数据：AI编程正在走向端到端自动化

Cursor的报告给出了更具体的数据。2026年开年以来，未经人工逐行审核、直接被自动接受并进入代码提交的AI修改，增长了5倍以上。

这意味着开发者越来越信任AI，愿意让它独立完成更多提交流程中的工作。AI编程正在从"辅助单个开发者"的工具，演变为一套端到端自动化软件开发流程的完整系统。

另一个值得关注的数据是：顶尖1%的用户获得的收益远高于其他人。P99开发者产出的代码行数是活跃中位用户的46倍，合并的提交次数是中位提交者的15倍。AI并没有天然抹平开发者差距，反而先放大了高手的优势。

懂架构、会拆任务、能判断模型输出质量的开发者，会把AI变成杠杆。而只把AI当成问答工具的人，获得的提升会有限。

报告还揭示了一个成本趋势：不同模型系列的单次请求成本相差近9倍，但看"最终留下的代码"，最大差距只有7倍——因为贵模型一次能写出更多能用的代码，并不像表面看起来那么昂贵。

输入Token现在占输入输出总量的90%以上，上下文已成为非缓存模型使用中的主要部分。缓存读取Token占了Token活动总量的绝大部分，说明现在的AI工作越来越依赖重复利用之前的上下文，而不是每次都从头读取所有内容。

context-mode：给AI编程减负的开源方案

context-mode的创始人Mert Köseoğlu曾作为技术顾问为OpenAI等企业提供服务，团队核心成员分布在土耳其、法国等国，主要通过GitHub异步协作。这个项目发布后登顶GitHub和Hacker News，已获得超过1.5万颗Star，吸引了超过24.3万名开发者接入。

它解决的核心痛点是"模型失忆"和"Token过多消耗"。团队成员孙逸诚分享了一个踩坑经历：参加Kaggle数据竞赛时，他把一个包含300组数据的训练任务交给了Claude。为了确认任务进度，Claude没有选择写一段定时脚本，而是选择每隔5秒钟向整个项目发起一次全局检索。这种低效的"死盯"策略，让一个高配会员账号的API额度在半小时内消耗了90%。

context-mode的解法是引入"虚拟沙盒"与精准检索。它在大模型和操作系统之间建立一道"防火墙"，先把所有文件和运行记录存放在本地，需要用到时再帮大模型把相关内容找出来。

《智能涌现》的测试结果显示，接入context-mode后，大模型读取一份79.3KB的文件时，Token消耗成本降低了87.7%。

为了解决"失忆"问题，context-mode通过构建"存档点"实时监控开发者的每一次文件编辑。当对话太长时，它会主动向AI注入一个通常小于2KB的"快照"，相当于在代码编辑过程中建立了一个存档点。官方表示，这种机制能将大模型连续编程的有效时间从30分钟提升到3小时。

最后，context-mode引入了强制性"用代码思考（Think in Code）"的范式——不让模型逐行阅读、处理文件，而是先让模型编写一个"小程序"，让小程序先在本地完成数据分析，再将提炼后的结果反馈给模型。根据测试，接入context-mode后，模型处理一份文件时节省了99.98%的Token成本。

上下文工程：AI编程的新护城河

把这三件事放在一起看，一个清晰的趋势浮现出来了。

早期AI编程产品比的是模型能力和交互体验，谁生成得准、响应得快。但随着任务变复杂，真正的护城河会逐渐转向上下文管理、缓存效率和成本控制。

AI编程不再只是"更聪明的代码编辑器"，而是在逼近一套新的软件生产基础设施。

这个基础设施的核心组件有三个：

第一是目标定义。 一个好的目标应该是可验证的。"帮我优化一下"不是好目标，什么叫优化？优化到什么程度算完成？有哪些约束条件？这些都不清楚。一个好的目标应该是："把这个接口的响应时间从800毫秒降到300毫秒以下，保留现有行为，所有测试必须通过。"

第二是上下文管理。 上下文不只是你跟模型的对话那么简单。代码库的当前状态、相关文档、需求说明、错误日志、测试结果、用户偏好、历史决策，以及之前几轮的尝试和结果，这些都是上下文。很多Agent表现差，根本原因不是模型不够聪明，而是loop每一轮喂给它的上下文太脏、太少，或者太随机。

第三是循环纪律。 澳洲大叔ralph的成功不在于它的模型有多强，而在于它有纪律——每次迭代重置上下文到锚点文件。context-mode的"存档点"机制本质上也是纪律。没有纪律的循环，只会产生无限增长的对话和指数级增长的Token消耗。

未来的AI编程工具，竞争的不在是模型有多聪明，而是谁能把传给AI的无效噪音压缩到极致，谁能帮开发者把连续编程的时间从30分钟延长到3个小时。

无限上下文是一个伪命题，克制才是AI工具最难建立的壁垒。