个人知识库 | 3小时搭建

人工智能2026-06-234,373

title: " 个人知识库 | 3小时搭建" category: 人工智能 tags:

大模型API中转站
个人知识库
RAG
Obsidian
Codex
星链引擎 description: "从目录结构、资料采集、Markdown 笔记、向量检索到星链引擎模型接入，给个人创作者和开发者一套 3 小时可跑通的个人知识库搭建方案。"

很多人搭个人知识库，一开始就选工具。

今天用 Notion，明天用 Obsidian，后天又换到飞书、多维表格、网盘、语雀、思源笔记。

工具越换越多，资料越存越散。

真正的问题不是你缺一个笔记软件，而是缺一套能长期运转的知识流。

一套能用的个人知识库，至少要回答五个问题：

资料从哪里进来？
原文和笔记怎么分开？
怎么快速找到旧资料？
怎么让 AI 只基于我的资料回答？
哪些内容不能上传给模型？

这一篇不做工具测评，也不劝你 All in 某个软件。

我们直接搭一套最小可用方案：

本地文件夹 + Markdown 笔记 + Git 备份 + 全文搜索 + AI 检索问答

如果你愿意再往前一步，就把星链引擎这类大模型API中转站接到中间，统一管理模型、Key、成本和调用日志。

1. 为什么个人知识库总是搭不起来

先说结论。

大多数个人知识库失败，不是因为资料太少，而是因为入口太多、命名太乱、复用太少。

常见情况是这样：

问题	表现	后果
只收藏不消化	浏览器收藏夹、微信收藏、网盘 PDF 越堆越多	真正写东西时还是重新搜索
只写灵感不留出处	笔记里只有一句观点，没有原文和链接	复盘时无法验证
目录按工具分	Notion 一份、Obsidian 一份、网盘一份	知识被软件切碎
文件名随手写	`新建文档.md`、`笔记1.md`、`资料整理.md`	搜索和迁移都困难
让 AI 直接总结全部资料	一次塞太多 PDF 和网页	成本高、幻觉多、答案不可追溯

个人知识库不是仓库。

仓库只负责堆东西，知识库要能支持行动。

对开发者、独立创作者、产品经理和研究型写作者来说，个人知识库最终应该服务三件事：

更快找到资料
更稳形成判断
更低成本产出文章、方案、代码和决策

所以我们不追求大而全。

先搭一个能跑通的闭环。

2. 个人知识库的最小架构

推荐从四层开始：

采集层
  -> 整理层
  -> 检索层
  -> 输出层

对应到文件夹，就是这样：

personal-kb/
  inbox/
  sources/
  notes/
  projects/
  outputs/
  prompts/
  index/
  config/

每个目录只做一件事。

目录	用途	规则
`inbox/`	临时入口	所有没处理的资料先放这里
`sources/`	原始资料	PDF、网页摘录、会议纪要、截图 OCR、聊天记录
`notes/`	消化后的笔记	一篇笔记只讲一个概念、案例或方法
`projects/`	当前项目	写文章、做产品、学课程、研究选题
`outputs/`	最终产物	文章、方案、课件、代码片段、发布稿
`prompts/`	AI 指令模板	摘要、问答、改写、事实核对
`index/`	检索索引	全文索引、向量库、标签表
`config/`	配置	模型、Key 名称、忽略规则、同步规则

关键原则是：

原始资料不要改。
笔记必须可读。
输出必须可追溯。

如果你只能记住一句话：

把资料放进 sources，把想法写进 notes，把成果放进 outputs。

这样后面接 AI 才不会乱。

3. 第一步：先建目录，不要先装插件

在电脑上新建一个目录：

personal-kb/

然后建立基础结构：

personal-kb/
  inbox/
  sources/
    articles/
    books/
    docs/
    meetings/
    screenshots/
  notes/
    concepts/
    cases/
    methods/
    people/
  projects/
    2026-knowledge-base/
  outputs/
    articles/
    reports/
    scripts/
  prompts/
  index/
  config/

为什么不一上来按主题建几十个分类？

因为主题会变。

