Contract Review Skill 采用审计：安全边界、评测缺口与试点清单

这份审计的对象是 nwwfewx/contract-review：一个 MIT 许可、GitHub 主语言为 Python 的公开工作流仓库。仓库页面记录创建日期为 2026-04-15，当前没有 release 或 tag；因此版本身份只能用提交哈希和获取日期锁定。README 明确它是 Codex、Claude 等代理使用的合同审查技能，提供流程和模板，不构成正式法律意见或律师服务。采用决定必须针对企业自己的事实、辖区、模型、文档系统和责任链作证，不能把仓库存在、星标数量或一次成功演示当成生产验证。

审计范围与判断口径

本审计只依据官方仓库的 README.md、SKILL.md、protocols、references、checklists、evals、scripts 及其目录说明；没有把第三方博客、厂商宣传或推测出的功能写成事实。检查的问题是“能否在受控边界内采用”，不是“如何安装”。每个结论分成可直接借鉴、需组织化改造、不可当作保证三类，并要求保留输入快照、执行版本、模型配置、输出、人工修改和最终签发记录。任何没有证据的字段都应标为未知，而不是用流畅语言填空。

可借鉴的 intake hard gate

README 的最小触发信息包括业务场景、立场、合同状态和合同文本或文件路径，这是很好的 intake hard gate。企业可以把它变成不可绕过的表单：场景必须从 general、asset_mgmt:issuance、asset_mgmt:investment:alternative、asset_mgmt:investment:standardized 中选择，立场写明甲方、乙方、中立或组织自定义角色，状态区分草稿、待签、已签、用印，文件则记录来源、版本、页数和哈希。缺少任一项时，Agent 只返回补充清单，不分析实质风险。网关还要拒绝空文件、扫描件无 OCR、密码保护、混合语言未标注和超过大小上限的输入。

canonical routing 与专项叠加

SKILL 的 canonical routing 思路值得保留：先由主模式决定检查路径，再对托管协议叠加 custody_overlay，而不是让用户随意拼接清单。组织应把路由表版本化，记录选择理由、适用法域、产品类型和排除项；同一份输入在重跑时应得到相同路由。路由器只能选择已审批准入的协议、reference 和 checklist，不能因为合同出现某个关键词就临时加载未知技能。模式不匹配、立场冲突或托管属性不明时必须停在路由阶段，生成“需人工分类”的状态。

evidence-backed finding 的最低证据

README 规定主表包含条款位置、风险描述、严重度、依据和建议改写，这为 evidence-backed finding 提供了可审计骨架。每一条发现至少绑定原文短引、文档坐标、适用规则来源、规则版本或发布日期、推理假设、置信度及人工复核结果。引用不存在的法条、把公司政策写成法律义务、或从标题推断全文含义都属于证据门禁失败。建议改写必须与原条款逐句对照，注明是风险缓解、谈判选项还是纯文字润色；没有依据时只能输出问题和待补证据，不得输出确定性结论。

固定交付与 fail-soft

delivery_only 默认只交付风险主表，dual_layer 才增加分析层，这是可直接复用的固定交付边界。企业模板应固定字段、排序、严重度定义、缺证据标记和签发区，避免每次对话改变格式。fail-soft 不是静默降级：解析失败、工具超时、模型拒答、引用缺失、文档坐标不稳定时，系统要保留已完成的可验证部分，明确列出未完成步骤、影响范围和人工动作，并把状态置为 NEEDS_REVIEW 或 FAIL。禁止把部分结果包装为“已完成审查”。

四门禁的采用方式

可将交付拆成 delivery、evidence、veto、style 四门禁。delivery 检查所有必填列、文件、版本和输出模式是否齐全；evidence 检查每个 P0/P1 是否有原文位置与可追溯依据；veto 检查法域不明、利益冲突、敏感数据、严重解析错误和未授权外发等停止条件；style 检查标题、编号、语言、修订标记、批注和版式是否符合交付约定。任何一门失败都不能以其他门通过抵销，门禁结果需写入审计日志并由指定角色确认。

哪些能力不能视为生产保证

仓库的 README 说明“独立可用”和“结果可交付”，并没有声明自动法律检索、实时法规更新、合规认证、模型准确率、数据隔离、服务可用性或生产环境验证。MIT 许可证只授予软件使用、修改和分发的许可，不承诺无缺陷、适合法律目的或承担损害责任。示例、模板和脚本证明的是仓库组织方式，不是企业合同上的正确答案。没有 release/tag 也意味着升级没有稳定发布通道；企业必须自行冻结提交、做差异审查、回滚演练和变更批准。

法律依据的生效状态与更新责任

references 或 knowledge_base 中的材料即使标有法规名称，也不能自动证明其在目标日期、辖区和行业仍生效。法务应为每条依据维护来源链接、公布机关、发布日期、生效日、废止或修订状态、适用主体、语言版本和最近核验人。遇到过渡条款、地方规章、监管问答、判例或合同约定时，必须分别记录层级和冲突处理。更新责任应落到法务知识库负责人而非 Agent 维护者；超过复核周期、来源无法访问或生效状态未知时，发现自动降级为“需人工核验”，不能生成“合规”标签。

