kc-beta 0.7.5 → 0.8.3

package/template/skills/zh/auto-model-selection/SKILL.md

@@ -2,51 +2,72 @@
 name: auto-model-selection
 tier: meta
 description: >
-  使用 Context7 CLI 获取最新 LLM 模型信息。当需要了解可用模型、模型能力、价格、
-  上下文窗口大小、或哪个模型适合某项任务时使用——包括分层分配、Worker LLM 工作流设计、
-  模型对比、服务商 API 调用方式等。Context7 提供训练数据中可能没有的最新信息。
-  需要安装 context7 CLI (npm i -g context7)。可选插件。
+  用 Context7 CLI 查最新模型事实（参数规模、API 格式、上下文窗口），用下面的指南
+  来理解"什么类型的模型适合 doc verification 应用的哪一段"。在为某个 tier 槽位
+  挑模型、在多个服务商之间取舍、或回看现有分层分配是否合理时调用。Context7 给你
+  新鲜事实；本 skill 给你把那些事实落到 KC 流水线上的启发式经验。可选插件
+  （安装：npm i -g context7）。
 ---
 
-# 通过 Context7 自动选择模型
+# Auto Model Selection
 
-## Context7 是什么
+模型选择并不是经常调用的 skill —— 对大部分用户来说，工作区 `.env` 里的分层已经设定得很合理，4 层 + 成本敏感的精细选型其实是过度设计。本 skill 存在的两个时刻：conductor 在从零启动时配 tier 分配（少见）；在 `skill-to-workflow` 内部某个 workflow 需要挑选合适的 worker LLM。
 
-Context7 (`c7`) 是一个轻量 CLI 工具，可获取最新的库和 API 文档。安装：`npm i -g context7`。两个命令：
-- `c7 library <查询>` — 按名称搜索库/服务商
-- `c7 docs <libraryId> <查询>` — 获取具体文档和代码示例
+下面的内容是经验性的 —— 是作者在这个领域里摸出来什么有效。当作起点启发式即可，保质期大概 3–6 个月，毕竟模型家族迭代很快。
 
-## 使用时机
+## Worker LLM 家族 —— 实战启发式
 
-- 用户的 `model-tiers.json` 过期（KC 长时间未更新）
-- 用户切换到新服务商，需要模型发现
-- 用户明确要求更新模型选择
-- 配置向导的 `/models` 端点失败，且内置模型列表过期
+- **Qwen 家族** —— 通用 worker 工作的健壮、便宜首选。任何时候该家族的旗舰 MoE 通常都是常规抽取/分类的最佳劳力之一。小尺寸（3B–70B）数量多且稳定。默认选它没错。
+- **DeepSeek** —— 复杂任务表现优秀。当规则涉及多步推理、嵌套判断、或者 Qwen 在长上下文里开始吃力的场景，伸手去拿它。
+- **GLM 和 Kimi** —— 在和 DeepSeek 相同的"复杂任务"档位也很强。代价：通常不出小尺寸变体（3B–70B），所以只能做 tier1/tier2，做不了 tier3/tier4。
 
-## 工作流程
+## 旗舰 MoE 形状与 tier1 基准
 
-1. 用户选择服务商并提供 API 密钥
-2. 用 `c7 library <服务商名>` 找到对应的 library ID
-3. 用 `c7 docs <id> "available models"` 获取当前模型列表
-4. 从文档中识别：模型名称、能力（推理、编码、视觉）、上下文窗口大小、价格
-5. 按能力和成本分配到分层：
-   - LLM tier1：最强（复杂判断、抽取）
-   - LLM tier2-3：中等（常规抽取、简单判断）
-   - LLM tier4：最便宜（大量简单任务）
-   - VLM tier1-3：视觉模型（文档解析/OCR）
-6. 更新 `model-tiers.json` 或工作区 `.env`
+当前这一代旗舰 MoE LLM 有一个可识别的形状：总参数 200-400B，每个 token 激活 ~20B 专家。例子（几个月后就会过期）：Qwen 在 200-400B-A20B 区间的旗舰 MoE、DeepSeek-V4-Flash 等。
 
-## 分层原则
+这个形状是不错的 worker LLM 首选 —— 不一定是 tier1 绝对最强，但作为基准起点很合理。挑 tier1 模型时，先从这一类开始，除非有特定理由再往别处走。
 
-- 满足准确率阈值的最便宜模型
-- 正则是 tier0 — 比任何 LLM 都小
-- 不需要填满所有分层 — 服务商没有合适模型时留空即可
-- 在 AGENT.md 中记录哪些模型适合哪些任务
+## 30B 以下的小 LLM —— 基本免费
 
