kc-beta 0.1.0

package/template/skills/zh/meta-meta/skill-to-workflow/SKILL.md

@@ -0,0 +1,275 @@
+---
+name: skill-to-workflow
+description: Distill a proven verification skill into a Python workflow with worker LLM prompts. Use when a rule skill has been tested and reaches the SKILL_ACCURACY threshold defined in .env. Covers the decision of what to implement as code vs LLM calls, prompt engineering for small context windows, model tier selection and progressive downgrade, and testing workflows against the coding agent's own results as ground truth. Also use when optimizing existing workflows for cost or speed.
+---
+
+# 技能到工作流的蒸馏
+
+## 蒸馏的本质
+
+技能（Skill）是标准答案。它由你这个编程智能体直接执行，调用最强的模型、拥有完整的上下文、不计成本地追求准确率。
+
+工作流（Workflow）是技能的廉价近似。它由 Python 代码驱动，调用更小、更便宜的Worker LLM（执行模型），在有限的上下文窗口内完成核查。
+
+蒸馏的目标：**在成本大幅降低的前提下，尽可能逼近技能的准确率。**
+
+这不是翻译。你不是把 SKILL.md 翻译成 Python。你是在重新设计核查流程，让一个能力更弱的执行者也能做对。
+
+## 启动蒸馏的前提条件
+
+必须同时满足以下条件才能启动蒸馏：
+
+1. **技能测试准确率达标**：在 `assets/samples.json` 和 `assets/corner_cases.json` 上的准确率 ≥ `.env` 中的 `SKILL_ACCURACY` 阈值
+2. **边界案例已充分记录**：至少覆盖了已知的主要例外情形
+3. **判定逻辑已稳定**：最近两轮迭代没有对核心判定逻辑做出修改
+
+如果技能本身还在频繁迭代，不要急于蒸馏。等它稳定下来。
+
+## 蒸馏决策：代码还是模型调用
+
+这是蒸馏过程中最关键的决策。原则很简单：
+
+### 用 Python 代码实现（零成本）
+
+- 日期比较、金额计算、税率换算
+- 正则匹配（发票号码格式、统一社会信用代码校验）
+- 字段存在性检查
+- 格式标准化（大小写、日期格式转换）
+- 枚举值校验（货币代码、国别代码）
+- 数学运算（价税合计 = 不含税金额 × (1 + 税率)）
+
+### 用Worker LLM调用实现（有成本）
+
+- 从非结构化文本中提取关键信息
+- 理解自然语言描述的业务含义
+- 判断两段文字的语义是否一致
+- 识别和解析复杂的表格结构
+- 分类判断（如：该笔费用属于哪个科目）
+
+### 混合方案（推荐）
+
+大多数核查规则的最优实现是混合方案：
+
+```
+1. Python 预处理（格式化、提取结构化字段）
+2. LLM 调用（语义理解、非结构化信息提取）
+3. Python 后处理（逻辑判断、计算、格式化输出）
+```
+
+把 LLM 调用夹在中间，用代码限制它的输入范围和输出格式。这样既能利用 LLM 的语义能力，又能用代码保证确定性。
+
+## 工作流文件结构
+
+```
+workflows/R001-invoice-date-validity/
+├── workflow_v1.py        # 主流程代码
+├── prompts/              # Worker LLM的提示词模板
+│   ├── extract_dates.md  # 日期提取提示词
+│   └── judge_validity.md # 有效性判断提示词
+├── config.json           # 配置（模型层级、参数）
+└── CHANGELOG.md          # 变更记录
+```
+
+### workflow_v1.py 的结构要求
+
+```python
+"""
+R001 - 发票日期有效性核查工作流
+蒸馏自: rule-skills/R001-invoice-date-validity/
+技能准确率: 95%
+蒸馏日期: 2025-04-01
+"""
+
+import json
+import os
+from pathlib import Path
+
+def run_verification(document_data: dict, config: dict) -> dict:
+    """
+    工作流入口函数。
+    
+    Args:
+        document_data: 待核查的单据数据
+        config: 运行时配置（模型选择、API地址等）
+    
+    Returns:
+        标准核查结果字典
+    """
+    # 步骤1: 预处理（纯代码）
+    # 步骤2: LLM提取（如需要）
+    # 步骤3: 逻辑判断（纯代码）
+    # 步骤4: 格式化输出
+    pass
+```
+
+入口函数必须是 `run_verification`，签名固定。这样质量监控和批量处理可以统一调度。
+
+### config.json
+
+```json
+{
+  "rule_id": "R001",
+  "rule_name": "发票日期有效性",
+  "distilled_from": "rule-skills/R001-invoice-date-validity/",
+  "version": "v1",
+  "model_tier": "TIER3",
+  "llm_steps": ["extract_dates"],
+  "code_steps": ["normalize_format", "compare_dates", "format_output"],
+  "estimated_cost_per_doc": 0.002,
+  "api_base_url": "${API_BASE_URL}",
+  "api_key": "${API_KEY}"
+}
+```
+
+## Worker LLM的提示词工程
+
+Worker LLM不是你。它的上下文窗口更小，推理能力更弱，对业务背景一无所知。提示词必须为它的局限性做设计。
+
+### 自包含原则
+
+提示词不能假设Worker LLM知道任何背景信息。所有必要的上下文都要在提示词中显式提供：
+
+```markdown
+你是一个单据信息提取助手。你的任务是从以下发票文本中提取开票日期。
+
+提取规则：
+- 查找「开票日期」或「Date of Issue」字段
+- 日期格式统一输出为 YYYY-MM-DD
+- 如果找不到日期，输出 null
+- 只提取日期，不要做任何判断
+
+发票文本：
+{invoice_text}
+```
+
+### 结构化输出强制
+
+Worker LLM的输出必须是可解析的。在提示词中明确要求 JSON 格式输出：
+
+```markdown
+请严格按照以下 JSON 格式输出，不要输出任何其他内容：
+
+{
+  "invoice_date": "YYYY-MM-DD 或 null",
+  "extraction_confidence": "high / medium / low"
+}
+```
+
+### 收窄上下文
+
+不要把整篇文档丢给Worker LLM。只传入它需要处理的那部分内容：
+
+- 如果只需要提取发票日期，只传发票头部区域的文本
+- 如果需要比对合同信息，只传合同中的相关条款段落
+- 上下文越窄，提取越准，成本越低
+
+### 使用单据语言
+
+提示词的指令语言应该与单据语言一致。核查中文单据时，提示词用中文写。这样可以避免Worker LLM在语言切换中引入错误。
+
+### 少量示例策略
+
+在提示词中提供 1-2 个精简的输入输出示例，但不要过多：
+
+- Worker LLM的上下文窗口有限，示例太多会挤占正文空间
+- 选择最典型的正例和一个常见的异常例
+- 示例要简短，只展示关键特征
+
+## 模型层级选择与逐级降级
+
+### 选择策略
+
+从 TIER1 开始，逐步尝试更低层级。`.env` 中定义了四个层级：
+
+- `TIER1`：最强，适合复杂的语义理解和多步推理
+- `TIER2`：中等，适合需要一定推理的提取和判断
+- `TIER3`：轻量，适合结构化信息提取
+- `TIER4`：最便宜，适合简单的格式提取和分类
+
+### 降级流程
+
+```
+1. 用 TIER1 运行全部测试样本，确立准确率天花板
+2. 用 TIER2 运行同一批测试样本，与 TIER1 结果对比
+3. 如果 TIER2 准确率接近 TIER1 → 继续尝试 TIER3
+4. 如果 TIER3 仍然接近 → 继续尝试 TIER4
+5. 选择满足 WORKFLOW_ACCURACY 阈值的最低层级
+6. 如果 TIER1 本身都不达标 → 回到技能层面检查提示词设计
+```
+
+注意：不同步骤可以使用不同层级。比如日期提取用 TIER4，语义判断用 TIER2。在 config.json 中按步骤记录最优层级。
+
+### 正式降级协议
+
+以下数值和流程是推荐起点，编程智能体和开发者用户应根据实际情况自由调整。重要的是模式本身（测试 → 对比 → 记录 → 退化时重评），而非具体数字。
+
+**方向**：自上而下。先用 TIER1 建立准确率天花板，再逐级尝试更低层级，找到成本与准确率的最优平衡点。
+
+**最低测试量**：每个候选层级至少运行 min(10, total_samples) 篇文档。样本量太少则结论不可靠。
+
+**准确率差值判定**：若低一级模型的准确率显著低于上一级（建议阈值：>5个百分点），则停留在较高层级。例如 TIER1 达到 96%、TIER2 只有 89%，则该步骤选定 TIER1。
+
+**逐步骤独立评估**：工作流中每个 LLM 调用步骤独立评估模型层级。步骤 A 可能用 TIER3，步骤 B 可能需要 TIER1。最终结果按步骤分别记录在 config.json 的 `llm_steps` 配置中。
+
+**退化触发重评**：生产环境质控发现准确率下降时（如 `quality-control` 技能检测到的退化信号），应对相关步骤重新执行降级评估。模型供应商更新、数据分布漂移都可能导致原有选择失效。
+
+**模型-任务推荐表**：在项目级别维护 task_type → tier 的映射表，积累经验数据。例如「中文发票日期提取 → TIER4」「合同语义比对 → TIER1」。随着测试轮次增多，这张表会成为新规则蒸馏的起点参考。
+
+**与文档解析的一致性**：此降级框架与 `document-parsing` 技能中解析器逐级升级的机制同构——都是在层级间做测试、对比、选择。两者可复用相同的评估脚本和判定逻辑。
+
+## 对照真值测试
+
+技能的核查结果就是真值（Ground Truth）。工作流的测试方法是与技能结果逐字段对比。
+
+### 对比维度
+
+- **判定一致性**：工作流的 verdict 是否与技能的 verdict 一致
+- **字段提取准确性**：工作流提取的字段值是否与技能提取的一致
+- **置信度校准**：工作流报告高置信度的案例，是否确实准确率更高
+
+### 准确率计算
+
+```
+工作流准确率 = 与技能判定一致的案例数 / 总案例数
+```
+
+分别计算总体准确率和分类准确率（通过、不通过、无法核查各自的准确率），避免类别不均衡导致的误判。
+
+## 版本管理
+
+工作流的迭代以文件版本号标识：
+
+- `workflow_v1.py` → 初始蒸馏版本
+- `workflow_v2.py` → 优化提示词后的版本
+- `workflow_v3.py` → 更换模型层级后的版本
+
+不要覆盖旧版本文件。保留完整的版本历史，便于回退和对比。
+
+## 成本追踪
+
+每次工作流运行都记录成本数据：
+
+```json
+{
+  "rule_id": "R001",
+  "workflow_version": "v2",
+  "document_id": "DOC-001",
+  "llm_calls": 2,
+  "total_tokens": 1850,
+  "estimated_cost_usd": 0.003,
+  "model_used": "TIER3",
+  "timestamp": "2025-04-01T10:30:00Z"
+}
+```
+
+汇总后用于评估单据平均核查成本，指导模型层级优化方向。
+
+## SiliconFlow API 配置说明
+
+工作流中调用Worker LLM时，通过 `.env` 中配置的 `API_BASE_URL` 和 `API_KEY` 连接到 SiliconFlow 或其他兼容的 API 服务。
+
+调用时注意：
+- 使用标准的 OpenAI 兼容接口格式
+- 设置合理的超时和重试机制
+- 对 API 错误做好降级处理（如某模型不可用时切换到备选模型）
+- 记录每次调用的 token 用量和响应时间

