用AI写高难度正则表达式与数据结构算法：解题思路与边界测试实战

正则写不对、算法题卡在边界用例上，很多人第一反应是丢给 AI，结果拿到一段跑得过样例、一到线上就崩的代码。问题通常不在模型，而在你没说清输入范围、没定义什么叫对、也没让它把边界列出来。这篇给的是提问方式和验证顺序：先定规格再要代码，先跑反例再改，最后按清单把边界一个个试过去。

正则写不对、算法题卡在边界用例上，很多人第一反应是把题目丢给 AI，结果拿到一段跑得过样例、换个输入就崩的代码。问题通常不在模型，而在你没说清输入范围、没定义什么叫对、也没让它把边界列出来。

这篇给的是提问方式和验证顺序：先定规格再要代码，先跑反例再改，最后按清单把边界一个个试过去。至于单测框架怎么搭、用例怎么组织，那是另一条线的事，这里只讲正则和算法题本身的问法与验法。

先写规格，再让 AI 写代码

规格没定就别急着要代码。你只丢一句「实现一个栈」，模型只能猜：是支持泛型还是固定类型，pop 空栈是抛异常还是返回空，要不要线程安全。猜错一次你就要来回改一轮，改到第三版你自己也说不清哪版对。

• 把输入域说全：允许哪些字符、长度上下限、空值和 null 算不算合法、要不要兼容全角
• 把「对」的定义写出来：匹配到什么算命中、不匹配要不要报错、返回布尔还是捕获组
• 数据结构题先说清操作序列与规模量级，要支持哪些操作、单次调用允许多慢
• 把不打算支持的情况提前声明，比如「不用考虑并发」「不用管超长输入」，省掉一半扯皮

正则怎么问：给它样例，别给它形容词

「帮我写个匹配邮箱的正则」这种问法基本没有信息量。模型不知道你要的是宽松校验还是严格按某份标准，只能各取一半，最后给你一个既漏又误报的中间态。改用样例驱动，结果会稳定很多。

1. 先给正反例正例标明「必须匹配」，反例标明「绝对不匹配」，各写几条，覆盖你真实见过的脏数据
2. 再说引擎与方言明确跑在哪种语言和哪个版本环境里，不同引擎对贪婪、回溯、Unicode 属性的处理不一样，别只写「写个正则」
3. 要求逐段解释让它把每个字符类的含义拆开讲，你只保留自己能读懂的写法，读不懂的部分等于埋雷
4. 问可读替代方案能拆成两步校验（先粗筛再精判）就别硬堆一个长正则，两步的维护成本通常更低

拿到正则之后别急着上生产。先拿你给的反例跑一遍，全都没命中才算起步；再去站内的模型资料库把这类表达式的常见坑点对一遍，确认不是你忘了某个字符类的边界行为。具体数字和版本差异到 /models 里看当时的说明。

边界测试清单：拿到代码先跑这几类

AI 给的代码最常见的失败方式不是逻辑全错，而是只覆盖了「正常输入」这一条路径。所以别先跑正例，先跑反例和极端值，通过了才说明它没你想的那么脆。

更省事的做法是直接让 AI 自己列：「这段代码在什么输入下会出错」。它列出来的清单往往比你临时想得全，你拿这份清单去实测，命中一条就说明确实有问题，比漫无目的地试快得多。

• 先跑明确不该通过的反例，通过了才叫有问题
• 再看正例是否全部命中，避免修反例时把正例改坏
• 把每条命中的问题记下输入与输出，方便下一轮对比
• 别只看代码是否更短更优雅，短不等于对

验证与改写：怎么判断改完是真好了

改完一版之后，最危险的动作是「看起来对就收工」。要有个固定的回归集合，把之前踩过的反例都放进去，每次改完重跑一遍，防止修一个坏一个。

对比两版差异时要具体到输入和输出，而不是「这版更简洁」。如果对方说做了性能优化，先问清输入规模是多少、复杂度从哪里降到哪里，再决定要不要采纳；规模本身说不清的场景，优化往往只是换了个写法。

回归集合

把历史反例固定成一组用例，改完必跑

差异对比

按输入与输出逐条对，不看主观评价

复杂度前提

任何优化都要先说明输入规模与量级

术语对齐

拿不准的写法去站内词典确认含义，避免各说各话

哪些情况别指望 AI 直接给答案

有几类任务，AI 产出只能当草稿，最终判断必须回到原文或你自己手上。搞清楚这条边界，比学会多少提问技巧都重要。

• 规则来自内部文档或行业标准原文时，模型记的可能是旧版或错的，以原文为准
• 正则用于安全校验（白名单、路径、SQL）时，AI 产出只是草稿，必须逐条对照威胁场景
• 竞赛类题目要的是最优解与证明，能过样例不等于正确，验收标准不能只看跑通
• 输入域说不清、样例凑不齐的任务，先把规格补完再回来问，否则来回改更慢

反过来，如果你要的是快速搭出可读的骨架、帮你列边界清单、或者把一段晦涩的正则翻译成人话，这类任务交给 AI 是划算的。分界线就是：能验证的交给它，不能验证的自己兜底。

样例能过只是起点，反例过不了才是你真正要解决的问题。