你今天研究 AI 写作，明天研究出海 SaaS，后天研究私域转化。

如果目录一开始就按主题切得太细，后面一定会纠结：“这篇文章到底放 AI、营销还是产品？”

更稳的方式是按资料状态分层，再用标签描述主题。

例如一篇关于 RAG 的文章：

sources/articles/2026-06-18-rag-for-personal-kb.md
notes/concepts/rag.md
notes/methods/markdown-vector-search.md
projects/2026-knowledge-base/article-outline.md
outputs/articles/personal-kb-guide.md

同一份资料可以服务多个项目，但原文只存一份。

4. 第二步：统一命名规则

知识库最怕“看起来都存了，但搜不到”。

文件命名建议用这个格式：

YYYY-MM-DD-主题-来源.md

例子：

2026-06-18-rag-personal-kb-openai-docs.md
2026-06-18-codex-skill-workflow-self-test.md
2026-06-18-obsidian-linking-method-note.md

如果是项目文件，可以加阶段：

2026-knowledge-base-01-research.md
2026-knowledge-base-02-outline.md
2026-knowledge-base-03-draft.md
2026-knowledge-base-04-review.md

每篇 Markdown 顶部加一个简单元信息块：

---
title: "RAG 在个人知识库中的用法"
type: source
source: "网页"
url: "https://example.com"
created: 2026-06-18
tags:
  - RAG
  - 个人知识库
  - 检索
status: raw
---

status 建议只用四种：

状态	含义
`raw`	还没处理的原始资料
`processed`	已经摘要或提炼
`evergreen`	长期有价值的常青笔记
`archived`	暂时不用，但保留

这比复杂标签系统更适合个人长期维护。

5. 第三步：采集资料只进 inbox

不要让资料直接散落到最终目录。

先统一进 inbox/：

网页剪藏
PDF
截图
语音转文字
会议纪要
微信聊天记录
AI 对话记录
灵感碎片

每天或每周做一次清理。

清理时只做三件事：

1. 删除明显无用的资料
2. 把原始资料移动到 sources
3. 把真正有复用价值的内容写成 notes

不要在 inbox 里精修。

inbox/ 的职责只有一个：接住所有输入。

真正的知识沉淀发生在 notes/。

6. 第四步：把笔记拆成三种

个人知识库里的笔记不要都写成长文。

建议拆成三种：

类型	放哪里	用途
概念笔记	`notes/concepts/`	解释一个概念，如 RAG、Embedding、模型路由
方法笔记	`notes/methods/`	记录一套可复用流程，如选题研究、代码审查、资料清洗
案例笔记	`notes/cases/`	记录一个真实项目、工具、错误、实验结果

每篇笔记都用同一个结构：

# 标题

## 一句话解释

用一句话说清楚它是什么。

## 适用场景

什么时候用，什么时候不用。

## 关键步骤

1. 第一步
2. 第二步
3. 第三步

## 相关资料

- [[source-xxx]]
- 原文链接

## 可复用输出

这条笔记以后可以用来写什么、做什么、判断什么。

注意这里的重点不是“写得漂亮”。

重点是以后能复用。

一篇好笔记应该能回答：

我以后写文章时能引用它吗？
我以后做方案时能复用它吗？
我以后问 AI 时能检索到它吗？

7. 第五步：先做全文搜索，再做向量检索

很多人一上来就想做 RAG。

但个人知识库的第一层检索，不应该是向量库，而应该是全文搜索。

原因很简单：

文件名、标题、标签、关键词，比语义猜测更稳定。

最小方案：

需求	工具
本地写笔记	Obsidian、VS Code、Typora
全文搜索	Obsidian 搜索、VS Code 搜索、ripgrep
版本管理	Git
云同步	iCloud、OneDrive、坚果云、Git 私有仓库
AI 辅助	Codex、Chatbox、Cherry Studio 或自写脚本

如果你是开发者，rg 已经很好用：

rg "RAG|Embedding|知识库" personal-kb/notes personal-kb/sources

如果你用 Obsidian，可以靠双链、标签和搜索先跑起来。

