116 lines
5.1 KiB
Markdown
116 lines
5.1 KiB
Markdown
---
|
|
name: legal-opinion-writing
|
|
description: 法律意见书写作方法论——从需求分析到定稿交付的完整工作流程、思考逻辑、审查方法和文书规范。基于苏州新东方×交通银行合作项目复盘总结。
|
|
tags: [legal, opinion, writing, methodology]
|
|
---
|
|
|
|
# 法律意见书写作方法论
|
|
|
|
## 触发条件
|
|
- 客户/用户要求出具法律意见书
|
|
- 需要对商业合作/交易进行法律可行性分析
|
|
- 需要对合规风险进行系统评估并给出建议
|
|
|
|
## 核心流程
|
|
|
|
### 第一步：需求拆解——把商业问题翻译成法律问题
|
|
|
|
客户说的是商业语言，律师要拆解为法律问题：
|
|
1. **谁在做？** → 主体资质和性质（公司类型、经营范围、牌照）
|
|
2. **做什么？** → 行为定性（广告发布？金融营销？居间？）
|
|
3. **给谁？** → 受众特征（是否涉及特殊群体保护）
|
|
4. **怎么做？** → 操作模式（嵌入/跳转？固定费用/效果分成？）
|
|
|
|
每个问题对应不同的法律规范体系。
|
|
|
|
### 第二步：法律检索——找到完整的规范链条
|
|
|
|
不是找到一条法条就够了，要找到**所有适用的规范层级**：
|
|
- 法律（人大）→ 行政法规（国务院）→ 部门规章 → 规范性文件
|
|
- 一般法 + 特别法叠加适用
|
|
|
|
**铁律：**
|
|
- 法条必须来自官方一手源（中国政府网、国家网信办、全国人大等）
|
|
- 律所文章≠官方来源，只能作为检索线索
|
|
- 必须确认是现行有效版本（注意修正、修订）
|
|
- 征求意见稿≠正式稿（内容可能有重大差异）
|
|
|
|
### 第三步：法律分析——三段论推导结论
|
|
|
|
大前提（法律规范）→ 小前提（客户事实）→ 结论
|
|
|
|
三种结论类型：
|
|
- **可以**：满足条件即可推进
|
|
- **不可以**：法律明文禁止，硬红线
|
|
- **有条件可以**：需要采取合规措施后方可推进
|
|
|
|
**关键区分：**
|
|
- "法律明文禁止" vs "存在被认定的风险"——前者无裁量空间，后者需说明概率和应对
|
|
- 不确定时：说明不确定性来源 → 分析倾向性 → 给保守建议
|
|
- 没有先例≠没有风险
|
|
|
|
### 第四步：撰写——结论前置、读者导向
|
|
|
|
结构模板：
|
|
```
|
|
引言/背景（一段话交代委托事项和分析范围）
|
|
第一部分 事实基础（表格呈现运营主体、合作模式等）
|
|
第二部分 法律定性（行为性质判断、适用法律确定）
|
|
第三部分 风险分析及合规建议（按业务线/平台分别分析）
|
|
结论/总结（一段话直接回答"能不能做"）
|
|
声明/保留
|
|
附件（分类表、法规清单等）
|
|
```
|
|
|
|
编排原则：
|
|
- **结论前置**：每个板块第一句话就是结论
|
|
- **分而治之**：多个主体/业务线必须分别分析、分别给结论
|
|
- **建议要具体可执行**：不写"建议加强合规管理"，要写"在合同中明确约定X不介入Y环节"
|
|
- **表格善用**：事实对比、产品分类用表格
|
|
|
|
### 第五步：审查——四层校验
|
|
|
|
1. **法律适用审查**：法条编号正确？内容与原文一致？是否遗漏关键规范？是否有新法？
|
|
2. **逻辑审查**：结论能否从分析中推导？前后是否矛盾？前提假设是否标注？
|
|
3. **事实审查**：与客户提供的信息是否一致？未核实信息是否标注？
|
|
4. **文字校对**：错别字、多余空格、术语统一
|
|
|
|
## 语言表达规则
|
|
|
|
- 用客户能理解的语言说清法律问题，法条原文作为支撑放括号或脚注
|
|
- 区分"不得"（法律禁止）与"建议不要"（风险建议），绝不混淆
|
|
- 不确定时明确标注："经检索，目前尚无XX先例，但该风险在现行法律框架下无法完全排除"
|
|
- 不编造法条、不做商业决策、不用"据了解""一般认为"等无来源表述
|
|
|
|
## 格式规范
|
|
|
|
- 标题层级：一级"第X部分/一、"→ 二级"（一）"→ 三级"1）"，不超三级
|
|
- 法律名称：首次全称+简称，此后用简称
|
|
- 法条引用：《广告法》第34条第2款
|
|
- 表格：列宽合理，表头加粗，单元格内不超3行
|
|
- 声明段：正文最后、附件之前
|
|
|
|
## 法条核实方法（铁律）
|
|
|
|
本skill源于实际踩坑教训：
|
|
|
|
| 错误类型 | 实例 | 教训 |
|
|
|---------|------|------|
|
|
| 条号搞错 | 将条例第28条内容标注为第21条 | 必须逐条比对原文 |
|
|
| 征求意见稿当正式稿 | 征求意见稿第29条有"不得推送广告"，正式稿第28条删除了该表述 | 必须确认版本 |
|
|
| 法条归属搞错 | 将《未成年人保护法》第74条第3款的内容说成不在该法中 | 被质疑时先重新核实再回答，不凭记忆反驳 |
|
|
|
|
**核实步骤：**
|
|
1. 从官方源获取法规全文
|
|
2. 定位到具体条款，逐字核对
|
|
3. 确认版本时效性（制定/修订/修正日期）
|
|
4. 交叉验证（至少两个独立官方源）
|
|
|
|
## Pitfalls
|
|
|
|
- 开头结论语气不能过于肯定——如果后文全是限制条件，开头不能写"具有可行性"，要写"在满足以下条件的前提下具有可行性"
|
|
- 不要为了给客户想听的答案而回避风险
|
|
- 风险提示必须配解决方案——只说"有风险"没有意义
|
|
- 初稿永远不够好——法条核实是底线
|
|
- 被客户/同事质疑法条时：先重新核实再回应，不凭记忆辩解
|