企业官网建设流程全解析

在 Obsidian 里设计模板，很多人的第一反应是排版好看、字段够用、变量能自动填充。但当模板的使用者从“人”扩展到“AI”之后，问题就完全变了：AI 不会像人一样从上下文里猜测“参会人”和“项目成员”有什么区别，也不会自动判断“状态”字段到底该填“进行中”还是“已完成”。如果模板本身信息不足，AI 生成的笔记就会结构完整但内容悬浮，看起来像那么回事，实际没法用于检索和汇总。

这篇文章围绕一个具体目标展开：用三份文件——模板文件、示例文件、规则文件——设计出一套连 AI 都能一眼看懂的 Obsidian 模板系统。搭建完成后，不管是手动记录，还是让 AI 插件根据关键词生成笔记，输出都能保持统一结构、清晰语义，并且能用 Properties 或 Dataview 做后续查询。文章会给出完整文件内容、变量语法说明、常见坑和排查路径，适合正在用 Obsidian 管理项目、会议、研究笔记，并且希望把 AI 真正接入笔记流程的人。

1. 先理解：Obsidian 模板为什么还要考虑 AI 能不能看懂

1.1 传统模板只有“骨架”，没有“语义”

传统的 Obsidian 模板解决的是重复输入问题。它的核心价值是：新建笔记时，把标题、表格、分区一次性铺好，人只需要往空位里填内容。

但人填内容时，会自动调用大量背景知识。看到一个“状态”字段，人知道它大概率指“待办、进行中、已完成”；看到“参会人”和“负责人”，人知道前者是列席者，后者是对结果负责的人。这些知识没有写在模板里，而是存在于人脑里。

AI 没有这个背景。它拿到模板后，看到的只是一堆 Markdown 标题、表格列名和空行。如果你不告诉它“状态”字段的合法取值，它可能填“主要工作”，可能填“进行中”，也可能填“OK”。如果你不告诉它“参会人”要不要用 Obsidian 内部链接[[姓名]]，它可能会写成纯文本，也可能写成带昵称的格式。每生成一次，格式漂移一次。

所以，面向 AI 的模板，核心问题不是“排版是否好看”，而是“字段语义是否明确、取值约束是否完整、结构规则是否可解析”。

1.2 让 AI 看懂模板需要三层信息

把模板拆开看，AI 要理解一份模板，至少需要三类信息：

结构层可以用一个模板文件解决，语义层和约束层则需要额外文件承载。这也是为什么“三份文件”比“一份文件”更可靠。

一份模板文件适合人使用，因为人擅长从留白中补全信息。但 AI 更适合“结构模板 + 填充示例 + 规则约束”的组合：模板告诉它长什么样，示例告诉它怎么填，规则告诉它边界在哪里。

2. 三份文件的分工：模板文件、示例文件、规则文件

2.1 三份文件分别解决什么问题

三份文件的角色不是随意划分的，而是对应 AI 理解和生成内容的三个关键环节：

模板文件是最先想到的，但示例文件的作用经常被低估。对 AI 来说，一个字段的取值规则，用文字描述十句，不如一个真实填写示例来得直接。示例文件本质上就是 few-shot prompt：AI 读完示例后，会模仿示例的措辞、格式、链接风格，而不是自己发明一套。

规则文件则负责“踩刹车”。AI 是概率生成模型，它在模仿示例时可能会过度发挥：把示例里的具体人名带进新笔记，把表格列名改掉，或者因为上下文信息不足而编造数据。规则文件要用明确、简洁、可检查的条款，把这部分风险压下来。

2.2 目录结构要固定，命名要有规律

三份文件建议放在同一个模板目录下，子目录分开。

你的Vault/ ├── _templates/ │ ├── template-项目复盘会议.md │ ├── samples/ │ │ └── sample-项目复盘会议.md │ └── rules/ │ └── rule-项目复盘会议.md

命名规律很重要。用template-、sample-、rule-三个前缀区分文件角色，后面接统一的业务名，比如“项目复盘会议”。这样即使是 AI 扫描 vault 目录，也能从文件名推断文件用途。

