作者：Lingo　发布：　阅读时间：10 分钟

AI Coding 时代，还要背正则表达式吗？

把一句匹配需求交给 Coding Agent，它通常几秒就能给出一条正则表达式，还会顺手解释每个字符的含义。GitHub 也把“生成正则表达式”列为 Copilot 擅长的任务。GitHub Copilot 最佳实践

这似乎让背正则变成了一件过时的事。

我的判断是：完整的语法表不再值得背，但正则的匹配模型仍然要留在脑中。AI 降低了回忆语法的成本，没有替开发者承担误匹配进入生产环境后的责任。以前需要记住怎样写；现在更需要看出它究竟写了什么。

AI 接管了语法回忆

正则表达式很适合 AI 生成。它的输出短，语法边界明确，需求也常能写成“匹配什么、排除什么”。GitHub 的 Secret Scanning 已经把这个过程做成产品：用户用自然语言描述目标，也可以补充样例，系统会返回最多三条候选正则。GitHub Security and Quality AI Features

这个产品设计已经回答了一半问题。使用者可以不知道具体语法，仍然得到一条可用的表达式。断言的拼写、flag 的位置和反斜杠的转义层数，都没有必要继续占用长期记忆。

但 GitHub 没有让生成结果直接生效。候选表达式要经过 dry run，官方说明也提醒，有些结果无法覆盖所有预期实例。生成器负责提出候选，仓库里的真实文本负责暴露边界。

因此，AI Coding 淘汰的主要是闭卷默写。正则是否正确，仍然取决于开发者能否把自然语言里的含糊要求变成可执行条件。

正则真正困难的部分不在语法

假设一篇文章的 slug 要满足下面的规则：只允许小写字母、数字和连字符；连字符不能出现在开头或结尾，也不能连续出现。

如果只告诉 AI“写一条匹配 slug 的正则”，它很可能给出：

^[a-z0-9-]+$

这条表达式看起来合理，却会接受 -regex、regex- 和 ai--coding。问题不在于 AI 忘了某个冷门语法，而在于“slug”没有天然携带这三条产品规则。

更接近需求的写法是：

^[a-z0-9]+(?:-[a-z0-9]+)*$

它先要求一段至少一个字符的字母或数字，后面可以重复出现“一个连字符加一段字母或数字”。模式因此不会留下孤立的连字符。

真正定义这条正则的，其实是下面这组样本：

输入预期
ai-coding匹配
regex2匹配
-regex不匹配
regex-不匹配
ai--coding不匹配
AI Coding不匹配
空字符串不匹配

只给正例，AI 容易生成一个过宽的模式；只描述规则，需求里的边界又可能没有说完整。正例和反例放在一起以后，表达式才有了可以验证的契约。

ICSE 2024 发布的 Re(gEx|DoS)Eval 收集了 762 条来自真实用户的正则描述，并为它们补充测试集。研究者同时检查功能正确性和 ReDoS 风险。这个评测方式很有启发：一条正则不能因为“像答案”就算正确，它必须在应当接受和应当拒绝的输入上产生预期结果。

还需要记住什么

开发者不必把整张 cheat sheet 搬进脑中，但要能读懂一条候选表达式的控制结构。最低限度的知识可以分成两类：

应该形成直觉可以随用随查
^、$ 限定了哪里，当前是否开启多行模式冷门 flag 的准确拼写
字符类描述了哪些字符，是否遗漏 UnicodeUnicode 属性类的完整名称
*、+、?、{m,n} 作用于前面的哪个单元复杂 lookaround 的引擎限制
分组怎样改变重复范围，`` 的两侧到底是什么
贪婪匹配会吃到哪里，失败时是否会大量回溯语言字符串、JSON 或 Shell 中需要几层转义

MDN 的正则参考把 JavaScript 正则拆成 assertion、atom、group、backreference 和 quantifier。学习这些概念是为了建立阅读能力。看到 ^(a+)+$ 时，应该立刻注意到一个重复分组里又出现了重复；看到没有 ^ 和 $ 的校验表达式时，应该先确认代码想检查整段输入，还是只要找到一个子串。

这种知识和记住 API 参数不同。参数名忘了可以查文档；如果不知道量词只约束它前面的 atom，就无法判断 AI 的解释是否可信，也很难设计能推翻它的反例。

同一条正则在不同引擎里不是同一句话

正则表达式没有一个覆盖所有语言的统一运行时。JavaScript、Python、PCRE2 和 Go 使用相似符号，却支持不同能力，匹配语义和性能保证也不完全相同。