等资料超过 300 篇、PDF 超过 100 份、搜索词经常不确定，再考虑向量检索。

不要为了技术感，把一个 50 篇笔记的小库搞成复杂工程。

8. 第六步：接入 AI 问答

AI 接入个人知识库，有三种层级。

层级	做法	适合谁
L1 手动上下文	自己复制相关笔记给 AI	刚开始搭建的人
L2 本地检索 + AI 总结	先用搜索找到资料，再让 AI 摘要	大多数创作者
L3 向量库 + RAG	自动切片、Embedding、召回、回答	开发者、团队、资料量大的人

推荐从 L2 开始。

流程是：

提出问题
  -> 先搜索本地知识库
  -> 选出 3-8 篇相关资料
  -> 让 AI 基于资料回答
  -> 输出引用来源
  -> 人工确认

一个可复用提示词：

你是我的个人知识库助理。

请只基于我提供的资料回答，不要补充资料外的事实。
如果资料不足，请直接说“资料不足”，并列出还需要补充什么。

输出格式：
1. 结论
2. 依据
3. 可执行建议
4. 引用来源
5. 不确定点

这条提示词看起来普通，但非常重要。

它把 AI 从“自由发挥”拉回“基于资料工作”。

9. 第七步：用 4SAPI 统一模型和成本

如果只是偶尔问几句，直接用网页端就够了。

但如果你想把个人知识库变成长期工作台，就会遇到几个问题：

不同模型价格不同
长文总结和短问题不该用同一个模型
Embedding、摘要、写作、推理的模型能力要求不同
Key 分散在多个工具里不好管理
调用日志和成本不好追踪

这时可以把 4SAPI 这类大模型API中转站放在中间。

结构是：

个人知识库
  -> 检索脚本 / Codex / Chatbox
  -> 4SAPI
  -> 不同大模型

推荐模型分层：

任务	模型策略
文件命名、标签建议	低成本文本模型
摘要、提纲、知识卡片	中等文本模型
复杂问答、选题判断	强推理模型
代码脚本、自动整理	代码能力强的模型
OCR、截图理解、图表分析	多模态模型
最终发布稿润色	强文本模型 + 人工审核

接入时不要把所有工具都塞同一个 Key。

更建议按用途建不同 Key：

kb-local-test
kb-writing
kb-rag-index
kb-team-demo

这样成本异常时，可以知道是谁在消耗。

如果用支持 OpenAI 兼容接口的工具，一般只需要配置三项：

Base URL: https://4sapi.com/v1
API Key: 在 4SAPI 后台生成
Model: 从模型列表复制完整模型名

实际使用时，建议先从只读任务开始：

读取 notes 下的资料
总结 5 篇文章
生成标签建议
输出缺失信息清单

确认稳定后，再让 AI 写入 notes/ 或 outputs/。

10. 第八步：做一个最小 RAG 原型

如果你有开发基础，可以做一个很轻的 RAG 原型。

不建议第一天就上复杂平台。

先跑通这个流程：

读取 Markdown
  -> 按标题和段落切片
  -> 生成 Embedding
  -> 保存到本地向量库
  -> 用户提问
  -> 召回相关片段
  -> 调用模型回答
  -> 返回来源文件

目录可以这样放：

personal-kb/
  scripts/
    build_index.py
    ask_kb.py
  index/
    chunks.jsonl
    vectors/
  config/
    model.json

切片规则先别复杂：

每个 Markdown 文件按二级标题切片。
每个片段保留文件名、标题、标签、原文位置。
每个片段控制在 300-800 中文字。

回答时必须带来源：

答案：
...

引用：
- notes/concepts/rag.md
- sources/articles/2026-06-18-personal-kb.md

如果答案没有来源，就不要信。

这是个人知识库问答的底线。

11. 第九步：为 Codex 写一份知识库规则

如果你经常用 Codex 整理文件、写文章、做项目，可以在知识库根目录写一份规则文件。

例如：

AGENTS.md

里面写清楚：

# Personal KB Rules

## Directory Rules

