用人工改写比例淘汰低效 AI 文档草稿

AI 写文档最浪费时间的地方，往往是那些每次都要被人重写的章节。作者给出的办法是：记录草稿到最终合并版本的改写比例，持续超出预算的章节，就收回模型的起草权限。

这个思路值得看，因为它把「模型写得好不好」转成了更容易讨论的问题：它到底替人省了多少编辑工作。不过，原文给出的是一套流程设计和示例脚本，没有真实仓库的效果数据，脚本与完整流程之间也还有缺口。

先量返工成本，别急着给文档打质量分

作者选择的信号，是模型草稿与人工最终合并文本之间的差异。相比另设评分表，或再找一个 LLM 当裁判，这个信号直接来自维护者已经做过的编辑。

指标叫改写比例，计算方式是 1 - similarity(draft_tokens, merged_tokens)。文本先转成小写词序列，去掉围栏代码、链接目标和部分 Markdown 标记，再计算相似度。长度不足两个字符的词也会被丢弃，以减少细碎编辑的干扰。

改写比例衡量编辑劳动，不能证明内容正确。

意思相同的两句话调换顺序，也可能得到较高的改写比例；一句错误描述如果没人发现、原样合并，反而能拿到漂亮的分数。这个指标可以辅助分配工作，但不能替代技术审核，更不适合包装成对外的文档质量统计。

作者还区分了两种权限判断。起草前的准入规则，根据 API 变化或内容类型决定模型能否碰某章；这里的预算机制则读取已经接受的历史，撤销曾经授予的权限。两者可以并存，但应放在不同文件和 CI 任务里，避免把内容风险与历史返工成本混成一个判断。

章节和版本对不齐，预算就没有意义

要追踪一章的改写成本，先得确认每次比较的都是同一章。作者建议从标题生成 slug，再把它冻结在台账里；标题改名时，必须在同一个 PR 中更新映射并显式登记别名。已知 slug 消失却没有别名，门禁应失败，由维护者判断这是删除还是改名。

标题是展示文本，章节 ID 是历史记录的身份。两者不能始终绑在一起。

版本也需要对齐。周一生成草稿，周五才合并，如果直接拿草稿与周五整份文件比较，中间其他人的修改也会算到模型头上。原文要求把草稿写到带日期的路径，例如 out/drafts/2026-11-06/guide.md，并将 git rev-parse HEAD 的输出保存到旁边的 base.txt。

作者提出，只有合并文件的历史包含这个基准提交时才计分，否则跳过并记录日志。不过，这项检查只能确认祖先关系，不能自动排除期间的无关编辑。要得到可信样本，还需要明确哪次人工修改是在接受这份草稿，并保留相应版本。

原文的调用方式如下，它把草稿、合并文本、台账和人工负责章节放进一次检查：

python doc_draft_ratio.py \
  --draft out/drafts/2026-11-06/guide.md \
  --merged docs/guide.md \
  --ledger .docs/rewrite-ledger.json \
  --protect install-from-source,security-model

要留意 --protect：脚本只有在受保护章节出现在草稿中、且内容与合并文本不同时才报错。它并不等于禁止模型接触该章节。

收回起草权限，要同时改规则和目录

作者用累计平均改写比例给章节分档，示例脚本中的规则是：

def band(mean):
    if mean < 0.15:
        return "auto-draft"
    if mean < 0.40:
        return "draft-with-review"
    return "human-owned"

要看清这里严格使用 <：均值低于 0.15 可以自动起草，达到 0.15 但低于 0.40 时需要审核，达到 0.40 就归人工负责。阈值是团队政策，不是实验发现。

原文展示了一个 24 章节页面运行六次夜间任务后的台账样子：安装说明均值 0.07、样本 n=6，配置参考 0.12、n=5，迁移说明 0.26、n=6，安全模型 0.51、n=6，支持平台 0.63、n=4。作者明确说明，这些都是示意数据，没有对应真实仓库的测量结果。

在均值分档之外，作者还提出：连续三个样本越过某档边界，就降一档并冻结；恢复权限必须在 PR 中写明发生了什么变化。这能减少权限来回跳动，但示例脚本没有实现连续样本、冻结状态或人工恢复流程，只会更新累计均值和档位。

权限还应落实到文件结构。原文建议拆成 docs/draftable/ 与 docs/human/，让起草任务只拥有前者的写权限，发布时通过 ./scripts/build-docs.sh 合并：

cat docs/human/*.md docs/draftable/*.md > site/guide.md

这样，--protect 才成为第二道防线。采用前还需要确定章节拼接顺序，不能默认两个目录分别排序后就符合原页面结构。

我的判断

我认可用返工记录调整自动化范围。它让讨论落到维护者真正付出的劳动上，也允许团队承认：模型适合写某些章节，另一些章节长期交给人更划算。

但这套方案目前属于经验之谈。作者没有提供引入前后的耗时对照，也没有验证 0.15、0.40 能否迁移到其他团队。直接维护一份人工负责章节清单，是更简单的替代做法；只有章节足够多、多人协作且反复争论边界时，持续记账才可能抵得过维护成本。

示例实现也不能直接当成完整门禁。它使用 Python 标准库、difflib.SequenceMatcher，并设置 autojunk=False，但标题解析只覆盖 H2 到 H4，slug 规则只保留英文字母和数字，中文标题可能生成空 ID。它没有实现别名映射、基准提交校验、自动读取档位保护章节。原文展示的 FENCE 正则还出现了异常换行，运行前需要核对。

数据偏差同样明显。只记录合并草稿，会漏掉被直接丢弃的失败尝试；重度润色会抬高比例；短于约 80 tokens 的章节容易大幅波动。作者建议短章忽略或合并统计，并每季度对已退出自动起草的章节做一次隔离试写，避免永远失去重新评估的机会。

作者说自己把夜间任务放在 MonkeyCode 的免费服务器选项上，用免费模型访问完成起草，并披露文章属于该产品的推广合作。这个部署经历可以参考，但原文没有给出资源额度、稳定性或成本对照。

能拿来做什么

• 对有固定章节的前端组件库或 Node 服务文档，先人工抽查几组草稿与合并结果，确认高改写比例确实对应额外劳动，再决定是否建立台账。
• 在日常 AI 文档任务中保留草稿、基准提交和对应的接受版本，同时记录被丢弃的草稿，避免台账只统计成功样本。
• 将长期返工的章节移出模型可写目录，并独立保留正确性审核。auto-draft 只代表允许起草，不能作为发布批准。
• 如果只有少量页面，直接列出人工负责章节即可。对于法律、认证文档，没有稳定标题的页面，以及从源码注释生成的文档，作者也明确建议跳过这套流程。