Boris Cherny 那句话很刺耳：“我不再提示 Claude，我写循环去提示 Claude。我的工作是写循环。”

这句话点破了 AI 编程最近一个更重要的变化：人不再只是和 Claude Code 这类工具来回对话，而是在外面搭一个 harness，把任务排队、调用模型、检查结果、失败重跑，直到机器判断可以收工。

反常点就在这里。以前模型说 done，人来验收；现在 done 这个信号，也开始交给机器判断。软件工程的控制权，正从“人盯着模型”挪向“系统驱动模型”。

agent loop 和 harness loop，差别不小

普通 agent loop 比较好理解：模型读文件、改代码、跑测试、提交一个结果。人通常还在旁边，决定要不要接受。

harness loop 多了一层外壳。任务先进入队列，外部系统反复调用模型，评估结果，补上下文，开新会话，甚至换模型继续干。它关心的不是一次回答好不好，而是一整套循环能不能把任务推到“可接受”。

对比项agent loopharness loop
驱动方式人给任务，模型执行队列给任务，系统调度模型
完成判断人通常参与验收机器评估占比上升
适合任务单次改动、局部修复可反复验证、可批量推进的任务
最大风险模型写错系统把“错的完成”规模化

这和“用 AI 写代码快一点”不是同一个问题。速度只是表层。更深的问题是：谁在定义完成，谁在保留理解，谁在负责后果。

对工程师来说，这意味着工作重心会变。少写一部分样板代码，多写任务描述、验证脚本、回归测试和约束条件。不会写 harness 的人，可能很快会觉得自己只是在给模型补充说明。

对技术负责人来说，采购 AI 编程工具不该只看 demo 速度。更该看三件事：能不能接入现有测试体系，能不能留下可审计的决策轨迹，能不能让人类在关键改动前停下来。

循环很好用，但边界很硬

我不把这件事看成反 AI 的故事。恰恰相反，harness loop 在一些场景里非常有效。

代码移植就是典型。MiniJinja 到 Go、Bun 部分从 Zig 到 Rust，都可以作为事实锚点：旧实现在那里，行为可以对照，测试可以补上，循环有东西可抓。

性能探索也适合。机器可以反复改参数、跑 benchmark、丢弃失败方案。人类最烦的枯燥试错，正好是循环擅长的活。

安全扫描更不用说。别人会用 loop 找你的漏洞，也会用 loop 给你报问题。维护者不想用，也可能被 AI 生成的报告量推着用。curl 维护者被大量 AI 生成报告压住，就是早期压力的样子。

场景为什么适合循环我的判断
代码移植有旧实现、有测试、有可比输出适合，前提是行为验证足够强
性能实验可反复试错，失败成本低很适合，人负责设指标
安全扫描攻防双方都会自动化不用也会被卷进去
研究探索需要发散，产物可丢弃适合找路，不适合直接沉淀核心代码
核心基础设施、数据格式依赖强不变量和长期解释目前仍危险

危险主要出在长期代码上。现阶段 loop 写长期代码，毛病很稳定：过度防御、局部修补、复杂化、回避强不变量。

看到异常，就加 fallback。看到坏状态，就多包一层处理。测试绿了，结构却更糊了。

Karpathy 说过模型“极度害怕异常”。这句话放进系统设计里很要命。很多时候正确做法不是处理所有坏输入，而是让坏状态根本写不进去。

这里有一条现实约束：如果你的验证体系很弱，harness loop 只会把弱验证跑得更勤快。跑一百遍，也不会自动长出工程判断。

创业者和工具开发者也该换个方向。别只做“更会改代码”的包装层。真正有价值的是任务队列、回归验证、权限边界、可回放日志、人工拦截点。没有这些，产品看着像自动化，实质是把风险藏进吞吐量里。

真正的分水岭：结束信号、理解权、维护权

我更在意三个权力。

谁判断任务完成？谁能解释这段代码为什么这样写？模型访问、成本或能力断供时，谁能接盘？

如果一个代码库由 loop 生成、由 loop 审查、由 loop 修补、由 loop 维持生命，它就已经不是普通的“用了 AI 工具”。它更像一种默认需要机器参与维护的系统。

人类工程师还在场，但角色可能缩水：转述需求、搬运结论、点击合并。听起来还在控制，实际只是在循环旁边签字。

软件过去也复杂。大型分布式系统从来不可能被一个人完整装进脑子。但工程文化至少承认一件事：关键不变量在哪里，承重墙在哪里，哪些改动不能碰，团队里必须有人知道。

harness loop 容易把这件事往后推。系统像病人一样被诊断、治疗、监控、稳定，却未必被理解。

这让我想起工业化早期的流水线。它让产量上去，也把工人的完整手艺拆成动作。类比不完全一样，写代码不是拧螺丝。但重复的是那种权力结构：流程越强，个人越容易只负责局部动作。

“天下熙熙，皆为利来。”这里的利不是抽象商业利益，而是速度。小团队想跑得像大团队，安全研究者和攻击者想 24 小时扫项目，维护者想从报告洪水里活下来。循环会被采用，不是因为它完美，而是因为大家都缺时间。

Pi 的谨慎反而重要。原文提到 Pi 时，态度不是担心它失控，而是认可它的克制。未来真正该做的，不是让一群机器随便乱改代码，而是把 task queue、agent orchestration、subagent、durable session 放进可控实验场。

更好的可视化还不够。团队需要知道 loop 做了什么，为什么继续，为什么停止，哪里改动了系统不变量，人半年后还能不能看懂。

接下来不用盯模型榜单。更该盯三个现实变量：

  • 结束信号.工具是否允许人类定义硬门槛，而不是只看模型自评。
  • 维护记录.每次循环是否留下可读、可回放、可追责的轨迹。
  • 断供能力.没有某个模型、某个 API、某个成本条件时，团队能否接管代码库。

工具如果只提高吞吐，不保存理解，就会制造新的技术债。债主不再只是某个框架或某个依赖，而是模型供应、API 成本，以及团队退化的理解力。

所以这轮 AI 编程的核心问题，不是机器能不能写代码。它已经能写很多代码。问题是：当代码越来越依赖机器循环来生成、审查和维护时，人类还剩多少真正的控制。

模型看着更强，产品可能更快，工程组织却可能更虚。循环不是洪水猛兽，但它要求一个很硬的前提：人不能只负责传话。