知识库与工具链整合：从碎片化到体系化的 AI 测试知识底座

知识库与工具链整合：从碎片化到体系化的 AI 测试知识底座

作者：浅木·先生

日期：2026 年 6 月 16 日

---

一、引言：一个测试团队的「知识之痛」

"这个系统的自动化脚本在哪个目录？""上一个版本的测试策略文档发我一下。""那个缺陷的根因分析写在哪了？"------这些对话，每天发生在每一个财政系统测试团队里。

过去五年，我经历了几轮财政领域核心业务系统的测试工作，从预算编审到国库集中支付，从非税收入到政府采购。每一个子系统都对应一套完整但彼此孤立的测试资产：成千上万条手工编写的测试用例、几百份年度测试策略报告、深埋在各版本分支里的自动化脚本、散落在微信群里的故障复盘记录。

我们面临一个典型的「碎片化困局」：

• 知识分布散乱：测试用例在 Excel 里，自动化脚本在 Git 仓库里，配置项在 Wiki 里，共识在人的脑子里。
• 检索成本高昂：一个新人从入职到独立完成一条完整的自动化测试，平均需要 45 天------因为他要问六个人、翻五个网址、读三份过期文档，才能拼凑出正确的操作流程。
• 工具链各自为政：接口测试用 Postman，UI 测试用 Selenium，性能测试用 JMeter，用例管理用 TestRail，缺陷管理用 Jira------每一个工具都产生自己的数据，但数据之间没有桥梁。
• 知识流失严重：核心骨干离职时带走的不仅是代码，更是对业务的理解、对边界条件的记忆、对历史缺陷根因的直觉。这些「隐性知识」几乎无法传承。

这是一个典型的「数据丰富，知识贫乏」困局。我们拥有海量的信息资产，却没有建立起从「信息」到「知识」再到「智慧的转化管道」。

2025 年末，我开始带领团队探索一条新路：以开源智能体框架 Hermes Agent 为中枢，以 Obsidian 为知识载体，整合 RAG 检索增强生成技术，构建一个面向财政系统测试场景的 AI 知识底座。目标是让知识从碎片走向体系，让工具从割裂走向整合，让团队的经验成为可传承、可检索、可对话的数字资产。

经过半年的迭代与落地，我们取得了一些真实可见的效果：新人上手周期从 45 天压缩到了 7 天，测试策略检索效率提升了 80% 以上，历史缺陷的根因复盘准确率达到了 91%。更重要的是，我们成功将这套方案部署在内网环境中，通过了等保三级的合规审计。

本文将完整回顾这个过程中的技术选型、架构设计、搭建造坑与工程落地，希望能为同样在财政系统（或类似强合规、内网封闭环境）中挣扎的测试团队提供一些参考。

---

二、核心理念：为 AI 构建「会思考的知识底座」

在动手搭东西之前，我们必须回答一个根本问题：我们的知识库到底要解决什么问题？

我把它归结为三个层次------

2.1 第一层：解决「找不到」------ 从被动存储到主动检索

传统知识库的本质是一个「文件柜」：你存进去，别人得知道关键词才能搜出来。而 AI 知识库应该是一个「咨询顾问」：你用自然语言提问，它就能理解意图、召回上下文、给出精准答案，并附上可信的来源。

这就意味着，我们的知识库不能只存 Markdown 文件，还要存语义向量 ，要建立关键字索引 + 向量检索的双路召回机制。

2.2 第二层：解决「学不会」------ 从静态文档到技能自动化

测试团队的知识不仅仅是「文档」，还有「流程」：怎么搭环境、怎么写用例、怎么跑回归、怎么分析缺陷。这些流程性知识，传统的 Wiki 无法表达。

我们的方案引入了 Hermes Agent 的 Skills 机制------把高频重复的测试操作封装成可复用的「技能」（SKILL.md），让 AI 代理不仅能「读」文档，还能「执行」动作。比如：

