我如何用Skills-RAG构建企业级测试知识库，新人上手自动化只需1天

目录

一、新人来了三个月还写不出稳定脚本，这不是能力问题
二、本质不是“没人教”，而是“知识被锁死在人脑里”
三、核心机制拆解：Skills-RAG 怎么让知识可检索、可执行
四、典型案例对比：一个新人两天 vs 一天，差别在哪
五、工程落地启示：你的知识库不应该是一堆文档
六、问你的团队一个问题

一、新人来了三个月还写不出稳定脚本，这不是能力问题

去年我们团队扩招，三个月里来了四个新人。
背景都不差，两个有Python基础，一个用过Selenium。

但第一个月，没有人能独立跑通一条完整的端到端用例。

不是卡在Playwright API，就是卡在等待策略写错，或者不知道某个业务模块的特殊校验逻辑。

老人被问得烦了，丢过去一堆文档链接。
新人看了两天，回来继续问同样的问题。

我意识到一个问题：
不是新人学不会，是我们的知识传递方式还停留在石器时代。

文档写得再详细，新人不知道“什么时候该看哪篇”。
老人再耐心，也记不住所有坑。

更讽刺的是，每次有人踩过的坑，下一个人大概率会再踩一遍。

这个行业有一个公开的秘密：
自动化测试的入门门槛从来不是技术，是那些散落在人脑、聊天记录、过期Wiki里的隐性知识。

二、本质不是“没人教”，而是“知识被锁死在人脑里”

很多团队认为，知识库就是一堆Markdown文档。

错了。

文档是死的。
人脑是活的，但不具备可复制性。

本质问题是：知识的生产、存储、检索、应用这四个环节，在绝大多数团队里是断裂的。

• 生产：老人写代码时随手解决了一个定位器失效问题，这个经验没有沉淀。
• 存储：沉淀了，放在Wiki或Confluence，没人记得路径。
• 检索：新人遇到问题时，根本不知道搜索什么关键词。
• 应用：即使搜到了，文档里写的是“注意xxx”，没有可执行的代码或校验逻辑。

Skills-RAG这个想法，就是为了把这四个环节串成一个闭环。

RAG（检索增强生成）大家不陌生，但多数人拿来做问答机器人。
我们把它用在测试知识库上，目标很明确：
让新人用自然语言提问，系统直接给出可复用的测试代码片段 + 上下文解释 + 注意事项。

不是再给一篇文档，是给一个可以直接用的“技能块”。

三、核心机制拆解：Skills-RAG 怎么让知识可检索、可执行

先看清架构，再讲细节。

拆解三个核心机制。

机制一：Skill不只是代码片段，而是“带元数据的可执行单元”

我们定义了一个Skill的最小结构：

skill_id: login_with_error_handling
场景:登录功能测试
适用组件:LoginForm
触发条件:用户需要测试登录失败/成功
代码模板:|
  def test_login(self, username, password, expected_error=None):
      page.goto("/login")
      page.fill("input[name='username']", username)
      page.fill("input[name='password']", password)
      page.click("button[type='submit']")
      if expected_error:
          page.wait_for_selector(f"text={expected_error}", state="visible")
      else:
          page.wait_for_navigation()
常见坑:
-密码字段可能是readonly（需先点击启用）
-失败后错误提示可能出现延迟，需wait_for_selector
关联Skill:[wait_for_navigation,toast_message_assert]

每个Skill都包含：适用场景、触发条件、代码模板、常见坑、关联Skill。

本质是：把经验变成结构化的知识单元，而不是散落的笔记。

机制二：检索不是关键词匹配，是语义场景匹配

新人不会问“如何处理登录后的异步加载”，他会问“为什么登录完点不了下面的按钮”。

我们用向量化模型把问题转成向量，去检索最接近的Skill场景描述。

比如“登录完点不了按钮”会命中wait_for_navigation和post_login_ready两个Skill。
召回的不是文档标题，而是可执行的解决方案。

机制三：应用层的动态组装

