法律研究报告

---
name: 法律研究报告
version: 1.0.0
description: >
  生成中国法律研究报告（Markdown 格式）。当用户描述涉及中国法律的事实情景、
  提出法律争议问题、询问某行为是否合法合规、要求分析法律条文适用性、
  或提及"法律研究""法律检索""合规分析""法律意见""研究报告"时触发。
  基于法律检索后端（元典/北大法宝，运行时自动适配+灾备，见 qoder.md「外部能力后端」）一手权威资料检索 + SEARCH.* 搜索二手文献，按 IRAC/CREAC
  推理框架分析，并依据用户画像自动切换律师视角 / 法务视角的结论导向。
---

# 法律研究报告

针对中国法律问题进行系统性检索与分析，输出一份结构简洁、依据透明的《法律研究报告》（**仅 Markdown 格式**）。研究框架参考 IRAC/CREAC 推理模式，一手权威资料经法律检索后端（元典/北大法宝，运行时自动适配+灾备，见 qoder.md「外部能力后端」）校验，二手文献经 SEARCH.* 搜索引出线索。

## 核心设计：双视角结论导向

本 skill 的结论部分根据**用户画像自动切换视角**，无需用户每次说明自己的身份。视角差异集中体现在「核心结论」与「实务建议」两节：

| 视角 | 适用画像 | 结论导向 | 关键措辞 |
|------|----------|----------|----------|
| **律师视角** | 外部律师 / 执业律师 | 从**委托事项处理**角度写结论：讲清**客户的法律风险** + **律师的建议思路** | "委托人/当事人""建议代理方案""诉讼/谈判策略" |
| **法务视角** | 公司法务 / 法律顾问 / 合规 | 从**业务咨询事项**角度写结论：讲清**公司的法律风险** + **法务的意见思路** | "我司/本公司""业务建议""合规口径" |
| **客观研究** | 纯概括性 / 学理性问题 | **仅总结客观研究结论**，不做视角化建议 | 中立陈述，不预设委托/业务场景 |

### 视角判定流程

1. **读取用户画像**：尝试读取套件根目录的 `qoder.md`，提取用户身份（律师 / 法务 / 其他）。
2. **判定视角**：
   - 画像显示「律师/律所/执业」→ 律师视角
   - 画像显示「法务/法律顾问/合规/公司内部」→ 法务视角
   - 无 `qoder.md` 或身份不明 → **询问用户一次**（律师 / 法务 / 仅客观研究），记住本次选择，不再重复询问
3. **纯概括性问题豁免**：若用户的问题是抽象法律概念辨析、学理探讨、纯法规梳理（无具体委托人或业务场景），无论画像如何，结论一律采用「客观研究」模式，只总结客观研究结论。

## 结论硬性要求

无论何种视角，「核心结论」一节必须遵守：

1. **篇幅 ≤ 500 字**——只下概括性论断，不做细节推演（推演过程放在「分析论证」节）。
2. **不假设未给信息**——绝不基于用户未提供的事实进行假设、想象或脑补。事实缺口必须在「研究前提」节明确列出，并说明其对结论的影响，而非自行填补。
3. **风险 + 建议两段式**（客观研究模式仅保留客观结论）：先讲清法律风险，再给视角化的处理/意见思路。
4. **确定性分层**——对有分歧或把握不足的问题，明确区分"较强观点""较稳妥观点""待进一步核实事项"，不强行给出唯一答案。

## 前置条件

| 序号 | 条件 | 必要性 | 说明 |
|------|------|--------|------|
| 1 | 用户的法律问题或事实情景 | 必需 | 从对话上下文获取，无需重复输入 |
| 2 | 法律检索后端（元典/北大法宝） | 推荐 | 一手法条/案例检索校验；不可用时降级（见降级策略） |
| 3 | SEARCH.*（搜索 MCP） | 可选 | 二手文献检索；不可用时跳过二手阶段 |
| 4 | 套件根目录 `qoder.md` | 可选 | 用于自动判定视角；无则询问用户一次 |

## 工作原则

1. **客观性**：报告用于识别风险，不为某一方辩护。不挑选有利案例，负面判例同样必须呈现。
2. **一手资料为王**：最终结论只能依据法律法规和裁判文书。二手文献只用于构建框架、引出线索。
3. **每引必校验**：正文每引用一条法规 / 法条 / 案例，立即通过法律检索后端核验其存在性、原文与时效性；核验不通过则用权威原文替换或标注，**绝不用记忆替代**。
4. **来源透明**：法条经校验后引用无需贴来源标签；二手文献引用须写明"据[机构名][作者]《标题》"并附 URL；自身推理在段末注"（分析推断）"。
5. **时效优先**：优先引用"现行有效"法规，已失效/已修改的必须明确标注。
6. **冲突处理**：上位法 > 下位法；新法 > 旧法；特别法 > 普通法。
7. **积分意识**：案例检索分两阶段消耗——先检索摘要，确需裁判说理全文时再调 `LAW.case_detail`，调用前向用户说明。正确性优先于积分节约。
8. **言简意赅，实事求是**。

