Legal Memo Generator

---
id: legal-memo-generator

name: 法律备忘录生成
description: 生成专业法律备忘录，支持复杂法律问题分析。适用于特定法律问题分析、项目交易架构设计、诉讼案件分析等场景。遵循结构清晰、结论优先的原则，采用AIRAC写作法，以段落形式论述（严禁要点列表），引用现行有效的法律法规和真实案例。支持类案检索功能。
---


# 法律备忘录生成器

## 文档偏好选择

**在正式开始生成法律备忘录/法律意见书前，必须先调用 `request_document_preferences` 工具收集用户偏好。** 不得跳过此步骤。

### 操作步骤

1. 识别本次任务是法律备忘录、法律意见书还是尽职调查报告，调用 `request_document_preferences` 工具并传入 `documentType: "legal_opinion"`。
2. 等待用户在弹出的选项卡片中完成选择。
3. 将用户返回的偏好结果作为后续各步骤的约束条件，特别是在「确定写作风格和读者背景」和「步骤二：框架起草」中直接应用。
4. 每次只处理一份备忘录；若用户一次要求多份，完成第一份后再为下一份调用偏好工具。

### 用户取消时的回退

如果 `request_document_preferences` 返回 `cancelled` 状态，使用以下默认偏好：
- 受众对象：内部法务
- 分析深度：标准分析
- 案例引用：引用关键案例
- 行文形式：严格段落（符合本 Skill 默认要求）

## 任务目标
本 Skill 用于生成专业、详实的法律备忘录，核心能力包括：
- **结构清晰**：按照标准6部分结构构建备忘录（标题、本备忘录的目的、概要、背景概述、法律分析、结论）
- **结论优先**：在交代必要背景信息后，优先呈现概要，让读者快速获取答案
- **段落形式论述**：**整个备忘录必须以段落形式行文，严禁任何形式的要点、列表、分项罗列**
- **实用性**：回应客户关切，提出明确建议和可行方案，在不确定性中寻找最大的确定性
- **可读性**：平铺直叙，针对不同读者背景调整内容深度，让人能够轻松愉快地理解
- **专业性**：格式统一、定义一致、引用规范、无笔误，呈现专业律所的作品质量
- 应用 AIRAC 写作法进行严谨的法律分析
- 引用现行有效的法律法规，验证法规的准确性和有效性
- 适当引用真实且相关的司法案例支持分析
- 控制执业风险，采用适当的免责声明和谨慎表述

**关键原则：严禁使用要点、列表、分项等形式**
- 整个备忘录从标题到结论，所有内容都必须以段落形式论述
- 严禁使用数字列表、项目符号、要点罗列等任何形式的列表
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- 多个要点应在同一段落中用"第一，...。第二，...。第三，..."等方式串联
- 每个段落必须完整表达一个观点或论题，形成连贯流畅的论述

## 适用场景
- **特定法律问题分析**：针对某一项目或事件中的具体法律问题展开研究并形成结论（最常见）
- **项目交易架构设计分析**：分析交易结构的合法性和可行性（需结合项目经验）
- **诉讼案件分析**：聚焦诉讼案件客户核心诉求或争议焦点

## 操作步骤

### 工具使用策略（强制）
- 触发范围：出现“案例”“判例”“裁判文书”“案例引用”“案例检索”“类案检索”“判例检索”“裁判观点”“案号”“裁判日期”等需求或表述，必须执行类案检索工具链
- 执行顺序：先生成 `search_request.json` → 运行 `python scripts/case_search.py --input search_request.json --output search_result.json` → 基于脚本输出筛选并引用案例
- 禁止联网：上述范围内严禁使用 `search_web` 或任何联网搜索工具获取或整理案例信息
- 失败处理：仅允许修正 `search_request.json` 或重试脚本调用，不得切换到联网搜索
- 输出要求：需在执行过程中展示脚本标准输出的摘要信息（如“case_search.py 启动…/API调用成功/检索结果全文如下…”），并在后续分析中据此引用

### 步骤一：前期准备

**行文形式提醒（至关重要）**：
- 整个备忘录必须以段落形式行文，严禁使用任何形式的要点、列表、分项罗列
- 法律分析、实务建议、风险提示等所有部分都必须以完整段落的形式论述
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- 多个要点应在同一段落中用"第一，...。第二，...。第三，..."等方式串联
- 每个段落必须完整表达一个观点或论题，形成连贯流畅的论述

1. **理解客户需求和商业意图**：
   - 明确客户或合伙人的具体要求，识别核心法律问题
   - **理解客户的商业意图**：透过工作指示和项目背景揣摩客户的商业意图
   - 有时客户的问题可能不全面或不清楚，需要追问客户的商业意图，以便了解法律备忘录的真正着力点
   - 例如：客户问FCPA法律后果，可能隐含两层意思：一是FCPA是否适用，二是如果适用则法律后果是什么

2. **梳理事实背景**：
   - 全面收集与案件相关的事实信息
   - 筛选出核心信息，剔除无关内容
   - 形成初步判断后与合伙人讨论确认

3. **明确核心法律问题**：将笼统的需求拆解为具体、可分析的法律问题

4. **确定写作风格和读者背景**：
   - 如果读者是公司内部律师：使用专业法律术语和严谨表述，无需解释基础法律概念
   - 如果读者是公司高管或业务团队：简化法律分析过程，突出核心结论，采用清晰直白的语言，对基础法律概念作进一步解释

