Back to Details

math-spec-driven

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Math Spec-Driven Skill

数学规范驱动型Skill

Purpose

用途

Use this skill whenever a task requires rigorous, unambiguous specification of a system, process, relationship, or transformation. Mathematical specification is a methodology — not a subject. It applies whenever precision, completeness, and falsifiability matter more than narrative approximation.
This skill teaches Claude to think in mathematical structures: sets, functions, relations, invariants, and formal constraints. It is domain-agnostic. The formalism is the tool; the domain is whatever the user brings.
当任务需要对系统、流程、关系或转换进行严谨、无歧义的规范定义时，即可使用本Skill。数学规范是一种方法论，而非某一学科。只要精确性、完整性与可证伪性比自然语言的近似描述更重要，就可以应用该方法。
本Skill会引导Claude以数学结构的方式思考：集合、函数、关系、不变量以及形式化约束。它与领域无关，形式化方法是工具，用户的需求领域才是核心。

Core Philosophy

核心理念

Mathematics is simultaneously:
  • A system (self-consistent, closed under its own rules)
  • A language (capable of expressing any precisely definable concept)
  • A specification method (the most unambiguous way to define what something IS and what it must DO)
When applied as a specification methodology, mathematics forces three things:
  1. Explicitness — every assumption must be stated
  2. Composability — every component can be independently verified then combined
  3. Falsifiability — every claim is either provable or disprovable within the system
数学同时具备以下三种属性：
  • 一个系统（自洽，遵循自身规则闭环）
  • 一种语言（能够表达任何可精确定义的概念）
  • 一种规范方法（定义事物本质与必须具备的行为的最无歧义方式）
当作为规范方法应用时，数学能强制实现三点要求：
  1. 明确性——所有假设必须清晰陈述
  2. 可组合性——每个组件可独立验证后再组合
  3. 可证伪性——每个论断在系统内要么可证明，要么可证伪

When to Apply This Skill

适用场景

Trigger this skill when you encounter:
  • Ambiguous requirements that need precise boundaries
  • Systems with many interacting parts that must remain consistent
  • Transformations where the input/output relationship must be guaranteed
  • Constraints that must hold under all conditions (invariants)
  • Decisions that need justification beyond intuition or convention
  • Any domain where "it depends" is not an acceptable specification
当遇到以下情况时，触发本Skill：
  • 需求模糊，需要明确的边界定义
  • 系统存在多个交互组件，必须保持一致性
  • 输入输出关系必须得到严格保障的转换场景
  • 必须在所有条件下都成立的约束（不变量）
  • 需要超越直觉或常规经验的决策依据
  • 任何无法接受“视情况而定”这种模糊表述的领域

The Math Spec Method

数学规范方法步骤

Step 1 — Model the Domain

步骤1 — 领域建模

Map the real-world problem onto mathematical primitives:
Real WorldMathematical Primitive
A collection of thingsSet 
S
A thing with propertiesTuple or Record 
(a, b, c)
A process or transformationFunction 
f: A → B
A relationship between thingsRelation 
R ⊆ A × B
A constraint that must always holdInvariant / Predicate 
P(x): Bool
A sequence of statesTrace 
[s₀, s₁, …, sₙ]
A measurementMetric 
d: S × S → ℝ≥0
Task: Before writing any specification, identify which primitives apply. Name them explicitly.
将现实世界的问题映射到数学基本元素：
现实世界数学基本元素
一组事物集合 
S
具备属性的事物元组或记录 
(a, b, c)
流程或转换函数 
f: A → B
事物间的关系关系 
R ⊆ A × B
必须始终成立的约束不变量/谓词 
P(x): Bool
状态序列轨迹 
[s₀, s₁, …, sₙ]
度量指标度量函数 
d: S × S → ℝ≥0
任务： 在撰写任何规范之前，先确定适用的数学基本元素，并为其明确命名。

Step 2 — Define the Universe of Discourse

步骤2 — 定义论域

