顺理成章的代价 — AI 深度参与的重文档项目复盘

一次 AI 深度参与的重文档项目复盘

这篇文章也是 AI 替我们写的。

① 33 天 / 9000 行法律文本 / 137 次修订；② AI 根据我们整个工程目录的 git history（提交日志），形成了 15,000 字的复盘和方法论；③ 我们再让 AI 脱敏改写为适合公开发布的形式。欢迎同行进行更深度的交流。

我们这个项目里最昂贵的错误，都出现在看起来最顺理成章的那一步。

这是一个多方参与、长期迭代、文档高度相互依赖的重文档项目——合同起草、多轮法务审阅、外部专业方编制与反馈、业务方参数回填、最终定稿锁定，几个环节交叠推进。AI 在其中深度参与：起草、审阅意见处理、占位符管理、文档渲染、跨文档一致性校验。

走到今天，我们想把这一路的几个关键判断点整理出来。不是成功学，也不是反面教材——是一份”带温度的骨架”：每个阶段做对了什么、做错了什么、回头想明白了什么。希望对正在做类似项目的同行有用。

五章，按我们走过的顺序：启动、奠基、起草与审阅、外部协作，以及 AI 协作的边界。

第一章 · 启动：我们一开始以为”结构”是个安全问题

项目启动时的第一件大事是定”目录怎么分”。我们最初把它当作一个”安全问题”——只要结构分得合理，后面就不容易出错。后来才发现，启动期的结构决策，真正的风险不在”分得对不对”，而在”什么时候分、分得多细”。

一次顺理成章的目录重组

做对了： 我们在启动期就明确了”三阶段”框架——起草阶段、对外文档准备阶段、签约定稿阶段——每个阶段的目录组织策略不同。这让后来的重要决策（什么时候锁定条款、什么时候 fork 出子项目副本）都有了稳定的锚点。

做错了： 当项目结构发生变化、需要按子项目维度切分时，我们的第一反应是立刻在文件系统里 fork 出多份副本——一份主版本、几份子项目版本，并行维护。这件事当时看完全顺理成章：业务上分出了几个子项目，文件系统上对应复制一套，直觉上没毛病。六天后做审计，我们发现：同一条款的通用化改进只在某份副本做了，没有回写到主版本。副本之间出现隐性漂移。整体回滚，删除 fork，改用”统一主模板 + 变化维度参数化”。

反思： 业务上的多实例，不等于文件系统上的多副本。业务分叉是逻辑概念，文件系统分叉是维护负担——提前承担这个负担，就是在给自己埋双轨维护的坑。正确做法是把”变化的维度”建模成参数（占位符、配置、变量），文件系统保持单源，直到业务实例真正稳定（对我们来说是签约那一刻）才实际 fork。

把变化当变量，不是当副本

做对了： 回滚之后，我们把子项目之间的”规模参数、覆盖范围、关键字段”这类差异抽取为占位符，在合同主模板里显式留白。不同子项目共用一份模板，差异通过一张参数表注入。一份模板 + 多份参数，极大降低了维护成本。

做错了： 在我们意识到参数化这条路可行之前，有一段时间我们直接把具体值硬编码在模板里——全量规模数字、覆盖范围列表、里程碑日期。等业务变了，这些硬编码数字成了技术债：散布在十几个文件里，清理要花几轮迭代。

反思： 起草时的”先写死一个值，后面再改”是最容易违约的口头承诺。”后面”往往不会来，直到某次对外交付那一刻它回来咬你。只要是”现在还不确定的值”，立刻占位符化，不允许硬编码过夜。

内容隔离是一种保护

做对了： 项目里有一份独立协议，和主合同体系的商务逻辑完全不相干。我们在启动期就把它放在独立目录、独立维护，并在项目文档里明写”这份协议与其他合同内容隔离：编写其他合同时不得引用它的任何条款，反之亦然”。这避免了”这个措辞在这边合理、在那边一看就是冲突”的语义污染。

反思： 在多合同项目里，辨识”哪些合同必须隔离”和写出”怎么组织目录”同样重要。边界没写清楚，后续每个起草决策都可能被错误地跨边界参考。

