一小时磨一条正则的日子结束了——我算了笔AI写正则的时间账

写正则到底浪费了多少时间

先说我自己的账。去年我给一个日志清洗脚本写正则，需求很简单：从 nginx 日志里抽取时间戳、请求路径和状态码。听起来十分钟的事，实际磨了一个多小时。

时间花在哪了？不是写，是验证。写出来的正则，日志标准格式能匹配，但日志里混着一条带引号转义的 URL、一条状态码后面多了个空格的脏数据，正则就翻车。我得一条条试、一段段改，改完还要回头确认没把之前能匹配的搞坏。边界条件，才是正则真正吃时间的地方。

后来我在团队里做了个小统计（就我们几个人，样本不大但趋势很明显）：一条中等复杂度的正则，手写加边界验证，平均 45 分钟；其中纯写大概 10 分钟，剩下 35 分钟全耗在试错上。而我们这种小团队，一个月正经要写的正则少说十几条：输入校验、日志抽取、文本替换、路由匹配。粗算下来，一个月光正则就是十来个小时——一个多工作日，就这么没了。

更糟的是隐性成本。赶时间上线的正则，边界没验干净，三个月后线上炸一次，排查又是两小时。这笔账没进统计，但比显性成本更疼。

换个思路：让AI写，但验证不能省

我现在的流程是：AI负责生成，验证边界这件事交给AI搭的测试集，但结论我自己确认。

具体分四步：

第一步，把需求说清楚。不是甩一句“帮我写个匹配手机号的正则”，而是把格式规则、边界情况、用什么语言的正则引擎，都写进提示词。这一步多花两分钟，后面省二十分钟。

第二步，让AI输出正则加解释。要求它逐段拆解含义，这样我能快速判断方向对不对，而不是拿到一串天书盲测。

第三步，让AI自己生成边界用例。这是关键。我要求它同时给出“应该匹配”和“不应该匹配”的测试样例，覆盖极端情况：空字符串、超长输入、特殊字符、大小写、多行。

第四步，跑一遍测试集。我会自己再补几条业务里的真实脏数据进去，确认全部通过才用。AI会犯错，但AI犯的错比我手写的错好发现得多——因为测试集就在眼前。

直接可用的提示词模板

这是我沉淀下来的模板，改掉占位符就能用：

你是一位正则表达式专家。请帮我完成以下任务：

【需求描述】
{{用一句话说清楚要匹配什么，例如：从日志行中提取日期、级别、消息三部分}}

【目标引擎】
{{PCRE / JavaScript / Python re / Go regexp 等，不同引擎语法有差异}}

【格式规则】
1. {{例如：日期格式为 YYYY-MM-DD}}
2. {{例如：级别只能是 INFO/WARN/ERROR}}
3. {{补充所有你已知的规则}}

【已知边界情况】
- {{应匹配：...}}
- {{不应匹配：...}}
- {{不确定但可能出现的脏数据：...}}

【输出要求】
1. 给出正则表达式，并逐段解释含义
2. 给出至少 8 条测试用例：5 条应匹配（含边界值）、3 条不应匹配（含易混淆格式）
3. 指出这个正则的已知局限（例如不支持的情况）

先解释思路，再给正则，最后给测试用例。

第四条输出要求是我加的。让AI主动交代局限，能提前发现“哦原来这个不支持多行匹配”，省得上线后才发现。

前后对比：一笔具体的时间账

用这套流程之后，我重新记了一个月的账（还是我们这几个人）：

单条正则的耗时从45分钟压到13分钟左右，一个月省下约8小时。更重要的是线上事故归零了——过去一年因为正则边界问题出过三次故障，今年改成这个流程后一次没有。因为“验证边界”从可有可无的良心活，变成了流程里固定的、低成本的一步。

还有个意外收获：AI生成的测试用例被我们留下来了。每条正则现在都配着自己的用例文件，谁改了正则跑一遍就知道有没有改坏。祖传正则“没人敢动”的问题，顺带解决了一半。

几个提醒

• 引擎一定要写明。JavaScript 和 Python 的正则语法差异不小，不说清楚AI会给你一份跑不起来的答案。
• 脏数据自己补。AI能想到常见边界，但你业务里的怪数据（比如某个老系统会输出全角冒号）只有你知道。
• 别跳过第四步。AI生成的正则初看很顺眼，直接复制粘贴是事故的主要来源。跑测试集的两三分钟，是整条流程里性价比最高的投入。

写在最后

正则是个很典型的场景：写它不难，验它才贵。AI把这中间最耗时的试错环节压缩了一个数量级，让“认真验证边界”从奢侈品变成了默认动作。对小团队来说，每个月省下的八小时，够多写一个功能了。

如果你想找一个稳定、不用自己一个个申请API Key的模型调用入口来跑这类任务，可以看看这个统一网关：https://api.thistoken.ai/register，多个模型一个入口切换，价格以官网价格页为准。

---

想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。