【More Than Coding】用 SOLO 搭建一套「会自己生长」的通用知识库——测试工程师的提效实战

SOLO挑战赛专区
1

【More Than Coding】用 SOLO 搭建一套「会自己生长」的通用知识库——测试工程师的提效实战

一、摘要

这是一套通用的个人知识库搭建方案，不限职业、不限领域，任何人都能复用。我用 TRAE SOLO + Obsidian 搭建了一套基于知识生命周期的知识库架构，通过模板驱动输出和自创建的 obsidian-knowledge-base Skill，实现了知识库的自运维：自动质量审计、索引同步、孤立检测、反馈纠错。

作为一名测试工程师，我尝试把这套通用方案落地到测试领域。目前知识库已经能帮我生成测试用例、测试报告、API 文档、Bug 管理、自动化脚本、日报周报这些工作输出，初步测算提效在 80% 左右。但这个数字只是粗略夸张估计(我瞎说的，我也没没统计)，实际效果因场景而异，而且方案本身还有不少粗糙的地方，需要持续迭代优化。

二、背景

我是个测试工程师。日常工作里，要输出的文档一大堆：测试用例、测试报告、API 文档、Bug 报告、自动化脚本、日报周报……说实话，这些活儿有个共同特点——高度模板化，但每次都得从零写起。

更头疼的是知识管理这事儿：

  1. 收藏夹吃灰：好文章、踩坑经验收藏了就忘，用的时候死活找不到
  2. 经验没法复用：上次写的 Prompt、调通的环境配置，下次还得重来
  3. 文档质量参差不齐：不同人写的 Bug 报告格式不统一，信息缺这少那，反复沟通

Karpathy 发过一篇文章，核心思路挺简单的：建三个文件夹，写个给 AI 看的说明文件，让 AI 当你的图书管理员。你只管采集和提问，AI 负责整理和维护。这个理念确实打动我了——但我需要的不仅是「整理笔记」，更想让知识库直接产出工作成果。

于是决定用 Trae SOLO + Obsidian 搭一套知识库。核心目标不是存东西，而是提效——让知识库变成日常工作的加速器。

三、实践过程

第一步：搭建知识库骨架——知识生命周期管理

Karpathy 那个 raw/wiki/outputs 三文件夹确实挺优雅的。但实践中我发现，得再细一点。我借鉴了他的核心理念——「你只管采集，AI 负责整理」，但把三文件夹扩展成了完整的知识生命周期：

my-knowledge-base/
├── 00_system/      → 系统配置（模板、规则、Skill）
├── 01_inbox/       → 收集箱（临时存放，7天清理）
├── 02_daily_notes/ → 工作日志
├── 03_raw/         → 原始素材（待处理）
├── 04_ai_wiki/     → AI 生成内容（待校验）
├── 05_permanent/   → 核心知识资产（已验证）
├── 06_mocs/        → 知识地图
├── 07_personal/    → 个人生活
├── 08_projects/    → 项目文档
├── 09_outputs/     → 成品输出
├── 10_resources/   → 可复用资源
├── 11_audit/       → 质量控制与反馈纠错
└── 99_archive/     → 归档区

一级目录定义的是知识的生命周期阶段，这个设计是通用的。二级目录才跟职业相关——我的 05_permanent/ 下面是 testing_notes/，你的可能是 product_design/ 或 marketing/。

和 Karpathy 方案的关键差异：

维度 Karpathy 方案 我的改进
素材处理 raw → wiki 直通 raw → ai_wiki（校验层）→ permanent，多一层质量门控
质量管控 「定期检查」（手动触发） 11_audit/ 自动化审计队列
格式约束 靠说明文件里的规则 00_system/templates/ 模板文件，新笔记自动套用
错误传播 「错误信息会一直传递」 反馈纠错闭环：四阶段诊断 + 完成证据链

第二步：Trae 以项目为单位适配 Obsidian——基础设施

这是整个方案能跑起来的关键。Trae 可以直接以 Obsidian vault 为项目打开，读写所有 .md 文件，理解 wikilink 语法，识别 frontmatter 属性。

你想啊，这意味着什么？Trae 和 Obsidian 共享同一个工作空间，双向实时同步。 我在 Obsidian 里手动改的笔记，Trae 立马感知；Trae 生成的笔记，Obsidian 里直接可见。不用导入导出，不用格式转换。

