AI 自治 Loop：让 AI 学会"自我测试"的开发循环
"
前言：当 AI 开始"自测"
想象这样一个场景：
你给 AI 一个开发任务，然后就可以去喝咖啡了。AI 自己编写代码，自己运行测试，自己修复错误，直到所有测试通过——然后通知你："任务完成了"。
这不是科幻小说，而是AI 自治 Loop正在实现的能力。
今天，我们就来探讨这个让 AI 能够"自我测试"的开发循环。
一、传统 AI 辅助开发的痛点
1.1 上下文漂移
场景：
你：帮我写一个用户登录功能
AI：好的，我需要先确认几个问题...
你：直接用 JWT
AI：好的，那我需要数据库schema...
你：用 MySQL
AI：好的，那我需要密码加密方式...
你：用 bcrypt
...（50轮对话后）
AI：好的，那前端表单验证规则是什么？
你：（崩溃）我都说了一百遍了！问题：
- 需求在对话中不断变化
- AI 每次只能记住部分上下文
- 重复确认相同的问题
- 最终实现可能与初始需求偏离
1.2 状态不可追溯
场景：
Day 1：AI 写了登录功能的一半
Day 2：新会话，AI 不知道昨天做到哪了
Day 3：又是一个新会话，AI 重新开始
...（一周后）
你：登录功能到底写完没有？
AI：我不知道，让我重新检查一遍...问题：
- 每次会话都是全新开始
- 无法追溯之前的进度
- 重复劳动，效率低下
- 难以管理长期任务
1.3 验收标准模糊
场景：
你：这个功能完成了吗？
AI：我觉得完成了
你：那测试一下？
AI：（运行测试）... 咦，有几个bug
你：那你修复一下
AI：好的...（修复后）现在应该可以了
你：再测试一次？
AI：（又发现新bug）...问题：
- "完成"的定义不清晰
- AI 无法自主判断是否真正完成
- 需要反复人工介入
- 测试和修复的循环无休止
1.4 缺乏自我修复能力
场景：
AI：我写完了登录功能
你：运行测试看看
AI：（测试失败）... 测试失败了
你：那怎么办？
AI：我不知道，你来告诉我怎么修复
你：（手动修复）... 现在重新测试
AI：（又失败）... 还是失败了
你：（再次手动修复）...问题：
- AI 无法根据错误信息自我修复
- 每次修复都需要人工介入
- 效率极低
- 无法实现真正的自动化
二、AI 自治 Loop：Plan 驱动的解决方案
2.1 核心定位
AI 自治 Loop 是一个面向 AI 自治运行的开发循环，结合了 TDD（测试驱动开发）与自动化测试，用于研发自测场景。
核心思想：
以 Plan（计划） 为核心载体，将需求、实现状态、验收标准固化在文档中，使 AI 能够按计划分批执行、自我修复，并最终退出循环。
2.2 三大核心特点
1. Plan 阶段锁定上下文
"在创建 Plan 时，尽可能将所有开放性问题关闭"
含义：
- 需求歧义 → 明确需求
- 技术选型 → 确定方案
- 边界条件 → 定义范围
- 验收标准 → 设定指标
效果：保证后续执行无需额外决策
2. Plan 记录实现状态
"Plan 文档需包含当前进度（已完成/进行中/待办）"
含义：
- 已完成：哪些任务已经完成
- 进行中：当前正在做什么
- 待办：还有哪些任务需要完成
效果：支持任务分批完成或失败后重试
3. 确定性验收方式
"必须给出可自动判定的验收标准"
示例：
- ✅ 所有 API 测试通过
- ✅ 单元测试覆盖率 ≥ 80%
- ✅ 无未处理的异常
效果：让 AI 能自主判断修复是否成功
三、Loop 规则：TDD 驱动的四步循环
3.1 完整流程图
流程说明：
- 开始：启动 AI 自治 Loop
- Chat进入Plan模式：人类/主管提供需求规格，给出指令进行 Plan
- 模型读取Plan：AI 模型从 docs/plans/ 加载 Plan 文档
- 模型创建测试和代码：按 TDD 顺序，先创建 API 测试，再实现代码
- 模型运行测试：执行 API 测试或浏览器调试
- 测试是否成功：判断测试是否通过
- 是：进入下一步，退出 Plan
- 否：返回修复错误，重新运行测试
- 模型退出Plan：所有验收测试通过，Loop 结束
- 结束：完成或进入下一个 Plan
关键设计：
- 判断节点："测试是否成功"是核心判断点，决定是退出还是继续修复
- 循环修复：测试失败时，自动修复并重新测试，形成闭环
- 退出条件：只有测试全部通过才能退出 Loop
图例说明：
- 🟢 绿色节点：开始/结束
- 🔵 蓝色节点：处理步骤
- 🟠 橙色节点：判断决策
- 🟣 紫色节点：人工操作
3.2 步骤详解
步骤 1：Plan 等待确认
"在 docs/plans/ 目录下，根据模板创建 Plan 文档"
Plan 文档包含：
- 需求描述
- 技术方案
- 接口定义
- 验收标准
关键点：人工或主管确认 Plan 内容无误后，循环才可继续
步骤 2：编写 API 测试（失败阶段）
"根据 Plan 编写 API 级别的集成测试"
工具选择：
- Supertest（Node.js）
- Postman Newman
- REST Assured（Java）
目标：运行这些测试，确保它们因功能未实现而失败（红条）
验证：以此验证测试本身的有效性
步骤 3：编写实现（单元测试 + 代码）
"编写单元测试（白盒覆盖），并实现功能代码"
TDD 顺序：
- 先写单元测试
- 再实现功能代码
- 确保代码通过编译
- 确保单元测试全部通过（绿条）
步骤 4：运行 API 测试并修复
"执行 API 测试，若测试失败，根据报错信息修复代码或测试"
循环：
- 测试失败 → 分析错误 → 修复代码/测试 → 重新测试
- 测试通过 → 本 Plan 完成，退出循环
四、关键角色与权限
4.1 Chat（人类/主管）
职责：
- 进入 Plan 模式
- 提供需求规格
- 批准 Plan 内容
权限：
- 决定是否开始 Loop
- 决定是否中断 Loop
- ByPass 权限（强制退出）
4.2 AI 模型
职责：
- 读取 Plan
- 编写测试/代码
- 运行调试
- 分析失败并修复
- 自主判断是否通过验收
权限：
- 自主执行测试
- 自主修复错误
- 自主决定是否完成
4.3 ByPass 权限
触发条件：
- 模型陷入死循环
- 多次失败且无法自动修复
权限：
- 跳过当前 Plan
- 修正方向
- 强制退出
设计目的：防止 AI 无限循环，提供人工干预机制
五、验收标准：确定性的完成判断
5.1 API 测试验收标准
1. 所有 API 端点返回预期的 HTTP 状态码和响应体
示例：
POST /api/auth/login → 200 OK + { token: "xxx" }
POST /api/auth/login → 401 Unauthorized + { error: "Invalid credentials" }2. 数据库状态变更符合预期
示例：
创建用户 → users 表新增一条记录
删除用户 → users 表删除对应记录3. 单元测试覆盖率不低于设定阈值
示例：
覆盖率 ≥ 80%
关键路径覆盖率 = 100%4. 无未处理的异常或内存泄漏
示例：
所有异常都有 try-catch
所有资源都有正确释放5.2 前端 UI 验收标准
1. 所有交互路径可正常执行
示例：
点击登录 → 表单验证 → API 请求 → 成功跳转2. UI 状态更新符合预期
示例：
登录成功 → 显示用户信息
登录失败 → 显示错误提示3. 浏览器控制台无错误
示例：
Console: 无 404 错误
Console: 无 JS 异常六、适用场景与限制
6.1 适用场景
1. 后端微服务接口开发
典型任务：
- RESTful API 开发
- 数据库 CRUD 操作
- 业务逻辑实现
优势：
- API 测试易于自动化
- 验收标准明确
- 修复方向清晰
2. 前端页面交互逻辑
典型任务：
- 表单验证
- 页面跳转
- 状态管理
工具：
- Cypress
- Playwright
- Selenium
3. 任何可自动化验收的模块迭代
前提：
- 有明确的验收标准
- 有可运行的测试
- 有可修复的错误信息
6.2 使用限制
1. Plan 必须足够详尽
问题：如果 Plan 含糊不清，AI 会产生二义性
解决：在 Plan 阶段尽可能关闭所有开放性问题
2. 测试用例应覆盖全面
覆盖范围：
- 正常路径
- 异常路径
- 边界条件
3. 外部依赖必须明确
示例：
- 第三方 API 的可用性
- 数据库的连接配置
- 环境变量的设置
七、核心价值：从"对话驱动"到"计划驱动"
7.1 传统 AI 辅助开发 vs AI 自治 Loop
| 维度 | 传统 AI 辅助开发 | AI 自治 Loop |
|---|---|---|
| 驱动方式 | 对话驱动 | Plan 驱动 |
| 上下文管理 | 容易漂移 | 锁定在 Plan |
| 状态追溯 | 不可追溯 | Plan 记录状态 |
| 验收标准 | 模糊判断 | 确定性验收 |
| 修复能力 | 人工介入 | 自我修复 |
| 自动化程度 | 低 | 高 |
| 适用规模 | 小任务 | 大任务 |
7.2 五大核心价值
1. 上下文固化
价值：
- 所有决策在 Plan 阶段锁定
- 避免执行中的上下文漂移
- 保证结果的一致性
2. 状态可追溯
价值：
- Plan 文档记录所有状态
- 支持断点恢复
- 支持分批完成
3. 确定性验收
价值：
- 可自动判定的验收标准
- AI 能自主判断是否完成
- 无需人工介入
4. 自我修复能力
价值：
- 测试失败后自动修复
- 根据错误信息调整代码
- 重新测试验证
- 形成闭环
5. TDD 驱动
价值：
- 先写测试，后写代码
- 红条 → 绿条 → 重构
- 保证代码质量
八、实践建议
8.1 Plan 编写最佳实践
1. 需求描述要具体
❌ 反例：
实现用户登录✅ 正例：
实现用户登录功能，支持邮箱+密码登录，返回 JWT token，有效期 7 天2. 技术方案要明确
❌ 反例：
使用数据库存储用户信息✅ 正例：
使用 MySQL 存储用户信息，密码使用 bcrypt 加密，salt rounds = 103. 验收标准要可测试
❌ 反例：
登录功能应该正常工作✅ 正例：
POST /api/auth/login 返回 200 且响应体包含 token 字段
所有单元测试通过且覆盖率 ≥ 80%8.2 测试编写建议
1. 测试用例要全面
覆盖：
- 正常路径：正确输入 → 正确输出
- 异常路径：错误输入 → 错误提示
- 边界条件：极限值 → 正确处理
2. 测试要独立
原则：
- 每个测试独立运行
- 不依赖执行顺序
- 不依赖外部状态
3. 测试要快速
目标：
- 单元测试：< 100ms/个
- 集成测试：< 1s/个
8.3 错误处理建议
1. 分析错误类型
分类：
- 代码错误：逻辑bug、语法错误
- 测试错误：测试用例错误
- 环境错误：依赖缺失、配置错误
2. 优先级排序
顺序：
- 环境错误（阻塞所有测试）
- 代码错误（影响功能）
- 测试错误（影响验证）
3. 修复策略
方法：
- 环境错误 → 检查配置、安装依赖
- 代码错误 → 分析堆栈、定位问题
- 测试错误 → 检查断言、修正预期
九、未来展望
9.1 演进方向
1. 更智能的 Plan 生成
目标：
- 自动从需求生成 Plan
- 自动识别技术选型
- 自动定义验收标准
2. 更强大的自我修复能力
目标：
- 更智能的错误分析
- 更精准的修复建议
- 更快速的修复验证
3. 更丰富的测试支持
目标：
- 更多测试框架集成
- 更智能的测试生成
- 更全面的测试覆盖
4. 更完善的工具链
目标：
- 更好的 Plan 编辑器
- 更强的测试运行器
- 更友好的调试界面
5. 更广泛的应用场景
扩展：
- 前端开发
- 后端开发
- 移动开发
- 数据工程
- DevOps
9.2 愿景
AI 自治 Loop 的终极愿景：
让 AI 能够像人类开发者一样，独立完成从需求分析到代码实现再到测试验证的完整开发循环。
实现路径：
- Plan 驱动的上下文固化
- TDD 驱动的质量保证
- 自我修复的闭环反馈
- 确定性验收的自动判断
十、总结
10.1 核心回顾
AI 自治 Loop 的三大核心特点：
- Plan 阶段锁定上下文：所有决策在 Plan 阶段确定
- Plan 记录实现状态：支持断点恢复和分批完成
- 确定性验收方式：AI 能自主判断是否完成
AI 自治 Loop 的四步循环：
- Plan 等待确认
- 编写 API 测试（失败阶段）
- 编写实现（单元测试 + 代码）
- 运行 API 测试并修复
10.2 革命性意义
从"对话驱动"到"计划驱动"：
传统 AI 辅助开发依赖持续对话，上下文容易漂移，验收标准模糊，需要人工介入。
AI 自治 Loop 通过 Plan 锁定上下文，记录状态，设定确定性验收标准，实现自我修复，完全自主运行。
从"人工测试"到"自我测试"：
传统开发需要人工编写测试、人工运行测试、人工分析错误、人工修复bug。
AI 自治 Loop 让 AI 自己编写测试、自己运行测试、自己分析错误、自己修复bug，形成完整的闭环。
这就是 AI 自治 Loop 的核心价值：Plan 驱动的 TDD 自测循环，让 AI 能够按计划分批执行、自我修复，并最终退出循环！
参考资源：
- TDD 最佳实践：https://martinfowler.com/bliki/TestDrivenDevelopment.html
- 自动化测试指南：https://www.oreilly.com/library/view/test-driven-development/9780321836599/
如果你觉得这篇文章有帮助，欢迎点赞、转发，让更多人了解 AI 自治 Loop 的开发方法！