合同修改（AI修订模式） Plus

合同修改（AI修订模式） Plus

本技能依据龚家勇律师定制规范设计：立场预置、法条强制核验、修订痕迹交付。 注意：本文档 frontmatter 的 author 字段为技能内部归属元数据，不写入任何对外交付文件（DOCX 修订署名强制锁定为 config/reviewer_profile.json 的 author="WPS" / initials="WP"，不得使用任何其他名称，仅作为 DOCX 修订标记中的修订作者显示，不进入交付文档正文；详见 Step 5 与第七部分注意事项）。

一、定位与强制规则

名称关联说明（中英文标识绑定）：

• 中文名称（对外展示 / 调用命令）：合同修改（AI修订模式） Plus
• 系统内部英文标识（Skills 目录名 / 脚本与引用 ID）：contract-modify
• 二者为同一技能的不同层面命名，本技能内所有英文路径、脚本名、引用（如 scripts/apply_modify_plan.py、references/checklist.md、scripts/docx/ 修订引擎，其与 contract-copilot 同源但为本技能内置副本）均对应此 contract-modify 标识。调用时请以中文名称 /合同修改（AI修订模式） Plus 为准；系统底层与文件结构以 contract-modify 为准。

本技能对上传的合同直接在其文本之上生成修改版：能直接修改之处以 Word 修订痕迹（w:del/w:ins）落点，需提醒用户或须由用户自行决断之处以 Word 批注锚定，最终输出同时含修订痕迹与批注痕迹的 DOCX 修订版（含页码）保存到用户桌面，不另写净稿。

六条强制规则（不可跳过）：

1. 立场绑定（视角由用户选择）：用户上传合同后，技能必须先以选择题方式询问修改视角（见 Step 1 强制交互）：1、有利于甲方；2、有利于乙方；3、中立公平；4、其他。1/2/3 互斥单选，选定后仍可在"4、其他"补充具体需求。选定 1/2 时加载 references/PLAYBOOK_zh-CN.md 作为立场基准（1 为正向、2 为反向套用）；选定 3 时不加载单方立场、改以公平均衡标准；选定 4 以用户自定义需求为准（可叠加 1/2/3）。未找到 Playbook 且用户选定 1/2 视角时，停止并提示用户先建立 Playbook，不得使用通用标准替代。
2. 法条强制核验：凡修改建议涉及法律条文、司法解释、案例案号，必须尝试通过华宇元典法律数据 MCP（yuandian-mcp）核验（调用流程见 Step 4 与 references/yuandian-verify.md）；MCP 已连接时必须调用核验，MCP 未连接时不得静默跳过，须将相关 legal_basis 全部标 unverified 并醒目提示"法条未经核验，须人工复核"。禁止将未经核验（或无法核验且未标注"⏳ 待人工复核"）的引用写入修订痕迹。
3. 最小必要修改 + 修订/批注分流（动作映射强制）：严格遵循"确定性错误直接改（落修订）、商务取舍与事实缺口批注（落批注）"原则（见 references/checklist.md）。动作映射不可错位：可直接修改的内容必须以 delete/insert/replace 落为修订痕迹，不得以纯批注或另起新文案替代；需提醒或须用户决断的内容必须以 comment 落为批注，不得擅自改为正文。
4. 交付形态（修订痕迹 + 批注痕迹 + 桌面 docx，核心强制规则）：本技能的最终交付物是一份 Word 修订版 DOCX，且该修订版直接构建在用户上传的合同文本之上（以原文档为母本，落修订/批注，而非脱离原文另写一份净稿）。具体形态与动作映射如下，二者并行、互不替代：
   • （1）能直接修改的地方 → 以"修订痕迹"呈现：凡属确定性错误、违法条款、缺失条款、明显失衡且无需客户授权的修改，统一以 Word 原生修订标记（w:del/w:ins，即删除线 + 插入下划线）落到原文本对应位置，保留"原文被删 / 新文插入"的可追溯痕迹，由客户一键接受或拒绝。不允许将可直接修改的内容以纯批注或另起新文案方式交付。
   • （2）需提醒用户或须由用户自行决断的地方 → 以"批注"呈现：凡属商务取舍、事实缺口、需客户授权决断、风险提示、或缔约过失红线（见第七部分）下不宜 AI 擅自落修订之处，统一以 Word 批注（comments）锚定在原文本对应位置，由用户阅读后自行修改或确认。不允许将此类事项擅自改为正文。
   • （3）最终文稿：生成 {合同名}_修订版_{YYYYMMDD}.docx，同时包含上述修订痕迹与批注痕迹，并插入页码，保存到用户桌面（绝对路径，不可用 ~ 简写）。本技能不另交付"净稿/清稿"，修订版即唯一交付物。
   • 技术前提：修订痕迹与批注痕迹均为 Word（DOCX）原生能力。用户上传 DOCX 时直接落修订/批注；上传 PDF / 纯文本 时，须先转为 DOCX（环境具备 markitdown/pandoc 时在隔离 venv/workspace 内安装转换，否则提示用户改用 DOCX 输入），转换后的 DOCX 方为落修订/批注的母本，再按（1）（2）映射输出桌面修订版。
5. 相对方资信预检（企查查 MCP + 华宇元典法律数据 MCP，主动询问）：在开始合同修改（Step 3 三观审视）之前，若用户的 WorkBuddy 已连接企查查 MCP（qcc-company）和/或华宇元典法律数据 MCP（yuandian-mcp），技能必须先以选择题方式主动询问用户：是否需要调用上述已连接的 MCP 查询本合同**相对方（非我方签约主体）**是否存在诉讼案件或执行案件（含被执行人、失信被执行人记录）等资信风险。具体执行见 Step 1.5。用户选择"需要"时方调用 MCP 执行查询；用户选择"不需要"时跳过自动查询，但仍须口头提示用户自行核查相对方资信，不得静默略过风险提醒。两者均未连接时，改以口头/批注提示方式请用户自行核查，不得静默跳过此风险提示。

🔴 资信预检结论滞后提示（强制·全文档统一标准）：凡本技能输出的"相对方资信预检结论"（含自动 MCP 查询结果、降级口头/批注提示、以及任何资信风险相关结论），一律须以红色圆点（🔴）醒目提示用户如下标准语，不得省略、不得弱化、不得替换为其他表述：

