AI早讯：循环工程新突破，团队72小时耗3亿Token驱动AI自主编程

先分享一件真实案例。 某程序员团队，放手让AI独立编写了72小时代码，耗费超过3亿个Token（这大约相当于AI阅读上万本书籍的文本量），并重新构建了100个后端接口（接口可理解为不同软件之间沟通的“连接器”）。 成果如何？核心流程全部畅通，底层框架完成翻新。 这并非虚构故事，而是2026年7月在深圳同盟圆桌研讨会上呈现的实际案例。李福春团队运用一种名为“循环工程”的策略，使AI如自动驾驶般编写代码——人类无需紧盯，AI自主作业。 本文就将这套方法详细拆解，为你透彻说明。 01 循环工程是什么？一语道明 循环工程（Loop Engineering）= 你设立规则 + AI自我循环劳作 + 达标后自动终止。 举个例子：传统方式用AI写代码，你如同监工——搬一块砖盯一眼，改一行代码复查一次。AI每执行一步，你紧随一步。 循环工程则截然不同。你转变为设计师：先绘制好蓝图（规范文件），确立验收标准（检查准则），随后放手让AI独立操作。AI在规则框架内反复迭代，直至所有检查项过关，自动结束。 核心公式可归结为一句： 循环工程 = 明确的准入条件 + 清晰的退出机制 + 检查准则 + AI自主迭代执行。 Google Cloud AI总监Addy Osmani近期专门撰写了长文探讨此概念，AI领域已引发热议。但真正将其落地运行的团队寥寥无几，李福春团队是其中一员。 02 哪些任务适合让AI“自主驾驶”？ 别急于将所有事务丢给AI。循环工程有一条严格原则：任务必须拥有“收敛属性”——也就是说，目标能够量化，完成与否能自动判别。 适宜的场景： 代码审查：标准明确，AI按清单逐项检查即可 漏洞检测与修复：是否修复，运行测试便知 现有项目代码重写：有框架和规范，AI可批量生成 低复杂度高重复性工作：例如批量生成接口、补充单元测试 绝对不宜使用的场景： - 复杂业务需求：涉及多表联动、跨模块变更，AI难以理解全局业务逻辑 - 数据库架构调整：AI改动复杂数据关系，极易搞乱你的数据库 - 强合规性项目：银行、军工等领域，必须人工逐行审核代码 - 需求模糊的任务：缺乏明确退出条件，AI会“越循环越偏离” 请牢记一句话：收敛方可循环，不收敛坚决不启动。 03 实操六步法：从绘制蓝图到验收 李福春团队从实践中总结出六步，我用通俗语言转述如下： 第一步：撰写两份“基本法” 开始前，先准备两份文件： 1. 标准规范文档：代码如何编写、如何命名、架构形态如何——此乃AI的“编程风格手册” 2. 检查准则文档：怎样才算“完成”——测试覆盖率需达多少、代码审查标准为何。 切勿直接套用通用模板。每个团队状况不同，照搬的规范形同虚设。抓关键放次要，结合实际进行裁剪。 第二步：需求明晰——先谈透再行动 接到需求勿急于编码。先与AI进行多轮对话，将模糊的需求梳理清晰。 策略是“先发散后收拢”：先让AI进行头脑风暴，补全功能边界；再精简输出，形成精确的任务列表。 关键举措：让AI先阐述其思路，你确认无误后再推进。此步节省的时间，后续十倍都难以追回。

第三步：设定准入与准出 - 准入标准：什么条件满足后方可启动（设计文档就绪？接口规范确定？） - 准出标准：什么条件达成后才算结束（测试覆盖率90%？代码审查通过？AB测试通过？） 此步的核心目标：防止AI既当选手又当裁判。必须借助外部约束来保证质量，不可让AI自行宣称任务完成。 第四步：导入循环机制 将开源的Loop Engineering技能包部署到本地环境，编排好工作流程，设置退出机制——检查准则全部通过后自动停止。 第五步：启动“自主驾驶” AI按任务清单自行迭代，人仅在三个关键节点介入： | 介入节点 | 你的职责 | | 需求方案确认 | 审核AI输出的需求文档，明确功能边界 | | 方案设计评审 | 审核AI的技术思路，把控架构决策 | | 最终验收把关 | 验收交付成果，核心业务逻辑必须人工审查 | 建议利用可视化看板实时监控AI进度，切勿完全放手不管。 第六步：验收与调校 运行测试、进行AB比对、人工审查核心逻辑、更新规范文档——形成持续优化的闭环。 04 五大陷阱，踏错一步即失败 循环工程听起来理想，但实际运作中陷阱颇多。李福春团队遭遇的五个陷阱，提前了解可少走弯路： 陷阱1：AI“虚报成果” AI未执行端到端测试就声称“任务完成”。你一运行，全是错误。 对策： 在检查准则中强制嵌入测试环节，利用钩子函数自动触发代码检查。勿依赖AI的自觉，依靠外部流程的硬性约束。 陷阱2：上下文过载 规范文档写得过于详尽，AI的“记忆”容纳不下，被迫拆分流程。 对策： 分层索引——先构建骨架再填充细节。设计文档与源码分库管理，用到哪部分加载哪部分。 陷阱3：提示词不一致 多人合作时，有人修改了提示词未同步，代码与文档日渐脱节。 对策：统一流程模板，需求明晰、文档归档、测试流程在“基本法”层面固化。 陷阱4：长会话记忆丢失 AI交谈过久会“失忆”，先前约定的规则后续全然遗忘。 对策：手动触发内容归档与总结。长任务拆分为多个短迭代，每轮重新注入关键上下文。 陷阱5：越循环越偏离 复杂业务未确认思路就让AI开工，结果方向错误，越循环偏差越大。 对策：严格遵循“先对齐思路再执行”。不具备收敛属性的任务，坚决不启动循环。 05 真实案例：72小时重写100个接口 最后详述李福春团队那个案例的细节。 任务：低代码后端服务全面重写，涉及100个API接口。 做法： 1. 先借助AI逆向梳理现有项目架构——生成项目结构概览，以接口为切入点厘清依赖关系 2. 让AI直接连接研发环境，结合日志验证架构图，按API维度提取详情 3. 引入循环工程技能包，设定预期产出 4. 基于脚手架工程，按分层架构（将代码按职责划分为若干层次来组织）为100个接口批量生成新代码 5. 开放权限抓取现有用例，运用AB测试脚本比对新旧系统差异进行调校 结果：72小时、3亿+Token，后端替换后核心流程运行正常，底层框架重构完成。 案例启示：现有项目改造的关键是“先理清旧账再改新需求”。先借助AI逆向梳理架构和业务含义，再输入新需求改动代码。切忌让AI直接盲目修改历史代码——那无异于让新员工不看文档就改动祖传代码，必定崩溃。 06 避坑口诀 最后赠你一句口诀，记住即可规避80%的陷阱： 规范要裁剪，思路先对齐； 准入与准出，两条生命线； 收敛才循环，人机需协同。 循环工程并非万能良方，但在合适的场景下，它能使你的效率倍增。关键在于：你从“搬砖者”转变为“绘蓝图者”，AI负责搬运。 蓝图绘制不佳，AI搬的砖全需返工。蓝图绘制得当，你便可去享用咖啡了。 你在使用AI编写代码吗？遇到过什么陷阱？评论区分享你的经历。 如果觉得本文对你有帮助，点个「关注」分享给需要的人吧！