初稿到定稿中间必须过四道，缺一道就是交付风险
一、四条红线不是并列的，第三条决定前两条能不能落地
先说清本文的边界：我们只讨论这四道审核怎么落成系统里的状态与字段，不讨论任何法律问题的实体结论，也不涉及对具体条文的理解。条文怎么读，永远留在有资质的人那侧；系统能做的是记录”谁依据哪一版文件判的”。
来源那篇文章给出四条红线：输出不构成法律意见；不得把涉密材料输入公共平台，优先使用企业级受控环境；机器初稿须经事实核查、法律审核、风险评估、专业定稿四道才能交付；复杂诉辩仍需专业人员。四条摆在一起看容易误判成四件独立的事，实际上第三条是另外三条的执行载体。”不构成专业意见”要靠定稿节点由有资质的人签字来体现；”涉密不进公共平台”要靠四道之前的输入检查才拦得住；”复杂事项仍需专业人员”要靠第三道留出升级出口才有地方可去。
多数团队的现状是：前两条写在制度里，第四条写在口头共识里，只有第三条没写进系统。这就是风险来源——一条没有对应字段和门禁的规则，不构成控制存在证据。我们验收这类系统时不看制度文本，只看三样：状态机里有没有那四个节点、节点之间有没有无法绕开的边、每个节点的判定记录里有没有责任人标识。
二、四道要写成状态机，每道有输入、判定人和出口
| 道次 | 必须处理的输入 | 判定内容 | 判定人要求 | 出口 |
|---|---|---|---|---|
| 事实核查 | 初稿与随附材料清单 | 每条可核验断言是否有来源 | 可由项目成员承担 | 通过、退回、挂起 |
| 规范与专业审核 | 核查后的文稿与其依据文件的版本标识 | 依据是否现行有效、判断是否成立 | 须有相应资质类别 | 通过、退回、挂起 |
| 风险评估 | 前两道的结论 | 争议点、可能后果、是否需升级 | 项目负责层级 | 通过、退回、升级 |
| 专业定稿 | 第三道通过的版本 | 是否可作为交付件发出 | 定稿人实名 | 定稿、退回 |
逐道说字段。事实核查这一道最容易被写成”看一遍”，必须拆成核查对象清单：主体名称与标识、金额与数字、期间与到期约定、引用与附件指向、事实性描述。每一条断言在系统里是一条记录，要有来源字段，来源为空就不允许整道通过。发现不实时的处置不是”改一下”，而是带标记退回生成环节，标记写清是哪一条不实、以什么为据。
第二道在来源的语境里叫法律审核，搬到我们其他专业文书项目里，它承担的是同一件事：按现行有效的规范版本做专业判断。这一道要落两个字段——依据文件的版本标识，以及判定人的资质类别与有效期检查。系统不去存储任何实体结论，那是文档本身的事。
第三道要落三个字段：争议点列表、可能后果的分级、是否触发升级。升级出口必须存在并且可达，因为”复杂事项仍需专业人员”这条红线在系统里的唯一形态就是它。第四道定稿只落两样：定稿人签名与定稿时刻记录，外加定稿文件的指纹。
关键约束是边的方向：定稿节点的入边只有”风险评估通过”，不存在从生成直接到定稿的路径。人工改状态这个动作如果存在，必须留下改前的状态、操作人与理由，否则状态机就只是界面上的四个标签。
三、三态与退回原因分类，退回分布本身就是质量指标
每道都要有通过、退回、挂起三态，缺一个都会失真。只有两态的系统会把”等材料”伪装成”不通过”，最后谁也说不清卡在哪。挂起必须有负责人和到期提醒，无主的挂起是链路上最久的等待。
退回原因要固定成可枚举的分类，不能自由填写。我们的取值是：事实不实、依据版本过期、材料缺件、同一文档内口径冲突、超出可自动处理的范围、生成结构缺陷。这个分布直接反映生成环节的质量——如果”事实不实”占大头，问题在提示词与素材供给；如果”依据版本过期”占大头，问题在依据文件的版本管理；如果”生成结构缺陷”占大头，说明模板该改了。把退回原因做成周报里的一个饼图，比任何”模型效果评价”都更能指导改动。
还有一条硬约束容易被忽视：初筛与定稿不能是同一个人。初筛是生成之后第一遍快速筛掉明显不合规的部分，定稿是对发出负责。同一标识承担两者就是自证无效，整条责任链塌在一个人的判断上。实现上很简单：定稿校验时比对三个标识——生成请求发起人、初筛人、定稿人——出现重复直接拦住，不允许提交。
四、四种失控各有落点，其中排版那一类最容易被低估
来源点了四种失控：版本混乱、排版错乱、权限失控、文档泄露。四者都要有对应的工程落点，不能都推给”规范使用”。
版本混乱的治理只认一个唯一键：文档标识加版本号加状态。除此之外的一切标识方式都要禁用，靠文件名（一份文书后缀里写着”最终””真最终””定稿不改”）和靠人工记忆，是同类事故最常见的两条成因。导出件必须带版本水印或元数据，否则文件一旦落到外部，就再也回答不了”这是哪一版、和定稿那版差在哪”。
排版错乱的真实代价不是难看，而是内容差异被掩盖。只做字符级比对会漏掉最要命的一类：内容对但引用错位。条款编号与正文错位、附件索引指向另一份文件、金额与单位被换行拆到两处，这些在字符层面全都”一样”。做法是把比对拆成两层：断言级的集合比对（主体、数字、期间、引用指向各自成集合）与结构级比对，两类差异分开报，不许合并成一个”差异率”。
权限失控有四个落点，必须分开授权：谁可看、谁可改、谁可导出、谁可分享给外部。最小实现是按项目与角色双轴授权，导出与外发单独开权限并留证——记录谁在什么时刻把哪一版送到了什么范围。第四项最常出事，因为分享动作在界面上最轻，风险上却最重。
泄露面要三条控制同时到位：受控环境（涉密材料只进企业级环境，公共平台一律不进）、字段级脱敏规则（哪些字段在进入生成请求前必须替换或去除，规则可核对）、输入前的敏感标识检查与阻断（命中即拦下，不是提示）。这里要说一句不太中听的话：把”提醒用户不要输入涉密内容”当作控制，是不成立的。它把责任完全推回人，既没有留证能证明拦住了什么，也没有失败率可测，出事后唯一的产出是一条谁都没读过的弹窗记录。
五、提示词库与链路同版本，留痕要有一张最小字段表
来源给的落地建议里有团队提示词库这一条。它一旦成为团队资产，治理要求和配置文件一样重：版本、适用场景、被谁改过、改后效果如何。更要紧的是它必须与四道审核同版本演进——提示词一改动，生成物的错误分布就会变，核查项与风险判定项要跟着复核。具体做法是：一次提示词变更的提交，必须同时更新用例集与状态机的版本标记，三者不同步就不允许生效。
留痕的最小集，我们按这九列建表，一列都不省。
| 字段 | 内容 |
|---|---|
| 文档标识与版本 | 唯一键三段：标识、版本号、状态 |
| 请求发起人 | 生成动作的发起标识，不是文档作者 |
| 输入摘要 | 素材范围与清单，不存原文全文 |
| 模型与提示词版本 | 两项分开记，便于定位是哪一侧变了 |
| 四道结论与判定人 | 每道一行，含三态与退回原因 |
| 定稿文件指纹 | 定稿那一版的哈希，作为对外唯一凭据 |
| 导出与外发记录 | 时间、操作人、目标范围、版本 |
这张表能回答的三件事，恰好是出事后最常被追问的三件事：这一版是谁的输入生成的、四道有没有真的都过、发出去的是不是定稿那一版。
六、交付合同里该写三条，”准确率”那条不该写
把上面这套搬进合同，我们只写三条。第一，本产出须经专业方定稿后方可使用，机器生成的部分不构成专业意见——这句是红线一在商务文件里的唯一正确形态。第二，使用范围与保留期：委托方能在什么范围内使用这些文档与随附数据，材料保留多久，到期怎么处置。第三，责任归属：专业判断责任由定稿人及其机构承担，交付方承担的是”链路按约定执行”的工程责任，即四道都在、边不可绕、留痕完整、导出可追。
不建议把”准确率”写进合同，原因不是它不重要，而是写不出可执行的测法。准确率需要一个分母和一套判定标准：什么算一个错误、由谁来判、判定人需要什么资质、同一份文稿两次判不判得一致。这几项定不下来，条款里的百分比就是一条无法复核的违约线，双方对它的理解必然不同。可以写的是过程承诺：四道各有留痕、退回原因可按约定分类统计、定稿人可按资质档位指定、外发有记录。这些指标双方都能各自查一遍，不需要信任任何一方的自评。
也不要在方案里承诺”某类文书可以完全由机器定稿”。这句话在交付上等价于取消第四道，而第四道一旦取消，前面三条红线全部失去载体。常见文书类型的差别只在前三道要查多少条，不在定稿这一道能不能省——保密协议要核的对象少，备忘录的结构约束松，四道都还得过。
洹拓内部把这套状态机跑通之后，最大的变化不是效率，是事故的成本结构：过去一份文稿出问题要翻聊天记录找谁改过，现在从指纹往前倒推，四道记录加导出记录能在一小时内还原整条链路。对做专业文书系统的甲方来说，能被还原这件事，比生成质量本身更接近他们敢用的理由。