Before specifying behavior, define what EXISTS in the system:
Let U = the universe of all valid entities in this domain
Let S ⊆ U = the subset currently under consideration
Let ∅ = the empty/null case (always handle this explicitly)
Ask:
  • What are the atomic elements? (Cannot be decomposed further)
  • What are the compound elements? (Defined in terms of atoms)
  • What is explicitly excluded?
在定义行为之前，先明确系统中存在的所有实体：
Let U = 该领域中所有有效实体的全集
Let S ⊆ U = 当前考虑的子集
Let ∅ = 空集/空值情况（必须明确处理）
思考以下问题：
  • 原子元素是什么？（无法再分解的元素）
  • 复合元素是什么？（由原子元素定义的元素）
  • 明确排除的元素有哪些？

Step 3 — Specify Functions and Transformations

步骤3 — 定义函数与转换

Every transformation has a signature and a contract:
f: A → B

Precondition:  P(a) must hold before f is applied
Postcondition: Q(f(a)) must hold after f is applied
Invariant:     I(a) = I(f(a))  [what must NOT change]
Write specs in this form even in prose-heavy domains. Example:
classify: Document → Category

Pre:  Document is non-empty, language is detected
Post: Category ∈ {defined_taxonomy}
Inv:  Document content is unchanged by classification
每个转换都有签名和契约：
f: A → B

前置条件:  应用f前必须满足P(a)
后置条件:  应用f后必须满足Q(f(a))
不变量:     I(a) = I(f(a))  [什么内容绝对不能改变]
即使在以自然语言为主的领域，也请以该格式撰写规范。示例：
classify: Document → Category

前置条件:  文档非空，语言已识别
后置条件:  Category ∈ {已定义的分类体系}
不变量:  分类操作不改变文档内容

Step 4 — State Invariants Explicitly

步骤4 — 明确陈述不变量

Invariants are properties that must hold at ALL times, not just at some steps.
For each invariant, state:
  • What it asserts (the property)
  • When it must hold (always / at boundaries / after each operation)
  • What violates it (the failure mode)
Pattern:
∀ x ∈ S: P(x)           — Universal invariant
∃ x ∈ S: P(x)           — Existence guarantee
P(x) ⟹ Q(f(x))          — Conditional guarantee
¬(P(x) ∧ Q(x))          — Mutual exclusion
不变量是必须始终成立的属性，而非仅在某些步骤成立。
对于每个不变量，需明确：
  • 断言内容（该属性的具体描述）
  • 生效时机（始终生效 / 在边界点生效 / 每次操作后生效）
  • 违反情况（失效模式）
常用范式：
∀ x ∈ S: P(x)           — 全称不变量
∃ x ∈ S: P(x)           — 存在性保证
P(x) ⟹ Q(f(x))          — 条件性保证
¬(P(x) ∧ Q(x))          — 互斥约束

Step 5 — Handle Edge Cases as First-Class Concerns

步骤5 — 将边界情况作为核心需求处理

Mathematical completeness requires handling the boundary:
  • The empty set (
    S = ∅
    )
  • The singleton (
    |S| = 1
    )
  • The degenerate input (zero, negative, infinite, null)
  • The identity case (
    f(x) = x
    )
  • The composition case (
    f(g(x))
    — does order matter?)
Never specify only the "happy path." A spec is incomplete if it omits boundary behavior.
数学上的完整性要求必须处理边界情况：
  • 空集 (
    S = ∅
    )
  • 单元素集 (
    |S| = 1
    )
  • 退化输入（零、负数、无穷大、空值）
  • 恒等情况 (
    f(x) = x
    )
  • 组合情况 (
    f(g(x))
    — 顺序是否重要？)
绝不能仅定义“正常路径”。如果规范遗漏了边界行为，那么它就是不完整的。

Step 6 — Compose and Verify

步骤6 — 组合与验证

Once individual components are specified, compose them:
h = f ∘ g   (h(x) = f(g(x)))

Verify:
  - Codomain of g matches domain of f
  - Preconditions of f are implied by postconditions of g
  - Invariants of both f and g are preserved by h
If composition breaks: the specification has a gap. Find and fill it.
当各个组件的规范完成后，将它们组合起来：
h = f ∘ g   (h(x) = f(g(x)))

