改结果的人永远赶不上改系统的人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 loopagent 产出 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 的结果不满意时先别急着改结果。问自己一句这个问题是结果的问题还是系统的问题 你目前是 in the loop、on the loop 还是 out of the loop有没有「改结果改到怀疑人生」的经历评论区聊聊。 更多实战记录见我的博客鱼日先生本文基于真实工程实践记录撰写69 个 Dify 实验、36 次约束文件受控实验Dify 1.16.x Hermes v0.20.0 环境。观点与数据均来自我们自己的实测不构成任何平台的官方结论。AI 参与创作声明本文由 AI 辅助写作内容基于作者真实实测记录。