Fabric 的 create_markmap_visualization 模式：把任意复杂思想转化为可交互 Markmap 思维导图

Fabric 的 create_markmap_visualization 模式：把任意复杂思想转化为可交互 Markmap 思维导图

【免费下载链接】FabricFabric is an open-source framework for augmenting humans using AI. It provides a modular system for solving specific problems using a crowdsourced set of AI prompts that can be used anywhere.项目地址: https://gitcode.com/GitHub_Trending/fa/Fabric

本篇文章围绕 Fabric 仓库中的 create_markmap_visualization/system.md 模式文件展开，讲解这套“输入任意内容 → 输出 Markmap 可视化语法”的提示词设计：它定义了 AI 的视觉专家身份、内嵌了一份可直接学习的 Markmap 语法范例、规定了从输入到成图的处理步骤与输出纪律。读完本文，你将掌握该模式的核心机制、Markmap 语法的关键约束（如标题层级与列表、块在同一层级的互斥规则），并能用fabric --pattern create_markmap_visualization把它接入自己的文档、汇报与知识整理流程。

一、先把它放回 Fabric 体系：一个“视觉化”Pattern 如何被装载与调用

Fabric 把“一个可复用的 AI 处理单元”组织为一个Pattern：仓库中每个 pattern 是data/patterns/<pattern_name>/目录下的提示词文件，绝大多数以 system.md 作为系统提示词主体，部分还配有user.md作为固定用户输入模板。本模式目录下只有system.md（已通过 list_files 确认），说明它是一个输入无关型模式：待可视化的内容不预置在提示词里，而是在调用时临时注入。

关于装载机制可以从源码得到印证：

• 文件系统数据库约定系统提示词文件名为system.md，见 internal/plugins/db/fsdb/db.go 中SystemPatternFile: "system.md"；
• 默认 pattern 目录常量DefaultPatternsGitRepoFolder = "data/patterns"，见 internal/tools/patterns_loader.go，该目录可通过fabric --setup引导配置并可同步更新；
• 模式文件尾部预留的INPUT:输入位，由加载器在拼装请求时用真实用户输入替换（见 internal/plugins/db/fsdb/patterns.go 中“replace our sentinel with the actual user input”的处理逻辑）。

在 CLI 上的调用方式为：

echo "你的任意文本/网页正文/会议要点/论文片段……" | fabric --pattern create_markmap_visualization

--pattern（短参数-p）是 fabric 顶层参数之一，见 internal/cli/flags.go；运行fabric --listpatterns即可看到本模式。也可把整个目录当作 prompt 主体传入：若把模型输出通过 Markmap 渲染器展示，就得到一棵可缩放、可折叠的交互式思维导图。README 中还提供了把 pattern 注册为 shell 别名的做法，例如alias markmap_visualize='fabric --pattern create_markmap_visualization'，参考 README.md 中的别名说明。

仓库内的辅助索引资料把该模式描述为：将复杂思想转换为清晰的可视化，用 Markmap 语法简化概念、并借助关系、方框、箭头与标签呈现结构（见 pattern_explanations.md）；元数据标签为VISUALIZE / CONVERSION / CR THINKING（见 pattern_descriptions.json），即它同时服务于“可视化输出”“内容转换”与“批判性思维梳理”三类场景。

二、IDENTITY and PURPOSE：给模型一个“数据与概念可视化专家”的身份

system.md 开篇先用身份声明锁定模型的行为取向（对应原文前 8 行）：

• 模型被定位为Markmap 场景下的数据与概念可视化专家，擅长把复杂想法改写成可用 Markmap 表达的形式；
• 输入类型不限（文本、结构化数据、讨论、代码等均可），模型的工作是找出“最能表达核心思想”的 Markmap 组织方式；
• 关键约束是：即使必须把输入概念简化到能被 Markmap 可视化的程度，也始终输出 Markmap 语法。

这条约束决定了本模式的根本策略——Markmap 是受 Markdown 标题层级驱动的树形导图，天然擅长“层级 + 归类 + 标签”的表达，而对非树形或高维关系则需先做面向树的简化。提示词明确授予模型“化简输入”的权限，目的是保证任何输入都能落地成一棵自洽的思维导图，而不是因形式不匹配而拒绝输出。

三、MARKMAP SYNTAX：内嵌的官方语法范例逐行拆解

system.md 中段完整内嵌了一段可渲染的 Markmap 示例（对应原文件第 9～57 行，原文用plaintext围栏包裹）。这段内容同时承担两重职能：既是给模型“照着学”的少样本范例，也是本文读者快速掌握 Markmap 的最佳教材。下面按结构分层解读。

3.1 Front matter：配置渲染参数

markmap: colorFreezeLevel: 2 ---

Markmap 支持在文档头部写markmap:开头的 YAML 配置段，再以---与正文分隔。示例中的colorFreezeLevel: 2表示把前两层标题的主题配色“冻结”下来，第 3 层及以下的节点颜色由其祖先决定，从而避免深层节点配色过于杂乱。实际可调参数还包括控制超长文本是否折行显示的maxWidth（见后文 3.3）。