验证：
  - g的陪域与f的定义域匹配
  - f的前置条件由g的后置条件隐含保证
  - f和g的不变量都能被h保留
如果组合后出现问题：说明规范存在漏洞，需要找到并填补。

Step 7 — Express Uncertainty with Precision

步骤7 — 精确表达不确定性

Where things are probabilistic or unknown, apply the right formalism:
P(outcome | evidence)     — conditional probability
E[X]                      — expected value
Var(X)                    — variance / spread
argmax_{x} f(x)           — best choice under a criterion
Uncertainty does not mean imprecision — it means quantified imprecision.
当存在概率性或未知情况时，使用合适的形式化方法：
P(outcome | evidence)     — 条件概率
E[X]                      — 期望值
Var(X)                    — 方差/离散程度
argmax_{x} f(x)           — 某一准则下的最优选择
不确定性不意味着不精确——它意味着可量化的不精确。

Output Format

输出格式

When producing a mathematical specification, always structure output as:
undefined
生成数学规范时，请始终按照以下结构输出：
undefined

Specification: [Name]

规范：[名称]

1. Domain Model

1. 领域模型

[Named sets, types, and primitives]
[已命名的集合、类型与基本元素]

2. Functions / Operations

2. 函数/操作

[Signatures, preconditions, postconditions, invariants]
[签名、前置条件、后置条件、不变量]

3. Invariants

3. 不变量

[Formal or semi-formal statements of what must always hold]
[形式化或半形式化的始终成立的约束陈述]

4. Edge Cases

4. 边界情况

[Explicit boundary conditions and their specified behavior]
[明确的边界条件及其对应的规范行为]

5. Composition / Interaction

5. 组合/交互

[How components combine; verification that composition is sound]
[组件如何组合；验证组合的合理性]

6. Open Questions

6. 待明确问题

[What is explicitly left unspecified and why]

---
[明确未定义的内容及其原因]

---

Notation Guide (Use Consistently)

符号指南（请保持一致性）

SymbolMeaning
∀
For all
∃
There exists
∈
Is a member of
⊆
Is a subset of
∅
Empty set
→
Function mapping (A → B)
⟹
Logical implication
⟺
If and only if
∧
Logical AND
∨
Logical OR
¬
Logical NOT
∘
Function composition
≜
Defined as
`S
⊥
Undefined / bottom (error state)
Always define any non-standard notation locally.
符号含义
∀
对于所有
∃
存在
∈
属于
⊆
是子集
∅
空集
→
函数映射（A → B）
⟹
逻辑蕴含
⟺
当且仅当
∧
逻辑与
∨
逻辑或
¬
逻辑非
∘
函数组合
≜
定义为
`S
⊥
未定义/错误状态
如果使用非标准符号，请在本地明确定义。

Example (Illustrative — Domain is Arbitrary)

示例（仅作说明——领域可任意选择）

Task: Specify a content routing system. (Domain could be emails, support tickets, API calls, documents — the structure is what matters.)
undefined
任务： 定义一个内容路由系统的规范。 (领域可以是邮件、支持工单、API调用、文档——核心是规范的结构。)
undefined

Specification: Content Router

规范：内容路由系统

1. Domain Model

1. 领域模型

Let M = set of all incoming messages (finite, non-empty) Let C = {c₁, c₂, …, cₙ} = finite set of destination categories Let R = set of routing rules, where each r ∈ R is a predicate r: M → Bool Let priority: R → ℕ = total ordering on rules (lower = higher priority)
Let M = 所有传入消息的集合（有限、非空） Let C = {c₁, c₂, …, cₙ} = 有限的目标分类集合 Let R = 路由规则集合，每个r ∈ R是一个谓词r: M → Bool Let priority: R → ℕ = 规则的全序关系（数值越小优先级越高）

2. Functions / Operations

2. 函数/操作

