★ FEATURED ARTICLE 1. 瓶颈期代码量不到两千行我却在这个小工具上卡了两周先讲一个让我印象很深的例子。某开发者的副业项目——一个帮小型工作室做客户进度跟踪的内部小工具——写到了第二周代码量还不到两千行功能上就是增删改查加几个统计页数据库三张表怎么看都不算复杂。但他卡在一个重复出现的怪圈里每次打开项目想加一个新功能需求本身并不难前后端逻辑也能理清楚可一旦动手改代码就会在改完A导致B报错修B又牵扯C的循环里转不出来。有时候一个下午看起来忙忙碌碌提交记录不少功能却几乎没有推进。我当时给他提了个建议别再把写代码当作唯一的工作方式了试试把任务交给AI去跑循环。这个建议后来衍生成了一套完整的开发流程也就是标题里说的Loop Engineering。它不是让AI替你做一个完整的项目——那种想法既危险也不现实——而是把开发过程拆成一个又一个明确的小循环提出任务、让AI执行、运行验证、根据反馈修正再进入下一轮。每一轮循环解决的问题都足够小判断标准足够清楚因此整个项目的推进过程变得可以观察、可以记录、也可以控制。这篇文章我会把这套流程从原理到落地完整地讲一遍包含我从这个项目里整理出来的完整调试记录、工具链配置方式、以及大量越用越顺手的细节经验。如果你正处于小项目迟迟推不动、改一处坏一处的阶段或者你只是想找一个让AI真正成为生产力的方法这篇内容值得你认真读一遍。为什么说Loop Engineering是个工程方法而不是什么提示词技巧关键在于可观测性。传统方式下你让AI写一段代码然后你肉眼审查合不合法全靠经验判断而Loop Engineering把让AI写代码变成了建立循环、观察反馈、持续修正的过程每一步都有输出有检查项目的进展是透明的。2. 把让AI写代码改造成一条可观测的工程流水线2.1 为什么大多数人和AI协作的方式效率很低我先给这个项目当时的协作方式画个像。很多人和AI协作是这样的打开对话框把自己目前的完整需求一股脑写进去——要包括什么模块、每个页面长什么样、用什么框架、数据库怎么设计——然后期待出来一个能跑的东西。结果通常有两种要么AI生成了一堆看起来专业但很难集成进现有项目的代码要么生成的东西跑起来全是报错然后你在这个报错上又绕了几十轮。问题出在哪出在对AI工作方式的理解上。现在的AI模型擅长的是理解指令并生成合理的文本输出它并不天然理解你项目的全部上下文也不理解运行时的各种隐式约定。你给它一个庞大的、包含几十个隐含条件的大任务它只能基于平均水平去猜测自然会有偏差。更关键的是很多人在第一轮结果不满意时不是去调整输入或者缩小任务范围而是直接跟AI争论不对你要再想想——这既没有给AI新的有效信息也消耗了自己的耐心。Loop Engineering的第一性原理就是把任务切碎。不是切小一点而是切到一次循环只解决一个可以被明确验证的问题。比如把表单数据正确保存到数据库是一个可以验证的问题——跑起来、填数据、看数据库表里多没多一行。而做一个完整的后台管理系统不是它太模糊了。2.2 Loop Engineering的标准循环长什么样我给这个项目定义的标准循环是四步下达任务、执行生成、验证结果、反馈修复。你可以把它想象成一个自动化测试的流程只不过被测试的对象是你和AI共同生成的代码。四步循环的具体内容是这样的下达任务用一句话描述本轮要完成的最小单元任务同时给出完成的定义。注意这里要求的是一句话不是一段话。多出来的上下文应该来自项目文件本身而不是重复描述。执行生成让AI针对这个任务生成代码或修改方案。如果是修改现有代码直接让AI基于项目实际文件内容做变更不要靠记忆复述。验证结果把生成结果跑起来。这一步是整个循环里最有价值也最容易被跳过的环节——很多人让AI写完代码看一眼输出没有明显问题就算过了这是不对的。验证必须是运行级的项目能不能启动接口能不能请求通数据在数据库里对不对页面交互有没有报错反馈修复如果验证不通过把真实的错误信息原封不动地贴给AI让它基于错误信息修复而不是任由它猜问题。如果验证通过本轮循环就关闭进入下一轮任务。这四步看着简单难的是执行纪律。我在用这套流程帮那个开发者处理项目时发现最容易出的问题就是人在第三步到第四步之间自己动手。看到AI生成了一段代码觉得逻辑有点绕就忍不住上手改。这一改循环就断了——因为后续的反馈信息不再来自运行结果而是来自你的主观判断AI也就失去了持续纠正的依据。2.3 这个项目里我用到的工具链清单这个项目是在Windows环境下开发的我给它配的工具链尽量保持轻量。不需要复杂的CI系统不需要Docker只需要几个基础工具就能把Loop Engineering完整跑起来。工具类型选择理由代码编辑器支持AI插件的主流编辑器方便把项目文件内容直接喂给AI工具而不是复制粘贴命令行终端系统自带终端足够跑脚本、看日志、执行数据库操作运行时环境项目本身的开发语言运行时用最朴素的启动方式验证避免环境复杂性干扰判断数据库客户端支持直接查看表结构的轻量工具快速确认数据是否正确写入这是验证环节的关键截图/录屏工具浏览器开发者工具自带页面问题通过截图反馈给AI直观且信息密度高这个组合的核心理念是不要引入任何需要额外学习成本的东西。Loop Engineering的注意力应该放在循环本身而不是放在工具上。工具越简单循环越不容易中断。顺便提一下另外一种我试过但最后放弃的方案——搞一套完整的自动化测试脚手架让每次代码变更自动触发测试并生成报告。技术上当然可行但对这种量级的项目来说搭建脚手架的成本比项目本身还高循环的反馈延迟也会变长。项目规模到一定程度后再考虑自动化不迟初期老老实实手动跑验证是性价比最高的。2.4 给AI设计可验证的任务指令这个环节很多人不重视但它是Loop Engineering能不能跑通的分水岭。同样让AI改一个功能优化一下用户列表页和在用户列表页的每条记录后增加一个编辑按钮点击后跳转到/editor?idxxx要求列表页保持现有样式不变是完全不同的两种指令。前者AI不知道完成标准后者每一步都可验证。我在这个项目里总结了一套任务指令公式操作对象 具体变更 完成后的可观察结果。操作对象是哪个文件、哪个组件、哪个接口具体变更是从什么变成什么可观察结果是你通过什么手段知道它完成了。套用这个公式几乎每一个任务都能被快速验证。另一个经验是首次让AI处理某个模块时先要求它只读懂不要改。也就是让AI输出它对这块代码的理解和你确认意图一致然后再下达修改指令。这一步会明显降低后续循环的返工率——AI理解对了项目约定代码生成质量会完全不同。3. 保姆级实操从环境准备到第一轮完整循环3.1 准备目录结构和初始代码Loop Engineering不适合从零开始什么代码都没有的项目。因为这个循环依赖运行反馈而一个空项目没有反馈可言。所以实践的起点是先把一个最简可运行的项目骨架搭出来。这个项目的骨架是这么准备的项目目录下放了一个后端入口文件、一个前端页面文件夹、一个数据库初始化脚本以及一个依赖清单文件。前端页面先用一个最简单的静态页顶上后端只实现一个健康检查接口数据库只建出最基本的几张表不写任何业务逻辑。这个骨架不需要AI参与纯手动十分钟搞定目的是让验证这一环节有东西可以验证。骨架搭好后把整个项目目录结构、核心依赖、启动方式说明这三样东西整理成一份简短的说明文件放在项目根目录。后面每次与AI协作时这个文件会作为上下文的一部分反复被引用。它能替AI省掉大量先猜项目结构的时间也保证AI生成的代码符合你的目录约定。3.2 第一轮循环让AI理解项目而不是让AI写功能轮到这个项目的主角登场了。启动第一轮循环时我没有急着让AI写功能而是下达了一个只读任务请AI阅读这份项目说明并输出它对这个项目技术栈、目录约定、运行方式的完整理解同时指出任何它觉得不合理的地方。这轮循环的验证标准非常明确AI输出的理解与我的设计意图是否一致。这一轮的价值很容易被低估但实际收益很大。AI说项目使用XX框架作为后端页面文件放在XX目录启动时需要先执行数据库初始化脚本并主动指出前端页面缺少错误处理逻辑接口请求失败时用户没有任何提示。这个发现是意外的但证明它确实读懂了项目。如果AI只是泛泛说这是一个典型的前后端分离项目然后开始写代码那我会直接终止这一轮——因为它的信息输入还不够支撑后续可靠的工作。读完确认后我给这个循环画上句号。整个过程不到五分钟但它为后续所有循环建立了公共上下文。3.3 第二轮循环一个真实功能的完整推进过程第二轮循环才开始进入业务功能。我选了一个足够小、又贯穿全链路的功能实现健康检查接口并让前端首页显示后端运行状态。任务指令是在后端添加/health接口返回JSON格式的{status: ok}在前端首页增加一个区域页面加载时调用该接口若请求失败显示红色提示文字成功则显示绿色状态文字。这个任务天然分成后端和前端两个验证点。先跑后端启动服务后用命令行工具请求/health接口确认返回了正确的JSON——这是第一个验证。然后跑前端打开页面观察状态文字的显示——这是第二个验证。两个验证都通过本轮循环才关闭。实际过程中发生过一次有意思的偏差AI在前端请求接口时写死了本机开发地址而不是用相对路径。这导致如果其他人把项目clone下来跑或者在局域网里访问接口必然请求失败。这是一个典型的看起来成功了但实际不可移植的问题。单靠运行验证发现不了它因为本机运行一切正常。怎么发现的我在检查AI生成的代码时注意到fetch里出现了完整地址然后要求AI改成从当前页面地址动态推导接口地址。这个例子说明一个很重要的经验循环验证不能只做能跑的验证必要的时候要做换环境还能不能跑的验证。前者的反馈来自运行本身后者的反馈来自代码审查。Loop Engineering并不排斥人工审查它排斥的是没有反馈依据地乱改代码。3.4 关于验证的几条硬性规则跑了几轮循环后我沉淀出几条必须遵守的验证规则。这些规则并不是理论推演而是踩过坑以后总结出来的。规则一改动必须可以单独启动验证严禁堆积多个未经验证的改动再一次性启动。很多开发者习惯让AI连续完成五六处修改然后一起启动看结果结果报错后根本分不清是哪个修改引起的。Loop Engineering要求一次循环只改一个点这看起来效率低实际上总效率高得多。规则二错误信息必须原样反馈禁止转述和概括。把终端里的完整堆栈贴给AI和分析师是两码事。AI对信息的利用能力远超你的想象但前提是你给它的是原始信息。转述会丢失关键行号和上下文让修复变成猜谜。规则三每次验证前记录上一次通过的状态。我习惯在项目里维护一个简单的验证日志文件记录最近的验证时间、验证动作、结果。一旦后续改动破坏了什么我可以快速回退到已知正常的状态而不是在错误状态下继续循环。这个习惯在循环次数多起来以后非常救命。这四条规则听起来都像是在说要细心但实际效果是把模糊的开发过程变成了真正意义上的工程循环。每一条规则都服务于同一个目标让每次循环的反馈信息尽可能干净、完整、可行动。4. 项目实战复盘从做一个副业工具到一个能演示的Demo4.1 把一个大目标拆成可循环的里程碑清单现在进入完整的项目实战复盘。前面提到这个副业工具是小型工作室的客户进度跟踪系统功能上包含客户信息管理、项目进度记录、简单的统计看板、登录验证。这个目标如果直接告诉AI让它全做大概率会在第50轮循环时仍然原地打转。我做的事情是先把大目标拆成里程碑再往里程碑里拆循环。里程碑的划分遵循一个原则每个里程碑结束时的项目状态都必须是可演示的。也就是说哪怕所有后续工作都停了当前这个版本仍然可以跑起来给人看也能自圆其说。第一里程碑是客户信息管理因为它是整个系统的根基第二里程碑是项目进度记录它依赖第一里程碑建立的数据关系第三里程碑是统计看板它依赖前面两个里程碑产生的数据第四里程碑是登录验证它横切所有功能。每个里程碑内部再拆分循环。比如第一里程碑内部拆成了这些循环循环1设计并创建客户表包含姓名、电话、所属工作室、创建时间等字段循环2实现客户列表页支持分页展示和按名称模糊搜索循环3实现新增客户表单提交后写入数据库并在列表页能看到新记录循环4实现客户详情页展示该客户的所有基本信息和关联项目此时项目模块还没做所以先显示空提示循环5实现编辑和删除功能操作完成后列表页数据同步刷新其中循环4有一个很好的设计它不依赖还没做的项目模块但页面结构先把关联项目的区域留好了。这样等第二里程碑开发项目模块时只需要回来把这个区域的假状态替换成真实数据即可不需要重新设计页面。这也算是Loop Engineering中一个潜在的架构技巧——让每一轮循环的成果能被下一轮直接使用。4.2 里程碑一客户信息管理的完整循环记录第一里程碑实际执行时我记录了每一轮循环的任务指令、验证结果、修复动作和最终状态。这里挑几轮有代表性的详细说明。**循环2客户列表页**是执行中比较顺利的一轮。任务指令很简单在现有前端框架下新增一个客户列表页面数据来源是后端客户列表接口支持按名称关键字过滤。AI生成后我启动项目验证发现列表能正常展示三条测试数据但搜索功能没有任何反应。把浏览器控制台的报错贴给AI后它识别出问题出在搜索请求的URL拼接方式上修复后搜索功能正常。这轮循环耗时大约二十分钟其中大部分时间花在等待AI生成代码上人工介入的时间非常少。**循环4客户详情页**是值得展开的一轮。任务要求展示客户基本信息并在页面下方预留项目进度区域。AI生成的页面基础信息部分正常但预留区域它擅自实现了一个展示项目列表的假数据区块——这个我没有要求而且假数据容易让后续迭代时分不清真实数据是否走通。我要求AI删掉假数据改为展示一个友好提示。这个修正单独又跑了一轮循环。这个例子想说明的是即便任务指令说得很清楚AI依然倾向于把故事讲完整——它不喜欢留空所以会自己补内容。这些内容如果恰好是你后续计划的真实功能那还好但更多时候是凭空造的假数据会成为项目的负担。所以验证环节里专门检查有没有多余的东西是必要的不要只检查需要的东西有没有。**循环5编辑和删除功能**是踩坑最多的一轮。客户列表现有的编辑按钮点击后没有反应删除按钮点击后数据从界面上消失了但刷新后又出现——典型的只有前端动作没有后端持久化。这一轮的错误反馈是我手动测试后描述给AI的点击删除后列表自动移除了该行但刷新页面后该客户重新出现说明删除没有真正持久化到后端。AI根据这个描述找到了问题前端调用了API接口但后端接口返回了成功状态码却没有真正执行删除语句也就是假成功接口。这个修复本身不复杂但那种接口返回成功但实际上什么都没做的情况如果不做数据层面的验证刷新页面/查数据库很容易被当成循环已通过而放过。这个教训值得所有人记住验证结果时不要只验证界面反馈要验证数据是否真的变了。界面上元素消失可能是前端过滤掉了而不是后端删掉了。数据库里的行还在这个问题就还在。4.3 里程碑二项目进度记录如何复用前三轮的反馈进入第二里程碑时项目里已经积累了二十多条循环记录。这些记录不仅记录了项目历史也是后续循环的上下文。我让AI在开发项目模块前先阅读这些记录重点是搞清楚两个问题客户详情页预留的项目区域是什么结构以及现有数据库操作代码遵循什么约定。第二轮AI生成项目进度模块时直接复用了客户详情的页面风格并把关联项目区域的假状态替换成了真实数据。整个模块的开发比预期的顺利很多。原因我认为就是前面提到的架构技巧起了作用——第一里程碑里预留区域的设计不是规划出来的而是在第四轮循环中恰好想到后面会用到顺手定下的约定。这种过程中自然涌现的架构比一开始完全规划好的架构更容易落地。这个阶段也有过一个小坑项目进度模块需要给每条进度记录添加状态标签进行中、已完成等AI默认用了一个字符串字段存标签文字。当时数据量小这么做的确没有问题。但考虑到后续统计看板需要按状态分组计数用字符串字段在统计时需要进行文本匹配不仅低效还容易因为文字不一致出现统计偏差。我让AI改为用固定的数字编码存储状态页面上再做编码与文字的映射。这个选择背后的原因是面向未来的统计看板里程碑。Loop Engineering虽然在任务粒度上切得很细但决策时一定要考虑后续循环的需求。否则每次后续需求变化前面开发的模块都推倒重来一遍循环效率再高也补不回返工的成本。4.4 里程碑三和四统计看板与登录验证的循环细节统计看板里程碑实现的功能是按客户维度统计项目总数、进行中项目数、已完成项目数并在首页展示一个简单的汇总卡片。这个模块的开发依赖于前面两个里程碑产生真实数据所以在开发前我先手动往数据库里灌了一批模拟数据确保统计结果有东西可看。这轮循环遇到的问题集中在接口粒度上。AI默认实现的统计接口是一次性返回所有统计数据前端拿一次数据算好展示。这种方式在这个项目里没什么问题但也忽略了一个后续场景如果统计口径需要扩展比如增加本月新增客户数前端和后端都要改。我让AI把统计接口拆成语义化的子接口每个统计卡片对应一个独立接口。这样后续扩展时只需要加新卡片和新接口老接口不用动。登录验证里程碑是整个项目里唯一涉及时序问题的模块。实现逻辑是用户输入用户名密码后校验成功后发一个带时间的令牌后续请求带上这个令牌视为已登录。这个功能如果让AI一次性实现会很容易出现登录成功后跳转正常但刷新后跳回登录页这类会话状态丢失的问题。所以我把这个里程碑拆成了三个循环令牌发放与校验、前端请求携带令牌、刷新后的会话保持。这三个循环里会话保持是最微妙的。浏览器刷新会导致内存中的登录状态丢失所以必须依赖持久化存储或者Cookie之类的机制。AI在第一版实现时把令牌只存在了内存变量中刷新页面后令牌丢失自然跳回登录页。我把这个现象反馈给它后它改为使用持久化存储方案问题解决。这个案例是典型的运行验证驱动修复——如果是靠人工审查代码很可能要等调试很久才发现内存变量的问题而运行验证几秒钟就能暴露。5. 突破循环瓶颈错误信息处理、批量任务调度与人工干预的边界5.1 如何处理AI反复修不好的情况Loop Engineering跑熟了以后会遇到新的挑战某个循环反复无法通过AI换了四五次方案仍然报错。这时候最容易产生的冲动有两个——一是亲自上手改代码二是让AI从头重写整个文件。这两个动作都不是最优解。我在这个项目里遇到过类似情况问题出在一个数据库字段的默认值上。AI每次生成的建表脚本都会报一个数据库语法错误我贴了三次完整报错它反复修改却始终在同一个位置出错。后来我做了个决定把这个报错连同一个请仔细检查字段定义部分不要再修改其他区域的指令发给AI并要求它先输出对该错误的逐行解析再给出修复方案。这次AI总算定位到问题所在——它一直在修复字段后边的索引定义而没有注意到是字段内部的字符集声明写错了。这个经验可以总结为当循环反复不通过时不要重复给错误-等修复这个简单反馈而是升级反馈的层次要求AI先分析再动手。分析过程会让AI看到它此前忽略的部分。如果连分析都回答不对说明当前AI能力对这个任务有困难换个思路比硬杠更有意义。5.2 批量任务怎么跑多线程循环与依赖管理项目开发到后半程很多循环任务彼此之间没有依赖关系比如编辑客户信息时校验电话号码格式和客户列表导出功能完全可以同时做。这时候再一个循环一个循环地串行跑效率就太低了。我开始使用批量会话的方式同时开多个AI会话处理不同任务然后在项目验证日志里记录每个会话的进展。批量调度的前提是任务之间没有共享的文件改动。否则两个会话同时改同一个文件后写覆盖先写的冲突会非常混乱。我在调度前会先让AI输出每个任务涉及的文件清单凡是有文件重叠的任务就归入同一批次串行执行没有重叠的才并发处理。这种方式能把项目后半段的推进速度提升两三倍但它有一个前提条件——你要有足够清晰的验证清单。每个并发任务执行完都需要独立验证、独立记录。我在项目里建了一个简单的批处理记录表表格的表头是任务ID、涉及文件、会话状态、验证结果、备注。每次批量调度后更新这个表整个项目的状态一目了然。如果没有这个表并发任务的混乱程度会让你宁愿回到串行方式。5.3 人工干预的边界什么情况下直接写代码反而更优虽然我把Loop Engineering说得很有吸引力但它不是万能的。有些场景下直接人工写代码比循环更快也更可靠。结合这个项目的实际经历我总结出三类必须人工干预的情况。第一类是涉及复杂业务规则的逻辑。比如这个项目里判断某个项目是否逾期的规则涉及多个条件的组合项目截止日期是否超过今天、是否处于暂停状态、是否有未关闭的延期申请。这种多条件交织的判断逻辑AI生成时很容易漏掉某个边界条件人工写反而清爽可靠。第二类是性能敏感的关键路径。虽然这个副业工具规模小但比如客户列表的分页排序如果设计不合理数据量大了以后会出现响应缓慢的问题。这种现在看不出来但未来可能出事的优化AI不会主动做优化需要人来判断和干预。第三类是代码风格和项目约定的一致性维护。AI生成的代码在单次看是合理的但多轮循环以后不同的会话可能产生不同的命名风格、不同的错误处理方式。让项目保持统一的风格约定这件事目前仍然需要人来做。我在项目验收阶段花了一些时间做全局检查把风格不一致的地方统一掉。这三类干预场景不是反Loop Engineering的恰恰相反它们说明了一个事实循环的价值在于放大人的效率而不是替代人的判断。你判断全局AI执行局部这才是健康的协作关系。5.4 规模化后的记录方法验证日志怎么写得既轻量又有用最后讲一个关于记录的方式。Loop Engineering规模上来以后最需要建好的是一套轻量记录习惯。这个项目的记录载体就是一个简单的Markdown文件按日期分块每块记录当天跑过的循环编号、任务、验证结果、遗留问题。没有用任何项目管理工具因为对个人开发者来说工具反而是负担。记录的关键不是详实而是事后可回溯。我不会每天写一大段只记录每轮循环的四个要素任务是什么、验证动作是什么、结果通过还是失败、失败时的原始反馈是什么。这四个要素已经足以支持几天后回看并定位问题的需求。有一次项目出了个诡异的问题某条数据在列表页显示但详情页显示不了。我翻验证日志发现这个问题和几天前某个循环的遗留记录完全吻合五分钟定位到原因。如果没有这份日志以这个项目的代码规模排查时间可能要以小时计。6. 循环跑了六十多次之后我对工程化的重新理解项目最终收官时我数了一下验证日志里的循环记录总共六十多轮。每个里程碑都有对应的循环记录可查每次变更都能追溯到是哪个任务、哪次验证、哪个修复引入了它。这个项目的代码质量未必顶尖但开发过程是有史以来最透明的。这让我重新理解了工程化这个词。我之前总觉得工程化是指那些重型的东西架构设计、自动化测试、CI/CD流水线、详细的文档规范。但Loop Engineering用最小可行的方式实现了一种轻量工程化——它不具备重型工程化的完备性却抓住了工程化最核心的特质把不可控变成可控把隐式的假设变成显式的验证。回想这个过程中最让我有感触的时刻是某个开发者朋友问我说你们用AI做了这么多功能是不是完全没写代码我说不是我们写了很多代码但方式变了。以前写代码是在脑子里推演整个系统然后一次性落笔现在写代码是在一堆验证反馈里做决策——哪些反馈说明方向对了哪些反馈说明该换方案了哪些反馈其实是无关噪音。AI负责生成候选方案人负责选择和验证。这种分工比人类全写AI辅助或者AI全写人类旁观都更可持续。如果说有什么建议留给想实践这套方法的人我会说三句话。第一句不要贪心一次循环只解决一个可以被明确验证的问题。第二句验证的动作要真实到数据层面界面显示正常不等于功能真的正常。第三句记录每轮循环的反馈事后回看时它会变成项目里最有价值的资产。那台机器上跑着的副业工具现在还在稳定运行。工作室的人偶尔会提新需求我就顺着原有循环继续跑新任务——打开项目验证日志加一条新循环记录然后启动开发。事情变得简单了很多。
阅读完成 · 觉得有帮助？
