# 知识型 Markdown 笔记整理与拆分提示词 请帮我整理并拆分指定的长篇 Markdown 学习笔记，使其成为适合在 Obsidian 中循序学习、独立阅读和长期维护的一组知识笔记。 > [!important] 核心要求 > 必须先完整理解全文，再按知识依赖关系拆分。不要按固定字数、原文件顺序或现有标题机械切割；尽量保持原文内容、观点、示例和表达不变。 ## 一、任务目标 根据该领域常见的知识体系、学习路径、前置依赖、难度递进和实际应用方向，完成以下工作： 1. 将长笔记拆分为若干主题完整的中文笔记； 2. 按适合初学者的顺序建立推荐学习路线； 3. 修复标题、段落、列表、表格、代码和 Markdown 格式； 4. 建立总目录、上一篇/下一篇、前置知识、后续学习及相关内容链接； 5. 保留原文完整备份，并验证正文、图片、代码和链接没有丢失。 只允许进行必要的内容移动、归类、去重、标题调整和格式修复。不要凭空补充原文没有支持的事实、案例、引用或结论，也不要把原文统一改写成 AI 文风。 --- ## 二、执行方式 请直接执行，但必须按以下阶段进行，不要一边粗略扫描一边批量覆盖。 ### 阶段一：完整读取与审计 1. 读取目标笔记全文； 2. 读取与上下文有关的本地图片、附件和必要的链接笔记； 3. 识别知识主题、前置关系、难度层次和可选专题； 4. 审计标题、正文、代码、命令、表格、图片和导入噪声； 5. 记录需要人工结合上下文判断的问题，不要仅凭正则表达式直接替换。 ### 阶段二：制定拆分方案 1. 确定分篇主题和中文文件名； 2. 确定推荐学习顺序； 3. 确定各篇的前置知识及相互关系； 4. 确认每个示例、图片、代码块和说明归属哪一篇； 5. 确认拆分位置均为自然知识边界。 ### 阶段三：备份与写入 1. 创建 `拆分前完整备份.md`； 2. 验证备份写入完整后再修改原文件； 3. 创建分篇笔记； 4. 将原文件改为总目录； 5. 添加必要的学习导航和双向链接； 6. 不修改已经创建的完整备份。 ### 阶段四：逐篇复查 先逐篇抽样阅读，再运行结构检查。不能只依赖批量脚本宣告完成。 除非出现无法从原文判断、且错误处理可能破坏内容的关键歧义，否则不必让我逐项确认。 --- ## 三、拆分原则 ### 1. 按知识逻辑组织 通常可以参考以下顺序，但必须根据具体领域调整： 1. 基础概念与背景； 2. 环境搭建与准备； 3. 基础语法或基本操作； 4. 核心知识； 5. 综合应用； 6. 工程实践、系统管理或实际案例； 7. 开发、源码、性能、安全、服务器等进阶专题。 不要简单复制原文顺序，也不要把进阶内容插入初学者必学路径。 ### 2. 保证每篇主题完整 每篇笔记应当： - 主题集中、边界清楚； - 能够相对独立阅读； - 所需前置知识已经出现； - 同一知识点尽量不跨文件拆断； - 示例、代码、图片、输出结果和解释保持在一起； - 结论与论证过程不分离。 ### 3. 不按字数机械切割 篇幅可以不均衡。主题过长时可以继续按子主题拆分，但不得： - 在段落、列表、表格或代码块中间截断； - 将函数、类或一个完整示例拆到两篇； - 为平均文件大小破坏知识逻辑； - 将说明留在上一篇、代码放到下一篇。 ### 4. 标记非主线内容 开发、源码、内核、安全、服务器和专项工具等内容，可以根据学习目标标为“选学”“进阶”“专题”或“实践”。 --- ## 四、标题与正文的语义识别 逐行判断原文中的 `#` 是否真的是 Markdown 标题。不要因为某行以 `#` 开头，或原文把它写成大号字体，就直接认定为标题。 ### 真标题应满足 - 能概括后续一组内容； - 后面有若干段落、列表、示例或子主题； - 在全文知识结构中有明确层级； - 不是依附于单个命令、参数或例子的临时说明。 ### 以下内容通常不是标题 - 一整句解释性正文； - “下面我们……”“可以看到……”等过渡句； - “注意”“例如”“说明”“或者”等短句； - 单条命令、命令格式或参数名称； - 返回值、输入输出和操作步骤； - 图片说明和表格中的字段； - 代码注释、预处理指令和 Shell 提示符； - 被 OCR、Word、网页或文档转换工具误加 `#` 的普通内容。 这些内容应根据语义恢复为正文、列表、行内代码、代码块、表格、加粗说明或 callout。 --- ## 五、标题层级规范 每篇笔记只能有一个一级标题： ```markdown # 本篇主题 ``` 其余内容按逻辑使用： ```markdown ## 主要章节 ### 子主题 #### 示例、参数或补充说明 ``` 要求： - 标题层级连续，不无故跳级； - 不使用超过六级的标题； - 不把每条命令、步骤、参数或示例都设为标题； - 不为了视觉效果制造大量空洞标题； - “格式”“说明”“选项”等标题必须隶属于明确的上级主题； - 标题下应有实际内容； - 同级标题应处于相近的抽象层次； - 拆分后必须逐篇人工复查标题语义，不能只依赖脚本。 --- ## 六、代码、命令与导入噪声处理 这是强制检查项。 ### 1. 区分不同内容类型 - 单个标识符、类型名、函数名、短表达式或单条短命令：使用行内代码； - 多行 C/C++、Python 等程序代码：使用对应语言的代码块； - 多行 Shell 命令：使用 `bash` 或相应 Shell 代码块； - 编译结果、终端输出、报错信息：使用 `text` 代码块； - 代码解释仍作为正文，不得混入代码块； - 不得仅因一行包含分号、`class`、`new`、`int` 等词，就把整段正文判定为代码。 ### 2. 恢复网页或文档导入产生的代码块 常见损坏形式包括： ```text cpp 复制 下载 class Example { public: void run(); }; ``` 应整理为： ```cpp class Example { public: void run(); }; ``` 需要删除仅用于网页界面的噪声，例如： - `cpp`、`c++` 等孤立语言标签； - `复制`、`下载`、`Copy`、`Download`； - `AI写代码`； - 明显属于代码编辑器界面的孤立行号。 删除前必须确认它们不是正文内容。 ### 3. 修复代码导入损坏 结合上下文修复以下格式问题： - `\#include`、`**#include <...>**` 等代码块外遗留格式； - 每行分别加粗或整个代码段被粗体包裹； - `*//*`、`*//`、`\*//\*` 等损坏的 C/C++ 注释； - 注释中的 `p* *是空指针`、`T* *是类型参数` 等残留强调符； - 代码与解释文字被放在同一代码块； - 代码围栏语言缺失、错误或不统一； - 空代码块、未闭合代码块和被截断的代码块。 例如： ```text int *p = nullptr; *//* *p 是空指针* ``` 应恢复为： ```cpp int *p = nullptr; // p 是空指针 ``` 只修复能够从上下文明确判断的格式损坏，不得擅自改变代码逻辑、变量名、返回值或知识结论。 ### 4. 代码块内部规范 - 代码块内保留正常语言语法，不做 Markdown 转义； - C++ 代码块中的 ``、`#include `、`*p`、`int **ptr` 必须保持原样； - 删除代码行上的 Markdown 粗体、斜体和多余反斜杠； - 保持或恢复合理缩进； - 代码围栏前后保留空行； - 同一个示例不要被拆成多个无意义的单行代码块； - 不把正文、结论或步骤说明包进代码块。 --- ## 七、Markdown 敏感代码符号 代码块外的 C++ 模板、头文件、指针和解引用表达式容易被 Markdown 误解析，必须专项检查。 ### 1. 尖括号与 HTML 误识别 在代码块和行内代码之外，任何形如 ``、``、`vector`、`template ` 的内容，都可能被识别为 HTML。 处理规则： - 优先将完整代码表达式写成行内代码，例如 `` `vector` ``； - 如果需要保留普通正文或粗体格式，则至少转义左尖括号，例如 `vector \`、`\`； - 不要写成裸露的 ``、`` 或 ``； - 不要在代码围栏内部添加这些反斜杠。 ### 2. 指针、解引用与乘法星号 在代码块和行内代码之外，裸露的 `*p`、`int *p`、`int **ptr`、`(*ptr)[N]` 可能被识别为斜体或粗体。 处理规则： - 优先使用行内代码，例如 `` `*p` ``、`` `int **ptr` ``； - 如果必须保留普通正文或粗体，则逐个转义星号，例如 `\*p`、`int \*p`、`int \*\*ptr`、`(\*ptr)[N]`； - 不允许残留 `***a**`、`****`、未闭合 `**` 等损坏的强调标记； - 表格中的类型和表达式也必须执行同样检查。 ### 3. 其他易误解析内容 以下内容在正文中优先使用行内代码： - `#include `； - `std::vector`； - `operator*`、`operator<`； - Lambda 表达式； - 比较、赋值、取地址和解引用表达式； - 包含 `&`、`<`、`>`、`*`、`[]`、`::` 的代码片段。 ### 4. 强制扫描 整理完成后，扫描代码块外且不在行内代码中的： - 未转义的 `<字母...>`； - 未转义的单星号和双星号代码表达式； - `***`、`****` 和奇数个粗体分隔符； - 未闭合的行内反引号； - 损坏的 `*//*`、`*//`、`\*//\*` 注释。 发现命中后必须结合上下文修复，不能直接把所有命中项机械替换。 --- ## 八、原文保护与必要编辑 ### 必须保留 - 原文主要内容、原意、个人表达和判断； - 专业术语、命令、参数和代码； - LaTeX、HTML、表格、引用和 callout； - 图片、Wiki-links、外部链接和脚注； - 示例、输出结果及其解释。 ### 可以调整 - 内容所在文件和章节； - 不合理的标题层级； - 明显由 OCR、网页或文档转换产生的格式错误； - 重复标题和完全相同的重复内容； - 列表、表格、代码块和 Markdown 转义； - 少量影响理解的病句、错别字和标点。 ### 不允许 - 擅自删除无法确认重要性的内容； - 大幅改写原文风格； - 凭空补充事实、案例、引用或结论； - 修改命令、代码、公式和结论的含义； - 因内容看起来过时就直接删除； - 未确认备份成功便覆盖原文； - 使用正则表达式对全文进行未经抽样检查的盲目替换。 发现疑似事实错误或过时内容时，可以添加简短提示，但不要擅自改成另一个结论。 --- ## 九、文件命名、备份与安全 ### 文件命名 拆分后的文件名必须以中文为主，并使用统一的两位数编号，例如： ```text 01 基础概念与历史背景.md 02 环境搭建与基本操作.md 03 文件系统与常用命令.md ``` C++、STL、GCC、Linux 等必要专业术语可以保留。不要使用 `part1.md`、`basics.md`、`chapter-01.md` 等模糊英文名。 同时要求： - 文件名与一级标题基本一致； - 编号连续且位数统一； - 重命名后同步更新全部 Wiki-links； - 避免使用 Windows 文件名不支持的字符。 ### 备份与安全 - 拆分前创建 `拆分前完整备份.md`； - 备份必须包含原笔记完整正文； - 验证备份成功后再改写原文件； - 备份创建后不得继续格式化或修改； - 不移动、删除或重命名图片资源； - 不触碰无关笔记和 `.obsidian/` 配置； - 所有写入操作仅针对目标目录中的明确文件。 --- ## 十、总目录与学习路线 将原长笔记改为总目录。总目录至少包含： ```markdown # 学习指南 > [!tip] 使用说明 > 本笔记已按照知识依赖关系拆分，建议按以下顺序学习。 ## 推荐学习顺序 1. [[所在文件夹/01 基础概念|基础概念]] 2. [[所在文件夹/02 环境搭建|环境搭建]] 3. [[所在文件夹/03 核心知识|核心知识]] ## 学习路线 - **入门基础**：第 1～3 篇； - **核心知识**：第 4～6 篇； - **实践应用**：第 7～8 篇； - **进阶选学**：第 9 篇以后。 ## 原文备份 - [[所在文件夹/拆分前完整备份|拆分前完整备份]] ``` 目录顺序必须体现真实知识依赖，不能只是复制原文标题顺序。 --- ## 十一、双向链接与学习导航 遵循 [[Template_math]] 的格式，即： ```yaml --- tags: [] 下一篇: "[[所在文件夹/03 下一篇|下一篇标题]]" 上一篇: "[[所在文件夹/01 上一篇|上一篇标题]]" 返回目录: "[[所在文件夹/总目录|学习指南]]" 前置知识: "[[所在文件夹/02 前置主题|前置主题]]" abstract: "" finished: false creation: <% tp.file.creation_date("YYYY-MM-DD") %> --- <% tp.file.cursor() %> ``` 没有必要的前置知识时，不添加前置知识。 第一篇不添加“上一篇”，最后一篇不添加“下一篇”。 ### 相关关系 可以按真实知识关系添加“后续学习”和“相关内容”，例如： - 基础概念与实际应用； - 用户管理与文件权限； - 进程管理与服务管理； - 网络基础与 SSH； - 编译工具与调试工具； - 容器、算法与迭代器； - 类、继承与多态。 链接要求： - 总目录链接到所有分篇； - 每篇可以返回总目录； - 上一篇和下一篇连续； - 前置知识与后续学习形成必要的双向关系； - 优先使用完整相对路径； - 同名笔记用路径消除歧义； - 不创建没有目标文件的空链接； - 不保留旧文件名链接； - 不为了增加数量而机械互链。 --- ## 十二、Obsidian 语法与图片保护 不得破坏： - YAML frontmatter； - Wiki-links 和嵌入语法； - 块引用、callout、脚注和标签； - Markdown 链接； - Dataview、Templater 和 Mermaid； - LaTeX、HTML 和代码围栏。 图片处理要求： - 本地图片继续使用原有路径和嵌入方式； - 图片、图注和解释必须保留在同一篇； - data URI 图片的超长行不得重新编码、折行或误当正文处理； - 不根据文件大小判断正文多少，因为 data URI 会显著放大文件； - 拆分前后应比较图片数量；条件允许时比较图片内容或 data URI 哈希，确保完全一致。 --- ## 十三、完成后的强制验证 ### 1. 内容完整性 - 原文是否全部进入拆分结果； - 是否有段落丢失、重复或被截断； - 示例、图片、代码、输出和解释是否仍在一起； - 是否存在空文件； - 备份是否完整且未被修改。 不要只比较总行数。应在忽略标题、导航、代码围栏和纯格式变化后，对正文做抽样或归一化比对。 ### 2. 标题与文件 - 每篇是否恰好一个一级标题； - 一级标题是否与文件名一致； - 是否仍有正文、命令、参数或过渡句被误设为标题； - 标题层级是否连续； - 是否存在空标题或超过六级的标题； - 文件名是否中文为主且编号连续； - 总目录和全部分篇是否位于预期目录。 ### 3. 代码与 Markdown - 代码围栏是否成对且语言正确； - 是否有空代码块或被截断的代码块； - 是否仍有孤立的 `cpp`、`复制`、`下载`、`AI写代码`； - 是否仍有 `*//*`、`*//`、`\#include` 等导入损坏； - 代码块内是否混入正文； - 正文是否被误包进代码块； - 代码块外是否存在会被当作 HTML 的裸 ``、`` 等； - `*p`、`int **ptr` 等是否使用行内代码或正确转义； - 是否存在未闭合粗体、`***`、`****` 或奇数个反引号； - 表格、列表、callout、YAML、LaTeX 和 HTML 是否有效。 ### 4. 图片 - 图片数量是否与拆分前一致； - 所有图片路径是否有效； - 是否有图片遗漏或被移动； - data URI 或图片哈希是否一致； - 图片是否仍与相关说明位于同一篇。 ### 5. 链接与导航 - 总目录是否链接到所有分篇； - 每篇是否能返回总目录； - 上一篇、下一篇是否连续； - 第一篇和最后一篇是否没有越界链接； - 所有 Wiki-links 的目标是否真实存在； - 是否仍有旧文件名、空链接或歧义链接； - 双向链接是否反映真实知识关系。 ### 6. 最终抽样 至少抽查： - 第一篇、中间篇和最后一篇； - 含大量代码的笔记； - 含表格、图片或 data URI 的笔记； - 拆分边界两侧的段落； - 自动脚本命中的高风险位置。 未完成上述检查前，不要报告任务完成。 --- ## 十四、最终汇报格式 完成后只需简要汇报： 1. 拆分篇数和推荐学习顺序； 2. 创建或更新的文件； 3. 修正的主要结构与格式问题； 4. 建立的双向链接类型； 5. 备份文件位置； 6. 验证结果： - 内容是否完整； - 图片是否缺失或发生变化； - 代码围栏是否成对； - Markdown 敏感符号是否处理； - Wiki-links 是否有效； - 是否仍有正文误判为标题； 7. 仍需用户确认的事实疑点，如有。 不要在回复中完整重复拆分后的正文。