## MCP 工具映射

本套件统一走 MCP 调用，**不依赖任何本地脚本或 API Key 配置文件**。调用前先用 `qw_mcp_get` 确认参数 schema。

> 实际工具名由运行时 `qw_mcp_list` 探测解析（元典/北大法宝等），映射见 qoder.md「外部能力后端」；本表只列能力名，不绑定供应商。

#### MCP 预检

正式检索前，先调用 `qw_mcp_list` 探测以下后端是否可用：
- **法律检索**：关键词 `law`/`yuandian`/`pkulaw`/`法宝` → 映射 LAW.*
- **全网搜索**：关键词 `search`/`搜索`/`web`/`AiSearch` → 映射 SEARCH.*
- **知识库**（可选）：关键词 `qmind`/`knowledge` → 映射 qmind（第三阶段 Part A 使用；`qoder.md`「知识库方案」未配置则跳过）

**探测结果处理**：
- **法律检索不可用** → 用 `AskUserQuestion` 告知用户："法律检索 MCP 未连接，报告中的法条和案例引用将无法自动校验。建议前往 QoderWork → 设置 → 连接器 中配置元典或北大法宝。是否暂不配置、以降级模式继续？"
- **SEARCH.* 不可用** → 告知用户："全网搜索 MCP 未连接，二手文献阶段将跳过。是否继续？"
- **qmind 不可用且已配置** → 静默跳过内部知识库预检索（Part A），直接进入 Part B。

> 探测协议详见 qoder.md「MCP 预检协议」。

### 一手权威资料（法律检索后端：元典/北大法宝）

| 用途 | 能力名 | 说明 |
|------|----------|------|
| 法条关键词检索 | `LAW.article_search` | 已知精确术语时用 |
| 法条语义检索 | `LAW.semantic_search` | 问题模糊/口语化时用 |
| 法条详情原文 | `LAW.article_detail` | 校验法条原文与时效 |
| 法规关键词检索 | `LAW.statute_search` | 查整部法规 |
| 法规详情 | `LAW.statute_detail` | 法规全文（含效力状态） |
| 权威案例检索 | `LAW.case_search` | 指导性/典型案例 |
| 普通案例检索 | `LAW.case_search` | 裁判文书 |
| 案例语义检索 | `LAW.case_semantic` | 找事实相似判例，召回更全 |
| 案例详情全文 | `LAW.case_detail` | 第二阶段，需分析裁判说理时调用 |
| 引用一键核验 | `LAW.citation_verify` | 幻觉校验/引用溯源 |

**关键词检索 vs 语义检索原则**：已知具体法规名/法条号/案号，或二手文献已提炼精确术语 → 关键词检索；问题模糊、口语描述、术语不确定，或需跨法规发现相关条文 → 语义检索。

### 二手文献（SEARCH.*）

| 用途 | MCP 工具 | 说明 |
|------|----------|------|
| 综合二手检索 | `SEARCH.web_search` / `SEARCH.ai_search` | 律所文章、政府解读、学术文献 |
| 链接正文提取 | WebFetch（内置） | 提取检索到的文章正文 |

关注头部律所文章、政府政策解读、法学期刊学术文章。

## 八阶段工作流

### 第一阶段：信息完整性检查 + 视角判定

1. **判定视角**：按「视角判定流程」读取 `qoder.md` 或询问用户一次，确定本次报告的视角（律师 / 法务 / 客观研究）。
2. **信息完整性**：
   - **事实陈述型**：核验主体信息（谁、主体性质）、核心事实（时间/地点/事件）、争议问题。
   - **法律问题型**：核验问题完整性，确认适用法域。
3. 信息不完整时向用户补问。**不在信息不足时开始研究，也不自行假设缺失事实。**

### 第二阶段：研究问题的提出与确认

- 事实陈述 → 归纳为法律争议问题；法律问题 → 规范化表述。
- 向用户列出并**等待确认**后方可推进：
  1. 归纳的核心法律争议问题（1-3 条）
  2. 拟研究的范围与方向
  3. 关键前提假设（如有）

> **硬性暂停**：未收到用户确认，禁止开始任何检索（含法律检索后端与全网搜索 MCP 调用）。

