我经营着一家叫作 HumanLayer 的公司，致力于研发人类与智能体协作的工具。因此，我下面要说的内容可能会带点主观色彩。不过，即便如此，我还是希望你能觉得这个话题对你有所帮助，或者至少和我一样对它感兴趣。
我猜我们都在循环工程的路上了
我们都在争先恐后地将 AI 编码投入生产。关于循环工程（Loop Engineering），人们已讨论了很多，目前普遍的看法是：我们或许应该多构建一些循环流程。
StrongDM 曾撰文介绍他们的“黑灯”软件工厂：在那里，没有人阅读代码，也没有人编写代码。
大致的说法是这样的：
你就是瓶颈。
模型已经足够好。
代码是免费的。
抓紧交付就好。
OpenAI 的 Ryan Lopopolo 曾在 2 月份撰文探讨了这一话题，并于 4 月份就 OpenAI 的软件工厂项目 Symphony 发表了演讲。
这些人个个都聪明绝顶，我由衷地敬佩他们。但若从最刻薄的角度解读，这不过又是一种说辞，好让风险投资家们往这个烂摊子里再砸钱。
它正在……
我们的朋友 Mario 在 AI 工程师欧洲大会上登台呼吁大家放缓脚步——因为那些本不该因编码智能体失误而出现故障的公司，偏偏因为编码智能体的失误遭遇故障。
正如 Matt Pocock 所言，代码库崩坏的速度达到了前所未有的水平。
我没能找到 StrongDM 针对这套黑灯工厂项目进展发布任何确切的数据与结论。他们的项目气象报告从今年 2 月份到 6 月份仅有零星更新。不过，7 月 23 日团队在 Hacker News 参与了讨论，听上去我们很快有望看到一份更为正式的进展通报！
Faros AI 团队发布了一份报告：自今年一二月份大家陆续用上各类 AI 编码工具以来，PR 的评审质量大幅下滑。
评审留言变多、篇幅变长，还有大量 PR 在没有评审的情况下就被合并。
线上故障数量大幅上升。
每位开发人员的缺陷数量也显著增加。
这份报告更像是一种相关性信号，而不是确凿的铁证。这篇文章的核心目的在于提醒大家警惕垃圾数据，不过结合我自身观察来看，报告反映的趋势还是可靠的。
“是你使用方式不对”（事实并非如此）
很多人会跟你说，问题出在使用者技能不足——如果你没能获得理想的效果，那是你自己的问题。
但无论你选择怎样去用它，我敢肯定一定会有人对你说：如果极致消耗词元这条路行不通，那就是你的技能问题。你只需要消耗更多词元，不要再纠结于读懂代码了。而且，如果你刚开始走到这个阶段，我可以保证，这正是成长过程的一部分。去年夏天，我也曾这样想过。
遗憾的是，因为我的虚荣心，我之前随口说了些关于“如何更好地驾驭它”的傻话，结果居然被录了下来，如今在 YouTube 上的累计观看量已接近百万。我并非想炫耀，只是想借此说明，我早已深入研究如何最有效地利用编码智能体，并且发现了一些对许多人来说确实很有用的见解。
网上铺天盖地、让人不胜其烦的这套论调——“使劲堆词元就行了”，它的核心逻辑就是：只要做好充分的 harness 工程设计，我们便能鱼与熊掌兼得：
10 到 100 倍效率提升；
高质量；
再也不用做所有人都头疼的代码评审。
我们所要做的，无非是配置更多代码检查工具，再给足够多的 PR 评审机器人加上一些“对抗性评审”之类的神奇词汇，然后软件就能顺顺利利自动构建，不会出错。
这不是技能问题
我要努力说服你的是，无论怎样优化硬件设计或提升循环峰值性能，都无法从根本上解决一个本质上属于模型训练的问题。
为把这件事讲清楚，我深入研究了代码模型实际的训练与评估机制，包括可验证奖励强化学习（RLVR）及基准评测方面的内容。
在这篇文章中，我会依次讲解：
软件工厂的历史可追溯到 1968 年，它们经历了怎样的演变？AI 又是如何改变了它们？
为什么模型即使在各项基准测试中表现优异（甚至包括全新的“前沿”基准测试），仍能生成大量垃圾内容？
尽管存在上述问题，我们依旧可以高效推进开发，同时不至于把代码库搞得一团糟。
我打算抛开每天层出不穷的 Skill 插件以及 AI 狂热与过度追求极致性能的炒作建议，以更宏观的视角来谈谈那些真正有效的方法，不会提及任何特定的 Skill 或框架。
软件工厂简史
我的整个职业生涯都在构建和研究软件工厂，但直到最近才了解到：这一术语最早可追溯到 1968 年的一次北约会议——正是那次大会提出了“软件工程”这一概念。
自那以后，我唯一觉得特别有趣的一点是，美国国防部写了一篇长达 31 页的 PDF 文件，内容大致是关于国防部需要更好地使用 Jenkins 之类的事项。
2022 年的软件工厂
让我们以 2022 年——即 AI 出现之前——为基准来界定我们的“软件工厂”概念。在典型的软件工厂里：
人们决定要构建什么——工程师、项目经理和引领愿景的领导层共同推动。
它会进入一个跟踪器——Linear、Jira 或者其他的什么东西：一个描述所需完成事项的状态机。
有人领取工单，然后开始构建——很可能在构建过程中还会做一些手动或自动测试。
拉取请求——自动检查，由人工审查代码，或许还有人将代码拉下来做测试。
发现问题？回到开发环节。
发布到生产环境——正式面向用户。
添加监控——整个行业都围绕着在凌晨 3 点某个地方出问题时给工程师发寻呼而建立起来的。
用户反馈——提出需求、发现漏洞、提交功能请求，流转回团队，录入任务追踪系统。
如此循环往复。我们甚至还没触及 AI，这张图里就已经出现了好几个循环了。
对齐前置
数十年前的团队就已明白：开发需要数小时或数天，代码评审也是如此。
因此，团队会把工作前置——包括规划、架构方案和冲刺迭代计划。这意味着：
更少的返工，因为我们是在写代码之前就已达成一致。
减少逐行评审的时间。
我们稍后再回过头来讨论这个——现在我们来看看引入编码智能体时会发生什么。
智能体软件工厂
现如今几乎所有公司都在跟风
Ramp
Stripe
WorkOS
Brex
今年的大部分时间，他们都在宣扬自己如何打造了一个智能体工厂，产出的代码占比高达 75%。
智能体工厂看起来基本上就是将“人工开发某个功能”替换为“智能体开发某个功能”——这里面涉及一些内容，比如编排、工具箱、沙盒、模型、计算机使用等等。我就不深入探讨这些细节了，因为说实话，这类内容我已经看得审美疲劳，而且我敢肯定，你们也一样。
当由智能体开发功能时：
开发耗时从数小时乃至数天缩短至几分钟或几小时。
但代码评审依旧要耗费数小时、甚至数日。仍然需要人工通读代码、验证改动。于是，评审环节成了新的瓶颈。
于是你也加快评审速度：
用智能体评审代码，检查代码规范、发现缺陷与安全漏洞。
用智能体进行回归测试，通过浏览器、计算机操作能力对系统进行探测；完成后说不定还会给你发一段可爱的小视频。
现在评审速度更快了，但可能仍然存在瓶颈。不过，我们可以增加更多循环。
接下来，你可能还会将线上故障直接转接到工厂。这样一来，他们不必在凌晨 3 点被叫醒去处理，而是在一觉醒来时看到一个已经完成修复的 PR。
我们还可以将用户反馈直接接入到工厂。用户提出需求，产品就会被制造出来。
此时，这里只剩下两个问题：你能往任务队列里塞多少需求，以及你能以多快的速度完成评审和测试？
这就引出了黑灯软件工厂。
黑灯软件工厂
Dan Shapiro 发明了这个术语，而 Simon Willison 则撰文介绍了 StrongDM 的落地实现——在这个实现中，人类不再阅读代码了。
你看着自己精心搭建的软件工厂，却被那个烦人的代码评审环节给毁了。于是你心想：那个由人来逐行审阅每处改动的流程？算了吧，我才不要呢。
于是你舍弃人工代码评审，把精力放到其他地方：
测试，让智能体自行验证自己的产出；
沙箱和编排；
自动化代码评审；
监控；
发布；
收集用户反馈。
至此，问题就只剩一个：我们能让智能体开发多少东西？我们打算多大程度上“竭泽而渔”？
看起来很棒（事实并不会）
我要提出一个可能颇具争议的观点：黑灯软件工厂行不通。
让我们来探讨一下黑灯软件工厂为何会失败。
我们尝试过了
2025 年 7 月，我们全面进入黑灯工厂模式：智能体只需要阅读需求规范和工单，中小型开发任务全部交由后台智能体处理，整个流程就搞定啦。
如果你认真尝试几个月，就知道结局会怎样。你一定会碰到至少一个极度棘手的难题，即使你使用了最前沿的提示词和工作流，智能体依旧束手无策。
你进行深度的上下文感知排查，将所有相关的要素整合起来供模型分析。
你让智能体尝试以 10 种不同的方式重现。
最终，你不得不硬着头皮去翻阅那个三个月前就不再看的代码库，试图弄清楚哪里出了问题。
与此同时：
你的网站瘫痪了。
你的用户生气了。
而你呢，如果你和我一样，一定会痛苦不堪——读着那些你不小心引入系统的垃圾代码。
第一次遇到这种情况时，我毫不在意地把它抛诸脑后。尽管我花了近两周时间梳理那些乱七八糟的代码，但依然觉得“潜在风险换来开发速度是值得的”。到了 11 月，这类问题第三次出现，我们干脆决定从头开始重写，我的联合创始人甚至整整花了两周时间使用 VS Code（连 Cursor 都没用）纯靠手写把所有模式都梳理了一遍。
随着时间推移，大模型会拉低代码库质量
我想强调的是：模型存在一个缺陷——它们无法长期持续提升代码库的质量，除非有相当程度的人工干预。
我所说的可维护性，指的是这样一种情况：想要修改代码库中的某一处代码，极大概率会引发其他地方报错。这正是 Martin Fowler 所说的“霰弹式手术”。
我就不多谈可维护性了。关于这方面的书有很多，可以去读一读。
John Ousterhout 的《软件设计哲学》
Robert C. Martin 的《代码整洁之道》
Martin Fowler 的《重构》
那么，为什么大模型无法实现软件可维护性呢？
但毫无疑问，大模型变得越来越好了
此时，你可能迫不及待地想说：自 7 月份以来，这些模型可已经进步不少了！
在某些方面，他们是的。而在某些方面，它们在原地踏步。
解决一次性问题或快速搭建新的网站？这方面确实好很多了。
但要说长期持续提升代码库质量？依我看，并没有好多少。
这一点我无法证实，你同样也无法证实。目前尚无可靠的基准测试可用来衡量大模型保持代码库质量的能力。
但如果你已经使用编码智能体一段时间——而且很多人都在讨论这个问题——你可能早已有所察觉：随着时间推移，它们往往会让情况变得更糟，使代码库更难维护。
为了弄清楚为什么会发生这种情况，我想将视角拉回到第一个伟大的编码助手。
Claude Code 之所以获胜，是因为它采用了强化学习
Claude Code 在不到一年时间里，营收从零一路攀升至约 40 亿美元，如今年化营收大约达到 90 亿美元。
这有点儿令人匪夷所思，因为此前已经有不少优秀的命令行工具智能体了——Aider、Cline、Codebuff——它们全都早于 Claude Code 问世，而且都内置了出色的上下文处理功能，而且具备大家以为是 Claude Code 首创的全套工具能力：读、写、编辑、文本检索、命令行终端。我都用过，确实不错。但与此同时，这些工具有时会彻底失效——你会眼睁睁看着它对着同一段编辑内容折腾三次，最后只好自己打开编辑器重新动手编辑。
2024 年的 SWE-Agent 论文指出工具形态的细微变化会如何带来显著差异，例如在 ReadFile 返回的结果中加入行号，或将 Edit 工具从查找/替换改为按行范围编辑。
随后，Claude Code 一经推出业务规模便迅速一路走高。你可以简单将其归因于渠道推广优势，但业界公认的解释是：Claude Code 之所以胜出，是因为它更优秀，而它之所以更优秀，是因为 Anthropic 在训练模型时采用了强化学习技术——这是首次有研究机构针对未来实际部署的工具来训练模型。因此，Claude Code 在以智能体方式调用这些工具时表现得极为出色。
不断调整工具定义、反复调试评测方案，直到摸索出模型最适配的交互形式，这是一回事——我为此耗费了好几周时间，针对各种不同的应用场景。但当你掌握了权重，并能直接修改模型本身，让它在特定工具组合上表现得更好时，这就完全是另一番境界了。
OpenAI 的团队在 11 月份的一次演讲中对此做了很好的阐述：如果你只打造了一个支架，不拥有权重，也无法对支架内的模型进行强化学习，那么你始终会处于劣势，而那些同时拥有两者的团队则占据明显优势。
60 秒完成编码智能体强化学习
我围绕这个话题做了一大堆研究，并制作了不少可视化图表，试图解释其中的关键点。不过，我发现 Calvin French-Owen（曾在 Codex 团队，也是 Segment 的创始人）在 AI Council 上做的一场演讲讲得更好、更简洁明了。因此，我索性直接把受他幻灯片启发而制作的这段动画放在这里：
为了让大模型写出更好的代码，你需要：
生成编码智能体执行轨迹来解决问题（例如，修复测试）；
根据某些标准对轨迹进行评分（验证器）；
更新模型权重，让优质执行轨迹出现的概率变高，劣质轨迹出现的概率变低。
然后，你在数周或数月的时间里重复这个过程数百万次。
不过，这个流程里的“评分”环节往往会有些随意且维度单一。
糟糕的设计不会受到惩罚
以 SWE-bench 多语言版为例。这些任务规模较小——每项大约只需要十五分钟时间就可完成——均取自 Redis、jq 和 Django 等开源代码库。奖励结果为 1 或 0，具体取决于：
FAIL_TO_PASS——是否修复了被要求修复的问题？PASS_TO_PASS——有没有破坏了其他功能？
这里有一个真实的例子，fastlane__fastlane-19304，来自 fastlane —— 一个 Ruby 项目。它的 zip 操作会接受两个可选参数，并立即对它们调用 .empty? 方法，如果你不传 include 和 exclude 参数，它会直接报错：
'zip_command': undefined method 'empty?' for nil:NilClass
人类开发者解决这个问题只需要修改两行代码：
在评估过程中，大模型
以一个基础提交作为起点——也就是代码仓库切换到修复合入之前的那个提交节点
错误报告——在本例中为
'zip_command': undefined method 'empty?' for nil:NilClass
智能体根据这条工单信息独立编写代码。它看不到标准答案补丁或测试补丁：
然后：
我们保留它生成的补丁
丢弃它对测试文件所做的修改（我们发现模型会悄悄地注释掉失败的测试，或插入一个使测试失去意义的模拟对象）
在代码之上应用基准的测试补丁
运行整个测试套件：包括现有的 zip 测试（
PASS_TO_PASS）以及新增的测试（FAIL_TO_PASS），检验它们是否都能通过。
模型如何得出正确答案并不重要。只要测试通过，我们就赢了。而导致代码库可维护性降低，我们无需受到任何惩罚。
这就是为什么模型会到处滥用 try-catch 包裹代码：
以及那些偷懒的类型转换，它们从根本上消解了类型系统原本所能带来的价值。
验证代码质量的难度比“测试是否通过”高出几个数量级
运行测试可在短短几秒内给出通过或失败结果。正因如此，强化学习才能运行数百万次迭代，优化模型的每一次生成。
但糟糕的架构让我们付出的代价可能以周、月甚至年为单位来衡量。这种情况往往在第一次有人打开那个文件，仅仅为了做一行小小的改动时就出现了——他们这才意识到，根本无法通过修改一行代码搞定。之前开发的人图省事、凑出了能跑通的方案，如今我们不得不在十一个地方做出同样的修改，还得祈祷改动不会悄无声息地造成另外三个文件出问题。
糟糕的设计正是当今基准测试无法评估的一环。强化学习并不等同于基准测试，但如果这个问题能在强化学习中得到解决，我敢肯定，它迟早也会反映在我们基准测试的设计方式上。
无论如何，我并不认为模型在现有评测基准上取得的任何性能提升能够证明它们突然学会了不再胡乱糟蹋你的代码库。
前沿模型的能力正在缓慢进步
当然，许多聪明人都在为此努力。我的观点并不是说这件事做不成，而是说炒作的热度已经超过了应有的严谨性。
我认为一些努力方向是正确的：
SWE-Marathon（Abundant AI）：约 400 小时的任务，例如“克隆 Excel 的所有功能”——采用复合奖励机制，而非单一的通过/失败一元判定。
DeepSWE（Datacurve）：OSS 代码库中那些从未在现实世界中真正被实现的大型任务，因此从本质上讲，它们不可能存在于训练集中（可解决污染问题，但无法保证质量）。
Frontier Code（Cognition）：多项 PR 任务，以及一项巧妙的设计——以确定性方式评估质量：如果模型编写的测试在预补丁代码上未能通过，便会受到惩罚。此外，它还会用评判模型来检查差异内容。
但依靠模型来评判代码质量，终究存在局限。
事实上，不难想象，如果一个模型能够可靠地分辨出好代码与坏代码，它或许从一开始就写出了更好的版本。强化学习需要一个快速且可靠的“预言者”，而我们目前尚不具备这样一个用于衡量可维护性的“预言者”。
当然，使用更多的评审智能体和更多的词元确实能起到作用 —— 它们抬高了下限，能捕捉到那些低级的错误。
但它们无法突破上限，因为上限就是我们在强化学习中成功教会模型的东西；而所谓优秀的设计，恰恰是我们目前仍不知如何教会模型的那些东西。
所以，我仍然不会把代码库的质量押注在这些工具上。但它们是我见过的首批尝试评估可维护性而不仅仅是停留在判定通过或失败层面的工具。
重新把灯打开
现在，你是评判者——所以我们把代码评审重新放回原位：
我们将沿用自 AI 出现之前就一直采用的做法——事先做一点规划，降低经历漫长而艰难审查的可能性。
我们将找到突破口，并借助 AI 在四个阶段中进行助力：
产品需求
系统架构
程序设计
垂直切片
产品评审
一切从产品评审开始：这是一份简短的文档，精准地阐明了我们正在构建什么以及为何要这么做。我们的目标是能够将两句话或一段冗长的语音笔记整理成某种半结构化的内容。
首先，我们要明确需要解决的问题——即用户真正面临的痛点，并用用户的语言来表述。其次，明确成功的标准——我们可以在产品上线后通过哪些指标来判断这项功能确实值得开发。理想情况下，这些成功指标应该是用户层面的成果，比如“能以更短的时间完成 XYZ 工作流程”或“提前达成 ABC 上手目标”。有时，这些指标可能更偏向底层，比如错误率或延迟数值；有时则简单地表现为“与 X 相关的客服工单数量减少”。
我们尽量将讨论重点放在产品领域，而非技术层面。作为一位一脚踏在产品世界、另一脚踏在技术领域的从业者，我常常发现自己会不自觉地陷入技术细节的讨论中。每当这时，我都会先随手记下这些内容，留在后续阶段深入探讨，然后尽快回到用户体验这一核心问题上来。如果技术决策阻碍了产品决策，我们就先确定现有方案，着手进行架构设计，或者进行更多的原型研究，探索可行的解决方案。
由于大部分都是关于用户可见的内容，我并不会用文字去描述——而是直接进行原型设计。一份简单的 HTML 原型就能一锤定音，若是用三段文字阐述，只会让分歧持续拉锯。
这里有一个正在推进的真实案例——用 JSON 大纲明确了功能，随后提供了两个粗略的 HTML 界面原型。
当然，并非所有东西都会评审。对于文案微调、一次性脚本或是明显可复现的错误——我们依然直接一次性交给智能体处理。这尤其适用于那些一旦智能体误解了我们的意图就会带来高昂代价的改动。
对于所有相关文档，我们采用作者主动参与的评审方式。如果你希望在评审过程中节省时间，可以选定一位负责评审该 PR 的人员，并与他/她一起快速过一遍产品和技术规范——这既可以采用异步方式，通过文档评论进行（我们自己就用 HumanLayer 来实现这一流程，不过你也可以在 GitHub、Notion、Plannotator 等工具中完成）。
系统架构
产品评审一旦敲定，我们便开始进行系统架构设计。这其实并不算什么新鲜事，甚至依靠 AI 即兴编码的开发者也开始推崇这一做法了。
在这一阶段，我们确定服务、端点、模式、队列和存储之间如何相互通信，无需深入探讨程序设计的细节。为了最大限度地提升人与智能体之间的沟通带宽，我们在这个阶段大量使用可视化手段——例如序列图：
契约/端点：
PUT /api/resources/:slug
request: { destination: string }
response: { resource: Resource }
数据模型与转换：
-- new tables
CREATE TABLE resource (
slug TEXT PRIMARY KEY,
destination TEXT NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
-- new query shapes
-- SELECT ... FROM ...
使用 Mermaid 绘图固然可行，但有时可能用力过猛，还容易让人产生一种“各方已对齐”的错觉。架构具有相当高的杠杆效应，这一阶段可以有效避免许多潜在的不良建模习惯。然而，仅靠架构还无法产出高质量的代码；为此，我们还需要进行程序设计。
程序设计
在架构完成之后，我们需要做一件我认为在智能体编程中被严重低估的事情：程序设计。
大多数人以为，只要架构设计得当，大模型就能自动搞定一切。你确实可以这么做，但可能并不会喜欢最终的结果。
但从实践来看，行之有效的做法是：在开始编写实现代码（无论是人类还是智能体）之前先从架构层面深入到代码的具体形态：包括类型、方法签名、程序布局以及调用栈。
我们程序设计的第一版简直烂透了。代码难懂，让人精疲力尽。我们试过 Mermaid，它确实有其用武之地，但其实我们更喜欢用伪代码进行轻量级的可视化呈现：
涉及流程编排或控制逻辑变更时，我们就采用调用栈树。如果重点在于对比改动内容，请使用差异语法：
Dillon Mulroy 提到他将调用图作为规划流程的一部分，我认为这完全正确。
文件树差异——让你随时掌握代码库的布局以及各种内容所处的位置。
关键功能的类型和方法签名——这些内容过于细节，不适合写在架构文档中，但智能体依然很容易在这里出错。
interface Item {
id: ItemId
parentId: ItemId | null
// ...
}
interface Cursor {
position: ItemId
direction: 'up' | 'down'
// ...
}
resolveTarget(items: Item[], cursor: Cursor) -> ItemId | null
这些都不需要花费很长时间来完成（由大模型起草，你再与之讨论），而且每项决定都相当于你在代码审查过程中原本会不自觉做出的决定——而此时此刻正是你最难以改变主意、成本最高的时候。
垂直切片
接下来，我们喜欢做一种我称之为“垂直切片”的事情——2026 年 1 月，Matt Pocock 和我在一场直播中聊过垂直切片或“追踪弹”——这也被称为追踪弹。
大模型往往倾向于采用我所说的横向规划（Horizontal Plan）——也就是按照技术栈分层顺序依次构建：
数据库迁移
服务层
API
前端
实际上，这意味着在开发过程中根本无法真正“触碰”解决方案。你可以用代码测试一些东西，但就我开发过的几乎所有功能而言，仅阅读测试用例还只是个开始；在开发过程中，总要时不时地在浏览器中打开看看，或者用 curl 直接调用一下才行。
在 AI 普及之前，很少有人能在编写代码时做到不中途检查就写出 2000 多行甚至哪怕 500 多行代码。
我花了一段时间才注意到与我以往习惯的不同——以前在没有 AI 辅助的情况下写代码，我总是从中间开始，然后向外扩展。大致是这样：
创建 API 契约并提供模拟数据，使用 curl 进行测试。
创建前端来消费模拟数据，在浏览器中迭代并优化。
将 API 连接到服务层（服务提供模拟数据/行为）。
添加数据库迁移，将服务连接到数据库。
添加大量业务逻辑。
添加大量错误处理。
而且我会在每个步骤中进行测试、迭代和打磨。
如果我对这段代码质量要求很高，或者怀疑模型难以在代码库的这一模块写出可靠代码，我也会在每个步骤都仔细审查代码。每次检查 100 到 200 行代码，并进行调整，这样做成本要低得多。
大多数前沿模型在没有人类引导的情况下都不会设计出这样的方案。而且，这种方案很难直接套用到所有代码库，甚至不能直接照搬到每一项开发任务上，所以我更倾向于全程参与其中。相信我，如果能将这部分思考外包出去，我早就这么做了。
30 分钟规划可节省数小时评审时间
因此，我认为如果想在不耗费大量精力去清理堆积如山的烂代码的情况下，仍能保持接近人类水平的质量，那么有些步骤是必须由人类参与把控的。
产品设计
系统架构
程序设计
垂直切片
显然，我们并不会对所有上线功能都完整执行这个流程（参见下文的二八法则）。我大致预估工作量分布情况如下：
约 40% 的任务采用一次性生成，或在经过 1 到 2 轮轻度反馈后一次性完成。
对于中等规模的任务，我们会在一份计划文档中完成产品和系统设计，无需费心将工作拆分成多个阶段。
对于大型项目，我们会完成所有步骤。对于大型重构这类不适合做产品设计的工作，我们会跳过产品设计环节。
而且，在大多数情况下，我会让模型一次完成 1 至 3 个垂直切片，边做边检查代码。尽早进行调整要容易得多——无论是调整内部实现还是实际功能——总比到了 2000 多行代码之后却完全摸不着头脑、不知哪里出了问题要好得多。
你可能会觉得这样创建了太多 PR
你的 PR 并不多，是不好的 PR 太多了。
早在 AI 普及之前，我们就已经评审过大量需要返工的 PR。
但一个高质量的 PR 评审起来会让人十分舒心。你翻阅着每一个文件，代码整洁规范，完全遵循了你在软件开发过程中所做出的所有决策、讨论以及来之不易的观点。
反之，如果一个 PR 需要 20% 的返工（这已经算是很宽松的估计了，我认为大多数 AI 一次性生成的 PR 实际返工比例更接近 50%），这对提交者和评审者来说都既是智力上的负担，也是情感上的负担。（即便提交者是 AI，也多半是因为有人启动了这项任务，或是对 AI 的生成结果进行了润色打磨。）
约束理论（2026 年版）
看完本文的核心观点，人们难免会感到些许沮丧：“目前，我们还是不得不亲自阅读代码”。
我也曾对这样的一种世界充满期待：我们只需提出需求，让大模型自动完成开发，无需阅读代码就能获得高质量且不断进化的生产级软件，再也不用担心它会变得一团糟。
但我在此竭力阐述的不过是一系列客观存在的现实约束。大模型在某些方面表现优异，而在另一些方面则不尽如人意。面对这些约束，你该如何优化你的流程呢？
你可能正一心追求追求 10 到 100 倍的开发提速，还试图说服自己代码质量已无关紧要。但其实如果你能接纳这些客观约束，反而能更安全地实现 2 到 3 倍的提速。
我这里想给出的总结性建议基本上是：
充分了解约束条件，在与模型大量协作的过程中积累经验直觉
在这些约束条件下优化系统
寻找效率杠杆
务必审阅代码
正文到此结束。希望这能帮你避免灾难，或者至少让你在观看这些可爱的动画时感到愉快。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
原文链接：https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md
