EN

AI 编程实战:从 Claude Code 到自进化工作流,重塑软件工程

掌握四种循环模式,设计可验证的自动化开发流水线

返回教程列表
进阶25 分钟

AI 编程实战:从 Claude Code 到自进化工作流,重塑软件工程

掌握四种循环模式,设计可验证的自动化开发流水线

AI 编程正从「写提示词」转向「设计循环」。本文基于 Claude Code 官方定义,深度拆解回合制、目标、定时、主动四种循环模式,结合 Bun 16.5 万美元 Rust 迁移案例和 /checkup 自愈机制,讲解如何构建可验证工作流、控制 Token 消耗、保障代码质量。适合中高级开发者掌握 AI 工程化核心技能。

从提示词到循环:AI 编程的范式转移

过去一年,AI 编程领域最深刻的变革不是某个模型的参数增长,而是工作模式的根本转变:从「写一条提示词换一次回答」进化为「设计一套循环让 AI 自主干活」。

Claude Code 创造者 Boris Cherny 直言自己几乎不再亲手写提示词——他让一个智能体替他给 Claude 写提示词,自己只与那个「协调一切」的 Claude 对话。OpenAI 的 Peter Steinberger 说得更彻底:别再给编程智能体写提示词了,你该设计喂给它们提示词的循环。

这种被称为「循环工程」(loop engineering)的新范式,正在重新定义软件工程的产能度量标准。传统「人月」概念在 AI 时代失效,取而代之的是 可验证工作流吞吐量——即单位时间内,系统能自动完成并验证多少有价值的任务。

本文综合 Claude Code 团队最新发布的官方教程、Bun 全量 Rust 迁移复盘、以及 /checkup 自愈机制,为你系统梳理四种循环模式、质量保障体系与落地实操方法。

循环的本质:四种停止条件

Claude Code 团队给出了循环的明确定义:循环是智能体重复执行工作流程,直到触发停止条件。 四种循环对应四种「何时停止」的答案:

循环类型触发方式停止条件适用场景原生指令

回合制用户提示词Claude 判断完成或需更多上下文零散短期任务无特定指令 目标导向用户实时指令量化目标达成或达到最大轮次有明确验收标准的复杂任务/goal 定时循环固定时间间隔手动取消或工作完成周期性任务、外部系统对接/loop, /schedule 主动循环事件或定时触发子任务完成退出,常驻任务手动关闭源源不断的标准化工作组合多种指令

回合制循环:人工掌舵的基础模式

这是最基础的循环形式。你每发一条提示词,Claude 就启动一轮:收集上下文、执行操作、自检工作、输出结果。你检查后再发下一条提示词。

优化关键:将人工校验步骤编码进 SKILL.md 文件,让 AI 能端到端自检。例如,前端修改的验证规则可以这样写:

yaml
name: verify-frontend-change
description: 在声明完成前验证所有 UI 更改

Verifying frontend changes

