我做了一个 AI Native 测试产品：Scout

这是一个标准版本。
你可以基于它，捏出更适合自己公司的测试分身。

大家好，最近我做了一个小产品，叫 Scout。

它是一个面向测试场景的 AI Native 测试产品，目前已经开源（地址放在最下方），也欢迎大家体验、提建议，或者基于它做出更适合自己团队的版本。

---

为什么做 Scout？

做 Scout 的起点其实很简单：

我一直觉得，测试工具不应该只是一个 “能用的后台页面” 或者 “提效脚本集合”。

测试工作本身并不机械。

我们每天面对的不是标准答案，而是：

• 模糊需求
• 缺失文档
• 频繁变更
• 复杂链路
• 历史包袱
• 风险判断
• 以及大量只能靠经验慢慢拆出来的问题

所以我想做一个更像 测试搭档 的东西。

不是只给你一个按钮，让 AI 一次性吐出一堆文本；
而是希望它成为一个更自然的测试工作入口。

你可以把需求文本、文档链接、Figma 链接、PDF、Word、图片，甚至一些还没完全组织好的想法丢给它。Scout 会先尝试理解你给它的上下文，再把测试思路、风险点和可执行内容继续往下展开。

打开 Scout，你看到的不是一个复杂后台，而是一个很简单的入口：

• 生成用例
• 需求分析
• 自动测试
• Bug 回归
• 测试报告

它被做成开源标准版，不是因为我觉得一套产品可以解决所有公司的测试问题。

恰恰相反。

我觉得测试工具真正落地，一定会高度依赖每个公司的业务系统、权限规则、账号体系、测试环境、用例规范和报告格式。

所以 Scout 更像是一个可以继续生长的基础版本。

你可以直接体验它，也可以基于它，捏出属于自己公司的 Scout。

Scout 的大脑

让测试经验不是一次性消耗品

Scout 里有一个我很在意的设计：Scout 的大脑。

你可以从主页头像进入它的大脑，看到 Scout 在使用过程中沉淀下来的知识碎片、经验标签和关系图谱。

这不是一个单独拿来展示的 “知识库页面”。
它是贯穿整个产品的底层能力。

当你生成用例时，它可以参考过往的测试经验。
当你做需求分析时，它可以记住某些业务系统里的特殊规则。
当你做自动测试时，它可以知道一些环境前提，比如：

• 配置权限要用管理员账号
• 测试环境登录要走 SSO
• 某个系统需要先切到指定角色的账号
• 某个页面保存后需要刷新才会生效
• 某类优惠券不能和店铺券叠加

当你做 Bug 回归或测试报告时，它也可以把之前沉淀过的风险、规则和业务上下文重新带回来。

我希望 Scout 不是一个每次打开都从零开始的 AI 工具。

它应该在使用中慢慢长出自己的上下文：

• 知道你测过什么
• 知道哪些规则反复出现
• 知道哪些坑以前踩过
• 知道一个测试场景背后还有哪些关联知识

这也是我说它是 AI Native 测试产品的原因。

AI Native 对我来说，不是把 LLM 接进一个测试平台里，也不是在每个按钮后面放一个 prompt。

而是产品形态本身就围绕 AI 的理解、记忆、执行和反馈来设计。

Scout 的大脑也不是为了让所有团队共用同一套知识。

恰恰相反，我觉得每个团队都应该有自己的测试大脑。

因为真正影响测试质量的，往往不是那些通用测试方法，而是藏在团队日常里的具体经验：

• 某个系统必须用管理员账号配置权限
• 某个测试环境登录要走 SSO
• 某个历史接口经常出现状态不同步
• 某个后台操作会影响前台展示状态
• 某个业务规则需求里没写，但测试同学都知道它很重要

这些东西很碎，但非常有价值。

我希望 Scout 提供的是一个标准底座，让这些碎片可以被沉淀、被召回、被继续用于生成用例、需求分析、自动测试、Bug 回归和测试报告。

---

1. 生成用例

从模糊需求到结构化测试思路

这是 Scout 现在最核心的能力之一。

你可以直接粘贴需求文本，或者上传 PDF、Word、图片等资料。Scout 会尝试从这些信息里识别功能点、业务流程、边界条件、异常路径和潜在风险，然后生成结构化的测试用例。