### 第三阶段：二手文献检索 + 内部知识库预检索

**A. 内部知识库预检索**（可选）：

> **触发条件**：`qoder.md`「知识库方案」已配置（qmind 或协作平台文档）且参数齐备。未配置则跳过 A 直接进入 B。

先问内部知识库——团队之前是否研究过类似问题、沉淀过相关法规解读或裁判分析。避免重复劳动，让研究站在团队经验的肩膀上。

调用方式按所选载体：
- **qmind**：调用 qmind retrieve，输入"<法律争议问题+案由+关键术语>"+ 对应板块 notebook ID（优先「工作笔记」板块）。
- **协作平台文档**（`COLLAB.doc_read`）：经协作平台在知识库空间内关键字搜索 → 读相关文档全文 → 综合回答。

返回结果统一标注 `[KB:诉讼知识库]`。若找到高相关历史研究成果，后续检索可优先沿用其法规/案例路径。知识库不可用时静默跳过，不阻断主流程。

**B. 二手文献检索**（SEARCH.*）：

用 SEARCH.* 搜索能力构建问题框架、引出一手线索。依次检索：政府解读/官方答复 → 头部律所文章 → 学术文献。国内问题用中文，涉外问题加英文。关注文章引用的法规条号、案号、解读要点。如 SEARCH.* 不可用，跳过本阶段直接进入一手检索。

### 第四阶段：二手文献分析

从结果提取：① 引用的法规清单（名称+条号，待校验）② 引用的案例（案号/案名，待校验）③ 扩展关键词（供第五阶段）。

### 第五阶段：一手权威资料检索与验证

1. **验证二手引用**：对每条提取的法条调 `LAW.article_detail` 核实是否真实存在、内容一致、现行有效。
2. **扩展检索**：用 `LAW.article_search` / `LAW.statute_search` 检索法条法规；用 `LAW.case_search` 检索权威/普通案例。
3. **语义检索补充**：关键词召回 < 3 条或问题模糊时，追加 `LAW.semantic_search` / `LAW.case_semantic`，优先取相似度高的结果，仍须取原文后再引用。
4. **按需取全文**（积分第二阶段）：案例高度相关、需分析裁判说理时，向用户说明后再调 `LAW.case_detail`。

> **每引必校验**：进入分析前，确保正文将引用的每一条法条/案例都已通过法律检索后端取得校验过的原文。

### 第六阶段：分析与推理

**法律解释方法链**（按序）：文义解释 → 体系解释 → 历史解释 → 客观目的论解释。

**推导链条**：事实认定 → 问题识别 → 适用规则 → 规则解释 → 规则涵摄（Subsumption）→ 形成结论 → 评估风险与不确定性。

要求：严格遵循推导链条，不从二手观点直接跳转结论；缺关键事实时列明缺失事实及其影响（不自行假设）；准确理解规则后再涵摄；对不确定问题区分确定性层级。

### 第七阶段：验证与风险自检

输出前自检：

- [ ] 是否确认所引法条的时效性（现行有效/已修订/已废止）
- [ ] 是否优先使用更高级别法律渊源
- [ ] 是否存在只引条号、未核实条文内容的情况
- [ ] 是否存在超出法律渊源支持范围的推断
- [ ] 是否存在只引二手转述、未见原文的情况
- [ ] 是否混淆不同法域/层级/时间版本
- [ ] 是否把实务/学术观点误写为明确法律结论
- [ ] 裁判分歧明显时，是否如实呈现不同立场
- [ ] **是否对用户未提供的事实进行了假设/想象**（如有，删除或移入「研究前提」）
- [ ] **核心结论是否 ≤ 500 字、是否符合所选视角的导向**

存在问题则降低确定性并写明风险边界。

### 第八阶段：生成 Markdown 报告

> **⛔ 交付前必过闸门**（见 qoder.md「法律核验闸门」）：核验对象为报告全文（含案号）。

**先产出 Markdown 交付物**（写入输出目录），命名 `法律研究报告_{主题}_{日期}.md`，保存至用户指定文件夹或当前输出目录，并以 `file://` 链接交付。经 `/法律核验` 放行后，询问用户『是否转 Word（Word 转换后端（DOCX.md_to_docx, preset=legal））』，确认才转 .docx。报告结构见下节。

## 报告结构（Markdown）

报告要素**简洁、按场景灵活裁剪**：标 `[核心]` 的为必备节，标 `[按需]` 的依研究场景取舍。

