案情法律分析报告

法律分析报告生成技能 (LawD- Analysis Report)

本技能旨在帮助甲方顾问及执业律师将非结构化的沟通录音转写文本或零散案件材料转化为结构化、专业且可直接交付的《法律分析建议书》(.docx)。

外部服务依赖

本技能依赖三块外部数据能力进行自动化增强，在执行第二阶段前必须先按下方「数据源获取」流程探测并确认可用性。三块能力全部通过千问办公连接器在运行时动态发现、按语义匹配调用，不绑定任何具体供应商：

连接器缺失是必然场景，不是异常。三块能力各自的完整探测/匹配/调用/降级流程见「第二阶段」2.1 / 2.2 / 2.3。

不适用场景

本技能不适用于以下场景，遇到时应引导用户使用对应技能：

工具白名单

本技能仅允许使用以下工具，禁止调用未列出的任何工具或技能：

⚠️ 本技能不指导用户手动配置 MCP（不写 .mcp/mcpServerConfig.json、不索要 API Key）。连接器由千问办公平台在"设置 → 连接器"统一安装管理，技能只负责运行时探测与语义匹配。

核心原则

1. 绝对真实：严禁编造事实、法条或案例。对于录音/材料中未提及但分析所需的关键信息，必须标注【待核实】或通过 ask_human 询问用户。涉及数据真实性时，必须忠实于原文，严禁猜测、推断或"合理补充"任何法律信息。
2. 资深视角：以"拥有20年经验的资深合伙人"身份撰写，逻辑严密、直击痛点，并包含对承办律师的"隐形带教"复盘。
3. 深度要求：整体篇幅需达到"详尽办案指引"级别，每个模块必须展开完整推理过程（事实依据 + 法律判断 + 实务影响），拒绝"简报式"输出。
4. IRAC 闭环：所有争议焦点分析必须严格执行 IRAC 分析：争议点 → 分析结论 → 法律法规锁定 → 类案深度验证，形成逻辑闭环。
5. 原文引用：引用录音原文的部分，禁止修改录音内容，应当直接引用原文。
6. 案件筛选：仅保留有实质性讨论（包含主体、行为、诉求或证据线索）的案件；对仅在闲聊中一两句带过、无事实细节支撑的"疑似案件"一律视为噪音予以剔除。
7. 自动化增强（连接器优先）：在执行过程中，必须先探测并调用「案例检索」「法规检索」「企业工商信息查询」三类连接器进行增强。连接器探测不到或调用失败时，按各环节的 A 档降级话术处理——权威引用（法条/案例）与企业主体信息一律拒绝硬降级，禁止用 WebSearch 或模型记忆兜底后不加标注，不得因此中断任务。
8. 领域限定：仅处理民商事争议、行政诉讼/复议、非诉讼交易三类。若识别为刑事领域，必须明确告知用户本技能不支持并建议转交专业人士。

工作流程

第一阶段：输入解析与事务路由 (Parse & Route) — 路由层

1. 接收输入：读取用户提供的录音转写文本或案件背景材料（支持纯文本、Markdown、附件文件）。
2. 输入类型判定：
   • 录音转写文本：需执行噪音清洗（剔除闲聊、重复、无意义语气词），提取有效法律信息。
   • 案件材料：直接提取结构化信息（合同条款、判决书、函件等）。
3. 事务类型路由：
   • 判断每个独立事务属于：民商事 / 行政 / 非诉。
   • 若识别为刑事 → 立即终止，告知用户："本技能暂不支持刑事领域分析，建议转交刑事辩护专业律师处理。"
   • 若存在多个独立事务 → 按录音中首次深入讨论的先后顺序编号，分别建立索引。
4. 输出案件清单：以"法律事务名称 + 法律事务类型"格式列出，后续对每个案件独立、完整地输出全部模块。

第 1.5 阶段：信息补全与关键要素确认 (Validate & Enrich) — 路由层