注意：模板文件必须放在 Obsidian 核心模板插件指定的模板文件夹里，否则插入模板时找不到。示例文件和规则文件不需要被模板插件识别，它们只是普通 Markdown 文件，最好也放在 vault 内，这样 AI 插件按 vault 路径检索时能读得到。

2.3 三份文件的配合方式

使用场景有两种：

手动建笔记：只使用模板文件，把模板插入新笔记，人自己填内容。示例文件作为参考，规则文件一般不用读。

AI 生成笔记：把模板文件、示例文件、规则文件一起作为输入。推荐顺序是先让 AI 读规则文件，再给它看模板文件和示例文件，最后要求它按规则生成。规则文件优先于模板结构，模板结构优先于示例措辞。

在 AI 插件里，不同的插件引用文件的方式不一样。有的支持在对话框中输入@路径或[[链接]]，有的需要手动粘贴内容。使用前先读插件的说明。无论插件能力如何，三份文件都放在 vault 内，始终是能被读取的前提。

3. 环境准备：Obsidian 与插件配置

3.1 Obsidian 本体与核心模板插件

首先保证 Obsidian 本体可用，并启用内置的“模板”核心插件。

操作路径：设置 -> 核心插件 -> 模板 -> 开启，然后在模板插件设置里指定模板文件夹位置，例如_templates。

核心模板插件支持几个简单变量：

这套变量足够覆盖大多数模板。它们的优点是简单稳定，缺点是表达能力有限，不能做条件判断、循环、文件名截断等逻辑。

3.2 可选的 Templater 与 AI 插件

如果你需要更灵活的模板逻辑，可以安装社区插件 Templater。Templater 使用<% ... %>语法，能调用tp.date.now("YYYY-MM-DD")、tp.file.title、tp.system.prompt等函数，还能嵌入 JavaScript 代码片段。

但要注意：Templater 功能越强，模板的“可读性”越差。AI 面对一段<% tp.date.now("YYYY-MM-DD") %>时，无法判断这是日期还是文件名。所以在面向 AI 的模板里，优先用核心模板插件的简单变量；如果项目已经依赖 Templater，则把复杂逻辑封装好，并在规则文件里说明变量含义，避免 AI 误解。

AI 集成可以通过社区插件实现，例如 Copilot、Text Generator、Smart Connections 等。不同插件的底层模型、上下文长度、文件引用方式差异较大。安装前先看对应 GitHub 仓库是否与当前 Obsidian 版本兼容，再查看设置项中的模型配置和提示词入口。

3.3 推荐的最低环境组合

最低组合其实只需要 Obsidian 和核心模板插件，再加上规则文件和示例文件。AI 插件只是把“人读规则”替换成“AI 读规则”，文件设计本身并不依赖某个特定插件。

4. 实战：用三份文件搭建一个“项目复盘会议纪要”模板

下面以“项目复盘会议纪要”为例，完整实现三份文件。这个场景非常典型：字段多、表格多、状态枚举多、需要跨笔记追溯，而且 AI 参与生成的收益很大。

4.1 模板文件：结构优先，能填空就行

在_templates目录下新建template-项目复盘会议.md：

--- type: meeting-minutes title: "{{title}}" date: {{date}} attendees: [] focus: project-review status: draft tags: - meeting/project-review --- # {{title}} <!-- AI:System 这是会议纪要模板。请保留所有 H2 结构和表格列名，只填充和补全内容，不要删除任何分区。 --> ## 会议信息 - 会议时间: - 主持人: - 记录人: - 参会人: ## 会议目标 （一句话说明本次会议要解决什么问题） ## 上期行动项检查 | 行动项 | 负责人 | 状态 | 备注 | | --- | --- | --- | --- | | | | | | ## 讨论纪要 ### 议题一： （背景、讨论、结论） ## 决策记录 | 决策编号 | 决策内容 | 提出人 | 影响范围 | | --- | --- | --- | --- | | | | | | ## 行动项 | 行动项 | 负责人 | 截止日期 | 优先级 | 状态 | | --- | --- | --- | --- | --- | | | | | | | ## 风险与阻塞 - 风险/阻塞: - 影响: - 应对措施: ## 下次会议 - 时间: - 重点议题:

关键设计点：

• frontmatter 里用type、status、focus三个机器可读字段。type用于区分笔记类型，status用于标记会议状态，focus用于分类。
• 所有 H2 标题都是名词短语，不包含修饰性内容，AI 更容易识别。
• 表格列名固定，不写“示例”“说明”这类多余列，避免 AI 在生成时把示例文字当成正式内容。
• <!-- AI:System ... -->是一段 HTML 注释。在 Obsidian 阅读和实时预览模式下不会显示，但 AI 读取文件时能看到，相当于内嵌在模板里的系统提示词。

4.2 示例文件：给 AI 一个完美的“标准答案”

在_templates/samples目录下新建sample-项目复盘会议.md：

--- type: meeting-minutes title: "里程碑评审：2025-03-10" date: 2025-03-10 attendees: - "[[张明]]" - "[[李婷]]" - "[[王峰]]" focus: project-review status: completed tags: - meeting/project-review --- # 里程碑评审：2025-03-10 ## 会议信息 - 会议时间: 2025-03-10 14:00-15:30 - 主持人: 张明 - 记录人: 李婷 - 参会人: [[张明]], [[李婷]], [[王峰]] ## 会议目标 确认第二阶段里程碑是否达标，并决定是否需要延期。 ## 上期行动项检查 | 行动项 | 负责人 | 状态 | 备注 | | --- | --- | --- | --- | | 完成用户端接口联调 | 张明 | 已完成 | 提前两天完成 | | 输出性能测试报告 | 李婷 | 已完成 | 见附件 | | 搭建灰度发布环境 | 王峰 | 进行中 | 预计本周五完成 | ## 讨论纪要 ### 议题一：接口联调结果 接口联调已全部通过，主要接口平均响应时间在 300ms 内，达到预期。 ### 议题二：性能瓶颈 压测场景下数据库连接池存在瓶颈，需要调整最大连接数并增加慢查询日志。 ## 决策记录 | 决策编号 | 决策内容 | 提出人 | 影响范围 | | --- | --- | --- | --- | | D-01 | 第三阶段允许提前启动 UI 开发 | 张明 | 研发、设计 | | D-02 | 增加连接池参数优化专项 | 王峰 | 后端、运维 | ## 行动项 | 行动项 | 负责人 | 截止日期 | 优先级 | 状态 | | --- | --- | --- | --- | --- | | 调整数据库连接池参数 | 王峰 | 2025-03-14 | 高 | 待办 | | 补充慢查询日志指标 | 李婷 | 2025-03-12 | 中 | 待办 | | 输出第三阶段排期计划 | 张明 | 2025-03-13 | 高 | 进行中 | ## 风险与阻塞 - 风险/阻塞: 性能测试环境硬件资源不足 - 影响: 高并发验证不充分 - 应对措施: 向运维申请临时扩容，并在生产环境逐步放开流量 ## 下次会议 - 时间: 2025-03-17 14:00 - 重点议题: 第三阶段计划评审、连接池优化效果复查

这份示例的作用不是给人类看的，而是让 AI 学习“填空规则”。注意几个细节：

• 参会人使用 Obsidian 内部链接格式[[张明]]，AI 看到后就会在新笔记里模仿。
• 日期格式统一为YYYY-MM-DD。
• 状态字段已完成 / 进行中 / 待办与规则文件中的枚举值保持一致。
• 决策编号、风险字段都有真实内容，AI 会把这些当作格式范本。

4.3 规则文件：约法三章，避免 AI 自由发挥

在_templates/rules目录下新建rule-项目复盘会议.md：

