前几天刷到一篇 QA 写的复盘，讲她用 Claude 加 Obsidian 搭日常工作流。同行的东西我一般扫两眼就翻篇，这篇读完了，还往回翻了两遍。
不是因为她搭得多花哨。是因为她无意中把一件事的最难版本做出来了，然后没给这件事上保险。
先把结论甩这儿：那套东西里最值钱的不是 Obsidian，也不是把 Claude Code 塞进笔记软件的那个插件。是"拿团队反馈反过来改模板"的那条回路。最大的窟窿，是这条回路现在靠人肉在跑——没有断言，没有回归，没有版本。
她搭了什么
三块：Templates、Skills、Plugins。
模板是三类笔记格式，技术任务一类，业务任务一类，会议记录一类。技术任务模板拿去给数据库迁移、consumer 创建、API 这些活生成测试计划；业务任务模板用在 product discovery 阶段，跟 PO 一起把测试层级、风险和缓解方式定下来。
skills 三个，按我觉得有意思的程度排：
第一个，喂一个 Jira 任务 ID 进去，它去拉任务上下文，按 CLAUDE.md 里的说明去 Confluence 找参考页面，套上已有模板，吐出一份 Markdown 测试计划。
第二个，接 Atlassian MCP，把打了某个标记、但没有测试计划的任务捞出来，写进一个 Markdown 文件，再用 Kanban 插件当待办看板管起来。
第三个，把定好的用例发到 Zephyr。
画外音：一个 QA，把"找出哪些东西没人测"这件事本身做成了一个 skill，然后这个 skill 没有人测。
这不是玩梗。第二个 skill 的存在本身就说明她清楚"漏"比"错"可怕——错的用例跑起来会红，漏的场景不会，它只会静默地少一行。可这套逻辑她只对被测系统用了，没对自己这套工具用。
整条链路里没有一个地方会报错
那个测试计划 skill，链路大概长这样：
Jira ID
→ 拉任务上下文（MCP）
→ 按 CLAUDE.md 的说明去 Confluence 找对应参考页
→ 套模板
→ 输出 Markdown 测试计划
每一步都是软约定。"去 Confluence 找参考内容"不是函数签名，是一句人话。页面改了标题、挪了 Space、权限变了，或者 Jira 那边把验收标准从 description 挪到了自定义字段——哪一处动了，这个 skill 都不会报错。它会安静地、格式完整地产出一份缺了一大块的测试计划。
缺了一块的东西看起来是完整的。标题在，层级在，格式对，你扫一眼没有任何理由怀疑它。
我上一个项目里栽过几乎一样的跟头。CLAUDE.md 里本来有一条：
# CLAUDE.md 片段
- 生成测试计划前，从 Confluence 的 "QA Reference" 页面读取本模块的边界说明
- 测试计划必须包含：正常流 / 边界值 / 异常流 / 回滚方案
后来我觉得列点太啰嗦，把"必须包含回滚方案"这句挪进了下面的一段话里。就这一下，模型不写了。三天后才发现——还是因为一个同事随口问了句"这个回滚怎么不写"。
注意这两条的性质不一样。第一条是让模型去"找"，找不到引用是空的，你至少能看出来；第二条是让模型自己保证"写了"，它失败的时候会写一句话把位置填满，你看不出来。后者才是这个 pipeline 里最滑的地方。
改一个排版级别的东西，行为就变。这不是模型的错，是我从来没给这句话上过任何约束。
我要是她，先补这三样
"给 AI 产物加测试"这事不玄。无非分两类：能机器判的，和只能人判的。第一类现在就能补，补起来难看，但有效。
一、把结构钉死成脚本能查的东西。
要求测试计划必须有哪些小节，就写一段脚本逐条查。蠢是蠢，但它抓的正好是"模型自己永远会说做了"的那类缺失。
# 笨办法：测试计划的结构检查
for section in "正常流" "边界值" "异常流" "回滚方案"; do
grep -q "$section" "$PLAN" || echo "MISSING: $section in $PLAN"
done
二、让引用变成可验证的引用。
要求输出里带上它引用的 Confluence 页面 ID 或链接，然后拿这些 ID 真去请求一次。拉不到就 fail，而不是让模型自己糊一段"根据相关文档"。改动很小，但它把"它说自己查了"变成了"它确实查到了"。
三、攒一个历史回归集。
这条是重点。从过去几个月的 Jira 里挑五个任务，它们的测试计划是人写的，事后证明是完整的。以后每次改模板、改 CLAUDE.md、换模型，都拿这五个重跑一遍，跟人工基线做 diff。
评论区里有人说到了这条，我认为这人是真懂行。大意是：多模型路由里供应商之间的差异会随时间变，模型行为可能在供应商那一侧悄悄改了，而你这边一行代码没动。
对普通代码这叫依赖漂移，你有 lockfile、有 CI、有 dependabot 天天敲你。对 skill 来说，你什么都没有。你的 skill 是拿自然语言写的，跑在一个你看不见、也锁不住的依赖上，唯一能发现它变了的方法，就是定期拿已知答案的输入去撞它一次。
最值钱的和最会被抄错的，正好是反的
她文章里有一段，说这套流程真正的挑战是审 AI 产出的内容——收集团队对生成测试和数据的反馈，看表达清不清楚、覆盖全不全，然后拿这些反馈去更新模板，加有用的上下文，删掉不适用的。
这是整篇里最值钱的一段，比那两个插件值钱得多。只是她自己把它写成了一个"挑战"，而不是一个"系统"。
它现在的形态是：反馈进她的脑子，她判断哪儿不对，改模板。下一次生成得好不好，取决于她这次改得准不准。跟人肉测试一个味道——有效，但不沉淀。团队这次指出漏了什么，本该变成下一轮能自动检查的一条，现在它躺在记忆里，等下次开会她自己想起来。
她自己搭的第二个 skill 就是干这个的：把"检查"从记忆变成一个能跑的东西。她只是没对自己这套工作流再用一遍。
至于那两个插件——一个是在 vault 目录里开终端，好让你在 Obsidian 里面直接用 Claude Code；一个把所有可用的 skill 列出来，从 Obsidian 里直接跑。
它们会被抄。截图好看，步骤清楚，"在笔记软件里跑 Claude Code"这句话本身就有传播力。
但这是整套东西里最不值得先抄的部分。真正让她少干活的，是那些不好看的模板、是 CLAUDE.md 里那句"按指定去 Confluence 找参考"、是那条"拿反馈改模板"的习惯。这些没法截图。
所以看到她说插件还没到最终版、还没上社区商店、仓库里放了本地使用步骤，我第一反应是：挺好，别急着上架。上架之后一堆人装完跑不起来，锅还是插件的。
（跑题两秒：她说从 Notion 迁到 Obsidian 的一个原因是，Notion 的视觉定制让她花在做模板上的时间比填内容还多。这个我信，我自己在 Notion 上折腾布局的时间够我写三篇复盘 😅 扯远了。）
回到最开始那个结论。她的模板和 skill 是资产，插件是门面，团队反馈回路是发动机。发动机和资产之间少了一根轴——没有回归集，没有结构检查，没有可验证的引用。
以后我改任何 CLAUDE.md 或者模板，先跑一遍那五个历史 case，diff 跟人工基线比；没有基线就先攒基线，攒完再改。
你手上那套 CLAUDE.md 和 skills，有没有一个东西能在换模型之后立刻告诉你"输出变了"？没有的话，你缺的不是配置，是那五个 case。