目录
一、新人来了三个月还写不出稳定脚本，这不是能力问题
二、本质不是“没人教”，而是“知识被锁死在人脑里”
三、核心机制拆解：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的时候：
翻Wiki，找到一篇三个月前写的“订单测试指南”，里面引用的选择器已经过时。
问老人，老人给他扔了一个内部群聊天记录，里面有一句“注意审批按钮在status=ready后才出现”。
尝试写脚本，用了time.sleep(5)，有时过有时不过。
调试到第二天，发现还需要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有几个。）
