[测试技术] Obsidian 是什么？一个适合长期沉淀知识的本地笔记工具

原创内容，未获授权禁止转载、转发、抄袭。

很多人做笔记，最后都会遇到一个问题：

东西记了很多，但真正要用的时候找不到。

需求评审记录、测试总结、Bug 复盘、接口说明、排查经验、工具配置，散在飞书、钉钉、文档、截图、聊天记录里。

时间久了，就变成“写过，但找不到”。

Obsidian 解决的就是这个问题。

它不是普通笔记软件。

更准确地说，它是一个本地 Markdown 知识库工具。

Obsidian 的核心特点

Obsidian 最大的特点是：

笔记存在本地。 内容是 Markdown。 笔记之间可以互相链接。

它的每一篇笔记，本质上都是一个.md文件。

这些文件放在一个本地文件夹里，Obsidian 把这个文件夹叫做 Vault。

这点很重要。

因为你的笔记不是被锁在某个云平台里，而是保存在自己电脑上。即使以后不用 Obsidian，这些 Markdown 文件也还能用 VS Code、Typora、Notepad 等工具打开。

这也是我觉得 Obsidian 比很多在线笔记工具更适合长期沉淀知识的原因。

它和普通笔记软件有什么区别

普通笔记软件更像文件柜。

你要先想好放在哪个文件夹。

比如：

测试工具 接口测试 自动化测试 线上问题复盘

但实际工作里的知识，经常不是单一分类。

比如一篇“支付回调问题复盘”，它可能同时属于：

• 支付
• 接口测试
• 幂等
• 线上问题
• 自动化回归
• 质量看板

如果只靠文件夹，就很难放。

Obsidian 更推荐用链接组织知识。

比如在一篇笔记里写：

这次问题和 [[支付回调]]、[[订单状态流转]]、[[接口幂等]] 有关。

这样这些笔记之间就连接起来了。

以后你打开“接口幂等”，就能看到有哪些笔记引用过它。

这就是 Obsidian 的双向链接。

双向链接适合沉淀经验

双向链接最适合记录经验类内容。

比如测试团队经常会遇到这些问题：

为什么支付成功了，权益没到账？ 为什么页面提示成功，但数据库没写入？ 为什么接口返回 200，业务状态还是失败？ 为什么自动化偶现失败？ 为什么优惠券重复领取？

这些问题不适合只放在一个“问题记录”文件夹里。

更适合按知识点串起来。

比如一篇复盘可以这样写：

# 支付成功后权益未到账复盘 关联知识： - [[支付回调]] - [[订单状态流转]] - [[消息队列消费失败]] - [[接口幂等]] - [[自动化回归范围]] 问题原因： 支付回调成功后，权益发放消息消费失败，页面只展示了支付成功，但没有继续校验权益到账状态。 测试补充： 后续支付成功后，需要同时验证订单状态、支付流水、权益发放记录。

这样写的好处是，后面再遇到类似问题，不是重新翻聊天记录，而是能顺着链接找到历史经验。

Graph View 不只是好看

Obsidian 有一个 Graph View，可以把笔记之间的连接展示成图谱。

很多人第一次看到会觉得很酷。

但它真正的价值不是好看。

而是帮你发现哪些知识点经常被关联。

比如你发现很多笔记都连到了：

接口幂等 订单状态流转 支付回调 权限校验 优惠券返还

这说明这些就是你团队高频踩坑点。

这些点就值得沉淀成测试规范、检查清单、自动化回归重点。

Graph View 不一定每天都看。

但做阶段性复盘时很有用。

Canvas 适合梳理复杂问题

Obsidian 还有一个 Canvas 功能。

它像一块无限画布，可以把笔记、图片、网页、文本卡片放在一起，再用线连接起来。

这很适合梳理复杂问题。

比如排查一次线上问题，可以把这些信息放进 Canvas：

• 用户反馈
• 接口请求
• 日志截图
• 订单状态
• 支付流水
• 时间线
• 初步结论
• 后续改进

相比一篇长文档，Canvas 更适合做问题分析图。

比如：

用户支付成功 ↓ 支付回调成功 ↓ 订单状态已支付 ↓ 权益发放消息失败 ↓ 用户权益未到账

这种链路放在 Canvas 里会很清楚。

Properties 和 Bases 让笔记更结构化

Obsidian 不只是写散文式笔记。