3.2 标题层级 = 树的深度，列表/块用于承载叶子节点

Markmap 的核心语法非常朴素：每一级#标题对应导图中的一个层级，一级标题是根节点，##、###依次向下展开；节点下的列表项、块级内容则成为该节点的附加信息。示例中：

• # markmap是根节点；
• ## Links、## Related Projects、## Features是二级主干；
• 每个##下的- [...]列表项对应其叶子分支。

请特别注意原文明确指出的一个同级互斥规则：“如果列表和块出现在同一层级，列表会被忽略”（Note that if blocks and lists appear at the same level, the lists will be ignored.）。示例为此特意把## Features下的富文本列表（### Lists）与代码块/表格区块（### Blocks）分别放进不同的三级标题之下。这是一条非常实用的排错提示：当你发现某个列表“消失”时，多半是它与代码块、表格等块级元素挤在了同一父节点下。

3.3 节点内可用的行内富文本与特殊语法

Markmap 节点正文不只是纯文本，示例中### Lists节点下集中演示了：

• 加粗**strong**、删除线~~del~~、斜体*italic*、高亮==highlight==；
• 行内代码`inline code`；
• 任务列表[x] checkbox；
• KaTeX 数学公式：$x = {-b \pm \sqrt{b^2-4ac} \over 2a}$；
• 折叠注释<!-- markmap: fold -->：作用是在渲染时默认收起该分支，示例用它把较长的公式子树折叠起来，避免初次展开时导图过长；
• maxWidth选项：现代版本支持依据设定的最大宽度自动折行，示例原文即注明“现在我们可以基于maxWidth选项来折行非常非常长的文本”。

这些能力意味着 Markmap 导图节点可以承载轻量的排版强调、代码片段乃至数学公式，使其不只是“大纲”，而是带语义标注的知识节点。

3.4 Blocks：代码块、表格与图片如何进入导图

示例的### Blocks分支展示了三类“块”：

• 围栏代码块（示例中是一段console('hello, JavaScript')）；
• Markdown 表格（Products / Price 两列）；它会被渲染进节点信息区，用于表达二维对照数据；
• 图片![](/favicon.png)。

也就是说，Markmap 并未把节点限定为纯文本列表，而是兼容相当一部分块级 Markdown——这也解释了为什么要遵守“列表与块分层放置”的纪律：需要表格/代码/图片时，把它们收进独立的子标题下，就能同时保住同级列表与块。

3.5 示例的生态链接段：三种编辑器接入方式

示例中## Links与## Related Projects的分支罗列了 Markmap 生态的常见渲染入口：官方编辑器/站点、面向 Neovim 的 coc-markmap、面向 VSCode 的 markmap-vscode 扩展，以及面向 Emacs 的 eaf-markmap。实际使用时把本模式输出保存为.md文件后，用上述任一工具即可渲染为可交互导图（原文含外链，此处按规范仅作功能说明，不附链接）。

四、STEPS：从任意输入到“独立可传达”的 Markmap 的处理流水线

STEPS 部分（对应原文件第 59～75 行）规定了模型拿到输入后的工作方法，共七步，可归纳为“建图 → 校验 → 定级 → 说明 → 兜底”五道工序：

1. 建图：通读输入，用规范的 Markmap 语法构造最能解释它的可视化；
2. 校验独立性：保证这张图脱离任何上下文、单独看也能完整传达概念——导图不是对原文档的压缩包，而应是自足的知识地图；
3. 用关系元素表达结构：提示词要求“用方框、箭头、标签等视觉元素（when appropriate）展示数据之间、概念之间的关系”——映射到 Markmap 语境，即通过层级嵌套表达包含/派生关系，通过分组标题表达归类，通过加粗/高亮标签表达关键属性；
4. 规模与复杂度匹配：概念越复杂、数据越多，就应产出“更精细、更详尽、更大”的可视化，而不应一律套用四五行的小图；
5. 图文一致性校验：在可视化之后必须输出名为VISUAL EXPLANATION的小节，用每条 10 词以内的要点逐条说明“输入是如何被转化成这张图的”，并要求说明必须与图示完全吻合，不吻合就重画——这是防止模型“画一套、说一套”的自我校验闭环；
6. 聚焦收敛：如果可视化覆盖内容过多，就把它归纳成最主要的主张（primary takeaway），只对这一主张作图；
7. 绝不放弃：明令“DO NOT COMPLAIN AND GIVE UP”——遇到难表达的内容，要么更努力地尝试，要么向上归纳到一个更高层的抽象概念（upleveled concept）再作图。

值得注意的是：VISUAL EXPLANATION用“10 词以内的要点（bullets）”而非段落，是刻意设计的低开销自检手段，让生成说明几乎不消耗输出预算，却能让读者和模型自己都快速核对图示与原文的对应关系。

五、OUTPUT INSTRUCTIONS：三条严格的输出纪律

OUTPUT INSTRUCTIONS（对应原文件第 77～83 行）从“态度”和“格式”两个维度对输出做出硬性限定：