5. **针对性研究和准备**：
   - 在了解清楚事实、背景及客户需求后，有针对性地进行法律研究
   - 准备法律备忘录的提纲
   - 对于客户关心的内容，需要深入研究，多维度调研分析
   - 对于虽然被客户指示覆盖但不属于客户核心关注的内容，适当从简
   - 可以附上一句："如果需要进一步了解这一问题，我们可以深入分析"

### 步骤二：框架起草

**行文形式提醒（至关重要）**：
- 整个备忘录必须以段落形式行文，严禁使用任何形式的要点、列表、分项罗列
- 法律分析、实务建议、风险提示等所有部分都必须以完整段落的形式论述
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- 多个要点应在同一段落中用"第一，...。第二，...。第三，..."等方式串联

按照以下标准6部分结构构建备忘录框架：

#### 1. 标题
**格式要求**：
- 文件名称：明确标注"法律备忘录"或"法律意见书"
- To：接收方（客户名称、部门或具体联系人）
- From：出具方（律所名称、律师姓名）
- Date：出具日期
- Re：主题（简要说明备忘录涉及的核心事项）

**作用**：除归档外，出具日和接收方也发挥限制备忘录使用条件的作用

#### 2. 本备忘录的目的
**撰写要点**：
- 用几句话简短概括备忘录的目的和要解决的法律问题
- 确保作者与读者是"on the same page"的，对需要解决的问题认识一致
- 问题表述清晰、具体，避免过于宽泛

#### 3. 概要（重要：结论优先）
**撰写要点**：
- 结论应尽可能优先呈现给读者
- 在交代完必要的背景信息后，以直截了当的方式给出最想要的答案
- **不要使用"YES"或"NO"作为开头**，而是用完整的句子给出明确结论
- 简洁明了，通常1-2段即可

#### 4. 背景概述
**撰写要点**：
- 简炼地描述与需要解决的法律问题相关的事实
- 包含重要的背景信息
- 避免无关的事实信息，保持精炼
- 按照时间顺序或逻辑顺序组织

#### 5. 法律分析（核心部分）
**分析方法**：采用 AIRAC 方法（按照AIRAC逻辑结构行文，但不输出标题）
- **答案**：针对该问题的直接答案（直接在分析开头给出，不使用"Answer"标题）
- **问题**：具体法律问题（不使用"Issue"标题，直接表述）
- **规则**：适用的法律法规（不使用"Rule"标题，直接引用）
- **分析**：法律应用分析（不使用"Analysis"标题，直接展开）
- **结论**：针对该问题的结论（不使用"Conclusion"标题，直接总结）

**内容要求**：
- 向读者呈现法律分析过程
- 引用、解释、适用各种法律依据（法律条文、司法判例）
- 引用实践操作（商业案例、匿名电话咨询结果等）
- 说明如何最终得出结论
- **按照AIRAC的逻辑结构行文，但不输出"Answer""Issue""Rule""Analysis""Conclusion"等标题单词**
- **如本次分析需要引用司法案例，必须在开始法律分析前完成类案检索脚本调用并基于脚本输出筛选案例，未完成工具调用不得进入正文写作**

**标题细化（重要）**：
- **标题必须编号**：严格按照层级使用不同编号格式
  - **一级标题**：使用 `**一、**`、`**二、**`、`**三、**` 等中文数字编号，每个编号必须加粗
  - **二级标题**：使用 `**（一）**`、`**（二）**`、`**（三）**` 或 `**(1)**`、`**(2)**`、`**(3)**` 编号，每个编号必须加粗
  - **三级标题**：使用 `**1.**`、`**2.**`、`**3.**` 编号，每个编号必须加粗
- 针对每一个需要讨论的问题，使用具体的、概括性强的小标题
- 小标题应能准确反映该部分讨论的核心内容
- **所有标题必须加粗**：使用 `**` 符号包裹整个小标题文本，如 `**一、关于XX问题的分析**`
- 避免使用通用的"法律分析"作为唯一标题
- **标题需要细分（强制要求）**：
  - 一级标题：针对每个大问题，如 `**一、关于股东派生诉讼当事人主体资格的分析**`
  - 二级标题：针对具体要点，如 `**（一）股东派生诉讼的原告**`、`**（二）股东派生诉讼的被告**`、`**（三）股东派生诉讼的第三人**`
  - 三级标题：如需要，使用 `**1. 原告资格的认定标准**`、`**2. 持续持股期间的计算**` 等
- 可使用问句式标题，如 `**一、XX是否构成YY？**`（同样需要加粗）
- **禁止使用**：
  - 禁止使用"1."、"2."、"3."作为一级标题
  - 禁止使用"（1）"、"（2）"、"（3）"作为一级或二级标题
  - 禁止标题不加粗

**类案检索**：
- 当法律分析需要引用司法案例时，必须调用类案检索功能，严禁使用联网搜索获取或整理案例信息
- 检索步骤：
  1. 确定检索关键词（如"不可抗力 关税政策"、"情势变更 政策调整"等）
  2. 使用 `create_file` 工具生成 `search_request.json` 文件，样例如下：
     ```json
     [{
       "group_id": "P1",
       "parameters": {
         "input": "{\"Court\":\"最高人民法院\", \"CheckFullText\":\"不可抗力 政府行为 全局性\",\"LastInstanceDate\":{\"Start\":\"2018-1-1\",\"End\":\"2024-12-31\"}}"
       }
     },{
       "group_id": "P2",
       "parameters": {
         "input": "{\"Court\":\"高级人民法院\", \"CheckFullText\":\"不可抗力 政策调整 关税\",\"LastInstanceDate\":{\"Start\":\"2018-1-1\",\"End\":\"2024-12-31\"}}"
       }
     }]
     ```
  3. 调用 `scripts/case_search.py` 脚本进行检索：
     ```bash
     python scripts/case_search.py --input search_request.json --output search_result.json
     ```
  - **强制执行要求**：
    - 必须通过 `scripts/case_search.py` 调用 API 完成案例检索
    - 严禁使用 `search_web` 或任何联网搜索工具进行案例检索或摘要
    - 如脚本调用失败，应修正 `search_request.json` 或重试，不得切换到联网搜索
  4. 从返回结果中筛选与法律备忘录讨论主题和各要点相关的案例
  5. 在AIRAC分析的Rules部分，以段落形式引用案例，展示：
     - 案号
     - 裁判日期
     - 核心观点
     - 全文链接
