技能介绍

它解决的具体问题

把合同丢进对话框之后，真正的成本不在“看不懂条款”，而在风险结论、Word 批注、审查意见书之间是断裂的。手动复制法条、逐条加批注、再单独整理一份意见书，既容易漏改，也说不清某条批注对应哪个风险等级。这个技能要处理的正是从 DOCX 输入到两份交付文件的完整链路。

核心能力与工作路径

审查阶段走“三层四步”框架：先看宏观交易结构、中观文本形式、微观条款语言；再按前置澄清、分层扫描、条款落地、交付跟进推进。用户未说明立场时，会先确认甲方 / 乙方 / 中立与克制 / 常规 / 强势口径；命中历史记录则默认沿用。

每个风险点按 P0 / P1 / P2 分级，并输出风险后果、判别标准、推荐措辞、整改建议、法律依据等字段。确定性问题直接落入正文修订，留空项、待补事实和谈判项转为批注，程序优化型问题只写入意见书，避免正文被低价值改动淹没。

交付阶段执行 scripts/review/apply_review_plan.py 后，默认产出审核修订版 contract_reviewed.docx 与 Word 审查意见书 contract_reviewed_审查报告.docx；计划、Markdown 报告和执行日志归档到 archive/。意见书采用律师出件版式，详细意见以表格对照风险、原条款、建议修改与依据。

起草阶段通过 references/contract-routing.md 生成起草路由卡，再用 templates/合同起草信息清单.md 固定文件包与待补事实，从 12 类合同主文件和 templates/条款库.md 抽取结构与措辞；缺失信息统一标注未提及 / 待补充，不臆造商业安排。

适用边界与注意点

分类固定为 12 类合同；混合交易按实质归入“主合同类型 + 配套协议类型”双标签。运行脚本前需要本地 Python 安装 defusedxml 与 lxml。审查人身份、客户名称、审查立场缺失时会先追问再执行。只输出文字清单不视为完成；文件来自飞书等 IM 时，默认回传原会话。该技能是辅助工具，不替代律师出具正式法律意见。