一份服务合同写着“交付后及时验收，逾期视为通过”。读者可能马上觉得有风险，但如果意见只写“建议明确验收条款”，业务同事仍然不知道该向对方提出什么。交付指哪些文件？验收从收到邮件起算，还是从取得完整成果起算？发现缺陷以后，原来的期限是否继续计算？
Contract Review 是一套面向编码助手的合同审查工作流，提供输入要求、检查清单和交付约定。它适合帮助整理问题与证据，具体合同效力、法律适用和谈判决定仍需要负责人员复核。本文按 2026 年 9 月 23 日官方仓库说明，以虚构服务合同演示整理方法，不提供针对某笔交易的法律意见。项目仓库
安装之前，先看它包含什么
仓库除了 SKILL.md，还有 references、checklists、protocols 和 templates 等目录。入口文件会按场景引用这些资料，因此只复制一段提示词，不能等同于安装完整工作流。
官方 README 分别给出 Codex 与 Claude Code 的安装位置。实际使用时应核对当前客户端的技能发现方式，并记录采用的仓库提交。首次试用可以先让助手确认读到了哪些文件，再交给它一份去标识化样例。
不要直接把真实合同、客户附件和内部谈判底线全部交给一个尚未验证的环境。先确认文件解析、模型提供方和产物保存位置，再按团队要求扩大范围。本文没有执行安装，也没有生成经过法律复核的交付文件。
先说清楚你代表谁、合同到哪一步
同一条责任上限，对委托方与服务方的意义不同。输入中应说明业务类型、客户立场、合同状态，以及本轮希望解决的问题。只说“帮我审一下”，很容易得到双方立场混杂的建议。
可以从这样一段请求开始：
请审查这份虚构的服务合同样例。
业务类型：general。
我方身份：购买服务的一方，合同中称为甲方。
合同状态：待签署草稿。
本轮范围：交付、验收、付款条件和终止后的资料返还。
先列文件与缺失信息，再给带条款位置的风险表。
没有依据的事实不要补写，法律依据不确定时标为待人工复核。
这是一段输入示例，不是能绕过缺失材料的快捷指令。合同中若还有未提供的技术附件，助手应指出它影响哪些判断，而不是用通常做法代填。
项目区分通用合同与几种资管场景，也提供专项叠加清单。模式应依据交易本身选择，不能只看到某个词就把普通服务合同套进完全不同的业务规则。工作流入口说明
文件名里的“最终版”不能决定采用哪份
收到主合同、补充协议、报价单和邮件以后，先建立文件清单。记录文件来源、日期、签署状态和相互引用关系；存在冲突时，把冲突列出来。
一份较新的草稿未必已获双方认可，一份已签补充协议也可能只修改原合同的某几条。不能用一个简单的文件排序替代具体内容判断，更不能自动把旧主合同全部丢弃。
扫描件还需要检查文本抽取。金额中的小数点、表格中的空白项、否定词和手写补充都可能影响含义。若文本与页面不一致，应回到原页确认，再让后续分析使用修正后的材料。
审查记录中保留文件版本与定位方式。即使正文后来重新分页，也应能通过条款号、标题和摘录找到当时分析的位置。
把验收问题写成一条完整意见
回到“交付后及时验收，逾期视为通过”这个虚构条款。第一步先摘录足够的上下文，确认合同别处是否已经定义交付物、验收期限和通知方式。若附件已有明确约定，不能只看这一句就报告缺失。
假设检查后仍没有这些内容，意见可以指出：交付完整性与验收起点未明确，双方可能对期限何时开始产生分歧；如果视为通过又触发付款，就会影响付款节点。
修改建议应对应这个机制，例如请业务确认成果清单与验收负责人，补充完整交付的确认方式、验收窗口、缺陷反馈和修复后的复验安排。具体期限取决于项目工作量，不能由模型随意给一个天数。
对外沟通可以写得更直接：“请在附件中列明交付包，并约定甲方收到完整交付包后开始验收；存在缺项或需要修复时，请明确后续复验安排。”这段措辞仍需结合合同定义与双方谈判结果调整。
这样一条意见同时回答了哪里有问题、什么情况下产生后果、需要谁补充事实，以及怎样推进修改。它比单独给出“高风险”三个字更方便复核。
检查责任条款时，把交叉引用一起拿出来
再设一个虚构例子：一条规定服务方赔偿上限为已收服务费，另一条要求特定数据事件承担全部损失。两条是否冲突，要看适用范围、例外和优先顺序，不能只比较字面上的金额大小。
审查时把相关定义、责任条款和例外放在一起，说明当前文本有哪些解释空间。建议可以要求双方明确上限适用的损失类型、计算范围以及特定事项是否排除在外，但不应凭空宣布某种安排必然有效或无效。
业务人员还需要确认风险能否承担、是否有保险或其他补救安排。技术团队则可以解释数据处理实际经过哪些系统。合同意见有时需要这些事实，缺了就应保留待确认状态。
如果是已经签署并正在履行的合同，交付方式也要改变。直接把原文件改成新条款，不代表双方已经完成变更；可以先整理待协商事项、补充文件需求或内部执行安排，由负责人员决定下一步。
风险表的每一行都应回到证据
项目的输出约定强调固定主表与条款定位。实际验收时，可以从最重要的几行开始，逐项打开原文件核对：摘录是否完整、是否漏掉例外、所述后果是否依赖尚未确认的事实。输出要求
严重程度也应有理由。关键附件缺失可能阻止本轮作出判断；表达不够顺畅则未必影响履行。若所有问题都标成最高级，业务团队反而难以决定先解决什么。
法律依据与合同事实分开核实。工具列出一个法规名称，不代表已经确认它当前有效、适用于相关地区与交易，或确实支持该结论。对于未核实的依据，保留待复核状态，不用看似精确的条号掩盖缺口。
复核人发现一条意见没有依据时，应删除、降为提问或补足证据。不要为了让表格看起来完整，保留无法回到原文的风险描述。
Word 交付要区分修改和说明
如果需要带修订的文档，正文改动与解释性批注各有用途。修订让对方知道准备增加、删除或替换什么；批注说明原因、待确认事实或谈判问题。
生成以后，用目标办公软件打开检查。确认改动落在正确条款，重复出现的句子没有选错位置，表格没有错位，批注没有包含仅供内部讨论的底线或个人信息。
还可以检查接受全部修订后的文本是否连贯，以及拒绝修订后能否回到原先内容。文件能打开不代表修订语义正确，尤其涉及跨段落替换与表格单元格时，需要逐处看。
对于要求保留版式的交付，以确认过的文件副本为基准。不要为了方便处理，把复杂合同先转成 Markdown 再重建，却没有检查页眉、编号和附件引用是否改变。
用几个有预期结果的样例维护工作流
第一次试点可以准备完整草稿、缺附件、版本冲突和文本定位失败等样例。每个样例写出预期行为，例如缺附件时应列出影响范围，定位失败时不应修改相似条款。
升级 Skill、客户端或模板后重跑这些样例，比较输入解析、问题定位和最终文件。样例数量本身不能证明质量，实际结果与人工复核记录才有用。
一轮审查结束时，保存采用的文件清单、未决问题和交付版本。业务补充了事实以后，只重新评估受影响的意见，并保留变化原因。这样才能让下一位同事接着工作，而不必从一张没有出处的风险表重新猜起。