企业官网建设流程全解析

1. 项目概述：从零散笔记到智能知识库的进化

如果你和我一样，常年被海量的笔记、文章、会议记录淹没，每次想找点东西都得在文件夹里大海捞针，或者对着聊天记录问了一遍又一遍，那这个项目可能就是你的“第二大脑”构建器。obsidian-llm-wiki-local不是一个简单的笔记工具，它是一个基于本地大语言模型的“知识编译器”。它的核心思想很简单：你只管往一个文件夹里扔你的原始笔记（Markdown格式），剩下的交给它。它会自动阅读、提取核心概念、生成结构化的维基百科式的文章，并且随着你添加新笔记，整个知识库会像滚雪球一样，越滚越大，越来越聪明。

这个项目的灵感来源于 Andrej Karpathy 提出的“LLM Wiki”构想。Karpathy 认为，LLM 不应该只是一个健忘的聊天伙伴，而应该成为一个能持续积累、交叉引用、自我更新的知识管家。obsidian-llm-wiki-local正是这一构想的具体实现。它把 LLM 当作一个编译器，你的笔记是源代码，而最终产出的，是一个由相互链接的、结构化的维基文章组成的知识库。这个知识库直接以 Obsidian 库的形式存在，这意味着你可以立刻享受到 Obsidian 强大的图谱视图、反向链接和 Dataview 查询功能，而无需任何额外配置。

最吸引我的一点是它的“本地优先”和“拒绝反馈循环”设计。默认情况下，它完全依赖本地运行的 Ollama，你的数据无需离开你的电脑。同时，当你对 AI 生成的草稿不满意时，你可以直接拒绝并给出理由，比如“这个概述太模糊了，需要具体例子”。这个反馈会被系统记住，并在下一次针对该概念的编译中，作为提示词的一部分注入，引导模型修正问题。这种迭代优化的机制，让知识库的质量能随着你的“调教”而不断提升。

1.1 核心需求解析：为什么需要它？

在深入技术细节之前，我们先聊聊痛点。传统的个人知识管理（PKM）工具，无论是 Notion、Roam Research 还是 Obsidian 本身，都依赖于我们手动建立链接、整理结构。这非常耗费心力，而且随着笔记数量增加，维护成本呈指数级上升。而基于聊天的 AI 助手，虽然能即时回答问题，但每次对话都是孤立的，缺乏持久化的知识沉淀。

obsidian-llm-wiki-local瞄准的正是这个中间地带。它解决了几个核心问题：

1. 从“存储”到“理解”的自动化：它不只是存储你的笔记，而是主动理解内容，识别出“量子比特”、“神经网络”、“敏捷开发”这样的核心概念，并为每个概念创建独立的、内容聚合的文章。
2. 知识的“复利效应”：每当你添加一篇关于“量子计算”的新笔记，系统会自动找到已有的“量子计算”文章，将新信息融合进去，更新内容。知识不是孤立的，而是在不断叠加和增强。
3. 人机协作的编辑流程：它不追求全自动。生成的草稿需要你审核（olw review），你可以批准、拒绝或手动编辑。拒绝时的反馈会成为模型学习的养料，形成正向循环。这比完全手动整理省力，又比完全信任 AI 生成更可控。
4. 所有权与隐私：所有处理都在本地完成（使用 Ollama），生成的 Markdown 文件完全归你所有。没有云服务，没有数据泄露风险，符合“数字花园”的核心理念。

简单来说，它适合那些有大量阅读、学习、研究材料，希望将这些材料系统化、结构化，但又不想或没时间完全手动整理的人。研究员、学生、终身学习者、技术文档撰写者，都是它的目标用户。

2. 核心架构与工作流拆解

要理解这个工具，必须把它看作一个由三个核心阶段组成的自动化流水线。这个流水线巧妙地分配了 LLM 的不同任务，从轻量分析到深度写作，环环相扣。

2.1 第一阶段：摄取与分析

当你运行olw ingest或olw run时，流水线启动。首先登场的是“快速模型”（Fast Model），通常是一个 3B 到 8B 参数量的轻量级模型，比如gemma4:e4b。

它的任务清单：

