原创内容未获授权禁止转载、转发、抄袭。现在很多人用 AI 写代码、改脚本、分析日志但最常见的问题是AI 第一次做不对。第二次改偏了。第三次为了让测试通过可能把关键断言删了。所以只会写提示词还不够。很多 AI 任务不是“一问一答”就能完成的而是需要反复执行、检查、修正、再执行。这就是最近越来越多人提到的 Loop Engineering。先说明一下Loop Engineering 还不是像 TDD、BDD 那样稳定的方法论。它更像是 AI Agent 圈里正在形成的一种实践说法。本文说的 Loop 工程主要指面向 AI Agent 的任务闭环设计不是泛泛的反馈循环。简单说Prompt Engineering 关注怎么问 AI。 Loop Engineering 关注怎么让 AI 持续把一件事做完、做对、做可控。为什么提示词不够了如果只是让 AI 回答一个问题提示词很重要。比如帮我生成订单取消功能的测试点。但真实工作很少这么简单。AI 第一版可能会漏库存释放第二版可能补了库存但忘了优惠券返还第三版写了很多测试点却没有验证方式。这时候靠一次提示词很难稳定解决问题。更合理的方式是设计一个闭环先拆业务规则 再生成测试点 再检查遗漏 再补验证方式 最后输出可评审版本Loop 工程的价值不是写一个更长的提示词而是把任务拆成可检查、可反馈、可停止的过程。一个最小 Loop 长什么样一个最小的 Loop大概是这样目标 - 执行 - 检查 - 反馈 - 修正 - 再执行 - 结束比如让 AI 修复自动化脚本不应该只说帮我修一下这个失败脚本。而应该设计成1. 读取失败日志和截图 2. 判断失败原因 3. 如果是定位问题修复选择器 4. 如果是数据问题说明需要准备数据 5. 如果是产品缺陷停止修改脚本 6. 修复后重新运行测试 7. 最多尝试 3 轮 8. 输出每一轮做了什么这才是可控的 Agent Loop。AI 不是一直乱试而是按规则处理。Loop 工程需要哪些东西一个可用的 AI Loop至少要有这些内容组成作用目标这轮任务最终要完成什么输入需求、代码、日志、截图、接口返回等上下文工具权限AI 能读什么、改什么、运行什么执行动作每一步允许 AI 做什么检查标准怎么判断结果是否通过反馈信号测试结果、报错、人工评审意见停止条件什么情况下结束循环人工介入点哪些情况必须让人判断过程记录每一轮做了什么、为什么这么做对测试任务来说最关键的不是让 AI 多跑几轮。而是检查标准、停止条件和人工介入点。没有停止条件AI 可能会一直改、一直试、一直消耗 token。比如可以规定最多修复 3 轮。 同一个错误重复出现 2 次后停止。 涉及业务规则不明确时停止。 测试环境不可用时停止。这就是 Loop 工程和“让 AI 自己一直跑”的区别。测试场景怎么用 Loop对测试人员来说Loop 工程很适合用在这几类任务。1. 需求测试点分析需求 - 提取业务规则 - 找风险点 - 生成测试点 - 自查遗漏 - 输出评审版比如优惠券需求AI 第一版可能只写“领取成功”。Loop 里可以继续要求它检查重复领取库存扣减并发领取活动未开始活动已结束退款后返还这样生成的测试点会更接近真实工作。2. AI 用例评审输入用例 - 检查是否可执行 - 检查是否有验证方式 - 检查是否覆盖异常 - 输出修改建议不是看 AI 写了多少条而是看有没有前置条件预期是否可判断是否只看页面提示是否缺少接口或数据验证是否漏了金额、权限、状态流转3. 自动化脚本修复运行脚本 - 读取失败日志 - 判断失败原因 - 修改脚本 - 再运行 - 输出结果这个场景最像真正的 Agent Loop。但要注意脚本绿了不代表质量好了。AI 不能为了让脚本通过就删除关键断言。Loop 里要加限制页面元素不明确时不要编造选择器。 业务断言不明确时不要删除断言。 连续两次失败原因相同停止并提示人工介入。一个完整例子自动化失败分析比如有一条 Playwright 脚本失败了。失败现象优惠券领取后页面提示成功但券包接口查询为空。普通问法可能是帮我分析失败原因。AI 可能会回答建议检查网络或接口返回。这太泛。用 Loop 的方式可以这样设计目标 判断自动化失败是脚本问题、数据问题、环境问题还是产品缺陷。 输入 1. 失败日志 2. 页面截图 3. 领取接口返回 4. 券包查询接口返回 5. 当前测试数据 工具权限 1. 可以读取日志和截图 2. 可以读取接口返回 3. 如果没有数据库或消息日志权限不能直接下结论 执行步骤 1. 先判断页面操作是否成功。 2. 再判断领取接口是否返回成功。 3. 再判断券包接口是否有延迟。 4. 如果有数据库或日志权限再判断是否写入领取记录。 5. 如果页面成功但券包无记录优先怀疑业务链路问题。 6. 如果证据不足列出还需要哪些信息。 7. 不允许直接删除断言让脚本通过。 停止条件 1. 找到明确原因。 2. 缺少关键证据。 3. 同一结论重复 2 次。 4. 需要开发确认业务逻辑。这样 AI 输出就会更接近测试人员需要的结论页面成功不代表业务成功。 当前证据显示领取操作已触发但券包未生成记录。 优先排查领取成功后写券包链路。 如果无法查询数据库或消息日志需要补充领取记录表或异步消息消费日志后再判断。这就是 Loop 的价值。它不是让 AI 多说几句而是让 AI 按排查路径做事。什么时候不适合 Loop不是所有任务都需要 Loop。如果只是一次性查询、简单总结、格式转换没必要设计复杂闭环。比如把这段文本转成 Markdown。 总结这篇文章的 3 个观点。 把接口字段整理成表格。这些任务直接提示词就够了。另外涉及权限、金额、生产数据、上线决策的任务也不能让 AI 自动循环到底。比如自动决定是否上线。 自动修改生产数据。 自动重放支付接口。 自动删除失败断言。这些场景必须有人介入。Loop 工程不是为了让 AI 无人驾驶而是让 AI 在可控范围内多做几步。Human-in-the-loop 很重要Loop 工程听起来很自动化但测试和质量场景里不能完全交给 AI 决策。更合理的做法是 Human-in-the-loop。AI 负责执行、整理和提出建议。 人负责判断和拍板。比如 Bug 要不要卡上线、金额差异能不能接受、规则到底以产品还是后端为准这些都需要人判断。AI 可以进入循环。人要守住边界。一个实用模板如果想把一个测试任务改造成 Loop可以按这个模板写任务目标 [说明最终要完成什么] 输入材料 [需求、代码、日志、截图、接口返回等] 工具权限 [AI 可以读取什么、修改什么、运行什么] 执行步骤 1. 先分析背景 2. 再执行任务 3. 根据结果自查 4. 如果发现问题修正后再执行 5. 达到停止条件后输出结果 检查标准 1. 结果是否符合业务规则 2. 是否有验证方式 3. 是否覆盖异常场景 4. 是否需要人工确认 停止条件 1. 成功完成任务 2. 连续失败 N 次 3. 缺少关键信息 4. 涉及业务判断 5. 工具或环境不可用 输出格式 [按团队需要固定格式]这个模板不复杂但能让 AI 从“一次性回答”变成“按流程做事”。常见误区第一个误区是把 Loop 写成无限重试。AI 不是越多轮越好。没有检查标准和停止条件只会浪费时间和 token。第二个误区是只让 AI 自我检查。AI 自查有用但不能替代测试结果、日志、接口返回和人工评审。Loop 里的反馈信号越真实结果越可靠。第三个误区是让 AI 为了通过测试而修改目标。比如自动化失败后AI 把断言删了脚本确实绿了但质量也没了。第四个误区是没有记录过程。一个好的 Loop应该能留下过程记录改了什么、为什么改、哪一轮失败、最终怎么通过。否则出了问题很难追溯。最后总结Loop 工程不是新的提示词技巧。它是一种面向 AI Agent 的任务闭环设计方法。提示词解决的是这一步怎么问。Loop 工程解决的是这件事怎么持续做完、做对、做可控。在测试场景里Loop 工程可以帮我们把需求分析、用例评审、自动化修复、失败归因这些任务变成可重复的流程。但最终质量不能只交给 AI。AI 可以进入循环人要守住边界。