对了，00_system/templates/ 里的模板文件，让 Trae 创建新笔记时自动套用统一格式——这是 Karpathy 方案没有的约束力。

第三步：让知识库产出工作成果——核心提效场景

这是整个项目最重要的部分。知识库不只是「存东西」，而是直接产出我每天需要的工作文档。

场景 1：生成测试用例

我有一套 template_test_case.md 模板，包含用例编号、优先级、测试类型、自动化程度、状态流转这些。当我说：

“根据这个登录接口的需求文档，生成测试用例”

Trae 会：

  1. 读取 05_permanent/testing_notes/ 里的接口测试知识
  2. 调用 template_test_case.md 模板格式
  3. 输出包含正常流程、异常流程、边界值的完整用例表

讲真，原来写一套登录接口用例得 1-2 小时，现在 10 分钟出初稿，我只需要审核和微调。这效率，杠杠的。

场景 2：输出 API 文档

template_api_test_doc.md 模板覆盖了端点信息、认证方式、请求参数、响应结构、错误码、安全检查清单。Trae 可以直接从代码或 Swagger 文档生成符合模板的 API 文档，比手写快 5 倍。

场景 3：Bug 报告

template_bug_report.md 模板含严重程度、优先级、Bug 类型、复现概率、最小化复现路径、HAR 文件收集指南、AI 辅助根因分析。以前写一个完整 Bug 报告 20 分钟，现在用模板 + Trae 辅助分析，5 分钟搞定。

场景 4：自动化测试脚本

知识库里有完整的接口自动化框架设计（三层架构、pytest+requests+allure 技术栈），Trae 可以基于这些知识直接生成自动化脚本骨架，包括请求封装、Fixture 配置、Allure 报告集成。

场景 5：日报周报

daily_note.md 和 weekly_review.md 模板让我每天/每周的记录有固定格式。Trae 可以根据我当天的笔记和 git 提交记录，自动生成工作日报草稿。

场景 6：测试报告

知识库里有完整的测试报告规范（7 要素、核心指标、缺陷分析、质量门禁），Trae 可以基于测试执行数据自动生成测试报告框架。

提效总结（个人经验数据，仅供参考）：

工作输出 传统方式 知识库+SOLO 估算提效
测试用例 1-2 小时 10 分钟初稿 + 审核 约 80%
API 文档 2-3 小时 20 分钟初稿 约 85%
Bug 报告 20 分钟 5 分钟 约 75%
自动化脚本 半天 1 小时骨架 约 80%
日报周报 30 分钟 5 分钟草稿 约 83%
测试报告 2 小时 20 分钟框架 约 83%

注：以上数据基于我个人使用情况的粗略估算，不同场景、不同复杂度下实际提效会有差异。而且目前方案还有不少局限，比如复杂业务场景的用例生成准确率还不够高，需要人工审核的比例较大。

第四步：创建 obsidian-knowledge-base Skill——让知识库自运维

在使用 Trae 管理知识库的过程中，我发现每次都要重复告诉 AI 「我的知识库结构是什么」「笔记应该怎么整理」「质量标准是什么」。说实话，挺烦的。于是我把这些规则沉淀成了一个 Skill——obsidian-knowledge-base Skill，这是我逐步创建的，不是拿来就用的。

这个 Skill 解决了什么问题？

没有 Skill 的时候，每次新对话都要重新解释知识库的规则；有了 Skill，Trae 自动加载这些规则，就像给 AI 装上了「知识库管理专家」的大脑。

核心能力：

1. 操作前确认——不盲目执行

当我说「帮我整理笔记」，Skill 先确认意图：整理范围？质量级别？成功标准？避免 AI 「好心办坏事」。

2. 六维质量框架——自动体检

每次操作后自动评估：准确性(25%)、完整性(15%)、一致性(20%)、时效性(15%)、相关性(10%)、可访问性(15%)。低于阈值的笔记进入 11_audit/ 待处理队列。

3. 反馈纠错闭环——错误不会一直传递

Karpathy 说过「错误信息会一直传递」。我的方案通过四阶段诊断法解决：症状确认 → 根因分析 → 修复执行 → 验证闭环。每次修正都有完成证据链。

4. .context.md 分级索引

