条件规则解决什么
默认行为只能覆盖大多数情况，边缘情况让模型自由发挥就会飘。把边缘情况写成「如果……则……」的规则行，每条说清条件、动作与例外，行为就变得可预测、也可测试。规则行的关键细节是匹配顺序：是从上到下命中即停，还是全部评估后合并，必须在提示里写明，否则多条规则同时命中时结果不可控。
基本信息
| 适合任务 | 审核规则、数据清洗、路由分发等有明确分支的任务 |
|---|---|
| 写法 | 每条规则一行：条件 + 动作 + 例外说明 |
| 顺序声明 | 写明「命中即停」或「全部评估」 |
| 兜底分支 | 规则之外的情况归入「其他」并说明 |
| 规模上限 | 超过十几条就应迁移到规则引擎或代码 |
典型使用场景
- 金额与数值清洗：负数标为异常、缺失值保留空、不做猜测补全
- 工单字段规范化：备注含「加急」时提升优先级一档
- 内容审核：区分「讨论违规」与「实施违规」的处理动作
- 数据入仓前校验：日期缺失或格式错误时的降级路径
- 回复路由：根据问题类型分派到不同处理流程或人工队列
规则行写法
规则行写法
# 先声明匹配方式，再逐条列规则，最后给兜底
按以下规则处理，规则之外的情况归入“其他”并在理由中说明：
- 如果金额小于 0：标记为“异常”，不计入合计
- 如果日期缺失：保留空值，不要猜测
- 如果备注含“加急”：优先级提升一档
- 其他：按常规流程处理
# 顺序：写明命中即停，避免多条规则打架
匹配方式：从上到下匹配，命中即停；同一事项只应用一条规则。
# 例外：规则要能单独测试，一条规则对应一组正反用例
# 记录：命中的规则编号一并输出，便于复核与统计各分支使用率规则要素与常见缺陷
| 要素 | 写法要求 | 常见缺陷 |
|---|---|---|
| 条件 | 可判定的客观特征 | 用「严重」「较大」等模糊词 |
| 动作 | 明确的输出变化 | 只说要处理，不说怎么改 |
| 顺序 | 命中即停或全部评估 | 不声明，结果随表述顺序漂移 |
| 兜底 | 其他分支与说明 | 没有兜底，边缘输入被硬塞进某条规则 |
多条规则不声明匹配顺序时结果不稳定：同一输入在不同批次可能命中不同规则，评测分数也会抖动。
规则数量增长后应迁移到规则引擎或代码判断；提示词不适合承载几十条分支，维护与测试成本都会失控。