• 查缺陷 → 自动从 Jira 拉取缺陷列表，按严重度和影响面排序
• 写测试用例 → 根据需求文档自动生成用例框架，附上等价类和边界值建议
• 环境检测 → 自动检查被测系统的服务状态、数据库连接和关键日志

2.3 第三层：解决「传不下」------ 从个人经验到组织记忆

这是我个人最关注的一层。一个工作了五年的测试老手，脑子里装着几百个「隐含的前提条件」------比如「这个模块的并发测试要在凌晨两点跑，因为白天有定时任务会干扰数据」------这些知识没有任何文档记录过。

我们通过 Hermes 的持久记忆系统 ，让每一次问题排查、每一次策略讨论都被记录、被结构化、被索引。当新人问「这个模块的并发测试注意什么」时，AI 能够回忆起半年前老同事的讨论记录，给出准确的提醒。这就是组织记忆的价值。

---

三、整体架构设计

基于上述理念，我们设计了一套四层架构的 AI 知识底座系统。以下为架构示意图（文字描述）：

┌─────────────────────────────────────────────────────┐
│                   用户交互层                          │
│  ┌─────────┐  ┌─────────┐  ┌───────────────────┐   │
│  │ Hermes  │  │ Obsidian│  │ Web 门户（内网）  │   │
│  │   CLI   │  │   客户端 │  │  (知识库浏览)     │   │
│  └────┬────┘  └────┬────┘  └────────┬──────────┘   │
├───────┴────────────┴────────────────┴──────────────┤
│                   智能调度层                          │
│  ┌─────────────────────────────────────────────┐   │
│  │        Hermes Agent（核心引擎）              │   │
│  │  ┌──────────┐ ┌──────────┐ ┌──────────┐    │   │
│  │  │ Skills管理│ │ 记忆系统 │ │ 工具调度 │    │   │
│  │  └──────────┘ └──────────┘ └──────────┘    │   │
│  │  ┌──────────────────────────────────┐      │   │
│  │  │     LLM 路由（本地/远程）         │      │   │
│  │  └──────────────────────────────────┘      │   │
│  └─────────────────────────────────────────────┘   │
├────────────────────────────────────────────────────┤
│                   知识存储层                         │
│  ┌──────────┐ ┌──────────┐ ┌──────────────────┐   │
│  │ sqlite-vec │ │ 文件系统 │ │ 关系型数据库    │   │
│  │ (向量库)  │ │(Markdown)│ │ (元数据/权限)   │   │
│  └──────────┘ └──────────┘ └──────────────────┘   │
│  ┌──────────────────────────────────────────┐      │
│  │       Git 版本控制（全量历史回溯）        │      │
│  └──────────────────────────────────────────┘      │
├────────────────────────────────────────────────────┤
│                   数据源接入层                       │
│  ┌──────┐┌──────┐┌──────┐┌──────┐┌──────────┐   │
│  │ Jira ││Test- ││ JMeter││ Con- ││ NAS/文件 │   │
│  │缺陷  ││Rail  ││ 报告 ││ fluence││ 服务器   │   │
│  └──────┘└──────┘└──────┘└──────┘└──────────┘   │
└─────────────────────────────────────────────────────┘

各层职责说明

用户交互层：Hermes CLI 提供对话式知识查询入口；Obsidian 客户端提供知识编辑、阅读和管理的可视化界面；Web 门户为权限受限的浏览用户提供只读访问。

智能调度层：Hermes Agent 是整个系统的大脑。它接收用户问题，通过意图分类决定使用哪个 Skill，从记忆系统中召回上下文，通过 RAG 管道检索向量库，最后调用 LLM 生成答案。

知识存储层：采用三层混合存储------向量库（sqlite-vec）负责语义检索，文件系统（Markdown）负责知识内容的可读性和可维护性，关系型数据库负责元数据、权限和审计日志。所有内容通过 Git 进行版本管理，支持随时回溯到任意历史版本。