这里我不太想把它做成 “AI 帮我写几条用例” 的感觉。

因为真实测试里，最难的常常不是写，而是把需求背后的分支拆出来。

比如一个 “电商退款系统” 的需求，表面上可能只是：

• 用户发起退款
• 商家审核
• 平台退款到账

但真正做测试时，我们会关心：

• 用户取消订单后还能不能退款？
• 部分发货、部分退款怎么算？
• 优惠券、积分、余额、第三方支付的退款顺序是什么？
• 商家拒绝后，用户再次申请会进入什么状态？
• 退款中订单被后台人工改状态会不会出现脏数据？
• 用户端、商家端、管理后台看到的退款状态是否一致？

Scout 在生成用例时，不是只生成 “正常退款、失败退款、异常退款” 这种很泛的内容，而是会尽量把这些状态、角色、金额、流程分支拆开，让你能继续判断哪些要补测，哪些要找产品确认。

实现上，我现在会让它先做一层信息结构化：

先识别需求里的对象、角色、流程、状态、规则，再进入用例生成。

同时，Scout 的大脑也会参与进来。

如果它之前已经沉淀过类似的测试规则，比如：

• 店铺券和平台券的退回规则不同
• 订单叠加优惠后要额外关注金额分摊

这些经验就不应该只停留在某一次生成结果里，而应该能在后续类似需求中被重新唤起。

这对你有什么用？

很多公司的测试用例规范、业务风险偏好、场景覆盖标准都不一样。

你可以基于 Scout 的标准版，接入自己团队的用例模板、业务规则和历史经验，让它生成更像你们公司测试同学会写的用例。

---

2. 需求分析

先读懂需求，再进入测试设计

很多时候，测试不是不会写用例，而是前置信息太散了。

需求文档在一个地方，交互稿在另一个地方，补充说明在群聊里，技术实现又写在另一份文档里。测试同学真正花时间的地方，常常不是 “写”，而是先把这些信息拼起来。

所以 Scout 里也放了「需求分析」这个入口。

它更偏向帮你梳理：

• 这个需求到底想解决什么问题
• 涉及哪些用户角色
• 核心业务流程是什么
• 页面、状态、数据之间有什么关系
• 哪些地方存在歧义
• 哪些信息缺失会影响测试设计
• 哪些风险需要提前拉齐

比如一个 “权限管理系统” 的需求，看起来可能只是新增角色、配置权限、给用户授权。

但测试时很容易发现，真正复杂的地方不在新增按钮，而在：

• 权限继承
• 权限回收
• 组织调整
• 历史数据兼容
• 超级管理员边界
• 越权访问
• 接口绕过

Scout 会尽量先把需求里的角色、资源、动作、权限范围拆出来，再提示哪些地方需要确认。

比如：

• 角色删除后，已授权用户怎么办？
• 权限被回收后，已打开页面是否还能继续操作？
• 前端隐藏按钮后，接口是否仍然需要鉴权？
• 跨部门用户能否看到不属于自己的数据？
• 管理员是否能给自己提升权限？

这些问题不一定都能从需求文档里直接读出来，但测试应该想到。

实现上，这部分我更关注的是 “需求理解” 而不是 “立刻产出”。

我希望 AI 先把需求拆成一张可讨论的结构：

角色、模块、流程、状态、风险、待确认问题。

Scout 的大脑在这里也很重要。

很多需求里的关键信息，其实不是这一次文档里写出来的，而是散落在历史经验里。

比如：

• 某个系统的权限配置必须用管理员账号
• 测试环境登录需要走 SSO
• 某类店铺券有固定的使用限制
• 某个后台操作会影响前台展示状态

这些信息如果每次都靠测试同学重新提醒 AI，那 AI 工具就还是很笨。

我希望 Scout 能把这些碎片慢慢沉淀下来，在下次需求分析时主动带回来。

这对你有什么用？

你可以把自己公司的 PRD 模板、评审关注点、历史踩坑点、业务术语和技术约束放进来，让 Scout 不只是 “读懂一段文字”，而是逐渐读懂你们团队的测试语境。

---

3. 自动测试

基于 Pi，让 AI 尝试像人一样操作系统

Scout 里也放了「自动测试」方向。