1. 读取原始笔记：系统扫描raw/目录下的所有.md文件。
2. 提取核心概念：模型快速阅读笔记内容，识别并提取出文中提到的关键概念名词。例如，从一篇关于机器学习的笔记中，它可能提取出“监督学习”、“梯度下降”、“过拟合”。
3. 质量评估与摘要：模型会为这篇笔记生成一个质量评分和一个简短的摘要。这些元数据被存入一个 SQLite 数据库（state.db）中，用于后续的追踪和管理。
4. 创建源摘要页：同时，系统会在wiki/sources/目录下，为这篇原始笔记生成一个对应的摘要页面。这个页面记录了笔记的元信息，并链接回所有从它身上提取出的概念文章。

注意：raw/目录是神圣不可侵犯的。工具永远不会修改你的原始笔记。所有衍生数据和文章都存放在wiki/目录和.olw/state.db数据库中。这保证了源材料的纯净性。

2.2 第二阶段：编译与生成

这是核心的“写作”阶段，由“重型模型”（Heavy Model）执行，通常是一个 7B 以上参数量的模型，如qwen2.5:14b。重型模型拥有更大的上下文窗口，能处理更多信息。

它的工作流程：

1. 概念聚合：对于每一个被提取出来的概念（例如“梯度下降”），系统会从数据库中找出所有提及该概念的原始笔记。
2. 注入反馈：这是 v0.2 版本的杀手锏。如果这个概念之前生成的草稿被拒绝过，那么当时你提供的拒绝理由（如“缺少代码示例”）会被作为特殊指令，插入到本次生成的提示词中。模型会优先处理这些反馈。
3. 撰写维基文章：模型阅读所有相关的原始笔记内容（在上下文窗口限制内），综合这些信息，撰写一篇结构完整的维基文章。文章会使用 Obsidian 的[[双链语法]]自动链接到其他相关概念。
4. 添加置信度标注：如果模型认为生成的内容置信度不高（例如，信息源单一或内容矛盾），它会在文章中插入 HTML 注释进行标注，如<!-- olw-auto: single-source — cross-reference recommended -->。这些注释在 Obsidian 的预览模式下不可见，只在编辑器中显示，提醒审核者注意。
5. 输出草稿：生成的文章不会直接发布，而是先放入wiki/.drafts/目录下，等待人工审核。

2.3 第三阶段：审核与发布

这是“人”介入的关键环节。运行olw review会启动一个交互式命令行界面。

审核界面功能：

• 列表展示：列出所有待审核的草稿，并按被拒绝次数排序（被拒越多，排名越靠前，优先处理）。
• 差异对比：可以查看草稿与已发布版本（如果有）的差异，也可以查看与上一次被拒绝版本的差异，清晰了解修改轨迹。
• 操作选项：你可以选择批准（a）、拒绝（r）、直接编辑（e）或查看详情（d）。
• 反馈循环：如果选择拒绝，你必须输入一个理由。这个理由会被精准记录到该概念名下，并在下一次编译时使用。如果一个概念连续被拒绝 5 次，系统会自动将其“封锁”，暂停为其生成文章，直到你手动解封（olw unblock）。
• 发布与清理：批准后，文章会从.drafts/移动到wiki/主目录，所有 AI 添加的注释标签会被自动剥离。同时，系统会更新wiki/index.md这个导航文件，并自动进行一次 Git 提交（如果配置了auto_commit = true），为所有操作提供版本安全网。

整个流程形成了一个完美的闭环：笔记输入 -> 概念提取 -> 草稿生成 -> 人工反馈 -> 模型改进 -> 知识沉淀。你不再是知识的被动整理者，而是成为了一个知识库的“主编”和“训练师”。

3. 从零开始的完整实操指南

理论讲完了，我们上手实操。假设你是一个对量子计算和机器学习都感兴趣的开发者，手头有一堆零散的阅读笔记，现在让我们用obsidian-llm-wiki-local把它们变成结构化的知识库。

3.1 环境准备与安装

首先，我们需要一个 Python 环境。推荐使用uv，这是一个快速、现代化的 Python 包管理器和项目工具，能避免很多依赖冲突问题。

# 安装 uv (如果尚未安装) curl -LsSf https://astral.sh/uv/install.sh | sh # 安装完成后，重新打开终端或 source ~/.bashrc (或 ~/.zshrc) # 使用 uv 安装 obsidian-llm-wiki uv tool install obsidian-llm-wiki

安装完成后，你应该能在终端中直接使用olw命令。如果提示命令未找到，请检查你的$PATH是否包含了uv的工具目录（通常是~/.local/bin）。

接下来是模型部分。项目默认使用 Ollama 来本地运行大模型。Ollama 的安装非常简单。

