软件测试转AI：先补数学还是先刷项目？实战路线解析

入行十几年，大部分时间都在跟测试、自动化、质量管理打交道，这几年肉眼可见的一个趋势是：AI 已经不是概念，而是开始渗透到研发链条的每一个环节。我身边不少做软件测试的朋友，包括带过的团队成员，都在问同一个问题：我想转 AI 方向，是应该先回去啃数学，还是直接上手刷项目？

这个问题听起来像是二选一，但实际操作中，它更像一个节奏和策略问题。选错了顺序，轻则浪费时间，重则直接消磨掉转型的信心。比如我见过有人花三个月死磕线性代数和概率论，最后连一个大模型接口都没调通过，一面试就被“你做过什么实际项目”问得哑口无言；也有人反着来，教程看了无数个，GitHub 上项目拷贝了一堆，但面试官一问“为什么这里用余弦相似度而不是欧式距离”就彻底卡壳。

这篇文章不是给你灌鸡汤，也不是列一个所谓的“三十天转行路线图”。我想从软件测试从业者这个具体的背景出发，把“先补数学还是先刷项目”这个问题拆开揉碎，讲清楚什么阶段该做什么、做到什么程度，以及最重要的——怎么把测试背景变成转 AI 时别人没有的加分项。

如果你正在犹豫要不要转、转了之后怎么学、学的时候怎么分配精力，这篇文章就是给你写的。

1. 内容整体设计与思路拆解：先想清楚“转去做什么AI”再谈学习顺序

很多人的误区是一上来就纠结“数学重不重要”，但其实这个问题本身是伪命题。AI 是个很大的筐，里面装的方向差异巨大，不同方向对数学的要求、对项目的需求完全是两码事。在选择先学什么之前，你至少得先判断自己要去哪条赛道。

1.1 为什么方向判断比“先学什么”更重要

软件测试从业者有一个非常特殊的优势：你比纯开发更懂业务逻辑，比产品更懂技术实现，而且天生具备“找漏洞”“怀疑一切”的思维习惯。这个优势在不同 AI 赛道里的价值完全不一样。

• 如果目标是AI 应用开发（比如调用大模型做工具、做智能体），那么对数学的要求很低，对工程能力和场景理解要求很高，测试背景的优势非常明显。
• 如果目标是算法工程师（训练模型、调参、优化效果），那么数学是硬门槛，线性代数、概率论、微积分基本都要过关，项目反而可以往后放。
• 如果目标是AI 测试/AI 质量保障，这是一个非常小众但需求激增的方向，既不需要太深的数学，也不需要卷到飞起的模型训练经验。你的测试思维本身就是核心竞争力。

很多人在这一步就走错了：看网上说转 AI 必须学机器学习，就买一堆数学书从早啃到晚，结果越学越虚，因为不知道自己学的这些东西将来用在哪。这是典型的“用战术上的勤奋掩盖战略上的懒惰”。

1.2 测试背景转 AI 的四个主流方向与学习侧重

结合当前的行业热度和招聘情况，我梳理了四个最适合软件测试从业者切入的方向，以及每个方向对应的学习重心。这不是让你所有都学，而是让你有针对性地选一条主线。

我个人的建议是：软件测试从业者最舒服的切入点是前两个方向，尤其是 AI 测试开发和 AI 应用开发，这两个方向既能复用你已有的经验，又不需要花一年时间死磕数学。

一旦方向定了，后面的问题就好回答了。如果是算法方向，老老实实先补数学，没有项目经验可以靠 Kaggle 竞赛来弥补；如果是应用方向，先刷项目、在项目中补数学，效率远高于先啃书本。

2. 核心细节解析与实操要点：数学到底要补到什么程度才算“够用”

先给结论：如果你走 AI 应用开发或 AI 测试方向，不需要啃完同济版《线性代数》或《概率论与数理统计》的全部内容。你需要补的是与动手实践直接相关的“最小必需集合”，而不是一个数学系学生的完整知识体系。