🔴 本技能资信预检结论存在滞后，仅供参考，请用户自行核查。

适用边界：只要在交付物、对话回复、批注或任何输出形态中呈现"相对方资信预检结论"（无论是否经 MCP 查询、无论用户是否选择查询、无论 MCP 是否已连接），均须紧跟该结论附加上述 🔴 红点提示；提示应紧随结论、中间不得插入其他文字而弱化其效力。本提示与第七部分"相对方资信风险提示常态化"、Step 1.5 各子流程的时效/降级提醒并存、互补，不得相互替代。

重要提示：本技能协助法律工作流，不提供法律意见。所有修订应由具备资质的法律专业人士复核后再依赖。

二、调用方式

/合同修改（AI修订模式） Plus <合同文件或文本>

如未提供合同文件，提示用户提供（支持 DOCX / PDF / 粘贴文本）。

三、方法论底座：四套方法论的融合

本技能的合同修改逻辑，借鉴《合同起草审查指南：三观四步法（第五版）》（何力、常金光等著，2024年法律出版社出版）关于宏观—中观—微观"三观"视角 + 沟通/规划/审查修改/复核"四步"流程的内容，以及《完美的合同：合同的基本原理及审查与修改（第四版）》（吴江水著，2024年北京大学出版社出版）关于三重质量标准 + 五大基本模块 + "两比一找"的内容，以及《合同审查与修改实务》（杨司和著，2022年法律出版社出版）中修改技术动作与分场景要诀的内容，以及龚家勇律师于 2026-07-31 提炼的「实战审查九维要点」（交易实务维度），融会贯通出一套修改合同的方法论。四套方法论各司其职、相互支撑，而非简单堆砌：

来源	提供的方法论	在本技能中的角色
《合同起草审查指南：三观四步法（第五版）》（何力、常金光等著，2024年法律出版社出版）	"宏观—中观—微观"三观视角 + "沟通—规划—审查修改—复核"四步流程	流程骨架与视角分层（解决"先看什么、后改什么"）
《完美的合同：合同的基本原理及审查与修改（第四版）》（吴江水著，2024年北京大学出版社出版）	三重质量标准（内在/外在/版式）+ 五大基本模块（质量/价格/期限/对象/违约）+ "两比一找"	微观审查标尺与交易主线（解决"按什么标准逐项改"）
《合同审查与修改实务》（杨司和著，2022年法律出版社出版）	修改的具体技术动作（增/删/改/调、表述技术、体例技术）+ 分场景修改要诀	动作落点与技术规范（解决"具体怎么动手改"）

民法典规范体系贯穿三层，作为合法性底线；华宇元典 MCP 作为法条校验防线。

补充方法论（实战维度）： 龚家勇律师于 2026-07-31 提炼的「从律师视角修改合同的要点（九大维度）」，作为本技能实战审查维度的补充，与以上三套方法论交叉互补——三套偏"结构—质量—动作"，本补充偏"交易实务九维度"（主体资格、标的、价款支付、履行、违约、保密/IP/不可抗力、争议管辖、效力形式、通用方法论）。在 Step 3 中与三观分层同步展开，细化清单见 references/checklist.md「二-补、实战审查要点（九维）」。

0. 融合逻辑总览（自洽闭环）

三观四步法（流程+视角）
   │
   ├─ 宏观（交易结构/交易类型/交易主体）：定性、主体适格、交易模式合法
   │     └─ 落到《完美的合同》"对象模块" + 杨司和"主体与定性技术"
   │
   ├─ 中观（合同形式/合同体例/交易条件）：形式匹配、章节体例、权利义务群
   │     └─ 落到《完美的合同》"外在质量" + "五大模块"权利义务主线 + 杨司和"体例技术"
   │
   └─ 微观（合同条款/文字表述）：逐条合法性、利己性、文字精确
         └─ 落到《完美的合同》"内在质量/外在质量（语言）" + "两比一找" + 杨司和"表述技术"

         ↓ 每一步均按杨司和"修改动作"落为 delete/insert/replace/comment

   复核（四步法第四步）←→ 两比一找闭环校验 ←→ 三观视角回溯

• 视角分层（三观）决定分析的广度与顺序：先看宏观交易结构是否站得住，再看中观体例与交易条件是否周延，最后落到微观条款与文字。
• 审查标尺（完美的合同）决定分析的深度与标准：用三重质量 + 五大模块逐层体检。
• 技术动作（杨司和）决定分析的落点：把每一个发现翻译成具体的增删改调动作，并对文字、体例、标点、引用做规范化处理。

1. 三观视角（来自《三观四步法（第五版）》）

《三观四步法》将合同审视分为三个由大到小的视角，本技能严格按此顺序展开，确保"重大结构问题不淹没在文字细节里"：

顺序纪律：宏观缺陷（如定性错误、主体不适格）优先于中观，中观（体例/闭环）优先于微观（措辞）。发现宏观硬伤时，先提示定性/主体问题，不先纠结文字润色。

2. 四步流程（来自《三观四步法（第五版）》）

《三观四步法》将合同工作分为四步，本技能映射为：

3. 三重质量标准与五大模块（来自《完美的合同（第四版）》）

作为微观与中观审视的验收标尺与交易主线：

三重质量标准（质量三维度）：

修改优先级：内在质量 > 外在质量 > 版式质量。

五大基本模块（交易主干，须逐一覆盖）：

五大模块构成"交易主体—交易内容—交易方式—交易保障"主线，与"以权利义务为主线"一致。任何模块缺失/缺陷均须作为 finding 并判定 action。

3-补（前置）. 条款性质三分法（法律 / 商务 / 技术）

与 §3「五大模块」及杨司和"条款功能分类"互补：五大模块按交易主干切分，条款功能分类按作业动作切分，本三分法按条款性质切分，用于微观审视时快速归类、避免漏审。依据《中华人民共和国民法典》第 470 条合同一般条款，并结合实务界通行分类（法律条款 / 商务条款 / 技术条款）。

