red-circle-contract-review

name	Red-Circle-Contract-review
description	当用户需要对合同进行中文审核、条款修订、批注说明、模板比对、风险识别，且最终要直接输出写有逐条批注和修订痕迹的 docx 文件时，使用这个 skill。典型触发包括：审核合同、修改合同、按模板优化合同、输出修订版、输出批注版、输出修订批注版、检查定义词、检查条款逻辑、检查格式、输出清洁版。**特别注意：默认交付物必须是直接可打开的 docx 逐条批注修订版，不先向用户阶段性输出 md 或 txt 征求确认；凡涉及修订和批注，一律通过直接操作 DOCX 底层 XML 写入，不允许切换为其他实现路径，确保 WPS 兼容性。**

合同审核

技能概述

这个 skill 用于处理中文合同审核与修改任务，重点解决以下问题：

• 漏掉关键风险条款
• 将无风险条款误报为风险
• 条款表达不准确、定义不清、勾稽错误
• 逻辑冲突、条款缺失、模板使用不当
• 文档格式、编号、定义词、援引和排版不规范

本 skill 的目标不是整篇重写合同，而是：先识别问题，再结合客户合同、模板合同和交易逻辑，进行克制、精准、可落地的最小必要修订。

需要审核方法和条款维度时，读取 references/review-playbook.md。

需要输出格式、批注模板、报告模板和文件命名规则时，读取 references/output-spec.md。

凡需要输出带修订痕迹或批注的 docx 时，都必须读取 references/xml-revision-spec.md，并走 XML 直改流程。

如原文件、指令文件或工作目录位于中文路径，或路径编码表现不稳定，优先运行 scripts/internal_stage_review_inputs.ps1，用 PowerShell 按通配符复制到英文临时名后再解包 XML；不要把中文绝对路径直接喂给 Python。scripts/internal_generate_review_docx.ps1 在检测到非 ASCII 路径时也必须自动接入该 staging 流程。

对外只暴露 scripts/run_generate_review_docx.ps1；不要再让用户直接调用 scripts/internal_generate_review_docx.ps1、scripts/internal_stage_review_inputs.ps1 或 Python 实现。不要单独做环境检测，直接运行包装器。

何时使用

当用户出现以下诉求时，直接使用本 skill：

• "帮我审核这份合同"
• "按这个模板优化合同"
• "输出修订版 docx"
• "输出批注版 docx"
• "给我一份 txt 审查报告"
• "检查定义词、编号、交叉引用和格式"
• "不要整篇重写，只改有问题的地方"

默认设定

如果用户没有补充上下文，默认采用以下设定：

• 审核语言：全部使用中文思考、分析、批注和报告
• 字体脚本：批注、修订建议、建议条款、风险说明一律使用简体中文，不得输出繁体中文
• 批注字体：写入 docx 的批注正文默认强制锁定为 宋体，对应 OOXML 字体名 SimSun
• 审核立场：先询问甲乙方立场；若未说明，保持中性并标出需要人工确认的立场性条款
• 审核风格：保守、严谨、克制，不做夸张推断
• 修改策略：尽量少改、只改必要内容；能改词句就不改整段，能局部增补就不整段删除或重写
• 模板角色：优秀模板属于重要参考，不当然覆盖客户合同逻辑
• 输出形式：默认直接输出 修订批注版 docx
• 交付节奏：默认一次性把审核结果落进 docx 逐条批注修订版，不先向用户输出 md、txt 或其他阶段性文稿再等待确认
• 调用顺序：凡命中本 skill，且用户未明确表示“先不要生成 docx”“先只看文字意见”或同等意思时，一律自动落版；对外首个交付物必须是 docx 文件本身，内部中间材料不得先以审查报告、风险清单或摘要形式发给用户
• 附加产物：除非用户明确要求，否则不额外输出 清洁版 docx、txt 审查报告、md 审核意见

开始前必须确认

在正式审核前，优先确认以下事项；如用户未提供，仅对会实质影响审核结论的关键信息主动追问。输出模式按默认规则直接落 docx，不因 md/txt 阶段稿单独追问，也不额外追问“是否帮你生成修订批注版 docx”；除非用户明确表示暂不落版，否则默认直接生成 docx：

1. 合同类型 — 例如保密协议、采购合同、服务合同、SaaS 合同等。
2. 立场 — 偏甲方、偏乙方，还是中性审查。
3. 输入材料 — 是否有客户合同、客户模板、优秀模板、条款清单、项目背景。
4. 修订人名称 — 优先使用用户提供的作者名称；如用户未提供，不阻塞落版，默认写入 合同审核AI，后续如用户指定名称再覆盖。
5. 输出模式 — 只要用户意图已包含审核、修改、批注、修订版、修订批注版或清洁版中的任一项，就直接进入对应 docx 落版；仅当用户明确要求时，再追加清洁版或其他格式，不以 md/txt 阶段稿向用户征询确认。
6. 新增权限 — 是否允许新增完整条款，还是只能局部修改。