-## 前置条件
+参数量降到 ~30B 以下后，大部分服务商上这些模型都极便宜。Qwen 在这个区间提供了一大堆选择，质量都不错。
+
+这个区间挑模型有两条规则：
+- **避开 coder 变体**（名字里带 `coder` / `code` 的）—— 小尺寸的 coder 模型在通用 worker 任务上多半不可靠。只在任务确实是代码相关时再用。
+- **优先选无 thinking 模式的变体**（如果有得选）。分配给小 worker 的任务都是简单固定的，多余的思考只会浪费时间和 token。
+
+## VLM / OCR 选型
+
+第一个问题：视觉任务是什么类型？
+
+- **扫描件字符、印章、手写体** —— 用专门的 OCR 模型。当前的强选项（随时间会变）：Paddle-OCR 家族、GLM-OCR、DeepSeek-OCR。旧版本仍能用。纯字符识别不需要上更大的通用 VLM。
+- **图表、复杂表格、奇怪边框或无边框的结构** —— 试更大、更贵的通用 VLM。在这类场景里，OCR 专用模型和通用 VLM 之间的结构理解差距迅速拉大。
+
+不确定时先跑最便宜的 OCR，只在它漏掉了结构信息时再升级。
+
+## Context7 —— 按需查模型事实
+
+上面的启发式回答的是"挑哪种模型"。具体事实（当前模型名、确切上下文窗口、定价、API 格式）用 Context7 查：
 
 ```bash
-npm i -g context7
+c7 library <服务商名>
+c7 docs <libraryId> "available models"
 ```
 
-验证：`c7 library openai` 应返回结果。
+两条命令：先用前者找到服务商的 library ID，再用后者拿到最新文档和代码示例。适用场景：
+
+- 工作区 `model-tiers.json` 看起来过期了（KC 自上次模型发布后没更新）
+- 用户切换服务商，需要发现可用模型
+- 某个新服务商的 `/models` 端点返回空或无帮助
+- 检查 `.env` 里的模型名是不是还在线
+
+安装：`npm i -g context7`。验证：`c7 library openai` 应返回结果。
+
+## tier1/tier2 选型最终落地
+
+tier 分配最后决定的是成本。能满足准确率要求的最便宜模型胜出。正则是隐含的 "tier 0"，规则只靠模式匹配就能完成时，应该先伸手去拿正则 —— 关于何时从正则升级到 worker LLM，见 `skill-to-workflow`。
+
+不需要填满所有 tier。如果服务商没有合适的小模型，tier3/tier4 留空完全可以。把生效的选择写到 `AGENT.md`，下次会话就能继承。
+
+## 复看节奏
+
+本 skill 的启发式会过期。作者打算每 3–6 个月在新模型代际落地之后回来更新一次。如果你发现这里的建议和 Context7 今天显示的事实矛盾了，信 Context7 —— 事实已经走在前面了。

package/template/skills/zh/bootstrap-workspace/SKILL.md

@@ -134,6 +134,33 @@ versions.json           # 版本清单（工作空间根目录）
 
 在初始化阶段就和开发者用户讨论这个节奏 —— 生产侧文档输入节奏直接决定 skill 和工作流的写法（批处理 vs 流式、幂等性要求等等）。
 
+## 持续维护 AGENT.md 的项目记忆
+
+工作区根目录的 `AGENT.md` 有几段「项目记忆」（`Project`、`Decisions`、`Domain Notes`、`User Preferences`）。它们在 bootstrap 阶段是占位注释 —— 你的任务是随着工作推进往里填东西，让跨阶段或跨会话的人能直接读出上下文。
+
+应该写什么：
+- **Project**：语料身份（法规名称 + 范围）、语言、主规则与辅助规则、样本文档集组成。
+- **Decisions**：从代码看不出来的设计决定 —— 比如「非标 35% 限制是银行级合计而非单产品限制，所以单文档报告给 WARNING 而非 FAIL」「R02-06/R02-08 对季报判 NOT_APPLICABLE，依据是法规 §39」。
+- **Domain Notes**：值得显式记下来的法规或业务领域细节 —— 比如「PT/RT/LZ 是三种不同产品类型，披露模板不同」、术语消歧。
+- **User Preferences**：开发者用户希望你在本项目上的协作风格 —— 详略偏好、命名约定、什么时候问、什么时候直接做。
+
+更新 `AGENT.md` 的自然时机：开发者用户给出实质性澄清之后、阶段结束之后、发现会影响后续阶段的设计约束之后。不要等用户发 `/remember` —— 这份记忆是你自己维护的。
+
+未来会话恢复时会先读 `AGENT.md`。它越充实，开发者用户需要重复解释的内容就越少。
+
+### 阶段切换的更新节奏
+
+一种值得警惕的反复出现的失败模式：agent 在 bootstrap 时把 AGENT.md 写得很丰富，之后就再也不碰 —— 后续若干小时的阶段工作里一次 AGENT.md 提交都没有。这就把长期记忆这个用途废了。
+
+要养成的节奏：**每次 phase transition 都往 `AGENT.md` 追加一行决策日志**。格式：
+
+```
+[<时间戳> | rule_extraction → skill_authoring]
+抽出 N 条规则；coverage_audit 已完成；R03/R05/R07 标记为判断密集型。
+```
+
+每次阶段切换三行摩擦；积累下来就是给下一个审计员、下一次会话的三十行洞见。格式不必严格 —— 节奏比措辞更重要。
+
 ## 何时需要重新初始化
 
 以下情况需要重新运行本技能：

