企业官网建设流程全解析

原创内容，未获授权禁止转载、转发、抄袭。

现在很多人用 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 可能会一直改、一直试、一直消耗 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 可以进入循环，人要守住边界。