```markdown
# 法律研究报告

> 研究问题：{一句话问题} ｜ 日期：{YYYY-MM-DD} ｜ 视角：{律师/法务/客观研究}

## 一、核心结论  [核心]

{≤500字。律师视角：客户法律风险 + 律师建议思路；
 法务视角：公司法律风险 + 法务意见思路；
 客观研究：仅客观研究结论。
 多主体可用表格对比。不做细节推演，不假设未给信息。}

## 二、研究问题与前提  [核心]

{规范化的法律争议问题（1-3条）；前提假设、适用法域、时间范围、主体性质；
 **已知信息缺口及其对结论的影响**（不自行填补）}

## 三、规则依据  [核心]

| 法规名称 | 法条号 | 条文内容（摘要） | 时效性 |
|---------|--------|----------------|--------|
| 《XXX法》 | 第X条 | {经MCP校验的原文} | 现行有效 |

{先一般规则、后特别规则，从宽泛到具体}

## 四、分析论证  [核心]

{将规则涵摄到事实，遵循解释方法链。细节推演在此展开，与核心结论呼应。
 自身推理段末注"（分析推断）"}

## 五、类似案例  [按需]

| 案号 | 审理法院 | 案由 | 裁判要旨 | 与本问题关联 |
|------|---------|------|---------|------------|

## 六、实务观点  [按需]

| 来源（机构/作者《标题》） | 观点摘要 | URL |
|------|---------|-----|

## 七、风险与不确定性  [核心]

{裁判尺度差异、地方差异、溯及力、事实缺口带来的不确定}

## 八、依据清单  [核心]

**法律法规**：{逐条列出，含时效性}
**裁判文书**：{逐条列出案号}
**二手参考资料**：{逐条列出标题 + URL}
```

> 纯概括性/学理问题：可省略「实务建议」性内容，「核心结论」只保留客观结论；「类似案例」「实务观点」按需保留。

## 报告输出后

向用户简报工具使用情况：法律检索后端调用了哪些能力（LAW.*）、各几次、检索了什么；SEARCH.* 调用几次、检索了什么关键词；案例 `LAW.case_detail` 全文调用消耗提示。

## MCP 降级策略

| MCP 不可用 | 降级方案 |
|-----------|----------|
| 法律检索后端法条检索/校验 | 法条标注"[L4-法条待验证]"，附待校验清单，提示用户自行核实条号与内容；**绝不用记忆编造法条** |
| 法律检索后端案例检索 | 跳过类似案例节，或用 SEARCH.* 查公开案例并标注"未经权威库校验" |
| SEARCH.* | 跳过二手文献阶段，仅基于一手资料分析，并在报告中说明未做二手文献调研 |
| 无 `qoder.md` | 询问用户一次确定视角 |

## 硬性约束

- **禁止编造法条**：所有法条必须经法律检索后端取得原文，返回为空时如实告知，不用记忆替代。
- **禁止编造案例**：所有案例必须来自法律检索后端检索结果。
- 每条法条引用必须包含：法规名称、法条号、原文内容、时效性状态。
- **优先输出 Markdown**：先产出 .md 交付物，完成 md 后询问用户是否进一步转 Word（Word 转换后端（DOCX.md_to_docx, preset=legal）），确认才转 .docx。
- **核心结论 ≤ 500 字**，不假设用户未提供的信息。
- 未确认研究问题前不得开始检索。

## 质量检查清单

### 视角与结论
- [ ] 已正确判定视角（律师/法务/客观研究）
- [ ] 核心结论 ≤ 500 字
- [ ] 律师视角：含客户法律风险 + 律师建议思路
- [ ] 法务视角：含公司法律风险 + 法务意见思路
- [ ] 客观研究模式：仅客观结论，无视角化建议
- [ ] 未基于未给信息做假设/想象

### 检索与校验
- [ ] 每条法条均经法律检索后端校验原文与时效性
- [ ] 每个案例均来自法律检索后端检索
- [ ] 关键词/语义检索按原则正确选用
- [ ] 案例全文调用已向用户说明（积分意识）

### 报告质量
- [ ] 必备节齐全，按需节按场景裁剪
- [ ] 依据清单完整（法规/案例/二手分列）
- [ ] 二手文献均注明来源 + URL
- [ ] 确定性分层清晰
- [ ] 已先输出 .md 文件并以 file:// 链接交付；放行后已询问是否转 Word（Word 转换后端（DOCX.md_to_docx））

## 错误处理

- 信息不足 → 补问，不假设缺失事实
- 用户未确认研究问题 → 暂停，不开始检索
- 法律检索后端返回空 → 如实告知，不编造，标注待校验
- 视角无法判定 → 询问用户一次后记住
- 案例过多 → 按相关度取前若干，向用户说明筛选标准