package/template/skills/zh/compliance-judgment/SKILL.md

@@ -4,27 +4,27 @@ tier: meta
 description: Determine whether extracted entities comply with verification rules. Use after entity extraction to make the pass/fail judgment for each rule on each document. Covers translating natural language rules into executable logic, choosing between Python calculation and LLM semantic judgment, and producing actionable comments on failures. Also use when designing the judgment step of a workflow or when a rule's judgment logic needs debugging.
 ---
 
-# Compliance Judgment
+# 合规判定
 
-Judgment is the moment of truth. You have the extracted entity. You have the rule. Do they comply? The answer must be clear, correct, and — when the answer is no — accompanied by a concise, actionable comment.
+判定是真相到来的时刻。你已经拿到抽取出来的实体，也有规则在手。它们是否合规？答案必须清晰、正确，并且——当答案为否时——附带一条简洁、可执行的说明。判定环节直接决定整个核查工作流的最终产出质量：抽取做得再细，如果判定阶段含糊或前后不一，下游的合规报告就难以使用。
 
-## The Judgment Spectrum
+## 判定光谱
 
-Rules range from trivially deterministic to deeply semantic. Pick the right tool for each rule.
+规则的复杂度跨度很大，从纯粹的确定性检查到深度语义判断都有。要为每条规则挑选合适的工具，不能一刀切。
 
-**Deterministic** — threshold checks, format validation, date arithmetic, cross-field consistency. Pure Python: free, instant, deterministic.
+**确定性判定** —— 阈值核查、格式校验、日期运算、跨字段一致性。纯 Python 就够：免费、即时、可复现，并且同一份输入永远给出同一份结果，便于审计与回溯。
 
-**Semantic** — adequacy, completeness, consistency, compliance with templates, detecting misleading or suggestive language, assessing whether a description is fair and balanced. These require language understanding — use worker LLM.
+**语义判定** —— 是否充分披露、是否完整、前后是否一致、是否符合模板、是否存在误导性或暗示性表述、描述是否公允平衡。这类判断需要语言理解能力，规则关键词法或模式匹配无法胜任，应直接使用 worker LLM 完成。
 
-Many real compliance rules require semantic judgment. "The risk disclosure must adequately describe the key risks" cannot be checked with regex or Python. "The contract description must not be misleading or suggestive" requires deep language understanding. Use worker LLM for these without hesitation.
+很多真实的合规规则都需要语义判定。"风险揭示必须充分描述主要风险"无法用正则或 Python 核查；"合同描述不得具有误导性或暗示性"需要深层的语言理解；"资产管理产品的宣传材料不得含有承诺收益的暗示"同样如此。这类场景应毫不犹豫地调用 worker LLM，强行用规则匹配反而会牺牲准确率。
 
-Some rules combine both: extract a number (deterministic), compare to threshold (deterministic), then assess the explanation if borderline (semantic). The mix depends on the rule.
+也有些规则会两者并用：先抽取数值（确定性），再与阈值比较（确定性），如果结果处于临界区间，再对其解释做语义评估。这种"Python 主跑、LLM 兜底"的组合往往是性价比最高的方案。具体如何组合，取决于规则本身。
 
-The right method is whatever achieves accuracy at lowest cost. Simple threshold checks don't need LLM. Semantic assessments don't benefit from Python. Most projects will have a mix — let the nature of each rule determine the method.
+正确的方法，是以最低成本达到所需准确率的那一个。简单的阈值核查不需要 LLM，语义评估也无法靠 Python 完成。多数项目都会两者混用——让每条规则的性质决定其判定方法，而不是反过来用方法去硬套规则。
 
-## Output Format
+## 输出格式
 
