Obsidian模板如何让AI看懂？三文件设计法

在 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 容易打乱章节顺序语义层每个字段代表什么可以填什么值哪些必填大多不覆盖AI 自由发挥字段值混乱约束层哪些内容不能改风格怎么控制生成后怎么自检完全不覆盖AI 删除分区、改列名、加无关内容结构层可以用一个模板文件解决语义层和约束层则需要额外文件承载。这也是为什么“三份文件”比“一份文件”更可靠。一份模板文件适合人使用因为人擅长从留白中补全信息。但 AI 更适合“结构模板 填充示例 规则约束”的组合模板告诉它长什么样示例告诉它怎么填规则告诉它边界在哪里。2. 三份文件的分工模板文件、示例文件、规则文件2.1 三份文件分别解决什么问题三份文件的角色不是随意划分的而是对应 AI 理解和生成内容的三个关键环节文件建议文件名角色给谁看核心内容丢失后影响模板文件template-项目复盘会议.md骨架人和 AIMarkdown 结构、表格、frontmatter、变量AI 不知道生成什么结构示例文件sample-项目复盘会议.md标准答案人和 AI一份填写完毕的完整笔记AI 只能猜测字段格式规则文件rule-项目复盘会议.md约束主要是 AI字段说明、枚举值、禁止行为、校验清单AI 无法控制生成质量模板文件是最先想到的但示例文件的作用经常被低估。对 AI 来说一个字段的取值规则用文字描述十句不如一个真实填写示例来得直接。示例文件本质上就是 few-shot promptAI 读完示例后会模仿示例的措辞、格式、链接风格而不是自己发明一套。规则文件则负责“踩刹车”。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。核心模板插件支持几个简单变量变量插入时替换结果{{title}}新笔记文件名{{date}}当前日期格式可在设置中指定如YYYY-MM-DD{{time}}当前时间格式如HH:mm这套变量足够覆盖大多数模板。它们的优点是简单稳定缺点是表达能力有限不能做条件判断、循环、文件名截断等逻辑。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 补全Obsidian 核心模板插件 一款 AI 插件模板、示例、规则三份文件全部放入 vault自动化较强Obsidian Templater AI 插件用 Templater 控制生成路径和文件名AI 负责内容填充结构化查询增加 Dataview 或 Properties 搜索依赖 frontmatter 字段规范模板设计时就要想好最低组合其实只需要 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 的 frontmatterYAML 属性区不仅是人类查看属性的工具也是 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 ---字段名本身也要自解释。如果字段叫attAI 不知道是“参会人”还是“附件”。直接写attendees多几个字符的成本远低于 AI 猜错后的修正成本。5.2 用 HTML 注释给 AI 隐形指令模板文件里可以嵌入!-- ... --注释AI 读取时能看到内容而 Obsidian 界面渲染时不会显示。这非常适合给 AI 传指令。例如模板开头!-- AI:System 这是会议纪要模板。请保留所有 H2 结构和表格列名只填充和补全内容不要删除任何分区。 --使用注释时要注意注释只是提示不是绝对约束。如果规则文件里已经明确“不要删除分区”注释里可以只做简短提醒避免重复指令占空间。注释内容应保持短句一段话超过 50 个字AI 的注意力会分散。不要用 Markdown 的普通文本写这类指令。如果写成这是会议纪要模板。请保留所有 H2 结构和表格列名只填充和补全内容。这段文字会被渲染成正文人看到困惑AI 也可能把它当成正文内容的一部分。HTML 注释是更安全的选择。5.3 模板变量语法要统一不要混用Obsidian 有至少两套模板变量体系它们的语法不兼容体系示例用途核心模板插件{{title}}{{date}}变量替换简单稳定Templater% tp.file.title %% tp.date.now(YYYY-MM-DD) %条件逻辑、调用 API如果在同一个模板里混用这两套语法核心模板插件插入时会把% ... %当作普通文本输出Templater 则会把{{date}}原样保留。最终生成的笔记里会出现大量未解析的占位符。在面向 AI 的模板里推荐两个做法做法一只用核心模板插件变量把% ... %全部移出模板。适合大多数场景。做法二如果已经用了 Templater则不要在模板文件里混入核心插件变量并额外在规则文件里写清楚## 变量说明 - % tp.file.title % 会被替换为当前笔记文件名 - % tp.date.now(YYYY-MM-DD) % 会被替换为当前日期 - 请不要在生成内容中保留这些变量原样另外要留意变量被替换后如果 AI 看到的还是% ... %或{{date}}说明模板插入流程没有执行成功。这种情况不要直接喂给 AI先解决变量替换问题否则 AI 会把占位符当正文。6. 让 AI 真正用起来最小工作流与验证方法6.1 从模板到成稿的最小工作流推荐按下面这个顺序操作每一步都有明确目标使用模板插件把template-项目复盘会议.md插入新笔记。目标是生成一份带变量替换结果的草稿。确认 frontmatter 里的title和date已经被替换而不是保留{{title}}。手动补充已知信息比如会议时间、参会人。即使 AI 能补也先把事实性内容写清楚减少 AI 编造空间。把新笔记内容连同规则文件、示例文件一起提供给 AI。提示词可以写成请根据规则文件 rule-项目复盘会议.md 和示例文件 sample-项目复盘会议.md补全下面的会议纪要内容。不要修改表格列名不要删除分区状态字段只允许使用规则文件中的枚举值。生成后照着规则文件末尾的“校验清单”逐项检查。注意不是所有 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 %。原因排查顺序是否启用了核心模板插件或 Templater 插件。插入方式是否正确。核心模板插件的插入入口是命令“模板插入模板”不是新建笔记时自动加载。是否混用了两套变量语法。核心模板插件不会解析 Templater 的% %。是否在模板文件夹里放入了无关文件干扰了插件识别。解决方案是统一变量语法。如果确定用核心模板插件把% ... %全部改成{{...}}如果确定用 Templater在规则文件里补充变量说明。7.2 AI 生成了模板结构但内容偏离字段语义现象表格列名还在但“状态”列填了“已完成”“优先级”列填了“高优先级”而不是“高”。原因规则文件里的枚举值没有真正被 AI 采纳或者 AI 没有读取规则文件就生成了内容。检查方式在提示词中明确要求“状态字段只能填写规则文件中的枚举值之一”并给 AI 一个更短的状态范围。例如状态字段只允许待办、进行中、已完成、已取消。请从这四个值中选择。如果问题仍然出现把规则文件内容直接粘贴到提示词中而不是依赖插件自动引用。7.3 frontmatter 解析失败或属性丢失现象笔记界面没有显示属性面板或者 Dataview 查询不到字段。常见原因frontmatter 必须位于文件第一行前面不能有空行或文字。字段值如果是字符串不要漏掉引号尤其是包含中文或特殊字符时。attendees列表项缩进要统一不要在-前混用空格和 Tab。问题现象常见原因检查方式处理建议属性不显示frontmatter 前面有空行源码模式查看文件头部删除前面空行和多余内容类型解析错误日期写成2025/3/10查看属性面板类型统一改为2025-03-10list 属性变成字符串列表项没有缩进源码模式查看 YAML 缩进按 YAML 列表规则缩进字段缺失模板里字段名拼写不一致检查模板文件和生成的笔记统一字段名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 能一眼看懂”的真正保障。