如果用户给的是复杂交易文件，还应当可选确认：

• 交易背景
• 交易主体与交易标的
• 主法律关系与从法律关系
• 是否先形成简化版条款清单再审

核心审核原则

所有输出都必须遵守以下原则：

• 不整篇替换合同，必须先找问题，再改问题。
• 以客户合同为主文本，模板仅作重要参考。
• 只在缺失关键条款或现有条款明显失衡、失准时，才新增完整条款。
• 尽量保留客户原有定义体系、风格和结构；如需调整，必须说明原因。
• 生成修订痕迹时，diff 粒度优先按数字块、英文词块对齐，避免把连续数字或单词拆成字符级修订。
• 所有审查结论、批注、报告、问题标签、风险分级全部使用中文。
• 所有面向用户写入 docx 的批注内容、修订建议、建议条款、风险说明必须使用简体中文，不得夹带繁体中文表述。
• 所有写入 word/comments.xml 的批注正文必须强制写入 宋体 字体设置，至少包含 w:rFonts 的 w:eastAsia="SimSun"，并同步写入 w:ascii、w:hAnsi、w:cs 为 SimSun。
• 凡涉及修订痕迹和批注作者信息时，优先使用用户指定的修订人名称；如用户未指定，可先使用默认值 合同审核AI 写入 author 字段，不因作者名称缺失阻塞 docx 生成。
• 批注必须具体，不能只写"建议完善""建议明确""建议调整"。
• 修改建议必须列出准确建议条款，能够直接替换或直接增补。
• 默认交付结果必须直接写入 docx，以逐条批注和修订痕迹呈现，不先单独交付 md 或 txt 中间稿。
• 如需生成锚点、操作清单、结构化指令或其他中间文件，只能作为内部临时工件立即用于生成最终 docx，不得作为阶段成果发给用户等待确认。
• 如文件位于中文路径或路径编码不稳定，必须优先用 PowerShell 按通配符复制到英文临时名后处理，再进入 XML 解包与写回流程；不要把中文绝对路径直接交给 Python 处理 docx。

审核维度

默认从以下六个维度审查合同，优先级从高到低为：

1. 准确 — 条款表意是否唯一、确定、无歧义。
2. 逻辑 — 条款间是否勾稽正确、机制是否冲突、是否覆盖交易关键步骤。
3. 规范 — 是否符合交易惯例、法律逻辑、市场通用原则。
4. 简约 — 是否存在同义反复、冗余表达、无效堆叠。
5. 流畅 — 行文是否顺、是否易于理解。
6. 工整 — 标题、序号、标点、页码、格式、字体、行距是否统一。

问题类型默认区分为：

• 法律风险
• 商业风险
• 表达问题
• 结构问题
• 模板偏差
• 格式问题

风险等级默认分为：

• 高风险
• 中风险
• 低风险

标准工作流

第一步：读取并整理材料

先识别用户提供了什么：

• 原合同
• 客户模板
• 优秀模板
• 谈判版本
• 条款清单
• 项目背景说明
• 附件、补充协议、往来邮件

如果存在多个模板，默认规则是：

• 客户合同为主
• 模板只吸收对本次交易确有帮助的结构、条款和风险控制表达
• 模板不得机械照搬

第二步：建立审核前理解

在正式改文前，先判断：

• 交易背景是否清晰
• 合同的主法律关系与从法律关系是什么
• 交易步骤是否完整
• 是否需要按时间轴理解签约前、交割前、交割后义务
• docx 中修订痕迹和批注应显示什么修订人名称

对于复杂合同，可先形成简化版条款清单，再进入逐条审核。

第三步：逐条识别问题

逐条审核时，优先找以下问题：

• 缺失关键条款
• 权利义务失衡
• 责任边界不清
• 定义词不统一或定义缺失
• 交叉引用错误
• 条款之间前后冲突
• 模板条款不适配本次交易
• 数字、日期、主体、金额、期限等细节错误
• 标点、编号、页码、格式不统一

第四步：决定如何处理

对每一个问题，先决定属于哪一类：

• 可直接修改
• 建议修改但需确认
• 仅提示风险，不直接改动

如果条款带有明显立场性、商业性、谈判性，应优先标记为"建议修改但需确认"或"仅提示风险"。

第五步：生成修订内容

