发帖
雷达卡
做了五年软件功能测试，我算是团队里比较早把AI工具带进日常工作的人。最开始接触AI的想法特别朴素：就是帮我省下写报告、整理缺陷的重复功夫。
那时候的用法很简单，版本测试结束后，把零散的测试记录、缺陷清单丢给大模型，让它润色成格式规范的测试报告；把一条条口语化的bug描述，整理成统一的缺陷标题和复现步骤。那段时间确实省了不少文字工作，我一度以为，这就是AI给测试岗位提效的全部了。慢慢用得熟练了，我开始试着把更多测试场景交给AI。比如版本迭代后产生的几百条服务日志，让AI按异常类型、关联模块做归类统计，不用再逐条人工排查；需求评审结束，拿着需求文档让AI拆解测试点，补充正向、反向和边界场景；两个版本的测试结果做对比，让AI梳理差异项、新增缺陷和覆盖率变化；到了月底，让AI汇总当月缺陷趋势，整理高频问题和高风险模块。
这些用法让我的工作效率又上了一个台阶，但与此同时，也开始遇到很多不稳定的情况。
比如日志异常归类时，AI会按照字面意思划分类别，不符合我们团队的业务模块划分逻辑；分析异常根因时，它会给出看起来逻辑通顺，但不符合实际服务调用链路的推断；如果我只粘贴了部分日志、没补充业务背景，输出的总结就会遗漏关键的上下文信息，甚至出现偏差。
最开始我总觉得是工具不够好用，换了好几个大模型尝试，情况时好时坏。后来慢慢反应过来，问题的核心不在工具本身，而在我的使用方式——我始终是把原始内容直接丢给AI，既没有提前筛选信息、补充业务上下文，也没有明确约束输出规则，更没有固定的核验标准，输出结果自然不稳定。
那时候我才意识到，对于测试岗位来说，真正需要补的AI能力，从来不是“会不会让AI写报告”，而是三层更底层的能力。
第一层是AI交互能力，也就是怎么设计提示词、怎么筛选输入信息、怎么补充业务背景，让AI准确理解工作需求；
第二层是结果核验能力，清楚AI在哪些场景容易出错、哪些信息容易遗漏，建立快速校验的逻辑，不盲目依赖输出结果；
第三层是AI工作流能力，把零散的AI操作串联起来，形成固定的处理流程，比如从日志导入、异常归类到缺陷摘要、报告初稿，一步步连贯执行，而不是每次都从零开始操作。
想明白这点之后，我就不再零散地刷网上的技巧教程，而是打算找一套系统化的通用AI应用框架，把零散的经验梳理成完整的能力体系。了解下来，CAIE人工智能工程师认证的Level I比较贴合我的需求。
它是CAIE人工智能研究院发证的市场职业技能等级认证，一级考试时长为90分钟。学习内容围绕通用AI应用能力展开，覆盖提示词体系设计、上下文管理、结构化输出、多工具协同、AI业务工作流搭建这些模块，刚好对应我想要补齐的三层能力。
和很多侧重特定工具、特定厂商的认证不同，它不绑定单一产品体系，更关注怎么综合运用AI工具解决实际业务问题，这一点很贴合测试岗位多变的工作场景。
当然，和其他所有职业能力认证一样，CAIE的作用主要是提供系统学习路径和阶段性能力证明，无法承诺持证后直接就业、升职或加薪，效果仍取决于能不能把相关知识转化为具体的岗位案例、工作流程和实际成果。对我来说，它更像一个梳理能力的框架，帮我把之前零散的使用经验，归整成了一套可复用、可优化的工作方法。
到现在我用AI做测试工作已经快两年，越发觉得“自动写测试报告”真的只是最入门的用法。AI给测试岗位带来的真正提效，是从“用AI做一件事”到“用AI梳理一整套流程”的升级。 对于大多数传统测试工程师来说，不用一开始就急着学算法、转开发，先把通用AI应用能力补扎实，学会和AI高效交互、做好结果核验、搭建适配自己工作的AI流程，反而能更平稳地把AI落地到日常工作里，实实在在地提升工作效率。
京公网安备 11010802022788号