它也支持 Properties，也就是给笔记加结构化字段。

比如一篇 Bug 复盘可以这样写：

---type:bug-reviewsystem:paymentpriority:highstatus:closeddate:2026-07-01tags:-支付-回调-幂等---

这些字段可以用来筛选和整理。

新的 Bases 功能，可以基于这些 Properties 做类似表格、卡片的视图。

比如你可以做一个“线上问题复盘库”：

注意，Bases 不是传统数据库。

它本质上还是基于本地 Markdown 和 Properties 做视图。

这个设计的好处是：内容还是 Markdown 文件，不会被复杂系统锁死。

插件很强，但别一上来装太多

Obsidian 的插件生态很丰富。

官方也支持社区插件和主题。

常见插件有：

• Calendar：日历
• Kanban：看板
• Dataview：查询笔记
• Tasks：任务管理
• Excalidraw：画图
• Templater：模板增强

但新手不要一上来装一堆插件。

插件越多，系统越复杂，维护成本也越高。

我更建议先用原生功能跑起来：

Markdown 文件夹 双向链接 标签 Properties Canvas 搜索

等真的遇到痛点，再补插件。

工具应该服务于工作流，不要为了折腾插件而折腾。

测试人员可以怎么用

如果是测试人员，我建议从这几类内容开始沉淀。

第一类，测试经验。

接口测试怎么判断业务成功 支付回调怎么测幂等 优惠券领取怎么测并发 权限测试怎么防越权 弱网测试到底测什么

第二类，问题复盘。

线上问题原因 漏测点 影响范围 补充用例 后续自动化

第三类，工具配置。

Charles 配置 JMeter 参数化 Playwright 调试 Jira 导入用例 测试环境排查

第四类，团队规范。

用例评审标准 上线检查清单 接口断言规范 自动化脚本规范 Bug 描述模板

这些内容如果散在聊天记录里，很快就会丢。

放进 Obsidian，并用链接串起来，才会逐渐变成团队知识资产。

一个简单目录结构

刚开始不要设计太复杂。

可以先这样建：

测试知识库/ 00_索引/ 01_测试方法/ 02_业务知识/ 03_问题复盘/ 04_工具配置/ 05_团队规范/ 06_模板/

再建几个入口笔记：

测试知识地图.md 接口测试索引.md 自动化测试索引.md 线上问题复盘索引.md 工具配置索引.md

入口笔记里放链接。

比如：

# 接口测试索引 ## 核心方法 - [[接口返回 code=200 就代表成功了吗]] - [[接口测试为什么要看数据库]] - [[接口幂等怎么测]] ## 业务场景 - [[支付回调怎么测]] - [[订单取消接口怎么测]] - [[优惠券领取怎么测]]

这样比纯文件夹好用。

因为知识不是只靠分类，而是靠链接不断长出来。

Obsidian 不适合什么

Obsidian 也不是万能的。

它不适合替代多人在线协作文档。

如果团队要多人同时编辑、评论、审批，飞书文档、钉钉文档、Confluence 这类工具更合适。

它也不适合当正式测试管理平台。

用例执行、缺陷流转、测试计划、报表统计，还是应该放在专业系统里。

Obsidian 更适合做个人或小团队的知识沉淀。

比如：

经验总结 问题复盘 测试方法 工具配置 学习笔记 业务理解

一句话：

协作交付用在线文档。 过程管理用测试平台。 长期知识沉淀用 Obsidian。

我的建议用法

如果刚开始用 Obsidian，不要想着一步到位。

可以先做到三件事：

第一，每次解决一个问题，写一篇复盘。

第二，每篇复盘至少链接 2 到 3 个相关知识点。

第三，每周整理一次索引，把零散笔记串起来。

比如今天排查了一个支付问题，就写：

支付成功后权益未到账复盘

然后链接到：

[[支付回调]] [[权益发放]] [[消息队列]] [[接口幂等]]

时间长了，你会发现自己的知识库越来越像一张网。

这才是 Obsidian 真正有价值的地方。

一句话总结

Obsidian 不是用来把笔记写得更漂亮。

而是用来把知识连起来。

它适合长期沉淀：

• 测试经验
• 问题复盘
• 业务规则
• 工具配置
• 团队规范
• 学习笔记

如果你只是临时记一段文字，用什么工具都差不多。

但如果你想把几年工作经验慢慢沉淀成自己的知识库，Obsidian 很值得试试。