启动期的结构决策，风险不在”分得对不对”，而在”什么时候分、分得多细”。业务上的多实例，不等于文件系统上的多副本。

第二章 · 奠基：规则写得晚一天，代价要多还十天

项目启动两周后，我们就开始写合同条款了。起草的节奏很快，但有一类工作一直被推迟——我把它叫做”治理工件”：单一权威数据源、术语规范、违禁词清单、跨合同引用规则、给 AI 看的元规则。这些都是”不直接产出合同条款”的元工作。每次都觉得”先把这版条款写完再做”，每次都被推迟到下一轮。

代价比我以为的贵得多。

治理必须先于交付

做对了： 项目后期，我们终于建立了一套 SOT（single source of truth，单一权威数据源）体系——编号连续的数据子表，每份注明来源、有效期、被哪些下游引用。当数据与合同起草、对外交付物、下游其他文档出现冲突时，SOT > drafts > references 的优先级规则给出唯一答案。建立之后，”发生冲突时该听谁的”这件事不再是争议。

做错了： 项目结构发生过一次较大的重组，新增了几个子项目维度。SOT 的建立却滞后于这次重组整整十天。这十天里，发给外部协作方的资料中既有”项目全量数据”也有”某子项目切片数据”，没有粒度标签。外部方据此编制的首版交付物里，多处把全量聚合值误用为切片值——两个层级的数字差距很大。后来要逐处清理，再走一次外部流转。

反思： 治理工件是用来让组织对抗自己的惯性的。惯性就是”先把今天这版写完”。但每一次业务结构变化、每一次对外发资料的关口，都是治理必须升级的触发点——不升级，等于默认把错误外送给协作方，然后等他们带错误回来，再花十倍时间清理。

让元规则承担安全网

做对了： 我们后来把一类规则写进 AI Agent 的元规则文件（CLAUDE.md / AGENTS.md）——这些规则不是”某一次指令”，而是”每次 Agent 干活都自动遵守”的协议：条款编号必须用阿拉伯数字 N.N 格式、占位符不得嵌套在粗体内、修改 SOT 必须同步检查下游引用清单。规则到位后，一类反复出现的小错误基本消失。

做错了： 很长一段时间，我们缺少”安全网类”规则——zombie 文件（用完没删的临时文件）、失效的 SOT 版本（被新版替代但仍在被引用）、零散的版本化文件、手头的硬编码技术债。这些问题不是不知道，是没有自动触发的检查规则。靠人眼扫描必有遗漏，熵缓慢增加。

反思： 让 AI Agent 长期稳定工作的秘诀，不是每次给它详细指令，是把共识写进元规则、让规则自己触发。规则承担三种职能：安全网（防已知陷阱）、同步网（变更时自动联动下游）、工具前置（必然高频的流程提前工具化）。这三件事每省一件，未来就多一次”本可避免”的事故。

跨边界的信息，要放在更高的高度

做对了： 我们到中后期把一些跨合同共享的信息——成本测算模型、时间表、跨合同引用索引——从某个子合同目录上提到项目根或一个专门的元目录。路径稳定后，几个合同同时引用这些文件，谁都不用维护它，只需要引用。

做错了： 早期这些跨合同信息散在各个子合同目录里。一个合同的财务测算表放在它自己的子目录，另一个合同引用它时跨路径引用。一旦文件挪动，下游引用失效，没人知道。

反思： 如果一份信息被多于一个合同引用，它就不再属于其中任何一个合同——它属于项目本身。应该放在项目根或元目录。这是组织信息的”就近原则”的反面：不是”放在最先用到它的人身边”，而是”放在所有用到它的人都够得着的最高处”。

治理写得晚一天，代价要多还十天。规则不是文档，是让组织对抗自己惯性的工具。

第三章 · 审阅：工具是痛出来的，本不该是痛出来的

项目走到第二个月，多轮法务审阅和外部专业审阅开始涌入。一份合同的修订稿返回时可能带几百条修改和批注——有接受的、有拒绝的、有需要转成具体条款改写的。这个阶段我们建了一系列工具：决策表、修订提取、引用校验、版本对比。