-For each rule × document combination:
+对每个"规则 × 文档"的组合：
 
 ```json
 {
@@ -38,26 +38,26 @@ For each rule × document combination:
 }
 ```
 
-**Result values:**
-- **pass**: Entity complies with the rule.
-- **fail**: Entity does not comply. Comment is required.
-- **missing**: The entity could not be found in the document. This is different from fail — the information is absent, not non-compliant.
-- **error**: Something went wrong during extraction or judgment (parsing failure, API error). Needs investigation.
-- **uncertain**: The judgment is ambiguous. May need human review.
+**结果取值：**
+- **pass**：实体符合规则要求。
+- **fail**：实体不符合规则要求。必须填写 comment。
+- **missing**：文档中未找到该实体。这与 fail 不同——信息缺失，并不代表违规。
+- **error**：抽取或判定过程出现异常（解析失败、API 错误等）。需要排查。
+- **uncertain**：判定结果存在歧义，可能需要人工复核。
 
-**Design exit criteria first:** Before writing judgment logic for a rule, define the exit conditions: what constitutes pass, what constitutes fail, what triggers escalation to human, how to handle empty/missing values, what value ranges are valid. Explicit exit criteria prevent ambiguous or inconsistent judgment.
+**先设计退出条件：** 在为一条规则编写判定逻辑前，先把退出条件定义清楚：什么算 pass、什么算 fail、什么情况下需要升级到人工、空值/缺失值如何处理、合法的取值范围是什么。显式的退出条件能避免判定模糊或前后不一致，也方便后续在进化循环中复盘判定逻辑的盲区。
 
-**Prompt design:** Design prompts for what you want, not against what you don't want. "Don't include reasoning" is less reliable than extracting the verdict from structured output in postprocessing. Use output filtering instead of prompt negation.
+**Prompt 设计：** 提示词要正向描述你想要什么，而不是反向描述你不想要什么。"不要包含推理过程"远不如在结构化输出里抽取判定结果可靠。模型对否定指令的遵循度普遍偏低，不如直接约束输出字段、再用后处理过滤把多余内容去掉。
 
-**Comments:**
-- Required only when result is `fail`. Skip for `pass` unless the developer user specifically requests pass comments.
-- Be concise and factual: "Capital adequacy ratio is 7.2%, below the regulatory minimum of 8.0%."
-- Do not editorialize: not "This is a serious violation that could result in penalties." Just state the facts.
-- Include the extracted value and the expected value/condition for context.
+**Comment 写法：**
+- 仅在 result 为 `fail` 时必须填写。`pass` 时不写，除非开发者用户明确要求记录通过项的说明。
+- 简洁、陈述事实："资本充足率为 7.2%，低于 8.0% 的监管最低要求。"
+- 不做评论性发挥：不要写"这是严重违规，可能招致处罚"。只陈述事实即可。
+- 在 comment 中给出抽取值和期望值/条件，便于读者理解上下文。
 
-### Lightweight Annotation Markup
+### 轻量标注语法
 
-For human review, token-efficient logging, and clean diff comparisons, results can also be expressed in compact text markup:
+为了便于人工复核、节省日志 token、做干净的 diff 比对，结果也可以用紧凑的文本标注形式表达：
 
 ```
 [PASS] capital_adequacy <- 12.5% (>= 8.0%) | conf:0.95 | src:p3-s2
@@ -65,19 +65,33 @@ For human review, token-efficient logging, and clean diff comparisons, results c
 [MISSING] collateral_value | conf:0.60 | note:Collateral valuation not found in document
 ```
 
-This format is losslessly convertible to and from the JSON format above. Use it when presenting results to the developer user for quick review, logging to evolution iteration summaries where token economy matters, or computing diffs between verification runs. See `references/output-format.md` for the full specification and conversion rules.
+这一格式与上面的 JSON 格式可无损互转。在以下场景使用：向开发者用户展示结果以便快速过目、写入进化迭代摘要等对 token 经济敏感的日志、在多次核查运行之间计算 diff 以发现回归。完整规范和转换规则参见 `references/output-format.md`。
 
-## Judgment Ordering
+## 判定执行顺序
 
-Some rules depend on the results of other rules:
-- Rule B might only apply if Rule A passes. "If the borrower is a new customer (Rule A), then additional documentation is required (Rule B)."
-- Rule C might use a value computed by Rule A. "The risk-weighted capital ratio (Rule A) determines the required reserve level (Rule C)."
+部分规则会依赖其他规则的结果：
+- 规则 B 可能只在规则 A 通过时才适用。"如果借款人是新客户（规则 A），则需要额外的文件资料（规则 B）。"
+- 规则 C 可能要复用规则 A 计算出的数值。"风险加权资本充足率（规则 A）决定了所需的准备金水平（规则 C）。"
 