2.1 按方向拆分数学优先级：哪些必须学、哪些可以放

我见过太多人被“转 AI 先学三年数学”这句话劝退，但实际上，工程应用岗位需要用的数学比想象中少得多。以 AI 应用开发为例，你天天打交道的数学概念只有几类：

• 线性代数：只需要理解向量、矩阵、矩阵乘法、向量空间这几样，因为大模型里的 Embedding（嵌入）本质上是把一个词或一段文本映射成一个高维向量，计算相似度就是在做向量运算。你不需要会手工计算矩阵的特征值，但你要理解“两个向量越相近，夹角越小，余弦值越大”这个直觉。
• 概率统计：只需要理解条件概率、贝叶斯定理、期望、方差这些概念，因为在 Prompt 工程里你要知道模型输出的是一个概率分布，为什么在回答时会“一本正经地胡说八道”，本质是概率采样问题。
• 微积分：应用岗基本用不到，但如果你想读懂大模型训练相关的文章，至少要知道梯度下降是用来求损失函数最小值的工具，明白“导数”是函数变化率的含义就够了。

这里有个非常实用的判断标准：当你读一篇 AI 应用的技术文档时，看到一个数学公式，你能知道它在解决什么问题、影响哪个环节，这就够了。不需要会推导，更不需要刷题。真正需要手推公式的岗位是少数，而且那些岗位大概率不会从零开始招一个没有相关学历背景的人。

2.2 一个月速成“够用版”数学的执行方案

如果你的数学基础已经丢了很久，我建议按下面的顺序用 2 到 4 周时间补一轮“够用版”数学，每天投入 1 小时左右就足够。注意，这里不是让你去刷《高等数学》课后习题，而是建立概念直觉。

第一步：用 3Blue1Brown 的《线性代数的本质》视频过一遍向量、矩阵、线性变换的核心概念。这套视频用可视化的方式讲线性代数，看完之后你会对“向量点积”“线性组合”有非常直观的体感，而不是死记公式。

第二步：重点搞懂向量相似度的计算方式，尤其是余弦相似度的几何含义。你可以用 Python 手写一个计算两个句子相似度的函数，输入两个句子，输出一个 0 到 1 之间的数。这个练习一开始看起来跟 AI 没关系，但当你做到 RAG（检索增强生成）项目时，你会发现在向量数据库里找相似内容用的原理和这个一模一样。

第三步：学条件概率和贝叶斯定理，不用做太多题，关键是理解“新证据如何更新已有判断”这个思想。在 AI 测试中，你可能会用到置信度、误报率、召回率这些指标，它们的底层都是概率思维。

第四步：了解梯度下降的基本思想。你可以自己写一个极简的线性回归模型，通过不断调整参数让损失函数变小，亲眼看着 loss 曲线一点点降下去。这一步做完，你就算亲眼见过“机器学习训练”到底长什么样了。

提示：如果你学数学的时候觉得“这跟 AI 有什么关系”，不要硬撑。停下来，去找一个调用大模型 API 的小项目先跑通，再回来看数学，你会发现之前抽象的概念全都变得具体了。我见过很多人的转型卡点不是数学太难，而是数学和项目脱节导致失去动力。

2.3 什么时候该果断暂停数学，转去刷项目

这个问题我用一句话回答：当你发现自己已经在做数学题、而不是在理解概念的时候，就该停了。数学对应用类 AI 岗位的作用是“扫盲”，不是“深造”。你能看懂技术方案里的公式、能和算法工程师对话、能在面试时说出“这个问题本质上是个概率问题”，就已经足够应对绝大多数场景。

我自己踩过的一个坑是：刚开始转 AI 的时候总觉得数学基础不牢，硬是花了两个月刷完了一本线代习题集，结果真正开始做项目时发现那些题对工程一点帮助没有。后来面试官问我的项目细节，我答得头头是道，反而没一个人问我“你会不会求矩阵的特征值”。