这些工具事后看都对。但它们都是痛出来的——不是提前规划的，而是每次压力到达不可承受的那一刻才开始建。

每一个工具都先痛一轮

做对了： 建立起来的审阅处理工具链把一轮审阅固化为四步：从修订稿提取原始修订 → 生成决策表 → 用户逐条决策 → 合并回源文件 + 输出反馈报告。每一轮独立归档。这个流程稳定下来之后，后续每一轮审阅的处理时间大幅下降。

做错了： 工具链是在第一轮法务审阅返回、手工处理不可持续的那一刻才开始建的。那一轮处理相当痛苦。类似地，交叉引用校验工具是在发现多处条款引用编号错位之后才建；版本对比工具是在经历了一次”累积修订痕迹淹没关键错误”的事件之后才建。每一次”先痛一轮”都在该次交付上留下了可见的损伤。

反思： 有些流程是”必然高频”的——法务审阅、交叉引用校验、版本对比、参数回填——做这类项目的人都知道它们一定会来。识别这些流程、在它们到达之前就设计好数据结构（至少让首轮手工的产出能被未来工具直接消化），是元治理的一部分。工具可以是反应式的，但工具所处理的数据结构不该是反应式的。

让 AI 只改被请求的那一处

做对了： 我们设计了”决策表”机制——AI 从修订稿提取修改建议、分类、给出理由，用户对每条 accept / modify / reject。这条边界把 AI 做重体力活（提取、分类、建议）和用户做关键判断（法律决策）区分清楚。既释放了人的时间，又保留了决策权。

做错了： 在没有明确约束的情况下，AI 起草或修改条款时有一种不易察觉的惯性——”顺手”加一条补充说明、”顺便”把相关条款也对齐一下、”完善”一下措辞让它更像一份法律文件。这些”顺便”单独看每一条都不算错，但合在一起意味着合同里多出了未经用户审议、未经对方谈判的条款。给未来埋坑。

反思： AI 是高效的文本生成器，但在合同场景下，”多生成的文字”是负资产。每一件 AI 顺便做对的事，都是一块你没来得及审议的风险。 正确的约束是”最小扰动原则”：修改点 A 时不扩展到 B；需要扩展时，AI 必须先陈述理由请求人确认。这条规则要写进元规则，让 AI 每次自动守住，不靠人每次记起来。

决策表是人机的边界线

做对了： 决策表从一开始就设计为两层——AI 给出建议 + 理由，用户给出决策 + 说明。每轮审阅结束还会生成一份”给审阅方的反馈报告”——你提的哪些被采纳、哪些没采纳、理由是什么。这让外部审阅方感到意见被认真处理，也沉淀了”某条款为什么没改”的历史理由。

反思： 在重文档项目里，人机边界比 AI 能力本身更重要。边界清楚了，AI 是高效伙伴；边界模糊了，AI 是隐蔽的风险源。决策表是我们目前见过最有效的边界形式——它逼着每一条修改都经过人的一次”显式过滤”。

工具可以是反应式的，工具处理的数据结构不该是反应式的。每一件 AI 顺便做对的事，都是一块你没来得及审议的风险。

第四章 · 外部协作方：他们的工作习惯是我们最大的盲区

项目的第三个月，外部协作开始密集：法务审阅、外部专业审阅方、业务方参数回填、合作方反馈。每一方有自己的工作习惯、交付格式、反馈节奏。我们起初没有把”外部方工作习惯”当作一个需要管理的变量——我们以为只要自己做好、材料发到位，对方自然会按流程处理。

这个假设代价极大。

从接入第一天起约束对方工作流

做对了： 项目后期，对每一类外部方我们都明确了一份”接入协议”——用什么格式交流（Word tracked changes / markdown diff / 填表 / 决策表）、反馈的粒度、交付节奏、权威源归属。协议清楚之后，每一轮外部交付都能被标准化处理。