# AI 规则：项目复盘会议纪要 生成会议纪要时，规则文件的优先级最高，其次是模板文件，最后参考示例文件。 ## 必填字段 | 字段 | 说明 | 取值 | | --- | --- | --- | | type | 笔记类型 | 固定为 meeting-minutes，不要修改 | | title | 会议标题 | 与一级标题保持一致 | | date | 会议日期 | 格式 YYYY-MM-DD | | attendees | 参会人列表 | 使用 Obsidian 内部链接 [[姓名]] | ## 必填分区 - 上期行动项检查：必须保留“行动项、负责人、状态、备注”四列表格 - 决策记录：每条决策必须包含决策编号，编号格式 D-01、D-02 - 行动项：每个行动项必须包含负责人、截止日期、优先级、状态 - 风险与阻塞：必须包含风险描述、影响、应对措施三项 ## 枚举取值 状态字段只允许： - 待办 - 进行中 - 已完成 - 已取消 优先级只允许： - 高 - 中 - 低 ## 禁止行为 - 不要编造参会人姓名和讨论内容 - 不要修改模板中的表格列名 - 不要在会议纪要里加入模板说明文字 - 不要使用“TODO”“TBD”之外的状态描述 - 不要省略“决策记录”分区，即使没有决策也保留表格并填写“无” ## 校验清单 生成或补全完成后，按以下顺序检查： 1. frontmatter 的 type 是否仍为 meeting-minutes 2. 一级标题是否与 title 字段一致 3. 所有表格是否保留原始列名 4. 状态字段是否在允许取值内 5. 是否删除了模板中原本存在的空分区 6. 参会人是否全部使用内部链接格式

规则文件不是越长越好，越长的规则越容易被 AI 忽略。用表格和清单压缩信息密度，让每条规则都能直接检查。

“没有决策也保留表格并填写‘无’”这个条规则是具体的业务约定，体现了规则文件的真正价值。它把 AI 从“必须编内容”里解放出来，AI 没有信息时可以直接写“无”，而不是强行编造。

5. 关键设计细节：字段、枚举、注释与变量

5.1 用 frontmatter 给 AI 机器可读的元数据

Obsidian 的 frontmatter（YAML 属性区）不仅是人类查看属性的工具，也是 AI 理解笔记类型的最直接入口。

设计 frontmatter 时要注意几点：

• type字段必须用固定的字符串值，如meeting-minutes。不要用${type}这类占位符，AI 无法解析。
• status字段倾向用枚举值。枚举值要提前在规则文件里定义，AI 才能确定范围。
• attendees这类多值字段使用 YAML 列表格式，不要用逗号分隔的字符串，否则 Properties 和 Dataview 解析时会出现类型错误。
• tags遵循 Obsidian 标签规范，使用meeting/project-review层级格式，方便后续检索。

错误写法示例：

--- type: 会议纪要 date: 2025/3/10 attendees: 张明, 李婷 status: 需要确认一下进度 ---

推荐写法：

--- type: meeting-minutes date: 2025-03-10 attendees: - "[[张明]]" - "[[李婷]]" status: draft ---

字段名本身也要自解释。如果字段叫att，AI 不知道是“参会人”还是“附件”。直接写attendees，多几个字符的成本远低于 AI 猜错后的修正成本。

5.2 用 HTML 注释给 AI 隐形指令

模板文件里可以嵌入<!-- ... -->注释，AI 读取时能看到内容，而 Obsidian 界面渲染时不会显示。这非常适合给 AI 传指令。

例如模板开头：

<!-- AI:System 这是会议纪要模板。请保留所有 H2 结构和表格列名，只填充和补全内容，不要删除任何分区。 -->

使用注释时要注意：注释只是提示，不是绝对约束。如果规则文件里已经明确“不要删除分区”，注释里可以只做简短提醒，避免重复指令占空间。注释内容应保持短句，一段话超过 50 个字，AI 的注意力会分散。

不要用 Markdown 的普通文本写这类指令。如果写成：

这是会议纪要模板。请保留所有 H2 结构和表格列名，只填充和补全内容。

这段文字会被渲染成正文，人看到困惑，AI 也可能把它当成正文内容的一部分。HTML 注释是更安全的选择。

5.3 模板变量语法要统一，不要混用

Obsidian 有至少两套模板变量体系，它们的语法不兼容：

如果在同一个模板里混用这两套语法，核心模板插件插入时会把<% ... %>当作普通文本输出，Templater 则会把{{date}}原样保留。最终生成的笔记里会出现大量未解析的占位符。

在面向 AI 的模板里，推荐两个做法：

做法一：只用核心模板插件变量，把<% ... %>全部移出模板。适合大多数场景。

