为什么有了AI你反而更累了？因为你在错误的层级上作战
基于 2026 年 AI Agent 落地现状撰写。我们团队的实践记录：69 个 Dify 实验、87 个 DSL 工作流、36 次约束文件受控实验（Dify 1.16.x + Hermes v0.20.0 环境）。
📖 摘要：人在 AI 编程中的位置分三层：in the loop（逐行审查、手动修改）、on the loop（不碰代码、构建和改进 harness）、out of the loop（只说想要什么、agent 自己搞定）。区别在对结果不满意时最明显：in the loop 的人去改结果，on the loop 的人去改产生结果的系统。AI 应用交付的重心，正在从「把功能做出来」迁移到「把环境设计好」——这是我们认为后续 AI 应用发展的关键。本文的「AI 编程」泛指用 AI 做开发：既包括让 agent 写代码，也包括搭应用（工作流编排、知识库、Agent 定制）。
📌 这篇文章要解决的三个痛点：
- 以为 AI 编程 = 逐行审查 agent 写的代码——你在跟它抢键盘；
- 对结果不满意就改 prompt、改代码——你在治标，下次还会犯；
- 团队还在用「改结果」的姿势做交付——成本随 agent 能力增长而爆炸。
结论
AI 编程里，人的价值不在「改结果」，在「改产生结果的系统」。 这句话不是口号，是一条可以执行的判断标准。它由三层递进构成：
- in the loop：逐行审查、手动修改。人离代码最近，离系统最远。
- on the loop：不碰代码，构建和改进 harness——约束、工具、反馈、验证。
- out of the loop：只说想要什么，agent 自己搞定。
这三层的区别，在你对结果不满意的那一刻最明显：in the loop 的人去改结果；on the loop 的人去改产生结果的系统，让它下次产出更好的结果。
这篇文章反对的，是「in the loop 万能论」——把 AI 编程窄化成逐行审查 agent 的代码，用改结果的方式弥补系统的缺陷。它不反对 in the loop 本身：那是学习必经的阶段，也是 on the loop 的前提。区别只在于：你是在改结果，还是在改产生结果的系统。
场景：跟 agent 抢键盘的人
我见过太多团队用 AI 编程，姿势出奇一致：让 agent 写一段代码，然后人趴在旁边逐行审查，看到不对就手动改，改完让 agent 再跑，跑了不对再改。一天下来，人比 agent 还累。
这不是 AI 编程，这是给 agent 当校对。你花 80% 的精力在检查 agent 的输出上——而 agent 的输出，恰恰是你最不该花精力盯的东西。
更荒诞的是：agent 的能力越强，这种姿势越亏。模型升级了，代码产出变多了，你审查的工作量跟着翻倍。别人在用 10 分钟搭一个交付，你在花 10 小时审 10 段代码。你在用人力给 AI 打工。
推导链：为什么「改结果」会越来越贵
「改结果」的姿势成立，有一个前提：agent 产出少、错误少，人力审查还罩得住。
这个前提正在消失。agent 的能力指数级增长，单次产出的代码量、覆盖面、复杂度都在涨——人力审查的速度是线性的。线性的人力，去追指数的产出，差距只会越来越大。
而「改系统」的姿势不一样。你构建一个 harness：约束文件告诉 agent 什么能做、什么不能做；工具链让它能自己验证；反馈机制让它犯错后自己纠正。系统每改进一次，之后所有的产出都跟着变好——成本是线性的，收益是复利的。
这就是结构性的原因：改结果是消耗型动作，改系统是投资型动作。 前者每次消耗人力，后者一次投入、持续受益。
正例：我们怎么从 in the loop 迁到 on the loop
说一个我们自己的例子，不是展示，是给「on the loop」一个具体形态。
我们做 AI 应用交付——工作流编排、知识库（RAG）、Agent 定制。早期我们也是 in the loop：agent 产出 DSL，我们逐行核对，改完导入平台，跑挂了再改。一个应用交付下来，人力大头全在「修结果」上。
后来我们做了一次受控实验：36 次会话，3 种写法对比，测试约束文件（AGENTS.md）怎么写才有效。结果：无约束时达标率 88.2%，精简铁律反而触发过度验证、成本飙到 2.28 倍，结构化写法 100% 达标、成本只有 1.44 倍。从那以后，我们交付前先设计约束，而不是交付后改结果。
这套迁移在三个地方落地：
- 约束即 harness：交付项目先写 AGENTS.md——分节、要求与禁止成对、800-1500 字。agent 犯过的错，固化成行为边界。
- 管线即 harness：知识库建库前先清洗，清洗后过质量门禁——四项 25 分制评分、四层验证、污染注入回归。数据脏不脏，门禁说了算，不靠人肉抽查。
- 验证即 harness：交付后跑独立验收，用用例集逐字执行。合格不合格，用例说了算，不靠「我觉得行」。
这三件事的共同点：我们不再修改每一个产出，我们设计让产出变好的系统。 这就是 on the loop。
反例：in the loop 的三种死法
给 agent 当校对。 逐行审查 agent 的代码，把「AI 编程」做成了「AI 写作、人审稿」。agent 越强，你越忙。你不是在驾驭 AI，是在给它打下手。
改 prompt 治标。 对结果不满意，第一反应是改 prompt、改参数。改完这次好了，下次换个输入又崩——因为你在改结果，不是改产生结果的系统。真正的问题（缺少约束、缺少验证、缺少反馈）一次都没解决。
人肉兜底。 agent 犯错，人手动修。修完就完了，错误没有沉淀成约束。于是同样的错反复犯——每次都是新的，因为系统从没变过。
这三种死法的共同点：人在用线性的人力，对抗系统的结构性缺陷。 你赢不了，因为你在错误的层级上作战。
实践动作：怎么从 in the loop 迁到 on the loop
批评完了，给能用的。
第一步：给 agent 写约束，而不是给 agent 改输出。 交付项目先写 AGENTS.md——分节、要求与禁止成对、800-1500 字。每次 agent 犯错，问一句：这个错，值得写进约束文件吗？
第二步：把验证交给系统，而不是交给肉眼。 代码写完让 agent 自己跑测试；数据清洗完过质量门禁；交付完跑独立验收。凡是能用脚本判定的，就不要用人眼判定。
第三步：错误要沉淀，不要擦掉。 agent 犯错，别急着改完走人。把错误固化成约束、检查、回归用例——让系统下次产出更好的结果。错误是系统的输入，不是人的任务。
第四步：接受 out of the loop 是目标，不是起点。 从 in the loop 学系统，到 on the loop 建系统，再到 out of the loop 用系统——这是能力递进，不是一步到位。别在没建好 harness 的时候，就指望 agent 全自动。
边界：in the loop 不是错，停留才是
有人会问：你反对 in the loop，难道新手不该逐行看代码吗？
该看。in the loop 是学习阶段，是理解系统的必经之路——你都不知道 agent 会怎么错，怎么设计约束？但学习阶段和交付姿势是两回事：学习时 in the loop 是为了看明白，交付时 in the loop 是为了补漏洞——前者是投资，后者是消耗。
还有人会问：out of the loop 是不是终极形态？
是目标，但不是免费的。out of the loop 的前提是 harness 足够强：约束覆盖了错误模式、验证能拦住坏产出、反馈能自我纠正。没有这个前提，out of the loop 就是放手不管，不是高级，是失控。
这篇文章反对的是「in the loop 万能论」——不是 in the loop 本身。改结果是改系统的入门课，改系统是改结果的毕业证。
收尾
回到开头那句话：AI 编程里，人的价值不在改结果，在改产生结果的系统。
AI 应用交付的重心，正在从「把功能做出来」迁移到「把环境设计好」。功能是给客户看的，环境是给 agent 活的——功能决定这一次交付好不好，环境决定以后每一次交付好不好。
这是我们做工程项目的观点，也是我们认为后续 AI 应用发展的关键：当模型的能力不再是瓶颈，瓶颈就在 harness——而 harness，是 on the loop 的人设计的。
所以下次你对 agent 的结果不满意时，先别急着改结果。问自己一句：这个问题，是结果的问题，还是系统的问题？
本文基于真实工程实践记录撰写（69 个 Dify 实验、36 次约束文件受控实验，Dify 1.16.x + Hermes v0.20.0 环境）。观点与数据均来自我们自己的实测，不构成任何平台的官方结论。