- 案例引用格式示例：
  ```
  例如，最高人民法院(2021)最高法民申6537号案中，法院认为，政府行为成为不可抗力的情形"应限于政府为了应对重大、突发的自然灾害、危及公共安全的各种社会事件等作出的具有宏观性应对措施，或者针对社会经济生活作出具有全局性影响的重大政策调整等"。
  ```

**法规检索**：
- 当法律分析需要引用法律法规时，可调用法规检索功能
- 检索步骤：
  1. 确定检索关键词（如法规名称"民法典"、颁布机关"最高人民法院"等）
  2. 使用`create_file`工具将以上逐个关键词请求字段生成 `law_search_request.json` 文件，确保每个关键词组都出现在`law_search_request.json`文件中
```json
[{
     "group_id": "1",
     "parameters": {
            "title":"民法典", "fulltext":"租赁合同"
     }
},{
     "group_id": "2",
     "parameters": {
            "title":"民法典", "fulltext":"婚姻"
     }
},...]
```
  3. 调用 `scripts/law_search.py` 脚本，检索相关案例，并返回这些法规数据。脚本包含两个参数：
- input：输入的 law_search_request.json 文件的路径
- output：生成的 law_search_result.json 文件的路径。文件的内容会在脚本运行中直接输出，所以你不需要阅读这个文件。

#### 脚本样例
```bash
python scripts/law_search.py --input law_search_request.json --output search_result.json 

```
  4. 检查返回数据的 `TimelinessDic` 字段，确认法规为"现行有效"（只引用 `{"01": "现行有效"}` 的法规）
  5. 使用 `search_web` 工具通过 `Title` 和 `IssueDepartment` 获取法规原文
     - 搜索关键词示例："民法典 全国人民代表大会"
  6. 在AIRAC分析的Rules部分，引用法规的具体条文
- **重要：法规引用要求**
  - 如果生成的备忘录涉及法律法规的引用，**务必输出与备忘录讨论主题强相关的、正确的逐字原文**
  - 不应只引用法规名称或条文编号，必须提供完整的法条内容
  - 引用的条文应与法律备忘录讨论的主题和各要点高度相关
  - 逐字引用确保法规内容的准确性和权威性
- 法规时效性说明：
  - `{"01": "现行有效"}` → 法规有效，可以使用
  - `{"02": "废止或失效"}` → 法规无效，不能使用
  - `{"03": "已被修改"}` → 法规已被修改，需要查询最新版本
- **重要**：必须让模型确认法规有效后再引用
- **特殊情形：历史性问题**
  - 如果客户问的问题是历次修订的法律法规情况、立法历程，或者以前的法律规定等历史性问题
  - 这种情况下，**不需要引用现行有效的最新法条**
  - 应当引用历史版本的法规或相关立法文件
  - 校验时**跳过**"法规引用检查"中关于现行有效性的检查项（标记为N/A）
  - 历史性问题的判断标准：
    - 问题明确涉及"历次修订"、"立法历程"、"以前的法律规定"
    - 问题涉及时间点（如"2020年以前"、"合同签订时的法律"）
    - 问题涉及法律演变或对比

**环境变量要求**：
- 如需调用类案检索或法规检索功能，需设置环境变量 `identity_ticket`（法律数据库API认证凭证）

#### 6. 结论
**撰写要点**：
- 总结法律问题及答案
- **提出应对建议和可行方案**
- 在不确定性中寻找最大的确定性（收益最大、风险最小的解决方案）
- 确保结论与分析部分逻辑一致

**实用性的关键**：
- 必须回应客户关切，不能东绕西绕
- 必须给出明确结论，不能以不确定性替代建议
- 可以指出分析的局限性，但不能以免责声明替代结论
- 免责声明不应过于冗长

**实务建议和风险提示的行文形式要求（重中之重）**：
- **必须以段落形式论述，严禁使用要点、列表、分项等形式**
- **如果实务建议和风险提示部分出现任何形式的要点、列表、分项罗列，必须立即修改**
- **零容忍**：发现任何形式的列表，不得保留，必须改为段落形式
- **错误示例（禁止使用）**：
  ```
  贵公司需充分考虑以下风险：
  风险一：前置程序履行的有效性
  如贵公司未履行书面请求程序直接起诉，法院可能驳回起诉
  建议：严格履行前置程序，并保留完整的送达证据
  
  风险二：诉讼时效问题
  如果超过法律规定的诉讼时效，贵公司将丧失胜诉权
  建议：及时主张权利
  ```
- **正确示例（必须使用）**：
  ```
  股东派生诉讼存在如下风险：第一，前置程序的履行可能被驳回起诉的风险。在实践中，如果贵公司未履行书面请求程序直接起诉，法院可能驳回起诉。因此，我们建议贵公司严格履行前置程序，并保留完整的送达证据。第二，诉讼时效问题。如果超过法律规定的诉讼时效，贵公司将丧失胜诉权。因此，我们建议贵公司及时主张权利，并在诉讼时效届满前提起诉讼。
  ```
