regex-builder

已弃用 — 现代 Claude 模型原生即可生成准确且解释清晰的正则表达式模式， 并提供边缘情况测试套件和多语言用法示例。这项技能带来的提升几乎为零。仅保留作存档参考。

正则表达式构建器

将匹配要求（正例和反例）转换为经过测试的正则表达式模式，并提供逐组件说明、捕获组文档、 边缘情况识别，以及可直接使用的 Python 和 JavaScript 代码。

参考文件

文件	内容	加载时机
references/character-classes.md	字符类参考、Unicode 类别、POSIX 类	始终
references/quantifiers.md	量词行为、贪婪与惰性及占有式量词、回溯	模式需要重复匹配时
references/common-patterns.md	经过验证的电子邮件、URL、电话、IP、日期、UUID 等模式	请求常见验证时
references/flavor-differences.md	Python、JavaScript、PCRE、POSIX 之间的语法差异	需要多语言用法时

前置条件

• 清晰的规范：哪些内容应该匹配，哪些不应该匹配
• 目标正则表达式风格（Python re、JavaScript、PCRE）——默认为 Python

工作流

阶段 1：收集示例

收集正例（应该匹配）和反例（不应该匹配）：

1. 来自用户 — 用户明确提供的示例
2. 来自上下文 — 如果用户说“匹配电子邮件地址”，则推断标准的正例和 反例
3. 来自数据 — 如果提供了样本数据，则识别其中的模式

至少需要 3 个正例和 3 个反例。示例过少可能导致模式对特定案例过拟合。

阶段 2：推断模式

分析示例以构建模式：

1. 识别固定字面字符 — 所有正例中出现在相同位置的字符
2. 识别字符类 — 出现不同字符但遵循某种模式的位置（数字、字母、字母数字）
3. 识别重复 — 出现次数可变的元素
4. 识别可选元素 — 部分正例中存在、其他正例中不存在的部分
5. 识别锚定方式 — 模式是否必须匹配整个字符串，还是可以匹配子字符串？

阶段 3：解释模式

将模式拆分为组件表：

组件	含义
^	字符串开头
[A-Za-z]	一个字母（大写或小写）
\d{3,5}	3 到 5 位数字
$	字符串结尾

如果模式使用了捕获组，请单独记录。

阶段 4：生成边缘情况

针对每个模式，识别可能引发问题的输入：

1. 空字符串 — 模式能否正确处理？
2. 近似匹配字符串 — 与有效匹配仅相差一个字符
3. 边界长度 — 有效长度的最小值和最大值
4. 特殊字符 — 输入中的句点、方括号、反斜杠
5. Unicode — 多字节字符、表情符号、变音符号
6. 灾难性回溯 — 会导致匹配时间呈指数增长的输入

阶段 5：输出

生成模式、解释、测试用例和用法示例。

输出格式

## Regex Pattern: {Brief Description}

### Requirements
- **Must match:** {description of valid inputs}
- **Must reject:** {description of invalid inputs}
- **Flavor:** {Python re | JavaScript | PCRE}

### Pattern
```regex
{pattern}

说明

组件	含义
{component}	{它匹配什么以及原因}

捕获组

组	名称	捕获内容	示例
1	{name}	{what}	{example value}

测试用例

#	输入	应匹配	原因
1	{input}	是	{why — happy path}
2	{input}	是	{why — boundary}
3	{input}	否	{why — invalid}
4	{input}	否	{why — near-miss}
5	``（空）	否	输入为空

边界情况

• {Edge case 1}：{what to watch for}
• {Edge case 2}：{what to watch for}

用法

Python：

import re

pattern = re.compile(r'{pattern}')

# Match entire string
if pattern.fullmatch(text):
    ...

# Search within string
match = pattern.search(text)
if match:
    captured = match.group(1)

# Find all matches
matches = pattern.findall(text)

JavaScript：

const pattern = /{pattern}/;

// Test
if (pattern.test(text)) { ... }

// Match
const match = text.match(pattern);
if (match) {
    const captured = match[1];
}

// Find all
const matches = [...text.matchAll(/{pattern}/g)];

## Calibration Rules

1. **Correctness over cleverness.** A readable, slightly longer pattern is better than
   a cryptic short one. `[A-Za-z0-9]` is clearer than `\w` when you specifically mean
   alphanumeric without underscores.
2. **Test negatives as rigorously as positives.** A pattern that matches everything
   technically matches all positive examples. Negative examples prevent over-matching.
3. **Anchor when appropriate.** `^\d{3}$` matches exactly 3 digits. `\d{3}` matches
   3 digits anywhere in the string. State the anchoring intent explicitly.
4. **Avoid catastrophic backtracking.** Nested quantifiers like `(a+)+` cause exponential
   time on non-matching input. Test with adversarial inputs.
5. **Named groups over numbered groups.** `(?P<year>\d{4})` (Python) or `(?<year>\d{4})`
   (JS) is self-documenting. Use numbered groups only for simple patterns.
6. **Specify the flavor.** Python `re`, JavaScript, and PCRE have different feature sets.
   Lookaheads, lookbehinds, and Unicode support vary.

## Error Handling

| Problem | Resolution |
|---------|------------|
| Insufficient examples | Ask for more. Minimum 3 positive, 3 negative. |
| Contradictory examples | Flag the contradiction. Ask which examples are correct. |
| Requirements too complex for regex | Suggest a parser instead. Regex cannot handle recursive structures (nested brackets, HTML). |
| Pattern causes backtracking | Rewrite with atomic groups or possessive quantifiers. Test with worst-case input. |
| Unicode requirements unclear | Ask if the pattern needs to handle non-ASCII. Default to ASCII unless specified. |
| Multiple valid patterns | Present the simplest one. Mention alternatives if they have meaningful tradeoffs (performance vs readability). |

## When NOT to Build Regex

Push back if:
- The input requires parsing a recursive grammar (HTML, JSON, nested expressions) — use a parser
- The validation is for a standard format with a library (email validation, URL parsing) — use the standard library
- The pattern is for security-critical input validation as the sole defense — regex is a first filter, not a security boundary
- The user wants to modify matched content in complex ways — regex replacement has limits; suggest code instead