做法二：如果已经用了 Templater，则不要在模板文件里混入核心插件变量，并额外在规则文件里写清楚：

## 变量说明 - <% tp.file.title %> 会被替换为当前笔记文件名 - <% tp.date.now("YYYY-MM-DD") %> 会被替换为当前日期 - 请不要在生成内容中保留这些变量原样

另外要留意：变量被替换后，如果 AI 看到的还是<% ... %>或{{date}}，说明模板插入流程没有执行成功。这种情况不要直接喂给 AI，先解决变量替换问题，否则 AI 会把占位符当正文。

6. 让 AI 真正用起来：最小工作流与验证方法

6.1 从模板到成稿的最小工作流

推荐按下面这个顺序操作，每一步都有明确目标：

1. 使用模板插件，把template-项目复盘会议.md插入新笔记。目标是生成一份带变量替换结果的草稿。
2. 确认 frontmatter 里的title和date已经被替换，而不是保留{{title}}。
3. 手动补充已知信息，比如会议时间、参会人。即使 AI 能补，也先把事实性内容写清楚，减少 AI 编造空间。
4. 把新笔记内容连同规则文件、示例文件一起提供给 AI。提示词可以写成：

请根据规则文件 rule-项目复盘会议.md 和示例文件 sample-项目复盘会议.md，补全下面的会议纪要内容。不要修改表格列名，不要删除分区，状态字段只允许使用规则文件中的枚举值。

5. 生成后，照着规则文件末尾的“校验清单”逐项检查。

注意，不是所有 AI 插件都支持跨文件引用规则文件。如果插件不支持，可以在提示词里直接粘贴规则文件的正文内容。规则文件本身是 Markdown，复制成本很低。

6.2 验证模板是否被 AI 看懂

验证分为三层：

结构验证：看 AI 输出是否保留了模板里所有 H2 分区。缺少任何一个分区，说明 AI 可能没有正确读取模板结构，或者规则文件被忽略。

字段验证：逐项检查 frontmatter 的字段是否合法，尤其是type是否被改、status是否在枚举内、attendees是否用列表格式。

内容验证：看表格里是否有明显编造内容。比如把示例文件中的“张明”带到了新笔记里，说明示例文件被过度模仿，规则文件中“不要编造参会人姓名”的约束没有生效。

如果结构验证通过但内容验证不通过，优先调整规则文件，而不是模板文件。规则文件里把“不要将示例文件中的具体人名带入新笔记”作为一条独立规则，比在提示词里反复强调更有效。

6.3 用 Dataview 验证结构一致性

当一批笔记都按同一模板生成后，可以用 Dataview 查询验证。假设笔记存放在meetings文件夹下：

TABLE date, status, attendees FROM "meetings" WHERE type = "meeting-minutes" SORT date DESC

如果这条查询能返回完整的日期、状态、参会人列表，说明 frontmatter 字段被正确解析，模板设计是成功的。如果返回为空或字段缺失，重点检查 frontmatter 格式、字段名拼写、文件路径。

Dataview 对 frontmatter 的解析要求比较严格：字段名大小写必须一致，列表项缩进要正确。这也是模板里使用固定字段名的原因。

7. 常见问题与排查路径

7.1 模板变量没有被替换

现象：插入模板后，笔记里仍然显示{{title}}或<% tp.file.title %>。

原因排查顺序：

1. 是否启用了核心模板插件，或 Templater 插件。
2. 插入方式是否正确。核心模板插件的插入入口是命令“模板：插入模板”，不是新建笔记时自动加载。
3. 是否混用了两套变量语法。核心模板插件不会解析 Templater 的<% %>。
4. 是否在模板文件夹里放入了无关文件，干扰了插件识别。

解决方案是统一变量语法。如果确定用核心模板插件，把<% ... %>全部改成{{...}}；如果确定用 Templater，在规则文件里补充变量说明。

7.2 AI 生成了模板结构，但内容偏离字段语义

现象：表格列名还在，但“状态”列填了“已完成”；“优先级”列填了“高优先级”而不是“高”。

原因：规则文件里的枚举值没有真正被 AI 采纳，或者 AI 没有读取规则文件就生成了内容。

