GLM-4.7 真正引爆技术圈的原因，并不只是“又一个更强模型”。大模型竞争，正在从“谁更聪明”， 进入“谁更工程化、谁更能落地”的阶段。这场变化，才刚刚开始。

在数字化转型浪潮下，软件测试领域正经历着一场由大语言模型技术驱动的深刻变革。这场变革不仅仅是技术工具的迭代更新，更是对传统测试方法论和工作流程的系统性重构。作为测试工程师，深入理解这些变化趋势并掌握相关技能，将成为职业发展的关键竞争力。

通过将 Dify 工作流的自动化、可视化能力与大语言模型的创造力和认知能力相结合，我们成功地构建了一个强大、灵活且易于使用的测试数据生成工厂。这种方法不仅极大地提升了数据生成的效率和质量，还让测试数据的创建过程变得前所未有的智能和有趣。无论是为了单元测试、集成测试，还是为了填充演示系统、训练 AI 模型，Dify + LLM的方案都能让你从“造数据”的苦海中解脱出来，将更多精力投入到核心业务逻辑的

模型可能会编造不存在的业务规则或API接口。模型的训练数据可能不包含你项目最新的、特定的业务知识。无法将庞大的产品文档、设计稿、历史用例库全部塞进模型的上下文窗口。RAG恰好能完美地解决这些问题。检索增强生成。其核心思想是，在让大模型回答问题之前，先从你的知识库中检索最相关的信息，然后将这些信息作为上下文提供给模型，最后让模型基于这些“事实依据”生成答案。如GPT-4、ChatGLM、文心一言等，

聊Serverless之前，先说说为什么选Playwright。我们之前用过Selenium，也短暂试过Cypress。Selenium的问题是太“重”了——需要单独管理WebDriver，不同浏览器版本还要操心驱动兼容性，维护成本不低。Cypress在当时只支持Chrome系浏览器，跨浏览器测试这块短板比较明显。Playwright是微软开源的项目，原生支持Chromium、Firefox、We

在 Skill 出现之前，我们扩展大模型能力主要依赖：更复杂的 Prompt外部 Tool 调用Agent 编排流程但这些方式都存在工程问题：Prompt 不稳定 Tool 过于原子化 Agent 复杂度过高Skill 的定位，恰好在 Tool 与 Agent 之间。Tool 是操作层 Skill 是能力层 Agent 是调度层Skill 不是简单封装接口，而是：定义清晰职责约束输入输出结构明确触

同一个需求，有人半天写完用例，有人十分钟交付一套完整测试方案。差距不是经验，也不是加班。而是——有没有用对工具。很多测试同学现在的状态是：需求一来，先自己读一遍，再手动拆测试点写用例靠经验，边界靠补自动化脚本一条条写，改一次需求全跟着改看起来很努力，但效率一直上不去。更现实的问题是：你以为大家都在这么做，其实已经不是了。现在一部分团队的做法是：需求直接丢给模型，先出一版用例自动补齐边界条件顺带生成

上周和几个测试经理吃饭，一桌子人菜没怎么动，全在聊一个话题：团队还要不要养那么多测试执行的人。起因是有个朋友的公司，研发团队开始全面接入 AI 编程助手，顺带试了用大模型直接生成接口测试用例和自动化脚本。结果发现，以前需要两个中级测试工程师干三天的回归测试，现在一个实习生点几下鼠标，一个下午就跑完了。而且覆盖率报告、缺陷分析自动出，连 bug 单都帮你写好。那个朋友说了一句很扎心的话：“我现在看着

AI写报告不是为了让测试工程师失业，而是让测试工程师从重复劳动中解放出来，去做真正需要人的判断力的事情。我们现在测试团队花在报告上的时间从每版本人均4小时降到了20分钟，省下来的时间用来做测试策略设计、故障模式分析和质量度量体系优化——这些才是测试工程师真正的价值所在。如果你现在还在手动整理数据、逐条粘贴Bug、憋半天写“总体质量良好”，我建议你今天就开始试试这个Prompt模板。一杯咖啡的时间，

大模型没那么神秘。它就是那个刚入职、什么都会一点但什么都不精的实习生。你不能指望它自己搞定一切，但有了它，你可以把时间花在真正需要你判断的事情上。下次打开大模型对话窗口的时候，别想“我在跟AI对话”，想“我在给实习生交代工作”。瞬间就知道该怎么用了。