Python 标准库支持反向引用和 lookbehind，字符串字面量还会再处理一次反斜杠，因此官方文档建议在常见场景下使用 raw string。Python re 文档 JavaScript 又有自己的 Unicode 模式和 flag；MDN 当前列出的 u 与 v 会改变字符集合及 Unicode 的解释方式。

Go 的 regexp 使用 RE2 语法，官方保证匹配时间随输入长度线性增长。Go regexp 文档 这个保证伴随着功能取舍：RE2 不支持反向引用和 lookaround，因为这些结构通常需要回溯实现。RE2

所以，“帮我写一条正则”并不是完整提示。至少要说明目标语言和运行时版本。AI 如果在 JavaScript 项目里给出一条 PCRE2 表达式，即使逻辑意图正确，代码也可能无法编译；把 Python 里的模式直接复制进 Go，某些高级结构会在引擎入口就被拒绝。

引擎属于需求的一部分，不是生成完成以后再补的环境信息。

AI 会让危险的正则生成得更快

正则错误不只会多匹配几条数据。回溯型引擎遇到某些嵌套量词和重叠分支时，可能尝试大量路径。攻击者构造一段最终无法匹配的长输入，就可能让服务长时间占用 CPU，这类问题被称为 Regular Expression Denial of Service。

OWASP 使用下面的表达式解释这个风险：

^(a+)+$

输入由许多 a 组成时，内外两个 + 产生大量可能的分组方式。末尾再放一个不匹配字符，回溯引擎要在确认失败前检查许多路径。OWASP ReDoS

OWASP 的例子不意味着正则一定很慢。Go 的 RE2 路线用功能约束换取线性时间。风险是否存在，要看具体模式在哪一种引擎中运行，还要看外部用户能否控制输入。

ICPC 2024 的研究专门分析了 LLM 生成正则中的 ReDoS，发现生成结果中确实存在多项式复杂度的脆弱模式。Understanding ReDoS in LLM-Generated Regexes 这项研究使用的是当时的模型，不能直接代表 2026 年所有 Coding Agent；它证明的范围更窄：自然语言生成正则以后，安全性仍需要单独验证，功能样例通过并不等于面对长输入也安全。

有些需求本来就不该变成正则

正则擅长描述不依赖递归结构的文本模式。需求一旦要求理解嵌套语法或外部事实，继续增加分组只会把问题藏进一行更难审查的字符里。

日期可以用正则检查是否长得像 2026-08-11，但 2 月 29 日是否存在取决于年份。电子邮箱可以先检查基本形状，地址能否收信仍要靠验证流程。HTML、JSON 和 Markdown 的嵌套结构已经有成熟 parser，让 AI 拼出一条更长的正则，不会把它变成更合适的工具。

开发者需要保留的另一项能力，是知道何时停止写正则。AI 很擅长继续满足当前提示；如果提示已经选错抽象，它也可能沿着错误方向生成一条非常完整的答案。

一套更适合 AI Coding 的写法

让 AI 生成正则时，可以先交付一份很短的契约：

目标环境：Node.js 24，JavaScript RegExp
用途：校验整段文章 slug
应当匹配：ai-coding、regex2
不应匹配：-regex、regex-、ai--coding、AI Coding、空字符串
输入来源：公开 HTTP 请求，最长 80 个字符
输出要求：给出正则、逐段解释，并生成可运行的单元测试

然后运行这些测试，再补三类反例：边界位置、Unicode 与换行、接近长度上限但最终失败的输入。若模式处理公开输入，还要确认目标引擎的回溯行为，或者使用有明确复杂度保证的引擎。

GitHub 对 AI 生成代码的审查建议也是从自动化测试和静态分析开始，再核对代码是否符合项目意图。Review AI-generated code 对正则来说，审查不能停在那一行模式上。模式要放进目标引擎，用样本和真实调用方式检查行为。

2026 年的 Query4Regex 用 DFA 等价性检查模型对正则的转换是否保持语义。论文中，程序化 DSL 指令比自然语言指令的平均准确率最多高 6.74 个百分点。这个结果不能说明每条业务正则都该改用 DSL，却说明自然语言里的“删掉这部分”“只保留那一类”仍可能含糊。把意图写成测试，通常比继续润色提示更接近程序事实。

记忆的对象变了

AI Coding 时代仍然需要学正则，但学习目标已经变化。没有必要背完所有断言、flag 和转义组合。应该熟悉的是边界怎样收紧匹配，量词怎样扩大候选范围，分组如何改变作用域，以及引擎在失败时可能做什么。

