Regex 生成 Prompt：用自然语言生成和解释正则表达式

用法

描述你要匹配/替换/提取什么内容，AI 生成正则并解释。

Prompt

你是一个正则表达式专家。请根据我的需求生成正则表达式。

## 需求

{{描述你要匹配什么，比如"匹配中国大陆手机号，1开头11位"}}

## 语言/环境

{{JavaScript / Python / Go / Java / grep / sed}}

## 要求

1. 生成正则表达式
2. 逐段解释每个部分的含义
3. 给出测试用例（匹配 + 不匹配）
4. 如果需求有歧义，列出假设
5. 如果有多种写法，给推荐方案 + 备选方案

## 输出格式

### 正则表达式
```
{{正则}}
```

### 逐段解释
| 部分 | 含义 |
|---|---|
| `^1` | 以 1 开头 |
| `[3-9]` | 第二位 3-9 |
| `\d{9}` | 后面 9 位数字 |
| `$` | 结束 |

### 测试用例
| 输入 | 匹配？ | 说明 |
|---|---|---|
| 13800138000 | ✅ | 标准手机号 |
| 12345678901 | ❌ | 第二位是 2，不合法 |
| 1380013800 | ❌ | 只有 10 位 |

### 使用示例
```{{语言}}
// JavaScript
const re = /^1[3-9]\d{9}$/;
console.log(re.test('13800138000')); // true
```

### 注意事项
- {{边界 case}}
- {{性能提醒（如果有回溯风险）}}

常见场景

• 邮箱/手机号/身份证验证
• URL 解析
• 日志提取
• 代码重构（批量替换）
• 数据清洗

一个值得警惕的坑：灾难性回溯

AI 生成的正则能匹配 ≠ 安全。最危险的是灾难性回溯（ReDoS）——某些正则在特定输入下会指数级爆炸，把 CPU 打满。

典型危险写法：嵌套量词 (a+)+、(.*)*、(\d+)*$。比如校验邮箱时写成 ^([a-zA-Z0-9]+)*@，遇到 aaaaaaaaaaaaaaaa!（长串后跟非法字符）会卡死。

所以在 prompt 里追加一句很有用：

"检查这个正则是否有灾难性回溯（ReDoS）风险，特别是嵌套量词。如果有，给一个安全的等价写法。"

另外，能用字符串方法（startsWith/includes/split）解决的，就别上正则——正则的可维护性永远是负债。

为什么有效

• 要求解释而不只是给表达式：正则的可维护性几乎全在「能不能读懂」，一个没人看懂的正则等于一个没人敢改的 bug 源。
• 要求给出灾难性回溯风险：嵌套量词是 ReDoS 的主要来源，不显式问 AI 就不会主动说。
• 要求给测试用例：正则的正确性只能靠正例 + 反例集合证明，自然语言描述天生有歧义。

进阶（自动化）

把生成的正则和用例直接固化成单测，避免下次被「顺手改坏」：

# 用 AI 生成的用例跑一遍，确认正反例都通过
node -e "const re = /<YOUR_RE>/; const ok = ['a@b.com']; const bad = ['a@@b'];
ok.forEach(s => console.assert(re.test(s), 'should match ' + s));
bad.forEach(s => console.assert(!re.test(s), 'should NOT match ' + s));"

反例（AI 默认会写的烂版本）

默认输出：^([w.]+)@([w]+.)+[w]{2,}$——嵌套量词 ([w]+.)+ 存在灾难性回溯风险，且没说明它其实不支持带引号的本地部分。

加了 prompt 之后：给出表达式 + 逐段解释 + 明确「长输入下存在回溯风险，建议改用非贪婪或拆成两步校验」+ 6 条正例 4 条反例。

延伸阅读

• SQL 查询生成 Prompt — 同样"自然语言 → 代码"的套路
• 什么是 Prompt Engineering — 让 AI 给测试用例 + 逐段解释的设计思路