一、引子：Obsidian 给我的启发

最近一直在用 Obsidian 做知识管理，用着用着发现一个有趣的事——Obsidian 的组织方式，跟我做了6年的自动化测试，本质上是一回事。

Obsidian 怎么工作的？简单说就三样东西：

• 根目录的配置：告诉软件去哪里找东西、用什么规则运行
• 资源的路径：笔记文件、附件图片、模板文档，都有自己的位置
• Skill 的执行：各种插件和脚本，按需调用

这三样东西组合在一起，就形成了一个灵活的知识管理系统。你想加一个新功能，不需要动核心代码，加个配置、放个文件、调个插件就行。

这个"核心不变，外围扩展"的思路，让我想到了自动化测试。

二、类比：传统自动化测试框架的本质

做了6年自动化测试，回头看我们平时搭的框架，其实也是这个结构：

核心代码：就像 Obsidian 的程序本身，提供基础能力——驱动浏览器、发请求、断言结果。

外部资源：测试数据、配置文件、页面元素定位、环境变量……这些就是 Obsidian 里的笔记和附件。

执行调度：Jenkins 定时任务、TestNG 的 testng.xml、pytest 的 mark 机制——相当于 Obsidian 的插件和快捷键。

但问题是，我们以往的自动化策略，往往是"核心代码 + 外部资源"的简单叠加。测试用例写在代码里，数据和配置放在文件里，看起来分了层，实际耦合还是很紧。

改一个测试用例，要改代码、改数据、改配置，有时候还得改框架本身。维护成本随着用例数量线性增长，甚至更快。

有没有办法像 Obsidian 那样，真正把"配置""资源""执行"彻底解耦？

三、方案：MCP Server + 文档驱动的新范式

AI 时代出现了一个很合适的工具——MCP Server（Model Context Protocol Server）。

MCP Server 的核心能力，就是把各种外部工具和资源通过标准协议暴露给 AI 模型去调用。你可以把它理解为"工具的中介"。

把这个思路放到自动化测试里，就变成了这样一个架构：

3.1 文档即用例

测试用例不再写在代码里，而是写在文档中——就像 Obsidian 里的 Markdown 文件。每一条测试用例就是一个文档，包含：

• 前置条件（配置）
• 操作步骤（流程）
• 预期结果（断言）
• 依赖资源（数据文件路径、页面元素定位）

这些文档放在一个结构化的目录里，用 Obsidian 或者任何 Markdown 编辑器都能维护。

3.2 MCP Server 作为执行层

测试用例写好之后，由 MCP Server 来负责"读文档 + 调工具 + 执行测试"。

具体流程：

文档目录
    ↓
MCP Server 读取文档，解析用例
    ↓
根据用例内容，调用对应工具
（浏览器驱动 / API 客户端 / 数据库连接器）
    ↓
执行测试，返回结果

MCP Server 不需要知道具体的测试逻辑，它只负责两件事：

1. 读懂文档里的指令
2. 调用正确的工具去执行

3.3 这个模式好在哪

维护成本低：改测试用例就是改文档，不需要碰代码。产品经理、测试人员都能直接参与。

解耦彻底：框架代码、测试数据、执行引擎各自独立。换一个框架，文档不用动；换一套数据，代码不用动。

AI 友好：文档本身就是 LLM 最容易理解的形式。未来可以用 AI 自动生成测试用例、自动分析失败原因、自动补全测试场景。

扩展性强：加新工具就是给 MCP Server 加一个 Skill，跟 Obsidian 装插件一样。

写在最后

这个想法还在探索阶段，不是成熟方案，但它代表了一个方向——让自动化测试从"写代码"变成"维护文档"。

Obsidian 通过"配置 + 资源 + Skill"的架构，让知识管理变得灵活可扩展。自动化测试为什么不能这样？

MCP Server 的出现，给了我们一个很好的实践基础。接下来的问题是：怎么把这套想法落地成可用的工具？

这是我接下来想探索的事情。