package/template/skills/zh/meta-meta/skill-to-workflow/references/worker-llm-catalog.md

@@ -0,0 +1,50 @@
+# Worker LLM Catalog
+
+Models available via SiliconFlow API for worker LLM tasks. Update this catalog as models change.
+
+## Text Models
+
+| Tier | Model | Context Window | Strengths | Notes |
+|------|-------|---------------|-----------|-------|
+| TIER1 | Pro/zai-org/GLM-5 | 128K | Strong reasoning, Chinese language | Top tier for complex judgment |
+| TIER1 | Pro/moonshotai/Kimi-K2.5 | 128K | Long context, strong extraction | Good for full-document processing |
+| TIER2 | Pro/deepseek-ai/DeepSeek-V3.2 | 64K | Balanced capability/cost | Good general purpose |
+| TIER2 | Pro/MiniMaxAI/MiniMax-M2.5 | 64K | Strong Chinese, fast | Good for Chinese documents |
+| TIER2 | Qwen/Qwen3.5-397B-A17B | 32K | Large MoE, strong reasoning | Cost-effective for complex tasks |
+| TIER3 | Qwen/Qwen3.5-122B-A10B | 32K | Good accuracy, lower cost | Sweet spot for many tasks |
+| TIER4 | Qwen/Qwen3.5-35B-A3B | 16K | Fast, cheap | Best for simple extraction |
+
+## Vision/OCR Models
+
+| Tier | Model | Strengths | Notes |
+|------|-------|-----------|-------|
+| OCR_TIER1 | zai-org/GLM-4.6V | Best OCR accuracy | Use for complex tables/charts |
+| OCR_TIER2 | Qwen/Qwen3.5-397B-A17B | Good general vision | Multimodal version |
+| OCR_TIER3 | PaddlePaddle/PaddleOCR-VL-1.5 | Fast, lightweight OCR | Best for standard text |
+
+## Selection Guidelines
+
+- Start with the highest tier that fits your context window needs.
+- For extraction of simple entities (dates, amounts, names): TIER3-4 often sufficient.
+- For semantic judgment (adequacy, compliance): TIER1-2 usually needed.
+- For Chinese financial documents: prefer GLM and Qwen models over DeepSeek for domain terminology.
+- Context window constraint: if the section to process exceeds the model's window, either narrow the context further (tree processing) or use a model with a larger window.
+
+## API Configuration
+
+```python
+import openai
+
+client = openai.OpenAI(
+    api_key=os.getenv("SILICONFLOW_API_KEY"),
+    base_url=os.getenv("SILICONFLOW_BASE_URL")
+)
+
+response = client.chat.completions.create(
+    model="Qwen/Qwen3.5-122B-A10B",  # Use the model name from the table
+    messages=[{"role": "user", "content": prompt}],
+    temperature=0.1  # Low temperature for deterministic extraction
+)
+```
+
+This catalog should be maintained by the coding agent. Add new models as they become available, remove deprecated models, and update capability assessments based on testing experience.