微观审视时，对每一条款先判定其性质归属：法律条款重点查"效力与救济"，商务条款重点查"授权与平衡"（商务事实缺口须 comment 而非擅自改），技术条款重点查"特定化与可验收"。三类条款交叉处（如质量条款兼具商务与技术属性）须同时覆盖。

3-补. 实战审查九维要点（龚家勇律师提炼，2026-07-31）

与 §3「五大模块」同源互补：五大模块是"交易主干标尺"，本九维是"律师实战审查清单"。在 Step 3 中，每一条 finding 除标记 view/quality_dim/module 外，可并行标注其所属实战维度（①–⑨），确保交易实务要点无遗漏。完整可勾选清单见 references/checklist.md「二-补」。

4. 条款功能分类 + 两比一找（微观落点）

• 条款功能分类（按类施策）：
  • 陈述性条款（鉴于条款、主体信息、背景事实）：重在准确、无矛盾；笔误/信息错漏直接 replace。
  • 允诺性条款（权利义务、履行行为）：重在清晰、可执行、利益均衡；失衡或不可执行须 replace/comment。
  • 免责/限制责任条款（不可抗力、责任限额）：重在合法、不显失公平（《中华人民共和国民法典》第 506 条）；违法或不当须 replace/comment。
  • 争议解决条款（管辖、仲裁、送达）：重在有效、对我方有利；不利或无效须 replace。
  • 附随条款（保密、IP、通知、生效）：重在闭环、无漏洞。
• 两比一找（吴江水"作业动作"，贯穿微观审视）：
  • 与法律比（合法性）：对照民法典及规范，识别效力性强制规定违反（《中华人民共和国民法典》第 153 条）、格式条款不公（《中华人民共和国民法典》第 496–498 条）、主体/程序缺失（《中华人民共和国民法典》第 502 条）。
  • 与利益比（利己性/利益平衡）：对照我方立场（甲方优先 PLAYBOOK），识别权利义务失衡、风险分配不当、救济落空；防止过度利己致交易失败。
  • 找缺陷：系统发现内在/外在/版式三维度缺陷。

5. 修改技术动作（来自《合同审查与修改实务》杨司和著，2022年法律出版社出版）

杨司和将"审查发现"转化为"修改动作"的技术规范化，本技能据此把每个 finding 落到具体动作，并约束文字/体例技术：

（一）四类基本动作（对应 action 字段）：

即本技能 action 枚举：delete / insert / replace / comment，与杨司和"增删改调"一致（调=comment）。

（二）表述技术规范（微观文字修改的硬性要求）：

• 重点词精确：应当（义务强制）/ 可以（授权或选择）/ 有权（权利）/ 视为（法律拟制）严格区分，不混用。
• 避免歧义句式：少用"等""相关""适当"等模糊词；列举项用"包括……但不限于"或穷尽列举；否定范围用"除……外"明确。
• 权利义务对称：甲方义务对应乙方权利，避免单向义务群（义务清单遗漏）。
• 引用规范：法条写全称+条号（如《中华人民共和国民法典》第五百七十七条），不写"相关规定"；金额/日期/比例用阿拉伯数字且前后一致。
• 标点与体例：条款内分项用统一编号（1. 2. 3. 或（一）（二））；避免长句嵌套超过两层。

（三）体例技术规范（中观修改）：

• 章节编号连续、无跳号；交叉引用（"见第X条"）指向存在且一致。
• 定义表（如有）与正文用词统一；签署栏要素（名称/授权/日期/盖章）齐备。
• 附件清单与正文引用对应；空白字段统一标注"[　]"或批注提示补录。

6. 三大理念约束（跨方法论的共同软约束）

• 交易目的导向：每项修改回溯"是否服务于交易目的的实现"，不因文字洁癖牺牲交易效率（三观四步法"沟通"本质 + 完美的合同核心思想）。
• 利益平衡与可交易性：识别"确定性错误"与"商务取舍"，不替客户做未授权商业决断；过度严苛阻碍合法交易的，应标注而非强制修改（与"最小必要修改"强制规则一致）。
• 歧义控制：修改应消除而非制造歧义，重点词准确；避免非对称条款与义务群遗漏（杨司和表述技术 + 完美的合同语言要求）。

四、工作流（三方法论融合落地，6 步主流程 + Step 1.5 强制前置资信预检）

工作流严格对应《三观四步法》"沟通—规划—审查修改—复核"四步，并在"审查修改"阶段按"宏观→中观→微观"三观逐层展开，每一层以《完美的合同》"两比一找"为作业动作，最终以《合同审查与修改实务》"增删改调"技术落为修订痕迹。其中 Step 1.5（相对方资信预检）为沟通阶段的强制前置子环节，须在 Step 2 加载立场之前完成。

Step 1 — 接收与解包（沟通·明确交易目的·锁定修改视角）

• 接受 DOCX / PDF / 文本。DOCX 走 XML 解包（复用 scripts/docx/）：解包到临时目录，保留 word/document.xml 等结构。
• PDF / 文本：先用 markitdown 或 pandoc 转为 DOCX 再解包（若环境不支持，明确告知用户改用 DOCX 输入）。
  • 隔离运行时（受管 Python/Node）通常未预装 markitdown/pandoc；如确需转换，应安装在隔离 venv/workspace 内或提示用户在本机提供 DOCX，不可假定其已存在。
• 识别合同类型与我方角色（甲方/乙方），作为后续分析视角锚点。
• 明确交易目的（三观四步法"沟通"核心）：向用户确认或推断本合同核心交易目的（如"完成货物买卖并控制付款风险""锁定服务成果交付"），作为 Step 3 全过程的出发点。
• 沟通需求边界：确认修改范围、客户授权（哪些可改、哪些须批注待决）。

强制交互（上传合同后立即执行，不可跳过）： 用户上传待修改合同后，技能必须以选择题方式主动询问修改视角（兼容 Step 1.5 资信预检的合并提问，见下方⚡交互合并），再进入 Step 2 加载立场。使用 AskUserQuestion 工具呈现如下选项，1/2/3 为互斥单选项，用户选定 1/2/3 中任一项后仍可在"4、其他"中补充填写具体需求（即"其他"可附属于选定项，不互斥）：

