文档改写后，如何揪出悄然变化的需求

把「必须禁止」改成「可以」，把 24 小时改成 48 小时，再删掉审批条件，句子更短了，工程师要实现的规则却变了。AI 改写需求时，语言变顺与含义不变，是两件需要分别检查的事。

Meaning Diff 尝试给普通 diff 加一轮定向检查：把数字、义务词、否定词和条件的变化集中呈现。它不保证理解全文，也没有公布真实语料上的准确率，但提供了一种可复现的办法，帮助评审者找到需要停下来核对的位置。

改写后的句子，到底改了哪些规则

原文用两句话说明问题：第一句要求访客在 24 小时内不得再次分享文档，除非所有者批准；第二句变成访客可以在 48 小时内再次分享。

这次改写同时涉及义务强度、否定表达、时间数量和审批条件。它们可能分别影响权限判断、时间窗口与审批流程，不能只当作一次措辞调整。

普通 diff 已经包含这些变化。难点在于，它们往往夹在标点修正、段落调序等修改中，评审者未必会逐一追问。

Meaning Diff 比较两个 Markdown 文档，先对齐句子，再报告数量、义务词、否定词、句尾条件，以及句子的新增和删除。报告保留修改前后的文本与源文件行号，方便回到上下文核对。

它负责提供值得追问的证据，规则是否允许改变仍由人判断。

示例能跑通，但句子对齐也会出错

工具要求 Python 3.11 或更新版本，没有第三方运行时依赖。下面是原文提供的完整命令，用随项目附带的规格生成 Markdown 和 JSON 报告：

git clone https://github.com/asadani/meaning-diff.git
cd meaning-diff
out_dir="$(mktemp -d)"

python -m meaning_diff compare \
  fixtures/sharing-before.md fixtures/sharing-after.md \
  --format markdown --out "$out_dir/review.md"

python -m meaning_diff compare \
  fixtures/sharing-before.md fixtures/sharing-after.md \
  --format json --out "$out_dir/review.json"

要留意两条比较命令的退出状态：示例都会返回 1，表示产生了待审查信号，并非运行故障；无效输入、文件无法读取等问题使用状态 2。

随附示例得到 5 对发生变化的句子和 7 个信号。其中还有一处无害的改述，被识别为变化句对，却没有触发已配置的信号。完全未变的句子会被省略，围栏代码块不参与正文比较。

工具先用归一化后的完全匹配建立锚点，再在替换区块中，根据词汇相似度配对剩余句子。大白话解释：先找确定对应的句子，再给其余句子寻找文字上相近的搭档。对齐阈值可以配置，默认是 0.45。

这个办法容易检查，也容易解释，但大幅改述可能匹配不上，用词相似的无关句子也可能配成一对。未匹配文本仍会作为新增或删除展示，报告还保留对齐方法和分数，供评审者检查。

信号的优先级只是固定的审查顺序提示，并不是经过测量的风险概率。

我的判断

我认可它把检查范围收窄到具体模式。对于权限、时限、操作条件这类规格，集中查看数字和否定词，能给评审提供明确入口。项目采用 MIT 许可证，源码包含报告结构、示例修订和比较算法，团队可以检查它究竟在检测什么。

但不能把「没有信号」当作「含义没变」。数字变化可能是有意纠错，未触发模式的改述也可能改变业务规则。句子对齐本身还会引入误配和漏配。

当前证据支持它能复现指定模式检查，尚不足以证明它能降低真实团队的漏审率。

作者没有建立带标注的真实语料准确率，也没有给出普通 diff 与叠加报告后的对照结果。原文中的案例是演示，文章也披露使用了 AI 辅助起草。

与再找一个模型判断改写是否忠实相比，这种方法的优势是规则可查、结果可定位；局限是覆盖范围受模式约束。它适合作为已有评审流程的一道补充，完整 diff 和源文档仍要保留。

能拿来做什么

• 审查前端或 Node 服务的权限、分享时限和审批需求时，可以用它集中核对数量、禁止条款与条件的变化，再回到完整 diff 确认上下文。
• 让 AI 精简需求或操作文档后，保留原稿并生成报告，逐项确认被标出的规则变化是否经过业务认可。
• 接入脚本时，应区分退出状态 1 和 2，把待评审信号与输入、读取故障分别处理。
• 正式引入团队前，选几次真实修订，人工标出必须发现的变化，对比普通 diff 与附加报告的漏审、无关提示和阅读成本，再决定是否长期使用。