数据源接入层：通过 Hermes 的 Skill+Tool 机制，可以拉取 Jira 的缺陷数据、TestRail 的用例数据、JMeter 的性能报告、Confluence 的已有文档以及 NAS 上的历史归档文件。所有数据统一预处理后进入知识存储层。

---

四、具体搭建步骤（内网环境实战版）

以下步骤基于我们实际落地的一台内网服务器（操作系统：CentOS 7.9，CPU：8 核，内存 32 GB，无外网访问）。所有的依赖包需通过离线方式导入。如果你有外网条件，流程会更顺畅。

4.1 环境准备与离线依赖打包

第一步：确定技术栈版本

组件	版本	用途
Hermes Agent	v1.2+	核心智能体框架
Python	3.11.9	运行环境
Node.js	v22.x	Hermes 前端/插件
Obsidian	v1.8+（桌面版）	知识库编辑器
sqlite-vec	最新版	向量检索库
Git	2.x+	版本控制
Ollama（内网部署）	0.5+	本地大模型推理

第二步：离线环境搭建（关键！）

在内网外网隔离的情况下，需要一台「搬运机」来传递依赖：

# 在外网机器上：
pip download --platform manylinux2014_x86_64 -d deps-python \
  fastembed sqlite-vec hermes-agent

# 通过光盘/USB 导入到内网后：
pip install --no-index --find-links=./deps-python hermes-agent

踩坑记录 #1 ：Hermes Agent 默认安装脚本会从 GitHub 拉取最新的 Skill 仓库。内网环境下这一步必然失败。解决方案是：在外网下载好 ~/.hermes/skills/ 目录的全部内容，打包后导入内网。我们为此写了一个 sync_skills.sh 脚本。

4.2 Hermes Agent 安装与配置

# 创建运行目录
mkdir -p ~/.hermes/{skills,memories,config,logs}

# 配置文件：~/.hermes/config.yaml
cat > ~/.hermes/config.yaml << 'EOF'
provider:
  custom:
    type: openai-compatible
    base_url: http://内网Ollama地址:11434/v1
    api_key: noop  # 内网环境无需真实 key
model:
  main: qwen2.5:14b
  embedding: bge-m3:latest
skills:
  obsidian:
    vault_path: /data/knowledge-base
  rag:
    retriever: vector
    fallback: bm25
    fusion: rrf
    k: 60
    reranker: bge-reranker-v2-m3
memory:
  type: persistent
  path: /data/knowledge-base/memories
EOF

踩坑记录 #2：内网环境使用 Ollama 部署大模型时，强烈推荐 Qwen2.5 系列的中文优化模型。我们测试对比了 Qwen2.5:14b 和 Llama3:8b，前者在中文测试场景下的理解准确率高出 23%。14B 参数模型在 32GB 内存机器上可以流畅运行，无需独立显卡。

4.3 Obsidian Vault 初始化与目录结构

# 创建知识库根目录
mkdir -p /data/knowledge-base/{notes,memories,skills,wiki,raw,entities,queries}

# 目录结构说明
# /data/knowledge-base/
# ├── notes/           # 测试笔记、策略文档
# ├── memories/        # Hermes 持久记忆
# │   ├── MEMORY.md    # 系统记忆
# │   └── USER.md      # 用户偏好记忆
# ├── skills/          # 自定义测试技能
# ├── wiki/            # LLM Wiki（结构化知识）
# ├── raw/             # 原始文档（PDF、Word）
# ├── entities/        # 结构化实体定义
# └── queries/         # FAQ 与检索记录

在 Obsidian 中打开 /data/knowledge-base/ 作为 Vault，安装以下社区插件：

1. Dataview ------ 将文档元数据转为可查询的数据表
2. Templater ------ 测试用例、缺陷报告等模板
3. Git ------ 直接在 Obsidian 中提交版本
4. Excalidraw ------ 绘制测试架构图
5. Kanban ------ 测试任务看板