⚡ 交互合并（提速·不损质量）： 本步「修改视角」询问与 Step 1.5「相对方资信预检」询问合并为同一次 AskUserQuestion 调用（在同一弹窗中并列两个问题：① 修改视角四选一；② 资信预检二选一）。合并后仅省去一次 UI 往返，两问仍各自独立作答、互不替代，且强制规则第 1 条（视角）与第 5 条（资信预检）的询问义务、写入 modify-plan.json 的字段、降级提示要求均与原分两步完全一致，不得因合并而省略任何一题或静默跳过资信提醒。合并提问的答案收集完毕后，再按 Step 1.5 的连接状态判定与执行查询/降级流程处理。

header（标签）	选项	说明
修改视角	1、按照有利于【甲方】的视角进行修改	以甲方利益最大化为基准调整权利义务、风险分配与救济（默认沿用 PLAYBOOK 甲方优先立场）
修改视角	2、按照有利于【乙方】的视角进行修改	以乙方利益最大化为基准调整；此时需将 PLAYBOOK 立场反向套用（乙方优先）
修改视角	3、按照【中立、公平】的视角进行修改	不预设任何一方利益，以提供公平、均衡、可交易的标准条款为基准（脱离 PLAYBOOK 单方立场）
修改视角	4、其他	用户自定义视角或具体需求（如"兼顾甲方利益但管辖地改在乙方所在地"）；用户可在选定 1/2/3 后此处补充细化要求

交互规则：

• 必须等待用户作答并确认其选定项（及"其他"中补充内容，如有）后，方可继续 Step 2。
• 若用户仅选 4 且未选 1/2/3，则以用户填写的自定义需求为准，并提示该需求将替代默认立场。
• 将用户选定结果写入 modify-plan.json 的 meta.modify_perspective 字段（取值：甲方利益 / 乙方利益 / 中立公平 / 自定义:<内容>），作为后续所有 与利益比 作业的视角锚点。
• 用户选定结果如与 PLAYBOOK 默认（甲方优先）不一致，Step 2 按选定视角加载/反向套用立场，并在修改说明中标注实际采用的视角。

Step 1.5 — 相对方资信预检（规划前置·企查查 MCP + 华宇元典法律数据 MCP，强制·选择题询问）

触发前提：本步骤属于强制规则第 5 条的落地动作，不可跳过。在 Step 1 已启用"修改视角 + 资信预检"合并提问的模式下，资信预检的答案与修改视角在同一轮 AskUserQuestion 中同步获得；若未启用合并（或 MCP 未连接走降级），则本步骤在 Step 1 视角确认后、Step 2 加载 PLAYBOOK 之前执行。无论何种模式，均须在 Step 2 之前完成连接状态判定与查询/降级流程。

本步骤包含两个可并行的资信风险信号源：企查查 MCP（工商/经营/司法执行维度的公开风险）与华宇元典法律数据 MCP（裁判文书/案例/执行案件维度的司法风险）。关键点：本步骤不自动查询，而是先以选择题方式征询用户授权，用户确认"需要"后才调用已连接的 MCP 执行查询；用户选"不需要"则跳过自动查询。

• 连接状态判定：技能首先确认用户的 WorkBuddy 是否已连接 企查查 MCP（qcc-company） 与 华宇元典法律数据 MCP（yuandian-mcp）。

  • 两者均未连接（disconnected / 不可用）：直接执行下方"③ 降级提示"流程，不弹出选择题。
  • 任一或两者已连接（status: connected）：执行下方"① 选择题询问"流程。

• ① 选择题询问（任一/两者已连接时，强制弹出，不可跳过）： 使用 AskUserQuestion 工具，以醒目方式向用户呈现如下选择题（1/2 为互斥单选项）：

  header（标签）	选项	说明
  资信预检	1、需要查询对方是否有诉讼或执行案件	调用已连接的企查查 MCP / 华宇元典法律数据 MCP，重点检索相对方作为当事人（尤其是被告、被执行人）的未结诉讼、被执行案件、失信被执行人等资信风险信号（企查查侧同时可补充经营异常、行政处罚等工商风险旁证，但均属资信风险主题）
  资信预检	2、不需要	跳过 MCP 自动查询；技能转以口头/批注提示用户自行核查相对方资信，不静默略过风险提醒

  交互规则：

  • 必须等待用户明确作答（选 1 或选 2）后方可继续 Step 2；不得默认代用户决定查询与否。
  • 若用户选 1（需要查询）：执行下方"② 执行查询"流程，对所有已连接的 MCP 信号源调用查询；将用户选择写入 modify-plan.json 的 meta.counterparty_credit_check_consent 字段（取值：需要查询）。
  • 若用户选 2（不需要）：跳过自动查询，执行"③ 降级提示"中的口头/批注提醒，并将 meta.counterparty_credit_check_consent 标注为 不需要（已提示用户自行核查）；后续 Step 3 仍正常进行，不阻断修改流程。

• ② 执行查询（用户选 1 且对应 MCP 已连接时的流程）：

  • 从合同首部/签署栏识别相对方主体全称与统一社会信用代码（应与 Step 1 识别的我方角色相对，即"非我方"的签约主体；多方合同时逐一列出各相对方）。
  • 已连接企查查 MCP（qcc-company）时：以用户授权询问的范围为限，重点检索相对方作为被告/被执行人的未结诉讼、被执行案件、失信被执行人记录（即"诉讼或执行案件"核心信号）；同时可补充呈现与之直接相关的工商风险信号（经营异常、行政处罚、股权冻结/出质、终本案件、限制高消费、破产重整/清算等）作为资信风险旁证，但须在提示中明确区分"诉讼/执行案件信号"与"其他工商风险信号"，不超出用户授权查询的资信风险主题。将结果（已查 / 未发现风险信号 / 发现风险信号及摘要）写入 meta.counterparty_credit_check。
  • 已连接华宇元典法律数据 MCP（yuandian-mcp）时：通过 yuandian_rh_ptal_search 等工具（以 ToolSearch 确认的实际工具名为准，见 references/yuandian-verify.md），按相对方名称检索其作为当事人（尤其被告、被执行人）的裁判文书/案例，重点关注诉讼案件、执行案件（被执行人）、失信被执行人记录。将结果（已查 / 未发现诉讼执行信号 / 发现信号及摘要）写入 meta.counterparty_credit_check_yuandian。
  • 合并呈现与风险提醒（醒目）：将各已连接 MCP 的检索结果以分层清单向用户提示，并明确提示"相对方资信风险可能影响本合同项下交易安全、履约能力，以及违约责任、担保条款的可执行性"，建议用户在继续修改前评估是否需补充担保/预付款/分期/管辖等风险缓释条款。
  • 数据时效提醒：企查查、华宇元典检索结果均存在更新滞后与覆盖度局限，重大交易建议以"中国执行信息公开网""国家企业信用信息公示系统""裁判文书网"交叉复核；相关结论仅供风险提示、不构成法律意见或资信背书。

  🔴 本技能资信预检结论存在滞后，仅供参考，请用户自行核查。（强制：凡呈现本②步 MCP 资信预检结论，须紧跟附此红色圆点提示，详见强制规则第 5 条统一标准）

