知识管理02：AI读懂了文字，为什么还是会误解你的意图

“书不尽言言不尽意。然则圣人之意其不可见乎”——《周易·系辞上》AI 能读懂笔记的文字却未必能稳定识别它属于什么类型、现在用于什么工作以及应与哪些内容一起读取。要减少这种误解知识库需要让笔记的类型、位置和使用语境逐步变得可读取。系列导读这是六篇《让知识自由生长》系列的第二篇聚焦可信上下文与机器可读基础这一步。它承接上一篇对知识来源、证据、知识记录、提炼认知与治理规则的区分不再展开解释而是讨论怎样让这些信息在日常笔记中可被看见、检索和读取。本文的判断是**AI 不能仅凭文字推断你的意图。**机器可读的结构是后续关系网络和可复用 AI 工作流的第一层基础。它不是把每篇笔记写成数据库而是让人和工具都少猜一次目录、元数据、模板和说明足够稳定时Markdown 既保持可读也能被检索、筛选、关联和更新。系统可以组织、呈现和检查这些信息人仍须评估证据并作出决策。机器可读的第一步是上下文可稳定读取AI 能获得什么上下文取决于知识库中信息的质量。格式自由、命名不一致、缺少元数据和链接约定的知识库会增加定位语境的成本也更容易产生不一致或不可靠的输出。机器可读的目标不是让工具替人解释内容而是先让笔记的类型、位置、结构与使用规则可以被一致地读取。内容很少时自由格式完全够用先记下来比先分类更重要。只有当内容需要反复查找、比较、维护或交给工具处理时结构才值得逐步补上。其中首先需要稳定的是笔记的位置。PARA 用位置说明内容当前的用途要决定一篇笔记当前如何使用先要区分它属于正在推进的项目、持续维护的领域、参考资料还是提炼出的技巧并确认它是否已经归档。要让工具也能读取这层信息需要用明确、可读取的约定标明位置。PARA 按内容的用途和状态组织内容文件夹只是这种约定在磁盘上的表现不是唯一正确答案。下面是 PARA 在 Obsidian 中的一种文件夹结构参考My-Knowledge-Base/ ├── Projects/# 有目标和截止日期的活跃任务├── Areas/# 持续维护的知识领域│ ├── Technologies/ │ ├── Patterns/ │ └── Processes/ ├── Resources/# 参考资料│ ├── Articles/ │ └── Docs/ ├── Techniques/# 提炼出的可行动知识│ ├── AIML/ │ └── 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_updatedArea知识领域acronym,tags: [Area],last_updatedResource参考资料source,tags: [Resource],last_updatedTechnique提炼后的可行动知识tags: [Technique],last_updatedPerson同事或人物档案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 步完成让知识库的上下文能够被稳定读取。知识存储的越来越多为什么每次使用还要从头开始AI读懂了文字为什么还是会误解你的意图本文当笔记彼此照亮知识才真正开始生长走过的路怎样变成下一次出发的方法当AI开始整理知识最后的决策由谁作出方法可以借鉴知识系统要从自己的生活里生长下一篇《当笔记彼此照亮知识才真正开始生长》将说明 wikilinks、backlinks 与查询如何在这层可读基础上建立可穿行的知识网络。