4.4 RAG 知识库搭建

RAG（检索增强生成）是整个系统最核心的能力。我们采用双路召回 + 重排序的方案：

# 1. 初始化向量库
hermes vector init --engine sqlite-vec --fts5 true

# 2. 批量导入历史文档
hermes ingest --path /data/knowledge-base/raw/ --recursive

# 3. 生成向量并写入
hermes vector upsert \
  --file /tmp/processed_chunks.json \
  --metadata '{"department":"test","level":"internal"}'

# 4. 配置 RAG 管道
hermes rag configure \
  --retriever vector \
  --fallback bm25 \
  --fusion rrf \
  --k 60 \
  --reranker bge-reranker-v2-m3

参数解释：

• retriever vector：主检索使用向量语义匹配
• fallback bm25：当向量检索置信度低于 0.7 时，回退到关键字 BM25 搜索
• fusion rrf：使用 Reciprocal Rank Fusion 融合双路结果
• k=60：每路取前 60 个候选，融合后再取前 10 个送入 LLM
• reranker：交叉编码器对候选进行二次排序，消除噪声

4.5 编写测试专用 Skill

在实际使用中，Skill 是 Hermes 最强大的武器。以下是我们实际部署的几个关键 Skill 示例。

Skill 1：测试策略查询

# SKILL.md -- 测试策略查询

## 目的
为测试工程师提供基于最新运行手册和测试策略的自然语言查询能力。

## 输入
- query: 测试人员的自然语言问题（如"预算编审模块的回归测试范围"）
- filters: 可选的模块名称、版本号、时间范围

## 步骤
1. 解析 query，提取模块名、版本号和测试类型（冒烟/回归/全量）。
2. 调用 `vector.search` 在 notes/ 和 entities/ 中检索相关文档。
3. 若检索结果置信度低于 0.7，回退至 BM25 全库搜索。
4. 将候选块与 query 拼接，调用 LLM 生成结构化回答。
5. 在答案末尾附上来源文档的 Obsidian 内部链接。

## 输出
- answer: 结构化回答（含测试范围、优先级、预期耗时）
- citations: [{doc_name, snippet, confidence}]

Skill 2：缺陷归因分析

# SKILL.md -- 缺陷归因分析

## 目的
根据缺陷描述，自动检索历史相似缺陷的根因和修复方案。

## 输入
- defect_id: Jira 缺陷编号（可选）
- description: 缺陷自然语言描述

## 步骤
1. 若提供 defect_id，通过 Jira API（内网）拉取完整缺陷信息。
2. 将描述转为向量，在 memories/ 和 queries/ 中检索历史上相似的缺陷。
3. 使用 LLM 对比当前缺陷与历史缺陷的异同，给出最可能的根因分类（SQL 错误 / 数据状态 / 配置错误 / 业务逻辑 / 环境问题）。
4. 输出归因结果和推荐修复方案，并标注历史参考编号。

## 输出
- root_cause: 根因分类与分析
- similar_defects: [{id, similarity_score, fix_summary}]
- recommended_fix: 推荐修复方案

4.6 接入测试工具链

知识底座必须「活」起来，不能只是一个被动的文档库。我们的方案通过 Hermes 的 Tool 能力与现有工具链打通：

# 注册 Jira 数据源
hermes tools register jira \
  --base-url http://内网Jira地址 \
  --auth basic \
  --username test-admin \
  --password-file /data/secure/jira_pass.gpg

# 注册 TestRail 数据源
hermes tools register testrail \
  --base-url http://内网TestRail地址 \
  --api-key-file /data/secure/testrail_key.gpg

# 创建定时任务：每晚同步新增缺陷和测试用例
hermes cron create \
  --name nightly-sync \
  --schedule "0 2 * * *" \
  --command "hermes tools jira sync --since '24h'; hermes tools testrail sync --since '24h'"

---

五、财政系统的特殊考量：等保合规与内网部署