-Map these dependencies in the rule catalog. Execute rules in dependency order. Pass upstream results as context to downstream rules.
+把这类依赖关系登记在规则目录中，最好以显式的依赖图形式维护。按依赖顺序执行规则，把上游规则的结果作为上下文传给下游规则，避免下游规则在缺少前置真值时拿到错误的输入。
 
-## Handling Edge Cases
+## 边界情况处理
 
-- **Null extraction**: The entity was not found. Default to `missing`, not `fail`. A missing value is an extraction problem, not a compliance problem.
-- **Multiple values**: The document contains the entity in multiple places with different values. Flag as `uncertain`. Report all found values.
-- **Conditional rules**: "If the loan exceeds 1M, then collateral is required." Check the condition before applying the rule. If the condition is not met, the rule does not apply — result is `pass` (or `not_applicable` if you add that category).
-- **Negative results**: Some rules check for absence. "The document must NOT contain guarantees to related parties." Searching for absence is harder than searching for presence. Be thorough in the search, then be confident in the negative.
+- **抽取为空**：实体未找到。默认归为 `missing`，而不是 `fail`。值缺失属于抽取问题，不是合规问题。
+- **多值情况**：文档在多处出现同一实体，但取值不一致。标记为 `uncertain`，并把所有找到的值连同各自的位置都报出来，便于人工复核时定位差异源头。
+- **条件规则**："如果贷款金额超过 100 万，则必须有担保。"先核查条件再套用规则。条件不成立时规则不适用——结果记为 `pass`（如果你额外引入了 `not_applicable` 类别，也可以使用）。
+- **否定型规则**：有些规则核查的是"不存在"。"文档中不得存在向关联方提供的担保。"搜索"不存在"比搜索"存在"难，因为要先证伪所有可能的命中位置才能下结论。先把搜索做彻底，再对否定结论保持信心。
+
+## 跨文档的置信度阈值一致性
+
+对一条要跨多文档判定的规则（常见情况），**"通过"的置信度阈值必须在所有文档上保持一致**。一条在文档 A 上要求 0.85 置信度才能通过、在文档 B 上只要 0.75 的规则，其实是两条规则伪装成了一条。
+
+当 worker LLM 当判官时，把阈值写在 prompt 里或者写在后处理里，不要 "让 LLM 自己每次决定"。LLM 调用之间的随机性意味着每一次调用都会落到分布上的某个点；你的工作是把分布必须越过的那条线划出来。
+
+两种落实方式：
+- **写在 prompt 里**：明确写"只有置信度高于阈值才输出 PASS"。便宜，但易受 LLM 多次调用之间漂移影响。
+- **写在后处理里**：让 LLM 分别输出 verdict 和 confidence，再用一小段 Python wrapper 应用阈值。更可靠，引擎看到的是代码层面的阈值，不是 prompt 文本。
+
+对有稳定模式的规则（格式、存在性核查），优先用后处理。对主观判断（充分性、完整性），prompt 层面的阈值更好写，但值得审计 —— 抽样一个批次看 LLM 有没有遵守那条线。
+
+`confidence-system` skill 描述了置信度怎么从多个信号合成；本节讨论的是怎么把它在同一规则的不同文档之间一致地应用。

package/template/skills/zh/compliance-judgment/references/output-format.md

@@ -1,48 +1,48 @@
-# Lightweight Output Format Specification
+# 轻量输出格式规范
 
-This document defines the compact text markup format for verification results, its grammar, JSON conversion rules, and edge case handling.
+本文档定义核查结果的紧凑文本标注格式、其语法、JSON 转换规则以及边界情况处理。
 
-## Grammar
+## 语法
 
 ```
 [RESULT] field_name <- value (constraint) | conf:score | src:location | note:text
 ```
 
-| Component | Required | Format | Description | Example |
+| 组成 | 是否必填 | 格式 | 说明 | 示例 |
 |-----------|----------|--------|-------------|---------|
