Markdown 语义优化器

一个反复出现的痛点

git diff 里经常铺满大片重排：段落被拆成列表、标题层级忽深忽浅、字段标签和正文混在一起，review 时很难看出到底改了什么。更麻烦的是机械格式化工具解决不了这类问题——prettier 不知道「触发示例」是字段标签还是普通正文，还会把口语里的单波浪号 ~（如「办理业务~」）误改成删除线 ~~。这类判断只能靠语义理解，不能靠正则。

技能如何工作

核心原则

• 内容零删减：只重排与加强调，不删除、不改写原意。
• 先备份再覆盖：覆盖原文件前，在同目录生成 原名.备份-YYYYMMDD-HHMMSS.md，时间戳用 date +%Y%m%d-%H%M%S 获取，并告知用户备份路径。
• 不跑 prettier / markdownlint --fix：表格列对齐会让源码变宽难读，渲染结果并无差别。
• 输出位置：默认写到原文件旁的 原名_优化版.md，方便对照。新建文件属低风险，直接写；覆盖原文件必须等用户明确说「覆盖」。

工作流

1. 通读全文：用 Read 完整读取目标 md，语义判断需要全文上下文；超过 400 行时先优化一小节做「样张」给用户确认风格，再跑全篇。
2. 按规则重写：

- 标题层级规范化：章 → #，节 → ##，纯文本标题和 ASCII 缩进伪标题统一转为标准语法；
- 强调规则：字段标签（如 触发示例、前置条件）加粗，关键数值与系统名分别用 加粗 和 行内代码；
- 结构转换：ASCII 树转嵌套列表，并列长段落拆列表，字段对照转表格；
- 错别字只修明显笔误，修了逐条列出，告知可还原。

1. 交付：展示结果文件，附一处「优化前 vs 优化后」代码块对比，汇总改动分类。

适用边界与注意点

• 语义判断的准确性依赖全文上下文，碎片化输入不要指望它补全缺失的章节结构。
• 覆盖桌面等个人目录文件属高风险操作，务必遵守备份规则并明确告知路径。
• 章节序号断号（如 3.1.3.2 直接跳 3.1.3.4）只报告、先确认、再修改——断章可能是有意拆分，不要擅自重排。