• ③ 降级提示（两者均未连接，或用户选 2 不需要时）：

  • 技能必须以醒目方式口头/批注提示用户："当前无法/未授权自动核查相对方资信。请自行通过企查查、天眼查、中国执行信息公开网、国家企业信用信息公示系统、华宇元典裁判文书/案例库等渠道，核查相对方是否存在诉讼、被执行、失信、经营异常等风险，再决定是否继续修改。"
  • 在 modify-plan.json 的 meta.counterparty_credit_check 标注为 未执行（MCP未连接或用户选择不查询，已提示用户自行核查），不得静默跳过。
  • 🔴 本技能资信预检结论存在滞后，仅供参考，请用户自行核查。（强制：本降级提示本身即属"资信预检结论"的一种呈现形态，须紧跟附此红色圆点提示，详见强制规则第 5 条统一标准）

边界约束：资信预检仅作风险提示，不改变合同事实信息，不擅自修改相对方名称、统一社会信用代码等关键信息；发现相对方信息与合同记载矛盾时，按第七部分注意事项提示用户核对。

Step 2 — 加载立场（规划·定锚，按 Step 1 选定视角）

• 读取 references/PLAYBOOK_zh-CN.md，按合同类型套用对应条款立场（PLAYBOOK 已标注各条款的"模块/功能落点"及"三观视角"）。
• 视角套用规则（依据 Step 1 用户选定结果）：
  • 选定 1、甲方利益：直接以 PLAYBOOK 甲方优先立场为基准。
  • 选定 2、乙方利益：将 PLAYBOOK 立场反向套用（以乙方为"我方"、甲方为相对方）重新评估利己性。
  • 选定 3、中立公平：不加载 PLAYBOOK 单方立场，改以"公平、均衡、可交易"的通用标准评估，仅按法条合法性与表述规范落修改。
  • 选定 4、其他（自定义）：以用户填写的具体需求为准，可单独使用或与上述 1/2/3 叠加细化；该需求写入 meta.modify_perspective 并作为作业基准。
• 缺失 Playbook 且用户选定 1/2 视角 → 停止并请用户先建立（提供模板供填空）；若用户选定 3 中立公平或自定义需求不依赖 PLAYBOOK，则可继续。
• 规划三观审视路径：确定"宏观（定性/主体）→ 中观（形式/体例/交易条件）→ 微观（条款/文字）"的审查顺序与重点。
• 明确修改授权边界：仅做文本修订，不代客户决断商务事实（见第七部分注意事项）。

Step 3 — 三观逐层"两比一找"，生成 modify-plan.json（审查修改·核心）

以交易目的为出发点，严格按 宏观 → 中观 → 微观 顺序，每层以"与法律比 / 与利益比 / 找缺陷"为作业动作展开；每层内按《完美的合同》"五大模块 + 三重质量"体检，按杨司和"增删改调"判定 action。可直接复用 references/checklist.md 分层核查。

（一）宏观审视（交易结构·先决层，对应对象模块 + 内在质量"与法律比"）

• 交易定性：合同名实是否相符（如"合作"实为"借款"、"租赁"实为"买卖"），定性错误须 comment/replace 并优先提示。
• 主体适格：各方全称、统一社会信用代码、法定代表人、授权完整（可用企查查 MCP / 华宇元典核验）；主体不适格/授权缺失 → replace/comment。
• 交易模式合法：是否违反效力性强制规定（《中华人民共和国民法典》第 153 条）；违法模式 → comment 提示合规风险。
• 合同程序：需批准/登记/备案/内部决策的是否齐备（《中华人民共和国民法典》第 502 条）；缺失 → comment/insert。
• 担保/增信：是否齐备、可执行（对象模块）。

（二）中观审视（合同形式·体例·交易条件层，对应外在质量 + 五大模块权利义务主线）

• 合同形式与交易阶段匹配：意向书/预约/本约区分（《中华人民共和国民法典》第 495 条）；阴阳合同、空白合同风险 → comment。
• 体例结构：首部/正文/签署/附件齐全；章节编号连续、交叉引用一致；定义表、签署栏齐备（杨司和"体例技术"）。
• 交易条件闭环（权利义务群）：五大模块逐项比对 Playbook 立场，识别义务群遗漏、权利义务失衡、风险分配不当、救济落空（与利益比）；缺口 → insert/replace/comment。
• 名实相符复核：如前在宏观层已定性，此处校验正文表述与定性一致。

（三）微观审视（条款·文字层，对应内在质量/外在质量"语言" + 两比一找 + 杨司和"表述技术"）

• 与法律比（合法性·逐条）：
  • 格式条款公平拟写（《中华人民共和国民法典》第 496–498 条，提示公平拟写义务）。
  • 免责/限制责任条款是否落入无效情形（《中华人民共和国民法典》第 506 条）；违法 → replace/comment。
  • 具体条款效力（如违约金过高可诉请调整、质保期法定下限等）。