# 前往 Ollama 官网 https://ollama.com 下载并安装对应操作系统的版本 # 安装后，启动 Ollama 服务（通常安装后会自动运行） # 拉取推荐的模型 ollama pull gemma4:e4b # 快速模型，用于分析和路由，约9.6GB ollama pull qwen2.5:14b # 重型模型，用于文章撰写，约14B参数

实操心得：如果你的显卡显存有限（例如只有 8GB），可以只拉取gemma4:e4b，并在后续设置中将它同时用作快速和重型模型。gemma4:e4b本身能力很强，完全能胜任文章生成任务，只是速度可能比专用的大模型慢一些。这是平衡速度与资源占用的实用策略。

3.2 初始化配置与知识库创建

安装好模型后，运行设置向导来配置工具。这个向导会交互式地引导你完成所有必要设置。

olw setup

向导会依次让你选择：

1. Provider（服务提供商）：默认是本地 Ollama。你也可以选择 Groq、Together AI 等云服务（需要 API Key）。我们这里选1(Ollama)。
2. URL：默认是http://localhost:11434。如果你的 Ollama 运行在其他机器上，可以修改。
3. Fast Model：选择用于分析的快速模型，从你本地已拉取的模型列表中选择，例如gemma4:e4b。
4. Heavy Model：选择用于写作的重型模型，例如qwen2.5:14b。
5. Default Vault（可选）：可以设置一个默认的知识库路径，这样以后运行命令就不用每次都指定--vault参数了。

配置信息会保存在~/.config/olw/config.toml（Linux/Mac）或%APPDATA%\olw\config.toml（Windows）。特别注意：如果你选择了云服务商，API Key 只会保存在这个用户配置文件中，而不会出现在项目仓库的wiki.toml里，这保证了安全性。

现在，创建一个属于你的知识库：

olw init ~/Documents/My-Llm-Wiki

这个命令会做几件事：

• 在~/Documents/My-Llm-Wiki目录下创建标准的文件夹结构。
• 初始化一个 Git 仓库（用于版本控制和安全回滚）。
• 生成一个wiki.toml配置文件，其中包含了你在olw setup中选择的模型设置。

你的知识库目录结构将会是这样的：

My-Llm-Wiki/ ├── raw/ # 【你存放原始笔记的地方】 ├── wiki/ # 【系统生成的维基文章】 │ ├── .drafts/ # 待审核的草稿（Obsidian默认隐藏） │ ├── sources/ # 原始笔记的摘要页面 │ ├── index.md # 自动生成的导航页 │ └── log.md # 操作日志 ├── vault-schema.md # 给LLM看的本库编写规范 ├── wiki.toml # 配置文件 └── .olw/ # 内部状态数据库和锁文件（隐藏目录）

3.3 投入第一批“原料”并运行流水线

知识库建好了，现在是投入“原料”的时候了。把你任何格式的笔记（最好是 Markdown）复制或保存到raw/目录下。比如，我放入了三篇笔记：

• raw/量子计算入门.md
• raw/神经网络基础.md
• raw/敏捷开发实践.md

笔记内容无需完美，可以是读书摘要、博客文章剪藏、会议记录，甚至是零碎的想法。接下来，运行完整的流水线：

cd ~/Documents/My-Llm-Wiki olw run

olw run是一个组合命令，它依次执行：

1. olw ingest --all：分析raw/下的所有笔记，提取概念。
2. olw compile：为每个提取出的概念生成维基文章草稿。
3. olw lint：进行健康检查（如查找孤立的链接）。
4. 如果配置了auto_approve = true，则会自动发布草稿。默认需要手动审核。

第一次运行可能会花一些时间，取决于你的笔记数量和模型速度。完成后，运行olw review来审核生成的草稿。

3.4 审核与反馈：扮演“主编”

olw review的界面非常直观。你会看到一个编号列表，显示所有待审核的草稿。每个条目会显示概念名、来源笔记数量以及是否有低置信度标注。

1. 量子计算 (2 sources) [LOW CONFIDENCE] 2. 反向传播 (1 source) 3. 冲刺（Sprint） (1 source) ... Select draft number (a=approve all, r=review all, q=quit):

选择编号1查看“量子计算”的草稿。你可以：

• 按d查看与已发布版本的差异（首次发布则无）。
• 按e直接用默认编辑器（如 VSCode）打开草稿进行手动编辑。
• 按a批准发布。
• 按r拒绝。

这里就是“拒绝反馈循环”发挥作用的地方。假设你觉得这篇关于“量子计算”的草稿太过理论化，缺乏实际应用的例子。你按r拒绝，系统会提示你输入反馈理由：