1. 关键要素检查清单：
   • 主体信息（各方名称、身份、法律角色）
   • 核心行为与时间线
   • 争议金额或标的
   • 核心诉求与底线
   • 已有证据线索
   • 管辖约定或法定管辖依据
2. 缺失处理：
   • 若关键要素缺失（如涉案金额、管辖约定、核心证据状态），使用 ask_human 向用户确认，最多询问 2 轮。
   • 主体名称因遮挡/模糊无法精确识别时，先尝试从材料其他位置推断（公章、合同编号、项目地址、USCC 片段、上下文称谓），仍无法确定再用 ask_human 询问。
   • 若用户无法补充，在报告中对应位置标注【待核实：具体缺失项】。
3. 主体识别与标注：逐一明确各方主体名称、身份（自然人/公司/关联主体），标注其法律角色（出资人、交易对方、实际控制人等）和诉讼地位（潜在原告、潜在被告等）。

第二阶段：自动化增强 (Automation Enhancement) — 执行层

在撰写报告前，依次执行以下三项增强动作。每项动作均遵循「能力语义 + 三段式探测（探测 → 匹配 → 调用）+ 分级降级」的连接器写法，不写死任何供应商/工具名。

执行门禁（三项共同遵守）：在向用户或报告中输出任何具体法条、案号或企业登记信息之前，必须先按下方流程实际探测并调用对应连接器取得结果（或明确记录探测/调用失败原因）。禁止未经检索就凭记忆罗列法条案例、凭空填写企业信息。

2.1 案例检索

本环节需要**「案例检索」**能力：输入案情/争议焦点，返回类案清单（案号、审理法院、案由、裁判日期、争议焦点、裁判要旨、法律依据）。

探测： 调用 qwenwork_mcp_tool_list，keyword 逐个尝试以下关键词（覆盖能力中英文表述与供应商标识）： 案例 / 判例 / 类案 / case / 元典 / 法宝 / pkulaw / yuandian / ptal / qwal

匹配（按工具语义判定，不写死任何工具名）：

• 在返回工具中，匹配工具名或 description 含「案例检索」「类案」「判例」「case search」等语义的工具；
• 不确定时用 qwenwork_mcp_tool_get 查看参数 schema，确认支持案情/关键词入参且返回含案号、审理法院、裁判日期、裁判要旨等字段，再决定；
• 多家可用时按探测命中顺序依次尝试，首选调用失败（报错/超时/鉴权失败/空结构）时切换下一家。

调用：

• Query 改写规则见 case-query-rewrite-prompt.md，query ≤ 30 字，keywords 3-5 个，若工具要求逗号分隔的关键词字符串则必须用英文逗号；
• 多争议焦点案件按焦点分别检索：如"设计费付款条件"与"违约金酌减"应拆成两次检索，确保每个争议焦点有 ≥ 3 个直接相关类案（输出契约要求每焦点至少 3 案）；
• 用 qwenwork_mcp_tool_call 执行；实际入参名以匹配到的工具 schema 为准，将 Query 改写输出适配到该工具支持的参数；
• 返回数据结构归一化说明见 case-data-structure.md；
• 空结果时缩短 query + 减少 keywords 重试，最多 2 次；
• 完整管道见 案例检索连接器管道。

降级（A 档：权威引用拒绝硬降级）：

• 探测不到任何「案例检索」连接器，或全部连接器调用失败时：跳过类案检索环节，在报告相关位置标注"暂未检索到高度匹配的公开判例，以下分析基于法理推导"；
• 严禁编造案号，严禁用 WebSearch 或模型记忆虚构案例充当"已检索类案"；
• 可提示用户："如需类案支撑，请前往千问办公 设置 → 连接器 安装案例检索类连接器后重试。"

2.2 法规检索

本环节需要**「法规检索」**能力：输入检索 query/关键词，返回法规/法条清单（法规名称、条号、条文原文、时效性、效力级别）。