package/template/skills/zh/meta-meta/task-decomposition/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: task-decomposition
+description: Decompose each verification rule into independent sub-tasks and assign the optimal method (rule, code, LLM, manual) to each. Use when converting extracted rules into implementation plans, when a rule skill is too expensive or inaccurate and needs restructuring, or when designing a multi-step verification pipeline. Covers MECE decomposition, method selection via the four-dimension decision matrix, cost-benefit analysis, and source tagging. Also use when auditing an existing workflow for cost optimization opportunities.
+---
+
+# 任务分解与方法分配——柳叶刀方法
+
+## 为什么叫「柳叶刀」
+
+外科手术用柳叶刀，不用斧头。核查任务的分解也是如此——每一刀都要精准，切在方法论的边界上，而不是随意劈开。
+
+每条核查规则看起来是一个动作，实际上是一条操作链。以「核查发票日期是否在合同有效期内」为例，实际包含：定位发票日期字段 → 提取日期值 → 标准化日期格式 → 与合同日期比对 → 生成批注。这五个步骤各自需要不同的处理方法。
+
+把整条链丢给 LLM 处理当然能跑通。但成本是精细分解方案的 100 倍，出了问题也无法定位是哪个环节错了。柳叶刀方法的核心：把每条规则切到方法论上同质的最小单元，然后为每个单元分配最便宜且能胜任的方法。
+
+## MECE 分解原则
+
+将核查规则分解为子任务时，必须满足 MECE（互斥穷尽）原则：
+
+**互斥**——任意两个子任务不做重复的事。如果子任务A提取了发票日期，子任务B就不应再提取发票日期。重复意味着浪费和潜在的不一致。
+
+**穷尽**——所有子任务合在一起覆盖整条规则。不能有遗漏。如果依次执行所有子任务，规则应当被完整核查。
+
+每个子任务有且仅有一个输入和一个输出。上一个子任务的输出是下一个子任务的输入。这形成了一条接口清晰的流水线。
+
+### 何时停止分解
+
+当子任务在方法论上是**同质的**——即只需一种方法就能完成——就停止分解。如果一个子任务仍然需要两种不同的方法（比如先用正则提取，再用 LLM 判断），说明它还不是原子级别，需要继续切分。
+
+### 标准分解链
+
+大多数文档核查规则的分解遵循这条链路：
+
+```
+定位 → 提取 → 标准化 → 判定 → 批注
+```
+
+不是每条规则都有全部五个阶段。有些规则不需要标准化（提取值已经是目标格式），有些通过时不需要批注。但这条链路是可靠的起始框架。
+
+### 流水线拓扑
+
+根据规则类型不同，流水线有三种典型拓扑：
+
+- **线性**：单文档、单字段。`定位 → 提取 → 标准化 → 判定 → 批注`。大多数阈值检查属于此类，如资本充足率核查。
+- **汇聚**：来自不同文档或不同章节的两个字段。两条平行的定位-提取链在判定步骤汇合。发票金额与合同金额的交叉验证属于此类。
+- **扇出**：一条规则应用于文档内的多个条目（如验证发票中的每一行项目）。定位步骤产出 N 个条目，每个条目独立流过后续链路。此时规模维度至关重要——如果 N 很大，方法分配必须考虑单条目成本。
+
+### 分解示例：发票核查
+
+以「核查发票金额是否与合同约定一致」为例，完整分解如下：
+
+| 序号 | 子任务 | 输入 | 输出 | 分配方法 | 依据 |
+|---|---|---|---|---|---|
+| 1 | 定位发票金额字段 | 发票全文 | 字段位置 | 正则 | 增值税发票金额字段位置固定，标记明确 |
+| 2 | 提取发票金额 | 定位到的区域 | 数值（浮点数） | 正则 | 格式可预测：¥xxx,xxx.xx |
+| 3 | 大写金额交叉校验 | 小写金额 + 大写金额文本 | 一致/不一致 | Python | 中文大写转数字后比对 |
+| 4 | 定位合同金额条款 | 合同全文 | 段落文本 | LLM (Tier 3) | 合同格式多样，金额条款位置不固定 |
+| 5 | 提取合同金额 | 定位到的段落 | 数值（浮点数） | 正则 + Python | 正则提取数字，Python 处理万/亿单位换算 |
+| 6 | 金额比对 | 发票金额, 合同金额 | 通过/不通过 | Python | 纯算术比较（允许配置容差范围） |
+| 7 | 生成批注 | 所有提取值 | 批注字符串 | 模板 | 「发票金额 {X} 元与合同约定 {Y} 元不一致，差异 {Z} 元」 |
+
+七个子任务中只有一个需要 LLM 调用。其余全部由正则或 Python 代码完成，成本为零。
+
+## 决策矩阵
+
+分解完成后，为每个子任务分配处理方法。分配依据四个维度的综合评估。完整的决策矩阵及详细用例参见 `references/decision-matrix.md`。
+
+### 四维度定义
+
+| 维度 | 含义 | 低（1-2） | 中（3） | 高（4-5） |
+|---|---|---|---|---|
+| **确定性** | 输入格式的可预测程度 | 自由文本，无固定格式 | 半结构化，已知章节但格式多变 | 固定模板，字段位置精确 |
+| **规模** | 每份文档需处理的条目数量 | 1-5 个 | 10-100 个 | 1,000 个以上 |
+| **语义深度** | 需要的语言理解程度 | 零——纯模式或数值 | 中等——实体识别、简单上下文 | 深度——判断、充分性评估、意图推理 |
+| **成本敏感度** | 单文档预算约束 | 不限（一次性审计） | 中等（每月数百份） | 紧张（每日数千份） |
+
+### 方法优先级
+
+始终优先选择最便宜的能达到准确率要求的方法：
+
+```
+规则/正则 → Python 代码 → LLM 调用 → 人工审核
+```
+
+不允许跳级。先试正则，不行再试代码，代码不行再试 LLM，LLM 不行才上人工。每次升级必须有下级方法失败的证据。
+
+注意四个维度之间存在交互作用。高规模加高成本敏感度会强力推动选择代码方案，即使中等语义深度在正常情况下指向 LLM。相反，低规模可以放松成本压力，使得 LLM 在理论上可以用复杂正则解决的任务上也成为可行选项。让维度的组合引导你，不要被任何单一维度绑架。
+
+### 决策速查表
+
+| 确定性 | 规模 | 语义深度 | 成本敏感度 | 推荐方法 |
+|---|---|---|---|---|
+| 高 | 任意 | 低 | 任意 | **正则 / 规则** |
+| 高 | 任意 | 低 | 任意 | **Python 代码** |
+| 中 | 高 | 低 | 高 | **代码 + 正则** |
+| 中 | 低 | 中 | 低 | **LLM** |
+| 低 | 任意 | 高 | 任意 | **LLM** |
+| 低 | 高 | 高 | 高 | **低层级 LLM + 抽样校验** |
+| 任意 | 任意 | 任意 | — | **人工**（兜底） |
+
+## 成本效益意识
+
+方法分配不是纸上谈兵，它直接决定了生产环境的单文档成本。
+
+### 实战案例：发票匹配合同
+
+某企业需要将 31,800 张发票与 15,940 份合同进行匹配。暴力方案：对 5.07 亿个配对全部调用 LLM 比对。
+
+按 SiliconFlow API 定价（以 Qwen2.5-7B 为例，输入 ¥0.35/百万 token，输出 ¥0.35/百万 token），每次比对按 500 token 输入 + 100 token 输出计算：
+
+- 单次调用成本：约 ¥0.00021
+- 5.07 亿次调用：约 ¥106,470
+
+十万元人民币只为了做配对匹配，这在任何业务场景下都不可接受。
+
+柳叶刀方法的分层方案：
+
+| 层级 | 方法 | 输入规模 | 输出规模 | 消减率 | 成本 |
+|---|---|---|---|---|---|
+| 1. 供应商名称 + 合同编号精确匹配 | 正则 | 5.07 亿对 | 25,200 匹配 | 99.5% | ≈ ¥0 |
+| 2. 金额区间（±5%）+ 日期重叠 | Python | 剩余未匹配 | 12,400 候选 | 97.6% | ≈ ¥0 |
+| 3. 行项目描述语义比对 | LLM (Tier 3) | 12,400 候选 | 7,652 确认 | 精准过滤 | ≈ ¥170 |
+| 4. 低置信度匹配人工审核 | 人工 | ~200 不确定 | ~200 解决 | 兜底 | ≈ ¥700 |
+
+总成本：约 ¥870。是暴力方案的 **1/122**。准确率相同，可调试性更强。
+
+### 成本计算模板
+
+在分解阶段就估算单文档成本：
+
+| 子任务 | 方法 | 单次成本 | 每文档调用次数 | 小计 |
+|---|---|---|---|---|
+| 定位章节 | LLM Tier 3 | ¥0.001 | 2 | ¥0.002 |
+| 提取字段 | 正则 | ¥0.000 | 5 | ¥0.000 |
+| 标准化 | Python | ¥0.000 | 5 | ¥0.000 |
+| 交叉比对 | Python | ¥0.000 | 1 | ¥0.000 |
+| 语义判定 | LLM Tier 2 | ¥0.003 | 1 | ¥0.003 |
+| 批注生成 | 模板 | ¥0.000 | 1 | ¥0.000 |
+| **单文档合计** | | | | **¥0.005** |
+
+将单文档成本乘以预期文档量，与开发者用户确认预算是否可接受。如果超预算，优先优化成本最高的子任务——通常是单次调用最贵或调用次数最多的 LLM 步骤。
+
+### 核心原则：先廉后贵
+
+永远把便宜的过滤器放在前面。让正则和代码先消减 90%+ 的工作量，只把剩余的疑难部分交给 LLM。这不仅降低成本，还提升了调试能力——因为到达 LLM 步骤的数据已经被前序步骤严格筛选过。
+
+## 来源标记
+
+每个子任务的输出必须携带 `extraction_method` 字段。这不是可选的元数据——这是核查系统的承重结构。
+
+来源标记支撑三项不可或缺的能力：
+
+**调试定位**——当核查结论出错时，标记告诉你是哪个子任务、哪种方法产生了错误。没有标记，你面对的是一个黑盒。例如：金额比对失败，标记显示 `extraction_method: regex`，说明是正则提取阶段出了问题，而非判定逻辑有误。
+
+**成本归因**——标记让你精确计算每种方法的实际成本贡献。哪些 LLM 调用在消耗预算？哪些正则步骤在免费贡献准确率？这些数据驱动优化决策。
+
+**置信度校准**——不同方法有不同的可靠性特征。正则提取的结果非对即错，没有中间地带。LLM 提取的结果有置信度分布。来源标记直接输入 `confidence-system` 的方法先验（method prior），使置信度分数具备校准基础。
+
+### 标记规范
+
+在项目范围内保持一致的标记值：
+
+| 标记值 | 含义 |
+|---|---|
+| `regex` | 正则表达式提取 |
+| `python_calc` | Python 计算或转换 |
+| `llm_tier1` ~ `llm_tier4` | 对应层级的 LLM 调用 |
+| `template` | 模板填充（批注生成等） |
+| `manual_review` | 人工审核 |
+
+## 反模式
+
+### LLM 万能论
+
+把整份文档丢给 LLM，提示词写「请检查是否符合规则X」。演示时效果漂亮，生产中成本灾难。
+
+典型案例：某项目将发票号码格式校验交给 LLM 处理。发票号码是固定的 20 位数字，一条正则 `^\d{20}$` 就能搞定。LLM 每次调用消耗 2000 token，准确率反而低于正则（LLM 偶尔会「理解」出不存在的格式问题）。成本差异：正则 ¥0 vs LLM ¥0.001/次 × 10 万张 = ¥100。
+
+**诊断信号**：如果一个子任务的输入格式完全可预测，且不需要语义理解，它不应该用 LLM。
+
+### 正则过度工程
+
+为了覆盖所有可能的日期格式写了 500 行正则，结果维护成本极高，遇到新格式就崩溃。
+
+**诊断信号**：如果正则需要频繁修补或超过 3 行，考虑这个子任务是否应该升级到 LLM 处理。
+
+### 黑盒流水线
+
+子任务之间没有中间输出，只有最终结论。出错时无法定位是哪个环节的问题。
+
+典型案例：资本充足率核查流水线输出「不通过」，但无法区分是提取的资本充足率数值有误、还是比较逻辑有 bug、还是文档中根本没有这个字段。
+
+**诊断信号**：如果调试一条规则需要从头到尾重新跑一遍，说明缺少中间检查点。
+
+### 巨石端到端
+
+不分层，每个子任务都对每份文档执行，即使前序步骤已经可以短路。
+
+典型案例：贷款申请交叉验证流水线对每份申请执行完整的七步核查，即使第一步「定位」就发现文档中缺少相关章节。合理做法：定位失败 → 直接输出「字段缺失」→ 跳过后续步骤。
+
+**诊断信号**：如果流水线对明显不适用的文档也消耗完整的处理资源，说明缺少短路逻辑。
+
+### 过早优化
+
+在核查逻辑还没验证正确之前就花大量时间优化方法分配。
+
+**正确顺序**：先全部用 LLM 跑通 → 在 Samples/ 上证明核查逻辑正确 → 再逐个子任务尝试推向更便宜的方法，每次替换后验证准确率保持不变。先对再便宜，不能反过来。分解本身是最难的部分，方法分配随时可以调整。
+
+## 与其他技能的衔接
+
+任务分解在 KC Reborn 生命周期中处于规则提取和技能编写之间。
+
+**输入**：来自 `rule-extraction` 的规则目录。每条规则是一个原子级、可测试的核查要求。如果规则尚未达到原子级别，先退回给规则提取环节做进一步分解，再进入任务分解。
+
+**输出**：每条规则的子任务分解清单——每个子任务包含定义好的输入、输出和分配方法。这份分解清单直接输入 `skill-authoring`，成为技能文件夹的实现蓝图。分解清单同时也是测试契约：每个子任务的输出都可以独立测试和验证。
+
+方法分配同时指导 `skill-to-workflow` 中的层级选择。当技能被蒸馏为工作流时：
+- 正则/代码子任务 → `scripts/` 中的代码
+- LLM 子任务 → `prompts/` 中的提示词
+- 人工子任务 → 质量控制层的升级路径
+
+分解方案不是一成不变的。通过 `evolution-loop` 的测试迭代，你会发现某些方法分配需要调整——以为是确定性的子任务出现了需要 LLM 处理的边界情况，以为需要 LLM 的子任务其实一条正则就能解决。更新分解方案，用 `version-control` 记录变更。
+
+如果你发现一条规则很难分解为干净的子任务，这通常意味着你还没有充分理解这条规则。回到开发者用户那里去。问他们人工核查这条规则时的实际操作步骤。他们的人工流程往往就是最佳的分解蓝图——它揭示了再多抽象分析也无法发现的自然子任务边界。