• 与利益比（利己性/利益平衡·逐条）：五大模块（质量/价格/期限/对象/违约）逐条比对 Playbook；失衡/不可执行 → replace/comment。
• 找缺陷（逐条）：效力瑕疵、歧义、重点词误用（应当/可以/有权/视为）、句式异常、引用不规范、金额/日期/比例前后不一致。
• 表述技术落地（杨司和）：按 Step 3 第 5 节"表述技术规范"统一重点词、消除歧义、规范列举与引用；确定性错误 → replace，商务取舍/事实缺口 → comment。
• 实战九维并行核查（§3-补）：在以上三观审视的同时，逐项比对「实战审查九维要点（①主体资格→⑨通用方法论）」，识别任一维度缺口（如标的模糊、付款前置、管辖无效、保密期过短、未风险分级等），对应落 insert/replace/comment 并标注 dimension。

每层产出 finding 时，必须同时填写 view（macro/meso/micro）、quality_dim、module、action、risk_level、reason、legal_basis，保证可复核；涉及实战维度的，补充 dimension（①–⑨）以便按龚家勇律师实务口径汇总。

产出 modify-plan.json，字段（在原有基础上增补 view 字段以承载三观视角）：

{
  "meta": {
    "contract_name": "",
    "party_role": "甲方",
    "contract_type": "买卖",
    "playbook": "PLAYBOOK_zh-CN.md",
    "modify_perspective": "甲方利益|乙方利益|中立公平|自定义:<内容>",
    "methodology": "三观四步法(第五版,何力、常金光等著,2024法律出版社)+完美的合同(第四版,吴江水著,2024北京大学出版社)+合同审查与修改实务(杨司和著,2022法律出版社)",
    "generated_at": ""
  },
  "findings": [
    {
      "id": "F1",
      "view": "macro|meso|micro",
      "quality_dim": "inner|outer|layout",
      "module": "quality|price|term|object|liability",
      "clause_func": "statement|promise|exemption|dispute|ancillary",
      "clause": "第X条 条款名",
      "action": "delete|insert|replace|comment",
      "anchor_text": "原句片段（用于定位）",
      "current_text": "原文",
      "proposed_text": "建议改法",
      "risk_level": "高|中|低",
      "reason": "风险/修改理由（含所属三观视角、质量维度与模块依据）",
      "legal_basis": "《中华人民共和国民法典》第X条等（须经 Step 4 核验）",
      "verify_status": "pending|verified|unverified",
      "dimension": "①|②|③|④|⑤|⑥|⑦|⑧|⑨（对应实战审查九维，可选）"
    }
  ]
}

生成方式：可由 AI 在对话中直接产出完整 JSON；也可用骨架生成器 scripts/build_modify_plan.py 先产出模板再填充：

python3 scripts/build_modify_plan.py --name "XXX合同" --role 甲方 --type 买卖 --out modify-plan.json

注意 build_modify_plan.py 生成的骨架中 meta.modify_perspective 字段默认留空，须按 Step 1 选定结果补填（取值：甲方利益 / 乙方利益 / 中立公平 / 自定义:<内容>）。

• view 字段标记该发现所属三观视角（macro/meso/micro），与 quality_dim、module 共同构成"视角—质量—模块"三维追溯链。
• quality_dim 标记内在质量(inner)/外在质量(outer)/版式质量(layout)。
• module 标记五大模块，便于按交易主干回溯。
• action=comment 用于商务取舍、事实缺口、定性/程序提示（不直接改文，落为 Word 批注锚定原文本对应位置，由用户自行决断）。
• action=delete/insert/replace 用于确定性修改（笔误、违法、缺条款、明显失衡），对应杨司和"增删改"。
• dimension 标记该发现所属「实战审查九维要点」（①主体资格/②标的/③价款支付/④履行/⑤违约/⑥保密IP不可抗力/⑦争议管辖/⑧效力形式/⑨通用方法论），与 view/module 并行，便于按龚家勇律师实务口径汇总统计（可选，未覆盖时省略）。

Step 4 — 华宇元典强制校验（法条防线）

• 调用规范详见 references/yuandian-verify.md（前置工具确认、校验流程、结果判定、成本与降级、引用标注格式均以此文件为准）。
• 对所有 legal_basis 非空的 finding，调用华宇元典 MCP（当前可用工具名经 ToolSearch 确认，以下为实测名称；与 references/yuandian-verify.md 一致）：
  • 法条语义检索：yuandian_law_vector_search（按自然语言 query 做法条级语义检索，可按时效性、效力级别过滤）。
  • 法律幻觉检测：yuandian_hall_detect（自动抽取文本中引用的法规/法条和案号，与智库比对语义一致性并核验时效性，输出"一致/不一致/未命中"判定）。
  • 命中且一致 → verify_status=verified，在修订说明中标注"✅ 引用一致"。
  • 未命中 / 不一致 → 修正引用或标 verify_status=unverified 并注"⏳ 待人工复核"。
• ⚡ 加速（不损质量）：去重校验。多条 finding 引用同一条文时，仅对该条文核验一次，结果复用至所有引用它的 finding（同一 legal_basis 字符串归并为一组）。这减少 MCP 往返次数与额度消耗，且因结论统一反而更稳定。可在对话中先对 legal_basis 集合去重再批量调用。
• 成本意识：仅对有法律引用的 finding 校验，不对纯商业条款浪费额度。
• MCP 未连接 → 全部标 unverified，并明确提示用户手动复核法条。

Step 5 — 应用修订（落地·增删改调技术·修订与批注直接落在用户上传文本之上）

调用 scripts/apply_modify_plan.py（其 import 路径已通过 sys.path.insert 指向本技能自带的 scripts/docx/，即与 contract-copilot 同源的 XML 级修订引擎内置副本，二者 ContractReviewer 签名一致）：