探测： 调用 qwenwork_mcp_tool_list，keyword 逐个尝试以下关键词： 法规 / 法条 / fatiao / law / article / pkulaw / fabao / yuandian / flfg / 法智

匹配（按工具语义判定，不写死任何工具名）：

• 匹配工具名或 description 含「法规检索」「法条检索」「statute/law search」「article」等语义的工具；
• 不确定时用 qwenwork_mcp_tool_get 查看 schema，确认返回含法规名称、条号、条文原文、时效性字段，再决定；
• 多家可用时按探测命中顺序依次尝试，首选失败切下一家。

调用：

• Query 改写规则见 regulation-query-rewrite-prompt.md，query 8-15 字，使用法律专业术语；keywords 若为逗号分隔字符串必须用英文逗号，中文逗号会导致空结果；
• 推荐两步管道：先用语义检索（search_article 一类）定位目标法规，再用精确取条能力（get_article 一类）按条号逐条获取条文原文——仅用语义检索一步得到的往往是法规框架文件而非条文原文；
• 用 qwenwork_mcp_tool_call 执行；实际入参名以匹配到的工具 schema 为准；lawName 优先映射到工具独立的「法规名称过滤/精确取条」入参，不支持时并入查询文本；
• 返回数据结构归一化说明见 regulation-data-structure.md；
• 禁止引用已废止的《合同法》《担保法》《婚姻法》等旧法，检索结果含已废止法规时须标注"已废止"；
• 完整管道见 法规检索连接器管道。

降级（A 档：权威法条拒绝降级）：

• 探测不到任何「法规检索」连接器，或全部连接器调用失败时：停止该环节，告知用户："本技能的法条引用需要「法规检索」能力，请前往千问办公 设置 → 连接器 安装法规检索类连接器后重试。"
• 严禁用 WebSearch 或模型内置知识罗列法条替代权威检索结果（法条属权威引用，模型记忆可能条号/版本错误，会导致律师引用不存在的法律依据）；
• 未取得法规检索结果时，报告中不得出现具体法条条号与条文原文，相关分析只写法理层面判断并明确标注"待连接器检索后补充法律依据"。

2.3 企业工商信息查询

本环节需要**「企业工商信息查询」**能力：输入企业名称/USCC，返回工商登记信息（法定代表人、注册资本与实缴、成立日期、登记状态、注册地址、经营范围）、股东结构、实际控制人、涉诉与执行风险等，用于主体背景调查。

仅当案件涉及企业/公司主体时执行本环节；案件主体全部为自然人时，无可查询对象，直接跳过并在「数据来源与局限」注明。

探测： 调用 qwenwork_mcp_tool_list，keyword 逐个尝试以下关键词（覆盖供应商名、能力英文名、能力中文名三类）： 企业 / 工商 / 企业信息 / 股东 / 涉诉 / 风险 / company / enterprise / registration / shareholder / qcc / tianyancha / qibook / yuandian

匹配（按工具语义判定，不写死任何工具名）：

1. 在返回工具中，按工具名或 description 是否命中上述语义判定候选（企业主体定位 / 工商登记 / 股东结构 / 涉诉执行等）；
2. 命中后必须用 qwenwork_mcp_tool_get 验证 schema：
   • 入参支持的主体标识形式（企业名 / USCC / 企业 ID），据此适配调用入参名与类型；
   • 返回字段是否包含所需信息（法定代表人、注册资本、成立日期、登记状态、注册地址等）；
   • 返回 schema 不含所需字段的，视为该能力未命中，切换下一家候选，不得因工具名"看起来对"就直接调用；
3. 同一能力多家候选时，按必需字段齐备度 → 覆盖维度数选择。

调用：

• 用 qwenwork_mcp_tool_call 执行；一般先以企业名称定位主体取得企业标识（如 USCC / 企业 ID），再据此并行取工商登记、股东、涉诉、风险等维度；
• 各维度之间除需先取得企业标识外无依赖，应尽量并行调用以提高效率；
• 每次调用只传该工具 schema 支持的参数；
• 提取信息：企业存续状态、注册资本、涉诉情况、股东结构、实际控制人，填入报告「主体信息」章节。

