企业官网建设流程全解析

“书不尽言，言不尽意。然则圣人之意，其不可见乎？”——《周易·系辞上》

AI 能读懂笔记的文字，却未必能稳定识别它属于什么类型、现在用于什么工作，以及应与哪些内容一起读取。要减少这种误解，知识库需要让笔记的类型、位置和使用语境逐步变得可读取。

系列导读

这是六篇《让知识自由生长》系列的第二篇，聚焦可信上下文与机器可读基础这一步。它承接上一篇对知识来源、证据、知识记录、提炼认知与治理规则的区分，不再展开解释，而是讨论怎样让这些信息在日常笔记中可被看见、检索和读取。

本文的判断是，**AI 不能仅凭文字推断你的意图。**机器可读的结构是后续关系网络和可复用 AI 工作流的第一层基础。它不是把每篇笔记写成数据库，而是让人和工具都少猜一次：目录、元数据、模板和说明足够稳定时，Markdown 既保持可读，也能被检索、筛选、关联和更新。系统可以组织、呈现和检查这些信息，人仍须评估证据并作出决策。

机器可读的第一步是上下文可稳定读取

AI 能获得什么上下文，取决于知识库中信息的质量。格式自由、命名不一致、缺少元数据和链接约定的知识库，会增加定位语境的成本，也更容易产生不一致或不可靠的输出。

机器可读的目标不是让工具替人解释内容，而是先让笔记的类型、位置、结构与使用规则可以被一致地读取。内容很少时，自由格式完全够用，先记下来比先分类更重要。只有当内容需要反复查找、比较、维护或交给工具处理时，结构才值得逐步补上。其中，首先需要稳定的是笔记的位置。

PARA 用位置说明内容当前的用途

要决定一篇笔记当前如何使用，先要区分它属于正在推进的项目、持续维护的领域、参考资料还是提炼出的技巧，并确认它是否已经归档。要让工具也能读取这层信息，需要用明确、可读取的约定标明位置。PARA 按内容的用途和状态组织内容，文件夹只是这种约定在磁盘上的表现，不是唯一正确答案。

下面是 PARA 在 Obsidian 中的一种文件夹结构参考：

My-Knowledge-Base/ ├── Projects/# 有目标和截止日期的活跃任务├── Areas/# 持续维护的知识领域│ ├── Technologies/ │ ├── Patterns/ │ └── Processes/ ├── Resources/# 参考资料│ ├── Articles/ │ └── Docs/ ├── Techniques/# 提炼出的可行动知识│ ├── AI&ML/ │ └── Architecture/ ├── Archive/# 已完成或不再活跃的内容│ ├── Areas/ │ ├── Projects/ │ ├── Resources/ │ └── Techniques/ ├── Journal/# 日志原始笔记│ ├── Weekly/ │ ├── Monthly/ │ └── Meetings/ ├── People/# 你的联系人网络├── _Templates/# 笔记模板├── _Attachments/# 图片和文件├── Knowledge.base# 统一的 PARA 索引├── Projects.base# 项目跟踪├── Techniques.base# Techniques 索引├── Journal.base# 日志条目索引├── People.base# People 索引└── README.md # 系统说明`

当文件夹开始变多，问题就从“放哪里”变成“怎么不迷路”。以下约定用于保持知识库的可导航性：

• Areas 的子文件夹按领域设置：可按Technologies/、Patterns/和Processes/等类别组织。PARA 不强制要求子分类，但持续跟踪的领域较多时，子目录能降低导航成本。
• Archive 镜像 PARA 结构：Project 完成或 Area 不再活跃时，可原样移入Archive。归档笔记应保留其 wikilinks 和反向链接。内容没有被删除，只是退出活跃工作范围。
• Journal 与 PARA 分开：日志条目是按时间记录的原始素材，包括会议、反思、一对一沟通和职业评估。这些素材可作为项目、领域与技巧的输入材料，但不应与稳定的 PARA 内容混在同一分类逻辑中。
• 以下划线开头的文件夹应在视觉上与知识内容区分开：_Templates和_Attachments支撑系统，但它们本身并不是知识。这个约定既能在 Obsidian 中直观地区分它们，也便于在检索知识时排除它们。