作为服务于财政系统的测试团队，我们面临着一系列特殊的约束条件。这些条件决定了技术选型的边界和落地的路径。

5.1 等保三级合规要求

根据《信息安全技术 网络安全等级保护基本要求》（GB/T 22239-2019），财政系统通常被列为第三级保护对象。这意味着一系列强制性要求：

身份鉴别：

• 所有访问必须通过统一身份认证。我们对接了内网的 LDAP/AD 系统，实现了单点登录（SSO）和强制 MFA。
• 关键操作（知识库写入、权限变更、配置修改）必须有双因子认证。

访问控制：

• 采用 RBAC 模型，定义四个角色：阅读者（只读）、编辑者（创建/修改，需审批）、审计员（仅审计日志）、管理员（完全控制）。
• 踩坑记录 #3：Hermes 原生的权限模型不支持 AD 集成。我们写了一个 adapter skill，在 Hermes 和 LDAP 之间搭建了一个中间层，每次请求先验证 AD 令牌，再映射到 Hermes 内部角色。这个适配器后来成为了我们团队复用的基础组件。

数据完整性：

• 所有知识文档在写入时自动生成 SHA-256 哈希，存入防篡改的审计库。
• 使用 Git 作为底层存储，每一次变更都有完整的 commit 记录，可以审计「谁在什么时间改了什么地方」。

审计日志：

• 开启粒度审计，记录每一次文档访问、权限变更、系统配置修改。
• 日志保留周期为 1 年（热存储 30 天，冷存储 11 个月），且日志写入「只写磁盘」，防止事后篡改。

数据加密：

• 传输层强制 TLS 1.2+，使用 AES-256 加密套件。
• 存储层采用 LUKS 全盘加密，密钥由内部 KMS 管理。

5.2 内网环境的特殊挑战

没有外网，所有的依赖管理方式都要改变。

依赖供应链：

• 我们建立了一个内部 PyPI 镜像站，每季度评审并同步一次。所有 Python 包经过安全审查后才能入库。
• Node.js 的 npm 依赖通过类似方式管理。Hermes Agent 的前端依赖全部通过 tar 包离线导入。
• 踩坑记录 #4 ：第一次部署时，我们尝试手动逐个安装依赖，结果踩了 6 个版本冲突的坑。最终我们写了一个依赖锁文件（lockfile），并在一台外网机器上用 pip freeze 导出完整依赖树，再整体迁移。

大模型部署：

• 内网无法调用 OpenAI 等云端模型。我们在服务器上部署了 Ollama，加载 Qwen2.5:14B 作为主模型、bge-m3 作为嵌入模型。
• 14B 参数量的模型在 32GB 内存机器上可以达到 12-15 tokens/s 的推理速度，对于知识问答场景完全够用。
• 踩坑记录 #5：Qwen2.5 的上下文窗口是 32K tokens，但我们发现当检索出的文档块超过 8K tokens 时，回答质量会显著下降。最终我们将单次检索的候选块数量从 10 片压缩到 5 片，且每片不超过 1024 tokens。

网络拓扑：

• 知识库服务器放在内部核心 VLAN，通过防火墙与业务 VLAN 隔离。
• 仅开放 HTTPS 443 端口供内网用户访问 Web 门户。
• 所有跨 VLAN 流量记录源/目的 IP、端口和时间戳。

5.3 多人共享知识库的协作方案

多人同时编辑一个知识库，必然会遇到冲突和一致性问题。

我们的方案：以 Git 为中心，Obsidian + Hermes 作为前端。

• 每个人在本地 Obsidian 中编辑自己的知识文件，完成后提交 Git commit 到中央仓库。
• 中央仓库在合并时自动运行 CI 检查：Markdown 格式校验、链接有效性检查、元数据完整性检查。
• Hermes Agent 作为只读的「知识检索端」，从最新版本的分支读取数据。任何对知识内容的修改都必须走 Git 提交 - 审查 - 合并流程。
• 踩坑记录 #6：团队初期有人直接在服务器上修改文件，导致 Git 历史混乱。后来我们写了一个 git hook，禁止在服务器端直接修改知识库文件，所有修改必须从本地推送到远程仓库。

