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

发布时间:2026/9/8 13:33:39
软件测试转AI:先补数学还是先刷项目?实战路线解析 入行十几年大部分时间都在跟测试、自动化、质量管理打交道这几年肉眼可见的一个趋势是AI 已经不是概念而是开始渗透到研发链条的每一个环节。我身边不少做软件测试的朋友包括带过的团队成员都在问同一个问题我想转 AI 方向是应该先回去啃数学还是直接上手刷项目这个问题听起来像是二选一但实际操作中它更像一个节奏和策略问题。选错了顺序轻则浪费时间重则直接消磨掉转型的信心。比如我见过有人花三个月死磕线性代数和概率论最后连一个大模型接口都没调通过一面试就被“你做过什么实际项目”问得哑口无言也有人反着来教程看了无数个GitHub 上项目拷贝了一堆但面试官一问“为什么这里用余弦相似度而不是欧式距离”就彻底卡壳。这篇文章不是给你灌鸡汤也不是列一个所谓的“三十天转行路线图”。我想从软件测试从业者这个具体的背景出发把“先补数学还是先刷项目”这个问题拆开揉碎讲清楚什么阶段该做什么、做到什么程度以及最重要的——怎么把测试背景变成转 AI 时别人没有的加分项。如果你正在犹豫要不要转、转了之后怎么学、学的时候怎么分配精力这篇文章就是给你写的。1. 内容整体设计与思路拆解先想清楚“转去做什么AI”再谈学习顺序很多人的误区是一上来就纠结“数学重不重要”但其实这个问题本身是伪命题。AI 是个很大的筐里面装的方向差异巨大不同方向对数学的要求、对项目的需求完全是两码事。在选择先学什么之前你至少得先判断自己要去哪条赛道。1.1 为什么方向判断比“先学什么”更重要软件测试从业者有一个非常特殊的优势你比纯开发更懂业务逻辑比产品更懂技术实现而且天生具备“找漏洞”“怀疑一切”的思维习惯。这个优势在不同 AI 赛道里的价值完全不一样。如果目标是AI 应用开发比如调用大模型做工具、做智能体那么对数学的要求很低对工程能力和场景理解要求很高测试背景的优势非常明显。如果目标是算法工程师训练模型、调参、优化效果那么数学是硬门槛线性代数、概率论、微积分基本都要过关项目反而可以往后放。如果目标是AI 测试/AI 质量保障这是一个非常小众但需求激增的方向既不需要太深的数学也不需要卷到飞起的模型训练经验。你的测试思维本身就是核心竞争力。很多人在这一步就走错了看网上说转 AI 必须学机器学习就买一堆数学书从早啃到晚结果越学越虚因为不知道自己学的这些东西将来用在哪。这是典型的“用战术上的勤奋掩盖战略上的懒惰”。1.2 测试背景转 AI 的四个主流方向与学习侧重结合当前的行业热度和招聘情况我梳理了四个最适合软件测试从业者切入的方向以及每个方向对应的学习重心。这不是让你所有都学而是让你有针对性地选一条主线。方向核心工作内容数学要求项目要求测试背景适配度AI 测试开发设计大模型测试用例、评测集、对 AI 应用做质量保障低了解基本指标即可中需要能做 AI 产品的测试方案很高AI 应用工程师用大模型 API 开发工具、智能体、RAG 问答系统低理解向量和相似度够用高需要完整可演示的应用高数据分析/机器学习工程做数据清洗、模型训练、特征工程中高需要系统学线代和概率高需要 Kaggle 或真实训练项目中算法研究员模型结构改进、训练新模型很高需要扎实数学功底高需要论文或开源贡献低不建议零基础转我个人的建议是软件测试从业者最舒服的切入点是前两个方向尤其是 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 的核心流程拆开来看就是四步将知识文档切片Chunking把长文档切分成适合检索的片段。对每个切片做 Embedding也就是用嵌入模型把文本变成向量。用户提问时把问题也做 Embedding然后在向量数据库中做相似度检索找到最相关的几个片段。将检索到的片段和用户问题一起交给大模型让它基于这些内容生成答案。这个项目里你之前补的线性代数直觉终于派上了用场第 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 场景里找例子学概率统计时在看模型评估指标的论文里找对应章节。这样学出来的数学是“带着问题”的而不是一堆悬空的公式。阶段主要任务数学与项目的精力配比时长建议启动期跑通最小 AI 项目建立体感2 : 81~2 周成长期完成 1 个测试场景完整项目按需补数学4 : 64~8 周进阶期完成 RAG 或 Agent 项目系统补基础概念3 : 78~12 周深耕期根据目标岗位针对性强化算法岗转数学应用岗转工程视岗位而定持续迭代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 项目再回头看当初纠结的“数学还是项目”的问题你就会发现它们本来就不是非此即彼的两件事。