记住：应用型 AI 岗位的面试验证的是你能不能用 AI 解决真实问题，而不是你能不能通过数学考试。你刷再多的特征值习题，也不如把一个 AI 应用跑通拿到线上用更有说服力。

3. 实操过程与核心环节实现：从测试场景切入，用三个项目建立完整技能树

方向定好了，数学的“够用版”也补上了，接下来是最核心的部分：项目实战。这里我强烈建议软件测试从业者做一个很多人没意识到的选择——不要去做网上流行的“猫狗识别”“房价预测”，而是做跟测试场景强相关的 AI 项目。原因有两个：第一，你对测试场景的理解是独一无二的，做出来的东西有实际价值；第二，面试时你解释项目的业务逻辑会比别人解释 MNIST 数据集流畅得多。

3.1 第一个项目：智能接口测试用例生成器

这是一个门槛低、见效快、和测试工作直接挂钩的项目，非常适合作为第一个上手练习。它的核心思路是：利用大模型的自然语言理解和代码生成能力，自动从接口文档中生成测试用例。

具体做法是，选择一个你平常工作里最熟悉的接口文档（如果没有现成的，可以在网上找一个公开的 API 文档），然后通过大模型 API 让它根据接口描述生成覆盖正常、异常、边界、权限等场景的测试用例。你的任务不是简单调用 API，而是要完成一整套工程化处理：

• 设计清晰的 Prompt，让大模型输出的格式稳定的 JSON 结构，方便后续解析。
• 写一个 Python 脚本，读取接口文档，调用大模型，将返回结果解析成表格或可直接导入测试管理工具的格式。
• 对生成结果做校验，比如检查必填字段是否完整、用例步骤是否合理，这一步其实就是你作为测试人员的专业价值所在。

为什么第一个项目要选它？因为它涉及了 AI 应用开发里最核心的一环——Prompt 工程，同时不需要搭建复杂的前后端，一个脚本就能搞定。你不需要先学 Flask，不需要懂数据库，把精力聚焦在打通“调用大模型 API → 解析结果 → 结构化输出”这条最基础的链路上。

做完之后，你会对“AI 能力调用”这件事产生非常直观的体感，也知道 Prompt 输出不稳定是常态，需要做格式约束和异常处理。这个项目虽然小，但它是一个完整的 AI 应用闭环。

3.2 第二个项目：基于 RAG 的测试知识库问答机器人

第一个项目让你跑通了 API 调用，第二个项目就进入 AI 应用开发的主战场了：RAG（检索增强生成）。这个项目的业务场景很自然：团队里总有大量测试规范文档、历史缺陷报告、产品需求文档，新同事入职后经常反复问一些老人才知道的知识，做一个问答机器人比翻文档高效得多。

RAG 的核心流程拆开来看，就是四步：

1. 将知识文档切片（Chunking），把长文档切分成适合检索的片段。
2. 对每个切片做 Embedding，也就是用嵌入模型把文本变成向量。
3. 用户提问时，把问题也做 Embedding，然后在向量数据库中做相似度检索，找到最相关的几个片段。
4. 将检索到的片段和用户问题一起交给大模型，让它基于这些内容生成答案。

这个项目里，你之前补的线性代数直觉终于派上了用场：第 3 步计算相似度，用的就是向量之间的距离或夹角余弦。你不需要写向量数据库的内核，但是要理解为什么用向量检索比传统的关键词搜索更适合语义匹配。

我建议实现时选择一个开源的向量数据库，比如 Chroma 或 Milvus，再配合一个 Embedding 模型和常见的大模型 API。整个项目可以做成一个简单的 Web 服务，用 Flask 或者 FastAPI 搭一个前端问答页面。