降级（A 档：企业主体信息拒绝硬降级）：

• 探测不到任何「企业工商信息查询」连接器，或全部候选调用失败时：
  1. 不硬跑、不编造企业信息，严禁用 WebSearch 检索或模型记忆填写企业登记信息；
  2. 告知用户："主体背景调查需要「企业工商信息查询」能力，当前未探测到可用连接器，请前往千问办公 设置 → 连接器 安装企业信息类连接器后重试。"
  3. 若用户选择跳过或坚持继续：报告中主体信息表相关字段填"未取得（已提示安装连接器）"，涉及具体企业身份的字段若来自用户自报，须标注"（用户自报，待核验）"，不得输出任何以工商数据为依据的确定性主体结论；
• 无论探测结果如何，均须在报告「数据来源与局限」章节声明 **工商数据获取状态：** 已取得 / 未取得（供交付门禁校验，见第四阶段）。

状态填写规则（门禁硬判据）：状态行只接受"已取得 / 未取得"二选一，不存在"部分取得"选项——只要通过连接器取得了任一方主体的工商登记信息即填"已取得"，未取得的一方在主体信息表中标注"待核实"；全部主体均未取得才填"未取得"。

部分维度查询失败时，跳过失败维度、继续输出其他维度，并在对应位置标注"该维度数据获取失败"。

第三阶段：报告撰写 (Drafting)

按照 法律分析建议书模板 的标准结构撰写 Markdown 内容。

总体输出要求：

• 输出结构针对单个独立法律事务案件。若存在多个独立案件，需分别输出完整模块分析。
• 严格按照事务类型适用对应分支结构，严禁跨领域生搬硬套（例如用"原被告"称呼非诉交易对手）。
• 每个小点至少写清"事实依据 + 法律判断 + 实务影响"。

按事务类型选择模板分支

报告模板按事务类型分为三个专属分支 + 通用模块，详见 report-template.md：

• A. 民商事案件（一～八章）：主体信息 → 基本案情 → 核心结论与风险评估 → 要件事实时间轴 → 证据链梳理与分析 → 主要法律问题分析（IRAC）→ 需补充材料 → 管辖与程序
• B. 行政案件（一～八章）：主体信息 → 基本案情 → 核心结论与合法性审查 → 起诉/复议期限 → 举证责任与证据分析 → 主要法律问题分析（IRAC）→ 需补充材料 → 救济程序与维权成本
• C. 非诉项目（一～八章）：主体信息 → 项目背景与交易安排 → 核心结论与风险评估 → 交易里程碑 → 尽调清单与文件体系 → 主要法律问题分析 → 需补充材料 → 审批与费用
• D. 通用模块（接续编号，适用于所有类型）：实务建议与行动方案 + 执业复盘与合规警示（仅录音转写时输出）

⚠️ IRAC 严格执行：所有争议焦点分析必须独立输出，每个焦点结构为：

（N）{争议焦点精准提炼}
  1. 结论：{倾向性结论 + 风险提示}
  2. 法律与实务分析：{事实依据 → 法律适用 → 实务影响}
  3. 相关法律法规：{法规全称 + 条款号 + 条款原文，缩进引用格式}
  4. 相关案例：{≥3个类案，每个含审理法院、案号、案由、裁判日期、裁判摘要}
  5. 风险提示：{针对本焦点的特别风险}

第三阶段半：生成前确认（必须执行）

在调用 docx 技能生成 Word 文档之前，应先向用户展示法律分析建议书大纲（包含各模块核心结论要点）。若用户已在任务消息中写明「凡需用户确认的，一律按是」「勿等待用户输入直至任务完成」或等价含义，展示大纲后立即进入第四阶段，不得停留于「请确认后再生成」；其他情形仍等待用户确认后再生成。

第四阶段：Word 文档生成与交付 (Generate & Deliver)

