| name | corner-case-management |
| tier | meta |
| description | 识别、登记、处理那些不符合主工作流的边缘案例。**在经过若干轮 skill/workflow 迭代之后**——确实出现了适应不了的文档、且把它塞进主流程的代价不划算——才使用本 skill。涵盖：什么算边缘案例（vs 系统性问题），如何登记，如何用"检测 + 解决"机制把边缘案例留在冷路径上、只有当类似文档再次出现时才取出来用，以及何时把边缘案例提升为常规规则。 |
边缘案例管理
好的工作流处理绝大多数文档。边缘案例是剩下那一小撮 —— 单独看出现率低，累积起来又不能忽略。关键认知：不要为了边缘案例给主工作流打补丁。补丁导致逻辑混乱、代码脆弱、回归风险。
正确做法：把边缘案例从主流程中分离出来，单独管理。
什么时候才用这个 skill
边缘案例是在测试迭代之后识别的，不是在初次设计阶段。典型路径：
- 你为某条规则建好了 skill / workflow。
- 在样本集上跑过一遍。大多数通过，少数失败。
- 你迭代 —— 改代码、改 prompt、跑回测。
- 跑了若干轮之后，仍有少数 case 死活不合 —— 要么是：
- 当前工作流抓不住它们；让工作流去适应它们的代价又太大（破坏无关 case、徒增复杂度、需要架构重构）。
- 这些 case 在反复"摇摆"—— 这一轮改对了，下一轮又坏，振荡持续。
这时候才使用本 skill。**第一轮就遇上不合的 case 不用。**能在工作流里合理修复的不用。只有当把这个 case 塞进主流程的成本超过这个 case 本身价值的时候，才登记成边缘案例。
理念
边缘案例在文档核查里是必然存在的。金融文档由数千家不同机构出具，每家都有自己的排版习惯、模板风格、对法规的不同理解。没有任何工作流能覆盖所有变体。
问题不是"怎么消灭边缘案例"，而是"怎么在不污染主流程的前提下高效管理它们"。
答案是：分离它们。主工作流保持干净。边缘案例可追踪、可检测、再次出现时可取出来用。
主工作流 vs 边缘案例处理的分工
文档进入
│
├─ 检查边缘案例注册表 → 匹配？→ 执行特定解决方案
│ │
│ 不匹配
│ │
└───────────────────────────┤
▼
执行标准工作流
标准工作流保持简洁、通用、可维护。边缘案例有自己的管理体系。两者独立演进。
边缘案例注册表
每条规则技能的 assets/ 目录下维护一个结构化文件 corner_cases.json：
[
{
"id": "CC001",
"rule_id": "R001",
"description": "部分银行年报将资本充足率以小数形式（0.125）而非百分比（12.5%）表示",
"affected_documents": ["bank_xyz_annual_2024.pdf"],
"detection_pattern": {
"type": "regex",
"pattern": "资本充足率[：:]*\\s*0\\.\\d+",
"confidence_threshold": 0.8
},
"resolution": {
"type": "code",
"action": "在阈值比较前将提取值乘以100",
"code_snippet": "if value < 1.0: value *= 100"
},
"discovered_at": "<日期>",
"iteration": 3,
"status": "active"
}
]
每条记录应包含：
- 描述（description）：用人话说清楚这是什么情况。开发者用户需要能看懂。
- 检测模式（detection_pattern）：如何在执行前识别此类文档。类型可以是：
regex：正则匹配文档内容。keyword：关键词组合匹配。structural：文档结构特征（如缺少某个章节、表格格式异常）。model：需要 LLM 判断（成本高，仅在简单方法无法检测时使用）。
- 解决方案（resolution）：如何处理匹配的文档。类型可以是：
code：Python 代码修正（如单位转换）。regex：正则替换或别名映射。prompt：使用不同的 LLM 提示词。parser：使用不同级别的解析器。manual：标记为需人工处理，不自动判定。
- 发现时间和迭代轮次。
- 状态（status）：
active、promoted（已提升到主工作流）、 deprecated（已废弃）。
怎么处理边缘案例 —— 懒加载，高检索阈值
边缘案例只活在注册表里，不进主核查路径。它们是懒加载、高阈值检索的，意思是：
- 主工作流先在每份文档上跑。
- 注册表只有当一份新进文档强烈地像某条已收录的边缘案例时才被调用，这条记录的解决方案才被取出来用。
- "强烈地像"这条线要划得高 —— 误匹配会把一个不相干的解决方案套上来，污染主结果。宁可漏匹配（主工作流接管，哪怕处理得不完美），也不要把无关的边缘补丁错套上去。
两种检测模式都行：
- 便宜的确定性匹配：基于文档文本的正则或关键词指纹。快，每份文档都能跑。
- 基于 embedding 的相似度：对文档里规则相关的区域算 embedding，和已登记的边缘案例 embedding 做相似度比对。能抓住正则抓不到的语义相似性，但成本高。
早期规则、注册表条目少时，确定性检测足够。注册表大了之后，基于 embedding 的相似度更可扩展。
匹配触发时：
- 记录"触发了哪条边缘案例"（审计可见性）。
- 应用登记的解决方案。
- 按解决方案的指示跳过 / 补充 / 覆盖标准工作流。
检测效率
检测必须轻量。每份文档跑很多个正则检查是可以接受的；跑很多个 LLM 调用就不行。
优先级：
- 正则 / 关键词检测（毫秒级）→ 优先使用。
- 结构检测（秒级，需解析）→ 解析完成后顺带检查。
- LLM 检测（秒级+成本）→ 仅在前两种无法识别时使用。
何时添加边缘案例
在演进循环里，当一个失败案例被分析后，需要决定它是系统性问题、边缘案例、还是数据质量问题。
添加为边缘案例的条件（三个条件同时满足）：
- 标准工作流的迭代无法以合理代价容纳这份文档。
- 有可辨识模式：能描述这类文档的共同特征，能写出下次再识别它的检测规则。
- 解决方案明确且自包含：知道怎么处理，不是"待调查"。
不应添加为边缘案例的情况：
- 失败影响很多文档 —— 那不是边缘案例，是一种模式，主工作流该改。
- 失败无可辨识规律 —— 可能是数据质量问题，升级给开发者用户。
- 解决方案需要改变核心判定逻辑 —— 属于主工作流的范畴。
何时提升边缘案例
边缘案例不应该永远是边缘案例。当它变得普遍时，应该被提升为主工作流的一部分。
提升条件：
- 大量文档都触发：在最近的文档批次里，许多文档都触发了这条边缘案例。它已经不是"边缘"了，而是一种常见模式。
- 模式聚类：多条相似的边缘案例指向同一个底层问题。与其维护几条相似条目，不如合并为一次通用的工作流改进。
- 开发者用户确认："这就是常态，所有 XX 类型的文档都是这样" —— 开发者用户的领域知识是最权威的提升依据。
提升操作：
- 把解决方案整合到主工作流里。
- 注册表中状态改为
promoted。
- 对两个变更都做版本记录。
- 在下一批文档上验证提升后的工作流仍然正确。
人类可见性
边缘案例注册表必须对开发者用户透明可读：
- 格式清晰：JSON 或 markdown 表格，人可读。
- 上下文充分：领域专家无需阅读代码就能理解每条记录。
- 在仪表板中展示：新发现的边缘案例应出现在报告中。
开发者用户可添加
开发者用户往往掌握编程智能体尚未遇到的边缘案例知识。他们应能添加类似条目：
- "XX 银行的 Q4 报告总是用不同模板。"
- "2020 年以前的公募基金文档遵循旧版信息披露规定。"
- "小型农商行的贷款合同经常缺少标准条款编号。"
- "境外分行的报告中金额以美元计，不是人民币。"
这些输入是宝贵的预防性信息。注册表里给手动添加的条目标注来源为 "开发者用户"。
成本控制
每条边缘案例都有运行时成本：检测逻辑在每份文档上都要执行。保持注册表精简：
- 清理废弃条目：已提升或不再出现的边缘案例，状态改为
deprecated，定期清理。
- 合并相似条目：若有多条边缘案例都在处理"日期格式变体"之类的事，合并为一条更宽泛的检测模式。
- 检测模式高效化：优先用正则而非 LLM 检测。
- 监控规模：当单条规则的边缘案例数量明显变大时，这其实是工作流本身需要改进的信号 —— 这些"边缘"里可能很多该被提升到主流程。
定期审查注册表：还在活跃的有哪些？有可合并的吗？有可提升的吗？有过时的吗？保持注册表的新陈代谢。一个不断膨胀的注册表和一个从不更新的注册表一样有害。
与演进循环的协作
边缘案例管理是演进循环的重要输出之一：
演进循环分析失败
│
├─ 系统性失败 → 修改工作流
│
├─ 边缘案例 → 添加到注册表
│
└─ 数据质量问题 → 报告给开发者用户
每次演进循环跑完，检查是否有新的边缘案例需要添加，以及现有边缘案例是否需要状态变更。