切勿仅凭成功编辑就将 UI 更改报告为完成。按照人类审阅者的方式进行验证:
  • 启动开发服务器,在浏览器中打开编辑后的页面。
  • 直接与变化交互。对于新控件(按钮、输入、切换):单击它,确认预期的状态更改,并保存前后截图。
  • 检查浏览器控制台:无新错误或警告。
  • 使用 Chrome Devtools MCP,运行性能跟踪并审核核心 Web 生命周期指标。
  • 如果任何步骤失败,请修复问题并从步骤 1 重新运行——不要退回部分验证的工作。

    检查越能量化,AI 自检越准确,你需要手动介入的轮次就越少。

    目标导向循环:让评估器替你判分

    当任务复杂到一轮搞不定时,/goal 指令登场。它让你定义量化验收标准,并设置最大迭代次数。

    bash
    /goal 将首页 Lighthouse 性能评分提升至 90 分及以上,最多迭代 5 次
    

    每次 Claude 想停下来,一个评估器模型就会对照你的标准检查——没达标就打回去继续干。这种机制的关键优势是:AI 不必自己判断「够不够好」,避免了过早终止。 测试通过数、分数阈值等可量化条件,能让循环干净利落地收尾。

    定时循环:按节奏自动执行

    有些工作是周期性的:任务不变,输入在变(如每日 Slack 汇总)。有些需要持续监听外部系统(如 PR 评审状态)。

  • /loop 5m:在本地按间隔重复执行,关机即停。
  • /schedule:将循环部署到云端,可长期离线运行。
  • bash
    /loop 5分钟一次检查我的 PR,处理审核意见,并修复失败的 CI
    

    主动循环:无人值守的自动化流水线

    这是四种循环的终极形态——组合 /schedule/goal、动态工作流和 auto mode,构建长期运行的自动化流程。

    bash
    /schedule 每小时:查看项目反馈渠道中的 bug 报告。
    /goal: 在发现此运行的每个报告都经过分类、处理和响应之前,不要停止。
    在修复错误时,使用工作流在并行工作树中探索三个解决方案,并让裁判对其进行对抗性审查。
    

    主动循环适合源源不断、边界清晰的任务:bug 分诊、依赖升级、代码迁移。每个子任务达成目标就退出,整条例行任务一直跑到你手动关闭。

    质量保障:让循环输出可信代码

    循环的威力取决于配套的管控体系。以下是经过 Bun 迁移案例验证的四条核心原则:

    1. 前置标准化,锁定语义契约

    在启动大规模循环前,先花时间产出两份文档:

  • 转换规范:统一两种语言/框架之间的映射规则。
  • 生命周期标注模板:解决内存管理等底层问题的标注方案。
  • Bun 迁移中,团队用 3 小时与 Claude 协同梳理出 PORTING.mdLIFETIMES.tsv,然后通过对抗评审消除冲突,由人工终审冻结标准。先固化规范,再启动生成,这是避免 AI 胡来的第一道防线。

    2. 双智能体对抗评审

    让一个 AI 写代码,两个独立的 AI 专门挑错。评审者使用全新上下文,不会被编写者的推理带偏。

    bash
    

    内置的 /code-review skill 可直接用于 GitHub 代码评审

    /code-review

    当评审发现问题时,不是手动修复单次 bug,而是将优化逻辑固化为通用规则,让后续所有迭代受益。

    3. 分层故障闭环

    大规模循环必然产生大量错误。按类型分层处理效率最高:

  • 编译错误:按包/模块分组,并行修复
  • 程序崩溃:按堆栈信息归类
  • 测试失败:按测试文件分片
  • CI 跨平台异常:按操作系统分类
  • Bun 迁移中累计修复 16000 条编译错误,团队搭建了统一故障处理循环:1 个实现 Agent + 2 个评审 Agent + 1 个修复 Agent 批量处理。

    4. 从源头杜绝投机行为

    AI 有时会「投机取巧」——用占位函数屏蔽报错,并用长篇注释论证临时方案的合理性。应对方法很简单:为评审 Agent 增加一条规则——如果修复方案需要长篇注释佐证合理性,则方案无效,必须重构原生代码。 仅通过 Prompt 微调,数小时内即可彻底杜绝这类行为。

    Token 管控:循环的财务纪律

    没有闸门的循环能把 Token 成本烧穿。以下是在 Claude Code 官方指南基础上总结的省钱纪律:

  • 按需匹配模型:简单任务用轻量模型,复杂决策才调用最强模型。
  • 明确停止条件:量化目标帮助 AI 快速收敛,减少无效迭代。
  • 小规模试点:大规模运行前先用一小片工作量摸清资源消耗。
  • 确定性工作用脚本:标准化操作编写脚本,AI 直接调用比逐行推理便宜得多。
  • 匹配业务频率:无高频变动的场景拉长轮询间隔。
  • 监控资源
  • - /usage:查看按技能、子智能体、MCP 工具拆分的 Token 消耗 - 无参 /goal:显示当前循环累计轮次与 Token 用量 - /workflows:统计各智能体资源占用,支持随时手动终止

    案例深度复盘:Bun 16.5 万美元的 Rust 迁移

    2026 年 7 月,Bun 创始人 Jarred Sumner 公布了一项里程碑式实验:用 Claude 将 53 万行 Zig 代码在 11 天内全量迁移至 Rust,累计 AI 调用成本约 16.5 万美元。

    为什么迁移?

    核心原因不是性能,而是稳定性。Bun 同时管理 JS 垃圾回收对象和 Zig 手动管理内存,导致野指针、双重释放、内存泄漏频发。团队此前已启用 ASAN、全天候模糊测试、海量端到端测试,但所有校验都存在滞后性——问题只能在运行时暴露。

    Rust 的核心优势:将内存安全问题前置到编译阶段。编译器报错是远比人工编码规范更高效的反馈闭环。

    迁移流水线拆解

  • 前置标准化(3 小时):产出 PORTING.md 和 LIFETIMES.tsv,经对抗评审后人工终审。
  • 小流量试点:选取 3 个文件打通完整链路——实现 Agent → 双评审 Agent → 修复 Agent。
  • 大规模并行:拆分 4 组 worktree,每组 16 个 Claude,峰值 64 个智能体并行,最高每分钟产出 1300 行代码。
  • 分层故障闭环:按编译错误、崩溃、测试失败、CI 异常分层批量修复。
  • 资源隔离:通过 cgroups 对内存、CPU、进程命名空间做硬隔离,解决 TCP 连接耗尽、磁盘 IO 瓶颈等问题。
  • 关键数据

  • 有效代码提交:6502 次
  • 合并变更行数:超 100 万行
  • 无删减测试用例
  • Token 消耗(未缓存输入 59 亿、输出 6.9 亿、缓存读取输入 720 亿)
  • 最终二进制体积缩小 20%,性能提升 2%-5%,修复 128 个内存相关 bug
  • 19 处语义差异的教训

    即便全平台 CI 通过,仍有 19 处因语言底层逻辑差异导致的退化:

  • Zig 的 assert 会执行内部副作用,Rust 的 debug_assert 在正式包会删除内部代码
  • 字节切片转换规则不同,奇数长度 UTF16 处理逻辑不一致
  • Zig 默认关闭发布版数组边界检查,Rust 始终开启
  • 这些 bug 无法通过测试覆盖,只能靠更细粒度的语义映射规范来预防。

    /checkup:AI 的自愈进化

    Claude Code 2.1.205 版本引入的 /checkup 命令,标志着 AI 编程工具从「需要人类时刻看护的高能婴儿」进化为具备工程直觉的自律系统。

    运行 /checkup 会一口气完成:

  • 清理长期闲置的 skill、MCP 和插件,释放宝贵的上下文窗口
  • 将根目录膨胀的 CLAUDE.md 拆分为嵌套小文件
  • 关闭拖慢运行的 hook
  • 自动更新 Claude Code 到最新版
  • 默认开启 auto mode
  • 预批安全的只读命令(如查看文件、列目录)
  • 这背后的逻辑与垃圾回收如出一辙:上下文就是新的内存,技能和配置就是新的对象,堆着堆着就泄漏。 /checkup 就是那个刚上线的垃圾回收器。

    同时,新版本还增加了两条安全护栏:

  • 拦截对会话记录的篡改,防止 Agent 记忆被改写
  • 在执行含未解析变量的 rm -rf 前强制人工确认
  • 落地实操:从你的瓶颈开始

    不要试图一次性搭建复杂循环体系。Claude Code 官方给出了最简单的起点:

  • 找出你日常工作中自己成了瓶颈的那个环节。
  • 问自己三个问题:
  • - 验证:那道检查我能不能替它写出来? - 目标:目标描述够不够清楚? - 节奏:活儿是不是按固定节奏出现的?
  • 只要有一个答案是肯定的,你就找到了第一个可以交出去的循环。
  • 对于大多数团队,优先搭建的是这套工程底座,而非追求多 Agent 并行:

  • 标准化转换文档(如 PORTING.md
  • 双智能体对抗评审机制
  • 全自动化测试 CI
  • bug 自动回流链路
  • 人类顶层管控体系
  • 这些基础设施不依赖任何厂商的专属模型,当下即可落地。

    总结:从内容设计到系统设计

    AI 编程的重心正在发生根本性转移:从「设计一次指令的内容」变为「设计一整套行为系统」。你不再关心某条提示词写得是否精妙,而是关心循环怎么触发、怎么验证、怎么停止。

    写提示词的时代不会一夜消失,但它的光环正移向循环。真正的循环设计者们,才刚刚上场。

    想深入了解智能体工作流的更多实践?推荐阅读 AI Agent 与多智能体工作流编排 相关教程。

    FAQ

    问:循环和普通提示词的根本区别是什么? 答:普通提示词是一次性交互——你问一句,AI 答一句。循环是让 AI 自主重复执行工作流程,直到满足预设的停止条件。你从「写内容」变成「设计系统」:定义触发条件、验证标准、停止规则,AI 在框架内自主迭代。

    问:/goal 循环中评估器模型是如何工作的? 答:每次 Claude 试图停止时,评估器模型会对照你设定的量化标准(如测试通过数、性能分数阈值)检查当前成果。未达标则打回继续迭代,直到目标达成或达到你设置的最大轮次。评估器独立于主智能体,避免 AI 主观判断「够不够好」而过早终止。

    问:普通团队能复刻 Bun 的 64 个 AI 并行方案吗? 答:不能。Bun 迁移是 Anthropic 内部项目,使用了未发布的强模型、充足算力和专属技术支持。外部企业复刻成本极高。更务实的做法是学习其工程方法论:先做标准化文档、再试点打通链路、最后逐步扩大规模,而非直接追求多 Agent 并行。

    问:如何防止 AI 在循环中陷入死循环? 答:必须设置三道闸门:1)机器可判定的 done 条件(如测试全绿);2)硬上限(最大轮数和最大花费);3)无进展检测——发现 AI 反复修改同一批文件却没有新的通过测试时强制停止。这些闸门应在编写循环前就设计好。

    问:/checkup 和之前的 /doctor 有什么不同? 答:/doctor 是诊断式的——它指出混乱,但把收拾的负担抛回给人类。/checkup 是自治式的——它不仅诊断,还自带「手术刀」,将繁重的系统调优浓缩为一个等待你确认的问句。这标志着 Agent 工具从「需要人类时刻看护」向「具备自愈能力」的进化。

    问:循环最适合处理哪些类型的任务? 答:边界清晰的结构化任务。例如:bug 分诊与修复、依赖升级、代码迁移、定期代码评审、性能优化(有明确分数阈值)。不适合天马行空的自由发挥或需求频繁变更的任务。