每个一级目录都有 .context.md，它不是给人看的导航，而是给 AI 读的「目录卡片」。AI 在 30 秒内理解某个目录的定位和内容边界，而不是去读所有文件。这和 Karpathy 的 CLAUDE.md 本质相同，但粒度更细。

5. 知识生命周期流转

收集(inbox) → 加工(raw) → 校验(ai_wiki) → 沉淀(permanent) → 归档(archive)

以我的测试工程师知识库为例：最初只有基础测试理论，随着工作需要逐步加入了自动化测试、AI 测试等模块。AI 测试模块从一篇笔记生长为 6 个子模块（M0-M5），未来还会继续扩展。知识库的边界由需求决定，不由设计决定。

第五步：踩过的坑

坑 1：不要手动编辑 AI 维护的内容

Karpathy 反复强调这一点，我也深有体会。手动改了 AI 生成的 wiki 后，AI 不知道你改了什么，下次更新时会覆盖或矛盾。正确做法：把修正意见告诉 AI，让它来改。

坑 2：.context.md 不是越详细越好

一开始放了太多内容，AI 读取时消耗大量 token 反而降低效率。等等，这里我得补充一下——.context.md 应该只放定位信息（这个目录是什么、包含什么、去哪找），不放具体内容。

坑 3：模板是效率的基石

一开始觉得模板太死板，但实践发现模板最大的价值是让 AI 的输出可预测。当 Trae 知道「用这个模板生成测试用例」，它的输出格式、元数据、结构都是统一的，后续检索和关联的准确率大幅提升。

四、成果展示

知识库现状（仍在持续完善中）：

维度 数据 备注
一级目录 13 个（通用架构，不限职业） 部分目录利用率还不高，需要优化
工作输出模板 8 套（测试用例/Bug报告/API文档/需求分析/测试策略/日记/周报/完整笔记） 模板覆盖场景有限，复杂场景支持不足
核心知识笔记 50+ 篇结构化笔记 质量参差不齐，部分旧笔记需要重构
AI 测试模块 6 个（M0-M5），持续扩展中 模块间关联性还不够强，检索效率待提升
自创建 Skill obsidian-knowledge-base Skill v7.1.0 规则还不够完善，偶尔会有误判
质量评分 3.5/5.0（B 级，自优化持续提升中） 距离理想的 A 级还有差距

一级目录架构（通用，任何人可复用）：

my-knowledge-base/
├── 00_system/      → 系统配置（模板 + Skill）
├── 01_inbox/       → 收集箱
├── 03_raw/         → 原始素材
├── 04_ai_wiki/     → AI 生成（待校验）
├── 05_permanent/   → 核心知识
├── 09_outputs/     → 工作输出
├── 11_audit/       → 质控纠错
└── 99_archive/     → 归档

五、效果与总结

SOLO 在我的流程中做了什么？

  1. 架构搭建：帮我从混沌中梳理出知识生命周期架构
  2. 内容整理：自动分类、模板化、建立关联，我只管采集和提问
  3. 工作输出：测试用例、API 文档、Bug 报告、自动化脚本、日报周报，直接从知识库生成
  4. 质量保障：六维审计、反馈纠错、索引同步，知识库不会「腐化」
  5. Skill 创建：把重复的管理规则沉淀为 obsidian-knowledge-base Skill，一次创建持续受益

可复用的方法：

  1. 知识生命周期法：inbox → raw → ai_wiki → permanent → archive，任何领域通用
  2. 模板驱动输出：把工作文档的格式沉淀为模板，让 AI 的输出可预测、可复用
  3. .context.md 分级索引：每个目录一张「目录卡片」，AI 快速定位
  4. Skill 沉淀规则：把重复告诉 AI 的规则写成 Skill，一次创建持续生效
  5. 自优化闭环：六维质量 + 四阶段诊断 + 证据链，解决错误传递问题

一些想法（以及目前的局限）：

Karpathy 说「三个文件夹，一个说明文件，一个 AI」就够了。说实话，我同意他的极简哲学，但实践中我发现，当你把知识库从「个人笔记」升级为「工作输出引擎」时，需要更多的结构化支撑——模板约束质量、Skill 沉淀规则、审计机制防止腐化。