-| `[RESULT]` | Yes | One of: PASS, FAIL, MISSING, ERROR, UNCERTAIN | The judgment outcome. | `[FAIL]` |
-| `field_name` | Yes | snake_case identifier | The rule or field being checked. | `capital_adequacy` |
-| `<- value` | No (omit for MISSING) | Free text, no pipes | The extracted value from the document. | `<- 12.5%` |
-| `(constraint)` | No (omit if no constraint) | Parenthesized expression | The expected value or condition. | `(>= 8.0%)` |
-| `conf:score` | Yes | Decimal 0.00-1.00 | Confidence score of the judgment. | `conf:0.95` |
-| `src:location` | No | Page-section reference or trace ID prefix | Source location in the document. | `src:p3-s2` |
-| `note:text` | No | Free text to end of line | Human-readable comment. | `note:Signing overdue by 45 days` |
+| `[RESULT]` | 是 | 取值之一：PASS、FAIL、MISSING、ERROR、UNCERTAIN | 判定结果。 | `[FAIL]` |
+| `field_name` | 是 | snake_case 标识符 | 被核查的规则或字段。 | `capital_adequacy` |
+| `<- value` | 否（MISSING 时省略） | 自由文本，不含竖线 | 从文档中抽取出的值。 | `<- 12.5%` |
+| `(constraint)` | 否（无约束时省略） | 括号表达式 | 期望值或条件。 | `(>= 8.0%)` |
+| `conf:score` | 是 | 0.00-1.00 的小数 | 判定的置信度分数。 | `conf:0.95` |
+| `src:location` | 否 | 页-节引用或 trace ID 前缀 | 文档中的来源位置。 | `src:p3-s2` |
+| `note:text` | 否 | 至行末的自由文本 | 人类可读的注释。 | `note:Signing overdue by 45 days` |
 
-Components after `field_name` are separated by ` | ` (space-pipe-space). The `<- value` and `(constraint)` components appear before the first pipe, space-separated.
+`field_name` 之后的各个组成部分以 ` | `（空格-竖线-空格）分隔。`<- value` 和 `(constraint)` 出现在第一个竖线之前，彼此以空格分隔。
 
-## Field Definitions
+## 字段定义
 
-### Result Values
+### 结果取值
 
-| Value | Meaning | When to Use |
+| 取值 | 含义 | 使用时机 |
 |-------|---------|-------------|
-| `PASS` | Entity complies with the rule. | Deterministic or semantic check confirms compliance. |
-| `FAIL` | Entity does not comply. | Clear non-compliance detected. Note is strongly recommended. |
-| `MISSING` | Entity not found in document. | Extraction could not locate the required field. |
-| `ERROR` | Processing failure. | Parsing error, API timeout, unexpected format. |
-| `UNCERTAIN` | Ambiguous judgment. | Borderline values, conflicting evidence, low confidence. |
+| `PASS` | 实体符合规则。 | 确定性检查或语义检查确认合规。 |
+| `FAIL` | 实体不符合规则。 | 明确检测到不合规。强烈建议填写 note。 |
+| `MISSING` | 文档中未找到该实体。 | 抽取过程无法定位到所需字段。 |
+| `ERROR` | 处理过程出错。 | 解析错误、API 超时、非预期格式。 |
+| `UNCERTAIN` | 判定存在歧义。 | 临界值、证据冲突、置信度偏低。 |
 
-### Confidence Score
+### 置信度分数
 
-A decimal between 0.00 and 1.00 representing the system's confidence in the result. For deterministic Python checks, confidence is typically 0.95-1.00. For LLM semantic judgments, confidence reflects the model's self-assessed certainty. Scores below the configured threshold in `.env` trigger human review.
+介于 0.00 与 1.00 之间的小数，表示系统对该结果的把握程度。对于确定性 Python 检查，置信度通常为 0.95-1.00。对于 LLM 语义判定，置信度反映模型自评的确定性。低于 `.env` 中配置阈值的分数会触发人工复核。
 
-### Source Location
+### 来源位置
 
-The `src:` component uses a compact reference format: `p{page}-s{section}`. Example: `src:p3-s2` means page 3, section 2. For trace ID integration, use the trace ID prefix: `src:R001-DOC042-P3-S2` (see Integration with Trace IDs below).
+`src:` 部分使用紧凑引用格式 `p{page}-s{section}`。示例：`src:p3-s2` 表示第 3 页第 2 节。如需与 trace ID 集成，使用 trace ID 前缀：`src:R001-DOC042-P3-S2`（详见下文"与 Trace ID 的集成"）。
 
-## JSON Conversion
+## JSON 转换
 
-### Markup to JSON
+### 标注 → JSON
 
 ```
 Input:  [FAIL] sign_date_gap <- 75d (<= 30d) | conf:0.90 | src:p1-s4 | note:Signing overdue by 45 days
@@ -59,31 +59,31 @@ Output:
 }
 ```
 
