写在前面
当下，AI 技术的发展速度远超我们的预期。每天醒来，都可能看到一个新的测试工具发布、一个新的框架开源、一个新的概念刷屏。信息的爆炸非但没有带来清晰和激动，反而制造了更多的焦虑：我们该学哪个工具？该跟哪个热点？该信哪个观点？
在这股汹涌的浪潮中，随波逐流或许最容易，却也最容易让人迷失。今天的热点明天就可能被遗忘，今天的工具后天就可能被替代。如果我们只是追逐浪花，就永远看不到潮水的方向。
为了不被信息吞没、不被认知过载压垮，我选择从逐浪中停下来，走上岸，并试图用自己十几年在软件质量领域的理解，和当下对 AI 的有限认知，帮助自己理清一个根本性的问题——AI 时代，软件测试何去何从。
本篇文章仅是我在当下时间节点的一次思考快照，随着 AI 时代的光速发展，这些认识也可能很快随着技术的发展、我的认知和实践的改变而发生本质的变化。
AI 时代软件测试从业者的三大命题
在我看来，AI 时代对软件测试从业者的影响大致分为三个命题：
命题一：源于 “测试对象” 的质变——如何测试 AI 软件系统
无论是大模型应用、Agent，还是各种各样智能决策平台，当被测系统本身变成了 AI 系统，当系统的核心逻辑从确定性的 “if-else” 变成了 “概率分布”，我们传统的软件测试范式还适用吗？测试的范式需要重构吗？如何重构？
命题二：源于 “生产力工具” 的质变——如何用 AI 赋能传统软件测试
当 AI 成为我们手中的工具，它能帮我们做什么？写用例、生成代码、分析日志、预测风险——这些曾经需要大量人工投入的工作，能否被 AI 自动化甚至智能化？这不是 “测试工具” 的进化，而是 “测试生产力” 的跃迁。
命题三：源于 “生产者” 的质变——用 AI 编写的软件系统如何测试
当代码本身越来越多地由 AI 生成（Claude Code、Cursor 等工具的普及），我们会面对一个怎样的系统呢？AI 生成代码和人类代码相比，错误模式是否有明显不同？AI 理解需求的方式与人类是否有明显不同？当开发速度因 AI 而指数级提升，测试能否跟上？
在这篇文章中，我将重点聚焦于前两个命题的讨论，即，如何测试 AI 软件系统以及如何用 AI 赋能传统软件测试。（我所在的公司为一家创业公司，目前还没有大力推行 AI 编程。本着没有调查和实践就没有发言权的原则，命题三目前暂不再文本中讨论。但为了概念的完整性，还是把命题三放在此处）
命题一：测试 AI 软件系统的趋势
有人会说：这不是新命题。电商的千人千面、短视频的推荐系统，不都是 AI 软件系统吗？测试也一直在做。没错！但当 AI 时代来临，这个命题的内涵还是发生了一些变化。
AI 系统的变化
在前大模型时代，虽然已有不少厂商应用自研垂类模型赋能业务，但这类实践对基础设施的要求极高：需要海量的数据积累、完善的 A/B 测试平台、顶尖的算法研发队伍。这意味着，真正能把 AI 用起来的，更多还是头部软件厂商。对于中腰部及以下的企业来说，自研 AI 的成本是不可想象的。
大模型的出现，打破了这一壁垒。突然间，大量的非软件厂商，以及腰部长尾的软件开发商，都看到了在自己业务上落地 AI 的可能。一家制造业工厂、一家医疗器械公司、一家律师事务所，都可以快速构建自己的 AI 应用。
但随之而来的，是AI 精度压力的指数级上升。
为什么？因为场景变了。过去的 AI 应用主要集中在 ToC 领域——推荐错了，用户刷走就是了；搜索结果不够准，再试一次就好，用户对 AI 的 “容错率” 相对较高。但当 AI 进入制造业、医疗、金融、法律等严肃领域时，容错率急剧下降。一个知识库 Agent 在回答 “某材料的耐温极限是多少” 时，如果给出了错误数据，对于严谨的制造业而言，后果可能是灾难性的。
这意味着，当我们讨论 “如何测试 AI 软件系统” 时，就要面对 “不同行业的 AI 应用该用什么标准测” 的场景化挑战。这是一个从 “通用测试” 到 “领域适配” 的跃迁，也是 AI 质量保障正在面对的新战场。
当然，也有例外。由于目前各行业普遍存在 “AI 焦虑”，我们确实看到一些点状应用的案例：AI 被嵌入某些重业务逻辑的平台，或者客户为了不被视为 “out” 而象征性地上线 AI 功能。这类系统的质量保障，实际上仍以传统功能测试为主，精度反而不是其当前优先追求的目标。但这种场景相对偏少。
AI 评测给软件测试带来的挑战
AI 系统的效果评测，涉及诸多环节：评测数据如何构造、条数如何确定、指标如何选择、工具如何建设。具体可见https://testerhome.com/topics/43475。但如果只能选一个最重要的，我认为是 ** 评测数据的拟真性 **。
拟真性意味着：我们需要高质量的业务数据作为评测数据。而要获得这样的数据，就必须在一定程度上懂业务——懂业务场景下用户如何使用 AI 系统，懂业务视角下什么是 “正确”（即如何确定真值）。
在我最近的一些交流中，部分 ToC 从业者甚至管理者不太理解：为什么评测数据会是难点？对于 ToC 软件来说，流量充足，通过线上回流可以获取大量评测数据；而且绝大部分 ToC 业务的专家就在公司内部，数据构建相对顺畅。
但在绝大多数 ToB 场景中，我们面临一个残酷的现实：没有评测数据。
客户采购 AI 系统，往往是因为 “自己也不知道怎么做，希望 AI 来帮忙”。但当我们需要评测数据来验证 AI 效果时，却发现客户无法提供 “标准答案”。这是一个典型的 “先有鸡还是先有蛋” 困境。
更棘手的是，即便客户愿意配合，其配合程度也往往难以支撑高质量的数据共建。数据标注需要投入人力、需要领域知识、需要时间成本——而在客户的优先级列表里，他自己的业务推进更重要。为本身只是辅助的 AI 系统进行打标，通常排得很靠后。
面对这种情况，我们只能采取务实策略：在项目初期，先基于当前理解预设可想到的场景，构建初步评测集，得出基准值后决定是否上线；上线后，通过持续验证，对比我们的预设场景与客户真实场景的差异，逐步优化评测数据和行业 know-how。
这引出一个关键问题：软件测试角色如何获取更多行业 know-how？
由于测试通常处于研发流程下游，直接接触客户的机会有限，因此需要通过方案、运营等渠道，让行业知识输入到测试环节。只有如此，软件测试才能继续发挥先验价值，在系统上线前就识别出可能的效果风险。
AI 评测是否一定要深入理解 AI 技术
先说结论：懂一些 AI 技术的基本概念是必要的，但深入理解 AI 技术对于软件测试来说是 “nice to have”，而非必须。
以我自身经历为例。我曾参与一个自动驾驶业务的测试，当时为了读懂源码，复习了线性代数和概率论，在研究算法实现时，也曾纠结研发为什么用矩阵左乘而不是右乘、有没有计算置信区间。但越深入读下去，我越意识到：这种深入对业务质量提升的帮助极其有限。
对于研发来说，你告诉他 “高架桥下定位不准”，比质疑他 “为什么用左乘而不是右乘” 更重要。只要你能定义场景（高架桥下、隧道内、强光逆射……），研发就能有针对性地修复。与其花时间在源码深究上，不如你开着车绕北京跑一圈，实地采集那些复杂场景——尽管后者看似没有技术含金量，却是关键性动作。
所以我的判断是：如果深入理解 AI 技术不能为 AI 评测带来实质性的改变，那么这个动作就不是强制的。 测试的核心价值，在于定义 “什么是对的场景”，而不是证明 “算法为什么这么写”。
AI 评测本身是否会被 AI 替代
我的判断是：AI 评测的部分环节会被 AI 增强甚至替代，但评测本身不会消失，而是会演进出新的形态。
可以预见的演进方向包括：
第一，评测数据的生成，需要结合更多垂类、私域的行业 know-how 指导 AI 完成。
第二，评测的 “设计环节” 仍需要人。 谁来定义评测维度？谁来设定不同场景下的通过标准？谁来确保评测数据能代表真实业务？这些涉及业务理解、风险判断和价值权衡的问题，短期内难以被 AI 替代。
为什么 “评测的设计者” 难以被替代？因为评测设计的本质，是在人脑中构建一个关于业务的 “数字孪生”——一个能够模拟真实业务场景、用户行为、价值判断的认知模型。测试设计者需要基于这个认知模型，推演系统在不同情境下的表现，预判可能的效果偏差，并针对性地设计评测方案。
而当前 AI 之所以无法胜任这一角色，主要受限于两个层面：
一是模型能力的根本局限。 以 Transformer 架构为代表的大语言模型，本质仍是基于概率的统计模型。它们可以生成流畅的文本、匹配语义相似度，但并未真正 “理解” 世界。当评测设计需要洞察业务的隐性逻辑、权衡不同场景的优先级、判断哪些偏差可以容忍时，这种 “理解” 恰恰是关键。或许只有当李飞飞教授提出的 “世界模型”（World Model）得以实现，让 AI 具备对物理世界和社会规则的因果推理能力，情况才可能有所突破。
二是企业数字化水平的现实制约。 数字孪生的构建，依赖于高度数字化的企业环境——流程标准化、数据资产化、业务可量化。然而，受国内市场驱动模式和管理水平的制约，除少数顶尖企业外，绝大多数公司尚未达到这一状态。关键信息仍散落在文档、沟通和人的经验中，难以被 AI 完整捕获。在这种情况下，只有身处其中的人，才能通过长期浸润形成对业务的 “动态快照”。
这两个局限，共同决定了：至少在可预见的未来，评测设计的主导权仍将掌握在人的手中，而软件测试人员的测试重点可能也会往这个方向上去发展。
命题二：用 AI 赋能传统软件测试的趋势
传统软件测试的工作范畴
21 世纪初，受敏捷开发和 DevOps 理念的推动，软件测试的角色发生了深刻转变——不再仅在测试阶段介入，而是通过测试左移与测试右移，贯穿从需求到线上的全生命周期。尽管不同公司对测试工作的定义各有侧重，但在此大框架下，经过左右移后，测试的工作范围大致可以归类为以下几个方面：
方案评审：PRD 评审、技术方案评审、Code Review、上线方案评审、监控方案评审、灰度方案评审。
测试设计：测试范围评估（基于代码变更、业务影响面）、测试策略编写（测试分层、技术选型、环境依赖、通过标准）、测试用例编写（功能流程、异常场景、边界条件、隐式需求）。
测试执行：测试环境准备、测试数据构造、测试工具开发、测试动作执行（功能/性能/安全/效果/体验/高可用测试）、数据采集分析（执行结果、系统日志、监控指标）。
质量决策：过程风险纰漏、测试报告撰写。
线上洞察：线上监控体系搭建、灰度过程监控分析、线上问题定位止血、线上问题复盘分析。
软件测试的核心能力拆解及在 AI 时代的替代技术
由于各公司、团队和技术栈在成熟度上存在差异，上述工作范畴在实际执行中形态千差万别。然而，无论身处何种环境，这些表象之下始终贯穿着一些对软件测试人员的核心、普适性的能力要求。也正是这些能力，构成了软件测试群体的内部 “护城河”。
信息建模能力
能力介绍
信息是质量决策的底层燃料。在国内多数公司中，由于流程标准化和数据化程度不高，关键信息往往呈现 “碎片化” 与 “高熵” 状态。这些碎片散落在各种载体之中：项目成员的口述、离线和在线文档、内部系统数据及日志、代码及其注释……它们彼此孤立，甚至相互矛盾。
软件测试人员在着手具体事项前，首先要做的，就是将这些孤立数据在头脑中重组、拼接、构建成一个可在人脑内推理的模型。当这些碎片在脑海中形成实体的系统模型后，后续的规划、执行、决策才有了可依托的框架，这个人产出的内容才具有一定的 “系统性”。否则不仅给人的感觉很散，同时后续执行和拿结果时，也容易造成疏忽和遗漏。
AI 时代的替代技术
通过沟通获取信息：目前，AI 技术尚无法完全替代人与人之间的沟通以获取信息。然而，随着各技术岗位对 AI 工具的深度应用，知识沉淀与经验输出的模式正逐步向标准化与常态化演进。因此，尽管短期内信息获取仍高度依赖人工沟通，但从长期演进趋势看，伴随 AI 在生产流程中的深度融合，当前以沟通为主导的信息获取机制或将逐步被弱化甚至淘汰。
通过离线和在线文档获取信息：当前的主流技术路径是依托知识库管理平台，结合检索增强生成与图谱推理技术实现信息抽取与整合。但现阶段仍面临明显局限，包括 RAG 检索精度不高、模型幻觉问题未能完全消除、基于图结构的问答准确率有限等，这都可能导致关键信息在传递过程中出现遗漏。同时，部分场景仅采用 RAG 无法做到类似人脑的建模推理，必须采用只是图谱的方式，而构建知识图谱，尽管有团队在做，但鲜有看到最佳实践的分享。
通过内部系统数据、代码及日志获取信息：上述操作本质可归结为两个基础能力：其一，具备调用本地工具的能力，涵盖 Windows 与 Linux 环境下的操作接口；其二，具备通过 Web 端操纵业务系统的能力。近期 OpenClaw 等自动化操作工具的兴起，有望加速第一类问题的解决。针对第二类问题，当前已涌现出多种技术路径，包括 OpenClaw 方案、通过 Playwright 等工具编写自动化脚本、基于 Web 端提供的 MCP 服务等。从技术演进趋势来看，尽管现阶段上述方案在精确度上尚未达到 100% 的覆盖水平，部分遗留系统也无法直接提供 MCP 服务，但若加上适度的人工介入，并伴随 OpenClaw 等客户端工具的持续迭代，上述局限性有望在短期内实现实质性突破。
需要指出的是，尽管前文所述的三个信息获取环节（沟通、文档、内部系统）在 AI 时代已具备相应的技术替代路径，或有望在短期内实现实质性突破，但这并不意味着所有不同数字化成熟度的企业均能顺利落地这些技术，并将其有效转化为质量决策所需的信息支撑。AI 技术效能的发挥，不仅取决于工具本身的演进程度，更与企业在 AI 投入上的战略意愿、技术信心，以及整体数字化基础设施与数据治理水平密切相关。换言之，唯有当 AI 工具与组织数字化底座协同演进时，上述替代路径方能真正释放其潜力。因此对于身处不同成熟度企业的软件测试同学来说，AI 协同会有一定的差异。
问题规划/决策能力
能力介绍
在绝大多数场景里，软件测试人员接收到的往往只是一个目标。我们需要将这些目标进行拆解，化整为零，分解成可执行的步骤，再付诸行动。以一次性能测试为例，需要拆解为构造数据、编写测试脚本、调试压测工具、执行压测、采集监控指标、分析结果、判断是否准出等。缺乏规划的执行，很可能拿不到正确的结果。
决策则是约束下做出权衡。当一个版本已延迟三天，性能测试显示接口响应增加了 50 毫秒，业务方表示 “几乎无感知”，你是否放行？这个决策的背后，需要同时理解技术风险、业务容忍度、交付节奏和组织文化。没有标准答案，只有基于信息的综合判断。
AI 时代的替代技术
在当前技术背景下，Agentic AI 已在问题规划领域展现出较强潜力。以 Claude、Cursor 等为代表的智能体，能够通过自查询、自省、代码生成等能力，将用户给定的目标进行自动化拆解，并依据输入信息进行推理与决策。这意味着，当信息充足、经验可复用的情况下，AI 在规划与决策能力上可以达到较高水平。
然而，AI 在规划和决策方面的表现高度依赖于信息建模的完整性和经验沉淀的质量。如果输入信息不准确、领域模型不清晰，或缺乏真实的决策案例作为支撑，AI 的拆解与判断也可能偏离实际。因此，当前 AI 在这一维度的主要局限并不在于推理能力本身，而在于其所依赖的知识结构是否完备、经验是否可表达。
动作执行能力
能力介绍
无论信息建模多么完整、规划决策如何周密，最终都必须落地为可执行的行动。动作执行能力是软件测试从业人员最基础、最核心的实践能力。它涵盖了从文档产出到工具操作、从脚本开发到人际协作的多元场景，构成了测试活动得以推进的 “最后一公里”。
能力形态主要包括以下几类：
文档产出与知识沉淀：将测试思路、过程记录、结果分析和风险判断转化为可供他人阅读、追溯和复用的文档材料。
测试脚本开发：通过编写代码支撑测试活动的执行
本地工具操作：熟练使用 Windows 或 Linux 环境下的各类桌面工具和命令行工具
浏览器使用：通过浏览器访问和操作各类测试平台、及管理系统。
沟通与推动：通过对外协作，推动他人完成特定事项并跟进执行效果，例如协调开发人员补充单元测试、推动运维完善监控能力等。
AI 时代的替代技术
在文档撰写和脚本编写方面，大语言模型及各类智能体已展现出成熟能力，能够高效完成模板化、结构化的产出任务，这已成为行业共识。
在本地工具操作方面，以 OpenClaw 为代表的技术路径表明，通过 AI 与工具操作能力的结合，实现本地环境下的自动化交互正逐步成为可能。
浏览器操作层面，智能体已具备通过视觉理解与模拟点击完成页面交互的能力，前文已有阐述。
沟通与推动是当前大模型较难替代的领域之一，因其涉及人际理解、情感判断与动态协调。不过，在动作执行能力的整体构成中，沟通推动并不处于核心位置，其不可替代性对整体替代趋势的影响有限。
综合来看，与问题规划和决策能力类似，动作执行能力在可预见的未来，同样面临较高的被替代概率。这一判断基于技术演进路径的清晰性：当知识沉淀、代码生成、工具操作和界面交互均可由 AI 完成时，动作执行层的许多工作将逐步由人机协作转向智能体主导。
经验沉淀能力
能力介绍
无论是信息建模能力、问题规划与决策能力，还是动作执行能力，它们都依赖于一个共同的基石——经验。经验是基础构件，是真正可以被复用、被传承的核心资源。经验沉淀可以发生在不同层面，例如行业级、项目级、领域级或公司级。无论是 “如何编写测试用例”、“如何评审产品需求”，还是 “如何进行性能测试”，这些都是测试领域中具有价值的经验沉淀。
AI 时代的替代技术
无论是我们日常频繁使用的 Prompt 工程，还是近期在 Claude 和 Cursor 等平台上备受关注的 Skills 功能，本质上都是在为经验沉淀提供体系化的实现方式。从技术角度看，这些工具本身并不存在明显的局限性。但在实际应用过程中，有两个关键问题如果处理不好，将直接影响经验沉淀的效果，进而削弱信息建模、问题规划与动作执行的能力，最终拖累整体 AI 应用的表现。这两个问题分别是：
如何从人的思维中有效提炼能力？部分人缺乏高度的抽象总结能力，也有人出于岗位安全感等因素，在实际工作中未能全面、准确地贡献经验，给大模型的经验沉淀带来困难。
当前尚未形成明确的最佳实践。例如，哪些内容适合放在 Prompt 中，哪些适合放在 Skills 中，哪些又适合放在 Skills/references 层级下？内容应该细化到什么程度，既能确保 AI 准确理解，又不会因过于细致而引发执行过拟合？
上述两个问题中，问题 1 其实没有本质上的局限性。软件测试行业本身具备较强的分享意愿和赋能精神，即便你所在的团队暂时无法总结出某个专题的经验，其他公司迟早也会有人提炼出相应的成果。而问题 2 本质上是一个实践探索的问题，随着时间推移和持续积累，最佳实践终将应运而生。
综上所述，除信息建模能力仍需与组织的数字化底座深度绑定，以及本地工具操作和浏览器操作尚待进一步迭代与成熟外，其他方面目前已基本具备通过 “AI+ 人在旁路” 或 “人在回路” 模式实现可落地应用的状态。
人与 AI 交互的三种模式及预期场景
如果将上述能力串联起来，便构成了一个人完成一项任务的端到端闭环，而这一闭环的完整性与有效性，最终定义了其所交付成果的端到端质量，如下图所示。
值得注意的是，这个闭环具有递归性。当我们运用这套能力去解决一个复杂问题时，往往会将其拆解为若干子问题；而在应对每一个子问题的过程中，我们同样需要遵循这一端到端闭环。如此递归下去，直到某个子问题足够简单，仅凭该领域的已有经验便可直接闭环，无需再行拆解。
尽管从长远来看，当前技术所面临的种种局限迟早会被突破，但在现阶段，依赖 AI 完成任务时，准确性仍然是一个现实挑战。以系统可用性理论为例：假设完成一项任务需要四个步骤，每一步都由 AI 独立执行，且每个步骤的准确率均能达到 90%，那么最终端到端的整体准确率则为 90%4 ≈ 65.6%。这意味着，至少在当前阶段，人类仍需通过特定的协作模式介入 AI 工作流，以保障最终效果。
目前，人与 AI 的协作模式主要体现为以下三种场景：
人在旁路（Human on the Loop）：AI 自主完成任务流程，人类在旁观察关键输出，并在必要时进行补充或干预。例如测试工具开发、测试文档编写、方案前置评审等依赖的 AI 能力相对成熟，因此采用人在旁路更合适。
人在回路（Human in the Loop）：在 AI 执行的每一个关键步骤中，人类都进行实时检查与修正，通过实时修正确保交给下一个 AI 模块的输入是相对准确的。例如测试用例编写可以拆解成测试策略设计-〉业务模型创建 -〉测试用例创建。在整个过程中一方面目前 AI 并不是准确率都高，另一方面对于测试来说，边看需求边生成和修改测试用例有利于人脑和 AI 同时对需求进行建模。
人在领路（Human Leading the Way）：人类主导整个工作流程，AI 仅在局部环节提供碎片化辅助。例如：测试执行部分。但尽管人在领路，不过我们仍然需要保持对新技术趋势的关注，以便我们在合适的时机判断是否引入时机成熟。
笔者认为，尽管未来 AI 技术将持续突破，但依据可靠性工程的基本原理，对于复杂流程（例如 10 个节点需要 AI 完成），即便每个节点的 AI 准确率高达 98%，整个系统的端到端成功率也会衰减至约 81%。这意味着，在通用人工智能（AGI）真正到来之前，“人在回路” 的人机协同模式很可能成为长期共存的基本形态。因此，如何基于人在回路的逻辑，有效操控 AI Agent 以高质量、高效率地完成各类测试任务，或许是从当前 AI 时代迈向 AGI 时代过程中，软件测试人员需要持续探索的核心命题。
“人在回路” 的模式带来的职业不安全感
在 “人在回路” 甚至 “人在旁路” 的人机协同模式下，另一种隐形的挑战正在浮现——AI 带来的职业不安全感。
这种不安全感主要源于两方面的心理博弈：
对 AI 精度的天然质疑：测试人员深知，AI 会犯错，把任务交给 AI，就像悬着一颗心，不知道什么时候会出漏子。
对自身能力退化的隐忧：当长期习惯于 “审视” AI 的答案，而非亲自从零构建测试逻辑时，个人大脑中对复杂任务的建模精度和推理能力可能会悄然退化。更棘手的是，AI 本身不承担任何责任，而人最终要承担。
面对这种纠结，笔者的建议是：不必过度内耗，决策的尺度应回归到组织当下的战略节奏。
如果你所在的组织正在 “强推 AI”：那么不妨放下对完美的执念，先按照公司当前定义的最佳实践去做。既然 AI 化是大势所趋，过程中的试错就是必经之路。即便可能出现问题，暴露了也是为组织积累经验数据。既然担心无用，不如顺势而为，把注意力放在如何快速响应和补救上。
如果你所在的组织尚处于 “探索引入” 或 “观望” 阶段：那么确实需要保持一份谨慎。更好的做法是主动与领导对齐预期，划定清晰的 “实验区” 与 “保护区”。针对风险较低、可容忍失败的场景，大胆尝试 AI；风险较高、影响核心业务的场景，依然以人工为主。
面对大模型，软件测试是等、走、还是冲？
AI 正在以前所未有的速度渗透到软件研发的每一个环节。当开发开始用 AI 生成代码，产品开始用 AI 撰写需求文档，一个尖锐的问题摆在每个测试人面前：我们该怎么办？
为什么不能 “等”？
在 AI 浪潮下，无人能独善其身。当行业的内卷程度演进到开发依靠 AI 成倍产出代码、产品借助 AI 快速迭代需求时，测试如果仍在原地踏步，靠手工或传统自动化苦苦支撑，必然成为整个研发链条中最明显的瓶颈。等待意味着放弃适应，而放弃适应意味着被边缘化。当整个生产线都在提速，唯一的质检环节却停滞不前，结果只能是崩盘或被淘汰。
为什么不能盲目 “冲”？
那么，既然不能等，是不是就要立刻调转船头，全力冲刺 AI 转型？
对于身处头部、拥有充足算力和算法人才的大厂精英团队来说，或许可以一搏。但对于绝大多数处于腰部及以下的软件测试团队而言，盲目地 “冲” 很可能是一种得不偿失的冒险。
一方面，“冲” 需要巨大的投入。无论是采购 Token，搭建服务，还是抽调骨干力量进行自研，都需要投入大量的人力和精力。这种投入对于资源有限的团队来说，本身就是一种风险。
另一方面，“冲” 可能面临极大的不确定性。AI 技术的发展速度是指数级的。今天团队花费半年时间辛苦打磨的一个 AI 测试工具，明天可能就被业界某个开源项目或商业产品所覆盖。这种被 “背刺” 的风险，足以让团队的长期努力瞬间归零。
最适合大多数人的路：“走”
因此，对于绝大多数测试人员及团队来说，最务实、也最具韧性的策略，不是等，也不是冲，而是 “走”。
这里的 “走”，包含两层含义：
随着业界的浪潮走： 保持对前沿工具的敏感度，但不追求首发，而追求快速跟进。
随着公司的 AI 战略走： 将测试团队的提效目标，紧密绑定在公司整体的 AI 组织转型上。
既然是 “走”，如何设定 AI 提效目标？
这引出了一个现实且棘手的问题：既然是 “走”，意味着没有宏大的叙事，那我们的 AI 提效目标到底该怎么定？坦率地说，基于 “走” 的策略，我们很难设定一个类似于 “AI 取代 30% 人力” 或 “通过 AI 承接新业务线” 的宏大 KPI。对于大多数腰部团队而言，AI 带来的初期红利，可能仅仅是 “碎片化时间”。
原本需要半天完成的需求评审，在 AI 辅助下缩短到了 3 小时，省出了 1 小时。
原本需要手写的测试数据，用 AI 生成脚本跑了一遍，省出了半小时。
这些时间碎片确实提升了个人工作效率。但遗憾的是，这些零散的时间往往不足以让一个人去独立承接一个完整的新项目或新需求。它可能只是让原本紧绷的工作节奏稍微舒缓了一些。那么，这种微小的效率提升，价值何在？
价值在于为团队和个人赢得了 “机动” 的资本。这种 “机动” 指成为 “当下 AI 工具的驾驭者”。当公司需要引入 AI 测试技术时，团队能立刻给出有价值的判断，而不是从零开始摸索。