企业官网建设流程全解析

• 人工智能
• MCP 服务
• AI Agent
• 开发工具

本文以 ClaudeComputerCommander 仓库内置的obsidian-vault技能文档（skills/obsidian-vault/SKILL.md）为骨架，讲解如何借助该 MCP 服务器的文件系统与搜索工具，完成 Obsidian 知识库的导航搭建（MOC）、元数据规范化、仪表板生成、孤岛笔记清理、文件夹组织、去重与重命名，以及面向 AI 的笔记库预处理。读者学完后，将能直接用start_search、edit_block、write_file、read_multiple_files等工具在本地 Vault 上执行一整套可复现的维护工作流。

一、Obsidian 的三个底层事实：一切规则的前提

obsidian-vault技能（skills/obsidian-vault/SKILL.md）开篇先立了三条"塑造每一条规则"的 Obsidian 核心事实，理解它们才能理解后续所有操作为什么这样设计：

1. 链接是"按文件名解析"的 wikilink，不是按路径：[[Note title]]解析依赖文件名而非目录路径。在 Obsidian 内部重命名笔记会自动更新链接，但在 Obsidian 之外移动文件会破坏所有链接——因此凡是移动/重命名，都要优先引导用户回到 Obsidian 应用内完成，而不是用 MCP 的move_file硬搬。
2. 元数据是位于笔记顶部的 Properties（YAML frontmatter）：属性块是仪表板（Bases/Dataview）查询的数据来源，属性名与类型的统一直接决定后续自动化是否可靠。
3. 仪表板来自两个引擎：Dataview（插件、查询语言、只读、最灵活，适合报表与自动 MOC）与Bases（Obsidian 1.9 起内置、原生可编辑表格、大库更快、仅基于属性）。

在动手之前，技能要求先确认两件事：Vault 的根目录在哪里、用户是否安装了 Dataview 插件（Bases 自 Obsidian 1.9 内置）。当请求有歧义（"整理"还是"清理"还是"做仪表板"）时，先问清楚任务类型，再决定执行路径。

二、Wikilinks：内部导航的语法全集

技能文档给出了 wikilink 的完整语法矩阵，这些都是可以在 Vault 里直接复制的写法：