合同数据分类与脱敏

把合同按公开、内部、机密、严格机密和受监管个人信息分级，并为每级定义允许模型、区域、日志和人工角色。先在入口做实体识别和字段清单，替换姓名、证件号、账户、价格、客户编号、密钥、地址和未公开产品名；映射表单独保管，不能随提示词发送。脱敏要保持条款逻辑，例如金额区间、日期顺序和角色关系不能被破坏，否则评测会失真。原件与脱敏件分别计算哈希，明确谁能回填、何时销毁临时文件以及备份是否同步删除。

留存、跨境与供应商边界

试点前写清输入、抽取文本、提示词、模型响应、DOCX 产物、人工批注和指标各自的留存期限；默认不把合同正文写进普通应用日志。跨境传输要核对数据主体、客户合同、行业监管、区域存储、子处理者和政府访问条款，不能只看模型供应商的营销承诺。供应商边界应列出代理运行时、模型 API、OCR、对象存储、监控和备份，每一项注明数据是否出域、是否训练、加密方式、删除证明、密钥控制和故障通知。任何边界无法证明时，P0 阻断真实合同。

模型与 Skill 供应链

采用时固定仓库提交哈希、Python 版本、依赖锁文件、代理宿主、模型名称和系统提示词版本，建立 SBOM 与恶意代码扫描。审查 SKILL.md、protocols、scripts 的读写路径、网络访问、子进程、环境变量、凭据和临时目录；脚本只能在隔离账户、只读输入和最小权限下运行。更新必须经过代码审查、签名或可信来源校验、差异摘要和回滚测试。MIT 不等于安全审计，公开仓库也不等于经过供应链背书；未审查的依赖、下载器和动态执行均应列为高风险。

提示注入与不可信文本

合同、附件、批注、网页链接和 OCR 文本都是不可信数据，可能包含“忽略规则”“泄露系统提示”或诱导执行命令的文字。协议层要把指令与材料分隔，明确材料只能作为待审证据，任何嵌入指令都不得改变路由、门禁、外发和签发。工具调用采用白名单，网络默认关闭，写文件和发送邮件需二次授权；输出要扫描是否泄露系统提示、其他客户文本或凭据。红队应加入可见和不可见 Unicode、宏提示、表格单元格指令、引用链接和伪造法条，验证注入不会提升权限。

evals.json 八个场景的真实含义

仓库提供 evals/evals.json 的八个场景，适合当作工作流回归的起点，但不能说八个场景全通过，也不能据此推算法律准确率。先核对每个场景的输入、期望路由、必有发现、严重度、证据坐标和交付模式是否可执行，再记录实际运行环境、模型温度、工具版本和人工评分。八个场景可能覆盖常见模式，却未必覆盖本组织的法域、语言、扫描质量、复杂附件、表格嵌套、利益冲突、恶意文本或已签合同变更；缺口本身应成为评测报告的一部分。

组织自己的黄金集、对抗集与回归集

黄金集由资深律师脱敏标注，保存条款边界、风险类别、立场、法域、证据、建议和“不应发现”的负例，并由第二位律师盲审一致性。对抗集专门制造近似但结论相反的条款、否定词、定义跳转、例外、附件冲突、日期边界、双语歧义和提示注入。回归集按版本冻结，任何模型、路由、reference、脚本或模板变化都必须重跑；新增事故样本进入回归集前先去除客户身份。指标既看召回也看误报，并按场景、严重度、文档质量和语言切片，避免总平均掩盖 P0 漏洞。

false positive 与 false negative

false positive 会制造谈判噪音、延误签署、削弱法务信任；false negative 则可能遗漏无限责任、数据外泄、自动续期、制裁、终止或管辖风险。每条错误都要区分模型误读、抽取丢失、路由错误、依据过期、标注分歧和人工疏忽，不能只调高或调低阈值。对 P0/P1 采用成本加权指标，例如关键风险漏检率、严重误报率、证据缺失率和人工覆盖率；设定上线阈值前，先用历史案件估算漏检造成的实际损失。

DOCX 段落定位与表格

输入若是 DOCX，必须同时保存段落序号、表格编号、行列坐标、页眉页脚、脚注、文本哈希和抽取器版本。仅凭页面号不稳定，重排版、字体替换或分页会改变坐标；交付应能从主表跳回原文，并允许人工复核上下文。表格中的合并单元格、隐藏列、重复表头、编号字段和跨页行要单独测试，不能把所有单元格拼成无序文本。抽取失败、图片文字未识别或段落哈希变化时，证据门禁自动失败。

Track Changes、Comments 与版式回归

如果输出包含修订或批注，回归测试要确认修订作者、时间、插入删除范围、批注锚点、批注线程和原文可见性。验证 Word、LibreOffice 和企业文档系统打开后是否仍可接受或拒绝修订，导出 PDF 后是否保留可读性，二次编辑后锚点是否漂移。检查字体、编号、表格宽度、页眉页脚、中文换行、方向性文字和附件目录；用渲染截图或 XML 差异保存版式证据。任何批注落在错误条款、修订丢失或客户无法打开，均为交付 FAIL，而不是样式小问题。

