1. 为什么本地知识库总是变成“资料坟场”我猜你大概率用过 Obsidian、Notion、语雀或者飞书文档中的至少一个。刚开始都很兴奋剪藏、摘录、建双链感觉自己马上要构建第二大脑。三个月后再打开里面躺着几百篇没读完的文章、一堆孤立的笔记、几个永远没填完的模板。收集很多复用很少。问题不在于工具而在于维护成本。传统知识库依赖人工做这些事分类、摘要、建链接、整理概念、维护索引、定期复盘。每一件都重要每一件都耗时。当维护成本超过使用收益知识库就停止生长了。LLM Wiki 的思路是把这些维护动作交给 AI人负责判断价值和提供方向AI 负责整理、摘要、归类、链接、维护和复盘。但这里有个前提——你的知识库结构必须对 AI 友好。目录怎么分、文件怎么命名、页面元数据怎么写、AI 改完东西往哪记日志这些约定决定了 AI 能不能长期稳定地帮你干活。这篇要做的就是从零搭一套可被 AI 维护的本地 Markdown 知识库骨架并且用 TaoToken 的统一 Key 把 AI 工具接进来完成一次真实的“AI 写入 校验”闭环。适合已经在用 Markdown 做笔记、想让 AI 接手整理工作、又不想把资料全传到云端的开发者。2. TaoToken 在 LLM Wiki 里的位置统一 Key 与 API 通道先说清楚 TaoToken 在这套系统里扮演什么角色。它不是知识库软件也不是编辑器替代品。它是一个统一的模型 API 接入层你申请一个 Key就能通过同一套 OpenAI 兼容接口调用多个模型不用为每个工具单独配一套 Key 和环境变量。对 LLM Wiki 来说这件事的价值在于“工具无关”。你的知识库可能同时被几种工具读写命令行里的脚本、编辑器插件、独立的 Agent 工具。如果每个工具都各自维护 Key 和 base_url配置会散落各处换模型时要改很多地方。统一 Key 之后所有工具指向同一个 API 地址模型切换只改一个配置项。接入信息如下官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 基地址https://taotoken.net/api模型对话入口https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite注意API 基地址是https://taotoken.net/api很多 OpenAI 兼容客户端需要的是带/v1的完整路径具体以接入文档为准。配置时先确认客户端要求的格式能省掉一半的 404 报错。如果你后续要跑长期编码或 Agent 类任务可以了解 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite3. 目录结构让 AI 知道东西该放哪先建骨架。核心思想是分层临时输入 → 原始证据 → AI 摘要 → 稳定知识 → 报告输出。每一层职责单一AI 读目录名就知道该往哪写。LLMWiki/ ├── inbox/ # 低摩擦收集箱先扔进来不分类 ├── raw/ # 原始资料区只新增不改写 ├── wiki/ # 正式知识库 │ ├── index.md # 总索引AI 查询第一入口 │ ├── log.md # 操作日志记录每次变更 │ ├── sources/ # 来源摘要 │ ├── concepts/ # 稳定概念页 │ ├── projects/ # 项目知识页 │ ├── people/ # 人物/组织页 │ └── methods/ # 可复用方法流程 ├── outputs/ │ ├── reports/ # 简报、复盘、报告 │ └── lint/ # 健康检查报告 ├── prompts/ # 可复用提示词模板 ├── docs/ │ ├── specs/ # 设计文档 │ └── plans/ # 实施计划 ├── AGENTS.md # 多 AI 协作主协议 └── README.md # 使用说明用 PowerShell 一次性建好Windows 环境$root D:\LLMWiki $dirs ( inbox, raw, wiki, wiki/sources, wiki/concepts, wiki/projects, wiki/people, wiki/methods, outputs, outputs/reports, outputs/lint, prompts, docs, docs/specs, docs/plans ) foreach ($d in $dirs) { New-Item -ItemType Directory -Force -Path (Join-Path $root $d) | Out-Null } Write-Host 目录骨架创建完成$rootmacOS 或 Linux 用一行就够mkdir -p ~/LLMWiki/{inbox,raw,wiki/{sources,concepts,projects,people,methods},outputs/{reports,lint},prompts,docs/{specs,plans}}几个关键约定直接决定 AI 能不能安全协作raw/只新增不改写。它是证据层AI 如果随意改写原始资料追溯链就断了。需要更新时新增一个带新日期的版本。wiki/下每个正式页面必须有 YAML frontmatterAI 靠它判断页面类型和来源。每次有意义的变更都要同时更新wiki/index.md和wiki/log.md。这是多 AI 协作不互相覆盖的基础。4. 配置骨架config.toml 与 settings.json接下来是接入配置。不同工具读不同格式的配置文件这里给两份骨架按你实际用的工具取用。4.1 config.toml命令行工具与脚本用# LLMWiki/config.toml # 统一模型接入配置所有本地脚本读这一份 [api] provider taotoken base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY # Key 从环境变量读不写进文件 timeout_seconds 120 max_retries 3 [models] default gpt-4o-mini # 日常摘要、标签用轻量模型 reasoning gpt-4o # 概念抽取、矛盾检测用强模型 fallback claude-3-5-sonnet # 主模型不可用时的备选 [wiki] root D:/LLMWiki index_file wiki/index.md log_file wiki/log.md agents_file AGENTS.md raw_dir raw sources_dir wiki/sources concepts_dir wiki/concepts [ingest] # 摄入流程参数 max_source_chars 12000 # 单次送入模型的原始资料上限 require_frontmatter true auto_update_index true auto_append_log trueKey 不落盘通过环境变量注入# Windows PowerShell当前会话有效 $env:TAOTOKEN_API_KEY 你的Key# macOS / Linux写入 shell 配置可持久化 export TAOTOKEN_API_KEY你的Key4.2 settings.json编辑器插件与 Agent 工具用{ llmWiki: { root: D:/LLMWiki, agentsFile: AGENTS.md, indexFile: wiki/index.md, logFile: wiki/log.md }, model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, defaultModel: gpt-4o-mini, reasoningModel: gpt-4o, temperature: 0.3, maxTokens: 4096 }, ingest: { rawDir: raw, sourcesDir: wiki/sources, conceptsDir: wiki/concepts, requireFrontmatter: true, autoUpdateIndex: true, autoAppendLog: true }, lint: { checkFrontmatter: true, checkBrokenLinks: true, checkOrphanPages: true, checkMissingSources: true, reportDir: outputs/lint } }注意baseUrl填https://taotoken.net/api如果你的客户端自动补/v1/chat/completions就不要再手动加/v1否则会拼成/api/v1/v1/...。先发一个最小请求验证再批量跑任务。4.3 AGENTS.mdAI 协作的“宪法”这个文件比配置更重要。它告诉所有 AI 工具这个知识库怎么用、什么能改、什么不能碰。# AGENTS.md — LLM Wiki 协作协议 ## 知识库定位 本地优先的 Markdown 知识库AI 参与整理、摘要、归类、链接与复盘。 ## 操作原则 1. 修改 wiki/ 前先读 AGENTS.md、wiki/index.md、wiki/log.md。 2. raw/ 下既有文件默认不改写需要更新时新增带日期的版本。 3. 不删除 wiki 页面除非用户明确批准默认只新增、更新、标记废弃。 4. 每个正式 wiki 页面必须有 YAML frontmatter。 5. 断言应可追溯到 raw/ 或其他来源推测内容标注“待确认”。 6. 每次有意义的变更同步更新 wiki/index.md 和 wiki/log.md。 7. 不写入密码、token、access-key、secret-key、内网地址。 ## 页面类型 source / concept / project / person / method / index / log / report ## 命名约定 - raw/日期-来源-主题.md如 2026-07-08-csdn-llm-wiki.md - wiki/中文标题.md如 LLM-Wiki.md - 项目目录00-项目入口.md 起编号4.4 页面 frontmatter 模板--- title: LLM Wiki type: concept sources: - raw/2026-07-08-csdn-llm-wiki.md related: - wiki/concepts/知识库主动反馈闭环.md created: 2026-07-08 updated: 2026-07-08 confidence: medium ---confidence字段很有用high表示有明确来源支撑medium表示合理推断low表示待确认。AI 生成内容时按这个标准自评你复查时一眼能看出哪些需要人工核实。5. 验证请求跑通一次 AI 写入与校验配置写完不验证等于没配。这一步用一个最小脚本让 AI 读一篇 raw 资料生成来源摘要页更新索引和日志然后做一次 lint 校验。5.1 准备一篇原始资料在raw/下放一个文件!-- raw/2026-07-08-demo-note.md -- # 演示资料为什么知识库需要 AI 维护 来源本地笔记 日期2026-07-08 传统知识库的维护动作分类、摘要、建链、索引、复盘都是人工完成 成本高且容易中断。把其中可标准化的部分交给 AI人只保留价值判断和方向决策 可以让知识库持续生长而不是变成资料坟场。5.2 用 Python 发一次真实请求# scripts/ingest_demo.py import os, json, urllib.request API_BASE https://taotoken.net/api API_KEY os.environ[TAOTOKEN_API_KEY] MODEL gpt-4o-mini def chat(messages): payload json.dumps({ model: MODEL, messages: messages, temperature: 0.3 }).encode(utf-8) req urllib.request.Request( f{API_BASE}/v1/chat/completions, datapayload, headers{ Content-Type: application/json, Authorization: fBearer {API_KEY} }, methodPOST ) with urllib.request.urlopen(req, timeout120) as resp: return json.loads(resp.read().decode(utf-8)) raw_text open(D:/LLMWiki/raw/2026-07-08-demo-note.md, encodingutf-8).read() prompt f你是 LLM Wiki 的摄入助手。请阅读下面的原始资料 生成一个来源摘要页严格输出 Markdown包含 YAML frontmatter。 要求 - type: source - 包含一句话摘要、关键观点3条以内、对本知识库的启发、不确定性 - 不要编造资料中没有的事实 原始资料 {raw_text} result chat([{role: user, content: prompt}]) content result[choices][0][message][content] out_path D:/LLMWiki/wiki/sources/2026-07-08-demo-note.md with open(out_path, w, encodingutf-8) as f: f.write(content) print(写入完成, out_path) print(--- 生成内容预览 ---) print(content[:600])运行python scripts/ingest_demo.py成功时你会看到类似输出写入完成 D:/LLMWiki/wiki/sources/2026-07-08-demo-note.md --- 生成内容预览 --- --- title: 演示资料为什么知识库需要 AI 维护 type: source sources: - raw/2026-07-08-demo-note.md created: 2026-07-08 updated: 2026-07-08 confidence: medium --- ## 一句话摘要 ...5.3 校验动作lint 检查写入之后必须校验否则你不知道 AI 有没有漏 frontmatter、有没有断链。写一个轻量检查脚本# scripts/lint_wiki.py import os, re, glob ROOT D:/LLMWiki WIKI os.path.join(ROOT, wiki) INDEX os.path.join(WIKI, index.md) issues [] # 1. 检查 frontmatter for path in glob.glob(os.path.join(WIKI, **, *.md), recursiveTrue): name os.path.basename(path) if name in (index.md, log.md): continue with open(path, encodingutf-8) as f: text f.read() if not text.startswith(---): issues.append(f[缺 frontmatter] {path}) continue if type: not in text.split(---)[1]: issues.append(f[缺 type 字段] {path}) # 2. 检查页面是否进入索引 with open(INDEX, encodingutf-8) as f: index_text f.read() for path in glob.glob(os.path.join(WIKI, **, *.md), recursiveTrue): name os.path.basename(path) if name in (index.md, log.md): continue rel os.path.relpath(path, ROOT).replace(\\, /) if rel not in index_text and name not in index_text: issues.append(f[未进索引] {rel}) # 3. 输出报告 report_dir os.path.join(ROOT, outputs, lint) os.makedirs(report_dir, exist_okTrue) report_path os.path.join(report_dir, lint-2026-07-08.md) with open(report_path, w, encodingutf-8) as f: f.write(# Lint 报告 2026-07-08\n\n) if issues: f.write(\n.join(f- {i} for i in issues)) else: f.write(全部检查通过。\n) print(f检查完成问题数{len(issues)}) for i in issues: print( , i) print(报告, report_path)跑一次python scripts/lint_wiki.py如果摘要页没进索引你会看到[未进索引] wiki/sources/2026-07-08-demo-note.md。这时候让 AI 补一步把该页面挂到wiki/index.md的“来源”章节并在wiki/log.md追加一条记录。补完再跑 lint问题数归零闭环就通了。6. 本篇常见错排查报错 401 Unauthorized。九成是 Key 没读到。先确认环境变量在当前终端可见echo $env:TAOTOKEN_API_KEYPowerShell或echo $TAOTOKEN_API_KEYbash。如果为空说明 Key 只写进了配置文件但没导出到环境。另外检查请求头是不是Authorization: Bearer key少个空格也会 401。报错 404 Not Found。通常是 base_url 拼接问题。https://taotoken.net/api后面到底加不加/v1取决于客户端。用 curl 先测一次最小请求curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d {model:gpt-4o-mini,messages:[{role:user,content:ping}]}返回正常 JSON 说明路径对再回去改客户端配置。AI 生成的页面没有 frontmatter。提示词里要明确写“严格输出 Markdown包含 YAML frontmatter”并给出字段清单。模型有时会“忘记”在 lint 里把缺 frontmatter 作为硬性检查项跑一次就能发现。AI 改写了 raw/ 里的文件。这是协议问题不是模型问题。检查 AGENTS.md 里“raw/ 只新增不改写”这条有没有写清楚以及你的摄入脚本是不是只读 raw、只写 wiki。脚本层面做限制比靠提示词更可靠。索引和日志没更新。把“更新 index 和 log”作为摄入流程的最后一步写进提示词并在 lint 里检查页面是否进索引。漏了就让 AI 补补完再校验。模型返回超时。长资料一次送进去容易超时。config.toml 里的max_source_chars就是干这个的超过就分段处理或者换长上下文模型。重试次数设 3 次偶发网络抖动自动恢复。Key 泄露风险。任何时候不要把 Key 写进 config.toml、settings.json 或提交到 Git。统一走环境变量.gitignore里加上*.env和本地配置文件。项目 RAG 文档里也禁止记录任何凭据。7. 把 AI 接进知识库之后骨架搭好、配置跑通、lint 归零之后这套系统就能持续运转了。日常动作变成资料先进inbox/AI 定期消化进raw/和wiki/sources/稳定概念沉淀到wiki/concepts/项目资料整理成wiki/projects/下的 RAG 文档包每天生成简报、每周做复盘定期跑 lint 检查健康状态。如果你要长期跑编码或 Agent 类任务建议把 Coding Plan 配上统一 Key 在多个工具间复用会省很多事https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite想先验证模型输出质量可以直接在模型对话页试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewriteKey 管理和接入细节看这里https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 和 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite最后留一个我踩过的坑别一上来就把目录建得特别复杂。先用inbox/ raw/ wiki/ outputs/ prompts/这五个跑通一次完整摄入确认 AI 能正确读写、lint 能发现问题再按需扩展projects/和methods/。结构是长出来的不是一次设计出来的。