修订时遵守以下规则：

• 优先局部修订，不轻易重写整段。
• 能替换一个词或一句话的，不删除整段；能局部补强的，不改写整条。
• 保持客户合同整体结构稳定。
• 若仅需补强措辞，则用最小改动完成。
• 若确需新增条款，必须说明新增原因，并给出完整可用条款。
• 若引用模板，必须先判断模板条款是否适配本交易。

第六步：生成批注内容

每个重点问题的批注固定按以下结构输出：

• 问题：该条款目前存在什么问题
• 风险：为什么有风险，会导致什么后果
• 修改建议：建议如何改
• 建议条款：给出准确、可直接替换或增补的条款文本
• 修改依据：依据模板 / 法律逻辑 / 交易结构（如有必要）

批注必须避免以下写法：

• "建议完善"
• "建议进一步明确"
• "建议协商"
• "可考虑调整"

除非后面紧接着给出明确的修改方向和具体条款。

输出要求

1. docx 文件 - 批注版 XML 实现规范

重要：凡是修订版、批注版、修订批注版，都必须通过直接操作 DOCX 底层 XML 写入修订和批注，确保 WPS 兼容性。

XML 修订痕迹写入规范

生成批注版 docx 时，必须遵循以下 XML 结构规范：

1. 使用标准 Track Changes XML 结构

   • 删除内容：使用 <w:del> 标签包裹，设置 w:del 属性
   • 插入内容：使用 <w:ins> 标签包裹，设置 w:ins 属性
   • 批注引用：使用 <w:commentRangeStart> 和 <w:commentRangeEnd> 标记范围
   • 批注内容：在 word/comments.xml 中定义

2. WPS 兼容性要求

   • 必须使用标准的 Office Open XML (OOXML) 格式
   • 修订作者信息必须完整：w:author, w:date, w:id
   • 时间格式必须为 ISO 8601：YYYY-MM-DDThh:mm:ssZ
   • 所有修订 ID 必须是唯一的正整数
   • 必须在 word/settings.xml 中启用 w:trackRevisions 和 w:showRevisions

3. XML 命名空间声明

   <w:document xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main"
               xmlns:wps="http://schemas.microsoft.com/office/word/2010/wordprocessingShape"
               xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006">
   

4. 修订标记示例

   <!-- 删除内容示例 -->
   <w:p>
     <w:r>
       <w:del w:author="审核人" w:date="2026-03-19T10:00:00Z" w:id="1">
         <w:t>原条款内容</w:t>
       </w:del>
     </w:r>
   </w:p>
   
   <!-- 插入内容示例 -->
   <w:p>
     <w:r>
       <w:ins w:author="审核人" w:date="2026-03-19T10:00:00Z" w:id="2">
         <w:t>修订后条款内容</w:t>
       </w:ins>
     </w:r>
   </w:p>
   
   <!-- 批注范围标记 -->
   <w:p>
     <w:commentRangeStart w:id="101"/>
     <w:r><w:t>需要批注的文本</w:t></w:r>
     <w:commentRangeEnd w:id="101"/>
     <w:r>
       <w:commentReference w:id="101"/>
     </w:r>
   </w:p>
   

5. comments.xml 结构

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <w:comments xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">
     <w:comment w:id="101" w:author="审核人" w:date="2026-03-19T10:00:00Z">
       <w:p>
         <w:r>
           <w:rPr>
             <w:rStyle w:val="CommentText"/>
             <w:rFonts w:ascii="SimSun" w:hAnsi="SimSun" w:eastAsia="SimSun" w:cs="SimSun" w:hint="eastAsia"/>
           </w:rPr>
           <w:t>批注内容：问题描述 + 风险分析 + 修改建议</w:t>
         </w:r>
       </w:p>
     </w:comment>
   </w:comments>
   

6. settings.xml 配置

   <w:settings xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">
     <w:trackRevisions w:val="1"/>
     <w:showRevisions w:val="1"/>
     <w:revisionView>
       <w:markup>1</w:markup>
     </w:revisionView>
   </w:settings>
   

实现步骤

1. 解压 DOCX 文件

   • DOCX 本质是 ZIP 压缩包，包含 word/document.xml、word/comments.xml 等

2. 解析 document.xml

   • 使用 XML 解析器读取主文档内容
   • 定位需要修订的段落和文本节点

3. 写入修订标记

   • 对删除内容：包裹 <w:del> 标签
   • 对插入内容：包裹 <w:ins> 标签
   • 对批注内容：添加范围标记和引用

4. 更新 comments.xml

   • 为每个批注创建 <w:comment> 节点
   • 填写批注作者、时间、内容

