很精彩呀。同时也宣告了测试得从执行者往行业规范定义这个角色转变。类似工程师向专家的转变，同时 AI 时代以前的工程师阶梯晋升路线也将被缩短，这种缩短是不快速的递进，而是在变相的更快的筛选。有风险意识的也应该更快速的转变和思考后面要去做什么内容了。

明确测试范围，范围内测试主责，范围外测试次要。然后后续各个角色的 action 才能加强团队能力

普通人的工作上限由城市、行业决定，再就是角色职位了。

就拿近期比较火的 skills 做例子吧，就算 llm 已经被大家承认能力很强，也需要各种 skills 进行 token 压缩或者更具体更明确更效率的结果产出。我们用 AI 也只是在现有的流程工具下，增加 agent 角色的引入，它解决了一些显而易见的效率提升质量提升，但是这之后呢？挖掘额外的质量和效率依然是一个大的课题，然后重新回到 agent 角色和流程引入替换。

方案 1 适合已产品状态为基地的测试流。方案二适合以围绕产品配置的测试流。一个是静态数据，一个是动态数据。

AI 改变了问答模式，测试之家本来就是小众社区。像 CSDN,stack overflow 才是真正的寒冬，他们现在也只能靠卖数据为生，当数据被大模型完全消化完才是真的致命

估计是没发 ping pong 导致执行到这个阶段的时候被服务端关闭了。先确定一下单发是有效的那就可以排查长连接的配置问题

重点看一下工具落地环境，上层对测试的目标预期是否能支持你去做落地。人员没到 10 几个人，形成 2 级梯队的情况下，基本都是扁平化管理，2 人和 6 人没多少区别，当然会有更多调度资源，以及测开资源这确实是提升的部分。

本身这是一个循序渐进的过程，先有指标，再把不同数据纳入指标。这也是一个团队不团提升的过程。例如先 2%，但是指标数据是测试介入需求引起，下一个阶段就是需求缺陷，再下一个阶段就是所有需求。有这个过程的团队一般也是正规的公司才会有。

看到这篇分享，不禁让我想起之前看到的一篇文章。我们做自动化的终极目标是什么。如果是为了让不会代码的人通过低代码的方式完成自动化。那完成了之后呢？还是转向 coding 还是停留在这个阶段，如果是 coding 为什么一开始不就这么做。如果是为了让 AI 通过范式进行全自动化流程的设计，那么为什么一开始不这样做。我个人不反对任何形式的自动化模式，但是如果你是想推广它，那设计者应该明白，它最终的生命形态是怎么样的，即便是幻想。