这个项目做完，你的技能树上就点亮了 AI 应用开发最核心的环节：文本处理、向量化、检索、生成。而且“测试知识库”这个场景非常贴合你的背景，面试时你可以很自然地说：“我把团队三年的缺陷报告和测试规范做成了知识库，以前新同事查资料要半天，现在直接问机器人。”

3.3 第三个项目：让测试流程自动化的 Agent

第三个项目可以明显拉开你和普通转行者的差距，也是目前招聘市场最热的词——Agent（智能体）开发。做一个能自动处理测试相关事务的 Agent，不仅能让你掌握 Function Calling、工具调用、循环决策等进阶技能，而且场景天然和你的专业背景匹配。

举个具体的例子：做一个“智能缺陷分析助手”。它可以接收一条新的缺陷描述，然后做以下几件事：

• 调用一个缺陷库查询工具，检索历史上是否出现过类似的缺陷（需要调用搜索 API 或数据库接口）。
• 调用代码仓库的 Commit 信息接口，分析最近代码变更涉及的模块，判断缺陷可能影响的组件。
• 基于以上信息，生成一份包含根因猜测、影响范围分析、建议回归测试范围的报告。

这里的核心难点不是调用大模型 API，而是让 Agent 学会“决策”——面对用户需求，它先调用哪个工具，拿到结果后如何判断是否继续调用下一个工具。这个循环过程需要你理解 Function Calling 的机制，以及如何设计清晰的工具接口和提示词约束。

做完这三个项目，你已经不再是“听说过 AI”的状态，而是真刀真枪做过 AI 应用开发、RAG、Agent 三种主流形态。更重要的是，这三个项目全部围绕测试场景展开，形成了一条完整的叙事线：我不仅懂测试，还能用 AI 提升测试效率。

3.4 项目是“深做”还是“广做”：一个保证作品集质量的取舍原则

很多人在刷项目时会陷入另一个误区：贪多嚼不烂。今天看 LangChain 的教程做个文档问答，明天看 AutoGPT 火了就想做个 Agent，后天又觉得 LlamaIndex 很酷想试试，最后每个项目都只是把教程代码跑通了，没有任何自己的思考。

我建议项目数量控制在三个以内，但每个项目都要“深做”到能回答面试官追问的程度。所谓“深做”，至少要满足三点：

第一，你清楚项目每个环节的输入输出是什么。比如 RAG 项目里，切片大小对检索效果有什么影响，你是不是实际调过？不同的 Embedding 模型对答案质量影响大不大，你是不是实测对比过？

第二，你能说清楚项目方案的取舍。比如用 Chroma 而不是用 Elasticsearch，是因为项目体量小、需要快速上手，还是因为向量检索更匹配场景？做一个 Agent 时，你是用 LangChain 的现成框架还是自己写循环逻辑？为什么？

第三，你有数据支撑项目效果。比如生成一千条测试用例，和人工写的用例对比，覆盖率提升了多少？知识库问答机器人在 30 个真实问题上测试，正确回答了多少个？哪怕只是一个小规模的验证数字，也比“能跑”两个字有说服力得多。

4. 常见问题与排查技巧实录：先数学还是先项目的动态决策模型

讲完了具体怎么做，回到最开始的灵魂问题：先补数学还是先刷项目？我的答案是：不要把它当成一个二选一的决策，而要理解它是一个动态切换和迭代的过程。

4.1 “先跑通一个最小项目”是唯一的最优起点

对于已经工作了几年、没有太多连续学习时间的人来说，我强烈建议把“跑通一个最小 AI 项目”作为第一优先级。这里说的最小项目，可以简单到就是调用一个大模型 API，输入一段文本，让它返回一段总结。你不需要理解背后的任何数学原理，先看到输入输出到底是怎么回事。

这个阶段的目标只有一个：建立体感。你会知道原来调用 AI 接口没有那么神秘，不过就是发一个 HTTP 请求、解析一段 JSON；你也会发现 AI 的输出有随机性，同样的输入可能得到不同的答案，这让你立刻明白为什么 AI 应用需要做测试。这份体感是后续一切学习的支撑，它能让你在学数学的时候知道“为了什么而学”。

