UI 自动化本质上也算是代码化的一种，selenium、playwright、agentbrowser 这些驱使的 UI 自动化，完全可以由 AI 驱动。但是关于 UI 自动化也确实存在由 AI 视觉大模型驱动的，这种极其有潜力。

        测试的每轮提效其实和整个行业的招聘动向是吻合的，功能测试->自动化测试->测试开发->AI 测试开发，这些变迁本质上就是围绕着测试的可自动化的不断进阶。因为自动化本质上代替了人工，所以能够提效，且这段变迁是不断把测试坐移的。
        因此，AI 提效的核心，持平于开发效率暴涨的核心其实就在于如何更好的让 AI 左移，以及如何让AI 更好的进行回归测试。
        而开发提效效率如此之高，关键就在于大部分的效率拔高因于代码。由此抛砖引玉，我们测试应该思考哪些测试环节可以代码化，这样代码化的测试环节才能够享受到 VibeCoding 的红利，也就是我们测试的 VibeTesting。

其实在我开发了一个智能体项目后，个人体感 token 的测试可以围绕：

1.各轮次 usage（prompt、completion、total）的 toekn 叠加是否等于可观测性，或者接近，因为大多数 agent 是支持可观测性展示 token 数的；

2.每次任务的调用是否符合预算；

3.如果是想测试可观测性在模型测的 token 计数（单一 LLM api 调用），可以采用一些具有代表性的测试样例，结合各个大模型官方的 tokenizer，并在输入测控制 max_tokens=1，直接进行 assert 断言测试。

除此之外，还有哪些角度呢？你可以提供一些思路，如果没有的话，那我认为 token 消耗值得测试的就这么多。

        不愧是啄木鸟啊！感谢指出～

        这段代码主要用来演示如何捕获 diff，触发自动化反馈，确实是只会触发在本地终端，无可争议。

        针对此，通常建议使用 Notification Hook，监听 agent_completed 事件，对接到 IM 上，文中有补充道。

落地的话，结合你们的项目与公司的方向吧。因为专门的 agent 或者是 skill 的形式，对于知识库的依赖以及架构都是不同的，前者属于专门的智能体工程范畴，后者更加灵活重点可以放在知识库的质量上。且如果现有体系属于旧工程师搭建的 GUI 的情况下，其实可以直接考虑轻量 AI 重构，那么知识库也可以作为输入的形式，符合轻量高效。

具体人力时间只能说个大概，从 4 月份开始，人力分为专项 + 专人 all in

这种情况下需要你们公司的 CLI 基础设施建设跟得上，多平台 CLI 化，对于 Agent 而言才是理想环境。

怎么开始伤春悲秋了呢，就拿前段时间大热的 DeepSeek 招聘事件，算是国内无穷趋近 AI 的业务吧。其中就有 QA 岗位：https://app.mokahr.com/social-recruitment/high-flyer/140576#/job/50733e68-4b26-4037-8b63-2ed781aa44ed

        首先针对于 PRD 和技术文档，test-runner 会基于新增功能的全新测试，其中的回归是基于 CLAUDE.md 中涉及到的 “关键风险区域” 和 “历史缺陷” 在现有的回归测试集中进行的回归。
        而且需求不断的迭代完全可以靠 AI 驱动的 case 作为回归集，并且曾经的一些 GUI 或者是已有沉淀下来的 case 早已作为养料用 AI 标准化重构了，所以早已有了一大批可以复用且适合作为回归集的 case 了。
        另外，AI 需要了解的业务逻辑都是通过沉淀的知识库的形式来解决的，我们会先让 AI 去洗现有人类沉淀的文档，并且配有专人去把控去洗，把这些都整理为知识库的形式。
        以及，AI 执行的时候，不需要 “猜” 表的关系，而是依据知识库中的明确指引去执行校验。
        AI 断言在完全的 AI 驱动的情况下，也会有断言标准知识库用于参考，并辅以 prompt 执行。

不客气，一起加油！我简单补充一下：如果 skill 需要扩容的情况下，建议拆开 skill，主 skill 包含子 skill 化，这样效果会更好一些。