交付速度一快测试人员最先感到的不是忙而是不确定我是不是漏了什么覆盖的场景是不是真的够。这种焦虑靠加班解决不了得靠一套能查、能复用、能自动补全上下文的记录方式。有人把笔记工具换成 Obsidian再把 Claude 接进来日常测试工作就不再完全依赖记忆。Obsidian 本身是一个本地笔记和知识管理工具文件以 Markdown 格式存在电脑上。想要云端同步可以用付费版本或者装社区插件。它吸引人的地方不是功能多而是干扰少。之前用 Notion 时页面外观能调的东西太多容易把时间花在改模板样式上真正写进去的内容反而少了。换成 Obsidian 之后界面干净注意力更容易留在笔记本身。另一个现实考虑是数据安全。测试工作常接触内部系统、接口说明和业务规则笔记存在本地会让人更放心。Obsidian 也支持装外部插件来补功能但不会把主界面塞满。更重要的是Markdown 文本和 AI 工具配合起来很顺AI 生成的内容直接就是笔记格式不用来回转换。把 Obsidian 当第二大脑来用第一步不是装插件而是先固定几类经常写的文档。测试人员至少有三类模板值得提前建好。一类是技术任务模板。数据库迁移、消费者创建、接口开发这类工作测试计划的结构往往相似每次新建笔记时直接套用能省掉重复搭框架的时间。另一类是业务任务模板用在更早的阶段比如和产品负责人一起做产品发现时用来梳理新功能可以加哪些测试层、有哪些风险、怎么缓解、上线后怎么衡量是否成功。还有一类是会议笔记模板记录会议关键信息和待办也可以用来准备自己要主持的会议。模板解决的是格式统一技能解决的是重复动作。Claude 的技能可以理解成一段预设好的指令调用时按固定流程执行减少每次重新描述需求的时间。第一个技能用来生成测试计划。给它一个 Jira 任务编号它会先去取这个任务的上下文再到 Confluence 里找相关参考内容然后按事先建好的模板输出一份 Markdown 测试计划。整个过程不用手动复制粘贴。第二个技能用来找漏掉计划的任务。它通过 Atlassian 的 MCP 连接筛选出带特定标记、需要写测试计划但还没写的任务把结果写进一个 Markdown 文件再用看板插件展示方便安排优先级。第三个技能负责发布测试用例把已经规划好的用例推到 Zephyr 里这是日常管理测试的工具。插件方面看板插件一直在用用来跟踪任务状态。后来发现两个需求在社区商店里找不到现成的就自己写了。一个插件的作用是在 Obsidian 里打开当前库所在目录的终端这样不用切窗口就能运行 Claude Code。另一个插件用来列出所有可用的技能并且直接在 Obsidian 里执行。两个插件都还不算最终版本也没上架社区商店但仓库里写了本地使用的步骤。把模板、技能和插件串起来之后一个典型流程是这样的。假设拿到一个任务编号它来自产品侧的产品发现或史诗。先调用技能技能根据编号去 Jira 拉取任务背景再到 Confluence 找参考资料结合业务任务模板生成一份初步的测试计划草稿。草稿进入 Obsidian 后用看板插件标记状态提醒自己下一步要做什么。如果任务属于技术类型流程类似只是换成技术任务模板关注的测试层和风险点不同。最后确认好的用例通过发布技能推到 Zephyr。这套做法并没有让测试工作变成全自动。AI 生成的内容仍然需要人工检查尤其是测试场景是否覆盖完整、数据准备是否合理。比较有效的做法是收集团队对生成测试的反馈看看哪里描述不清、哪里漏了场景再回头改模板。模板本身也不是一次定型的用得多了会发现某些上下文需要补充某些段落其实没必要保留就随时调整。对测试人员来说值得先做的不是研究所有插件而是选一个自己最常写的文档类型建一个模板把重复的结构固定下来。等模板用顺了再考虑用技能把取上下文、找任务、发用例这些动作串进去。工具只是载体真正减少遗漏的是把上下文留在可查的地方让每次测试都有迹可循。