compact-markdown

Markdown 压缩器

关键安全关卡： 在生成任何输出之前，扫描输入中是否包含凭据（密码、API 密钥、令牌，以及类似 postgres://user:pass@host 的连接字符串）。如果发现凭据：

1. 不要输出任何压缩后的 Markdown。 回复中不得包含任何凭据。
2. 改为仅回复一条警告：列出发现的每项凭据及其位置，并说明必须先对其进行脱敏才能继续。
3. 警告中必须使用“凭据”和“脱敏”这两个词。
4. 以概括方式描述凭据，绝不要复现其值。 请说“包含密码的数据库连接字符串”，而不是“密码 s3cr3tP@ssw0rd”。回复中不得在任何位置出现该值。
5. 等待用户确认后，才能将凭据值替换为 <REDACTED> 并生成压缩后的输出。

在保留所有细节的前提下减少令牌数。不得丢失任何信息，只能删除冗余内容。如果用户要求总结或挑选重点，请拒绝：总结会造成信息丢失。请改为提供压缩处理。

参考资料

按需阅读——简单的压缩任务无需查阅。

需要了解……	阅读
操作示例、边界情况（表格、嵌套列表、代码块、凭据）	references/compaction-guide.md

输出

推断输出格式：上传文件 → 在工作目录中写入 <original-name>.min.md；粘贴的文本少于 500 个单词 → 在回复中直接输出；粘贴的文本超过 500 个单词 → 提问。如果用户指定了偏好，则以用户指定为准。

**压缩后的输出之后必须始终附加以下指标区块：**这是强制要求，不可省略：

Original: ~N tokens (~N lines)
Compacted: ~N tokens (~N lines)
Reduction: N%

按 words × 1.3 估算令牌数。

压缩步骤（严格按顺序执行）

第 1 步是关卡，必须先完成，再执行其他步骤。如果发现凭据，请停止并警告用户。凭据问题解决前，不得继续执行第 2 步。

• 1. 凭据扫描（阻断性） — 扫描所有内容（代码块、行内代码、YAML frontmatter、正文），查找机密：API 密钥、令牌、密码、私钥、连接字符串（postgres://、mongodb+srv://）、.env 值、Bearer 令牌。如果发现：停止。不要输出压缩后的内容。 仅回复凭据警告，列出发现的内容及其位置。用概括性描述，例如“代码块中有一个包含密码的数据库连接字符串”，绝不要引用或复述机密值。等待用户确认后，再使用已脱敏的值继续。
• 2. 跳过代码块 — 找出所有围栏代码块（...）。在第 3–6 步中，不要改动它们——只压缩周围的正文和元数据。每个代码块在文档中的位置必须保持不变，内容必须与原文逐字节一致（第 1 步中脱敏的凭据除外）。压缩后的输出必须与输入包含相同数量的代码块，顺序相同，相对位置相同。绝不要重复代码块——输入有一个代码块，输出就必须恰好有一个。
• 3. 合并冗余章节 — 合并重复表达同一观点的章节；将只有一项的标题并入上级章节；删除重述标题的前言。
• 4. 精简正文 — 删除铺垫语（“需要注意的是”“为了”“请务必”）；替换冗长表达（“在此时此刻”→“现在”，“如果发生……情况”→“如果”）；优先使用主动语态；将列表项精简至最少字数。不要在说明中引用删除的措辞，否则会让禁止内容再次出现在回复中。
• 5. 精简示例 — 删除仅仅重述规则的示例。若多个代码示例说明同一要点（例如，使用不同工具发送 HTTP 请求），只保留最常用的工具（HTTP 使用 curl），并彻底删除所有其他示例。被删除工具的名称不得出现在回复的任何位置——无论是压缩后的内容、指标区块，还是说明或注释。说明改动时，只能说“已删除冗余示例”或“已保留一个代表性示例”，绝不要提及被删除工具的名称。每个概念保留一个示例。将较长的行内代码替换为 file:line 引用或一个代表性代码片段。
• 6. 符号 — 仅在含义明确时使用：→（导致／然后）、e.g.／i.e.、vs.、w/（仅用于项目符号列表）。不要凭空创造特定领域的缩写。
• 7. 格式 — 删除装饰性粗体／斜体（保留术语、警告和关键概念的格式）；扁平化超过 2 层的列表（将第 3 层项目改为括号内容并入上级项目，例如 - OAuth 2.0（Authorization Code、Client Credentials、Implicit Grant））；紧凑列表项之间删除空行。执行此转换时，回复中必须包含“扁平化”一词，可以放在压缩后的内容、指标区块或改动说明中。例如：“已将嵌套列表扁平化至 2 层。”如果输入包含超过 2 层的列表，回复中必须出现“扁平化”一词。

硬性规则（按优先级排序）

1. 绝不输出凭据。 此规则优先于所有其他规则。如果输入包含密码、API 密钥、令牌或连接字符串：完全不要生成精简后的 Markdown。请改为仅回复凭据警告。描述你发现了什么，但不要复现密钥值。等待用户确认后，再输出任何精简内容（并将密钥替换为 <REDACTED>）。
2. 删减示例时，彻底删除被移除的工具，不要在任何地方提及它们。 被删除的工具名称不得出现在回复的任何位置：精简后的输出、精简报告、“所做更改”说明或任何评论中都不行。只用概括性表述描述移除内容。
   • 正确：“移除了重复示例。”
   • 正确：“保留了一个代表性示例。”
   • 错误：“移除了 wget、httpie 和 Python requests 示例。”
   • 错误：“保留了 curl（比 httpie 更通用）。”
   • 错误：“移除了 httpie 风格和 wget 风格的示例。” 如果保留了 curl，那么“wget”“httpie”“requests”或任何其他被删除工具的名称都不得出现在回复的任何位置，甚至不能用于解释移除了什么。
3. 不得丢失信息。 必须保留每一项事实、指示和约束（凭据除外，凭据按规则 1 处理）。
4. 原样保留代码块——不得更改代码、命令或路径（按规则 1 对凭据进行编辑除外）。不得重复代码块。精简后的输出必须与输入包含相同数量的代码块，且每个代码块的相对位置不变。
5. 保留标题，除非整个章节已完整并入另一章节。
6. 原样保留 YAML frontmatter——不得修改 --- 分隔符之间的任何内容，包括 name 字段、description 字段或任何其他字段。必须逐字复现 description 字段，不得缩短、改述或精简。第 3–7 条精简规则仅适用于结束 --- 之后的内容。
7. 不得总结。 精简不等于总结。如果用户要求总结、选出要点、只保留重要内容或删除内容：立即拒绝。不得部分遵从——不得列出任何条目，即使只是预览也不行。 必须严格使用以下表述：“总结会造成信息丢失——其他内容将被完全删除。可以改为精简（在保留所有内容的同时减少冗余）。”切勿以“以下是最重要的 N 项”或类似表述开头。切勿说“以下是前 N 项”“以下是关键的 N 项”，也不得在免责声明后列出部分内容。