Back to skills
SKILL.md
Ambiguity Stress Test
ASecurity对法律文本——合同、法规、规章或裁判文书——进行对抗式压力测试,检验其解释上的歧义: 找出受其约束的人们日后会对其含义产生分歧的薄弱接缝,并将每一处转化为具体的争议场景, 附双方论点、可能的结果和修复方案。当有人希望对法律文件进行压力测试、红队审查、 审计,或找出薄弱点、漏洞、缺口、歧义或起草问题时使用;当起草人希望在合同、法规、 规章或裁判文书发布前将其收紧时使用;当诉讼律师希望从裁判文书或合同中挖掘论点时使用; 或当有人交来一份法律文本并询问它会在哪里引发争议或进行争点识别时使用。对合同审查、 法规歧义分析、裁判文书射程分析和起草质量检查都触发本技能——即使使用者从未说出 "压力测试"或"歧义"。
- 9 stars
- 0 votes
- 0 copies
- 0 views
- Added September 25, 2026
Security analysis
100/100Pro scans all 8 files and shows the line behind each finding
npx -y skills add CSlawyer1985/legal-skillhub --skill ambiguity-stress-test --agent claude-codeAre you the author of Ambiguity Stress Test?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/cslawyer1985-ambiguity-stress-test)---
name: ambiguity-stress-test
description: >-
对法律文本——合同、法规、规章或裁判文书——进行对抗式压力测试,检验其解释上的歧义:
找出受其约束的人们日后会对其含义产生分歧的薄弱接缝,并将每一处转化为具体的争议场景,
附双方论点、可能的结果和修复方案。当有人希望对法律文件进行压力测试、红队审查、
审计,或找出薄弱点、漏洞、缺口、歧义或起草问题时使用;当起草人希望在合同、法规、
规章或裁判文书发布前将其收紧时使用;当诉讼律师希望从裁判文书或合同中挖掘论点时使用;
或当有人交来一份法律文本并询问它会在哪里引发争议或进行争点识别时使用。对合同审查、
法规歧义分析、裁判文书射程分析和起草质量检查都触发本技能——即使使用者从未说出
"压力测试"或"歧义"。
metadata:
author: "Seth J. Chandler"
author_link: "https://legaled.ai"
license: "Apache-2.0"
version: "2026-07-29"
jurisdiction: "United States"
language: "English"
---
# 解释歧义压力测试
对法律文本进行对抗式压力测试,找出受其约束的人们日后会对其含义产生分歧的地方。对每一处薄弱接缝,生成一个具体的争议场景:现实的事实模式、双方的论点、可能的结果和修复方案。文本可以是合同、法规、规章或裁判文书。
本技能建立在一条原则之上——**将检测器泛化,将解算器模块化。** 用于*发现*歧义的机制(解析、扫描、构建边界情形场景、构建两种合理解读)对每份法律文本都是一样的。用于*解决*歧义的机制则不同:合同歧义通过还原双方的交易安排来解决,法规歧义通过解释准则(canons of construction)解决,规章歧义通过解释准则加上授权法解决,裁判文书歧义通过先例学说解决。因此,本技能有一个通用的**核心**(本文件)和四个领域**配置文件**(位于 `resources/`)。运行核心;加载与文件匹配的那一个配置文件。
产出的是**争议,而非标记。** 代码检查工具会说"这个术语含糊"。本技能则设想出两个人,他们各自的解读若成立都可能有理由获胜——以及赌在这答案上的金钱或自由。潜在歧义对非专业人士是不可见的,直到有人向他们展示它将会引起的碰撞。
## 工作流
- **第 0 步**——选择配置文件并阅读其参考文件。
- **第 1 步**——解析文本。
- **第 2 步**——扫描缺陷。
- **第 3 步**——为每个确认的缺陷构建场景。
- **研究**——在第 3 步和第 4 步之间,确定有哪些来源可用,并对照它们核验存活下来的场景。仅限法规、规章和裁判文书配置文件;合同配置文件跳过此步。
- **第 4 步**——输出场景记录。
第 1-4 步是引擎,在各配置文件间完全相同。配置文件提供领域特定的缺陷家族、词表、相互竞争的解读方、推动可能结果的学说、改写语域以及任何质量门槛调整。
## 第 0 步——选择配置文件
识别文件类型,在扫描前阅读匹配的参考文件:
| 文件 | 配置文件 |
|----------|--------------|
| 合同、协议、租赁、保密协议(NDA)、录用通知、政策、服务条款 | `resources/contract.md` |
| 法规、法典条文、条例、已通过的法案 | `resources/statute.md` |
| 规章、机关规则、行政法规条款 | `resources/regulation.md` |
| 裁判文书、法院判决或判决草案 | `resources/opinion.md` |
如果文本是其他类型的规范性文件(遗嘱、条约、保险单、一套章程),运行最接近的配置文件并明确说明哪些界面要素不适用。如果输入混合了类型——例如一部法规及其配套规章——各自运行其配置文件,并同时检视两者之间的关联。
## 第 1 步——解析
将文本切分为可寻址单元,并建立四个工作清单:每个**定义术语**;每个**操作性条款**(权利、义务或权力——"应"、"可以"、"有权");每个**触发或条件**("如果"、"但条件为"、"在……时"、"如发生");以及每项**裁量权或单方权力的授予**。
对法规和规章,还要提取每一处对另一文件的**交叉引用**——最严重的缺陷就藏在这些链接里。对裁判文书,还要绘制结构部分——裁判要旨、支撑推理、旁论(dicta)、处理结果以及任何并存意见——因为裁判文书的操作性规则是潜在的,必须先重建才能加以检验。
## 第 2 步——扫描
将通用触发词表与当前配置文件的词表运行于每个单元之上,然后将七问诊断电池运行于每个被标记的单元以及整个文本之上。将每个确认的缺陷归类到六个通用家族之一或配置文件特定家族。将注意力投入争议真正产生的源头——定义、触发、条件、裁量权授予、交叉引用——并忽略样板条款(标题、序言、副本条款)。
### 通用缺陷分类
六个家族适用于任何法律文本。每个配置文件都增加自己的家族;这六个是最低限度。
- **A. 内部矛盾**——两条无法同时满足的条款。*自问:*如果我逐字执行两条,是否得到不可能或相反的结果?注意一般条款与特定条款处理同一主题之处。
- **B. 含糊的操作性术语**——一个开启或关闭某项权利却无定义、无衡量基准的词。*自问:*该术语决定金钱是否易手或自由是否丧失——两位诚实的读者能否在不同的位置划界?
- **C. 定义边界歧义**——一个*已定义*术语的定义边缘模糊,使真实事实既不能明确落入其内也不能明确落入其外。*自问:*我能否描述一个既可以说在内又可以说在外的现实事物?
- **D. 无标准的裁量**——一方主体对一项后果重大的决定拥有单方权力,却无明文标准、无中立裁决者、无审查。*自问:*由谁决定、依何标准、什么能阻止利己的决定?
- **E. 缺口 / 沉默**——文本未处理的情形:从未被保证发生的必要先决条件、缺失的救济、缺失的备选方案。*自问:*对每个必要步骤,如果被跳过、只完成一部分或不可能完成,由什么规则管辖?对每项义务,是否言明了违约后果?
- **F. 跨条款张力**——一处授予的权力悄然侵蚀另一处承诺的保护;两者各自有效,但合在一起一条吞噬另一条。*自问:*条款 A 中的一项权力是否让某一主体可以使其消灭条款 B 所承诺的内容?(该家族有一种*纵向*形态——较低位阶文件中的权力侵蚀较高位阶文件——由规章配置文件使用。)
家族按设计存在重叠。目标是覆盖面,而非干净划分。
### 通用触发词表
当单元包含以下内容时将其标记以供检查:
- *裁量词*——"完全酌情决定"、"由其酌情决定"、"按其确定"、"令……满意"、"视为" → 家族 D。
- *延迟确定词*——"待建立"、"待确定"、"待商定"、"按双方商定" → 家族 E。
- *未量化限定词*——"实质性"、"重大"、"重要"、"合理"、"立即"、"惯例"、"适当" → 家族 B。
- *开放式列举词*——"包括但不限于"、"诸如"、"等等" → 家族 C。
- *优先/覆盖词*——"尽管"、"取代"、"除……外"、"随时" → 家族 A。
- *单方变更词*——"不时"、"按……指定"、"按……指派"、"可修订或修改" → 家族 F。
- *交叉引用和时间词*——"以第……节为准"、"依据"、日期、具名期间、期限、生效日期表述 → 家族 F 和 A,加上日期计算检查。
配置文件的参考文件会向此清单添加领域特定的触发词。
### 诊断电池
对每个被标记的单元以及整个文本运行七个问题:上述六个家族问题,加上第七个——**术语一致性:** 每个定义术语是否被一致使用,是否出现未定义的近义词使对方可以主张其含义不同?通过全部七个问题的单元是健全的。未通过一个的单元是场景候选。配置文件会向电池添加自己的家族问题。
## 第 3 步——构建
发现缺陷是技能的一半;将其转化为非专业人士一眼就能理解的场景是另一半。构建受五条规则支配。
- **瞄准边界情形。** 绝不选择舒适地落在一个术语之内或之外的事实。选择*落在线上*的事实——唯一使接缝承重的事实模式。
- **为双方构建最强论证(steel-man)。** 每个场景以两个立场结尾,各具表面合理性、各引用真实文本、各有合理胜出的可能。**核心质量门槛:好的场景是称职的裁判庭无论怎么判都有道理的场景。** 如果一方明显占优,就使事实更尖锐直到对抗真实,或放弃该场景。
- **框定争议。** 两种解读,对立,相互排斥,并有具体的后果取决于答案。
- **使用文本自身的世界。** 真实的当事人、真实的标的物、现实的事实——一份来自未来的备忘录,而非抽象假设。
- **保持事实最少。** 三到六句。只要创造争议所需的内容;不要氛围,不要背景故事。
**叙事模板。** 第 1-2 句:触发事件。第 3 句:第一位解读方的立场及所主张的后果。第 4 句:第二位解读方的反方立场。叙事停在争议中途——它提出问题;分析层回答它。
**关卡。** 法规和规章配置文件增加*解释准则关卡*,裁判文书配置文件增加*先例关卡*:将每个候选歧义逐一通过配置文件的解释学说,只有在该等学说适用后仍确实可争辩的才予以保留。学说用一段话就能消灭的"歧义"是误报——删除它。合同配置文件无关卡;四角解释(four-corners)在那里可以接受。
## 研究与来源
适用于**法规、规章和裁判文书**配置文件。合同配置文件从文书本身内部解决,完全跳过本节——不要在合同审计上花费精力去调查来源。
学说消灭一些误报;既有判例消灭另一些。法院已经解释过的接缝不是活的争议,而仅阅读文书本身永远无法揭示这一点。本步骤的存在正是为了捕捉这一类误报,仅此而已。
### 使用哪个来源
取以下第一个适用者。每次审计决定一次,而非每个场景决定一次。
1. **用户的指示优先。** 如果用户指定来源——"使用 CourtListener"、"使用 Descrybe"、"就用网络"、"跳过研究"——照做。如果指定的来源不可用,明确说明并询问是否回退。绝不静默地用一个来源替代另一个:要求特定数据库却得到别的东西的用户,得到的是一个无法校准的结果。
2. **否则,使用已连接的。** 扫描前,检查本会话实际拥有哪些研究工具。寻找法律研究连接器——CourtListener、Descrybe、Midpage、Lexis 及类似工具都可以——并使用第一个合适的。
3. **否则,使用普通网络搜索。** 它比法律数据库弱,但对核心问题——法院是否已解释过该表述——是够用的。
4. **否则,仅从文本出发进行**,并在输出中说明。
### 要查找什么
- 法院是否已解释过争议表述,若是则场景已死,应删除。
- 同一法典的其他地方,或规章之上的授权法,是否解决了摘录部分遗留的问题。
- 对裁判文书:后来的法院如何解读它,以及它是否被限缩、区分或推翻。如果裁判文书已不复存在,对其未来射程的预测就毫无价值。
### 冠名学说,而非判例
优先使用学说而非引注。`likely_outcome` 字段要求的是推动预测的解释学说——*同类规则(ejusdem generis)*、从宽解释规则(rule of lenity)、*不利起草者解释(contra proferentem)*、反对赘余推定(presumption against surplusage)。学说是稳定的;判例引注会过时,未经验证的引注比没有更糟。
只有在研究步骤在本会话中实际验证过时才冠名具体判例。场景结果取决于一个未能验证的判例时,陈述学说并将该判例标记为未验证,而非静默删除。
### 说明发生了什么
每次审计以一行文字结尾,注明所用的来源——或说明没有可用来源且场景未对照既有判例核验。两个人审计同一部法规,一个有法律研究连接器、一个没有,会得到不同的结果。这是预料之中的。只有当输出不说明是哪一次运行产生的结果时,才显得像不可靠。
## 第 4 步——输出
将每个场景输出为一条含七个字段的记录。前三个是可见的"卡片";后四个是分析层。
| 字段 | 内容 |
|-------|---------|
| `title` | ≤ 8 个词,以平实语言点明缺陷类别 |
| `narrative` | 3-6 句,第 3 步模板,现在时,中性口吻 |
| `anchors` | 一个或多个条款编号(原生引用,而非位置猜测);多个锚点 = 跨条款或跨文件缺陷 |
| `defect_family` | 一个通用家族或配置文件特定家族 |
| `weak_point` | 一句话点明精确的文本缺陷 |
| `likely_outcome` | 预测的解决方式及推动它的解释学说——**由配置文件提供** |
| `redraft` | 以配置文件的起草语域,提出关闭该接缝的替换或补充措辞 |
只有 `likely_outcome` 和 `redraft` 的语域是领域特定的;核心产出其他一切不变。裁判文书配置文件修改此模式(`redraft` 变为对裁判文书的收紧,或在回顾模式下被替换为一组对抗论点)——参见 `resources/opinion.md`。
对预测结果要留有余地;它们是预测,不是宣判。当用户要求审计而非亮点时,**报告覆盖面**——扫描所暴露的每个缺陷——而不仅是少数重点。
每次审计以一行**来源说明**收尾,记录研究步骤使用了什么,如上文"说明发生了什么"。合同审计时该说明写作文书按自身条款解读且不适用研究步骤。
## 范围——本技能不做什么
本技能检测**解释歧义**,而非**效力**。合同可以完全清晰却完全不可执行;法规可以毫无歧义却违宪。从四角解读出发,检测器两者都捕捉不到——清晰不等于合法。法规和规章配置文件在其领域要求时略微越出文本之外(宪法回避和越权(ultra vires)家族),但那只是歧义检测滑向效力判断,而非系统性的合法性审计。如果用户想要效力或可执行性意见,明确说明并将其视为独立的另一轮工作。
## 法域
检测器与法域无关。六个缺陷家族、触发词表和七问电池对任何英文规范性文本都适用,因为它们取决于语言如何运作,而非谁的准据法。
解算器则不是。四个配置文件都基于美国学说运行——解释准则、授权法与越权框架,以及美国先例法——工作示例也都是美国材料。在该体系之外,扫描的一半可移植,`likely_outcome` 的一半则不可。当文本明显来自其他法域时,运行扫描,并要么声明结果是基于美国解释框架预测的,要么替换为当地学说并予以说明。
## 附带资源
只阅读与文件匹配的那一个配置文件;不要四个都读。
- `resources/contract.md`——合同、协议、租赁、政策、服务条款。
- `resources/statute.md`——法规、法典条文、条例、已通过的法案。
- `resources/regulation.md`——机关规则和行政法规;以法规配置文件为基础,该文件也必须一并阅读。
- `resources/opinion.md`——裁判文书,包括草稿;承载两种输出模式和一份工作示例。
## 局限与风险
本技能产出对法律文本的解释性分析。它不是法律意见,不决定任何人的权利,其预测结果也只是预测而非答案。未经律师本人对文书的阅读,其任何产出都不应被提交、依赖或发送给相对方。
有五项风险值得点名。
**预测留有余地是有原因的。** `likely_outcome` 字段陈述管辖学说大概会如何解决一条接缝。法院解决接缝的方式各不相同,而一个正是为了任何一方都能获胜而构建的场景,按定义就是结果不确定的。
**时效性取决于研究步骤。** 没有法律研究来源,本技能就无法知道法院已解释过该表述,或受审裁判文书已被限缩或推翻。来源说明披露了是哪一次运行产生了审计;在依赖结果前先读它。
**漏报是不可见的。** 扫描只能发现从文本和所运行的研究中可达的缺陷。依赖行业惯例、当事人之间的交易过程、未提供的附表或附件、或无法解决的交叉引用的缺陷不会出现——而它的缺席与它的不存在看起来毫无二致。
**误报与核验程度成正比地存活。** 学说关卡删除的是准则会消灭的歧义;只有研究步骤能删除判例已经消灭的歧义。仅四角解读的运行会过度报告。
**场景是对抗式构造。** 每个场景都是为了从边界情形中制造真实对抗而构建的,这意味着事实是为难度而非为可能性而选择的。实践中极少出现的接缝可能读起来很紧迫。据此权衡它们。
本技能不包含可执行代码,除宿主提供的任何研究工具外自身不做网络调用,也不将会话外的数据移动出去。
Files in this skill
- LICENSE
- NOTICE
- README.md
- SKILL.md
- resources/contract.md
- resources/opinion.md
- resources/regulation.md
- resources/statute.md
Attribution
Comments
Loading comments…