AI编程的瓶颈不是模型， 是你没给结构

⚠

LOOP ENGINEERING

AI编程的瓶颈不是模型， 是你没给结构

为什么你塞满上下文，AI还是干不好活？

停！

你还在往prompt里塞上下文？

需求文档贴进去，架构设计贴进去，历史代码贴进去，恨不得把整个项目目录压缩了往里塞——然后祈祷AI一次性给你生成个能跑的东西？

真是见鬼了！

"这是你每月的提醒：你不该再给编程Agent写提示词了。你应该设计循环来提示你的Agent。" — Peter Steinberger，OpenClaw创始人，现OpenAI

"我不再给Claude写提示词了。我有循环在跑，它们负责提示Claude并判断下一步怎么做。我的工作是写循环。" — Boris Cherny，Claude Code创建者

Addy Osmani——Google Cloud AI总监——随后写了篇长文，正式命名：Loop Engineering

三个人，三个组织，从不同方向走到了同一个结论。

但你注意到没有？这些话听起来很酷，可市面上的解读文章，全在讲"Loop Engineering是什么"——五要素、四层栈、范式演进，像教科书一样工整。

没有人回答一个最要命的问题：

为什么你塞满上下文，AI还是干不好活？

THREE FATAL FLAWS

上下文迷信的三大死法

你以为AI编程的瓶颈是模型不够强？

不是。

瓶颈是你没给AI一个它能稳定执行的工程结构。而"塞满上下文让AI一次干完"这个主流做法，有三种死法，每一种都够你喝一壶。

01

上下文遗忘

你给AI塞了一整个需求文档，它前几页还记得，写到后面就忘了前面。这不是bug，这是大模型的物理特性——注意力衰减。

你跟一个新员工说："这是全部需求，你一次干完。"他会干好吗？不会。那凭什么觉得AI会？

02

上下文漂移

更阴险。AI不是忘了，是跑偏了。你让它重构模块A，它写着写着开始"优化"模块B，再写两轮连模块C的接口都改了。你以为它在帮你，其实它在给你挖坑。

等你发现的时候，代码已经面目全非——你review的都不是你自己设计的东西了。

03

上下文超限

最绝望的一种。你塞了10万token的上下文，AI写了5万token的代码，token炸了。全部白干。从头来过。

就像你让一个人连续工作48小时不睡觉，做到一半直接昏倒——连做到哪了都说不出来。更恶心的是，你连"它写到哪了"都不知道——因为中间过程没有检查点，没有验收，没有沉淀。一炸回到解放前。

Reddit上有个匿名帖说得好：凌晨三点，他发现自己已经不认识自己的代码库了。

这就是上下文迷信的结局——你把AI当全能神，AI把你当实验品。

有人可能说："那我用更长的上下文窗口不就行了？"

可以。但你算过账吗？上下文越长，token消耗越猛，遗忘和漂移的概率并没有降低——你只是花了更多的钱，赌同一个概率。

你缺的不是更长的上下文，是更严的纪律。

THE SOLUTION

Loop Engineering：记忆+拆解+可验证

正规军怎么干？三个字：不依赖上下文。

大任务执行不依赖context，而是依赖规划和项目记忆。这是Loop Engineering的核心命题。展开来说，三件事：

01

记忆

不是让AI记住上下文，而是把工程状态沉淀下来。项目的架构决策在哪？哪些模块已经重构完了？下一步该干什么？这些东西不该存在于AI的"短期记忆"里，而应该存在于磁盘上——一个Markdown文件，一个看板，一个backlog。

Addy Osmani自己也强调：记忆必须存在磁盘上，而不是在上下文里——模型在每次运行之间会忘掉一切。

你想想Scrum里的Product Backlog和Sprint记录，是不是同一回事？每个迭代开始，你不需要把全部历史给团队讲一遍——backlog就在那，Sprint记录就在那。团队靠的是这些沉淀下来的工程记忆，而不是开会时临时说的那几句话。

02

拆解

被执行的任务一定要小。最小化的交付单元。

为什么？因为小任务才能被AI稳定执行，且降低单点失败成本。一个15万行的重构任务，你让AI一次干完，那就是上下文超限的命。但如果你把它拆成50个可独立交付的小任务呢？每个任务AI都能稳定完成，单个任务失败也只影响自己，不会拖垮全局。

这跟Scrum里把史诗级需求拆成Story和Task，是不是一模一样？一个Sprint只做能在这个迭代内完成的事。

03

可验证

交付单元必须可验证。越明确的可验证，越好交付。

为什么？因为可验证=可闭环。AI写完一个任务，你能验证它对不对——对了，进入下一个循环；错了，立刻修正，不会让错误在后续循环里滚雪球。这是AI自主循环的前提。你连"对不对"都判断不了，循环个什么？

Scrum里的Definition of Done，就是同一个东西。每个Story有明确的"完成定义"，团队才能在Sprint Review时判断"这个到底做没做完"。

记忆=Backlog+Sprint记录，拆解=Story，可验证=DoD，循环=Sprint Review+Retro

Loop Engineering不是什么新发明。它是Scrum的工程纪律，迁移到了AI自主执行的场景里。

区别只有一个：Scrum里执行的是人，Loop Engineering里执行的是AI。但纪律是一样的——你不给AI一个它能稳定执行的工程结构，它跟一个没有Sprint计划、没有backlog、没有完成定义的团队一样，只会越干越乱。

PROOF

15万行重构，30PD上线，0故障

说这些都是理论，给你看个实战的。

一个重构项目——15万行代码，3个系统合1个。正常这种规模，3到6个月起步，甚至更长。

团队用AI辅助，30个人天上线，0故障。提效70%以上。

怎么做到的？就是上面那三件事：

靠记忆——项目维度的工程记忆，每次AI执行之前，不需要把全部上下文重新喂一遍，规划就在那，状态就在那，AI读的是沉淀下来的记忆，不是临时的上下文。

靠拆解——15万行的重构不可能一次干完。三个系统，每个系统几十个模块，每个模块再拆成可独立交付的单元。一个单元就是一个循环——AI改完，验证通过，进下一个。单个单元失败了？只影响自己，不会拖垮全局。

靠可验证——重构项目的特点就是验收标准明确：输入不变，输出不变，中间逻辑重构。目标→计划→验收标准，循环往复。每个循环结束，验证通过才进入下一个。不是AI自己判断"我写完了"，而是你的工程结构告诉它"这轮过了，下一轮"。

市面上讲Loop Engineering的文章，没有一篇拿出过这样的交付数据。全在讲概念——五要素、四层栈、范式演进。

概念不值钱，交付才值钱。

有人说Loop就是cron job，有人说这是新瓶装旧酒。这些质疑不是没道理——如果你只是让AI跑起来就完事了，那确实跟cron job没区别。

但Loop Engineering的价值从来不是"让AI循环"，而是用工程纪律保证AI在每个循环里稳定交付。

征哥锐评

说白了——20年前没有Scrum的团队，跟今天没有Loop Engineering的AI编程，是同一种病：没有纪律的执行，只会越干越乱。

Scrum治的是人，Loop治的是AI，药方一样。

你缺的不是更强的模型，是更严的纪律。

征哥的知识架构笔记

技术圈的代码判官 · AI时代的架构领路人