夜雨聆风📌 3 句话速览
一、那个周末我到底做了什么
上个周末。半夜两点多，老婆孩子睡了，我泡了杯浓茶，本来只是想随手试试。
结果一坐就是六个小时。我把自己日常做 Flaky case 分诊的那一套思路，写成了一个 Claude Code 的 skill 。
不是写工具。是写一份让 AI 替我分诊的说明书。
写完那一刻我有点恍惚。这玩意儿要是早两年就有，我能少加多少班。
跑通后我数了一下：
第二天早上我还在想，这玩意儿到底算不算"工具"。后来想明白了——它不是工具，是把我 10 年踩过的坑，压缩成了一份能被 AI 复用的判断流程。
二、为什么测试工程师比谁都该写
我承认，第一次听到 skill 这个词，我以为又是套壳。
后来翻了几份热门 skill 的源码（Anthropic 官方文档[1]、 GitHub 上的 claude-code-skills-zh[2]），我改了主意。
skill 本质上是带触发条件的提示词包。 Agent 平时看不见它，只在 description 里的关键词被命中时才"被叫起来"加载执行。
这个机制对测试人意味着什么？
意味着你写一次"我会怎么测一个登录接口"，以后所有人——包括 AI——都能照着做。你的隐性经验，第一次有了可以分发的载体。
之前写文档，没人看。写 wiki ，没人维护。写 skill ，至少 AI 会用。
这个落差——挺大的。
三、做对的 3 件事
1. description 不写"是什么"，写"什么时候用"
我写的第一版 description 是这样的：
一个用于 Flaky test 分诊和治理的 skill ，包含分类、修复建议和归因分析。
跑了三次，全没触发。
后来翻别人写得好的，发现规律——description 里要有触发关键词和使用场景，越具体越好。改成：
当用户说 "flaky"、"测试不稳定"、"用例时好时坏"、"门禁被红了" 时触发。分诊 retry 类、环境类、断言类 flaky ，输出修复优先级。
立刻命中。命中率从 0 飙到 4/5 。
这一条原则，比所有"prompt engineering 技巧"都管用。
2. 主文件只放骨架，细节拆到 reference
第一版我把所有判断规则塞进 SKILL.md ，写到 600 多行。 Agent 加载一次烧掉 4000 多 token ，慢得像在拨号上网。
后来拆成：
Agent 只在需要的时候才会 读取: references/xxx.md。这就是官方文档里说的"渐进披露"。
我后来才反应过来，这跟测试用例分层的思路是一样的——冒烟用例放主链路，回归用例放扩展集。别把所有逻辑堆在入口。
3. 用脚本兜底"AI 不擅长的事"
AI 擅长判断和归类，不擅长精确读取一个 1000 行的日志文件。
我在 skill 里挂了一个 30 行的 Python 脚本，专门做日志解析。 Agent 自己调，调完拿结构化结果回来再判断。
读取: scripts/parse_trace.py
执行: python3 scripts/parse_trace.py {trace_path}
这一招让分诊准确率从大概 70% 提到 92%（我手动复核了 25 条做的对比）。
AI + 脚本，分工得当，比纯 prompt 强很多。
四、做错的 3 件事
1. 一开始就想做"通用 skill"
我最初的野心是做一个"能处理所有测试场景"的 skill 。
结果就是 description 写得越来越虚——"用于测试相关的各种任务"——这种描述 Agent 永远不会触发它，因为它跟任何具体场景都对不上。
skill 越窄，触发越准。
第二版我砍到"只处理 Playwright + Pytest 的 flaky"，命中率立刻起来。
也许我想多了。但我现在的判断是——一个 skill 解决一件事，比一个 skill 想解决十件事强 10 倍。
2. 把"教学"和"执行"混在一起
我在 SKILL.md 里写了一大段背景知识——"flaky test 是什么、为什么会出现、行业怎么治理"。
我以为这是在帮 AI 理解上下文。
后来发现 Agent 每次加载都要读这一段，但它根本用不到——它要的是"现在该做什么"，不是"为什么要做"。
把背景拆出去之后，主文件少了 200 行，响应快了一倍多。
给 AI 写指令，不是给人写教程。
3. 没写降级路径
第一版我假定脚本永远跑得通。结果第一次实战，目标项目没装依赖，脚本直接挂掉，整个 skill 卡死。
Agent 不会自己想办法，它会卡在那里报错。
第二版我加了一句：
如果脚本失败，跳过解析，直接用 AI 读取日志文件前 200 行进行模糊判断。
写 skill 跟写测试用例一样——异常路径必须显式覆盖，不能假设。
五、如果重来，我会这么干
3 条具体建议，给打算动手的同行：
至于 skill 的天花板在哪儿——我也不确定。但有一点想清楚了：以后不会写 skill 的测试工程师，跟以前不会写脚本的测试工程师，大概率是同一种处境。
不是被淘汰。是越来越多的活儿，到不了你手里。
写到这里我又有点犹豫。也许我把它说得太重了。但凌晨那杯茶喝完的时候，我是真的觉得——有些东西，已经不一样了。
你那边呢？ 你有没有哪段日常工作，是你脑子里有一套"判断流程"，但从来没写下来过的？评论区告诉我，我挑 3 条最有意思的，下一篇文章帮你拆成 skill 草稿。
参考链接
[1] Anthropic 官方文档: https://code.claude.com/docs/zh-CN/skills
[2] claude-code-skills-zh: https://github.com/laolaoshiren/claude-code-skills-zh
[3] Anthropic 官方仓库: https://github.com/anthropics/claude-cookbooks