Rejection reason for “量子计算”: 内容偏重理论，缺乏实际应用案例和当前技术进展的介绍。

输入理由并确认。这个反馈会被存入数据库。当下一次有新的关于“量子计算”的笔记被添加，或者你手动重新编译（olw compile）时，模型在撰写“量子计算”文章前，会看到这样的提示：“之前的拒绝理由：内容偏重理论，缺乏实际应用案例和当前技术进展的介绍。” 从而在新草稿中着重补充这部分内容。

批准后，用 Obsidian 打开~/Documents/My-Llm-Wiki这个文件夹作为仓库。你会立刻在图谱视图中看到“量子计算”、“神经网络”等概念节点，以及它们与sources/下的源笔记之间的连接线。一个由 AI 辅助构建、由你主导审核的个人知识图谱，就此诞生。

4. 高级配置与性能调优

默认配置适合大多数入门场景。但随着知识库的增长，你可能需要对其进行调优，以提升速度、质量或适应不同的硬件环境。

4.1 理解并配置上下文窗口

在wiki.toml的[ollama]或[provider]部分，有两个关键参数：fast_ctx和heavy_ctx。它们决定了模型一次能处理多少文本，直接影响处理长文档的能力和生成文章的质量。

• heavy_ctx(默认 32768)：这是重型模型的上下文窗口大小（单位：Token）。它决定了：
  • 源材料预算：模型在撰写一篇概念文章时，能阅读多少相关的原始笔记内容。预算大约是heavy_ctx / 2个字符。
  • 文章长度：模型生成的文章长度也受此限制。
  • VRAM 消耗：值越大，消耗的显存越多。

• fast_ctx(默认 16384)：这是快速模型的上下文窗口。它决定了在ingest阶段，一次能分析多长的笔记。如果笔记长度超过fast_ctx / 2字符，系统会自动将其分割成多个块（chunk）进行顺序分析，不会丢失任何内容。

重要提示：如果你使用的模型本身支持很大的上下文（例如gemma4:e4b支持 128K），而你的显存也足够，强烈建议调高heavy_ctx。这能让模型在撰写文章时看到更多的上下文，生成质量更高、更连贯的内容。修改wiki.toml后，需要运行olw compile --force来用新的上下文预算重新生成文章。

4.2 启用并行处理以加速长文档摄取

如果你有很多长篇笔记（比如完整的电子书章节），ingest阶段可能会比较慢。你可以启用并行处理来加速。

首先，确保你的 Ollama 服务以支持并行请求的方式启动（需要 Ollama 版本 >= 0.1.34）：

# 在启动 Ollama 服务前设置环境变量 OLLAMA_NUM_PARALLEL=4 ollama serve # 或者，如果你已经通过系统服务运行 Ollama，可能需要修改服务配置文件。

然后，在wiki.toml中启用并行摄取：

[pipeline] ingest_parallel = true

原理与注意事项：这允许 Ollama 同时处理一个长笔记被分割后的多个块。例如，一个 25K 字符的笔记被分成 4 块，可以并行分析。在 16GB VRAM 上，使用gemma4:e4b(9.6GB) 时，同时处理 4 个请求大约需要 12.8GB 显存，是可行的。实测中，这可以将处理时间从约 39 秒缩短到 14 秒。但如果你的显存紧张，或者模型本身很大，开启并行可能导致内存不足（OOM）错误。

4.3 多服务提供商切换实战

虽然本地 Ollama 是默认和推荐的选择，但工具支持任何 OpenAI 兼容的 API 端点。这在你想体验更强大模型（如 GPT-4）或没有足够本地算力时非常有用。

场景：使用 Groq 云服务（免费额度，速度极快）

1. 获取 API Key：前往 Groq 官网注册并获取 API Key。
2. 重新运行设置向导：

   olw setup

   在 Provider 选择时，选择 Groq（对应编号，例如10）。 输入 Groq 的 API 端点 URL：https://api.groq.com/openai/v1。 在提示输入 API Key 时，粘贴你的 Groq API Key。这个 Key 会被安全地保存在用户配置文件中。 为 Fast 和 Heavy 模型选择 Groq 提供的模型，例如llama-3.1-8b-instant(Fast) 和llama-3.3-70b(Heavy)。
