夜雨聆风我说自己最近在用 AI 做一个开源项目。今天就不卖关子了，拿出来给大家看看。
项目叫 automated-testing。
地址在这里：
https://github.com/worldofrorrim/automated-testing
它是做什么的？
简单说，就是：
你给它一个网站，它会自己打开浏览器，自己点页面，自己跑测试，然后给你一份报告。
听起来有点像“让 AI 当测试员”。
当然，话不能说太满。它不是万能的，也不是说有了它就不需要测试工程师了。更准确地讲，它是我做给自己用的一个工具：
发版前，让 AI 先帮我把网站跑一遍。
这件事听起来不大，但对我这种经常一个人折腾项目的人来说，真的挺有用。
为什么我想做这个东西？
做过 Web 项目的人应该都有这种经历。
功能写完了，页面也能打开，自己手动点了几下，感觉没问题。
然后一上线，用户一用：
登录按钮点不了
表单提交失败
某个页面跳转错了
移动端样式乱了
改了一个地方，另一个流程坏了
这些问题不一定很难，但很烦。
更烦的是，每次发版前你都知道“应该完整测一遍”，但真要手动点完整个流程，又很耗时间。
写自动化测试当然可以。
Playwright、Selenium 这些工具都很强，但问题是：你得先写脚本。
你要告诉它：
找到用户名输入框输入账号找到密码输入框输入密码点击登录按钮等待页面跳转检查结果
页面稍微一改，选择器可能又失效了。
所以很多个人项目、小团队项目，到最后测试就变成了：
“我大概点过了，应该没事。”
但“应该没事”这四个字，大家都懂。
于是我就想，能不能做一个工具，让 AI 帮我先干一部分脏活：
打开浏览器
识别页面
尝试登录
找出页面上能交互的地方
生成一些测试步骤
自己执行
把结果记录下来
这就是 automated-testing 的起点。
它现在能做什么？
目前这个项目主要做几件事。
第一，它会真的打开浏览器。
不是简单地请求一下接口，而是用 Playwright 启动 Chromium，像正常用户一样访问页面、点击按钮、输入内容、等待跳转。
测试过程中会保存截图和录屏。
如果哪里失败了，不用只看一行报错，可以回头看它到底点到了哪一步。
第二，它会处理登录。
登录其实是自动化测试里很烦的一步。
每个网站的登录页都不太一样。有的是账号密码，有的是扫码，有的是多步表单，有的按钮文案还很奇怪。
我在项目里做了一个登录处理流程。
如果是账号密码登录，它会尝试识别输入框；如果是扫码登录，它会把二维码截图保存下来，提示你扫码，然后继续后面的流程。
这不是百分百完美，但比每次从零写登录脚本省心很多。
第三，它不是只用一个“全能 AI”乱测。
我给它拆了几个测试角色。
比如：
有的负责到处探索页面，看看哪里可能出问题
有的专门看 UI 和交互
有的关注安全风险
有的关注性能
有的关注完整业务流程
有的关注无障碍体验
你可以把它理解成：不是一个人干所有活，而是让几个不同方向的“测试搭子”一起看这个网站。
比如我只想快速检查一下页面，就跑 UI 和探索测试。
如果我要发一个比较重要的版本，就把安全、性能、业务流程也一起跑。
我自己最在意的，不是“AI 很酷”
说实话，现在只要一说 AI，大家已经有点疲劳了。
很多东西听起来很厉害，真正用起来不一定顺手。
所以我做这个项目的时候，最关心的不是“看起来多智能”，而是几个很实际的问题：
第一，失败的时候能不能看懂？
测试失败不可怕，可怕的是你不知道它为什么失败。
所以我加了报告、截图、录屏和更清楚的错误分类。
至少出问题的时候，你能知道是页面元素没找到、AI 服务出错，还是验证逻辑没通过。
第二，页面改了以后能不能少崩一点？
自动化测试最常见的问题就是选择器失效。
前端改了 class 名，测试脚本就找不到按钮了。
所以我加了选择器验证和重试机制。
它会在操作前先检查元素能不能用；不行的话，再尝试备选方案。
这不能解决所有问题，但能减少很多低级失败。
第三，新人能不能跑起来？
很多开源项目最大的问题不是代码不好，而是第一次使用太痛苦。
所以这次我花了不少时间整理文档、配置文件、示例和 GitHub Actions。
我希望别人打开这个仓库，不需要猜半天：
怎么安装
配什么环境变量
怎么运行
报告在哪里
出问题去哪看
这些东西都应该尽量写清楚。
技术上其实不复杂
这个项目没有用什么神秘技术。
核心就是几块：
Node.js 作为运行环境
Playwright 负责浏览器自动化
DeepSeek API 负责页面分析和测试生成
agency-agents-zh 提供测试代理思路
Jest 做单元测试
GitHub Actions 做基础 CI
项目结构也比较直白：
src/ agents/ AI 代理和 AI 客户端 core/ 登录、页面分析、测试执行、重试、调试 utils/ 选择器、日志等工具 errors/ 错误类型 index.js 主入口examples/ 示例docs/ 文档tests/ 单元测试.github/ GitHub Actions 和开源协作配置
我比较喜欢这种结构。
不花哨，但每块东西放在哪里基本能看懂。
后面如果想扩展，也不会太难。
怎么试一下？
如果你想自己跑一遍，可以这样开始。
先克隆项目：
git clone https://github.com/worldofrorrim/automated-testing.gitcd automated-testing
安装依赖：
npm run setup然后复制一份环境变量文件：
cp .env.example .env在 .env 里填上这些：
DEEPSEEK_API_KEY=你的 DeepSeek API KeyTARGET_URL=你要测试的网站地址LOGIN_USERNAME=登录账号LOGIN_PASSWORD=登录密码
如果你测试的是公开页面，不需要登录，也可以设置：
SKIP_LOGIN=true然后运行：
npm run test:e2e跑完以后，可以去这些目录看结果：
reports/ 测试报告screenshots/ 截图videos/ 录屏
如果你只是想看看增强功能演示，也可以跑：
npm run demo它适合谁？
我觉得它比较适合这几类人。
独立开发者。
一个人做项目，经常是什么都要自己来。上线前让工具帮你多跑一遍，至少心里更有底。
小团队。
团队还没有完整测试体系，但又希望发版前多一层检查，可以先用它做基础兜底。
测试工程师。
它不是替代测试工程师的东西。
我更愿意把它看成一个辅助工具：把重复探索、基础检查、截图报告这些事情先交给 AI，人去做更复杂的判断。
想学 AI 工程化的人。
这个项目也可以当成一个例子看：
AI 不只是聊天框，它可以接浏览器、接测试框架、接日志、接 CI，最后变成一个真实可运行的工具。
开源前我又整理了一轮
既然要放到 GitHub 上，我不想只是把代码一扔。
这次我专门做了一轮整理：
补了 README
补了贡献指南
补了安全策略
加了行为准则
加了 issue 模板和 PR 模板
配了 CI
配了手动触发的 E2E 测试 workflow
补了一些单元测试
清理了本地运行产物和敏感文件
把文档里旧的配置说明统一了一遍
这些事情不一定“酷”，但我觉得很重要。
因为一个开源项目不是只给作者自己看的。
别人能不能看懂、能不能跑起来、出了问题能不能知道该去哪里找答案，这些都决定了它有没有机会被真正使用。
最后说几句
automated-testing 现在已经开源了。
项目地址：
https://github.com/worldofrorrim/automated-testing
它还不是一个完美项目，后面肯定还有很多地方要继续打磨。
但我挺开心的一点是，它已经从一个“我脑子里的想法”，变成了一个别人可以下载、运行、修改、反馈的东西。
这就是我理解的作品集。
不是只截图展示，也不是只写一句“我会什么技术”，而是把一个真实问题拿出来，做一个真实工具，再慢慢把它变好。
如果你也在做 Web 项目，或者对 AI 自动化测试感兴趣，可以去 GitHub 看看。
觉得有用的话，欢迎 Star、Fork、提 issue。
也欢迎在评论区聊聊：
如果让 AI 帮你测试一个网站，你最希望它先帮你测什么？
AI 时代，光讨论它会替代谁没什么意思。
能不能把它变成自己的工具，可能更重要。