上海支付组周五上线前，我用提示词验收订单正则

先把上海支付组的订单规则写成可验收的需求

周五上线前，最危险的正则往往不是完全匹配不了，而是悄悄放过了错误数据。给模型提问前，先把任务写成一份小规格：输入是什么，允许哪些字符，长度是多少，是否必须从字符串开头匹配，是否允许换行，是否要提取订单号，以及使用 JavaScript、Python、PCRE 还是其他语法。

例如，需求可以写成：订单号由两位大写字母、连字符和六位数字组成；整个字符串必须完全匹配；不接受前后空格；请给出 JavaScript 版本，并说明是否需要标志位。这样的描述比“帮我写一个订单号正则”更容易得到可检查的结果。

第一步：让模型先复述约束再生成表达式

• 1. 把业务规则、目标语言、输入来源和输出格式放在同一段提示词中。
• 2. 要求模型先列出它理解的约束，再给出正则表达式。
• 3. 要求逐段解释字符类、量词、边界和捕获组的作用。
• 4. 明确要求列出至少三个应匹配和三个不应匹配的样例。

可以加入一句：“如果需求存在歧义，先指出歧义并提出选择，不要自行补全。”这一步能阻止模型把“最多 20 个字符”误写成“恰好 20 个字符”，也能提前发现 Unicode、大小写和空白处理上的分歧。

第二步：把候选正则拆成可以逐项核对的部分

拿到结果后，先不要复制到生产代码。逐项查看是否有起始和结束边界，量词是否对应需求，字符类是否过宽，括号是否只是分组还是会产生捕获，转义是否符合目标语言。订单号示例的候选表达式可以是 ^[A-Z]{2}-[0-9]{6}$。

检查时要特别留意模型的解释是否与表达式一致。它如果说“数字可以是任意 Unicode 数字”，但表达式只写了 [0-9]，说明说明文字或实现至少有一处不准确。正则表达式、编程语言字符串转义和模型展示格式也可能各自再处理一次反斜杠，复制前应确认最终传给正则引擎的文本。

第三步：用正反样例覆盖边界而不是只看一个成功案例

• 1. 正常样例：AB-123456、ZX-000001。
• 2. 长度边界：一位字母、三位字母、五位数字和七位数字。
• 3. 字符边界：小写字母、中文、制表符、换行和全角数字。
• 4. 位置边界：前后多一个空格，或在更长字符串中嵌入合法片段。
• 5. 结构边界：缺少连字符、出现第二个连字符，或把字母放到数字区域。

把这些样例直接放回提示词，让模型逐行预测匹配结果，并要求说明每一行为什么通过或失败。预测结果只是第二份意见，不能替代实际执行；但它很适合暴露“表达式写的是完整匹配，解释却按包含匹配理解”这类问题。

第四步：在目标运行环境中执行同一批测试

把正则和样例放进项目实际使用的语言与库中。测试至少包含一个正常值、一个最短边界、一个最长边界、一个前后带空格的值和一个包含换行的值。对验证器来说，断言完整输入通过或失败，比只打印搜索结果更可靠。

如果程序使用 JavaScript，确认开发者写的是正则字面量还是字符串；如果使用 Python，确认原始字符串和反斜杠的处理。还要检查大小写标志、全局标志和多行标志，因为标志位可能改变边界或搜索行为。模型没有运行环境时，不能把它声称“已测试”的结果当成证据。

第五步：用故意刁钻的反例逼出隐藏漏洞

让模型扮演代码审查者，提示它寻找绕过方式：“请假设这条正则用于支付入口，重点检查空白、换行、Unicode、超长输入、前缀后缀和回溯风险。”随后把审查意见与真实测试结果对照。对于用户可控且长度不受限的输入，还应设置长度上限，并观察复杂表达式是否可能产生严重回溯。

修复时要求模型只修改必要部分，同时重新输出完整表达式、差异原因和全部测试表。这样能避免一次修复破坏另一条已通过的规则。

第六步：在提交代码前保存提示词和验收样例

把最终正则、目标引擎、标志位、正反样例和已知限制放在测试文件或技术说明中。未来需求改变时，先修改样例和约束，再让模型生成候选版本。若团队经常使用模型生成代码，可以通过 RelayVano 按量调用 Claude Sonnet 5.5 或 GPT-6 Astra，并把 API 接到现有的 OpenAI 兼容 SDK；这样同一套提示词和测试流程更容易复用。需要低门槛开始时，可以到 RelayVano 注册账号。