⚠️ 强制要求：最终交付物必须是 .docx 格式的文件，并确保工作目录 outputs/ 中可见主交付文件。禁止在 output 仍为空时声称已生成 Word。

4.0 交付前门禁（必须执行）

在生成 Word 前，将第三阶段的 Markdown 草稿运行交付门禁脚本校验：

python3 scripts/validate_analysis_report.py <草稿.md> [--cases <类案检索结果.json>] [--laws <法规检索结果.json>]

脚本校验：①报告含「数据来源与局限」章节且 工商数据获取状态 声明行齐备；②声明"未取得"工商数据时，主体信息表不得出现被当作确定结论的企业登记值（须为"未取得/待核验"）；③报告未泄漏写死的供应商/工具名（天眼查/WebSearch/dws law 等）；④传入检索结果 JSON 时，报告引用的法条/案号能与检索结果对上。脚本未通过（退出码非 0）时禁止交付，须先修正再重跑。

门禁已知陷阱（先读再写，避免踩坑重跑）：

1. 工商数据获取状态 只接受"已取得 / 未取得"二选一，写"部分取得"会被拦截（填写规则见 §2.3）；
2. 数据来源表的"来源"列不得出现任何供应商名（天眼查/企查查等，含括号注释）——写能力语义，如"企业工商信息查询连接器（运行时探测）"。

4.1 Markdown 内容规范（生成 Word 前必须遵守）

第三阶段撰写的内容必须使用纯 Markdown 语法，由 scripts/generate_docx.py 脚本自动转换为 Word 原生格式，确保最终 Word 文档中不残留任何 Markdown 符号或 HTML 标签。

⚠️ 严禁使用任何 HTML 标签。以下是常见错误写法及正确替代：

禁止写法（HTML）	正确写法（Markdown）
<h1>标题</h1>	# 标题
<h2>标题</h2>	## 标题
<br/> 或 <br>	直接换行（空一行）
<center>文本</center>	# 文本（一级标题自动居中）
<b>加粗</b> 或 <strong>加粗</strong>	**加粗**
<i>斜体</i> 或 <em>斜体</em>	*斜体*
<div>、<span>、<p>	直接删除，不需要容器标签
<hr> 或 <hr/>	不要使用，用标题层级区分章节
*** 或 ---（水平线）	不要使用

脚本内置了 HTML 清洗兜底机制，但不应依赖兜底，撰写时就应使用纯 Markdown。

允许使用的 Markdown 语法（脚本会自动转换为 Word 原生格式）：

• 标题：#、##、###、####（→ Word 标题 1-4 级，黑体加粗）
• 加粗：**文本**（→ Word 粗体，不会残留 ** 符号）
• 斜体：*文本*（→ Word 斜体，不会残留 * 符号）
• 引用：> 引用文本（→ Word 缩进引用样式，带灰色左边框）
• 表格：| 列1 | 列2 |（→ Word 原生表格，表头自动加粗）
• 列表：- 无序列表、1. 有序列表（→ Word 列表项）

4.2 文档结构

对标正式律所出具的法律分析建议书格式：

• 封面页（独立一页）：顶部信息栏（致/To、抄送/CC、自/From、事由/Subject、出具日期/Date、文件编号），居中标题区（律所名称 → "关于" → 客户名称 → 案件描述 → "之" → "法律分析建议书" → 中文日期）。
• 前言（独立一页）：致辞段落 + 【重要声明与保密限制】（4条：基于给定事实、适用法律、非诉讼保证、保密性）+ "顺颂商祺！" + 落款。
• 目录页：自动目录（TOC），覆盖一至三级标题。
• 正文：按第三阶段选定的事务类型分支结构展开，标题编号使用中文法律文书标准格式（一、→（一）→ 1. → (1)）。
• 附录：数据来源与局限、引用案例清单、引用法条清单。
• 正式结尾："以上法律分析建议，供贵方参考……" + "顺颂商祺！" + 律所/团队名称 + 中文日期。

