statute-analysis

⚠️ 实验性 — 此技能仅用于教育和提供信息，不构成法律建议。使用此技能的全部责任由用户承担。采取任何行动前，请咨询具备资质的法律专业人士。

法规分析

用于阅读、解读和适用法规、规章及规则的生产就绪框架。涵盖完整流程：从确定法律层级，到提取可执行要求并梳理实施义务。

---

目录

• 法律层级
• 初步步骤
• 工具
• 核心解释技巧
• 法律解释规则
• 解释依据
• 要求分类
• 跨司法管辖区分析
• 参考指南
• 工作流
• 故障排除
• 成功标准
• 范围与限制
• 反模式
• 工具参考

---

法律层级

了解法律渊源层级是法规分析的基础。

渊源	制定者	权威性	示例
宪法	主权者／人民	最高	美国宪法、欧盟条约
法律	立法机关	主要立法	GDPR、《清洁空气法》、《人工智能法案》
规章	行政机构	授权权限	FDA 21 CFR、FTC 规则
规则	机构或法院	程序性／解释性	《联邦民事诉讼规则》
指南	机构	不具约束力，但有参考价值	FDA 指南文件、CNIL 指南
判例法	法院	在司法管辖区内具有约束力	最高法院判例

关键原则： 上位渊源优先于下位渊源。规章不得超越法律授权。指南不得创设法律中没有依据的新义务。

---

先行澄清

分析前，请确认以下信息。如有任何信息未知或含糊不清，请询问，不要自行假设：

• 确切的法律／规章及其现行有效版本 — 分析已被取代或废止的版本会得出错误义务；提取任何内容前请确认其时效性
• 你在其中的角色 — 提供者还是部署者、控制者还是处理者，这决定了哪些义务对你有约束力，以及需要提取哪些义务
• 涉及的司法管辖区 — 需要据此标明跨司法管辖区冲突和先占问题；不同制度的定义各异，不得相互混用

停止规则：只询问最可能改变分析结果的 2-3 个问题。如果用户说“直接起草”，则继续，并在分析开头列出假设。

初步步骤

解释任何法规条款前，请完成以下检查：

1. 确认时效性和状态 -- 这是当前有效的版本吗？检查是否有修正案、废止或失效条款。使用官方来源（政府公报、EUR-Lex、congress.gov）。
2. 了解监管体系 -- 有哪些规章、规则和指南用于落实该法律？梳理完整的层级结构。
3. 浏览完整结构 -- 深入具体条款前，先阅读目录、定义部分、适用范围条款和过渡条款。
4. 找出定义部分 -- 几乎所有法律都会定义关键术语。这些定义优先于普通含义。
5. 检查生效日期 -- 不同条款的生效日期可能不同。梳理合规时间表。
6. 确定你的角色 -- 法律会根据读者的角色施加不同义务（例如，欧盟《人工智能法案》中的“提供者”与“部署者”，GDPR 中的“控制者”与“处理者”）。

---

工具

法规关键词分析器

扫描法规文本中的操作性关键词，并对义务、许可、条件和豁免进行分类。

# Analyze a statute file
python scripts/statute_keyword_analyzer.py --input statute.txt

# Analyze with JSON output
python scripts/statute_keyword_analyzer.py --input regulation.txt --json

# Analyze inline text
python scripts/statute_keyword_analyzer.py --text "The controller shall implement appropriate technical measures..."

# Save analysis report
python scripts/statute_keyword_analyzer.py --input statute.txt --output analysis.json

要求分类器

按类型、实施团队、执行机制和处罚对法定要求进行分类。

# Classify requirements from a JSON list
python scripts/requirement_classifier.py --input requirements.json

# Classify with JSON output
python scripts/requirement_classifier.py --input requirements.json --json

# Classify inline requirement
python scripts/requirement_classifier.py --text "Controllers must provide data subjects with a privacy notice at the point of collection"

# Generate implementation matrix
python scripts/requirement_classifier.py --input requirements.json --output matrix.json

---

核心解释技巧

定义分析

法定定义决定含义。请注意所用动词：

动词	类型	含义	示例
"means"	穷尽式	定义完整；不适用其他含义	"'Personal data' means any information relating to an identified or identifiable natural person"
"includes"	示例式	定义提供示例，但不限于这些示例	"'Processing' includes collection, recording, organization, structuring..."
"does not include"	排除式	明确将相关项目排除在适用范围之外	"'Consumer' does not include a natural person acting in a commercial or employment context"
"refers to"	引用式	纳入外部定义	"'Harmonised standard' refers to a European standard as defined in Regulation (EU) No 1025/2012"

操作性关键词