以我自己带人的经验，一个完全没有 AI 基础的测试工程师，从零开始跑通一个最小 API 调用脚本，通常只需要一个周末。但如果是先学一个月数学再开始动手，至少要花两倍时间还未必能坚持下来。

4.2 什么时候应该“边做项目边补数学”

当你完成第一个最小项目、手头正缺一块具体的数学知识时，就是“边做边补”的最佳时机。举个我自己经历过的例子：最开始做 RAG 知识库时，我用的是一个开源的向量数据库，里面默认用余弦相似度计算文本距离。当时我对“为什么两个句子越像，余弦值越大”这件事并没有完全的把握，于是专门找了一个下午，看了 3Blue1Brown 的线性代数视频，又手写了一个计算余弦相似度的小脚本，拿几个例子逐个验证。从那以后，“向量相似度”这个概念就再也没忘过。

这种“按需补数学”的效率，远超拿着一本教材从头到尾学一遍。因为它每一个知识点都有真实的落地场景，学完能立刻用上，大脑对这类信息的记忆强度非常高。

4.3 如果目标是算法岗，学数学的时间怎么安排

当然，如果你的目标不是应用开发，而是算法工程师方向，这时候数学的优先级就要大幅提前。算法岗面试对数学的要求是实打实的，面试官会直接让你推导模型公式、解释某个 Loss 函数的性质，没有系统的数学基础基本没戏。

但即使如此，我仍然不建议“纯学数学不碰项目”。更合理的节奏是：以 Kaggle 竞赛或开源项目为主线，每个实际问题需要什么数学就补什么。学线性代数时，在你正在处理的特征工程或 Embedding 场景里找例子；学概率统计时，在看模型评估指标的论文里找对应章节。这样学出来的数学是“带着问题”的，而不是一堆悬空的公式。

4.4 一个可复制的每天学习节奏

作为还在上班的软件测试工程师，你的学习时间本来就不多，节奏比时长更重要。我自己在转型期摸索出一套比较可行的节奏：

工作日的晚上抽出一个半小时，头 20 分钟看今天要做的项目的相关知识，接下来 40 分钟写代码，最后 30 分钟记录今天遇到的问题和最让你卡壳的地方。周末的上午用来连片式地攻克难点，下午则用来整理学习和项目笔记。

这里有一个非常重要的原则：不要攒着一个大问题等到周末再解决。遇到卡点超过半小时，马上切换任务，去查文档、去看别人的实现，甚至可以先绕过去做别的事情。我见过很多人卡在一个小 bug 上两三天，信心崩了，项目也停了。动手做 AI 项目，最重要的不是“硬啃”，而是“保持推进”。

5. 简历、面试与学习资料速查：把测试背景变成转型的敲门砖

项目和数学都准备得差不多了，最后一步是把你的积累有效地展示给面试官。这里我想单独讲一讲软件测试从业者在简历包装和面试应答时的策略，很多转型者在这一步丢掉好牌。

5.1 测试背景如何包装 AI 转型项目

先看一个常见的反面写法：“项目一：基于大模型的智能问答机器人，使用了 LangChain 和 OpenAI API，实现了文本问答功能。”这种描述到处都是，面试官看了毫无感觉，因为既看不清你做了什么，也看不出你的思考。

再看一个我帮团队成员改过的版本：“项目：基于 RAG 的测试规范问答系统。负责将团队近三年的测试规范、线上故障复盘文档进行切片和向量化，构建向量检索流程；通过自建 50 道真实业务问答评估集，对比不同切片大小和 Top-K 参数对回答准确率的影响，最终回答准确率从 68% 提升至 82%。”

