手机端先把条款录进去、电脑端再对着改，麻烦通常不在打字量，而在两端的“条与条对应关系”断了。只要手机端和电脑端各自按自己的顺序推进，改到中段就会出现两种典型情况：某一条的文字被贴到了相邻条款里，或者某一条整段没被打开过却谁都没发现。比较稳的做法是把编号当作唯一对齐键：录入阶段只记录、不下判断，修改阶段严格按编号递增推进，收尾时再用编号连续性反向查漏。
这套流程适合条款数量在十几条到上百条、两端不能实时同步的合同修改场景。要点是：手机端只录原文并带上固定编号，电脑端按编号顺序逐条比对并标记差异，改完后反向核对编号是否连续、有无重复。编号一旦中途变动，两端就要重新对齐。它把“漏改、改串”这类结构性问题变得可检查，但替代不了人工逐条确认，也不保证语义层面的准确。
给每条条款编一个固定编号
编号的作用是让两端能一条条对上，而不是给人看的装饰。建议在录入开始前就把整份合同的编号规则定死，中间不再调整规则本身。
编号规则示例：单层合同用 CL-001、CL-002 这样的流水号，三位数足够覆盖大多数合同；有章节层级的用 1.2-01、1.2-02，前段对应章节号，后段是条款序号。需要临时插入新条款时，用 CL-001-1 或 CL-001a 挂在原编号后面，不要重新给后续条款编号，否则两端编号会整体错位。
编号写在条款正文的上一行，或条款标题行的最前面，独立成段。不要写在括号里、脚注里或页边，这些位置在复制、导出时容易被丢掉。
CL-001
甲方应在收到货物后 5 个工作日内完成验收。
CL-002
验收不合格的，乙方应在 3 个工作日内书面答复处理方案。编号一旦分配给某条条款，就跟着这条条款走，修改内容不改编号，删除条款时编号也只标记为作废，不回收给其他条款使用。
手机端录入时只做记录不下结论
手机端最容易出的问题是边录边改：看到一句话觉得不通顺就顺手改掉，看到缺内容就自己补上。这样一来，原始文本和你的判断混在一起，电脑端比对时已经分不清哪些是合同原文、哪些是你改过的。
录入格式建议固定成“编号 + 原文 + 位置 + 状态”四段，每条之间空一行，方便后面按编号切分。
CL-001
原文：甲方应在收到货物后 5 个工作日内完成验收。
位置：第 2 页第 3 段
状态：已录入每条必填内容：编号、条款原文（照抄，不做同义替换、不做语序调整）、位置标识（页码、章节或截图编号）、状态标记。录入人和录入时间可选，但如果同一份合同有多人分头录，建议带上，便于后面追溯是谁录的。
录入完成的判断标准可以定得具体些：编号在同一份清单里连续、每条都有非空原文、没有把“待确认”“此处存疑”这类判断性文字写进原文段落、没有只录编号不录内容的空条。手机上录完先导出一次清单，用文本搜索确认没有遗漏编号，再进入电脑端。
电脑端按编号逐条比对原始文本
电脑端的任务是比对，不是重排。比对顺序从最小号开始，按编号递增往下走，不跳号、不凭印象挑着改。中途如果需要回头改某一条，记下编号，等这一轮走完再统一处理，避免两处同时改动导致编号和内容错位。
差异标记方式建议统一：原文保留不动，改动写在原文下方或紧随其后，用固定的行内前缀区分，例如 [原] 表示合同原文、[改] 表示拟修改后的表述、[增] 表示新增内容、[删] 表示建议删除并附理由。如果使用带 diff 功能的编辑器，也建议先关掉自动合并，逐条看过再接受改动。
CL-002
[原] 验收不合格的，乙方应在 3 个工作日内书面答复处理方案。
[改] 验收不合格的，乙方应在 3 个工作日内书面答复处理方案，逾期视为认可甲方意见。发现不一致时的处理动作分三种：如果只是录入错字，改原文并标记 [原] 已更正；如果是条款缺失，按插入编号规则补录，不要占用已有编号；如果是手机端多录了不存在的条款，标记为作废并写明依据，不直接删除，留痕比删干净更有用。
改完后反向核对编号是否连续
正向改完不等于改全了，还要反向走一遍，专门查漏条和重复条。
核对步骤：把最新清单里的编号单独抽出来排序，确认从起始号到结束号没有断档；再统计每个编号出现次数，确认没有同一个编号对应两段不同内容。抽出编号可以用简单文本处理完成，例如把清单导出后只保留编号行，再排序去重比对。
grep -o 'CL-[0-9]\{3\}' 清单.txt | sort | uniq -c常见漏项类型：跨页条款（上一页末尾和下一页开头容易被当成两条或漏掉一条）、附表和附件里的条款、括号内的补充说明、手写或口头补充的约定、以及手机端录入时因为屏幕滚动而被跳过的条款。这些位置建议在核对时单独列一份待查清单。
核对记录留痕方式：在版本目录里放一个核对说明文件，写明本次核对的编号范围、发现的漏项与重复项、处理动作、核对人和核对时间。记录本身不需要长，能让人两分钟后看明白“哪些编号查过、哪些没查过”就够了。
修改前后各存一版
没有版本留痕，后面出现分歧时只能靠记忆，而记忆在条款这种细节上并不可靠。
两版的命名规则建议统一成“合同名_版本号_来源端_日期”，例如 采购合同_v1_手机录入_20250101.txt 和 采购合同_v2_电脑修改_20250102.docx。来源端写清楚是手机录入还是电脑修改，日期用录入或修改当天，不写“最终版”“定稿”这类无法排序的词。
存放位置建议放在同一个合同目录下的 versions 子目录里，两版并列，不互相覆盖。区分版本的方法：v1 设为只读，作为原始录入的底稿；v2 可写，作为修改稿。正文里也可以加一行版本标记或页眉版本号，导出 PDF 时能直接看出是哪一版。需要继续修改时递增版本号，不要在同一文件名上反复覆盖。