- 多个建议或风险点可以在一个段落中用"第一，...。第二，...。第三，..."的方式串联
- 每个建议或风险点应包含：问题描述 + 分析/理由 + 建议措施
- 确保段落连贯流畅，形成完整的论述体系
- **关键**：实务建议和风险提示部分是段落形式论述的重点检查区域，必须确保完全符合要求

### 步骤三：正文写作（AIRAC 写作法）

**行文形式提醒（至关重要）**：
- 整个备忘录必须以段落形式行文，严禁使用任何形式的要点、列表、分项罗列
- 法律分析、实务建议、风险提示等所有部分都必须以完整段落的形式论述
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- **实务建议和风险提示部分是重点检查区域，必须确保完全以段落形式论述**
- 多个要点应在同一段落中用"第一，...。第二，...。第三，..."等方式串联

**标题细化提醒（重要）**：
- **标题必须编号**：使用"一、"、"二、"、"三、"等中文数字编号
- **标题需要细分**：
  - 一级标题：`**一、关于XX问题的分析**`
  - 二级标题：`**（一）XX问题的具体分析**`
  - 三级标题：`1. XX问题的详细说明`
- 所有标题必须加粗，使用 `**` 符号包裹

严格遵循 AIRAC 逻辑结构进行法律分析，但**不输出"Answer""Issue""Rule""Analysis""Conclusion"等标题单词**：

#### 行文形式要求
- **以段落形式论述**：整个法律备忘录应使用段落形式来行文，避免使用"要点"、"列表"、"分项"等形式
- **标题和段落结合**：各要点可以通过单独的标题和段落来呈现，每个要点作为一个完整的段落
- **连贯流畅**：段落之间应有逻辑关联，形成连贯的论述，而非割裂的要点罗列
- **完整表达**：每个段落应完整表达一个观点或论题，包含论点、论据和建议（如适用）
- **实务建议和风险提示特别要求**：
  - **严禁在实务建议和风险提示部分使用要点、列表、分项等形式**
  - 多个建议或风险点应在同一段落中用"第一，...。第二，...。第三，..."的方式串联
  - 每个建议或风险点应包含：问题描述 + 分析/理由 + 建议措施
  - 确保形成连贯流畅的段落论述，而非割裂的要点罗列
  - 参考步骤二"结论"部分中的"实务建议和风险提示的行文形式要求"章节

#### 示例对比

**错误的行文形式（避免使用）- 实务建议和风险提示：**
```
其次，关于诉讼风险提示。贵公司需充分考虑以下风险：
风险一：前置程序履行的有效性
如贵公司未履行书面请求程序直接起诉，法院可能驳回起诉
建议：严格履行前置程序，并保留完整的送达证据

风险二：诉讼时效问题
如果超过法律规定的诉讼时效，贵公司将丧失胜诉权
建议：及时主张权利
```

**正确的行文形式（应使用）- 标题编号和细分：**
```
**一、关于股东派生诉讼当事人主体资格的分析**

**（一）股东派生诉讼的原告**
根据《公司法》第一百五十一条规定，符合一定条件的股东可以提起股东派生诉讼。首先，原告必须是有限责任公司的股东，或者是股份有限公司连续一百八十日以上单独或者合计持有公司百分之一以上股份的股东。其次，原告必须已经书面请求监事会或者不设监事会的有限责任公司的监事提起诉讼，只有在拒绝或者三十日内未提起诉讼的情况下，股东才有权直接起诉。

**（二）股东派生诉讼的被告**
股东派生诉讼的被告应当是侵犯公司合法权益的董事、监事、高级管理人员或者他人。在实践中，被告的确定需要根据具体案情分析，包括但不限于公司管理层、控股股东、实际控制人等。需要注意的是，股东派生诉讼的被告是侵害公司利益的人，而非公司本身。

**（三）股东派生诉讼的第三人**
在股东派生诉讼中，公司应当作为第三人参加诉讼。根据司法解释，人民法院应当通知公司作为第三人参加诉讼。公司作为第三人在诉讼中的地位和权利义务需要根据具体案情确定。
```

#### 1. 给出答案
- 在分析开始时，直接给出针对该法律问题的答案
- **不要使用"YES"或"NO"开头**，而是用完整的句子给出明确答案
- 答案应当简洁明了，通常1句话即可
- 这是"结论优先"原则的具体体现
- **如果使用小标题，必须加粗**（如 `**关于合同效力的判断**`）

#### 2. 找出问题
- 梳理事实，提炼核心法律问题
- 如果客户未清晰列出问题，需自行归纳并讨论确认
- 问题表述应当清晰、具体、独立
- **如果使用小标题，必须加粗**

#### 3. 找到法规
- 通过多种途径检索相关法律法规
- **使用法规检索功能确保法规的时效性和正确性**：
  1. 确定检索关键词（如法规名称"民法典"、颁布机关"最高人民法院"等）
  2. 使用 `search_web` 工具通过 `Title` 和 `IssueDepartment` 获取法规原文
- 验证法规的准确性和有效性（确保现行有效）
- 明确适用标准
- 列出适用的法律条文、司法解释、规范性文件等
- **引用法规时务必输出逐字原文**
  - 不应只引用法规名称或条文编号
  - 必须提供完整的法条内容（逐字原文）
  - 引用的条文应与备忘录讨论主题和各要点强相关