人工签发与 RACI

Agent 只生成草稿和结构化意见，不能代表律师签字或自动发给交易对手。RACI 至少包含业务负责人（提供背景和立场）、法务审查人（核验法律依据与结论）、信息安全负责人（批准数据和工具边界）、平台管理员（锁版本和日志）、记录管理员（留存证据）及最终 Accountable 签发人。P0 必须由有资质人员逐条复核，P1 至少抽样加全量确认关键字段，P2 可按组织政策抽样；任何 manual_override 都要写原因、修改前后、人员和时间。

审计日志与可追溯性

日志要记录案件编号、数据分类、输入哈希、脱敏映射引用、路由及规则版本、模型与参数、工具调用、输出哈希、门禁结果、人工决定和发送对象。日志内容应最小化，正文与日志分离，访问采用分级权限和不可抵赖时间戳。重跑不能覆盖旧结果，应生成关联版本并说明触发原因。审计人员应能从最终交付反查到原文和依据，也能从某次模型升级找出受影响案件；无法完成双向追溯时，暂停扩大使用。

事故停止条件

出现未授权外发、跨租户数据混入、凭据泄露、提示注入导致工具越权、P0 漏检、法源状态错误、文档修订错位、日志缺失或供应商服务异常时，立即停止真实合同处理，冻结产物并通知安全、法务和业务责任人。停止不是删除证据：保全相关输入哈希、运行日志、模型响应和网络记录，隔离受影响版本，评估通知义务。恢复前必须完成根因、受影响范围、修复验证、独立复核和负责人签字；未经复核不得以人工补改掩盖系统事故。

分阶段试点清单

阶段零做数据盘点、法域清单、RACI、供应商审查、威胁建模和黄金集；阶段一只用合成或低敏、低争议、单一法域的 general 服务合同，关闭自动外发和写回；阶段二加入脱敏真实样本、双语、托管 overlay 和 DOCX 修订回归，按周复盘误报漏报；阶段三扩大到资管模式，但每个模式单独审批、单独指标和单独退出条件。每阶段都要有开始门槛、样本量、人工覆盖率、指标阈值、事故响应时限和回滚负责人，未达标则留在当前阶段。

上线决策表

建议用 P0/P1/P2 做明确决定。P0：无权限隔离、真实数据跨境未获批准、法源无法追溯、关键风险漏检或 DOCX 修订错位，结论为不采用，先整改并重新评测。P1：数据与权限已控但黄金集不足、双语或表格覆盖不足、人工 RACI 未演练，结论为仅限受控试点，禁止自动签发和高风险合同。P2：门禁、证据、日志、版式和事故演练均达标，且连续回归达到组织阈值，结论为有限上线；仍需定期抽样和变更复审。度量至少包括 P0 漏检率、P1 漏检率、严重误报率、证据完整率、路由正确率、解析成功率、版式回归通过率、人工覆盖率、平均复核时长和停止事件数。

最终采用结论

在完成上述证据前，最稳妥的 P0 结论是“不把仓库当生产法律保证”，但可以把 intake hard gate、canonical routing、evidence-backed finding、固定交付、fail-soft、四门禁以及 Track Changes/Comments 检查清单作为内部控制的候选组件。采用流程工具不替代律师；法律依据与结论必须由有资质人员结合事实、合同整体、目标法域和现行法律复核。企业的上线签字应针对冻结版本、模型和数据边界，而不是针对 GitHub 项目名称；每次变更都要重跑自己的黄金、对抗和回归集，并保留可供追责的完整证据链。

仓库事实与目录入口见官方仓库、README.md、SKILL.md；这些链接用于核验版本和文件内容，不构成自动法律检索或合规承诺。

审计控制补充 1：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 2：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 3：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 4：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 5：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 6：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 7：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 8：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 9：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 10：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 11：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 12：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

审计控制补充 13：企业应把该项纳入案件记录、人工复核、版本冻结、异常告警和回滚演练，使用真实指标证明边界有效，不把模型表达流畅当作法律结论。

控制点1要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点2要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点3要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点4要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点5要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点6要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点7要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点8要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点9要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点10要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点11要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点12要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点13要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点14要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点15要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点16要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点17要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点18要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点19要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点20要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点21要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点22要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点23要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点24要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点25要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点26要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点27要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点28要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点29要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点30要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

控制点31要求记录输入、证据、责任人、时间和复核结果，并在异常时停止自动交付。

上线证据项32必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项33必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项34必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项35必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项36必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项37必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项38必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项39必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项40必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项41必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项42必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项43必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项44必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项45必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项46必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项47必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项48必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项49必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项50必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项51必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项52必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项53必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项54必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项55必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项56必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项57必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项58必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项59必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项60必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项61必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项62必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项63必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。

上线证据项64必须由指定角色核验并可追溯，缺失时保持人工队列，不得声称审查完成。