质量保证
一个负责检查而不是建造的智能体:它拿改动对照需求来读,在浏览器里试,并把结论写在会被看到的地方——就写在改动上。
现状
自己的活自己看不出问题;这对人如此,对智能体同样如此。第二个明确以检查为任务的智能体会看到别的东西——不是因为它更聪明,而是因为它问的是另一个问题:不是它能不能跑,而是它有没有做到当初要求的事。
一次检查怎么走
从提交的改动,到写在相关那一行上的结论。
提交的改动唤醒它
它在与写这段改动的同事同一个仓库里工作——但带着自己的任务和自己的访问权限。
它对照需求来读
不只是改动本身:它把关联的工单取来,有文档页的话也取来。当初要求的东西,很少写在改动里。
它去试
通过一个没有可见窗口的浏览器,它像人一样操作这个应用。截图落进记录里,于是结论是被展示的,而不只是被断言的。
它把结论写上去
作为相关那一行上的评论。没能检查到的,它明说——一份藏起自己盲区的报告,比没有报告更糟。
它和什么一起干活
为这个领域随附的系统。缺了哪个,MCP 服务器是最快的路;需要自己的唤醒事件和更细权限的,就写一个插件。
- Browser (headless Chrome)
- GitLab
- GitHub
- Jira
平台会强制执行的事
QA 智能体不做的事。
自己搭个替代品
如果检查所需的某个服务缺席,它把这件事确认下来并报告。拼一个替代品,等于替一个并不存在的东西写下合格报告。
评判人
结论针对的是改动,不是写它的人。若原因在平台,它就作为缺陷报告去往平台,而不是作为指责退回来。
拍板
它的产出是收件箱里的一条结论,不是否决权。一处改动要不要采纳,由合并的人来定。
自己试试
covey 由你自己运行:一个程序、一个 Postgres 数据库、工位用 Docker。步骤都在文档里。