这些规则解决的是内容增长后如何保持可导航，而不是为分类本身增加层级。在 PARA 中，内容所在的位置表示其当前用途和状态，而不是主题。

模板规定人和 AI 共用的结构规则

笔记所在的位置能说明它当前的用途和状态，却不足以让人和工具按同一规则读取、比较和补充同类笔记。**反复使用的同类笔记需要一份稳定骨架。**模板提前说明这一类笔记通常应写明什么，于是人和工具能在同一位置阅读和写入。

模板减少反复决定笔记结构的成本，从而把注意力留给内容。它固定字段和章节的位置，却不要求每篇笔记得出同一个结论。因此，需要保持一致结构的笔记类型，应使用相应模板。

以下是 Area 笔记参考模板：

-- acronym: tags: - Area last updated: ---## Overview>[!info]这个领域是什么，为什么重要？>用2-3 句话说明这个知识领域。 -...## Key Concepts>[!tip]需要了解哪些核心内容？>列出理解这一领域所需的核心要点。 -...## Techniques>[!note]适用于这个领域的提炼知识>所有链接到此 Area 的 Technique 会自动填入>此表。## Resources>[!note]支持这个领域的参考资料>所有链接到此 Area 的 Resource 会自动填入>此表。## See Also>[!tip]相关链接

模板各部分的职责要清楚，才能保持结构一致。

Frontmatter 把类型和状态写成可查询属性

模板规定章节位置，YAML frontmatter 则写明机器无法从正文稳定推断的类型和状态。正文展开观点，属性为查询、排序和筛选提供条件，让 Markdown 成为可查询的数据。

这种分工的前提是字段少而稳定。属性中应写明“笔记属于什么类型、何时更新、可按什么条件找到”等信息，读者就不用在长段落里翻基础信息。模板已经固定了位置，接下来还需要让工具能按类型和状态直接读取这些信息。

--- acronym: MCP tags: - Area - AI-ML - GenAI last updated:2026-03-31T14:53:00 ---

tags标记内容与预期用途，因此 AI Agent 可以按标签筛选笔记，例如：找出所有标记为 AI-ML 的 Techniques。可用date按日期筛选会议笔记，last updated则记录最后更新时间，并可为复查提供线索。

问题不在于字段不够多，而在于字段是否对应查询和复查的需要。因此，只保留服务于查询、排序、审阅或工作流的属性，并要求同类笔记保持一致。批量筛选、定期复查或交给工具处理时，这层结构尤其有用。

tags、date和last updated分别标记内容及预期用途、日期和最后更新时间，但字段仍不能说明正文每个章节的职责。

Callout 说明每一段的用途

即使读者看得懂标题，对“这一节该写什么”仍可能作出不同理解，工具也无法仅凭标题可靠识别预期的内容类型。> [!info]、> [!tip]和> [!note]是 Obsidian callouts，会显示成更醒目的区块。它们可作为带用途标签的提示框，直接写在容易误解的位置。

这样做的机制很简单：新笔记从模板创建时，callout 说明本节容纳什么内容，系统可据此定位应处理的位置，并识别内容类型。提示只需在章节用途需要明确说明时使用。

同类模板应保留可预期的模式

单篇笔记的章节用途明确后，同类笔记仍需要可预期的共同模式。否则，笔记不断增加后，同一类型的笔记会逐渐出现不一致的格式。为避免这种割裂，同一类型内部应保持可预期的模式，下面是可采用的九种模板：

• Project有目标的活跃工作priority,date_from,date_to,tags: [Project],last_updated
• Area知识领域acronym,tags: [Area],last_updated
• Resource参考资料source,tags: [Resource],last_updated
• Technique提炼后的可行动知识tags: [Technique],last_updated
• Person同事或人物档案team,role,tags: [People, {Country}]
• Meeting记录与他人的会议笔记date,tags: [Journal, Meeting]
• Weekly每周复盘date_from,date_to,tags: [Journal, Weekly]
• Monthly月度回顾date_from,date_to,tags: [Journal, Monthly]
• Appraisal职业评估date,tags: [Journal, Appraisal]

