文档批量修改的 dry-run，怎样才值得人工看？
文档批量修改的 dry-run 应展示将改什么、依据什么、哪些内容保持不变，以及实际执行还需要核对什么。只有一个“未写入”标志，并不能让人判断修改方案是否正确；预演的价值来自可审阅的差异。
把动作计划变成可阅读的修改单
以替换一组项目文件中的合同主体名称为例，预演应列出目标文档、匹配位置、原文、拟替换内容和匹配数量。正文中的签约主体、历史案例引用和附件文件名可能出现同一家公司名，却不一定都要改。只展示“找到 87 处”会掩盖语义差异，也无法判断漏改和误改。
可以按用途分组：明确适用的目标、需要人工判定的引用、没有找到的必改字段。每组提供少量上下文，并允许定位原位置。涉及表格时显示行列标识和业务键，不要只给不稳定的行号。不同格式文件应展示各自可用的结构证据。
预演也要经过真实的校验路径
理想的实现让预演与正式执行共用参数解析、目标解析和业务校验，只在最后一步停止写入。若预演用一种搜索算法，正式执行改用另一种匹配方式，预演通过就不具有预测价值。工具 Schema 只约束输入形状，语义检查和目标解析仍需要接入真实服务。
| 预演结果 | 应该怎么处理 |
|---|---|
| 唯一目标、原值符合 | 进入拟修改列表 |
| 多个相似位置 | 保留歧义，补充定位信息 |
| 原值与要求不一致 | 重新核对任务依据 |
| 文件不可读取 | 记录缺口，不记为无须修改 |
让预演结论绑定具体输入
一张修改单至少带上生成时间、文件版本或内容摘要、工具版本和计划标识。正式执行前重新读取必要条件，确认对象与预演时一致。对不能获得可靠版本的接口，可以采用目标内容比对，但要如实说明这种保护的边界，不将它描述为服务端事务保证。
例如用户确认的预演写着“只替换正文中两处名称”，正式执行时却发现四处匹配，应重新生成计划，而不是沿用旧结论扩大范围。确认一个方案不等于确认任意后续变化。这里的重点是保留修改意图与真实输入之间的联系。
怎样判断预演报告太长了
先给出总体数量、关键风险和少量代表性差异，再提供可展开的逐项清单。不要把几万行原始日志当成审阅材料，也不要只给一个绿灯。对相同模式的修改可以分组展示，但例外项必须单独可见，且执行回执仍应逐对象记录。
这套方法适用于通过 API、CLI 或编辑器自动化修改企业文档的任务。石墨等产品是否具备原生预演、版本核对或批量事务能力，需要按实际接口验证。缺少原生 dry-run 时，也可以先构建只读计划器；不能给写操作换一个参数名就声称已经有安全预演。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。