我对这个方向的理解，不太是传统意义上的 “把测试用例翻译成自动化脚本”。

传统自动化很强，但它往往依赖比较固定的页面结构、选择器和维护成本。

而我更想探索的是另一种方式：

能不能让 AI 根据测试目标，像一个真实测试同学一样去理解页面、点击按钮、填写表单、观察结果，并判断是否通过？

比如在一个后台管理系统里，测试目标不是：

点击 #submit-btn
输入 xxx
断言页面出现 success

而是：

进入权限配置页面，创建一个只拥有查看权限的角色，
把它分配给测试账号，
然后验证这个账号可以查看列表，
但不能新增、编辑、删除数据。

这里面的关键不是某一个 selector，而是 AI 能不能理解测试目标、页面语义和操作路径。

它需要知道什么是角色，什么是权限，什么是只读，什么是越权。
它也需要在页面变化时，能像人一样重新观察，而不是因为按钮位置变了就完全失效。

目前 Scout 的自动测试能力已经基于 Pi 跑起来了。

我的理解里，Pi 更适合作为这个方向的执行层：它不是把用例硬翻译成脚本，而是让 Agent 根据测试目标去观察页面、规划动作、执行操作，并根据结果继续判断下一步。

大概的思路是：

1. 测试目标输入进来后，Agent 会拆解任务
2. 执行层会完成点击、输入、跳转、截图等动作
3. 执行过程中，Agent 会持续观察页面状态，再决定下一步怎么做
4. 最后根据目标和页面反馈，判断测试是否通过

这里 Scout 的大脑会承担一部分 “测试前置经验” 的角色。

比如：

• 配权限要用管理员账号
• 测试环境登录要走 SSO
• 某个系统要先切换到指定组织
• 这个页面的保存按钮有时候在抽屉底部
• 某类配置保存后，需要刷新页面才会生效

这些经验对于人类测试同学来说很自然，但对 AI 来说，如果没有记忆，它每次都会重新犯一遍傻。

所以我希望自动测试不只是让 Agent 会点页面，而是让它慢慢积累 “怎么在这个系统里完成测试” 的经验。

在我自己验证过的一些后台系统和 AI 产品场景里，效果还不错，也能看到它和传统脚本自动化不太一样的价值：

它不是死盯着某个 selector，而是会尝试理解 “我要验证什么”。

但我不想把它包装成 “已经适用于所有测试领域” 的成熟方案。

不同业务系统的复杂度差异很大：

• 有些是标准 Web 表单
• 有些是复杂后台
• 有些是强权限系统
• 有些是 Canvas / 低代码 / 白板类界面
• 有些还涉及多端、多账号、多数据状态

AI 在这些场景里的表现，肯定不是同一个难度。

所以这个方向我更希望和大家一起探索：

• 哪些测试场景真的适合交给 AI 来跑？
• 哪些场景仍然更适合传统自动化？
• AI 自动测试需要什么样的用例描述、环境准备和结果判定？
• 它到底应该成为测试同学的执行助手，还是未来可以承担一部分更完整的回归任务？

这对你有什么用？

你可以不完全照搬 Scout 的执行方式，但可以基于这个标准版去改：

• 接你们自己的登录方式
• 接你们自己的账号体系
• 接你们自己的测试环境
• 接你们自己的数据构造方式
• 接你们自己的结果断言方式
• 接你们系统里最常见的操作路径

---

4. Bug 回归

不只是验证修复，而是顺着 Bug 找风险

Bug 回归也是 Scout 想覆盖的场景之一。

很多 Bug 的问题不在于 “有没有修”，而在于：

• 这个 Bug 背后的原因是什么？
• 它影响了哪些相关链路？
• 修复后需要回归哪些场景？
• 有没有类似功能也可能存在同类问题？
• 这个问题是否暴露了需求、开发、测试协作中的某个信息断点？

比如一个 Bug 是：

用户退款成功后，订单状态仍然显示为 “待发货”。

如果只做最简单的回归，可能就是重新退款一次，看状态有没有变对。

但真实测试里，我们还会继续追问：