#### 4. 应用分析
- 将适用的法律规定精准应用于案件事实
- 进行深入、逻辑严密的论证
- 引用真实、相关的司法案例支持分析
- 引用实践操作（商业案例、匿名电话咨询结果等）
- 展示推理过程，说明如何最终得出结论

#### 5. 得出结论
- 针对该法律问题给出明确结论
- 确保结论与分析部分逻辑一致
- 直接总结，不使用"Conclusion"标题
- **如果使用结论小标题，必须加粗**

**重要：假设条款**
在免责声明部分或正文适当位置添加适当的假设条款，典型的假设包括：
- 客户提供信息的真实准确性
- 仅就中国法律发表意见
- 除特别说明外，未考虑其他法域法律
- 假设相关事实真实、完整、准确

### 步骤四：定稿优化

**行文形式检查（至关重要）**：
- 检查整个备忘录是否全部以段落形式行文
- 检查是否存在任何形式的要点、列表、分项罗列
- 如有发现，必须立即改为段落形式
- 多个要点应在同一段落中用"第一，...。第二，...。第三，..."等方式串联

#### 1. 提升可读性
- 使用概括性强的小标题，作为路标帮助读者快速了解整体内容
- **小标题必须加粗**：使用 `**` 符号包裹小标题文本
- 避免冗长句式和华丽辞藻，保持语言简洁直接
- 采用简明易懂的文字表达方式，确保非法律专业人士也能理解
- 对于长篇幅备忘录，考虑在最开头设置摘要（Executive Summary）

#### 2. 强化结论优先原则
- 确保"概要"在"背景概述"之后立即呈现
- 在"概要"中使用明确完整的句子表述，**不要使用"YES"或"NO"开头**
- 避免将核心结论淹没在冗长的分析中

#### 3. 风险控制
- 添加完整的免责声明，说明使用条件限制
- 对存在疑虑的法律结论，采用弱化表达（如"我们倾向于认为"）
- 避免使用"shall""must"等绝对化表达
- 使用建议性表述（如"It is advisable to..."）
- 免责声明不应过于冗长，不能以免责声明替代结论

#### 4. 准确性检查
- 逐行检查，确保"魔鬼都在细节中"
- 验证法规引用的准确性和有效性
- 确保案例引用的真实性和相关性（使用类案检索功能）
- 核对标题中的To/From/Date/Re信息准确无误

#### 5. 实用性检查
- 是否回应了客户的关切？
- 是否给出了明确的结论？
- 是否提出了可行的建议和方案？
- 是否在不确定性中寻找了最大的确定性？
- 是否避免了以不确定性替代建议？
- 是否存在东绕西绕、没有结论的情况？
- 免责声明是否过于冗长？

#### 6. 可读性检查
- 是否平铺直叙，条理清晰？
- 在客户感兴趣的地方是否展开阐述？
- 在客户不感兴趣的地方是否一笔带过？
- 是否考虑了读者的背景（法务人员vs业务团队）？
- 法务人员：是否避免了不必要的概念解释？
- 业务团队：是否对基础法律概念作了进一步解释？
- 是否使用小标题和分段帮助读者快速定位？

#### 7. 专业性检查
- 格式是否统一（字体、字号、缩进）？
- 该定义的词汇是否给予定义并通篇适用？
- 引用事实时是否有出处？
- 引用法律时是否有出处？
- 是否存在口语化表达？
- 是否存在笔误和错误？
- 序列号是否正确？

### 步骤五：最终校验（新增）

**行文形式检查（重中之重，必须优先检查）**：
- 检查整个备忘录是否全部以段落形式行文
- 检查是否存在任何形式的要点、列表、分项罗列
- 如有发现任何形式的列表，必须立即改为段落形式
- 多个要点应在同一段落中用"第一，...。第二，...。第三，..."等方式串联
- 每个段落必须完整表达一个观点或论题，形成连贯流畅的论述
- **如果发现任何形式的要点、列表、分项罗列，必须立即修改，不得保留**

**校验目的**：确保生成的备忘录完全符合SKILL.md中的所有要求和步骤。

#### 校验清单

按照以下清单逐项检查备忘录，如有缺漏或不一致之处，必须补充和修正，直到符合所有要求（不适用的内容除外）。

##### 1. 结构完整性检查
- [ ] 备忘录是否包含标准6部分结构？
  - [ ] 标题（含To/From/Date/Re）
  - [ ] 本备忘录的目的
  - [ ] 概要（结论优先，不在"背景概述"之后）
  - [ ] 背景概述
  - [ ] 法律分析（核心部分）
  - [ ] 结论
- [ ] 是否有不必要的额外部分？（如"注释"、"附件"、"附表"等应删除）

##### 2. 标题格式检查
- [ ] 是否使用To/From/Date/Re格式？
- [ ] 标题中的信息是否准确无误？
- [ ] 法律分析部分是否使用了具体的小标题？（而非通用的"法律分析"）
- [ ] 是否针对每个问题使用了细化标题？（如"一、关于XX问题的分析"、"二、关于YY问题的分析"）
- [ ] 是否可以使用问句式标题？（如"XX是否构成YY？"）

##### 3. 结论优先原则检查
- [ ] "概要"是否在"背景概述"之后立即呈现？
- [ ] "概要"是否使用了完整句子表述结论？
- [ ] "概要"是否**没有**使用"YES"或"NO"开头？
- [ ] 核心结论是否没有被淹没在冗长的分析中？