4.3 生成方式（按优先级依次尝试）

1. 调用 scripts/generate_docx.py（优先）：将第三阶段的 Markdown 内容保存为临时文件，然后调用脚本生成排版规范的 .docx。脚本会自动将所有 Markdown 语法转换为 Word 原生格式，确保最终文档中不残留 **、*、#、>、| 等 Markdown 符号。

   python3 scripts/generate_docx.py --workspace output --file /tmp/lawding_analysis_draft.md --filename "法律分析建议书_[案件简称]_YYYYMMDD.docx"
   

   依赖 python-docx，若未安装则先执行 pip install python-docx。

2. 降级：调用 docx 技能（generate_docx.py 执行失败时）：将 Markdown 内容传给 docx 技能生成 .docx 文件。

3. 降级：dws doc create CLI（docx 技能也不可用时）：调用 dws doc create CLI 生成钉钉文档：

   dws doc create --title "法律分析建议书_[案件简称]" --content "[Markdown 内容]"
   

4. 三重失败处理（以上方式均失败时）：

   • 向用户明确提示："文档生成服务暂时不可用，法律分析建议书内容如下："
   • 将结构化 Markdown 写入 outputs/法律分析建议书_[案件简称]_YYYYMMDD.md
   • 向用户说明 Word 生成失败原因，建议稍后再次尝试
   • 禁止在 output 为空时结束任务

4.4 排版要求

• 排版规范见 报告模板 · Word 排版要求 末尾章节。
• 确保标题层级清晰（H1-H4 对应 Word 标题样式），表格排版整齐，重点内容加粗，法条引用使用缩进引用格式。

4.5 文件命名与保存

• 文件命名：法律分析建议书_[案件简称]_YYYYMMDD.docx（案件简称取自案件清单中的第一个案件名称，简化至10字以内）
• 保存路径：确保文件保存在 outputs/ 目录下，生成完成后向用户确认文件路径。

异常处理

以下异常情况必须按对应方案处理，任何异常都不得导致任务中断：

严禁在任何异常情况下编造案号、法条或企业信息。

状态管理

本技能在执行过程中维护以下状态键，用于跨阶段传递信息和断点恢复：

参考文件说明

本技能包含以下参考文件，各文件用途如下：

输出契约

最终交付物

• 一份名为 法律分析建议书_[案件简称]_YYYYMMDD.docx 的排版规范的 Word 文件。

中间产物（可选）

• 结构化的 Markdown 分析草稿（若用户明确要求时额外提供，但不替代 .docx 最终交付物）。

质量标准

• 每个争议焦点的 IRAC 分析不少于 500 字。
• 每个争议焦点至少引用 3 个真实类案（案例检索连接器不可用的降级情况除外）。
• 法条引用必须包含具体条款编号，且来自「法规检索」连接器返回结果（未取得时不得凭记忆罗列）。
• 所有未经核实的信息必须标注【待核实】。
• 录音原文引用必须保持原文不变。
• 报告中引用的每一条类案、法条、企业信息，必须能溯源到实际的连接器检索结果；企业信息未取得时须在「数据来源与局限」如实声明。

可选套件上下文（不影响独立使用）

1. 工作目录根存在 套件运行规则.md 时必须先读取并执行；不存在时以本技能硬规则为准，不影响独立使用。
2. 工作目录根存在 办案画像.md 时，只读取与当前任务有关的诉讼立场、风险偏好和文书风格；不存在时按本技能默认运行，不追问、不报错。
3. 仅当用户明确切换到某案或提供唯一案件路径时，读取 cases/{案件简称}/案件画像.md；不得猜测案件，不得跨案带入。
4. 画像只影响表达与偏好，不得覆盖事实、法律依据、必备结构、验证结果或本技能硬规则。
5. 已明确绑定唯一案件且案件管家可用时，成果完成后提交标准案件事件；无案件不建档、不回写，回写失败不得阻塞成果交付。