做错了： 其中一类外部协作方，他们习惯”每次修改后把整份 Word 重新发回”——不用 tracked changes，每版生成一个新版本文件。版本号从 V1 一路膨胀到 V17。每版的增量不可见——你拿到 V17 不知道相对 V16 改了什么，要做版本对比才能拆解。事后补救：我们做了一次”V17 vs 早期版本”的结构对比，发现 V17 的某个重要章节比早期版本少了约 200 行内容——整段消失了，没人察觉。

反思： 外部方的工作习惯是这类项目被最低估的重力。你不能指望对方按你的节奏工作——除非你在接入第一天就写进合作协议里。修改方式、反馈格式、交付节奏、权威源归属——这四件事都要在”正式开始工作”之前约定死。写不进协议的，就是你事后要自己清理的漂移。

前置差异清单防模板污染

做对了： 在后期几次对外协作启动之前，我们会发一份”项目特征差异清单”——列出本项目与同类历史项目的 7 到 10 条关键差异（术语、责任边界、规模维度、合规属性等）。对方编制前看到这份清单，基本能避开”用历史模板默认值”的陷阱。

做错了： 最早的一次外部编制，我们没有发差异清单——以为”他们是这行老手，看材料就知道”。结果对方基于某历史同类项目的模板编制，首版交付里多处出现”历史项目特有但本项目完全不适用”的术语和条款（责任划分的默认归属、某些专业术语的默认含义）。首轮审阅逐条清理这些残留花了不少时间。

反思： 外部协作方复用历史模板是效率优选，不是他们的错。但对方不知道”本项目哪些默认值必须替换”——这个差异知识只在我方这边。不把它前置交底，就是把清理成本后置到自己这边。 一份三页的差异清单，能省掉整整一轮审阅的修正工作。

我方保留权威源，对方产物是派生

做对了： 后期我们把对外交付物的”权威源”明确为我方的 markdown 源文件——对方的 Word 产物经由版本对比工具转换为 tracked changes，回流到我方 markdown 做决策。合同条款一改，下次生成对外文档时自动吸收。

做错了： 早期我们以对方的 Word 为”权威源”——对方给什么版本，我方拆分保留什么版本。问题是对方在每版 Word 里带 tracked changes 混入修改，其中一次包含了一个关键的代号误改（把某个子项目的编号改成了另一个子项目的编号）。这个错误隐藏在累积的修订痕迹里，差点漏过审阅进入正式交付。

反思： 当你把对方的产物当作权威源，对方的每一个错误都可能成为你的错误。权威源必须在你能审计的地方。 对方的产物是派生——经过工具转换、经过决策过滤，再回流到你的源文件。这条原则看起来简单，但在早期”对方是专业方、用他们的产物为准”的默认假设下，很容易被忽视。

外部方的工作习惯是项目被最低估的重力。权威源必须在你能审计的地方。

第五章 · AI 协作的边界

前四章里散落着一些关于 AI 的观察。写这一章是为了把它们聚拢——对这类项目来说，AI 协作不是一个独立的技术话题，是贯穿所有阶段的方法论基石。

整个项目周期里，AI 承担了大量工作——起草、修订处理、占位符管理、文档渲染、一致性校验、审阅分类。回头看，AI 能做的远比我最初估计的多；但 AI 犯的错也比我估计的更隐蔽、更系统性。更重要的是——我们自己作为组织者犯的错，比 AI 犯的错多得多，而且多在同一层：没有给 AI 设定好协作的基础设施。

AI 的”顺便”是负资产

做对了： 通过决策表机制 + 最小扰动原则，我们把 AI 的工作收敛在”只做被请求的那一件事”。AI 给的是建议、附理由；决定权在人。这条边界让 AI 的高效和人的判断力能结合。

做错了： 早期没有明确约束时，AI 按”法律写作惯例”往往会在修改某条款时顺手加一段保护条款、扩展一下责任限定、对齐一下相邻措辞。这些”顺便”单独看不一定错，但合起来意味着合同里多了未经审议、未经谈判的内容。

反思： AI 的默认倾向是”写完整、写像样”——这是它作为生成器的本能。但合同不是越完整越好，是越精确越好。AI 默认保守不扩展，扩展需要显式许可。 这条规则要写进元规则，不靠每次人提醒。