##### 4. AIRAC写作法检查
- [ ] 法律分析部分是否按照AIRAC逻辑结构行文？
- [ ] 法律分析部分是否**没有**输出"Answer""Issue""Rule""Analysis""Conclusion"等英文标题单词？
- [ ] 分析是否包含以下要素？
  - [ ] 针对该问题的直接答案（在分析开头）
  - [ ] 具体法律问题
  - [ ] 适用的法律法规
  - [ ] 法律应用分析
  - [ ] 针对该问题的结论
- [ ] 分析过程是否逻辑严密、推理清晰？
- [ ] 是否避免了跳跃式推理？

##### 5. 案例引用检查（如适用）
- [ ] 是否引用了真实、相关的司法案例？
- [ ] 案例引用格式是否规范？（法院级别、案号、裁判日期）
- [ ] 是否以段落形式展示案例信息？（案号、裁判日期、核心观点、全文链接）
- [ ] 案例是否与法律备忘录讨论的主题和各要点相关？
- [ ] 是否在AIRAC分析的Rules部分起到了辅助分析的作用？
- [ ] 是否通过 `scripts/case_search.py` 完成检索（禁止联网检索）？

##### 6. 法规引用检查
- [ ] 是否使用了法规检索功能验证法规的时效性和正确性？
- [ ] **历史性问题判断**：是否属于历史性问题？
  - 历史性问题的判断标准：
    - [ ] 问题涉及"历次修订"、"立法历程"、"以前的法律规定"
    - [ ] 问题涉及时间点（如"2020年以前"、"合同签订时的法律"）
    - [ ] 问题涉及法律演变或对比
  - 如果是历史性问题：
    - [ ] 是否引用了历史版本的法规或相关立法文件？
    - [ ] 是否**没有**强制要求引用现行有效的最新法条？
    - [ ] 以下检查项标记为N/A（跳过检查）：
      - [ ] N/A: 引用的法律法规TimelinessDic字段是否为"现行有效"？
      - [ ] N/A: 是否只引用了TimelinessDic为"现行有效"的法规？
  - 如果不是历史性问题：
    - [ ] 引用的法律法规TimelinessDic字段是否为"现行有效"？
    - [ ] 是否只引用了TimelinessDic为"现行有效"的法规？
- [ ] 法规引用格式是否准确？
- [ ] 是否通过search_web工具获取了法规的完整原文？
- [ ] 是否避免了引用已废止或修订的条款（历史性问题除外）？
- [ ] 法规条文是否准确无误？
- [ ] 是否输出了与备忘录讨论主题强相关的逐字原文？
- [ ] 是否只引用了法规名称或条文编号而未提供完整条文？
- [ ] 引用的条文是否为逐字原文（无转述或概括）？

##### 7. 行文形式检查（重中之重，零容忍）
- [ ] 整个备忘录是否全部以段落形式论述？
- [ ] 是否存在任何形式的"要点"、"列表"、"分项"、"项目符号"等？
- [ ] 是否存在数字列表（1. 2. 3.）？
- [ ] 是否存在字母列表（a. b. c.）？
- [ ] 各要点是否通过单独的标题和段落呈现？
- [ ] 段落之间是否有逻辑关联，形成连贯的论述？
- [ ] 每个段落是否完整表达一个观点或论题？
- [ ] 是否存在割裂的要点罗列？
- [ ] 多个要点是否在同一段落中用"第一，...。第二，...。第三，..."等方式串联？
- [ ] **实务建议和风险提示部分是否以段落形式论述？**
- [ ] **实务建议和风险提示部分是否存在任何形式的要点、列表、分项罗列？**
- [ ] **零容忍**：如发现任何形式的列表，必须立即修改，不得保留

##### 8. 实用性检查
- [ ] 是否回应了客户的关切？
- [ ] 是否给出了明确的结论？
- [ ] 是否提出了可行的建议和方案？
- [ ] 是否在不确定性中寻找了最大的确定性？
- [ ] 是否避免了以不确定性替代建议？
- [ ] 是否存在东绕西绕、没有结论的情况？
- [ ] 免责声明是否过于冗长？

##### 9. 可读性检查
- [ ] 是否平铺直叙，条理清晰？
- [ ] 在客户感兴趣的地方是否展开阐述？
- [ ] 在客户不感兴趣的地方是否一笔带过？
- [ ] 是否考虑了读者的背景（法务人员vs业务团队）？
  - [ ] 法务人员：是否避免了不必要的概念解释？
  - [ ] 业务团队：是否对基础法律概念作了进一步解释？
- [ ] 是否使用小标题和分段帮助读者快速定位？
- [ ] 是否避免了冗长句式和华丽辞藻？

##### 10. 专业性检查
- [ ] 格式是否统一（字体、字号、缩进）？
- [ ] 该定义的词汇是否给予定义并通篇适用？
- [ ] 引用事实时是否有出处？
- [ ] 引用法律时是否有出处？
- [ ] 是否存在口语化表达？
- [ ] 是否存在笔误和错误？
- [ ] 序列号是否正确？

##### 11. 风险控制检查
- [ ] 是否添加了完整的免责声明？
- [ ] 免责声明是否说明了使用条件限制？
- [ ] 对存在疑虑的法律结论，是否采用了弱化表达（如"我们倾向于认为"）？
- [ ] 是否避免了使用"shall""must"等绝对化表达？
- [ ] 是否使用了建议性表述（如"It is advisable to..."）？
- [ ] 免责声明是否过于冗长，是否以免责声明替代结论？

##### 12. 动态观察检查（如适用）
- [ ] 对于正在进行中的政策变化，是否使用了动态观察的表述？
- [ ] 是否避免了下绝对性结论，预留了未来变化的可能性？

