先明确任务与结果
原材料B01收到12箱、损坏3箱，可用9；B02收到8箱、损坏1箱，可用7，总可用16。只补Usable与总计，Dispatch的review/hold保持不变。原生文件支持不是库存判断、发货授权或自动Git同步。
近期变化解决的是载体，不是验收责任
Google于10月26日的公告说明Docs可原生编辑.md，Drive可预览，并提供协作与历史记录；公告面向Google与Workspace账号。这项能力的公告日期是10月26日，本文提供后续的审稿实操。
本文不测试Google账号、不验证你所在组织的界面，也不承诺特定AI订阅或额度。若账号中看不到相应入口，可用普通文本编辑器审稿；核心检查方法不依赖这个新界面。
把文档当作协作副本时，要先记源文件版本与编辑范围。不要默认Drive上的修改会自动回到本地仓库；正文只讨论拿回最终.md之后如何检查，不包含任何仓库授权或自动同步操作。
明确原材料和允许改动
以下是原创教学材料，单位统一为箱，损坏箱全部排除，未引入预留、补货或可修复库存。Dispatch表示原流程中的人工状态，不随算术自动改变。
需求只有三处：两行Usable和总可用。Batch、Received、Damaged、Dispatch与行数都要保持。这让“文字更流畅”的要求不会悄悄扩大成业务决策。
# Batch handoff
| Batch | Received | Damaged | Usable | Dispatch |
| --- | ---: | ---: | ---: | --- |
| B01 | 12 | 3 | pending | review |
| B02 | 8 | 1 | pending | hold |
Total usable: pending
仅编辑下列Markdown的Usable单元格及Total usable。规则：Usable=Received-Damaged，所有数均为箱；总计只加Usable。保留Batch、Received、Damaged、Dispatch、两条记录和Markdown结构。不要把review/hold改成ready。先列计算与计划差异，再提供完整修改后.md。不能从本材料判断发货。
# Batch handoff
| Batch | Received | Damaged | Usable | Dispatch |
| --- | ---: | ---: | ---: | --- |
| B01 | 12 | 3 | pending | review |
| B02 | 8 | 1 | pending | hold |
Total usable: pending
先看语义差异，再看表格有没有歪
下面的错误稿由编辑刻意设计，不是某模型真实输出。它把收到箱数当作可用，又擅自把review/hold变为ready。即使Markdown结构完整，也同时违反了计算和编辑权限。
参考稿按12−3=9、8−1=7、9+7=16得出。20是收到箱数总量；4是损坏箱数总量，20−4=16提供独立复核。状态保持原文，不因可用数大于零就推断允许发货。
看起来整齐的稿件仍可能越界
# Batch handoff | Batch | Received | Damaged | Usable | Dispatch | | --- | ---: | ---: | ---: | --- | | B01 | 12 | 3 | 12 | ready | | B02 | 8 | 1 | 8 | ready | Total usable: 20
# Batch handoff | Batch | Received | Damaged | Usable | Dispatch | | --- | ---: | ---: | ---: | --- | | B01 | 12 | 3 | 9 | review | | B02 | 8 | 1 | 7 | hold | Total usable: 16
拿回.md后，按同一份参考答案验收
在协作副本中标注疑问和确认的人；如果使用Docs原生Markdown，核对.md标识及具体编辑文件。下载或拿回最终原文后，用文本视图检查表头、分隔行、两条Batch和Dispatch，不能只看截图。
将源稿和最终稿逐行比较：B01的Usable为9，B02为7，Total为16；received/damaged原值没有被重写。换行或空白变化可以单独记录，不应掩盖状态和值的变化。
再用Markdown结构预览方法看表格与标题是否仍可读；计算保留原始数字和算式。文件仍叫.md，不代表业务含义自动保真。本文提供的是人工可复算流程，未运行Docs或AI的实际回传测试。
需要同时交接批注时，可参考文档批注与导出核对，另行记录哪些审阅信息需要保留。
接受交接稿的四项条件
- 源版本与允许编辑范围可追溯。
- 两批箱数9/7、总16，有原材料和独立20−4核对。
- Dispatch仍是review与hold，未新增发货结论。
- 最终原文及呈现都核对，问题与确认记录留在协作流程。
如果业务规则更复杂，先扩大材料而不是让AI补猜
若损坏箱可修复、单位不同或还存在预留，当前16不能直接代表可承诺发货量。先补业务字段和时间点，再定义新的计算任务；不要只把提示词写得更长却不给原材料。
存在真实库存事件时，可接着读在库与预留账本，把状态与数量拆开。本文的下一步是把经核对的.md交给原负责人，不是让协作工具替人批准发货。