• 交付形态重申（对应强制规则第 4 条）：脚本以 --input 指定的用户原文档（DOCX）为母本，在原文本之上叠加修订与批注，不脱离原文另写净稿。输出的 --output 即为"原文本 + 修订痕迹 + 批注痕迹 + 页码"的修订版 DOCX。即：可直接改的内容以 w:del/w:ins 修订痕迹呈现于原文对应位置；需提醒/用户自改的内容以批注锚定原文对应位置。
• 脚本自动解包原 DOCX、读取 modify-plan.json、应用修订、注入页码并重新打包。
• ⚡ 加速（不损质量）：段落预索引定位。apply_modify_plan.py 在应用前构建一次"段落文本→节点"预索引，按 finding 顺序就近定位（build_paragraph_index + locate_node），避免每条 finding 全文档重复扫描；定位失败自动回退至原 find_text 行为。修订落点语义与原逻辑完全一致。
• ⚡ 快路径（迭代场景常态化启用）：可通过 --unpacked <目录> 传入一个调用方自建的持久目录，使脚本不在运行后自动删除该目录（rmtree 清理仅在不传 --unpacked 时触发）。默认行为：同一会话内对同一合同的第二次及后续 apply_modify_plan.py 调用，应复用同一个持久目录传入 --unpacked；仅当用户更换原合同或首次应用时方不传（走 tempfile 自动创建并清理）。实现说明（须与脚本一致，不得误解为"跳过解包"）：脚本在收到 --unpacked <目录> 时，仍以该目录为父目录、在其下 unpacked/ 子目录中重新解包原 DOCX（不会因目录已存在而跳过解包）；--unpacked 的真实价值是"目录生命周期由调用方掌控、不被脚本自动 rmtree"，从而省去每轮 tempfile 创建+删除的系统开销，并可在迭代中复用同一份解包产物做增量比对。交付报告中注明"复用持久解包目录 <目录>"。
• 通过 scripts/docx/reviewer.ContractReviewer（其内部固定 track_revisions=True，修订作者署名由 config/reviewer_profile.json 的 author/initials 注入，强制锁定为 author="WPS"、initials="WP"，任何人/任何配置均不得改为其他名称），将 delete/insert/replace 落为 w:del/w:ins 修订痕迹（对应杨司和"增删改"，即"能直接修改的地方"）；comment 落为 Word 批注（对应杨司和"调"，即"需提醒用户/须由用户自行决断的地方"）。两种痕迹均锚定在原文本对应位置，并存于同一修订版 DOCX 中。
• 非 DOCX 输入的转换前置：当用户上传 PDF / 纯文本时，须先在 Step 1 解包阶段将其转为 DOCX（见 Step 1 解包说明），以转换后的 DOCX 作为 --input 母本进入本步骤；禁止对 PDF/纯文本直接落修订或批注（二者为 Word 原生能力，非 DOCX 载体无法实现）。
• 修订作者署名强制锁定为 config/reviewer_profile.json 的 author="WPS"、initials="WP"（仅用于 DOCX 修订标记，不写入对外交付文档正文；且脚本层已硬锁定为 WPS/WP，任何改动配置或传参都不会产生其他署名）。
• 重新打包为 DOCX，并插入页码（页脚居中，逻辑见 scripts/apply_modify_plan.py 的 inject_page_numbers）。
  • 页码注入范围限制：inject_page_numbers 当前仅向文档**最后一个 w:sectPr（即主节）**注入页脚页码引用，对单节合同完整覆盖；若原合同含多个分节（如独立封面节、正文分节），后续分节不会自动获得页码，交付前须人工确认分节页脚是否已正确落页码。此描述与 scripts/apply_modify_plan.py 中 inject_page_numbers 的实现一致（函数注释亦明确"仅处理主 sectPr，简化实现"）。

实际调用命令（必填 --input / --plan / --output）：

⚠️ 注意：--output 路径不能使用 ~ 简写（Python argparse 不会展开 ~）。须使用绝对路径（如 /Users/用户名/Desktop/...）或在 shell 中用 $HOME/Desktop/... 让 shell 展开。

python3 scripts/apply_modify_plan.py \
  --input "<原合同.docx>" \
  --plan "modify-plan.json" \
  --output "$HOME/Desktop/<合同名>_修订版_<YYYYMMDD>.docx"

可选 --unpacked <持久目录>：指定一个调用方自建的持久目录作为解包父目录（脚本在其下 unpacked/ 子目录重新解包，且运行后不自动删除该目录）。迭代场景默认传入同一个持久目录：同一会话对同一合同重跑时复用；不指定则脚本用 tempfile 自动创建并在结束时清理。注意：--unpacked 不会跳过解包，仅控制目录是否自动清理。 若环境默认 python3 版本不足，使用受管运行时：/Users/gongjiayong/.workbuddy/binaries/python/versions/3.13.12/bin/python3。

Step 6 — 复核与交付（复核·收口）

复核动作（对应《三观四步法》第四步 + "两比一找"闭环）：

• 三观回溯：确认宏观（定性/主体）→ 中观（形式/体例/交易条件）→ 微观（条款/文字）的修改无遗漏、无错位；宏观硬伤已优先处理。
• 重读修订版，确认 delete/insert/replace/comment 与 modify-plan.json 一一对应、无串改。
• 确认未改变原合同日期、金额、当事人称谓等关键信息（笔误修正须已在说明中标注）。
• 汇总未核验法条清单，提示用户人工复核。
• 复核修改是否契合三大理念（交易目的导向、利益平衡与可交易性、歧义控制），避免过度修改阻碍交易。

提交：

• 修订版 DOCX 保存到桌面（绝对路径，如 /Users/用户名/Desktop/{合同名}_修订版_{YYYYMMDD}.docx；注意不能用 ~ 简写）。
• 同时在工作区保留 modify-plan.json（机器可复核清单）。
• 向用户报告（按三观视角 + 质量维度分层呈现）：各视角/维度/模块修改条数、风险等级分布、未核验项清单、文件保存路径。

五、输出规范

• 修订版 DOCX（唯一交付物）：以用户上传文本为母本，同时包含 Word 修订痕迹（w:del/w:ins）与 Word 批注（comments），并插入页码，保存到用户桌面（{合同名}_修订版_{YYYYMMDD}.docx）。本技能不另交付净稿/清稿。
• 修订 vs 批注的呈现分工（强制）：可直接修改的 → 修订痕迹；需提醒或须用户决断的 → 批注。两者在修订版中并存、互不替代。
• 修改说明（随修订版一并返回对话，不强制文件）：按 宏观 / 中观 / 微观 三观视角（并下挂"质量三维度 + 五大模块"）分层呈现，每条含 视角 → 条款 → 动作（修订/批注） → 风险等级 → 原文 → 建议改法 → 依据 → 校验状态。
• 语言：跟随合同语言（中文合同中文输出）。