AI 需要单源

做对了： 当信息都有唯一权威源，AI 的工作变得简单——它只在源上改，不操心下游派生。下次渲染自动吸收。

做错了： 早期有些信息没有明确的权威源——某个数字既在合同里又在对外交付物里，各自维护。AI 被要求”把这两处都更新”时，第一次改对了，第二次可能漏一处，第三次可能两处都改但改成了不同的值。没有单源，AI 的记忆是不可靠的。

反思： AI 的稳定性依赖它运行的环境的稳定性。给 AI 一个有单源、有边界、有明确依赖关系的工作环境，它表现得像一个可靠的初级专业人员；给它一堆双轨维护的文件，它表现得像一个善意但健忘的助理。

AI 需要变更传播视图

做对了： 项目后期我们开始建立跨合同的”下游依赖表”——某条 SOT 数据变了，需要联动哪些文件、哪些条款。AI 在处理变更时可以查这张表，不靠记忆。

做错了： 早期没有这张表，一条重要的权责边界调整需要联动 8 处条款（分布在多份合同、多种交付物里）。我们靠梳理、靠 AI 搜索、靠人脑回忆——每次都会漏一两处。

反思： 项目的知识是网状且时变的，不是线性文档。没有图状视图，变更传播就靠记忆，记忆是最不可靠的自动化。至少要有一张”下游依赖表”；更好的是用专门的图状工具维护节点间的关系和时间维度。

元规则和工具前置：AI 协作的基础设施

做对了： 到项目后期，元规则里写下的那些规则——最小扰动原则、条款编号格式、占位符约束、定稿锁定、SOT 同步清单——让 AI 变成一个”大部分默认就做对”的合作者。每加一条规则，就少一类反复出现的错误。

反思： 让 AI 长期稳定工作的关键不是”每次给详细指令”——那是把负担放回人的一边。关键是把共识沉淀成元规则，让 AI 自动触发。每一条写进元规则的共识，都是一份”不再需要人每次记起”的自动化。

在一个 AI 深度参与的项目里，工具建设不是”项目中发生的一件事”，是”让项目能发生的前提”。必然高频的流程——我现在的观点是：在首轮压力到达之前，就要设计好数据结构、约定好产物格式，即便首轮手工处理，也要让未来工具能直接消化历史数据。这是对 AI 协作的预付成本，也是”反应式建设”最好的解药。

给 AI 一个有单源、有边界、有明确依赖关系的工作环境，它是可靠的初级专业人员；否则它是善意但健忘的助理。每一条写进元规则的共识，都是一份”不再需要人每次记起”的自动化。

结语

回到开篇那句话：我们这个项目里最昂贵的错误，都出现在看起来最顺理成章的那一步。

事后看，”顺理成章”是一种危险信号。业务变了就 fork 副本，顺理成章；起草先写死一个值以后再改，顺理成章；先痛一轮再建工具，顺理成章；对方是专业方就让他们按自己习惯工作，顺理成章；AI 顺手补一段条款，顺理成章。每一件事单独看都不是错，合起来却构成这类项目里最系统的风险——因为它们都让下游的修正成本比前置的约束成本高十倍。

如果非要留下几条最通用的心法：

一、治理先于交付。规则、单源、术语、边界，这些工件必须在对外发资料之前到位。不是先做事再补规则，是规则先到位再做事。

二、单源优于副本。业务上的多实例不等于文件系统上的多副本。文件系统的单源，是你能审计一切的起点。

三、约束重于能力。尤其对 AI：默认保守不扩展，扩展需要显式许可。这条对人也同样适用。

诚实地说，还有一些事我们到今天也没做对。图状的知识管理工具还没真正上；zombie 文件、碎片版本、失效 SOT 的自动检测还在 TODO 里；元规则里的几条”同步网”规则仍然是承诺而不是代码。

这篇文字记录的不是”做好了”的经验，是”走到这一步的反思”。希望对正在走同样路的同行有用。

下次遇到”顺理成章”的时刻，记得停一下问问自己——它真的只是顺理成章，还是一次便宜的现在 + 昂贵的未来？