---

六、踩坑经验全记录

半年的落地过程中，我记录了超过 20 个大小不一的坑。以下是最值得分享的 8 个，按严重程度排序：

坑 1：向量检索的「语义陷阱」

现象：测试人员问「支付系统的并发用户数限制是多少」，AI 返回的是「预算编审」模块的内容。原因是两个模块的文档中都提到了「并发用户数」这个关键词，向量检索没有正确区分上下文。

解决方案 ：我们在文档预处理阶段增加了元数据标签------每一篇文档在切块时附带模块名、文档类型、业务阶段。检索时首先按元数据过滤，再在过滤后的子集中做语义匹配。这一改进将检索准确率从 72% 提升到了 89%。

坑 2：Obsidian 笔记的中文编码

现象：导入一批历史文档后，部分中文显示为乱码。原因是原始 PDF 文档在转换时使用了 GBK 编码，而 Hermes 默认处理 UTF-8。

解决方案 ：在文档导入管道中加入自动编码检测（用 chardet 库检测编码，先转为 UTF-8 再处理）。同时写了一个批量修复脚本，扫描整个仓库中非 UTF-8 编码的文件。

坑 3：大模型在专业术语上的「幻觉」

现象：询问「预算指标」相关的测试要点时，AI 生成了一段看似合理但实际上错误的回答------混淆了「预算指标」和「国库指标」两个完全不同的业务概念。

解决方案：

1. 建立了一个术语知识图谱（在 entities/ 目录下），明确定义了 300+ 个财政领域术语，包括定义、边界和关联关系。
2. 在 RAG 管道的 prompt 中注入：「如果问题涉及专业术语，优先从术语知识图谱中检索定义，再根据定义检索相关文档。」
3. 在回答末尾强制标注「置信度评分」，低于 0.8 的答案需要人工审核后才能使用。

坑 4：Git 仓库不断膨胀

现象：运行三个月后，知识库的 Git 仓库体积从 200MB 膨胀到了 3.2GB，因为每次自动同步都会引入大量二进制文件（截图、PDF 附件等）。

解决方案：

• 使用 Git LFS 管理大于 1MB 的二进制文件。
• 在 .gitignore 中加入 *.png;*.jpg;*.pdf;*.xlsx 等模式，大文件统一存储在 NAS 上，知识库中只保留链接。
• 每季度执行一次 git gc 和 git repack 进行仓库瘦身。

坑 5：多人协作的「覆盖冲突」

现象：A 和 B 同时编辑同一个知识文档，A 先提交，B 后提交时发生合并冲突，B 直接 force push 覆盖了 A 的修改。

解决方案：

• 引入 GitLab 作为中央仓库，所有合并必须通过 Merge Request 走审查流程。
• 编写 pre-receive hook，检测 force push 并拒绝。
• 收敛编辑入口：高频编辑的文档（如测试策略、环境信息）改为 Obsidian 模板+表单填写模式，减少直接手写 Markdown 的场景。

坑 6：SSO 集成时的认证延迟

现象：每次用户提问时，Hermes 都需要调用 AD 进行一次令牌验证，导致首问延迟从 2 秒增加到了 8 秒。

解决方案：引入本地令牌缓存，每次认证成功后生成一个有效期 5 分钟的本地 Token。缓存命中时直接放行，无需每次都去 AD 验证。首问延迟降回 2.5 秒。

坑 7：日志审计的磁盘爆炸

现象：开启全量审计后，每天产生 5GB 日志，一个月内磁盘告警。

解决方案：