过去，熟练意味着很快写出一条正则。现在，AI 可以把这部分速度压到几秒。更稀缺的能力变成了另一件事：先把需求写成可反驳的样本，再判断候选表达式有没有越过边界。

如果一条 AI 生成的正则无法被开发者解释，也没有反例测试，它就不是已经完成的代码，只是一条尚未验证的候选答案。

参考资料

AI Coding 时代，还要背正则表达式吗？｜MEDIA OS 限定了哪里，当前是否开启多行模式 | 冷门 flag 的准确拼写 |\n| 字符类描述了哪些字符，是否遗漏 Unicode | Unicode 属性类的完整名称 |\n| `*`、`+`、`?`、`{m,n}` 作用于前面的哪个单元 | 复杂 lookaround 的引擎限制 |\n| 分组怎样改变重复范围，`|` 的两侧到底是什么 | 命名捕获在不同语言中的写法 |\n| 贪婪匹配会吃到哪里，失败时是否会大量回溯 | 语言字符串、JSON 或 Shell 中需要几层转义 |\n\n[MDN 的正则参考](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions)把 JavaScript 正则拆成 assertion、atom、group、backreference 和 quantifier。学习这些概念是为了建立阅读能力。看到 `^(a+)+ AI Coding 时代，还要背正则表达式吗？｜MEDIA OS 时，应该立刻注意到一个重复分组里又出现了重复；看到没有 `^` 和 ` AI Coding 时代，还要背正则表达式吗？｜MEDIA OS 的校验表达式时，应该先确认代码想检查整段输入，还是只要找到一个子串。\n\n这种知识和记住 API 参数不同。参数名忘了可以查文档；如果不知道量词只约束它前面的 atom，就无法判断 AI 的解释是否可信，也很难设计能推翻它的反例。\n\n## 同一条正则在不同引擎里不是同一句话\n\n正则表达式没有一个覆盖所有语言的统一运行时。JavaScript、Python、PCRE2 和 Go 使用相似符号，却支持不同能力，匹配语义和性能保证也不完全相同。\n\nPython 标准库支持反向引用和 lookbehind，字符串字面量还会再处理一次反斜杠，因此官方文档建议在常见场景下使用 raw string。[Python `re` 文档](https://docs.python.org/3/library/re.html) JavaScript 又有自己的 Unicode 模式和 flag；MDN 当前列出的 `u` 与 `v` 会改变字符集合及 Unicode 的解释方式。\n\nGo 的 `regexp` 使用 RE2 语法，官方保证匹配时间随输入长度线性增长。[Go `regexp` 文档](https://pkg.go.dev/regexp) 这个保证伴随着功能取舍：RE2 不支持反向引用和 lookaround，因为这些结构通常需要回溯实现。[RE2](https://github.com/google/re2)\n\n所以，“帮我写一条正则”并不是完整提示。至少要说明目标语言和运行时版本。AI 如果在 JavaScript 项目里给出一条 PCRE2 表达式，即使逻辑意图正确，代码也可能无法编译；把 Python 里的模式直接复制进 Go，某些高级结构会在引擎入口就被拒绝。\n\n引擎属于需求的一部分，不是生成完成以后再补的环境信息。\n\n## AI 会让危险的正则生成得更快\n\n正则错误不只会多匹配几条数据。回溯型引擎遇到某些嵌套量词和重叠分支时，可能尝试大量路径。攻击者构造一段最终无法匹配的长输入，就可能让服务长时间占用 CPU，这类问题被称为 Regular Expression Denial of Service。\n\nOWASP 使用下面的表达式解释这个风险：\n\n```regex\n^(a+)+$\n```\n\n输入由许多 `a` 组成时，内外两个 `+` 产生大量可能的分组方式。末尾再放一个不匹配字符，回溯引擎要在确认失败前检查许多路径。[OWASP ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)\n\nOWASP 的例子不意味着正则一定很慢。Go 的 RE2 路线用功能约束换取线性时间。风险是否存在，要看具体模式在哪一种引擎中运行，还要看外部用户能否控制输入。\n\nICPC 2024 的研究专门分析了 LLM 生成正则中的 ReDoS，发现生成结果中确实存在多项式复杂度的脆弱模式。[Understanding ReDoS in LLM-Generated Regexes](https://doi.org/10.1145/3643916.3644424) 这项研究使用的是当时的模型，不能直接代表 2026 年所有 Coding Agent；它证明的范围更窄：自然语言生成正则以后，安全性仍需要单独验证，功能样例通过并不等于面对长输入也安全。\n\n## 有些需求本来就不该变成正则\n\n正则擅长描述不依赖递归结构的文本模式。需求一旦要求理解嵌套语法或外部事实，继续增加分组只会把问题藏进一行更难审查的字符里。\n\n日期可以用正则检查是否长得像 `2026-08-11`，但 2 月 29 日是否存在取决于年份。电子邮箱可以先检查基本形状，地址能否收信仍要靠验证流程。HTML、JSON 和 Markdown 的嵌套结构已经有成熟 parser，让 AI 拼出一条更长的正则，不会把它变成更合适的工具。\n\n开发者需要保留的另一项能力，是知道何时停止写正则。AI 很擅长继续满足当前提示；如果提示已经选错抽象，它也可能沿着错误方向生成一条非常完整的答案。\n\n## 一套更适合 AI Coding 的写法\n\n让 AI 生成正则时，可以先交付一份很短的契约：\n\n```text\n目标环境：Node.js 24，JavaScript RegExp\n用途：校验整段文章 slug\n应当匹配：ai-coding、regex2\n不应匹配：-regex、regex-、ai--coding、AI Coding、空字符串\n输入来源：公开 HTTP 请求，最长 80 个字符\n输出要求：给出正则、逐段解释，并生成可运行的单元测试\n```\n\n然后运行这些测试，再补三类反例：边界位置、Unicode 与换行、接近长度上限但最终失败的输入。若模式处理公开输入，还要确认目标引擎的回溯行为，或者使用有明确复杂度保证的引擎。\n\nGitHub 对 AI 生成代码的审查建议也是从自动化测试和静态分析开始，再核对代码是否符合项目意图。[Review AI-generated code](https://docs.github.com/en/copilot/tutorials/review-ai-generated-code) 对正则来说，审查不能停在那一行模式上。模式要放进目标引擎，用样本和真实调用方式检查行为。\n\n2026 年的 [Query4Regex](https://aclanthology.org/2026.findings-eacl.331/) 用 DFA 等价性检查模型对正则的转换是否保持语义。论文中，程序化 DSL 指令比自然语言指令的平均准确率最多高 6.74 个百分点。这个结果不能说明每条业务正则都该改用 DSL，却说明自然语言里的“删掉这部分”“只保留那一类”仍可能含糊。把意图写成测试，通常比继续润色提示更接近程序事实。\n\n## 记忆的对象变了\n\nAI Coding 时代仍然需要学正则，但学习目标已经变化。没有必要背完所有断言、flag 和转义组合。应该熟悉的是边界怎样收紧匹配，量词怎样扩大候选范围，分组如何改变作用域，以及引擎在失败时可能做什么。\n\n过去，熟练意味着很快写出一条正则。现在，AI 可以把这部分速度压到几秒。更稀缺的能力变成了另一件事：先把需求写成可反驳的样本，再判断候选表达式有没有越过边界。\n\n如果一条 AI 生成的正则无法被开发者解释，也没有反例测试，它就不是已经完成的代码，只是一条尚未验证的候选答案。\n\n## 参考资料\n\n- [GitHub Copilot：Best practices](https://docs.github.com/en/copilot/get-started/best-practices)\n- [GitHub：Security and Quality AI Features](https://docs.github.com/en/code-security/responsible-use/security-and-quality-ai-features)\n- [MDN：Regular expressions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions)\n- [Python 3：`re` — Regular expression operations](https://docs.python.org/3/library/re.html)\n- [Go：`regexp` package](https://pkg.go.dev/regexp)\n- [Google RE2](https://github.com/google/re2)\n- [OWASP：Regular expression Denial of Service](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)\n- [Re(gEx|DoS)Eval，ICSE 2024](https://conf.researchr.org/details/icse-2024/icse-2024-artifact-evaluation/68/Re-gEx-DoS-Eval-Evaluating-Generated-Regular-Expressions-and-their-Proneness-to-DoS-)\n- [Understanding Regular Expression Denial of Service，ICPC 2024](https://doi.org/10.1145/3643916.3644424)\n- [Query4Regex，EACL 2026](https://aclanthology.org/2026.findings-eacl.331/)\n","date":"2026-08-11","readTime":"10 分钟","tags":["AI Coding","正则表达式","代码审查","程序员基础"],"category":"tech","views":0,"likes":0,"comments":0,"author":"Lingo","updated_at":"2026-08-11T13:22:05.000Z","isPasswordProtected":false}