关键词	分类	法律效力
shall	强制性	产生义务；必须执行
must	强制性	在现代立法起草中，与 "shall" 含义相同
may	许可性	给予许可；可选择是否执行
may not	禁止性	形成禁令
and	合取	所列项目均为必需
or	析取	满足所列任一项目即可
unless	例外	条件满足时，该规则不适用
except	例外	将特定项目排除在规则之外
subject to	附条件	规则适用，但受另一条款的修改
notwithstanding	优先适用	本条款优先于相冲突的条款
provided that	条件	增加必须满足的要求
if...then	条件式	触发条件及其结果
upon	时间触发	事件发生时必须采取行动

合取与析取分析

这一区分决定了是否必须满足所有条件，或只需满足任一条件。

模式	解读	实际影响
"A, B, and C"	三项均为必需	必须满足每一项
"A, B, or C"	满足任一项即可	满足任意一项即可
"A, B, and/or C"	有歧义	标记以待澄清；结合上下文分析
"both A and B"	明确为合取	必须同时满足两项
"either A or B"	明确为析取	满足其中一项即可
串列逗号歧义	取决于上下文	为保持一致，适用整部法案规则

---

法律解释原则

完整的 12 条解释原则请参阅 references/canons_of_construction.md。

快速参考

准则	核心规则	适用情形
一般术语准则	一般术语按一般含义解释	默认解释
明示其一排除其他	明示一项即排除其他项	具体列表中没有兜底条款
整体法案规则	对条款作一致解释	各章节之间存在明显冲突
一致用语准则	同一术语在全文含义相同	术语多次出现
有意义的差异准则	不同术语含义不同	使用了相似但有区别的术语
避免赘述准则	每个词都有含义；不应重复	倾向于将某些词视为赘词
同类解释准则	词义由其关联词决定	列表中出现含义模糊的术语
同类限制准则	概括性用语跟在具体事项之后时，范围受限	出现“……以及其他类似事项”模式
避免使条款失效准则	优先采用能使条款生效的解释	存在两种可能的解释
避免荒谬结果准则	排除荒谬结果	按字面解释会产生不合逻辑的结果
救济性法规准则	作宽泛解释	消费者保护、安全法规
从宽解释规则	存在歧义时，应有利于受规制方	刑事条款或处罚条款

---

解释依据

当成文法文本存在歧义时，按以下顺序查阅相关依据：

优先级	依据	权重	查找位置
1	成文法文本本身	具有控制效力	官方公报、法典
2	定义部分	具有控制效力	通常位于开篇条款或章节
3	立法目的（说明条款、序言）	权重较高	序言、“鉴于”条款
4	法律解释准则	权重较高	法律论著、判例法
5	解释该条款的判例法	权重较高至中等	法院数据库
6	主管机关为实施法规而制定的规章	权重中等	主管机关网站、CFR
7	主管机关指南和常见问题解答	仅具说服力	主管机关网站
8	立法历史	权重较低（因司法管辖区而异）	国会记录、Hansard
9	学术评论	仅具说服力	法律期刊

---

要求分类

每项法定要求都对应一个实施类别：

类型	描述	典型负责人	示例
信息披露	必须向某人提供信息	法务 / 合规	隐私声明要求
运营	必须建立流程或程序	运营 / 合规	记录保存义务
技术	必须具备系统能力或保障措施	工程	加密、访问控制
UI/设计	用户界面必须包含特定元素	产品 / 设计	同意机制、退出按钮
组织	必须设立治理结构或岗位	管理层 / 人力资源	任命 DPO、董事会监督
文档	必须保存书面记录	法务 / 合规	影响评估、审计跟踪
报告	必须向主管机关提交信息	法务 / 合规	违规通知、年度报告

---

跨司法管辖区分析

当多个司法管辖区的要求同时适用时：

1. 确定适用的司法管辖区 -- 用户、实体和数据分别位于何处？
2. 识别重叠要求 -- 许多框架包含共同义务。
3. 采用最高共同标准 -- 按满足所有司法管辖区要求的最严格标准进行设计。
4. 标记冲突 -- 若要求确实冲突，应记录冲突并寻求法律建议。
5. 检查优先适用规则 -- 联邦法律可能优先于州法律；欧盟法规可能优先于成员国法律。

---

执法分析

对于每项法定要求，评估执法风险：

因素	评估问题
执法机构	由哪个机构执法？该机构的执法活跃度如何？
处罚类型	民事罚款、刑事处罚还是行政制裁？
处罚严厉程度	固定金额、按营业额比例计算，还是按每次违规计算？
整改期限	处罚生效前是否有权整改？
私人诉权	个人能否针对违规行为提起诉讼？
执法历史	该条款是否曾被积极执行？
监管指引	该机构是否已明确执法重点？