• 是订单状态没有更新，还是退款状态没有同步？
• 是前端展示错了，还是后端状态机错了？
• 如果是部分退款，订单状态应该怎么显示？
• 如果退款失败后重试，状态会不会卡住？
• 商家端、用户端、管理后台看到的状态是否一致？
• 消息通知、账务流水、售后记录是否同步更新？

所以我希望 Scout 的 Bug 回归不只是 “根据 Bug 描述生成几条回归用例”。

更理想的状态是，它能帮测试同学把 Bug 当成一个线索继续往外扩展：

• 从单点问题，扩展到相关模块
• 从修复验证，扩展到风险复盘
• 从一次回归，沉淀成后续可复用的测试经验

实现上，这部分我会让 AI 不只读取 Bug 标题和描述，而是尽量提取几个关键信息：

• 触发条件是什么
• 错误表现是什么
• 影响对象是什么
• 可能涉及哪些状态或链路
• 修复后应该回归哪些直接场景和关联场景

而 Scout 的大脑会让这些 Bug 不只是一次性的输入。

如果一个系统反复出现状态不同步、权限绕过、缓存未刷新、消息延迟这类问题，它们应该变成后续测试里的经验提醒。

这对你有什么用？

很多公司的 Bug 不是缺少记录，而是缺少从 Bug 到风险经验的沉淀。

Scout 的标准版可以作为一个起点，让你们把常见 Bug 类型、回归策略、历史高风险模块慢慢沉淀下来。

---

5. 测试报告

让测试输出更有结构，也更有判断

Scout 里还有一个「测试报告」方向。

我一直觉得，测试报告不应该只是：

测了多少条，通过多少条，失败多少条。

这些信息当然有用，但它们不一定能帮助团队做判断。

真正有价值的测试报告，应该能回答：

• 当前质量状态到底怎么样？
• 哪些风险已经被验证过？
• 哪些风险还没有被覆盖？
• 哪些问题会影响上线判断？
• 哪些模块需要产品、开发、测试进一步对齐？
• 这次测试暴露了什么协作或流程问题？

比如一个版本测试结束后，如果报告里只写：

执行用例 120 条
通过 113 条
失败 7 条
遗留 Bug 3 个

这个信息是完整的，但不够有判断。

更有价值的报告可能会补充：

• 退款主链路已覆盖，核心流程风险较低
• 权限相关场景仍有 2 个遗留问题，涉及后台人工操作链路，建议上线前确认是否有灰度或兜底方案
• 本轮测试发现多端状态展示不一致问题较多，后续类似需求建议提前明确状态机和展示口径
• 当前未充分覆盖高并发退款、第三方支付回调延迟、历史订单兼容等场景，需要根据上线策略判断是否补测

所以测试报告这个功能，我希望它能从测试过程、用例结果、Bug 情况、风险点中，生成一份更适合团队沟通的总结。

实现上，我不太希望它只是把数据重新排版。

我更希望它能把测试信息转成 团队能决策的信息。

比如：

• 哪些模块风险更高
• 哪些问题影响上线
• 哪些场景没有覆盖
• 哪些结论需要产品或开发确认
• 哪些经验应该沉淀到下一轮测试里

Scout 的大脑在这里也会继续发挥作用。

测试报告不应该只总结 “这一次发生了什么”，也应该能把这一次的风险、规则和经验沉淀下来，成为下一次测试的上下文。

这对你有什么用？

每个团队看测试报告的方式都不一样：

• 有的关注上线风险
• 有的关注缺陷趋势
• 有的关注覆盖率
• 有的关注项目节奏
• 有的关注遗留问题的影响面

你可以基于 Scout 的标准版，把报告格式改成你们团队真正会看的样子。

---

为什么我想把它做成 “产品”，而不只是工具？

过去很多测试工具是功能导向的：

能生成、能执行、能导出、能统计，就算完成了。

但我越来越觉得，AI 时代的测试工具，可能需要重新设计。

因为 AI 带来的变化不只是 “自动生成更多东西”，而是测试工作的入口、流程和表达方式都可能变化。

一个好的测试产品，应该不仅仅是：

你给我输入，我给你输出。

它应该更像：

你把一个还没完全想清楚的问题交给我，我们一起把它拆清楚。

这也是为什么我希望 Scout 不是一个功能堆叠的后台工具，而是一个有产品意识的测试入口。