- `sources/` 保存原始资料，不允许覆盖。
- `notes/` 保存消化后的 Markdown 笔记。
- `outputs/` 保存最终产物。
- 新资料先进入 `inbox/`，整理后再移动。

## Writing Rules

- 所有观点必须能追溯到 source 或明确标注为个人判断。
- 摘要不超过原文主要信息，不添加未验证事实。
- 输出文章前列出引用资料和不确定点。

## Safety Rules

- 不读取或上传包含身份证、银行卡、客户隐私、合同密钥的文件。
- 不自动删除原始资料。
- 修改前先说明计划，修改后列出文件清单。

这样 Codex 每次进入项目，就知道边界在哪里。

这比每次临时提醒更稳定。

如果再配合 4SAPI 的 Key 分组和日志，个人知识库就不只是笔记库，而是一套可审计的 AI 工作环境。

12. 第十步：每周做一次知识库维护

知识库不是建完就结束。

建议每周 30 分钟维护一次。

维护清单：

清空 inbox
给新资料改名
把 3-5 条高价值资料写成 notes
删除重复资料
补充来源链接
检查 outputs 是否可追溯
备份到 Git 或云盘
记录本周最有价值的 3 条知识

每月再做一次结构复盘：

检查项	问题
目录	有没有新的高频项目需要单独建目录
标签	有没有重复标签、无意义标签
搜索	最近 10 次搜索有没有找不到的资料
输出	哪些笔记真正变成了文章、方案或代码
成本	AI 总结、RAG、写作调用是否超预算
风险	是否有敏感资料进入模型上下文

个人知识库的价值不在“存了多少”，而在“复用了多少”。

13. 成本与风险提示

个人知识库接 AI，一定要注意三类风险。

第一，隐私风险。

这些内容不要直接上传给不清楚权限边界的模型：

身份证、护照、银行卡
客户名单、销售线索、合同
公司内部文档、未公开财报
API Key、数据库密码、服务器凭证
医疗、法律、财务等高敏感咨询记录

第二，幻觉风险。

AI 很擅长把不完整资料说得很完整。

所以知识库问答必须要求：

只基于资料回答
列出引用来源
标注不确定点
资料不足时不要硬编

第三，成本风险。

不要让强模型承担所有任务。

建议这样分工：

低成本模型：命名、分类、标签、短摘要
中等模型：文章提纲、资料合并、知识卡片
强模型：复杂判断、深度写作、最终审核
Embedding 模型：只用于索引和召回

星链引擎这类中转站的价值，就是把模型、Key、日志和成本集中管理起来。

但无论用什么工具，敏感资料脱敏和人工审核都不能省。

14. 最小落地方案

如果你今天只有 3 小时，按这个顺序做：

第 1 小时：建立 personal-kb 目录和命名规则
第 2 小时：整理 20 篇最常用资料到 sources
第 3 小时：写 5 篇 notes，并用 AI 做一次基于资料的问答

最小工具组合：

Obsidian 或 VS Code：写 Markdown
Git 或云盘：备份
rg 或内置搜索：全文检索
Codex 或 Chatbox：AI 辅助整理
4SAPI：统一模型和成本

最小目录：

personal-kb/
  inbox/
  sources/
  notes/
  outputs/
  prompts/

最小规则：

原文不改。
笔记可读。
输出可追溯。
敏感信息不上模型。

做到这四句，个人知识库就已经超过大多数“收藏夹式知识管理”了。

15. 总结

个人知识库不是另一个资料坟场。

它应该是一条持续运转的生产线：

采集
  -> 整理
  -> 笔记
  -> 检索
  -> AI 问答
  -> 输出
  -> 复盘

刚开始不要追求全自动。

先把目录、命名、原文、笔记和输出分清楚，再考虑 RAG、向量库和多模型路由。

一句话总结：

本地 Markdown 负责长期资产，搜索负责确定性，AI 负责提炼和生成，星链引擎负责模型和成本治理。

这套方案适合三类人：

人群	价值
独立创作者	把碎片资料变成稳定选题和长文素材
开发者	把文档、代码片段、踩坑记录变成可检索经验库
小团队	用统一目录、Key 和日志管理共同知识资产