看到区别了吗？后者有几个明显的优势：第一，明确了业务场景是“测试规范”；第二，强调了“自建评估集”——这也是测试人员的本能优势，你天然会考虑“怎么衡量一个东西好不好”；第三，有量化结果，不管数字是 68% 还是 82%，都说明你不仅做了项目还做了评估。

写简历项目的通用公式是：项目背景 + 你在其中的具体职责 + 你做的关键决策及其原因 + 可量化的结果。这个公式所有方向通用，但软件测试背景的人尤其容易把项目写成流水账，需要特别注意。

5.2 面试必背的核心概念清单

根据我面试 AI 应用岗位和被测 AI 产品的经验，软件测试背景的候选人如果简历里写了 AI 项目，面试官大概率会从下面几个方向里揪着问：

第一，大模型基础。不需要你把 Transformer 的结构背得滚瓜烂熟，但你要能说出 attention 机制是做什么的、为什么它能捕捉文本之间的关系、训练和推理的基本过程是什么。

第二，Prompt 工程。要能说清楚什么是零样本、少样本、思维链，以及在什么场景下用哪种策略更合适。面试官会给你一个具体场景，比如“要让模型从一段投诉文本里提取结构化信息”，你该如何设计 Prompt。

第三，RAG 的流程。从文档加载、切片、向量化、检索到答案生成，每一步你都应该能画出一个流程，并且能解释为什么需要检索这一步——因为大模型的训练数据有截止时间，而且模型会“编造”没有见过的信息，检索可以提供事实依据。

第四，Agent 与工具调用。要能说清楚 Function Calling 是一种让模型学会在需要时请求调用外部工具的机制，以及 Agent 的决策循环是怎么工作的。

第五，AI 测试特有的话题。这也是你的主场。比如大模型输出的随机性怎么测？对不同的 Prompt 版本怎么设计回归测试？如何构建评估集来量化回答质量？这些问题的思路是普通开发背景的候选人很难给出的，但对你而言是本能的优势。

5.3 低成本高质量的学习路径整理

最后简单整理一份我在转型过程中觉得真正有用的学习资源，全部不需要支付高额费用：

• 入门概念：3Blue1Brown 的《线性代数的本质》和《深度学习入门——基于 Python 的理论与实现》前几章，后者虽然有点老，但对理解训练、反向传播的过程帮助极大。
• 动手实践：直接在官网学习大模型 API 的调用文档，把官方示例跑一遍比自己看十篇教程都有用。LangChain 的官方文档也是很好的学习材料，但不要纠结于版本更新导致 API 变化，理解核心概念就行。
• 测试与 AI 结合：关注一些 AI 测试相关的开源项目，比如大模型评测框架，去看看别人是怎么设计测试集、怎么计算指标、怎么评估回答质量的。
• 社区与代码：建议维护一个自己的 GitHub 仓库，每次学到一个新知识点就写一个小项目放进去，不用怕代码写得丑。面试官看到你连续半年的提交记录，会比看到一份精修过的简历更相信你的学习能力。

6. 写到最后提醒几句：转型不是背叛，而是复用

这篇文章里我没有提到“抛弃测试经验”这个词，因为在我看来，软件测试从业者转 AI，真正的路径不是把过去的经验清零、从零开始，而是把过去积累的业务理解、质量意识和测试思维全部迁移到新的方向里。AI 应用越普及，“谁来保障 AI 输出的质量”这个问题就越重要，而这个问题恰恰是测试从业者的主场。

如果你现在还在犹豫是先学数学还是先刷项目，我的建议非常直接：先动手跑通一个最小 AI 项目，哪怕它丑、哪怕它只有几十行代码，先建立起“我能做 AI”这个信心。然后在做项目的过程中，哪里遇到的数学概念看不懂，就去补哪里的数学。等你做完一个完整的测试场景 AI 项目，再回头看当初纠结的“数学还是项目”的问题，你就会发现，它们本来就不是非此即彼的两件事。