检查方式：在提示词中明确要求“状态字段只能填写规则文件中的枚举值之一”，并给 AI 一个更短的状态范围。例如：

状态字段只允许：待办、进行中、已完成、已取消。请从这四个值中选择。

如果问题仍然出现，把规则文件内容直接粘贴到提示词中，而不是依赖插件自动引用。

7.3 frontmatter 解析失败或属性丢失

现象：笔记界面没有显示属性面板，或者 Dataview 查询不到字段。

常见原因：

• frontmatter 必须位于文件第一行，前面不能有空行或文字。
• 字段值如果是字符串，不要漏掉引号，尤其是包含中文或特殊字符时。
• attendees列表项缩进要统一，不要在-前混用空格和 Tab。

7.4 规则文件太长，AI 忽略或截断

现象：规则文件里写了步骤、示例、禁止行为，但 AI 只执行了第一条或前几条。

原因：规则文件信息密度低，或超出了模型上下文窗口。

解决思路：

• 把规则压缩成表格和短句，删除解释性长句。
• 最重要的规则放前面。AI 对上下文开头的关注度通常更高。
• 超过 30 行的规则文件拆成两个文件：一个必读规则，一个参考手册。AI 生成时只读必读规则。

注意：规则文件的优先级高于模板和示例。在规则文件开头写清“规则文件优先级最高”，并要求 AI 生成前先读取规则，能显著降低违规概率。

8. 最佳实践与扩展方向

8.1 设计模板的三条硬原则

第一条，字段名要自解释。date、status、attendees这类通用英文词比时间、进度、人员更容易让 AI 理解，也与 Obsidian 生态的字段命名习惯一致。

第二条，状态字段必须给枚举值。凡是可能出现“待办、进行中、已完成”这类取值的字段，一律在规则文件里写明枚举范围。这是控制 AI 输出格式最有效的手段。

第三条，示例文件必须和模板结构一一对应。模板有几张表，示例就要有一样的表；模板有几级标题，示例就要有一样的标题。结构不一致会诱导 AI 修改模板。

8.2 从单模板到模板家族的扩展

会议纪要只是一个起点。同一套方法论可以扩展到项目建档、文献笔记、客户记录、任务复盘等场景。

每增加一个场景，就新建一组三件套：

_templates/ ├── template-项目复盘会议.md ├── template-需求评审.md ├── template-文献阅读.md ├── samples/ │ ├── sample-项目复盘会议.md │ ├── sample-需求评审.md │ └── sample-文献阅读.md └── rules/ ├── rule-项目复盘会议.md ├── rule-需求评审.md └── rule-文献阅读.md

模板变多之后，建议写一个“索引文件”，列出所有模板的三件套位置和适用场景。这个索引文件同样可以给 AI 看，让它根据任务类型自动选择模板。索引文件的开头可以写成：

# 模板索引 当用户需要生成会议纪要时，使用 template-项目复盘会议.md，并读取 rule-项目复盘会议.md。 当用户需要记录文献时，使用 template-文献阅读.md，并读取 rule-文献阅读.md。

8.3 结合 Templater 和 AI 插件的进阶用法

对已经熟悉 Templater 的用户，可以进一步把模板过程自动化：

• 用 Templater 根据当前日期自动生成会议纪要文件名和存储目录。
• 用 Templater 读取当前打开的笔记，自动把相关链接写入参会人字段。
• 用 AI 插件生成初稿后，再用 Templater 的清理脚本删除空行和冗余内容。

但务必要保证自动化过程不破坏三份文件的定位。Templater 负责“生成笔记的壳”，AI 负责“填充内容”，规则文件负责“约束 AI 的输出边界”。壳、内容、约束三件事分开管理，模板系统才可维护。

最后一个建议：像维护代码一样维护模板。每次用 AI 生成后，如果发现它反复违反某条规则，就把这条规则写得更具体，并同步更新示例文件。模板三件套是活文档，不是一次性搭建完就固定不变。实际使用一两周后，再回头看最初的模板，通常会发现字段命名、枚举值、表格列名都值得再优化一轮。这个迭代过程，才是“AI 能一眼看懂”的真正保障。