-Pseudocode:
-1. Parse `[RESULT]` -> lowercase -> `result` field.
-2. Parse next token -> `field` field.
-3. If `<-` follows, parse until `(` or `|` -> `extracted_value`.
-4. If `(...)` follows, parse contents -> `expected`.
-5. Split remaining by ` | `. For each segment:
-   - `conf:X` -> `confidence` (parse as float).
-   - `src:X` -> `source`.
-   - `note:X` -> `comment`.
+伪代码：
+1. 解析 `[RESULT]`，转小写，赋值给 `result` 字段。
+2. 解析下一个 token，赋值给 `field` 字段。
+3. 若后随 `<-`，解析到 `(` 或 `|` 为止，赋值给 `extracted_value`。
+4. 若后随 `(...)`，解析括号内容，赋值给 `expected`。
+5. 将剩余部分按 ` | ` 拆分。对每一段：
+   - `conf:X` → `confidence`（按浮点数解析）。
+   - `src:X` → `source`。
+   - `note:X` → `comment`。
 
-### JSON to Markup
+### JSON → 标注
 
-Pseudocode:
-1. `[` + uppercase(`result`) + `] ` + `field`.
-2. If `extracted_value` exists: ` <- ` + `extracted_value`.
-3. If `expected` exists: ` (` + `expected` + `)`.
-4. ` | conf:` + format(`confidence`, 2 decimal places).
-5. If `source` exists: ` | src:` + `source`.
-6. If `comment` exists: ` | note:` + `comment`.
+伪代码：
+1. `[` + 大写(`result`) + `] ` + `field`。
+2. 若存在 `extracted_value`：` <- ` + `extracted_value`。
+3. 若存在 `expected`：` (` + `expected` + `)`。
+4. ` | conf:` + 格式化(`confidence`, 保留 2 位小数)。
+5. 若存在 `source`：` | src:` + `source`。
+6. 若存在 `comment`：` | note:` + `comment`。
 
-## Diff Example
+## Diff 示例
 
-Comparing two verification runs is where markup shines.
+对比两次核查运行，正是标注格式最能发挥优势的场景。
 
-**Markup diff** (clean, scannable):
+**标注 diff**（干净、易扫读）：
 ```
   [PASS] capital_adequacy <- 12.5% (>= 8.0%) | conf:0.95 | src:p3-s2
 - [PASS] sign_date_gap <- 28d (<= 30d) | conf:0.92 | src:p1-s4
@@ -91,7 +91,7 @@ Comparing two verification runs is where markup shines.
   [MISSING] collateral_value | conf:0.60 | note:Collateral valuation not found
 ```
 
-**JSON diff** (noisy, hard to scan):
+**JSON diff**（噪声大、难以扫读）：
 ```json
   {
     "field": "sign_date_gap",
@@ -108,44 +108,44 @@ Comparing two verification runs is where markup shines.
   }
 ```
 
-The markup diff communicates the same information in one changed line vs. five changed lines.
+同样的信息，标注 diff 只需要一行变更，而 JSON diff 需要五行。
 
-## Edge Cases
+## 边界情况
 
-### Multi-Value Fields
-When a field has multiple extracted values (e.g., the same metric appears in two places with different values), separate values with semicolons:
+### 多值字段
+当一个字段抽取出多个值（例如同一个指标在两处出现且数值不一致），用分号分隔多个值：
 ```
 [UNCERTAIN] total_assets <- 1,234,567;1,234,590 | conf:0.50 | src:p3-s1;p7-s2 | note:Conflicting values found
 ```
 
-### Long Notes
-In markup, truncate notes longer than 80 characters with `...`. The full text is preserved in JSON. Example:
+### 长注释
+在标注格式中，超过 80 字符的 note 截断为 `...`。完整文本保留在 JSON 中。示例：
 ```
 [FAIL] risk_disclosure <- (see detail) | conf:0.85 | note:Missing discussion of liquidity risk, market risk, and operational ri...
 ```
 
-### Special Characters
-If a value or note contains the pipe character `|`, escape it with a backslash: `\|`. During JSON conversion, unescape back to `|`.
+### 特殊字符
+如果值或 note 中包含竖线 `|`，用反斜杠转义：`\|`。转换为 JSON 时再反转义回 `|`。
 
-### Fields with No Constraint
-Omit the parenthetical entirely:
+### 没有约束条件的字段
+完全省略括号部分：
 ```
 [MISSING] collateral_value | conf:0.60 | note:Collateral valuation not found in document
 ```
 
-### Fields with No Extracted Value
-Omit the `<-` component (common for MISSING and ERROR results):
+### 没有抽取值的字段
+省略 `<-` 部分（在 MISSING 和 ERROR 结果中很常见）：
 ```
 [ERROR] capital_adequacy | conf:0.00 | note:PDF parsing failed on page 3
 ```
 
