必须放参考样例，且要成对出现：真实输入→匹配/不匹配结果；覆盖边界情况（如前后空格）；数量2～4组；绑定解释目标（如限定分析?=或验证分组逻辑），避免Claude套用模板库导致偏离实际用法。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Claude准确解释一段正则表达式，但不确定提示词里该不该加入输入输出样例——不加可能让它泛泛而谈，加了又怕干扰它对语法结构的底层分析。
必须放参考样例，且要成对出现
第一步：在提示词中明确给出至少一组真实、可验证的输入→对应匹配/不匹配结果。例如：“待解释正则：^\d{3}-\d{2}-\d{4}$；样例输入：'123-45-6789' → 匹配成功；'12-34-5678' → 不匹配”。
第二步：样例必须覆盖边界情况。只给正确格式的样例，Claude会默认该正则只处理合法输入，忽略锚点^$的作用、空格容错、Unicode字符等细节。补一个' 123-45-6789 '（开头有空格）→ 不匹配，它才会重点解释^如何阻止部分匹配。
第三步：样例数量控制在2～4组。超过4组容易让模型陷入逐条复述，而非提炼共性规律；少于2组则无法支撑它判断贪婪/非贪婪、分组捕获意图等深层逻辑。
样例不能孤立存在，必须绑定解释目标
方法一：用冒号直接限定解释焦点。写成“请解释以下正则中(?=...)的作用，并用所给样例说明其触发条件：正则：^(?=.*[a-z])(?=.*[A-Z]).{8,}$；样例：'Abc12345'→匹配，'abc12345'→不匹配”。
方法二：要求先验证再解释。提示词中写：“第一步：用样例验证该正则是否真能区分大小写；第二步：逐部分说明(?:\d{3}|\(\d{3}\))为何能兼容两种区号格式”。这强制Claude把样例当作校验工具，而非装饰性附件。
复杂任务工程化执行框架 — Sprint Contract 协商、三代理角色切换、对抗性评估、任务分解与上下文管理。3+ 文件修改或多模块设计时自动触发，防止复杂任务中的上下文污染和自我评估偏差。
【关键陷阱】只给正则不给样例时，Claude可能基于内置模板库直接套用“邮箱”“手机号”等高频场景的解释框架，导致对冷门模式（如日志行时间戳提取）的解析完全偏离实际用法。
样例质量比数量更重要
提供带注释的错误样例最有效。例如在解释.*?时，给出“'starttextend' → 捕获'a>text'（错误），'starttextend' → 捕获'a>text'（正确）”，Claude会立刻聚焦到?的非贪婪机制，而不是罗列所有量词定义。
避免使用含糊描述代替具体字符串。不要写“类似邮箱的格式”，要写“test+tag@domain.co.uk → 应匹配整个字符串，test@domain → 也匹配，test@ → 不匹配”。
这一步操作起来很简单，直接把三组明确定义的字符串粘贴进提示词就行。
