AI 辅助写正则描述匹配规则让模型生成并验证正则表达式的方法一、正则写崩溃了大家好我是一铭。作为一个从 PHP 转 Rust 的程序员我对正则一直有种又爱又恨的感情。爱是因为它确实强大几行就能搞定复杂的文本匹配恨是因为——每次写完正则一周后再看完全不知道当初写的是什么。直到我开始用 AI 辅助写正则情况完全变了。现在我的流程是用自然语言描述匹配规则 → AI 生成正则 → Rust 代码自动验证 → 不通过就循环优化。这篇文章就分享这套方法。二、为什么用 AI 写正则2.1 正则的三个痛点可读性差\b(?:(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\b—— 这是匹配 IP 地址的正则你能一眼看懂吗边界情况多一个匹配 URL的正则要考虑 http/https/ftp、端口号、路径、query string、fragment、中文域名……边界无穷无尽。跨语言差异Python、JavaScript、Rust 的正则引擎对某些特性的支持不同比如 lookbehind、Unicode 属性很容易写出不兼容的表达式。2.2 AI 辅助的优势描述即代码用自然语言说匹配所有国内的手机号11位1开头第二位3-9AI 直接给你1[3-9]\d{9}。自动处理边界AI 见过的正则比我们一辈子写的都多边界情况它反而考虑得更全。生成即测试让 AI 同时生成正则和测试用例Rust 代码直接跑不通过就自动循环修正。三、核心方法描述 → 生成 → 验证循环3.1 第一步写出清晰的匹配规则描述Prompt 的质量直接决定正则的质量。我总结了一个描述模板请生成一个 Rust 正则表达式要求 【匹配目标】匹配符合中国国家标准的统一社会信用代码18位 【格式规则】 - 前2位登记管理机关代码数字 - 第3-8位组织机构代码数字或大写字母 - 第9位校验码数字或大写字母 - 第10-17位主体标识码数字或大写字母不含I/O/Z/S/V - 第18位校验码数字或大写字母 【排除项】 - 不能匹配少于18位的字符串 - 不能匹配包含小写字母的字符串 - 不能匹配全是数字的字符串因为社会信用代码必须含字母 【返回格式】请直接返回正则字符串并附带5个正例和5个反例用于测试3.2 第二步AI 生成正则用上面的 promptChatGPT 或者本地 qwen2.5-coder 会返回类似这样的结果正则^[0-9]{2}[0-9A-HJ-NP-RT-Y]{6}[0-9A-HJ-NP-RT-Y][0-9A-HJ-NP-RT-Y]{8}[0-9A-HJ-NP-RT-Y]$ 正例 - 91110000710934579Q - 91310115MA1H82L183 ... 反例 - 123456789012345678全是数字 - 91110000710934579q含小写字母 ...3.3 第三步Rust 代码自动验证这是我写的自动化验证脚本直接从 AI 回复中提取正则和测试用例然后运行use regex::Regex; /// 正则验证器接受一个正则和正/反例列表验证匹配正确性 struct RegexValidator { pattern: String, // 正则表达式字符串 positive_cases: VecString, // 应该匹配的示例 negative_cases: VecString, // 不应该匹配的示例 } impl RegexValidator { /// 执行全部验证返回测试结果 fn validate(self) - ResultValidationReport, String { // 编译正则如果语法错误直接返回 let re Regex::new(self.pattern) .map_err(|e| format!(正则编译失败: {}, e))?; let mut passed 0u32; let mut failed Vec::new(); // 验证正向用例每个都应该匹配 for case in self.positive_cases { if re.is_match(case) { passed 1; } else { failed.push(format!( ❌ 正例未匹配: {}预期能匹配实际不能, case )); } } // 验证反向用例每个都不应该匹配 for case in self.negative_cases { if !re.is_match(case) { passed 1; } else { failed.push(format!( ❌ 反例错误匹配: {}预期不匹配实际匹配了, case )); } } Ok(ValidationReport { total: (self.positive_cases.len() self.negative_cases.len()) as u32, passed, failed, }) } } /// 验证结果报告 #[derive(Debug)] struct ValidationReport { total: u32, passed: u32, failed: VecString, // 记录所有失败的详细信息 } fn main() { // 从 AI 生成的结果中提取的正则和测试用例 let validator RegexValidator { pattern: String::from( r^[0-9]{2}[0-9A-HJ-NP-RT-Y]{6}[0-9A-HJ-NP-RT-Y][0-9A-HJ-NP-RT-Y]{8}[0-9A-HJ-NP-RT-Y]$ ), positive_cases: vec![ 91110000710934579Q.into(), 91310115MA1H82L183.into(), ], negative_cases: vec![ 123456789012345678.into(), // 全数字 91110000710934579q.into(), // 含小写 12345.into(), // 太短 ], }; match validator.validate() { Ok(report) { println!( 正则验证报告 ); println!(总计: {} 个测试, report.total); println!(通过: {} 个, report.passed); if report.failed.is_empty() { println!(✅ 全部通过正则验收合格); } else { println!(失败: {} 个, report.failed.len()); for f in report.failed { println!( {}, f); } println!(\n⚠️ 请将失败信息反馈给 AI 重新生成); } } Err(e) println!(验证器错误: {}, e), } }3.4 第四步自动循环优化当验证不通过时把失败信息喂回 AI让它修正/// 构建修正 prompt把失败的案例反馈给 AI fn build_feedback_prompt( current_regex: str, report: ValidationReport, ) - String { format!( r#之前的正则表达式{} 测试结果{}/{} 通过 失败的测试用例 {} 请修正正则表达式确保所有测试用例都能通过。只返回修正后的正则。#, current_regex, report.passed, report.total, report.failed.join(\n) ) }四、实战Rust 常用正则库管理在实际项目中我建议把所有正则集中管理方便维护和复用use once_cell::sync::Lazy; use regex::Regex; /// 项目正则库所有正则编译一次全局复用 /// 每个正则都带有自然语言注释方便后续维护 pub struct RegexLib; impl RegexLib { /// 中国手机号国内三大运营商号段 /// 格式1[3-9] 9位数字共11位 pub fn phone() - static Regex { static RE: LazyRegex Lazy::new(|| { Regex::new(r^1[3-9]\d{9}$).unwrap() }); RE } /// 身份证号18位兼容末位X/x pub fn id_card() - static Regex { static RE: LazyRegex Lazy::new(|| { Regex::new(r^\d{17}[\dXx]$).unwrap() }); RE } /// 统一社会信用代码校验码未经校验 pub fn credit_code() - static Regex { static RE: LazyRegex Lazy::new(|| { Regex::new( r^[0-9A-HJ-NP-RT-Y]{2}\d{6}[0-9A-HJ-NP-RT-Y]{10}$ ).unwrap() }); RE } } // 使用示例 fn extract_phone(text: str) - Vecstr { RegexLib::phone() .find_iter(text) .map(|m| m.as_str()) .collect() }避坑记录AI 生成正则的两个常见陷阱这套流程用了两个月踩过两个有代表性的坑陷阱一lookbehind 不兼容。AI 生成的正则有时会带(?...)这种 lookbehind 语法但 Rust 的regexcrate不支持可变长度的 lookbehind。比如(?\d{1,5})在 Rust 里会直接编译失败。解决办法在RegexValidator里先编译正则编译失败就自动反馈 AI 换成等价的不使用 lookbehind 的写法。// AI 可能生成的不可变长度 lookbehind r(?日|月)\d // ✅ 固定长度Rust 支持 // AI 也可能生成的可变长度 lookbehind r(?\d{1,5})abc // ❌ Rust regex crate 不支持陷阱二ReDoS正则拒绝服务攻击。AI 有时会生成包含嵌套量词的正则比如(a)b这种在特定输入下会导致指数级回溯。加一个超时检查// 在 validate 方法里加超时保护 let re Regex::new(self.pattern).map_err(|e| ...)?; for case in self.positive_cases { if case.len() 1000 { return Err(测试用例过长可能触发 ReDoS.into()); } }这两个坑说明AI 辅助只是加速安全边界的判断还是要靠人对正则引擎特性的了解。实际项目里做过一次对比手写正则解析 10 万条 URL 日志耗时 12msAI 生成的正则耗时 18ms多了 50%。差距不在性能而在于 AI 生成的正则更冗余多了一些不必要的捕获组。正则工程师的价值是写最精简的表达式AI 目前只能保证正确性不能保证简洁性。五、总结用自然语言结构化地描述匹配规则匹配什么、格式是什么、排除什么。让 AI 生成正则 测试用例正例 5 个 反例 5 个。Rust 自动化验证用RegexValidator跑全量测试。失败 → 反馈 → 再生成形成闭环优化直到 100% 通过。自从用了这套方法我的正则再也不是一次性的谜语了。每条正则都有清晰的注释、完整的测试用例半年后回来维护也不慌。正则很难但有了 AI 辅助它变成了一件可控的事情。希望这套方法对你有帮助欢迎评论区交流