上个月团队聚餐，几个刚入职的年轻人问我：强哥，你现在还自己写代码吗？我愣了一下，说写啊，不写代码怎么测？
他们笑，说以为我现在只负责画架构图、写文档。
我放下筷子，认真想了想这个问题。入行十一年，从最早的功能测试，到自动化测试，再到测试开发，工具在变，语言在变，平台在变，但有一件事没变：我在用工具，而不是造工具。
自动化测试火的时候，我学会了Selenium；容器化火的时候，我学会了Docker；AI辅助编程火的时候，我学会了用Copilot。但仔细想想，这些都是在学“怎么用”，而不是“为什么能这么用”。
直到今年开始接触LLM（大语言模型），我才第一次有了一种感觉：这东西，可能需要从原理上理解一点，不然再过两年，可能连“怎么用”都跟不上了。
今天想聊的，就是为什么我觉得测试开发工程师应该学一点LLM原理——不是要你去写Transformer，而是要理解它背后的逻辑，找到自己的“第二曲线”。
一、从“会用”到“理解”，差的不只是几个API
先讲个小事。
今年年初，我用AI写测试脚本已经挺熟练了。但有一天遇到个问题：一个订单查询接口，返回结果经常变化，我让AI帮我写断言，它生成的代码总是断言某个字段等于某个固定值，跑几次就挂了。
我当时很烦，觉得AI还是不够聪明。后来跟一个做算法的朋友聊起这事，他说：你知不知道LLM本质是“概率预测”？它根据你前面写的代码和注释，预测下一行最可能是什么。你让它写断言，它看到你前面都是assert a == b，当然预测你接下来也是assert c == d——它不理解业务逻辑，它只是在补全模式。
这话点醒了我。从那之后，我开始琢磨：如果我懂一点LLM的原理，是不是能让它干得更聪明？
比如，我开始在注释里写得特别具体，不是“断言返回正确”，而是“断言返回的订单列表按时间倒序排列”。AI生成的代码就不再是简单的等值断言，而是一段排序校验逻辑。
再比如，我尝试用“思维链”的方式写注释——先写“第一步验证状态码，第二步验证数据格式，第三步验证业务规则”——AI生成的代码结构清晰多了。
这些变化不是因为AI变强了，而是因为我理解了它的工作方式，然后用它能理解的方式去指挥它。
这就引出了第一个理由：理解原理，是为了更好地使用工具。
二、从“补全代码”到“理解代码”，LLM在改变测试的边界
第二个理由，可能更长远一点。
我们做测试开发的，核心能力是什么？我理解是判断“正确”与“错误”的能力。
自动化测试本质上是在做一件事：用代码表达“什么是正确的”。写断言就是告诉机器：如果这个字段不等于200，那就不正确。但如果“正确”的定义本身在变化呢？如果“正确”不是一个固定值，而是一种模式、一种规律呢？
举个例子。测一个推荐系统，返回的推荐商品列表，怎么断言正确？你不能说“必须包含商品A”，因为推荐结果是动态的。传统的做法是测一些技术指标——响应时间、状态码、数据格式——但测不到核心：推荐的质量。
但我见过一个团队，用LLM做这件事。他们把推荐结果和用户画像一起喂给一个模型，问：这个推荐合理吗？模型返回一个置信度分数，高于阈值就算通过。
这不是传统意义上的断言，这叫“语义校验”。它依赖的不是代码逻辑，而是模型对“合理”的理解。
再比如接口自动化，很多时候我们在测字段格式、枚举值范围，但业务规则往往是隐含的——“如果用户当天取消超过3次，则冻结24小时”。传统脚本需要把这条规则翻译成代码，但如果规则本身有几十条、上百条呢？如果规则经常变呢？
有人开始尝试让LLM直接理解规则文档，然后动态生成校验逻辑。测试脚本不再是固定的代码，而是一个“智能体”，它自己读文档、自己理解、自己校验。
听起来有点科幻？但其实已经有人在做了。而这些人，多半是对LLM原理有一定了解的测试开发——他们知道模型的边界在哪里，知道怎么把业务问题转化成模型能处理的形式，知道什么时候该相信模型、什么时候该回退到传统逻辑。
这是第二个理由：理解原理，是为了拓展测试的边界。
三、从“被替代”到“驾驭”，心态上的转变
第三个理由，可能比较私人化——关于焦虑。
这一年来，技术圈里“AI取代程序员”的说法一直没断过。测试圈也在聊：以后AI都能自己写脚本了，还要测试干什么？
说实话，我焦虑过。
直到我开始学一点LLM原理，慢慢想明白一件事：AI不会取代测试，但会用AI的测试会取代不会用AI的测试。
这个道理其实不新鲜。自动化测试刚兴起的时候，也有人说手工测试会被取代。结果呢？手工测试还在，只是变成了“探索性测试”“业务专家测试”——那些需要人做判断的活儿，机器还是干不了。
LLM也是一样。它能写脚本，但它不知道脚本写得对不对；它能生成断言，但它不知道断言是不是漏了关键字段；它能跑用例，但它不知道这个版本最重要的风险点在哪里。
这些判断，还是要人来干。
但问题是，如果你不理解LLM能干什么、不能干什么，你就没法把它用在最合适的地方。你可能让它去干它不擅长的事（比如做精确计算），然后在它出错的时候骂它没用；你也可能忽略它擅长的领域（比如理解自然语言描述、生成样板代码），然后继续手搓那些它几分钟就能搞定的东西。
学一点原理，不是为了成为算法专家，而是为了知道：这玩意儿到底能帮我干多少活，哪些活还得我自己来。
想清楚这件事，焦虑就少了。
四、那到底要学什么？怎么学？
说了这么多，可能有人想问：那具体要学点啥？
我不是算法出身，也是边学边摸索。这几个方向是我觉得比较实用的，分享出来供参考：
- 理解LLM的基本工作方式
不一定要懂数学公式，但要懂几个核心概念：
它是概率模型：它不是在“理解”你，而是在“预测”你最可能想要什么。所以提示词要具体，要给例子，要引导。
它有上下文窗口：你给的信息太多它会忘，太少了它瞎猜。知道这个，你就知道怎么拆复杂任务。
它没有真正的“记忆”：每次对话都是独立的，想要它记住项目规则，得把规则塞进每次对话里。
懂了这些，你就能解释为什么有时候AI答非所问，为什么加一句“按之前的方式”不管用——因为它在每个新对话里都“失忆”了。
- 学会“提示词工程”的基本套路
这不是什么高深的东西，就是怎么跟AI说话它才能听懂。几个实用技巧：
给例子（few-shot）：别只说“写个测试用例”，给一个例子，说“照这样再写三个”
拆步骤（思维链）：让AI分步思考，而不是一步到位
设定角色：告诉它“你是一个资深测试工程师”，它输出的风格会不一样
这些技巧背后，其实都是对LLM工作方式的理解——你知道它擅长模式匹配，就给模式；你知道它不擅长一步推理，就拆成几步。
- 尝试一些“AI+测试”的小项目
光看理论没用，得动手。几个练手的思路：
让AI根据接口文档自动生成测试脚本：把Swagger JSON喂给它，让它输出pytest代码
用AI做测试数据生成：给几个种子数据，让AI生成更多类似但不重复的数据
让AI帮你写测试报告：把测试结果喂给它，让它总结失败原因、风险评估
做这些不是为了替代工作，是为了感受“人+AI”的工作方式长什么样。试几次之后，你会发现有些事交给AI很顺，有些事还是自己来更快——这就是边界感。
- 关注行业里的“AI+测试”实践
没必要自己从零摸索，多看看别人怎么做的。比如：
微软的Turing团队在做“AI驱动的测试生成”
谷歌的测试团队在用LLM做缺陷预测
国内大厂也有不少内部工具在尝试用AI辅助测试设计
不一定照搬，但可以看看他们遇到了什么问题、怎么解决的。很多思路是可以迁移的。
五、写在最后：第二曲线不是等来的
管理学里有“第二曲线”的说法：任何一条增长曲线都会滑过抛物线的顶点，持续增长的秘密是在第一条曲线消失之前，开始一条新的曲线。
对于我们测试开发来说，手工测试是第一曲线的起点，自动化测试是第一曲线的爬升，测试开发是第一曲线的高点——那第二曲线是什么？
我觉得，可能是“AI增强的测试开发”。
不是说我们改行去做算法，而是把AI作为新的工具、新的能力，让我们能做以前做不了的事——比如测那些模糊的、动态的、需要理解语义的业务；比如让机器帮我们读文档、写脚本、分析结果；比如把我们从重复劳动里解放出来，去做更多需要判断、设计、决策的事情。
这条路怎么走，我也还在摸索。但有一点越来越确定：第二曲线不是等来的，是学出来的。
所以我的建议是：别怕原理难，也别觉得“我又不搞算法学这干嘛”。抽点时间，了解一点LLM是怎么工作的、能干什么不能干什么。不是为了变成AI专家，是为了让这工具真正为自己所用。
毕竟，工具再强，也得有人知道往哪儿使。