package/template/skills/zh/meta-meta/task-decomposition/references/decision-matrix.md

@@ -0,0 +1,81 @@
+# Decision Matrix for Method Selection
+
+This reference provides the detailed decision matrix for assigning methods to sub-tasks during task decomposition. Read `task-decomposition` SKILL.md first for the philosophy; this document is the operational reference.
+
+## The Four Dimensions
+
+| Dimension | Definition | 1 (Low) | 3 (Medium) | 5 (High) |
+|---|---|---|---|---|
+| **Certainty** | Predictability of input format and location | Free-form prose, no fixed structure | Semi-structured with known sections but variable formatting | Fixed template, exact field positions |
+| **Scale** | Number of items to process per document | 1-5 items | 10-100 items | 1,000+ items |
+| **Semantic Depth** | Language understanding required | None — pure pattern or numeric | Moderate — entity recognition, simple context | Deep — judgment, adequacy assessment, intent interpretation |
+| **Cost Sensitivity** | Budget constraint per document | Unlimited (one-off audit) | Moderate (monthly batch of hundreds) | Tight (daily batch of thousands) |
+
+## Method Assignment Rules
+
+Use the highest-priority method whose requirements are met. Priority order: Rule/Regex > Code > LLM > Manual.
+
+| Certainty | Scale | Semantic Depth | Cost Sensitivity | Assigned Method | Rationale |
+|---|---|---|---|---|---|
+| High (4-5) | Any | Low (1-2) | Any | **Rule / Regex** | Predictable input + no language understanding = deterministic pattern matching |
+| High (4-5) | Any | Low (1-2) | Any | **Code / Python** | Calculations, comparisons, transformations on structured data |
+| Medium (3) | High (4-5) | Low (1-2) | High (4-5) | **Code + Regex** | Volume demands speed; invest in parsing code to avoid per-item LLM cost |
+| Medium (3) | Low (1-2) | Medium (3) | Low (1-2) | **LLM** | Moderate understanding needed, low volume makes LLM cost acceptable |
+| Low (1-2) | Any | High (4-5) | Any | **LLM** | Deep semantic understanding has no cheaper alternative |
+| Low (1-2) | High (4-5) | High (4-5) | High (4-5) | **LLM (low tier) + sampling** | Volume + semantics + budget = use cheapest LLM, sample-verify with higher tier |
+| Any | Any | Any | — | **Manual** | Last resort when automated methods fail accuracy threshold |
+
+The table covers common patterns, not every combination. When a sub-task falls between categories, test both candidate methods on a sample and measure accuracy and cost. Let data decide.
+
+## Worked Example: Cross-Field Validation
+
+**Rule**: "The loan amount must not exceed 70% of the appraised collateral value."
+
+Decomposition into sub-tasks with method assignments:
+
+| # | Sub-task | Input | Output | Method | Rationale |
+|---|---|---|---|---|---|
+| 1 | Locate loan amount field | Full document text | Page/section reference | LLM (Tier 3) | Field position varies across document types |
+| 2 | Extract loan amount | Located section text | Numeric value (float) | Regex | Amount follows pattern: ¥/$/digits with commas |
+| 3 | Locate collateral section | Full document text | Page/section reference | LLM (Tier 3) | Section name varies: "Collateral", "Security", "Pledged Assets" |
+| 4 | Extract appraised value | Located section text | Numeric value (float) | Regex + Code | Regex extracts; code handles unit conversion (万/亿) |
+| 5 | Calculate threshold | Loan amount, collateral value | 70% threshold value | Code | Pure arithmetic: `collateral * 0.70` |
+| 6 | Compare | Loan amount, threshold | Pass/Fail | Code | Simple comparison: `loan_amount <= threshold` |
+| 7 | Generate comment | All extracted values | Comment string | Code (template) | Template: "Loan amount {X} is {above/within} 70% of collateral value {Y} (threshold: {Z})" |
+
+LLM calls: 2 (locate steps only). Everything else is regex or code. Total LLM cost per document: ~0.002 USD at Tier 3 pricing.
+
+## Worked Example: Large-Scale Filtering
+
+**Task**: Match 31,800 invoices against 15,940 contracts to find which invoices belong to which contracts.
+
+Naive approach: 507M pairwise LLM comparisons. Estimated cost: $50,000+. Time: weeks.
+
+Layered decomposition:
+
+| Layer | Method | Input Size | Output Size | Reduction | Cost |
+|---|---|---|---|---|---|
+| 1. Exact match on supplier name + contract number | Rule/Regex | 507M pairs | 25,200 matches | 99.5% eliminated | ~$0 |
+| 2. Fuzzy match on amount range (±5%) + date overlap | Code | Remaining unmatched pairs | 12,400 candidates | 97.6% of remainder eliminated | ~$0 |
+| 3. Semantic comparison of line-item descriptions | LLM (Tier 3) | 12,400 candidates | 7,652 confirmed | Final precision filter | ~$25 |
+| 4. Manual review of low-confidence matches | Manual | ~200 uncertain | ~200 resolved | Edge cases | ~$100 (labor) |
+
+Total cost: ~$125. Time: hours. Same accuracy as the naive approach.
+
+The key insight: each layer's method is chosen because it is the cheapest method that can reliably make the distinctions required at that stage.
+
+## Cost Estimation Template
+
+Use this template during decomposition planning to estimate per-document cost.
+
+| Sub-task | Method | Est. Cost/Call | Calls/Document | Subtotal |
+|---|---|---|---|---|
+| Locate section | LLM Tier 3 | $0.001 | 2 | $0.002 |
+| Extract fields | Regex | $0.000 | 5 | $0.000 |
+| Normalize values | Python | $0.000 | 5 | $0.000 |
+| Cross-field comparison | Python | $0.000 | 1 | $0.000 |
+| Semantic judgment | LLM Tier 2 | $0.003 | 1 | $0.003 |
+| Comment generation | Template | $0.000 | 1 | $0.000 |
+| **Total per document** | | | | **$0.005** |
+
+Multiply by expected document volume to get batch cost. Compare against the developer user's budget. If total exceeds budget, optimize the most expensive sub-tasks first — usually the LLM calls with the highest per-call cost or the highest call count.