不讲大趋势。
也不打算下什么“终局结论”。
我只是想把自己最近一段时间的实践，做一次阶段性整理。
看了不少文章，也和一些同行聊过。
信息很多，观点也很激烈。
但落到每天要做的测试工作上，真正有用的，往往不是最响亮的观点，而是能跑通的办法。
先跑通一个小闭环，再谈更大的方法论。
我感受到的三个变化
1）测试对象在变
以前我们测的大多数系统，逻辑是确定的。
输入 A，理论上就该输出 B。
现在接触到一些带 AI 能力的功能后，明显不一样了。
同样的问题，模型可能给出不同表达。
它不一定错，但你很难像过去那样，用“唯一正确答案”去判断。
这就逼着我们从“校对结果”转向“定义可接受范围”。
2）工作方式在变
以前很多时间花在重复动作上：
- 整理测试点
- 补基础用例
- 拼测试数据
- 对日志做初步归类
现在这些环节，AI 可以明显加速。
它未必一次给你最好的答案。
但它能很快给你一个“可编辑的初稿”。
好处也很直接：
你终于能把更多精力放在判断和取舍上，而不是机械整理。
3）协作节奏在变
研发提速之后，测试最容易被动。
以前一周一个节奏，你还有时间慢慢磨。
现在需求、代码、联调都在提速，测试窗口被压缩得很明显。
如果还用原来的方式做事，最先卡住的就是测试环节。
这不是谁的问题。
是节奏变了，工作方式也必须跟着变。
我做过的几次小尝试
我没做什么很“重”的 AI 改造。
基本都是挑低风险的地方先试，能跑通再往前走。
尝试一：AI 辅助整理测试点
我会先把需求核心流程、边界条件、异常路径丢给 AI，让它先发散。
然后我再做两轮筛选：
- 删掉泛泛而谈、没有场景支撑的点
- 补上业务里真正高风险的链路
结果是：前面那轮发散明显快了。
但“哪些值得测”，仍然要靠人来定。
尝试二：AI 生成用例初版
我让 AI 先出一个结构化用例骨架。
它在主流程覆盖上通常还行。
但在这些地方经常不够：
- 状态切换时机
- 跨系统联动
- 历史兼容逻辑
- 线上真实脏数据
所以我的做法是：
先让 AI 搭出 60% 的骨架，剩下最关键的 40% 还是我自己补。
这个比例比“全手写”更省时，也比“全自动”更稳。
尝试三：AI 参与回归前检查
回归前，我会让 AI 帮我先过一遍：
- 变更点清单
- 可能受影响模块
- 历史高频问题模式
它很适合做“提醒器”。
尤其在版本节奏快的时候，能减少遗漏。
但最终是否放行，结论我不会直接交给 AI。
因为放行是风险决策，不是文本生成。
我目前的看法：AI 提效很明显，但质量责任不会自动转移
这段时间最直观的感受其实很简单：
AI 可以帮你更快开始。
但不能替你承担后果。
它能提高效率。
不代表它自动提高质量。
测试工作的核心价值，反而变得更清晰了：
- 你能不能理解真实场景
- 你能不能识别关键风险
- 你能不能在时间压力下做出合理取舍
这些能力，短期内都很难被一键替代。
AI 可以给答案。
但“这个答案能不能上线”，最后还是人的责任。
接下来我准备怎么做
我给自己定了三个更务实的方向。
1）固定一个可复用流程
不追“最新最热”，先把自己常用的流程跑稳。
比如：需求理解 → 测试点发散 → 用例初版 → 人工补强 → 回归检查。
流程稳定了，效率才会稳定。
2）每周沉淀一个小模板
比如：
- 评审问题清单
- 用例补全检查表
- 回归前风险核对表
模板越具体，越容易复用。
3）持续记录“有效”和“无效”
不是所有 AI 用法都值得长期保留。
我会把有效方法留下，把不稳定方法标记出来。
这比盲目堆工具更重要。
最后
这篇文章当然不是定论。
更像是我给自己做的一次阶段性记录。
AI 和测试这件事，变化还会继续。
但对我来说，有一条原则越来越明确：
先把可执行的方法跑通。
然后再慢慢扩展边界。
如果你也在做类似尝试，欢迎交流你的做法。
我也想看看，不同团队在真实项目里，是怎么把这件事落地的。
部分信息可能已经过时