##### 13. 应对建议检查
- [ ] 结论部分是否提出了应对建议和可行方案？
- [ ] 建议是否具体、可操作？
- [ ] 建议是否使用了分层小标题结构？

##### 14. 格式检查
- [ ] 小标题是否已加粗（使用 `**` 符号）？
- [ ] 法律分析中的细分标题是否已加粗？
- [ ] 概要、背景概述、结论等章节标题是否已加粗？
- [ ] 是否存在未加粗的重要标题？
- [ ] 中文字体是否使用楷体？
- [ ] 英文字母和数字是否使用 Times New Roman？
- [ ] 段前间距是否设置为 0.5 行？
- [ ] 段后间距是否设置为 0.5 行？
- [ ] 整体布局是否美观，段落间距是否均匀？

##### 15. 标题编号和细分检查（重要，强制要求）
- [ ] 标题是否严格按照层级使用不同编号格式？
- [ ] 一级标题是否使用"一、"、"二、"、"三、"等中文数字编号？
- [ ] 二级标题是否使用"（一）"、"（二）"、"（三）"或"(1)"、"(2)"、"(3)"编号？
- [ ] 三级标题是否使用"1."、"2."、"3."编号？
- [ ] 标题是否进行合理细分（强制要求）？
  - [ ] 是否有一级标题（如`**一、关于XX问题的分析**`）？
  - [ ] 是否有二级标题（如`**（一）XX问题的具体分析**`或`**(1)XX问题的具体分析**`）？
  - [ ] 如需要，是否有三级标题（如`**1. XX问题的详细说明**`）？
- [ ] 所有标题（包括编号）是否都已加粗？
- [ ] 标题层级是否清晰合理？
- [ ] 标题编号是否连续有序？
- [ ] 标题内容是否准确反映该部分讨论的核心内容？
- [ ] 是否存在使用"1."、"2."、"3."作为一级标题的情况（禁止）？
- [ ] 是否存在使用"（1）"、"（2）"、"（3）"作为一级或二级标题的情况（禁止）？

##### 16. 举证责任检查（如适用）
- [ ] 在情势变更、不可抗力等需要举证的场景中，是否明确了举证责任分担？
- [ ] 是否引用了"谁主张、谁举证"的原则？

#### 校验执行流程

1. 生成备忘录初稿后，按照上述校验清单逐项检查
2. 对于每项检查，标记为"[✓]"（符合）或"[ ]"（不符合）
3. 对于不符合的项，立即进行补充或修正
4. 重新校验，直到所有检查项都标记为"[✓]"（不适用的项可标记为"N/A"）
5. 最终确认备忘录完全符合SKILL.md中的所有要求和步骤

**重要**：
- 如有任何步骤缺漏，必须补充
- 如有任何不符合要求之处，必须修正
- 直到与skill.md里的所有要求和步骤一致为止（不适用的内容除外）

## 资源索引
- **备忘录格式模板**：见 [references/memo-template.md](references/memo-template.md)（含完整示例和6部分结构说明）
- **AIRAC 写作法详解**：见 [references/irac-guide.md](references/irac-guide.md)（含实战示例和注意事项）
- **法规引用规范**：见 [references/citation-guide.md](references/citation-guide.md)（引用格式和验证方法）
- **风险控制要点**：见 [references/risk-control.md](references/risk-control.md)（免责声明模板和谨慎表述指南）
- **类案检索数据格式**：见 [references/case-data-format.md](references/case-data-format.md)（search_request.json格式说明和示例）
- **类案检索脚本**：见 [scripts/case_search.py](scripts/case_search.py)（调用法律数据库API进行案例检索）
- **法规检索数据格式**：见 [references/law-data-format.md](references/law-data-format.md)（law_search_request.json格式说明和示例）
- **法规检索脚本**：见 [scripts/law_search.py](scripts/law_search.py)（调用法律数据库API进行法规检索）

## 注意事项
- **结论优先原则**：确保"简要结论"在"事实描述"之后立即呈现，让读者快速获取答案，**不要使用"YES"或"NO"开头**
- **行文形式要求**：
  - **以段落形式论述**：避免使用"要点"、"列表"、"分项"等形式
  - **标题和段落结合**：各要点通过单独的标题和段落呈现，每个要点作为一个完整的段落
  - **连贯流畅**：段落之间应有逻辑关联，形成连贯的论述，而非割裂的要点罗列
  - **完整表达**：每个段落应完整表达一个观点或论题，包含论点、论据和建议
  - **示例参考**：见步骤三中的"行文形式要求"章节的正确示例
- **标题细化要求（重要，强制要求）**：
  - **标题必须严格按照层级编号**：
    - **一级标题**：使用 `**一、**`、`**二、**`、`**三、**` 等中文数字编号，每个编号必须加粗
    - **二级标题**：使用 `**（一）**`、`**（二）**`、`**（三）**` 或 `**(1)**`、`**(2)**`、`**(3)**` 编号，每个编号必须加粗
    - **三级标题**：使用 `**1.**`、`**2.**`、`**3.**` 编号，每个编号必须加粗
  - **标题需要细分**：针对每个大问题，必须使用一级标题；针对具体要点，必须使用二级标题；如需进一步细化，使用三级标题
  - **所有标题必须加粗**：使用 `**` 符号包裹整个小标题文本
  - **禁止使用**：
    - 禁止使用"1."、"2."、"3."作为一级标题
    - 禁止使用"（1）"、"（2）"、"（3）"作为一级或二级标题
    - 禁止标题不加粗