这种模式让读者能够预期同类笔记的结构和字段，工具也能按同一套规则定位相应内容。其中，Frontmatter 为搜索和筛选提供入口，字段、章节和内容边界共同减少歧义。

“每种模板，一个模式”不等于九种模板必须一模一样。同一类型要可预期，不同类型则应保留真正需要的字段。

Obsidian Bases让索引随内容自动更新

类型和状态明确后，结构化笔记仍需要持续汇总。内容继续增长时，静态目录会过时，手动索引也会把维护变成重复劳动。动态索引按条件生成清单，只显示当前符合条件的文件，不复制笔记内容。

需要这类动态索引时，Obsidian Bases 可用于承担这件事。扩展名为.base的文件是动态查询视图，其内容由对知识库的查询生成，而不是再维护一份静态列表。

需要在不同角度反复汇总内容时，根目录可设置五个 base 文件：

• Knowledge：跨越所有 PARA 笔记的统一视图。
• Projects：所有活跃项目的专用视图，包含优先级和日期。
• Techniques：所有提炼后的分析、操作指南和技术指南，并链接到 areas 与 resources。
• Journal：将所有会议笔记集中显示，并按最新程度排序。
• People：需要持续维护联系的人物档案列表。

以下是 Knowledge base 的参考内容：

filters: or: - file.inFolder("Projects")- file.inFolder("Areas")- file.inFolder("Resources")- file.inFolder("Archive")formulas: Type:>- if(tags.contains("Project"),"Project", if(tags.contains("Area"),"Area", if(tags.contains("Resource"),"Resource","Archive")))views: - type: table name: All order: - file.name - formula.Type - tags sort: - property: file.name direction: ASC

该配置创建覆盖 PARA 笔记的实时索引表。创建或更新 PARA 笔记后，列表自动更新，无需手动维护。

除了汇总全库，Base 还可用于单个主题页。当某个 Area 笔记需要展示关联资料，而又不想反复手填清单时，可直接嵌入 Base，让 Area 笔记显示链接到它的 Resources 或 Techniques。

filters: and: - file.inFolder("Techniques")views: - type: table name: Techniques filters: and: - file.hasLink(this.file)

嵌入笔记时，file.hasLink(this.file)是关键。它让系统筛选直接链接到当前笔记的文件。

这表明了显式写下的直接链接如何成为查询条件，以及 Base 如何在索引中呈现符合条件的笔记。它不生成链接，也不改变既有链接所表达的意义。Base 只会呈现已有的字段、路径和链接。

Area 笔记嵌入筛选条件后，所有直接链接到它的 Technique 都会进入表格。新增一篇 Technique 并补上直接 wikilink，表格随之更新，不需要再回到 Area 页面手动补一行。因此，更新后的表格只是呈现已有关系。

README 让人和工具先看见系统规则

索引能汇总既有笔记，但首次进入知识库的人或工具仍缺少整个系统的上下文。README 是系统的起点说明。它不收录全部内容，只写明系统如何组织、信息从哪里来，以及应按什么规则放置和读取。

以下是一份 README 示例：

这个知识库是我用于处理业务相关内容的 **Second Brain**。 它采用两套互补框架： - **CODE** 定义*工作流*，说明信息如何流动 - **PARA** 定义*结构*，说明信息存放位置 ---## CODE — 工作流### C — Capture记录能引发共鸣的洞察、想法和信息。 **在这个知识库中：** →`Journal/`### O — Organize根据*可行动性*，使用 PARA 整理已捕捉的信息。 **在这个知识库中：** → PARA 文件夹结构### D — Distill提炼已捕捉信息中的关键要点。 **在这个知识库中：** →`Techniques/`### E — Express将提炼出的洞察转化为有价值的成果。 **在这个知识库中：** → 从 Techniques 链接出的成果 ---## PARA — 结构|文件夹|用途||-------------|-------------------------------------------||`Projects/`|有目标和截止日期的活跃任务||`Areas/`|持续维护的知识领域||`Resources/`|用于学习的非行动性内容||`Techniques/`|提炼出的知识（Distill ↔ Express）||`Archive/`|已完成或不再活跃的内容|