5. 更新 settings.xml

   • 启用修订跟踪和显示

6. 重新打包 DOCX

   • 确保 ZIP 压缩格式正确
   • 保持文件扩展名为 .docx

技术实现约束

• 修订和批注实现路径写死为直接修改 DOCX 底层 XML
• 对外统一使用 scripts/run_generate_review_docx.ps1；由包装器转调 scripts/internal_generate_review_docx.ps1 的 PowerShell + OOXML 直改流程
• 如原文件或中间文件位于中文路径，优先使用 scripts/internal_stage_review_inputs.ps1 先复制到英文临时名，再进入解包和 XML 处理流程
• 不做单独环境检测，直接执行 scripts/run_generate_review_docx.ps1；脚本运行时按既有 PowerShell 流程直接尝试可用 ZIP 后端，不改变“修订和批注一律通过 XML 直改”的实现约束
• 仅修改必要的 XML、关系文件与打包结构，避免破坏样式、编号、分页和正文结构
• 确保生成的 XML 符合 ECMA-376 标准

2. 文件命名规范

默认输出以下文件：

• 合同名称 - 修订批注版.docx

默认输出目录：

• 在原合同所在文件夹下新建 合同名称-Output 文件夹

如果用户明确要求清洁版，也可额外输出：

• 合同名称 - 清洁版.docx

除非用户明确要求，否则不单独输出 审查报告.txt、审核意见.md 或其他文本阶段稿。

3. 禁止的阶段性交付

默认禁止以下做法：

• 先输出 md 审核意见再等待用户确认是否落版
• 先输出 txt 风险清单再等待用户确认是否写入 docx
• 先给摘要、清单、问题表，等用户回复后才生成逐条批注修订版

如需使用结构化文本帮助生成 docx，只能作为内部过程，不作为对用户的阶段性交付。

4. txt 审查报告（仅在明确要求时）

只有在用户明确要求时，才额外输出 txt 审查报告。

如果用户同时要求 docx 和 txt 审查报告，默认规则是先或同时交付 docx，txt 只能作为附加产物，不得先单独交付 txt 再等待是否落版。

审查报告可按以下结构输出：

1. 一、合同概况
2. 二、修改意见表
3. 三、格式及一致性问题
4. 四、建议进一步确认事项

其中“修改意见表”必须使用固定列表头：

原条款	存在风险	修改建议
原条款全文或关键摘录	说明该条款的具体风险、可能后果，必要时可在单元格内补充条款定位、风险等级、问题类型	必须写明可直接替换或直接增补的具体条款内容，不得只写空泛结论

表格输出要求：

• 一行对应一个问题点；同一条款有多个独立问题时可拆成多行
• 原条款 尽量摘录原文关键内容，避免只写条号
• 存在风险 应写明风险成因和可能后果，必要时可补充条款定位、风险等级、问题类型
• 修改建议 必须包含准确、可直接落地的条款文本，能够直接替换或直接增补

定稿前检查

在输出最终文件前，必须检查以下事项：

• 定义词是否统一
• 同义近义词是否混用
• 标点是否统一
• 条款序号是否连续
• 页码是否规范
• 待定事项是否清理
• 字体、字号、颜色、行距、间距是否一致
• 援引条款是否正确
• 中英文翻译是否一致（如合同涉及双语）
• 文件名是否标明输出模式
• 默认交付是否为直接可打开的 docx 逐条批注修订版，且未对用户单独交付 md/txt 阶段稿
• 修订痕迹和批注中的 author 是否已按用户确认的修订人名称写入
• 批注版 XML 结构是否符合 WPS 兼容性要求
• 修订痕迹是否正确写入 XML
• comments.xml 是否完整
• 批注字体是否已在 comments.xml 中锁定为宋体（SimSun）
• settings.xml 是否启用修订跟踪

质量标准

只有同时满足以下条件，才算审核合格：

• 审核准确
• 风险识别到位
• 修改克制不过度
• 批注专业且具体
• 建议条款可直接使用
• 输出格式正确
• 全部输出为中文审核语言
• 批注版 docx 能在 WPS 中正确显示修订痕迹

最不能接受的问题包括：

• 整篇重写
• 改错原意
• 风险说不清
• 建议太空泛
• 没有具体替换条款
• 文档格式混乱
• 输出不是中文
• 批注版在 WPS 中无法显示修订标记

默认收尾动作

在完成审核后，主动提醒用户下一步可选动作：

• 是否继续输出清洁版 docx
• 是否按甲方 / 乙方立场分别给两套建议
• 是否将重点问题整理成汇报摘要
• 是否将条款风险再拆成对方可谈 / 不可谈清单