召回Top-K个Skill后，不直接丢给新人。
通过LLM把这些Skill拼成一个完整的答案，同时保留原始代码块和注意事项。

输出格式是固定的：

## 解决方案
[自然语言解释]

## 可执行代码
[基于Playwright/Pytest的代码块]

## 需要注意
- 坑1: ...
- 坑2: ...

## 你可能还需要
- [关联Skill A]
- [关联Skill B]

新人复制代码，改几个参数就能跑。
不需要理解背后的所有细节，但每一次使用，都在强化对Skill的认知。

四、典型案例对比：一个新人两天 vs 一天，差别在哪

说个真实案例。

我们有一个老模块，“订单审批流程”。涉及状态机、权限校验、异步回调。
过去新人上手平均需要2.5天才能跑通第一个正向用例。

引入Skills-RAG之后，我让一个新来的校招生试了试。

没有Skills-RAG的时候：

1. 翻Wiki，找到一篇三个月前写的“订单测试指南”，里面引用的选择器已经过时。
2. 问老人，老人给他扔了一个内部群聊天记录，里面有一句“注意审批按钮在status=ready后才出现”。
3. 尝试写脚本，用了time.sleep(5)，有时过有时不过。
4. 调试到第二天，发现还需要mock某个权限接口，没人告诉他。

两天半，用例还没完全稳定。

有Skills-RAG之后：

他问了一句：“怎么测订单审批成功？”

系统返回：

• Skill：order_approve_flow
• 代码模板：包含了状态轮询、按钮等待、权限mock
• 常见坑：审批按钮的出现依赖WebSocket推送，不能用wait_for_selector，要用wait_for_function监听状态变量

他直接复制，改了订单ID和断言文案。
跑通。
总耗时：半天。

第二天，他又问了一个新问题，系统推荐了关联Skill，他自己组合出了异常场景用例。

一天时间，从零到能独立贡献用例。

可以被截图传播的观点句：

知识不是用来读的，是用来执行的。Skills-RAG把文档变成可运行的能力。

新人的上手速度，取决于你的知识库是“可搜索的文档”还是“可检索的技能”。

五、工程落地启示：你的知识库不应该是一堆文档

如果你现在就想动手，有三条落地建议。

启示一：从高频痛点场景开始拆Skill

别一上来就想覆盖所有业务。
挑10个最常被问的问题，比如“登录”、“分页等待”、“文件上传”、“弹窗处理”。
每个拆成Skill：场景 + 代码模板 + 坑。

数量不重要，覆盖率重要。
覆盖了80%的新人问题，剩下的20%他们会自己学会拆解。

启示二：向量检索 + LLM生成，不需要自研大模型

我们用开源模型bge-large-zh-v1.5做向量化，Chroma做存储，GPT-3.5或本地Qwen做生成。
成本极低，效果够用。

关键是打磨Prompt，让LLM严格按照Skill结构输出，不要自由发挥。

启示三：让技能贡献成为技术债的一部分

每解决一个线上环境导致测试失败的新问题，要求当事人沉淀一个Skill。
不是自愿，是流程。
不做，不开MR。

这样知识库才有生命力，不会三个月后腐烂。

对在校生来说：
你现在就可以开始练习“拆解技能”的思维。拿到一个测试场景，别急着写代码。先问自己：这个场景的核心Skill是什么？前置条件是什么？常见坑有几个？这个思维比任何框架都值钱。

对初级工程师来说：
试试用RAG搭建一个个人测试知识助手。把你踩过的坑全部结构化。三个月后你会发现，你解决问题的能力远超同龄人。

六、问你的团队一个问题

去你团队的Wiki或知识库首页，随便点开三篇测试相关的文档。

问自己一个问题：

如果明天来一个新人，只靠这三篇文档，他能不依赖任何人的口头解释，独立写出一个能跑通的生产级用例吗？

如果答案是不能。
那么问题不在新人，在你的知识库。

（评论区告诉我，你们团队的知识库里，活的Skill有几个。)