• 基础链接：[[Three laws of motion]]—— 只写文件名，不带扩展名和路径。
• 显示文本（管道语法）：[[atomic-habits|James Clear — Atomic Habits]]—— 管道符右侧是展示文本。
• 标题链接：[[Note#Section]]；块链接：[[Note#^block-id]]。
• 嵌入/转clusion：![[Note]]、![[Note#Section]]、![[image.png]]—— 感叹号前缀表示嵌入渲染。
• 别名：给笔记加aliases属性，让它能按其他名字被解析到。

文件名规范上，技能明确要求避免在文件名中使用#、|、^、:、%以及[、]——它们在链接语法里都有特殊含义，会造成解析歧义。内部导航优先用 wikilink；只有当 Vault 还要发布到无法解析 wikilink 的工具时，才退化为标准 Markdown 链接。

技能还强调：在添加链接的同时，要主动surface unlinked mentions——如果某篇笔记的标题以纯文本形式出现在其他笔记里（没有被[[ ]]包裹），应当顺手把它们转成真正的 wikilink。这一步既是链接卫生，也是后面"为 AI 使用做准备"的铺垫。

三、Maps of Content（MOC）：Vault 的导航层

MOC 是一篇聚合"某个主题下相关笔记链接"的导航笔记，它是比文件夹和标签都更灵活的导航层——不需要任何机构知识（institutional knowledge）就能维护。

技能给出的约定：

• MOC 自身要可被发现：命名清晰并打上tags: [moc]（或使用type: moc属性），让每个 MOC 本身也进入可查询范围。
• 保留一个顶层 Home / Index MOC：它链接到所有主题 MOC，是全库的单一入口（这也是后面 AI 读取 Vault 的首个文件）。
• MOC 的结构：一段简短介绍 + 分组 wikilink；可以手工维护，也可以用 Dataview/Bases 查询自动生成。

技能附带的 MOC 模板（可直接复制使用）：

--- type: moc tags: [moc] updated: 2026-06-18 --- # Auth — Map of Content Notes on authentication, sessions, and access control. ## Core - [[auth-flow]] - [[session-tokens]] ## Related MOCs - [[security-moc]]

从仓库源码看，MOC 的创建与后续写入完全由 Desktop Commander 的文件工具承载：write_file（src/server.ts）支持 rewrite/append 分块写入，适合先落一个 MOC 骨架；edit_block（src/server.ts）则用于在既有笔记里插入[[...]]wikilink——它要求"最小上下文 + 精确空白"，每个edit_block调用只做一次外科手术式替换，默认只替换一处，这正好符合"每篇笔记只插入一个链接、控制替换范围"的维护场景。

四、Frontmatter / Properties：让元数据全库一致

技能给出了一个推荐的基础属性块，并称之为"每篇笔记都应具备的基线"：

--- title: Session tokens aliases: [tokens, session token] tags: [auth, security] type: note # note | moc | dashboard | template | person | project created: 2026-06-18 updated: 2026-06-18 status: evergreen # seedling | growing | evergreen related: ["[[auth-flow]]"] ---

配套规则同样重要：

• 受控标签词表（controlled tag vocabulary）：标签要在动手前定好并持续复用，嵌套标签（auth/tokens）没问题，但不要让标签无限蔓延。
• frontmatter 里的tags不加#前缀；日期一律用 ISOYYYY-MM-DD。
• 属性名与类型全库一致：Bases 和 Dataview 都依赖这一点。规范化时，一个概念只保留一个名字（比如统一用created，而不是created/date/Created混用），并迁移其余写法。

这一步在 Desktop Commander 里的落地方式，对应工作流章节的 "Normalize metadata"：先用read_multiple_files（src/server.ts）批量读取笔记审计属性现状——该工具可同时读多个文件、单文件失败不影响整体、支持在允许目录内工作，正适合做全库属性普查；然后选定规范属性名，逐个用edit_block修改，最后补齐缺失的基线属性。

五、Dashboards：按场景选择 Bases 还是 Dataview

技能的核心决策原则是按用户环境和用途选引擎：

Bases（原生、可编辑、快——适合操作型看板）

• 创建.base文件或base代码块，由属性构建表格/看板视图；每个单元格直接编辑对应笔记的 frontmatter。
• 适用于任务清单、阅读清单、项目管线等一切"点一点就能改"的场景。

Dataview（插件、只读、最灵活——适合报表与自动 MOC）技能给出了三个开箱即用的查询示例：

TABLE status, updated, tags FROM #auth WHERE type = "note" SORT updated DESC

LIST FROM #auth WHERE type != "moc" SORT file.name ASC

TABLE updated FROM "" WHERE updated >= date(today) - dur(7 days) SORT updated DESC

第二个是"主题自动 MOC"的经典写法：列出主题下除 MOC 外全部笔记并按文件名排序，MOC 因此可以自动生长。第三个是"近期更新"报表。技能同时给出性能提醒：大 Vault 里重度 Dataview 查询会卡顿——这时优先用 Bases，这对应文档中"Bases fast on big vaults"的事实。

六、孤岛笔记与链接卫生：全库图的可信度基础

孤岛笔记（orphan）的定义：既没有入链（inbound）也没有出链（outbound）的笔记。技能给出了四条互补的发现路径，其中第一条是本文重点——因为它直接使用本 MCP 服务器的能力：

1. 从 Desktop Commander 直接查（无需打开应用、可扩展到大型 Vault）：用start_search在 Vault 里对每篇笔记的标题搜[[ ]]链接——零命中说明没有入链（即 unlinked note）；要确认真孤岛（入链出链都没有），再扫描笔记正文里是否有[[...]]。同一批搜索还能顺带暴露unlinked mentions（标题作为纯文本出现）和broken links（[[target]]指向的文件不存在）。
2. Graph view（Cmd/Ctrl+G）：孤岛会以孤立圆点悬浮在图边缘。
3. Dataview 查询（零链接笔记）：

LIST WHERE length(file.inlinks) = 0 AND length(file.outlinks) = 0

4. 修复动作：对每个孤岛，从相关 MOC/笔记插入 wikilink（用edit_block）、打上#needs-link标签留待批量处理，或直接归档废弃笔记。
5. 收尾：用edit_block把 unlinked mentions 转成真 wikilink、修复 broken links，其余在 Obsidian 右侧边栏处理。

这里值得展开start_search的源码级能力（src/server.ts）：

• 它支持两种搜索类型：searchType="files"（按文件名/扩展名找文件）与searchType="content"（在文件内容里找文本），并且当请求含糊时建议并行跑两个搜索再合并结果——这与"同时找入链 + unlinked mentions"的用法完全吻合。
• 模式匹配有两档：默认按正则表达式（literalSearch=false），而当模式含特殊字符（. * + ? ^ $ { } [ ] | \ ( )）时用literalSearch=true精确匹配——搜[[ ]]这类带方括号的字符串正是 literal 模式的典型场景（如pattern="[[auth-flow]]"、literalSearch=true）。
• 它是流式后台搜索：调用后立即返回 session ID，配合get_more_search_results渐进取结果、stop_search提前终止。底层由 Search Session Manager 管理（src/search-manager.ts），为每个会话生成search_${counter}_${timestamp}形式的 sessionId、管理 ripgrep 子进程生命周期并做会话清理——这正是"大 Vault 全库扫描"场景下不会卡死 Agent 的机制。

七、文件夹组织：粗桶 + MOC + 标签，不要过度嵌套

技能的核心观点是：文件夹只做粗粒度分桶，真正的组织靠 MOC 和标签。它给出一个可直接采用的分层布局：

00-inbox/ # unsorted captures 10-notes/ # atomic notes 20-mocs/ # maps of content 30-projects/ 90-assets/ # images/attachments 99-archive/ templates/

配套两条硬规则：

• 在 Settings 里设置附件文件夹，让嵌入文件落到90-assets/。
• 移动/重命名必须在 Obsidian 应用内完成（这样 wikilink 自动更新）——绝不要用move_file做这两件事，否则会打断每一个[[link]]。从 Desktop Commander 侧只编辑内容（edit_block/write_file），把移动和重命名留给用户在应用内执行。

这与move_file工具本身的定义并不矛盾：仓库中move_file（src/server.ts）被标注为destructiveHint: true，它的定位是通用文件移动/重命名（在允许目录内、可跨目录移动），但它不会反向更新 Obsidian 的 wikilink——这正是技能严禁用它做 Vault 内重命名的原因。这条"能力边界"的说明，是理解本技能安全准则的关键。

八、去重与重命名：合并笔记与安全改名

重复笔记的处理流程（技能原文步骤）：

• 用start_search搜索标题/别名找出近似重复的笔记；
• 合并为一篇：保留被链接最多的那个文件名，用edit_block拷贝唯一内容；
• 删除前，用start_search搜被废弃笔记的入链[[links]]并逐个重新指向新笔记。

重命名的硬规则：在 Obsidian 内完成（Rename note /F2）让反链自动更新——不是move_file。如果旧名字被广泛引用，保留一条aliases指向旧名。

文件名规范化：全库选定一种约定（kebab-case 或 Title Case）并一致执行，同时避开第一节列出的特殊字符。

九、为 AI 使用做准备：让 Agent 能可靠读取你的 Vault

技能把"让 AI 可用"总结为六个可执行项，这也是整个技能的落点：

1. 保证 frontmatter 一致（属性名/类型统一）——Agent 才能基于元数据过滤和推理；
2. 维护 Home/Index MOC作为 Agent 首个读取的单一入口；
3. 每篇笔记写一行summary/description属性，方便快速扫读；
4. 减少孤岛与 broken links，让链接图成为可信地图；
5. 保持笔记原子性（一篇一个想法）——便于 Agent 检索和引用；
6. 必要时导出 wikilink 为标准 Markdown 链接——如果 AI 工具无法解析[[ ]]。

这一节与第三节、第六节环环相扣：MOC 提供入口，属性提供过滤维度，链接卫生保证导航不失效，原子性保证引用的颗粒度。整条链路的最终收益是"Agent 读 Vault 时不会迷路、不会错引"。

十、四类标准工作流：把技能组装成日常操作

技能最后把上述所有能力组装成四条可执行工作流：

• Build navigation（搭导航）：write_file建主题 MOC →edit_block在笔记里写入链接 → 刷新 Home MOC → 转化 unlinked mentions。
• Normalize metadata（规范化元数据）：read_multiple_files审计属性 → 选定规范名 →edit_block逐篇修改 → 补齐缺失基线属性。
• Cleanup pass（清理轮）：start_search找孤岛、broken links、unlinked mentions → 去重 → 汇报变更（重命名留给 Obsidian）。
• Dashboard（做仪表板）：先确认 Dataview 还是 Bases → 基于属性/标签write_file出视图。

十一、收尾检查清单

技能给出了每次任务结束前的自检清单，可直接当作交付标准：

• 新增/修改的笔记 frontmatter 一致（规范属性名）
• 重命名/移动都在 Obsidian 内完成，没有链接被破坏
• 新笔记至少被一个 MOC 或笔记链接（不产生新孤岛）
• 标签来自受控词表
• 仪表板引用的属性和标签真实存在
• 变更过的笔记已更新updated

这套清单把"可验证"落到每一项上，配合 Desktop Commander 的搜索与编辑工具，意味着整个 Obsidian 维护流程可以被 Agent 半自动化执行、逐项核验并给出变更报告——这正是obsidian-vault技能文档从"手把手指引"升级为"可执行契约"的地方。完整技能原文见 skills/obsidian-vault/SKILL.md，同一技能在 plugins/claude/skills/obsidian-vault/SKILL.md（Claude 插件目录）与 plugins/cursor/skills/obsidian-vault/SKILL.md（Cursor 插件目录）各有对应副本，可供不同 Agent 环境直接加载。

• 人工智能
• MCP 服务
• AI Agent
• 开发工具