---

参考指南

指南	路径	说明
法律解释原则	references/canons_of_construction.md	12 项原则，包含定义、示例及误用警示
法律条文结构	references/statutory_structure.md	法律的组织方式、生效日期、优先适用及执法

---

工作流

工作流 1：首次研读新法规

1. 浏览完整目录和结构。
2. 阅读定义部分和适用范围条款。
3. 检查生效日期和过渡条款。
4. 确定你在该法规下的角色。
5. 对全文运行 scripts/statute_keyword_analyzer.py。
6. 查看义务／许可／例外对照表。
7. 找出适用于你所承担角色的条款。
8. **验证：**已整理定义、确定角色并列出关键义务。

工作流 2：提取并分类要求

1. 提取所有包含 "shall"、"must" 或其他强制性措辞的条款。
2. 对每项要求，确定：谁（主体）、做什么（行为）、何时（触发条件／期限）、如何（标准）。
3. 对提取的要求运行 scripts/requirement_classifier.py。
4. 查看实施矩阵。
5. 将每项要求分配给一个实施团队。
6. 根据执法风险和期限确定优先级。
7. **验证：**每项强制性条款均已分类、分配并确定优先级。

工作流 3：解析交叉引用

1. 找出目标条款中的所有交叉引用（例如“受第 X 条约束”“如第 Y 节所定义”）。
2. 完整阅读每项被引用的条款。
3. 判断交叉引用是修改、限制还是补充目标条款。
4. 检查是否存在循环引用或引用链（A 引用 B，而 B 又引用 C）。
5. 记录完整内容——即经所有交叉引用修正后的目标条款。
6. **验证：**所有交叉引用均已解析；不存在悬空引用。

---

故障排除

问题	可能原因	解决方法
法规中未定义某术语	立法机关采用了该术语的普通含义	运用一般术语解释原则；查阅判例，了解司法定义
“和／或”存在歧义	起草不够严谨	查阅立法历史；运用整体法案解释规则；标记以供法律审查
条款之间相互冲突	后续条款可能优先于前面的条款	检查是否存在“不论……如何”的条款；适用后法优先原则
门槛未定义	已授权通过法规加以规定	查阅实施法规和机构指引
条款似乎不起作用	可能是过渡性条款或占位条款	检查生效日期和修订历史
交叉引用指向已废止的条款	法规修订后未更新	检查保留条款；适用反对无效解释的推定

---

成功标准

标准	目标
所有定义术语均已编目	定义部分的映射率达到 100%
已提取义务	识别出每一项使用“shall/must”的规定
已分类要求	每项要求均注明类型、负责人、执行方式和优先级
已解决交叉引用	不存在未解决的引用
已评估执行风险	对每项重大义务均进行了执行分析
实施矩阵完整	已将要求分配给团队并注明时间表

---

范围与限制

**范围内：**阅读和解读法规文本、提取要求、对义务进行分类、运用法律解释原则、绘制执行风险图谱。

**范围外：**提供法律建议、预测法院判决结果、起草立法、解读判例裁决、进行宪法分析。

**免责声明：**此技能提供一套结构化的法规分析方法，不构成法律建议。对于具有约束力的解释，请务必咨询合格的法律顾问。

---

反模式

反模式	失败原因	更好的做法
孤立地阅读某个条款	法规彼此关联；孤立阅读会遗漏交叉引用、定义和范围限制	解读前务必先阅读定义、范围和交叉引用的条款
将指导意见视为法律	机构指导意见不具约束力且可能变更；仅依据指导意见构建合规方案会带来风险	以指导意见辅助解读，但以法规文本作为合规依据
忽略“法规未提及的内容”	沉默可能意味着许可、授权或疏漏；假设法规涵盖所有情况会导致合规缺口	主动检查法规是否涉及该情形；若没有，则分析原因以及哪些内容可以填补空白
将一个司法管辖区的解释套用于另一个	GDPR 中的“个人数据”与 CCPA 中的“个人信息”并不完全相同；交叉套用定义会造成错误	使用每部法规自身的定义和解释框架，分别进行分析
跳过定义部分	法规中的定义优先于通常含义；遗漏这些定义会导致根本性的误读	任何实质性分析之前，务必先阅读定义部分

---

工具参考

工具	输入	输出	使用场景
statute_keyword_analyzer.py	法规文本文件或内联文本	义务／许可／例外映射	对任何立法文本进行初步分析
requirement_classifier.py	要求列表（文本或 JSON）	包含类型、团队和执行方式的实施矩阵	将法规义务转化为可执行的实施任务