六、与既有技能的关系

• 复用与 contract-copilot 同源的 XML 级修订引擎（已作为本技能内置副本位于 scripts/docx/，ContractReviewer 签名一致），不重复造轮子。
• contract-review 等批注型技能保持独立；本技能专注"在用户上传文本之上直接落修订痕迹 + 批注痕迹"，修订与批注并存，输出含双痕迹的桌面 DOCX 修订版。

七、注意事项

• 不得改变合同日期、金额、当事人称谓等关键信息（除非 Playbook 明确要求修正笔误，且须在修订说明中标注）。

• 发现原合同矛盾（如前后金额不一致），提醒用户核对，不直接替用户决断事实。

• 【强制锁定·署名必须为 WPS】 批注人、修订人的 DOCX 修订署名统一固定为 "WPS"（缩写 "WP"），禁止使用任何其他名称（含真实审阅人姓名、AI 产品名如 Claude、合同审查助手等）。该署名取 config/reviewer_profile.json 的 author/initials，但已强制锁定为 WPS/WP：无论配置文件如何改动，scripts/apply_modify_plan.py 的 load_reviewer_profile() 始终返回 WPS/WP，scripts/docx/reviewer.py 与 scripts/docx/document.py 的默认值亦为 WPS/WP，任何环节均不会出现其他署名。署名仅用于 DOCX 修订标记，不写入对外交付文档正文；internal_author 字段为技能内部归属记录，严禁写入任何交付文件。此锁定系龚家勇律师明确指令，不得"评估是否改为真实审阅人署名"，不得留有任何改名的余地。

• 三观顺序纪律：宏观（定性/主体）重大缺陷应优先于中观（形式/体例），中观优先于微观（措辞）；内在质量（效力、权利义务）硬伤优先于外在质量与版式质量，不因文字润色掩盖结构问题（融合《三观四步法》视角顺序与《完美的合同》质量优先级）。

• 修改须受三大理念约束（交易目的导向、利益平衡与可交易性、歧义控制）：不因过度严苛或冗余条款阻碍合法交易达成，不因文字优化制造新的歧义（融合三套方法论的共同要求）。

• 杨司和"增删改调"技术规范：确定性错误用"增/删/改"落修订痕迹，商务取舍与事实缺口用"调"（批注）留待客户决断，不越权代决。

• 相对方资信风险提示常态化（选择题询问）：凡接入企查查 MCP 与/或华宇元典法律数据 MCP，在合同修改前须按 Step 1.5 以选择题方式主动询问用户是否查询相对方诉讼/执行案件资信风险（华宇元典侧重相对方作为当事人、被执行人的诉讼与执行案件信号）；用户选择"需要"时方调用 MCP 查询，选择"不需要"时跳过自动查询但仍须口头提示用户自行核查，不得以任何方式静默跳过。该提示仅为风险提示，不构成资信背书或法律意见。

  🔴 本技能资信预检结论存在滞后，仅供参考，请用户自行核查。（强制：凡本注意事项所涉及的任何资信预检相关提示/结论，无论是否经 MCP 查询、无论用户是否选择查询，均须以红色圆点（🔴）附此统一标准语，详见强制规则第 5 条）

• 磋商阶段缔约过失边界（修改行为红线）：AI 修订版若对合同核心/实质性条款（依《中华人民共和国民法典》第 488 条：标的、数量、质量、价款或报酬、履行期限、履行地点和方式、违约责任、解决争议方法）作出变更，须以可留痕方式提示用户取得相对方明确确认，不得擅自修改后直接交付签章，避免一方擅自变更核心条款未告知而被认定承担缔约过失责任（参照 (2025)浙02民终7446 号裁判要旨）。政府采购等依法须按招标文件/中标通知书签订书面合同的，不得对实质性内容作背离性修改（防"黑白合同"无效风险）。商务条款的非实质性细化调整可正常修订，但涉及权利义务实质变化的仍须批注待决。

八、性能优化说明（不影响修改质量）

以下优化仅加速执行，不改变修订痕迹语义、不跳过法条核验、不降低审查深度：

1. Step 4 去重校验：同一 legal_basis 条文只核验一次，结果复用（见 Step 4）。
2. Step 5 段落预索引定位：apply_modify_plan.py 构建一次段落索引、按序就近定位，避免每条 finding 全文档重复扫描（见 Step 5）。
3. Step 5 --unpacked 快路径（迭代场景常态化启用）：调用方自建持久目录并多次复用，避免每轮 tempfile 创建+自动清理开销（见 Step 5）。真实行为：脚本收到 --unpacked <目录> 时仍会在 <目录>/unpacked/ 下重新解包原 DOCX，但不自动 rmtree 该目录（rmtree 仅在不传 --unpacked 时触发）；在同一会话内对同一合同的第二次及后续调用复用同一持久目录传入即可。注意：该优化不跳过解包，仅将目录生命周期交给调用方掌控，避免重复创建/删除系统临时目录的开销，并非"复用已解包内容跳过解包"。
4. AI 侧可并行（注意交互中断）+ Step 1/Step 1.5 交互合并：在无强制交互等待的环节，Step 3 生成 plan 的宏观/中观/微观三观分析可在同一推理轮次内连续产出；Step 4 去重后的法条校验可批量提交。交互合并（省一轮往返，不损质量）：Step 1 的"修改视角"选择题与 Step 1.5 的"资信查询授权"选择题合并为一次 AskUserQuestion 提问（见 Step 1 强制交互段说明）。合并后仍是两问独立作答：视角四选一（1/2/3/4）与资信预检二选一（需要/不需要），二者互不替代；作答内容、写入 modify-plan.json 的字段（meta.modify_perspective、meta.counterparty_credit_check_consent）、以及强制规则第 1、5 条的合规义务均与原分两次提问完全一致。合并仅压缩 UI 轮次，不省略任何强制询问、不静默跳过资信风险提示。须注意：Step 1+1.5 合并提问与 Step 2 加载立场之间仍为强制等待用户作答的断点；上述并行优化仅适用于该断点之后的纯分析/校验阶段，不得假设整条链路无中断。