- **实用性**：
  - 必须回应客户关切，不能东绕西绕
  - 必须给出明确结论，不能以不确定性替代建议
  - 必须提出可行的建议和方案
  - 在不确定性中寻找最大的确定性（收益最大、风险最小）
  - 免责声明不能替代结论，不应过于冗长
- **可读性**：
  - 平铺直叙，条理清晰
  - 在客户感兴趣的地方展开阐述，不感兴趣的地方一笔带过
  - 考虑读者背景：法务人员无需解释基础概念，业务团队需要进一步解释
  - 使用小标题和分段提升可读性
- **专业性**：
  - **格式统一**：
    - 字体、字号、缩进都要统一
    - **字体规范（强制要求）**：
      - 中文字体：楷体
      - 英文字母和数字：Times New Roman
    - **段落格式（强制要求）**：
      - 段前间距：0.5 行
      - 段后间距：0.5 行
      - 确保段落间距均匀，整体布局美观
    - **小标题必须加粗**：使用 `**` 符号包裹小标题文本（如 `**关于XX问题的分析**`）
    - 法律分析中的细分标题必须加粗
    - 概要、背景概述、结论等章节标题必须加粗
  - 定义一致：该定义的词汇应当给予定义并通篇适用
  - 引用规范：引用事实和法律时都要有出处
  - 语言规范：避免口语化表达
  - 无笔误：杜绝笔误和错误，序列号要正确
- **结构清晰**：严格按照6部分结构组织内容，使用To/From/Date/Re格式标题
- **法规引用要求**：
  - **务必输出与备忘录讨论主题强相关的、正确的逐字原文**
  - 不应只引用法规名称或条文编号
  - 必须提供完整的法条内容（逐字原文），无转述或概括
  - 引用的条文应与备忘录讨论主题和各要点高度相关
- **法规有效性**：引用法律法规时必须确认其现行有效，避免引用已废止或修订的条款（历史性问题除外）
- **案例真实性**：引用案例时应选择真实、相关且权威的案例，避免虚构案例
- **AIRAC方法**：在法律分析中严格遵循AIRAC方法，按照AIRAC逻辑结构行文，但不输出"Answer""Issue""Rule""Analysis""Conclusion"等标题单词
- **免责声明**：必须添加完整的免责声明，说明使用条件限制
- **语言简洁**：避免过度使用专业术语和长难句，提升阅读友好度
- **逻辑严谨**：确保法律分析逻辑清晰，推理严密，避免跳跃式推理
- **风险防范**：始终添加适当的免责声明和谨慎表述，控制执业风险

## 使用示例

### 示例一：特定法律问题分析
**场景**：客户咨询某公司董事会决议的有效性问题
**执行方式**：
1. 按照To/From/Date/Re格式撰写标题
2. 提出"董事会决议是否有效"的核心问题
3. 在事实描述后立即给出明确完整的简要结论，**不要使用"YES"或"NO"开头**
4. 应用AIRAC方法进行法律分析（按照AIRAC逻辑行文，但不输出标题）
5. 使用细分小标题，**所有小标题必须加粗**（如 `**关于董事会决议程序的合法性分析**`）
6. 引用相关条款的逐字原文（如《公司法》第XX条完整条文）
7. 引用类似案例
8. 添加完整的免责声明

### 示例二：诉讼案件分析
**场景**：需要分析某一合同纠纷的诉讼可行性
**执行方式**：
1. 梳理合同条款和履行情况
2. 在简要结论中直接给出"建议起诉"或"不建议起诉"的建议
3. 使用AIRAC方法分析争议焦点（按照AIRAC逻辑行文，但不输出标题）
4. 引用相关法律规定和司法解释
5. 引用类似案例的裁判观点（如需引用案例，使用类案检索功能）
6. 分析胜诉可能性和风险因素
7. 添加免责声明

### 示例三：项目交易架构分析
**场景**：客户计划进行资产重组，需分析交易结构的合法性
**执行方式**：
1. 理解交易背景和商业目标
2. 在简要结论中给出"交易结构可行"或"需要调整"的结论
3. 使用AIRAC方法分析法律问题（按照AIRAC逻辑行文，但不输出标题）
4. 引用相关法规和监管要求
5. 引用类似案例支持分析（如需引用案例，使用类案检索功能）
6. 提供合规建议和风险提示
7. 添加免责声明

### 示例四：不可抗力/情势变更分析（使用类案检索）
**场景**：客户咨询因政策变化能否解除合同
**执行方式**：
1. 梳理合同履行情况和政策变化事实
2. 在简要结论中给出倾向性结论（如"难以构成不可抗力，但可能构成情势变更"）
3. 使用AIRAC方法分析法律问题（按照AIRAC逻辑行文，但不输出标题）
4. 引用相关法律规定（如《民法典》第563条、第533条）
5. 使用类案检索功能检索相关案例：
   - 使用 `create_file` 工具生成 `search_request.json`：
     ```javascript
     const requestData = [{
       "group_id": "P1",
       "parameters": {
         "input": "{\"CheckFullText\":\"不可抗力 政策调整\"}"
       }
     }, {
       "group_id": "P2",
       "parameters": {
         "input": "{\"CheckFullText\":\"情势变更 政策调整\"}"
       }
     }];

     await create_file({
       file_name: 'search_request.json',
       content: JSON.stringify(requestData, null, 2),
       mime_type: 'application/json'
     });
     ```
   - 调用 `scripts/case_search.py --input search_request.json --output search_result.json`
   - 从返回结果中筛选与政策变化相关的案例
6. 在分析中以段落形式引用案例，展示案号、裁判日期、核心观点和全文链接
7. 添加免责声明