北京
一位在软件工程、质量工程、自动化和交付领域干了23年多的从业者，最近把一句话摆上了台面：如果AI执行了测试，然后告诉我们它通过了，那谁来验证AI？
这个问题，是他动手做TestNeo的原因之一。测试这件事的模型，正在被彻底改写。
过去很多年，流程简单得像一条直线：人思考，人定义测试，机器执行，人评估结果。现在这条线变成了：AI思考，AI创建测试，AI执行，AI评估，AI报告——PASS。
生产力提升是真实的。对着助手说一句“给登录流程写个Playwright测试”，几秒钟就能拿到像模像样的东西：用例、代码、API检查、选择器、重试，甚至错误分析。
但生成一个测试，和证明应用能正常工作，是两回事。
再往前一步，人们开始让AI执行。不再写代码，而是直接说：“以管理员身份登录，创建一个客户，打开仪表盘，确认客户出现。”智能体能点完这条路径，看起来很棒——直到你追问一句：客户真的被创建了吗？
智能体说创建了。那依然只是一个说法。
让智能体给自己打分，问题就出在这里：
- 界面显示成功，后端其实失败了，智能体照样报PASS
- 结账“完成”，支付其实失败，页面跳转被当成了成功
- “测试通过”，智能体只是到达了某个页面，从未验证预期状态
智能体可能走了一条看起来正确的路，得出错误结论；也可能走了一条错误的路，碰巧得到正确答案。当AI从“生成东西”走向“做事”，没有独立证据的成功声明，就变成了发布风险。
他给出的链条是：声明 → 观察 → 验证 → 证据 → 学习。其中最重要的词是“验证”。没有证据的PASS，不过是另一句话而已。
验证需要上下文，不只是一条绿色进度条。一个可信的结果，除了截图和断言，还需要知道：哪些代码或PR发生了变更；产品上下文怎么说，包括流程、API、领域地图这些系统知识；这个失败以前见过没有，包括缺陷、根因分析、历史运行记录；针对当前风险，哪些检查才重要，功能、API、视觉、性能还是智能体行为；以及该记住什么，避免同一个事故再学一遍。
所以TestNeo的构建重点，不是“在浏览器里跑自然语言”这么简单。目标不是更多的结果，而是当有人问“我们该不该发布”时，你能拿得出、守得住的结果。
数量不等于信心。AI生成1000个测试，听起来很唬人——直到你发现其中很多是冗余的、薄弱的、不稳定的，或者早就过时了。更该问的是：鉴于这次改了什么，我们应该验证什么？我们有什么证据？还剩什么风险？工作重心也就从“生成测试”转向“基于风险的验证”。
智能体又把门槛抬高了一层。传统自动化里，意图基本是固定的；而一个自主智能体，可能自己选择路径、工具、重试次数，以及它是否相信自己成功了。于是需要评估的不只是应用本身，还有操作应用的AI的行为。
他们把自然语言意图带进Chrome，原因就在这里。“AI能控制浏览器”这件事已经跨过去了，真正有意思的问题是：我们怎么知道智能体完成了我们要求的事？
从一次运行到一次发布决策，中间隔着很多东西。现代发布混合了代码变更、Web、API、智能体、视觉、性能、安全信号，以及多年的运行历史。一张巨大的PASS/FAIL清单，不构成一个决策。
他梳理的路径是：改了什么 → 什么重要（上下文加风险）→ 我们验证了什么 → 记忆说以前见过什么 → 我们有什么证据 → 还剩什么风险 → 该不该发布（PASS / WARN / BLOCK）。这也是TestNeo Release Intelligence的方向：意图 → 执行 → 观察 → 验证 → 证据 → 记忆 → PR/发布门禁。
他并不认为这个问题已经解决。团队仍在实验，智能体时不时带来意外，有些检查还需要人在回路中。悬而未决的问题依然存在：在信任一个智能体之前，需要多少独立证据？当AI自己思考、自己行动、自己打分时，人必须留在哪里？
他没有最终答案。但干了二十多年这一行，他相信这一点：AI让测试变快是必然的；让结果可信到足以据此行动，才是更难的那道题。
他反复用一句话收尾：AI可以完成工作，但完成不是证明。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