3. 更新现有仓库配置：如果你已经有一个仓库，需要将新的提供商配置同步进去：

   olw init ~/Documents/My-Llm-Wiki # 使用 `--existing` 标志来更新已有仓库的配置，而不会覆盖你的 raw/ 和 wiki/ 数据。

   这会在wiki.toml中生成一个[provider]部分，覆盖之前的[ollama]设置。

环境变量覆盖：你也可以不修改全局配置，而是通过环境变量临时指定 API Key：

export GROQ_API_KEY=your_key_here olw run --vault ~/Documents/My-Llm-Wiki

这种方式更灵活，适合在不同项目或不同 API Key 间切换。

5. 日常维护与问题排查实录

工具设计得足够健壮，但在日常使用中，你仍可能会遇到一些典型情况。以下是我在深度使用过程中积累的常见问题与解决方案。

5.1 编译失败与重试机制

运行olw compile后，你可能会在输出末尾看到类似信息：

Generated 15 article(s) (13 succeeded, 2 failed: 方法论, 冲刺)

这表示有两个概念的文章生成失败了。别担心，这通常是暂时的。

原因分析：失败通常是因为 LLM 在生成特定概念的 JSON 输出时格式出错，或者遇到了非常模糊、矛盾的多源信息。工具内置了 3 层重试机制，会尝试修复格式问题。如果最终仍失败，才会标记为“失败”。

标准操作流程：

1. 自动重试：失败的概念会被记录。下一次运行olw compile时，系统会优先尝试重新生成这些失败的概念。很多时候，第二次就能成功。
2. 手动强制重试：如果你想立即重试，可以使用：

   olw compile --retry-failed

3. 调整配置：如果某个概念持续失败，可能是上下文窗口 (heavy_ctx) 太小，模型无法看到足够的信息来合成文章。尝试在wiki.toml中增大heavy_ctx值，然后运行olw compile --force。
4. 检查源材料：去raw/目录下，看看提及这个失败概念的原始笔记。是不是内容太短、太模糊或者自相矛盾？补充或修正原始笔记，然后重新运行olw ingest FILE和olw compile。

5.2 概念被“封锁”了怎么办？

这是“拒绝反馈循环”的一个保护机制。如果一个概念连续 5 次生成的草稿都被你拒绝，系统会认为当前模型无法满足你对这个概念的写作要求，从而自动将其“封锁”。被封锁的概念将不再参与后续的编译，以避免浪费算力和你的审核时间。

如何识别：运行olw status命令，输出中会有一个“Blocked concepts”部分，列出所有被封锁的概念。

解决方案：

1. 解封并继续调教：如果你认为模型经过几次反馈后有可能写出合格文章，可以解封它。

   olw unblock “敏捷开发”

   解封后，该概念会重新进入编译队列。
2. 手动创建或修改：如果对 AI 生成彻底失望，你可以直接在wiki/目录下手动创建或编辑敏捷开发.md文件。工具有一个重要特性：对于任何手动编辑过的文章，编译器会检测到并跳过，不会用 AI 生成的内容覆盖你的手工成果。这是对用户劳动的尊重。
3. 调整源材料：封锁的根本原因可能是源材料质量不佳。尝试为这个概念添加更多高质量、清晰的原始笔记，然后再解封尝试。

5.3 知识库健康度检查与自动维护

随着文章越来越多，可能会出现“僵尸链接”（链接指向不存在的文章）或“孤儿文章”（没有被任何其他文章链接）。olw maintain命令是你的知识库管理员。

# 检查健康状态，列出问题但不修改 olw maintain --dry-run # 自动修复发现的问题（创建缺失文章的存根、修复链接等） olw maintain --fix

--fix参数会执行以下操作：

• 创建存根文章：对于所有被引用但还不存在的[[wikilink]]，在wiki/下创建一个简单的存根文件（Stub），里面只包含标题和一条注释，提示这是自动创建的存根。这可以防止 Obsidian 图谱中出现断裂的节点。
• 提出合并建议：如果系统发现两个概念文章内容高度相似（例如“机器学习”和“ML”），它会建议你合并它们。
• 警告源分布不均：如果一个概念的文章只基于一个来源，它会提醒你补充更多资料以提高文章质量。

定期运行olw maintain --fix是一个好习惯，它能保持你的知识库整洁、链接完整。

5.4 查询你的知识库

知识库建好了，怎么用？除了用 Obsidian 搜索，你还可以用自然语言直接提问：

olw query “量子计算和经典计算的根本区别是什么？”

工具会利用wiki/index.md生成的索引，快速定位相关文章，并指令重型模型基于这些文章的内容生成答案。如果你觉得答案很有价值，可以保存下来：