但我也得承认，这套方案目前还存在不少问题：

  1. 模板僵化问题：固定模板虽然保证了格式统一，但面对非标准场景时灵活性不足，有时候为了套模板反而降低了效率
  2. Skill 规则不完善：obsidian-knowledge-base Skill 的规则还是基于我个人习惯设计的，通用性不够强，偶尔会出现误判或漏判
  3. 质量评分主观性强：六维质量框架的权重设置是我凭经验定的，可能不适合所有人，评分结果也有待更多样本验证
  4. 学习成本不低：这套方案对新手来说门槛偏高，需要理解知识生命周期、掌握模板语法、学会与 AI 协作，上手周期比想象中长

这些不是复杂度的堆砌，而是让知识库从「能用」到「好用」的必要进化——但「好用」的标准因人而异，我的方案只是其中一种尝试，肯定还有更好的解法。

未来规划：

  1. 对接 Draw 实现代码转图：目前测试框架设计和业务流程只能用文字描述，计划对接 Draw 工具，让 Trae 直接从代码或 Mermaid 生成架构图、流程图、时序图，让文档更直观
  2. 辅助面试准备：知识库中已有过往项目的 8 类面试题（基础/APP/接口/性能/Linux/MySQL/自动化/QA），计划让 Trae 基于这些内容模拟面试问答，生成个人面试知识卡片
  3. MCP + Skill 扩展更多功能：
    • Playwright MCP：让 AI 直接操作浏览器执行 UI 测试(更推荐cli)
    • MySQL MCP：让 AI 直接查询测试数据库验证结果
    • Excel MCP：让 AI 直接生成测试数据表格
    • 自定义 Skill：针对特定项目创建专属 Skill（如「XX 项目测试 Skill」）
  4. Playwright CLI 实现 UI 自动化：计划封装 Playwright CLI 工具，让 Trae 直接调用命令行执行端到端测试。比如我说「跑一下登录流程的自动化测试」，Trae 自动执行 npx playwright test login.spec.ts 并解析报告，把失败截图和日志直接归档到知识库的 11_audit/ 目录
  5. Feishu CLI 收集工作信息直接输出文档：通过飞书开放平台的 CLI 工具，自动拉取我的日程、会议记录、任务完成情况，直接生成日报/周报草稿。再也不用翻聊天记录回忆今天干了啥——Trae 直接从飞书获取数据，套用模板输出文档
  6. Git CLI 集成代码关联：封装 Git CLI，让 Trae 能读取我的代码提交记录、分支信息、PR 状态。写周报时自动关联本周的代码改动，生成「本周工作产出」章节
  7. Jira/禅道 CLI 集成缺陷管理：通过 API 或 CLI 对接缺陷管理系统，自动同步 Bug 状态变更。当我说「整理本周处理的 Bug」，Trae 自动拉取数据并生成 Bug 处理报告
  8. 多源采集自动化：接入 RSS + AI 自动摘要，实现「采集→摘要→入库」全自动流水线
  9. 知识库间协作：探索团队场景——多人往同一个 raw/ 扔素材，AI 统一整理，每个人都可以提问和补充
  10. AI 辅助代码审查：结合 GitHub/GitLab API，让 Trae 自动读取 PR 代码变更，基于知识库中的代码规范进行审查，输出审查报告

最后想说的话：

知识库不是建出来的，是长出来的。我从一个简单的 Obsidian vault 开始，用 Trae SOLO 逐步搭建架构、沉淀模板、创建 Skill、积累知识。现在这个知识库每天都在帮我输出工作成果——测试用例、API 文档、Bug 报告、自动化脚本……它不再是一个「写了就不看」的笔记仓库，而是一个会思考、会生长、会自我修正的工作伙伴——虽然这个伙伴有时候也会犯错，需要我不断调教。

我必须坦诚地说，这套方案还远不完美。模板不够灵活、Skill 规则有漏洞、质量评分主观、学习曲线陡峭……这些问题我都还在摸索解决。分享出来是希望能给有同样需求的人一些参考，也期待听到更多反馈和建议。

如果你也想搭建自己的知识库，不妨从 Trae 打开你的 Obsidian vault 开始，先让 AI 帮你整理收藏夹里吃灰的文章。不用一步到位，不用追求完美，让知识库跟着你的需求一起生长，在迭代中慢慢找到最适合自己的形态。

顺便提一句，这篇文章，含ai量99.99%