-## Integration with Trace IDs
+## 与 Trace ID 的集成
 
-The `src:` component can encode trace ID prefixes, linking each result line to the full trace ID defined by `version-control`. Use the trace ID format directly:
+`src:` 部分可以编码 trace ID 前缀，将每一行结果与 `version-control` 定义的完整 trace ID 关联。直接采用 trace ID 格式即可：
 
 ```
 [PASS] capital_adequacy <- 12.5% (>= 8.0%) | conf:0.95 | src:R001-DOC042-P3-S2
 [FAIL] sign_date_gap <- 75d (<= 30d) | conf:0.90 | src:R003-DOC042-P1-S4 | note:Signing overdue by 45 days
 ```
 
-When converting to JSON, the `src:` value maps to the `trace_id` field in the full result object. The character range (`C{start}:{end}`) can be appended when full precision is needed: `src:R001-DOC042-P3-S2-C120:180`.
+转换为 JSON 时，`src:` 的值映射为完整结果对象中的 `trace_id` 字段。当需要更高精度时，可在末尾追加字符范围 (`C{start}:{end}`)：`src:R001-DOC042-P3-S2-C120:180`。

package/template/skills/zh/confidence-system/SKILL.md

@@ -67,22 +67,47 @@ description: Design and calibrate confidence scoring for extraction and verifica
 - **近似匹配**：文档与某个边缘案例有相似特征但未完全匹配 → 略微降低置信度。
 - **无匹配**：正常文档 → 不调整。
 
+### 信号五：格式模式吻合度
+
+抽取出来的值是否符合该规则隐含的"可正则化"格式？很多字段都有可识别的形状 —— 电话号、身份证号、日期、金额、监管编码 —— 都能用正则便宜地校验一遍，独立于 LLM 自己对结果的信心。
+
+- 值匹配预期的格式模式：正信号。
+- 值违反格式模式（比如电话字段里出现字母）：强负信号，常是幻觉的指示。
+- 字段没有适用的格式模式：中性。
+
+这能抓住一种常见失败：LLM 正确定位了"值在哪里"但把格式弄错了（少一位数、漏国家码、返回了"详见附录"之类的占位词）。
+
+### 信号六：统计离群
+
+对数值类字段，这个值是否远离其他文档中同字段的典型范围？
+
+- 在均值的 1 个标准差内：中性 / 轻微正向。
+- 2–3 个标准差：轻微负向。
+- 超出 3 个标准差，或落在领域上不可能的区间：强负信号 —— 经常是单位错误（元 vs. 万元）、小数点错位、或多/少一位的幻觉。
+
+对金额、百分比、比率类字段尤其有用。参考区间从 QC 已确认的历史数据计算得出，周期性刷新即可。对分类字段，对应做法是"值不在已观测的值集合内" —— 见到新值就送审。
+
 ## 信号组合
 
-用加权平均组合多个信号：
+把上面的信号合成单个置信度分数。常用形式是加权求和：
 
 ```
-confidence = w1 × method_prior + w2 × source_match + w3 × historical_accuracy + w4 × corner_case_adj
+confidence = w_method   × method_prior
+           + w_source   × source_match
+           + w_history  × historical_accuracy
+           + w_corner   × corner_case_adj
+           + w_format   × format_conformance
+           + w_outlier  × outlier_check
 ```
 
-### 初始权重建议
+权重怎么定 **是你自己针对每条规则、每个项目要做的判断**。下面是几条定向原则，不是规定值：
+
+- 历史准确率在有数据之后是最有预测力的信号 —— 跑了几轮 QC 后该加大权重。
+- 方法先验和源文本匹配始终可用 —— 在历史数据还没有的早期，它们撑着场子。
+- 格式吻合度和统计离群信号不依赖 LLM —— LLM 过度自信时它们还在工作，这正是你需要它们的时候。
+- 边缘案例调整的权重通常较小，但一旦匹配到已知边缘案例就要果断生效。
 
-| 信号 | 权重 | 说明 |
-|-----|------|------|
-| w1（方法先验） | 0.25 | 基础信号，始终可用 |
-| w2（源文本匹配） | 0.25 | 反幻觉信号，始终可用 |
-| w3（历史准确率） | 0.35 | 最重要的信号，但需要数据积累 |
-| w4（边缘案例距离） | 0.15 | 辅助信号 |
+历史数据还没攒起来时，把 w_history 的权重重新分配给其他信号。最合适本条规则、本套语料的权重会在校准循环里慢慢显形 —— 那是下一节描述的过程。
 
 ### 历史数据不可用时的处理