Tolaria 动态 Wikilink 关系检测零配置的笔记关系图谱实现解析ADR-0010【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolaria本文围绕 docs/adr/0010-dynamic-wikilink-relationship-detection.md 展开深入剖析 Tolaria原 Laputa如何通过扫描 frontmatter 中所有含[[wikilink]]的字段来自动识别笔记间任意类型的关系从而免去硬编码关系字段列表的维护成本。读完本文你将掌握这套约定优于配置的关系检测机制的完整工作原理、源码级实现细节、真实 vault 中的配置写法以及误报边界与规避策略。Tolaria 是一款以本地 Markdown 知识库为核心的桌面应用。在其早期设计ADR-00102026-03-08中团队面临一个典型问题笔记之间的关系类型如Topics:、Key People:、Depends on:是开放且不断演进的硬编码的关系字段白名单让新增一种关系变成一次代码改动。本文记录了他们最终选择的方案——动态关系检测即解析器扫描全部 frontmatter 键凡是值中包含[[wikilink]]的字段一律视为关系字段。该机制至今仍构成 Tolaria 关系图谱、Inspector 关系面板与 Neighborhood 模式的基础。背景与动机为什么硬编码关系字段不可持续在引入动态检测之前Tolaria 使用一份硬编码列表RELATIONSHIP_KEYS来判定哪些 frontmatter 字段属于关系。这套方案的痛点非常直观新增关系类型 改代码用户想用Depends on:或Sponsors:这类自定义关系时必须等待一次代码发布用户无法自洽知识库的领域语义千差万别项目管理、个人笔记、研究文献……应用不可能预知所有关系名称列表漂移硬编码列表与真实数据脱节后容易出现字段明明写了却不算关系的认知偏差。从仓库现状可以印证这一演进方向今天的VaultEntry结构体在 src-tauri/src/vault/entry.rs 中为关系字段保留了通用入口/// Generic relationship fields: any frontmatter key whose value contains wikilinks. /// Key is the original frontmatter field name (e.g. Has, Topics, Events). pub relationships: HashMapString, VecString,这段注释直接复述了 ADR 的核心决策关系的判定标准不再是这个字段叫什么而是这个字段的值里有没有 wikilink。核心决策以[[wikilink]]存在性为唯一判据ADR-0010 的决策原文如下The Rust parser dynamically detects relationship fields by scanning all frontmatter keys for values containing[[wikilinks]]. Any field with wikilink values is captured in therelationshipsHashMap — no hardcoded field name list needed.翻译成实现语言解析 Markdown 文件时先通过gray_matter解析 YAML frontmatter再遍历其中每一个键值对只要值字符串、字符串数组乃至嵌套结构里含有[[与]]包裹的 wikilink就把该字段连同其 wikilink 值写入relationships映射。源码级实现extract_relationships关系提取的入口位于 src-tauri/src/vault/frontmatter.rs/// Extract all wikilink-containing fields from raw YAML frontmatter. pub(crate) fn extract_relationships( data: HashMapString, serde_json::Value, ) - HashMapString, VecString { let mut relationships HashMap::new(); for (key, value) in data { if FrontmatterKey::new(key).is_reserved() { continue; } let wikilinks relationship_wikilinks(value); if !wikilinks.is_empty() { relationships.insert(key.clone(), wikilinks); } } relationships }关键逻辑只有三步跳过保留字段is_reserved()防止结构性元数据如type、aliases、Status等被误判为关系递归提取 wikilinkrelationship_wikilinks对值做深度遍历非空即收录只要某字段提取出至少一个 wikilink就以原始字段名为键写入relationships。值得注意字段名原样保留包括大小写与空格因此Topics:、Key People:、Has:这些人类可读的字段名会直接成为关系键配合前端的 humanize 逻辑在界面上友好展示。wikilink 判定与递归收集值是否含 wikilink由 src-tauri/src/vault/parsing.rs 中的contains_wikilink判定/// Check if a string contains a wikilink pattern [[...]]. pub(super) fn contains_wikilink(s: str) - bool { s.contains([[) s.contains(]]) }而collect_relationship_wikilinkssrc-tauri/src/vault/frontmatter.rs负责递归收集fn collect_relationship_wikilinks( value: serde_json::Value, depth: usize, wikilinks: mut VecString, ) { match value { serde_json::Value::String(s) if contains_wikilink(s) wikilinks.push(s.clone()), serde_json::Value::Array(arr) { if let Some(link) nested_flow_wikilink(arr, depth) { wikilinks.push(link); return; } for item in arr { collect_relationship_wikilinks(item, depth 1, wikilinks); } } _ {} } }它覆盖了三种值形态单字符串Owner: [[person/luca-rossi|Luca Rossi]]→ 收集 1 条字符串数组Topics: [[[topic/rust]], [[topic/wasm]]]→ 逐项收集嵌套 flow 数组YAML 解析出的嵌套数组如[[person/alice]]的 flow 表示通过nested_flow_wikilink还原为[[person/alice]]形式depth 0时单元素非 wikilink 数组被包装成 wikilink。同时extract_properties同一文件的 frontmatter.rs与关系提取互为镜像含 wikilink 的值进入relationships不含 wikilink 的标量/标量数组进入properties。两类数据互斥不会重复归属。保留字段名单is_reservedsrc-tauri/src/frontmatter/keys.rs 定义了保留字段的判定pub(crate) fn is_reserved(self) - bool { self.normalized().starts_with(_) || is_known_frontmatter_key(self) }即两类字段不会被视为关系下划线前缀规范化后_archived、_icon、_order、_sort、_favorite等系统字段已知 frontmatter 键KNOWN_FRONTMATTER_KEYS表同文件 keys.rstitle、type/is_a/Is A、aliases、Status、color、template、visible、view等。关系键测试 relationship_key_tests.rs 对此有明确断言Is A、Aliases、Status即使值是[[...]]也不会进入relationships而Cadence、Created at、Real Relation这类自定义键则正常收录。方案权衡动态检测 vs 硬编码 vs 用户配置ADR 记录了三个候选方案及其取舍方案思路优点缺点A采用依据[[wikilink]]存在性动态检测零配置、可扩展、任意字段名皆可用含字面[[...]]内容的字段可能误报由双括号语法缓解B硬编码RELATIONSHIP_KEYS列表简单、可预测不灵活新增关系类型需改代码C在 vault 配置中声明关系字段列表灵活增加配置负担开箱不可用最终选择方案 A理由是它把新增关系的成本降到了零用户不需要了解任何配置项只需在 frontmatter 里写下[[wikilink]]。这一取舍也与 Tolaria以 Markdown frontmatter 为事实源的整体架构参见 docs/adr/0008-underscore-system-properties.md 与 docs/adr/0025-type-field-canonical.md一脉相承。实战用任意 frontmatter 字段定义关系基于上述机制用户在笔记的 frontmatter 中声明关系的方式非常直观。参考 site/concepts/relationships.md 中的示例belongs_to: - [[product-work]] related_to: - [[documentation]] - [[editor-research]] blocked_by: - [[release-process]] - [[sync-conflicts]]其中blocked_by完全由用户自定义——它不在任何预置名单中只因为值含 wikilink 就被动态识别为关系字段。仓库内的真实用例demo vault 中有大量真实示例。以 demo-vault-v2/25q2-laputa-v2.md 为例--- type: Project aliases: - [[Laputa App V2]] belongs_to: [[25q2]] owner: [[person-luca-rossi]] status: Active related_to: - [[laputa-qa-reference]] ---这里同时体现了三种形态belongs_to使用单值字符串[[25q2]]owner是用户自定义关系键related_to使用数组。三者都会被解析进relationships其中belongs_to还会同步填充VaultEntry.belongs_to便利字段。单值、数组与混合数组的解析规则mod_tests/relationships.rs 用大量用例固化了行为单字符串Mentor: [[person/bob|Bob Smith]]→relationships[Mentor] [[[person/bob|Bob Smith]]]且Owner不会进入properties测试test_parse_relationships_single_string数组Topics: [[[topic/rust]], [[topic/wasm]]]→ 逐项收集test_parse_relationships_array混合数组数组中同时含 wikilink 与普通字符串时只保留 wikilinktest_parse_relationships_mixed_wikilinks_and_plain_in_arrayReferences: - [[source/paper-a]] - just a plain string - [[source/paper-b]] - no links here解析结果为relationships[References] [[[source/paper-a]], [[source/paper-b]]]纯普通字段不含 wikilink 的Tags、Custom Field走properties不进关系test_parse_relationships_ignores_non_wikilinks大体积关系数组单字段 32 个 wikilink 也能完整解析test_parse_large_notes_relationship_array。wikilink 别名语法关系值支持[[target|display]]形式例如[[essay/foo|Foo Essay]]。relationships中保存的是完整 wikilink 字符串含显示别名而正文出链提取extract_outgoing_linksparsing.rs会剥离|display部分只保留 target。两种处理各司其职关系面板需要展示别名图谱导航需要纯净的目标路径。向后兼容belongs_to/related_to/has的去特权化ADR 明确Standard fields (belongs_to,related_to) are still recognized for backward compatibility but not privileged.在实现中这体现为便利字段 动态捕获并存VaultEntry保留belongs_to、related_to两个显式字段entry.rs供旧版前端逻辑使用同一份数据同时进入relationships动态映射前端RelationshipsPanel提供belongs_to、related_to、has三个建议/内置关系键RelationshipsPanel.tsx其中has作为belongs_to的自动反向关系出现——按 site/concepts/relationships.md 的说明If a note says itbelongs_toa project, the project can show that note under its inversehasrelationshiprelated_to则是双向横向关系。命名规范化方面关系键测试prefers_snake_case_relationship_keys_for_convenience_fieldsrelationship_key_tests.rs验证了同时存在belongs_to与Belongs to时蛇形命名优先进入便利字段仅存在旧式Belongs to时也能正确回退。这意味着历史笔记无需改写即可继续工作。前端呈现Inspector 关系面板与 Neighborhood 模式ADR 的后果之一是All relationship fields appear in the Inspectors RelationshipsPanel automatically. 前端组件 src/components/inspector/RelationshipsPanel.tsx 直接消费VaultEntry.relationships每个动态关系键渲染为一个分组显示原始字段名经humanizePropertyKey美化与其 wikilink 值列表支持在面板内直接增删关系值并通过NoteSearchList搜索笔记后写入[[wikilink]]新增自定义字段时无任何白名单约束——只要是含 wikilink 的字段就会自动出现。这些出链与反链数据进一步服务于 Neighborhood 模式笔记列表的图视图与过滤器把静态 frontmatter 变成可导航、可检索的关系网络。前端对 wikilink 的解析与写入工具集中在 src/utils/wikilink.ts如isWikilink、canonicalWikilinkTargetForEntry等与 Rust 端的判定口径保持一致。边界情况与误报风险动态检测的代价是假阳性任何含字面[[与]]的字符串都会被当作关系。ADR 将其列为明确的再评估触发器Re-evaluation trigger: if false-positive detection becomes a problem (e.g., fields with literal[[content that arent relationships).当前项目对该风险的缓解手段包括双括号语法本身[[...]]在 Markdown 中是足够特殊的约定普通文本几乎不会恰好成对出现保留字段过滤is_reserved排除了结构性元数据与下划线系统字段前后端一致性测试containsWikilinks在 src/components/DynamicPropertiesPanel.tsx 中与 Rust 端逻辑对齐确保渲染层与解析层对是否为关系的判定一致明确的测试覆盖混合数组、flow 嵌套、跳过键等场景均有回归测试兜底mod_tests/relationships.rs、relationship_key_tests.rs。此外关系数据通过 docs/adr/0043-reactive-vault-state-on-save.md 描述的状态刷新机制在保存时即时重算误报字段一旦被用户改成普通文本会立刻从关系面板中消失无需重启应用。小结ADR-0010 以极小的实现成本解决了任意关系类型这一知识库领域的经典难题不做配置、不做白名单让[[wikilink]]的存在性成为唯一的领域语言。这套机制的收益包括用户可以用任意字段名表达关系Owner:、blocked_by:、Sponsors:……零学习成本新增关系类型不再需要发版纯数据驱动关系字段自动进入 Inspector 面板、Neighborhood 模式与过滤器形成完整的关系图谱体验旧有belongs_to/related_to/has字段保持兼容平滑迁移。其代价字面双括号内容的误报被双括号语法与保留字段过滤控制在可接受范围并留有明确的再评估触发条件。对于任何以 frontmatter 为事实源、关系类型开放演进的 Markdown 知识库应用这套约定优于配置的动态关系检测思路都值得借鉴。进一步阅读关系语义的完整用户文档见 site/concepts/relationships.mdwikilink 使用方法见 site/guides/use-wikilinks.mdfrontmatter 字段参考见 site/reference/frontmatter-fields.md关系解析的全部 Rust 测试位于 src-tauri/src/vault/mod_tests/relationships.rs 与 src-tauri/src/vault/relationship_key_tests.rs。【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolaria创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Tolaria 动态 Wikilink 关系检测：零配置的笔记关系图谱实现解析（ADR-0010）
Tolaria 动态 Wikilink 关系检测零配置的笔记关系图谱实现解析ADR-0010【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolaria本文围绕 docs/adr/0010-dynamic-wikilink-relationship-detection.md 展开深入剖析 Tolaria原 Laputa如何通过扫描 frontmatter 中所有含[[wikilink]]的字段来自动识别笔记间任意类型的关系从而免去硬编码关系字段列表的维护成本。读完本文你将掌握这套约定优于配置的关系检测机制的完整工作原理、源码级实现细节、真实 vault 中的配置写法以及误报边界与规避策略。Tolaria 是一款以本地 Markdown 知识库为核心的桌面应用。在其早期设计ADR-00102026-03-08中团队面临一个典型问题笔记之间的关系类型如Topics:、Key People:、Depends on:是开放且不断演进的硬编码的关系字段白名单让新增一种关系变成一次代码改动。本文记录了他们最终选择的方案——动态关系检测即解析器扫描全部 frontmatter 键凡是值中包含[[wikilink]]的字段一律视为关系字段。该机制至今仍构成 Tolaria 关系图谱、Inspector 关系面板与 Neighborhood 模式的基础。背景与动机为什么硬编码关系字段不可持续在引入动态检测之前Tolaria 使用一份硬编码列表RELATIONSHIP_KEYS来判定哪些 frontmatter 字段属于关系。这套方案的痛点非常直观新增关系类型 改代码用户想用Depends on:或Sponsors:这类自定义关系时必须等待一次代码发布用户无法自洽知识库的领域语义千差万别项目管理、个人笔记、研究文献……应用不可能预知所有关系名称列表漂移硬编码列表与真实数据脱节后容易出现字段明明写了却不算关系的认知偏差。从仓库现状可以印证这一演进方向今天的VaultEntry结构体在 src-tauri/src/vault/entry.rs 中为关系字段保留了通用入口/// Generic relationship fields: any frontmatter key whose value contains wikilinks. /// Key is the original frontmatter field name (e.g. Has, Topics, Events). pub relationships: HashMapString, VecString,这段注释直接复述了 ADR 的核心决策关系的判定标准不再是这个字段叫什么而是这个字段的值里有没有 wikilink。核心决策以[[wikilink]]存在性为唯一判据ADR-0010 的决策原文如下The Rust parser dynamically detects relationship fields by scanning all frontmatter keys for values containing[[wikilinks]]. Any field with wikilink values is captured in therelationshipsHashMap — no hardcoded field name list needed.翻译成实现语言解析 Markdown 文件时先通过gray_matter解析 YAML frontmatter再遍历其中每一个键值对只要值字符串、字符串数组乃至嵌套结构里含有[[与]]包裹的 wikilink就把该字段连同其 wikilink 值写入relationships映射。源码级实现extract_relationships关系提取的入口位于 src-tauri/src/vault/frontmatter.rs/// Extract all wikilink-containing fields from raw YAML frontmatter. pub(crate) fn extract_relationships( data: HashMapString, serde_json::Value, ) - HashMapString, VecString { let mut relationships HashMap::new(); for (key, value) in data { if FrontmatterKey::new(key).is_reserved() { continue; } let wikilinks relationship_wikilinks(value); if !wikilinks.is_empty() { relationships.insert(key.clone(), wikilinks); } } relationships }关键逻辑只有三步跳过保留字段is_reserved()防止结构性元数据如type、aliases、Status等被误判为关系递归提取 wikilinkrelationship_wikilinks对值做深度遍历非空即收录只要某字段提取出至少一个 wikilink就以原始字段名为键写入relationships。值得注意字段名原样保留包括大小写与空格因此Topics:、Key People:、Has:这些人类可读的字段名会直接成为关系键配合前端的 humanize 逻辑在界面上友好展示。wikilink 判定与递归收集值是否含 wikilink由 src-tauri/src/vault/parsing.rs 中的contains_wikilink判定/// Check if a string contains a wikilink pattern [[...]]. pub(super) fn contains_wikilink(s: str) - bool { s.contains([[) s.contains(]]) }而collect_relationship_wikilinkssrc-tauri/src/vault/frontmatter.rs负责递归收集fn collect_relationship_wikilinks( value: serde_json::Value, depth: usize, wikilinks: mut VecString, ) { match value { serde_json::Value::String(s) if contains_wikilink(s) wikilinks.push(s.clone()), serde_json::Value::Array(arr) { if let Some(link) nested_flow_wikilink(arr, depth) { wikilinks.push(link); return; } for item in arr { collect_relationship_wikilinks(item, depth 1, wikilinks); } } _ {} } }它覆盖了三种值形态单字符串Owner: [[person/luca-rossi|Luca Rossi]]→ 收集 1 条字符串数组Topics: [[[topic/rust]], [[topic/wasm]]]→ 逐项收集嵌套 flow 数组YAML 解析出的嵌套数组如[[person/alice]]的 flow 表示通过nested_flow_wikilink还原为[[person/alice]]形式depth 0时单元素非 wikilink 数组被包装成 wikilink。同时extract_properties同一文件的 frontmatter.rs与关系提取互为镜像含 wikilink 的值进入relationships不含 wikilink 的标量/标量数组进入properties。两类数据互斥不会重复归属。保留字段名单is_reservedsrc-tauri/src/frontmatter/keys.rs 定义了保留字段的判定pub(crate) fn is_reserved(self) - bool { self.normalized().starts_with(_) || is_known_frontmatter_key(self) }即两类字段不会被视为关系下划线前缀规范化后_archived、_icon、_order、_sort、_favorite等系统字段已知 frontmatter 键KNOWN_FRONTMATTER_KEYS表同文件 keys.rstitle、type/is_a/Is A、aliases、Status、color、template、visible、view等。关系键测试 relationship_key_tests.rs 对此有明确断言Is A、Aliases、Status即使值是[[...]]也不会进入relationships而Cadence、Created at、Real Relation这类自定义键则正常收录。方案权衡动态检测 vs 硬编码 vs 用户配置ADR 记录了三个候选方案及其取舍方案思路优点缺点A采用依据[[wikilink]]存在性动态检测零配置、可扩展、任意字段名皆可用含字面[[...]]内容的字段可能误报由双括号语法缓解B硬编码RELATIONSHIP_KEYS列表简单、可预测不灵活新增关系类型需改代码C在 vault 配置中声明关系字段列表灵活增加配置负担开箱不可用最终选择方案 A理由是它把新增关系的成本降到了零用户不需要了解任何配置项只需在 frontmatter 里写下[[wikilink]]。这一取舍也与 Tolaria以 Markdown frontmatter 为事实源的整体架构参见 docs/adr/0008-underscore-system-properties.md 与 docs/adr/0025-type-field-canonical.md一脉相承。实战用任意 frontmatter 字段定义关系基于上述机制用户在笔记的 frontmatter 中声明关系的方式非常直观。参考 site/concepts/relationships.md 中的示例belongs_to: - [[product-work]] related_to: - [[documentation]] - [[editor-research]] blocked_by: - [[release-process]] - [[sync-conflicts]]其中blocked_by完全由用户自定义——它不在任何预置名单中只因为值含 wikilink 就被动态识别为关系字段。仓库内的真实用例demo vault 中有大量真实示例。以 demo-vault-v2/25q2-laputa-v2.md 为例--- type: Project aliases: - [[Laputa App V2]] belongs_to: [[25q2]] owner: [[person-luca-rossi]] status: Active related_to: - [[laputa-qa-reference]] ---这里同时体现了三种形态belongs_to使用单值字符串[[25q2]]owner是用户自定义关系键related_to使用数组。三者都会被解析进relationships其中belongs_to还会同步填充VaultEntry.belongs_to便利字段。单值、数组与混合数组的解析规则mod_tests/relationships.rs 用大量用例固化了行为单字符串Mentor: [[person/bob|Bob Smith]]→relationships[Mentor] [[[person/bob|Bob Smith]]]且Owner不会进入properties测试test_parse_relationships_single_string数组Topics: [[[topic/rust]], [[topic/wasm]]]→ 逐项收集test_parse_relationships_array混合数组数组中同时含 wikilink 与普通字符串时只保留 wikilinktest_parse_relationships_mixed_wikilinks_and_plain_in_arrayReferences: - [[source/paper-a]] - just a plain string - [[source/paper-b]] - no links here解析结果为relationships[References] [[[source/paper-a]], [[source/paper-b]]]纯普通字段不含 wikilink 的Tags、Custom Field走properties不进关系test_parse_relationships_ignores_non_wikilinks大体积关系数组单字段 32 个 wikilink 也能完整解析test_parse_large_notes_relationship_array。wikilink 别名语法关系值支持[[target|display]]形式例如[[essay/foo|Foo Essay]]。relationships中保存的是完整 wikilink 字符串含显示别名而正文出链提取extract_outgoing_linksparsing.rs会剥离|display部分只保留 target。两种处理各司其职关系面板需要展示别名图谱导航需要纯净的目标路径。向后兼容belongs_to/related_to/has的去特权化ADR 明确Standard fields (belongs_to,related_to) are still recognized for backward compatibility but not privileged.在实现中这体现为便利字段 动态捕获并存VaultEntry保留belongs_to、related_to两个显式字段entry.rs供旧版前端逻辑使用同一份数据同时进入relationships动态映射前端RelationshipsPanel提供belongs_to、related_to、has三个建议/内置关系键RelationshipsPanel.tsx其中has作为belongs_to的自动反向关系出现——按 site/concepts/relationships.md 的说明If a note says itbelongs_toa project, the project can show that note under its inversehasrelationshiprelated_to则是双向横向关系。命名规范化方面关系键测试prefers_snake_case_relationship_keys_for_convenience_fieldsrelationship_key_tests.rs验证了同时存在belongs_to与Belongs to时蛇形命名优先进入便利字段仅存在旧式Belongs to时也能正确回退。这意味着历史笔记无需改写即可继续工作。前端呈现Inspector 关系面板与 Neighborhood 模式ADR 的后果之一是All relationship fields appear in the Inspectors RelationshipsPanel automatically. 前端组件 src/components/inspector/RelationshipsPanel.tsx 直接消费VaultEntry.relationships每个动态关系键渲染为一个分组显示原始字段名经humanizePropertyKey美化与其 wikilink 值列表支持在面板内直接增删关系值并通过NoteSearchList搜索笔记后写入[[wikilink]]新增自定义字段时无任何白名单约束——只要是含 wikilink 的字段就会自动出现。这些出链与反链数据进一步服务于 Neighborhood 模式笔记列表的图视图与过滤器把静态 frontmatter 变成可导航、可检索的关系网络。前端对 wikilink 的解析与写入工具集中在 src/utils/wikilink.ts如isWikilink、canonicalWikilinkTargetForEntry等与 Rust 端的判定口径保持一致。边界情况与误报风险动态检测的代价是假阳性任何含字面[[与]]的字符串都会被当作关系。ADR 将其列为明确的再评估触发器Re-evaluation trigger: if false-positive detection becomes a problem (e.g., fields with literal[[content that arent relationships).当前项目对该风险的缓解手段包括双括号语法本身[[...]]在 Markdown 中是足够特殊的约定普通文本几乎不会恰好成对出现保留字段过滤is_reserved排除了结构性元数据与下划线系统字段前后端一致性测试containsWikilinks在 src/components/DynamicPropertiesPanel.tsx 中与 Rust 端逻辑对齐确保渲染层与解析层对是否为关系的判定一致明确的测试覆盖混合数组、flow 嵌套、跳过键等场景均有回归测试兜底mod_tests/relationships.rs、relationship_key_tests.rs。此外关系数据通过 docs/adr/0043-reactive-vault-state-on-save.md 描述的状态刷新机制在保存时即时重算误报字段一旦被用户改成普通文本会立刻从关系面板中消失无需重启应用。小结ADR-0010 以极小的实现成本解决了任意关系类型这一知识库领域的经典难题不做配置、不做白名单让[[wikilink]]的存在性成为唯一的领域语言。这套机制的收益包括用户可以用任意字段名表达关系Owner:、blocked_by:、Sponsors:……零学习成本新增关系类型不再需要发版纯数据驱动关系字段自动进入 Inspector 面板、Neighborhood 模式与过滤器形成完整的关系图谱体验旧有belongs_to/related_to/has字段保持兼容平滑迁移。其代价字面双括号内容的误报被双括号语法与保留字段过滤控制在可接受范围并留有明确的再评估触发条件。对于任何以 frontmatter 为事实源、关系类型开放演进的 Markdown 知识库应用这套约定优于配置的动态关系检测思路都值得借鉴。进一步阅读关系语义的完整用户文档见 site/concepts/relationships.mdwikilink 使用方法见 site/guides/use-wikilinks.mdfrontmatter 字段参考见 site/reference/frontmatter-fields.md关系解析的全部 Rust 测试位于 src-tauri/src/vault/mod_tests/relationships.rs 与 src-tauri/src/vault/relationship_key_tests.rs。【免费下载链接】tolariaDesktop app to manage markdown knowledge bases项目地址: https://gitcode.com/GitHub_Trending/to/tolaria创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考