对人来说，README 是理解系统架构时首先阅读的内容，也是组织方式与信息流的速查指南。工具则按其中写明的规则读取和处理内容。

README 无须证明系统多么完整，只需写明入口规则、目录含义和信息流；细节可以链接到模板或说明。

具体来说，README 写明 CODE 的 Capture、Organize、Distill、Express 流程，以及 PARA 的存放规则，使人能够理解这些阶段和结构，工具能够按明确规则读取内容。README 因而补充单篇笔记之外的使用语境和操作边界。

机器可读也有设计取舍

机器可读不仅取决于字段和索引，还取决于三项设计决策：选用的文件格式是否便于迁移，变化是否能够追溯，以及哪些需要反复使用的笔记适合采用模板。这三项决策分别影响内容能否跨工具读取、变更能否复查，以及结构何时值得固定。

Markdown 让结构和内容一起可见

格式选择要解决的是，内容离开某个应用后是否仍可读取和比较。Markdown 很适合需要版本比较、跨工具处理、长期保存或交给 AI 阅读的知识库。它是纯文本，因此工具无需解析专有格式即可读取、写入和比较差异，也能识别标题、列表、链接、代码块和 frontmatter 等常见结构。

“纯文本”意味着可用普通文本工具直接打开和处理，重点在可见性和可迁移性。富文本常把结构嵌在需要额外解析的格式中，Markdown 则直接把结构呈现为文本。不过，纯文本并不天然更高级，格式仍应服从使用方式。

Git 与云同步各记录什么

同步和版本控制常被当成同一件事，实际解决的却是不同问题。云同步让同一份文件出现在多台设备上，Git 则记录文件在何时发生了哪些文本变化；变化原因只有写入提交信息后才可追溯。两者可配合但不能互相替代：前者保证副本可用，后者让变更可审查。

Git 通过提交保存可追踪、可恢复的变更历史，便于审查差异、回滚和追溯内容演进。云盘有时也保留历史，但它并非为以可审查的方式记录内容演进而设计。需要审查差异、恢复版本或追溯内容演进时，Git 很有帮助。

模板与自由记录各自适合什么

这里的取舍要解决的是，既想快速捕捉，又不想让后续查询全靠猜。自由格式不预设字段和章节，适合尚未成形的想法。模板为同类内容保留稳定骨架，适合会被再次查找、比较或处理的内容。两者不是敌对关系。

模板会带来少量初始填写负担，但不使用模板造成的格式差异会随着笔记增多而放大，最后让人更难导航，也让工具更难定位内容。模板适用于稳定、重复且有后续用途的笔记类型。

机器可读只是基础，关系网络仍待建立

到这里，知识库已经具备机器可读的基础，人和AI可以稳定读取笔记的类型、位置和结构，但还没有形成可穿行的关系网络。现在已有：

• 用于按内容的当前位置组织内容的 PARA 文件夹结构。
• 带有 frontmatter 的笔记模板，用于让同类笔记保持可预期的结构。
• 提供动态索引的 Base 文件。
• 供人和工具查阅系统规则的 README。
• 让知识库保持机器可读的设计原则，包括选择 Markdown、区分 Git 与云同步的职责，以及划定模板与自由记录的边界。

这套基础即使没有 AI 也有用，它让知识记录更容易被定位、比较和维护。

至此，《让知识自由生长》六篇系列的第 2 步完成：让知识库的上下文能够被稳定读取。

1. 知识存储的越来越多，为什么每次使用还要从头开始
2. AI读懂了文字，为什么还是会误解你的意图（本文）
3. 当笔记彼此照亮，知识才真正开始生长
4. 走过的路，怎样变成下一次出发的方法
5. 当AI开始整理知识，最后的决策由谁作出
6. 方法可以借鉴，知识系统要从自己的生活里生长

下一篇

《当笔记彼此照亮，知识才真正开始生长》将说明 wikilinks、backlinks 与查询如何在这层可读基础上建立可穿行的知识网络。