它应该有清晰的场景。
有自然的交互。
有可以被理解的输出。
也应该有一点点让人愿意打开它、使用它、继续打磨它的感觉。

更重要的是，它应该会成长。

如果一个 AI 测试工具每次都从零开始，每次都需要你重新解释业务背景、环境限制、账号规则、历史坑点，那它其实还没有真正进入测试工作流。

我希望 Scout 的形态更 AI Native 一点：

• 能理解任务
• 能执行动作
• 能沉淀经验
• 能在后续任务里重新调用这些经验

好的工具不是让人感觉自己在操作机器，而是让人感觉自己的能力被延展了。

我希望 Scout 对测试同学来说，也能慢慢接近这种感觉。

---

现在的状态

Scout 目前已经开源。

它是一个 更面向测试社区里的 标准版本，而不是一个试图覆盖所有公司的万能测试平台。

因为测试场景太依赖具体业务了。

不同公司的：

• 系统形态不一样
• 权限体系不一样
• 账号规则不一样
• 测试环境不一样
• Bug 流转方式不一样
• 用例规范、报告格式、上线标准也不一样

所以 Scout 不应该假装自己能用一套固定答案解决所有问题。

我更希望它提供的是一个可以继续生长的基础形态：

• 一个简单的测试工作入口
• 一组围绕测试场景设计的 AI 能力
• 一套可以沉淀测试经验的大脑机制
• 一个基于 Pi 的自动测试探索方向
• 以及一些可以被替换、调整、扩展的产品和工程结构

大家可以基于这个标准版本，去捏出更适合自己公司的版本。

比如：

• 把你们公司的需求模板接进去
• 把你们自己的测试用例规范接进去
• 把你们常见的业务规则沉淀进 Scout 的大脑
• 把你们的账号、权限、环境、SSO、数据构造经验变成 Agent 可以调用的上下文
• 把测试报告调整成你们团队真正会看的格式
• 把自动测试能力改造成更适合你们系统形态的执行方式

它可以是：

• 电商公司的 Scout
• 游戏公司的 Scout
• 企业后台系统的 Scout
• ToB SaaS 团队的 Scout
• 也可以是任何一个测试团队自己的 AI 测试分身

我觉得这也是开源这件事最有价值的地方。

不是让大家都使用同一个 “标准答案”，而是给大家一个可以开始动手的测试产品底座。

---

欢迎一起捏出更多版本

Scout 现在还不是一个成熟产品，肯定有很多粗糙的地方：

• 功能还需要更多真实场景验证
• 输出质量还需要继续打磨
• 自动测试能力在不同系统里的表现也需要更多样本
• 大脑里的知识沉淀、召回和图谱关系也还会继续迭代
• 很多交互和产品体验也还有很大优化空间

但我想先把它发出来。

一方面，是欢迎大家体验。

如果它能帮你完成一点点测试设计、需求分析、Bug 回归、自动测试或报告整理，那就已经很开心了。

另一方面，也想邀请对这个方向感兴趣的同学一起贡献。

不管你是测试、开发、产品，还是对 AI 测试工具感兴趣，都欢迎来看看、提 issue、提建议，或者一起共建。

也非常欢迎大家贡献：

• 真实测试场景
• 更复杂的需求样例
• 你们平时最头疼的测试用例设计问题
• Bug 回归里的典型风险
• 不同业务系统里的测试模板
• 自动测试方向的想法和实现
• 关于 Scout 大脑如何沉淀和调用经验的想法
• 以及任何关于产品体验、交互、UI、文案的建议

我更想收集真实测试场景，而不只是 star。

哪怕只是丢给我一个你觉得 AI 一定会翻车的需求，也很有价值。

因为一个测试产品能不能成立，最终不是看它 demo 多漂亮，而是看它能不能进入真实测试工作流，解决真实测试同学的问题。

最后想说：

测试不只是质量保障的最后一道门。
测试也可以是理解产品、发现风险、推动系统变好的创造性工作。

所以测试工具当然也值得被做得更好用、更好看，也更像一个真正的产品。

欢迎大家体验 Scout。
也欢迎基于它，捏出更适合你们团队的版本。
地址：https://github.com/fishboot296/scout
mac 客户端：https://pan.quark.cn/s/c0bb3edfa948 提取码：NCVk