route: M → C ∪ {⊥}
Pre: m ∈ M, |R| ≥ 1 Post: If ∃ r ∈ R such that r(m) = true: route(m) = category associated with highest-priority matching r Else: route(m) = ⊥ [unrouted — must trigger fallback handler] Inv: m is not modified by route(m)
route: M → C ∪ {⊥}
前置条件: m ∈ M, |R| ≥ 1 后置条件: 如果存在r ∈ R满足r(m) = true: route(m) = 匹配的最高优先级规则对应的分类 否则: route(m) = ⊥ [未路由——必须触发 fallback 处理程序] 不变量: route(m) 不会修改m本身

3. Invariants

3. 不变量

∀ m ∈ M: route(m) is deterministic (same input → same output) ∀ m ∈ M: at most one category is assigned (no split routing) If route(m) = ⊥, an alert must be emitted
∀ m ∈ M: route(m) 是确定性的（相同输入→相同输出） ∀ m ∈ M: 最多分配一个分类（不支持拆分路由） 如果route(m) = ⊥，必须发出告警

4. Edge Cases

4. 边界情况

M = ∅ → route is never called; system is idle (valid state) R = ∅ → route(m) = ⊥ for all m (all messages unrouted) |C| = 1 → route(m) = c₁ for all matched m (trivial routing) Two rules match → highest priority(r) wins; tie-break by rule index
M = ∅ → route 函数永远不会被调用；系统处于空闲状态（有效状态） R = ∅ → 所有m对应的route(m) = ⊥（所有消息都未路由） |C| = 1 → 所有匹配的m对应的route(m) = c₁（简单路由） 两条规则匹配 → 优先级最高的规则生效；若优先级相同则按规则索引打破平局

5. Composition

5. 组合

filter ∘ route: filter: M → M' removes malformed messages before routing Pre of route is satisfied by Post of filter Composition valid iff filter guarantees m' ∈ M for all outputs
filter ∘ route: filter: M → M' 会在路由前移除格式错误的消息 route的前置条件由filter的后置条件满足 当且仅当filter保证所有输出m' ∈ M时，组合才有效

6. Open Questions

6. 待明确问题

  • How are rules added/removed at runtime? (Mutation spec not defined here)
  • What is the SLA on route latency? (Performance spec out of scope)

---
  • 运行时如何添加/删除规则？（未定义修改规范）
  • 路由延迟的SLA是什么？（性能规范超出本范围）

---

Anti-Patterns to Avoid

需避免的反模式

Anti-PatternProblemFix
"It should handle all cases"Not falsifiable — not a specList every case explicitly
"Usually returns X"Probabilistic without quantificationState P(returns X) or define when it doesn't
Defining only the happy pathCollapses on edge casesAlways specify ∅, ⊥, and boundary inputs
Natural language for constraintsAmbiguous, multi-interpretableRestate as predicate logic or structured form
Composing without domain/codomain checkSilent type errors at system boundariesVerify f ∘ g explicitly before combining
反模式问题修复方案
“它应该处理所有情况”不具备可证伪性——这不是规范明确列出所有情况
“通常返回X”未量化的概率性描述说明返回X的概率P，或者定义不返回X的场景
仅定义正常路径在边界情况会失效始终明确处理∅、⊥和边界输入
用自然语言描述约束模糊、存在多种解读重写为谓词逻辑或结构化形式
组合时不检查定义域/陪域系统边界会出现静默类型错误组合前明确验证f ∘ g的合理性

Quality Checklist

质量检查清单

Before delivering any math-spec-driven output, verify:
  • Every set is named and defined
  • Every function has a signature (domain → codomain)
  • Every function has preconditions and postconditions
  • At least one invariant is stated
  • Edge cases (∅, ⊥, boundary) are explicitly handled
  • Compositions are verified for domain/codomain alignment
  • Open questions are listed — not silently omitted
  • Notation is consistent throughout
在交付任何数学规范驱动的输出之前，请验证以下内容：
  • 所有集合都已命名并定义
  • 所有函数都有签名（定义域→陪域）
  • 所有函数都有前置条件和后置条件
  • 至少陈述了一个不变量
  • 边界情况（∅、⊥、边界值）已明确处理
  • 组合时已验证定义域/陪域的匹配性
  • 待明确问题已列出——而非默认忽略
  • 符号使用保持一致