• 设定日志级别：全量审计日志只保留 30 天热数据。
• 30 天后的数据压缩后转到冷存储（NAS 归档）。
• 关键日志（权限变更、配置修改）永久保留，普通日志（文档读取）保留 1 年。
• 实施限流：每秒超过 100 条日志时自动降级，只记录关键事件。

坑 8：新人培训中的「过度依赖」

现象：新人发现 AI 可以回答大部分问题后，开始完全依赖 AI，不再阅读原始文档。这导致他们对业务的理解停留在「别人总结过的二手知识」层面，缺乏深度。

解决方案：

• 在 AI 回答后强制附加「来源链接」，并要求新人在确认答案正确性时必须点击阅读原始文档。
• 设计了一套「渐进式学习路径」：第一周允许使用 AI 完整回答，第二周开始要求 AI 只给线索，第三周要求脱离 AI 独立解决问题。
• 在 Obsidian 中实现了一个「学习进度看板」，跟踪每个人对关键业务模块的了解程度。

---

七、效果评估与持续改进

7.1 量化效果

经过半年的运行，我们收集了以下数据（对比基线为部署前）：

指标	基线值	优化后	提升幅度
新人独立完成自动化测试	45 天	7 天	-84%
测试策略检索平均耗时	25 分钟	3 分钟	-88%
缺陷归因准确率（Top-3）	62%	91%	+29pp
知识文档使用率	35%	82%	+47pp
团队满意度（NPS）	6.2	8.7	+2.5

7.2 持续改进方向

方向一：多模型路由------当前只有 Qwen2.5:14b 一个模型。计划接入多个模型：简单问题用小模型（如 Qwen2.5:7b）快速响应、复杂问题用大模型（如 Qwen2.5:72b）深度推理、代码生成用专门的 Code 模型。

方向二：主动知识发现------当前系统是被动问答式。计划增加主动推荐能力：当测试人员在 Jira 中创建了一个缺陷单时，系统自动检索相似历史缺陷并推送到缺陷单的评论区。

方向三：测试用例自动生成------基于需求文档和知识库中的业务规则，自动生成覆盖等价类划分、边界值分析、判定表覆盖的测试用例框架，人工只需审核和补充。

方向四：知识质量量化评估------建立一套知识质量的成熟度评估模型，从完整性、准确性、时效性、可读性四个维度对每一篇文档打分，推动团队持续优化知识资产。

---

八、结语

回到开头的问题：为什么需要「从碎片化到体系化的 AI 测试知识底座」？

我的理解是：测试的本质不是「找 bug」，而是「建立对质量的信心」。要建立这种信心，你需要完整的信息、精准的判断、高效的协作和可传承的经验。传统的文档管理方式已经把测试团队推到了效率的极限------你不可能通过再写更多的文档来解决「文档太多找不到」的问题。

AI 知识底座提供的不是另一个文档系统，而是一种全新的知识组织方式：用语义理解替代关键字搜索，用智能检索替代人工翻找，用 Agent 执行替代手动操作，用持久记忆替代人的遗忘。

在财政系统这样合规要求高、业务复杂度高、人员流动率也高的环境中，这套体系的价值尤为突出。它让测试知识不再是「写在纸上的约束」，而是「可对话、可推理、可执行的组织智力」。

当然，这条路才刚刚开始。本文记录的方案和经验还有很多不成熟的地方，但我们已经在实际工作中验证了它的可行性和价值。希望这篇文章能给正在探索类似方向的同行们一些启发和帮助。

---

浅木·先生，财政系统测试架构师。长期专注于大型企业级系统的测试体系建设、AI 赋能测试工程和质量保障方法论。

---

附录：相关资源

• Hermes Agent 官方文档：https://hermes-agent.nousresearch.com/docs
• Obsidian 社区插件：Dataview、Templater、Git、Excalidraw
• Ollama 内网部署指南：https://github.com/ollama/ollama
• Qwen2.5 模型系列：https://github.com/QwenLM/Qwen2.5
• 等保 2.0 合规参考：GB/T 22239-2019