olw query “请解释梯度下降算法的几种变体” --save

这会将问题和答案保存到wiki/queries/目录下，成为知识库的一部分。这里有一个关键点：olw query的答案是基于已发布的wiki/中的文章内容生成的，而不是直接去读raw/笔记。这保证了答案与你的知识库现状一致，并且经过了你的审核。

5.5 版本控制与安全回滚

工具深度集成了 Git。每次通过olw工具批准发布文章或运行维护命令，只要配置了auto_commit = true（默认），都会自动创建一个提交，提交信息类似[olw] Publish ‘Quantum Computing’。

这提供了一个强大的安全网。如果你不小心批准了一篇错误的文章，或者想回退到之前的状态，非常简单：

olw undo

这个命令会执行git revert，撤销最近一次由olw创建的提交。你的wiki/目录和状态数据库会回退到操作前的样子。请注意：olw undo只针对olw的自动提交。你手动对文件做的修改不受影响，也需要通过 Git 手动管理。

6. 与 Obsidian 生态的深度集成技巧

obsidian-llm-wiki-local的产出是纯 Markdown，并且天然使用 Obsidian 的[[双链]]语法，这使得它与 Obsidian 生态的结合天衣无缝。以下是一些提升体验的高级技巧。

6.1 利用 Dataview 进行高级查询

Obsidian 的 Dataview 插件能让你用类 SQL 的语法查询笔记元数据。虽然olw生成的文章本身没有复杂的 Frontmatter，但你可以利用其生成的文件结构和链接关系。

例如，在wiki/目录下创建一个Dashboard.md文件，写入以下 Dataview 查询：

## 低置信度文章 ```dataview LIST FROM "wiki" WHERE file.path != this.file.path AND contains(file.name, "olw-auto: low-confidence") ``` ## 单来源文章 (需要补充) ```dataview LIST FROM "wiki" WHERE file.path != this.file.path AND contains(file.name, "olw-auto: single-source") ``` ## 最近更新的文章 ```dataview TABLE file.mtime AS "修改时间" FROM "wiki" WHERE file.path != this.file.path SORT file.mtime DESC LIMIT 10 ```

这样，你就能在一个面板里快速看到哪些文章需要你特别关注（低置信度），哪些文章来源单一需要你补充阅读，以及最近更新了哪些知识。

6.2 配置 Web Clipper 实现一键收藏

理想的工作流是：在网上看到好文章，一键剪藏到raw/目录，然后由olw自动处理。这完全可以实现。

1. 使用 Omnivore、Raindrop.io 等支持 API 和 Markdown 导出的稍后读工具。将它们配置为将文章导出为 Markdown。
2. 编写一个简单的脚本（如 Python 或 Shell），监听导出目录，将新文件自动移动到你的知识库raw/文件夹下。
3. 运行olw watch服务：在知识库目录下，执行olw watch。这个命令会监控raw/文件夹，任何新文件放入都会自动触发ingest和compile流程。

这样，你就建立了一个从“信息输入”到“知识内化”的半自动化流水线。剪藏 -> 自动分析 -> 生成草稿 -> 等待审核。极大地减少了从阅读到整理的摩擦。

6.3 处理手动编辑与 AI 生成的冲突

如前所述，工具尊重手动编辑。其原理是检查文件的“最后修改时间”和“作者”。如果系统发现一个wiki/下的文件最后修改者不是olw（或者修改时间在最后一次自动生成之后），就会将其标记为“手动编辑”，并在后续编译中跳过。

如果你想重新让 AI 接管某个已手动编辑的文章怎么办？

1. 最简单的方法是重命名或删除wiki/下的那个文件。
2. 然后运行olw compile。系统会发现这个概念的文章“缺失”了，从而为其生成新的草稿。
3. 通过olw review审核新的 AI 草稿。

另一种方法是利用版本控制：使用olw undo回退到 AI 生成的那个版本，然后在那个基础上进行手动编辑。这样历史清晰。

我个人在实际操作中的体会是，最好的模式是“AI 打底，人工精修”。让 AI 完成初稿的框架和基础信息聚合，然后我在此基础上进行润色、补充个人见解、更新最新案例。这样既利用了 AI 的归纳能力，又保留了人的判断力和创造性。obsidian-llm-wiki-local完美地支持了这种协作模式。它不是一个替代你的工具，而是一个强大的知识副驾，将你从繁琐的信息整理中解放出来，让你能更专注于思考、连接与创造。