• 不要抱怨，直接产出 Markmap——任何情况下都必须交出一张图；
• 不得输出反引号、代码块标记等“代码指示符”——这一点初看与本文 3.4 的代码块示例矛盾，但二者的语义其实互补：原文档第 48 行的 ```js 代码块是“被可视化进 Markmap 的展示内容”，而 OUTPUT INSTRUCTIONS 禁止的是“用代码块围栏把整份 Markmap 结果包起来”。也就是说：输出应是干净的 Markdown 源文本本身（含必要 front matter 与标题列表），而不是套在外层三反引号代码块里的伪“代码”，这样才方便用户直接另存为.md渲染；
• 无论输入多棘手，都依据 STEPS 决定图型并无论如何都完成作图。

这三条纪律的实际价值在于保证机器可消费性：干净无围栏的 Markmap 文本可以被下游渲染器、脚本或 fabric 管道直接读取，不会被多余的围栏字符污染。

六、INPUT：输入位与一个最小工作示例

system.md 的# INPUT:段（对应原文件第 85～88 行）是模式化的“输入注入点”。它告诉模型：真正的输入会在INPUT:之后给出。对使用者而言，这意味着：

• 直接“投喂原文”即可，无需手动附加指令；
• 系统会自动用调用者的输入替换该位置的内容（配合 patterns.go 中 sentinel 替换机制理解更佳）。

以输入一句技术判断为例，可预期的典型问答形态如下（示意）：

# INPUT: 对比 monolith 与微服务：微服务独立部署、边界清晰但分布式事务复杂； 单体简单直接但耦合高、扩展性差；团队规模小时更推荐单体。

一个合格的模型输出将是如下形态的“干净 Markdown 树”：

markmap: colorFreezeLevel: 2 --- # Monolith vs Microservices ## Monolith - 简单直接 - 耦合高 - 扩展性差 ## Microservices - 独立部署 - 边界清晰 - 分布式事务复杂 ## Decision - 小团队 → Monolith - 大团队 → Microservices

将该输出保存为.md文件并用 Markmap 渲染器打开，即可获得一棵可交互的决策树。注意上例省略了模式要求的VISUAL EXPLANATION校验小节，真实运行时模型应在其后补上 10 词级要点。

七、实战最佳实践与常见误区

综合原文约束与 Fabric 工程实践，总结如下使用建议：

1. 把“独立成图”当作验收标准：拿到模型输出后，先问“不看原文档，这棵导图能讲清概念吗”；不能，就让模型重画，而不是手动缝补；
2. 善用同层互斥规则排查“丢节点”：列表莫名消失时，检查是否与代码块、表格挤在同一父节点下，把它们移入独立的三级标题即可；
3. 对超长内容先让模型提炼核心主张再作图，避免导图退化为“全文大纲照抄”；
4. 通过--stream观察实时输出，出现大规模回退时及时中断重试（该参数与--pattern可组合使用，见 README.md 中管道与别名示例）；
5. 输出文件化后交给 VSCode/Neovim/Emacs 的 Markmap 插件渲染，与知识库工作流（如 Obsidian 目录保存、-o输出路径）集成，形成“分析 → 导图 → 沉淀”的闭环（README 中有把 pattern 输出自动落盘的别名脚本可供参考）。

另外需注意模式边界：本模式回答的是“如何用树状导图表达”，若你想表达的是流程图、时序图、状态机等非树形关系，应改用仓库中同族的create_mermaid_visualization（data/patterns/create_mermaid_visualization/system.md）或面向 GitHub 文档的create_mermaid_visualization_for_github；若想产出可在浏览器中交互的概念网络，还可参考create_conceptmap、create_excalidraw_visualization等可视化家族模式。它们与本模式共享“独立成图 + 图文一致 + 绝不放弃”的骨架，只是目标语法不同——这也从侧面印证了本模式在方法论上的可迁移性。

八、小结

create_markmap_visualization本质是一份“少样本 + 强约束 + 自校验”的视觉化提示词：

• 少样本：内嵌的 Markmap 语法全示例（front matter、层级标题、富文本节点、代码/表格/图片块、折叠注释）让模型无需预训练该语法也能即时产出合规文本；
• 强约束：IDENTITY 锁定专家身份、OUTPUT INSTRUCTIONS 锁定“干净 Markdown 树”格式，并以“禁止列表与块同层”“内容过多则提炼主主张”等规则控制图的结构质量；
• 自校验：VISUAL EXPLANATION的 10 词要点机制强制图文对齐。

在 Fabric 中，它通过data/patterns目录被 fsdb 加载、以system.md为系统提示词、经fabric --pattern触发。你可以从阅读 system.md 全文开始，把它接入阅读笔记、会议纪要、技术选型对比或论文梳理场景——凡是你需要“把一坨复杂信息变成一张可点击的知识地图”的地方，它都能直接复用。

【免费下载链接】FabricFabric is an open-source framework for augmenting humans using AI. It provides a modular system for solving specific problems using a crowdsourced set of AI prompts that can be used anywhere.项目地址: https://gitcode.com/GitHub_Trending/fa/Fabric