kc-beta 0.1.0

package/template/skills/zh/meta/tree-processing/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: tree-processing
+description: Build hierarchical document trees and navigate to specific chapters or sections required by verification rules. Use when a rule targets a specific part of a document, when documents are too long for a single LLM context window, or when you need to find where a specific entity lives within a large document. Implements the "onion peeler" approach for chunking. Also use for documents over 100 pages where full-document processing is impractical.
+---
+
+# 文档树处理
+
+绝大多数核查规则不需要整份文档。它们需要的是一个特定的章节、一张特定的表格、一段特定的披露。文档树就是你在大型文档中精准定位的地图。
+
+## 为什么需要文档树
+
+两个原因：
+
+1. **规则有作用域。** "第五章风险披露中应包含……"——你需要找到第五章，而不是通读 800 页年报。规则指向文档的特定位置，你的提取和判定也必须在这个位置上进行。
+
+2. **Worker LLM（执行模型）有上下文限制。** 一个 16K-32K 上下文窗口放不下一份完整的银行年报。你必须把内容缩窄到相关章节，才能喂给 Worker LLM。
+
+文档树同时解决这两个问题：它告诉你内容在哪里，让你只提取需要的部分。
+
+## 构建文档树
+
+### 第一步：发现文档结构
+
+在构建解析器之前，先浏览若干样本文档，找出结构规律。关注以下模式：
+
+- **标题格式**：
+  - 中文监管文档常见：`第一章`、`第二章`……`第一节`、`第二节`……
+  - 中文金融报告常见：`一、`、`二、`……`（一）`、`（二）`……`1.`、`2.`……
+  - 英文文档：`Chapter X`、`Part X`、`Section X.X`
+  - 编号体系：`1.1.2`、`Article 3`、`（a）（i）`
+- **视觉标记**：加粗文本、字号变大、分页符、横线分隔。这些在解析后的文本中可能表现为空行或特殊格式。
+- **目录（TOC）**：大多数正式金融文档都有目录。目录就是文档自己提供的树结构，包含标题和页码。
+
+在这一步多花时间。你发现的模式决定了后续的解析器是一个简单的正则表达式还是一个复杂的解析流程。
+
+### 第二步：选择解析器
+
+**如果模式一致**（监管文档通常如此）：
+
+用正则表达式构建分割器。金融文档中常见的中文标题模式：
+
+```python
+# 章标题：第一章、第二章……
+r'^第[一二三四五六七八九十百千]+章\s'
+
+# 节标题：第一节、第二节……
+r'^第[一二三四五六七八九十百千]+节\s'
+
+# 编号标题：一、二、三……
+r'^[一二三四五六七八九十]+、'
+
+# 子编号：（一）（二）（三）……
+r'^（[一二三四五六七八九十]+）'
+
+# 数字编号：1.1、1.2.3……
+r'^\d+\.\d+(\.\d+)*\s'
+```
+
+正则分割器速度快、结果确定、可靠性高。能用正则就用正则。
+
+**如果模式不一致或缺失**：
+
+使用 LLM 辅助的楔入式分割（参见 `rule-extraction/references/chunking-strategies.md`，其中详述了滚动上下文窗口、K-token 引用、Levenshtein 模糊匹配等完整算法）。这种方法速度慢、消耗 API 调用，但能处理结构不清晰的文档。滚动窗口机制意味着即使非常大的无结构叶节点也可以增量分块。
+
+**如果文档有目录**：
+
+优先解析目录。目录直接给出了树结构和页码，省去了你自己构建的工作：
+- 从目录中提取标题文本、层级关系、页码。
+- 用目录得到的结构去分割文档正文。
+- 验证目录与正文是否一致（偶尔会有目录与实际内容不符的情况）。
+
+### 第三步：构建树
+
+文档树是一个简单的嵌套结构：
+
+```
+年度报告
+├── 第一章 公司概况（第1-20页）
+│   ├── 第一节 基本信息
+│   └── 第二节 主要业务
+├── 第二章 财务数据（第21-80页）
+│   ├── 第一节 主要财务指标
+│   │   ├── 一、资本充足率
+│   │   └── 二、资产质量指标
+│   ├── 第二节 资产负债表
+│   └── 第三节 利润表
+├── 第三章 风险管理（第81-150页）
+│   ├── 第一节 信用风险
+│   ├── 第二节 市场风险
+│   └── 第三节 操作风险
+└── 附录
+    ├── 附录一 关联交易明细
+    └── 附录二 监管指标计算说明
+```
+
+每个节点存储：
+- **标题文本**：节点的标题。
+- **层级**：在树中的深度（章=1，节=2，条目=3……）。
+- **位置**：在解析文本中的起止位置（字符偏移或行号）。
+- **内容大小**：该节点内容的 token 数或字符数。这决定了能否直接喂给 Worker LLM。
+
+### 第四步：使用树
+
+当规则说"检查风险披露章节"：
+
+1. **搜索树节点**：将规则的作用域描述与节点标题匹配。
+   - 精确匹配："第三章"→ 找到标题为"第三章 风险管理"的节点。
+   - 语义匹配："风险披露相关内容"→ 需要模糊匹配或 LLM 分类，找到内容与风险披露相关的节点。
+   - 关键词匹配：对标题做关键词搜索，如"风险"+"披露"。
+
+2. **提取内容**：获取该节点（及其子节点）的完整内容。
+
+3. **检查大小**：内容是否能放进 Worker LLM 的上下文窗口？
+   - 能放下 → 直接使用。
+   - 放不下 → 下探到子节点，找到规则所需的具体小节。
+
+## 洋葱剥皮法
+
+这是处理大型文档的核心策略：像剥洋葱一样，一层一层缩小范围，仅在超出大小限制时才进行下一层分割。
+
+### 具体操作
+
+1. **最外层**：整份文档。如果文档在上下文窗口内（罕见），直接使用。
+2. **第一层剥离**：按最高级标题（章）分割。大多数章节在 16K-32K 范围内。
+3. **第二层剥离**：如果某章仍然过大，按次级标题（节）分割。
+4. **继续剥离**：必要时继续，但通常两到三层就够了。
+
+关键原则：**不要预先把文档切碎**。只在某个节点太大时才继续分割。过度分割会丢失上下文——一个段落脱离了它所在的章节，可能会被误解。
+
+### 保留上下文链
+
+无论下探到多深，始终在提取的内容前附加父节点链：
+
+```
+[文档标题] > 第二章 财务数据 > 第一节 主要财务指标 > 一、资本充足率
+
+（以下是该节内容）
+```
+
+这让 Worker LLM 知道当前内容在文档中的位置，避免脱离上下文的误判。
+
+## 中文文档结构模式
+
+不同类型的金融文档有不同的结构习惯：
+
+### 监管文件（银保监会、证监会发文）
+```
+第一章 总则
+  第一条、第二条、第三条……
+第二章 ……
+  第X条……
+附则
+```
+特点：条文编号连续，跨章不重置。
+
+### 上市公司年度报告
+```
+第一节 重要提示、目录和释义
+第二节 公司简介和主要财务指标
+第三节 管理层讨论与分析
+……
+第十二节 备查文件目录
+```
+特点：以"节"为最高级别，内部用"一、二、三"编号。
+
+### 银行资本充足率报告
+```
+一、核心概况
+二、资本充足率
+  （一）资本构成
+  （二）风险加权资产
+三、杠杆率
+……
+```
+特点：用中文数字编号，层级较浅。
+
+### 贷款合同
+```
+第一条 借款金额
+第二条 借款期限
+第三条 借款利率
+……
+第X条 违约责任
+```
+特点：扁平结构，每条独立。
+
+根据文档类型选择对应的正则模式。
+
+## 全文→章节→实体 的渐窄管道
+
+这是从文档到可核查数据的标准漏斗：
+
+1. **全文层**：用文档树了解整体结构。知道什么在哪里。
+2. **章节层**：导航到规则指向的具体章节。提取其内容。
+3. **实体层**：在章节内容中，使用 `entity-extraction` 技能的方法提取具体实体（数字、日期、条款文本等）。
+
+对于 16K-32K 上下文窗口的 Worker LLM：
+- 章节内容 + 提取提示词 + 输出格式说明 = 必须在上下文窗口内。
+- 留出足够空间给模型的回复（通常 1K-2K token）。
+- 如果章节仍然过大，继续在树中下探。
+
+## 上下文窗口管理
+
+为 Worker LLM 设计树导航时，做好 token 预算：
+
+```
+总上下文窗口：32,768 tokens
+- 系统提示词：   ~2,000 tokens
+- 提取指令：     ~500 tokens
+- 输出格式说明：  ~300 tokens
+- 示例（可选）：  ~500 tokens
+- 回复预留：     ~2,000 tokens
+---
+可用于文档内容：~27,468 tokens（约 18,000-20,000 中文字符）
+```
+
+中文 token 密度约 1.5 字符/token（取决于分词器）。根据实际使用的模型调整估算。
+
+## 缓存和复用
+
+文档树构建一次，所有规则共享使用：
+
+- 将树结构保存为 JSON 文件，存放在解析后文档旁边（如 `report.tree.json`）。
+- 多条规则可能需要同一文档的不同章节。每条规则通过树直接导航到其所需章节，无需重新解析。
+- 树结构文件应包含：节点标题、层级、起止位置、内容大小。不需要包含实际内容——内容从解析后的 markdown 文件中按位置提取。
+
+## 边缘情况
+
+- **扁平文档**：有些文档没有层级结构（如短篇通知、单页证明）。把整份文档视为一个节点。如超出上下文窗口，使用 LLM 辅助分块。
+- **深层嵌套**：部分法律文件嵌套达 6 层以上。构建所有层级，但对任一规则通常只需导航 2-3 层深。
+- **跨章节引用**："如第 1.2 节所定义"——提取时可能需要从多个树节点收集内容，合并后喂给 LLM。
+- **附录和附件**：经常包含关键表格和数据（关联交易明细、监管指标计算等）。将其作为顶层节点纳入树中，不要遗漏。
+- **目录与正文不一致**：偶尔目录列出的章节在正文中不存在（或反过来）。以正文为准，但记录差异。

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

@@ -0,0 +1,147 @@
+---
+name: bootstrap-workspace
+description: Initialize and configure a document verification workspace. Use when a developer user first opens this workspace, when .env needs configuration, or when the business scenario needs to be understood. Guides the coding agent through reading regulation documents, understanding the developer user's business context, configuring model tiers and thresholds, and establishing the working relationship. Covers initial conversation with developer user to scope the verification task, set expectations, and agree on checkpoints.
+---
+
+# 工作空间初始化与业务场景配置
+
+## 你的角色定位
+
+你现在承担的不是单一岗位的职责。在传统的单据核查项目中，通常需要业务分析师（BA）梳理法规条文、提炼核查逻辑，需要提示词工程师将业务逻辑转化为模型可执行的指令，需要QA工程师设计测试用例、回归验证。你一个人要把这三个角色的事都做了。
+
+因此，初始化阶段不要急于写代码。先像BA一样搞清楚业务，像提示词工程师一样评估技术可行性，像QA一样思考怎么验证。
+
+## 首次进入工作空间的动作序列
+
+### 第一步：阅读法规文件
+
+扫描 `Rules/` 目录下的所有文件。这些是业务法规、监管文件、内部制度等原始材料。阅读时关注以下要素：
+
+- 法规的适用范围（哪类单据、哪些业务场景）
+- 核查要求的粒度（字段级别、逻辑级别、交叉验证级别）
+- 是否存在条件分支（如：金额超过某阈值时需要额外核查）
+- 法规之间是否存在交叉引用或冲突
+- 时效性（是否有生效日期、过渡期条款）
+
+### 第二步：扫描样本文件
+
+检查 `Samples/` 目录。这些是开发者用户提供的单据样本，用于理解实际业务场景。注意：
+
+- 单据类型和格式（PDF、图片、结构化数据）
+- 字段分布和命名规律
+- 样本覆盖的业务场景是否充分
+- 是否包含正例（合规）和反例（违规）
+
+### 第三步：检查环境配置
+
+读取 `.env` 文件。如果不存在，后续需要引导开发者用户创建。如果已存在，检查各参数是否合理。
+
+## 与开发者用户的初始对话
+
+在动手之前，必须与开发者用户确认以下事项：
+
+### 核查范围界定
+
+- 本次核查覆盖哪些法规？是全量还是部分条款？
+- 针对哪些类型的单据？（发票、合同、报关单、银行回单等）
+- 核查目标是合规审查、风险排查，还是数据提取？
+
+### 规则粒度协商
+
+- 开发者用户期望的规则拆分粒度是什么？
+- 举例：「发票金额核查」是一条规则，还是要拆成「发票金额与合同金额一致性」「发票金额与付款金额一致性」两条规则？
+- 粒度越细，准确率越高，但开发和维护成本也越高
+
+### 期望值与检查点
+
+- 开发者用户对准确率的期望是多少？（建议初始目标 85%+，逐步优化到 95%+）
+- 哪些规则是高优先级的？（先做核心规则，再扩展边缘规则）
+- 约定检查点：每完成 N 条规则的技能编写后，暂停汇报进展
+
+## .env 参数配置指南
+
+以下是工作空间的核心配置参数：
+
+### 模型层级配置
+
+```
+TIER1_MODEL=         # 最强模型，用于复杂判断（如 claude-sonnet-4-20250514）
+TIER2_MODEL=         # 中等模型，用于结构化提取
+TIER3_MODEL=         # 轻量模型，用于格式校验和简单分类
+TIER4_MODEL=         # 最廉价模型，用于文本预处理
+```
+
+模型选择原则：从最便宜的开始尝试，只有当准确率不达标时才升级到更高层级。
+
+### 准确率阈值
+
+```
+SKILL_ACCURACY=0.90        # 技能（Skill）达到此准确率后方可蒸馏为工作流
+WORKFLOW_ACCURACY=0.85     # 工作流（Workflow）的最低可接受准确率
+```
+
+`SKILL_ACCURACY` 必须高于 `WORKFLOW_ACCURACY`，因为蒸馏过程必然有损耗。
+
+### 监控与迭代参数
+
+```
+MONITOR_FREQUENCY=mid      # 质量监控频率：high（全量）/ mid（抽样50%）/ low（抽样10%）
+MAX_ITERATIONS=10          # 单条规则的最大迭代轮次，防止无限循环
+```
+
+### API 配置
+
+```
+API_BASE_URL=              # LLM API 的基础地址（如 SiliconFlow）
+API_KEY=                   # API 密钥
+```
+
+## 工作空间目录结构搭建
+
+初始化时需要创建以下目录（如尚不存在）：
+
+```
+logs/                   # 所有测试、迭代、质控的日志
+  evolution/            # 演化循环日志
+  qc/                   # 质量监控日志
+workflows/              # 蒸馏后的生产工作流
+  prompts/              # 工作流使用的提示词模板
+rule-skills/            # 每条规则对应的技能文件夹
+versions.json           # 版本清单（工作空间根目录）
+```
+
+创建 `versions.json` 的初始内容：
+
+```json
+{
+  "workspace_version": "1.0.0",
+  "initialized_at": "<当前时间戳>",
+  "skills": {},
+  "workflows": {},
+  "last_updated": "<当前时间戳>"
+}
+```
+
+## 何时需要重新初始化
+
+以下情况需要重新运行本技能：
+
+- 法规文件发生重大更新（不是小修小补，而是新增法规或废止旧法规）
+- 业务场景发生根本变化（如从发票核查转为合同核查）
+- `.env` 中的模型配置发生变更（更换了 API 供应商或模型版本）
+- 开发者用户明确要求重置工作空间
+- 工作空间长时间未使用后重新启动（需要重新理解上下文）
+
+重新初始化时，不要删除已有的 `rule-skills/` 和 `workflows/`，而是先评估哪些可以保留、哪些需要更新。
+
+## 初始化完成的标志
+
+当以下条件全部满足时，初始化完成：
+
+1. `Rules/` 目录已阅读，规则范围已明确
+2. `Samples/` 目录已扫描，业务场景已理解
+3. `.env` 已配置完毕，参数合理
+4. 与开发者用户就范围、粒度、期望值达成一致
+5. 工作空间目录结构已创建
+6. `versions.json` 已初始化
+7. 可以开始进入规则提取阶段

package/template/skills/zh/meta-meta/dashboard-reporting/SKILL.md

@@ -0,0 +1,281 @@
+---
+name: dashboard-reporting
+description: Generate HTML dashboards for developer users to visualize verification results, system progress, and quality metrics. Use when a testing round completes, when production batches finish processing, when the developer user wants to see the system's status, or at any point where visual reporting would help communicate progress. Dashboards should be self-contained HTML files that can be opened by double-clicking. Also use when the developer user asks about results, accuracy, or system health.
+---
+
+# 可视化仪表盘生成
+
+## 仪表盘的定位
+
+仪表盘是开发者用户了解系统运行状态的唯一窗口。开发者用户不应该需要打开 JSON 文件、翻阅日志目录、或者向你询问「现在准确率多少了」。一切关键信息，打开仪表盘就能看到。
+
+仪表盘生成是一个服务性技能——在其他技能完成工作后，由你主动生成或由开发者用户按需要求生成。
+
+## 三类仪表盘
+
+### 一、核查结果仪表盘（Results Dashboard）
+
+展示某一批次或某一时间段的单据核查结果。
+
+#### 必须包含的内容
+
+**总览区域**：
+- 本批次处理的单据总数
+- 各规则的通过率、不通过率、无法核查率
+- 高置信度/中置信度/低置信度的分布
+
+**按规则明细**：
+- 每条规则的独立准确率
+- 每条规则最常见的不通过原因（Top 3）
+- 每条规则的平均置信度
+
+**失败案例清单**：
+- 判定为「不通过」的案例列表
+- 每个案例的关键字段摘要、不通过原因、置信度
+- 可按规则、按置信度、按不通过原因筛选
+
+**置信度分析**：
+- 置信度分布直方图
+- 低置信度案例的高亮标注
+- 置信度与实际准确率的校准分析（如有质控数据）
+
+### 二、系统进展仪表盘（Progress Dashboard）
+
+展示整个核查系统的建设进度，覆盖从规则提取到生产部署的全生命周期。
+
+#### 必须包含的内容
+
+**生命周期总览**：
+- 规则总数及各阶段分布（已提取、技能已编写、技能已测试、工作流已蒸馏、工作流已测试、已投产）
+- 用进度条或甘特图形式展示
+
+**演化循环时间线**：
+- 每条规则的迭代轮次和当前准确率
+- 从第一轮到最新一轮的准确率变化趋势
+- 标注关键事件（如「达到阈值」「触发回退」「开发者用户确认」）
+
+**阻塞事项**：
+- 达到 `MAX_ITERATIONS` 仍未达标的规则
+- 等待开发者用户确认的模糊事项
+- 缺少测试样本的规则
+
+### 三、质量监控仪表盘（Quality Dashboard）
+
+展示生产环境中的质量指标趋势。
+
+#### 必须包含的内容
+
+**准确率趋势**：
+- 每条规则的准确率随时间的变化曲线
+- 阈值线的标注（`WORKFLOW_ACCURACY`）
+- 低于阈值的时间段高亮
+
+**抽样率变化**：
+- 各规则当前的质控抽样比例
+- 抽样比例的变化历史（体现从全量到抽样的信心积累过程）
+
+**成本追踪**：
+- 每条规则的平均核查成本
+- 按模型层级的成本分布
+- 总成本趋势
+
+**异常警报**：
+- 准确率下降的规则（红色标注）
+- 置信度漂移的规则（黄色标注）
+- 成本异常的规则
+
+## 用户反馈收集
+
+每个仪表盘必须内置用户反馈机制，让用户可以直接在核查结果上报告错误和添加评论。用户反馈是系统中最有价值的数据来源，不是可选功能。
+
+### 开发者用户反馈
+
+开发者用户能看到完整的结果明细。他们的反馈界面应支持：
+- **字段级修正**：点击某个提取值，输入正确的值。
+- **结果覆盖**：将通过改为不通过（或反之），并附理由。
+- **规则重评估请求**：标记某条结果，要求用不同方式重新处理。
+- **自由评论**：对任何结果添加文本注释。
+
+### 终端用户反馈
+
+核查应用的终端用户看到的是简化结果。他们的反馈界面应支持：
+- **一键标记错误**：一次点击即可报告他们认为不正确的结果。
+- **添加评论**：简要文字说明他们认为哪里有误。
+- **严重程度**：这个错误的影响有多大？（严重 / 重要 / 轻微）
+
+### 反馈即基准真值
+
+用户报告的错误即基准真值。它们的优先级高于编程智能体的判断和 Worker LLM 的输出。反馈数据流转如下：
+
+1. 用户在仪表盘上提交反馈 → 存储为结构化记录。
+2. 记录格式：`{result_id, trace_id, reporter_role, feedback_type, original_result, corrected_value, comment, timestamp}`。
+3. 反馈记录作为已确认的失败案例，输入 `evolution-loop` 演化循环。
+4. 仪表盘展示反馈趋势：修正率随时间变化、最常被报告的问题、用户修正率最高的规则。
+
+例如：信贷审批场景中，业务人员发现某笔贷款的担保物估值被提取错误，一键标记后，该修正自动进入下一轮演化循环的失败案例池，驱动规则改进。
+
+反馈收集机制与仪表盘生成是一体的，不是独立功能。每个生成的 HTML 仪表盘都应包含反馈 UI，即使最初只是将反馈写入本地 JSON 文件，由编程智能体在下次迭代时读取。
+
+## 技术规范
+
+### 自包含 HTML
+
+仪表盘必须是单个 HTML 文件，不依赖任何外部资源：
+
+- CSS 内联（`<style>` 标签）
+- JavaScript 内联（`<script>` 标签）
+- 不引用任何 CDN 资源
+- 不需要启动任何服务器
+- 双击文件即可在浏览器中打开
+
+### 不依赖第三方库
+
+所有图表和可视化使用原生 HTML/CSS/JavaScript 实现：
+
+- 进度条：CSS `width` 百分比
+- 柱状图/条形图：CSS Flexbox 或 Grid + `div` 高度百分比
+- 折线图：SVG `<polyline>` 或 `<path>`
+- 饼图：SVG `<circle>` 的 `stroke-dasharray`
+- 表格：原生 `<table>` + CSS 样式
+
+不要引入 Chart.js、D3.js、ECharts 等库。保持零依赖。
+
+### 响应式布局
+
+仪表盘应在不同屏幕尺寸下可用：
+
+- 桌面端（1200px+）：多列布局
+- 平板端（768px - 1200px）：两列布局
+- 手机端（< 768px）：单列布局
+
+使用 CSS Media Query 实现响应式。
+
+### 深色/浅色模式
+
+支持系统级的深色/浅色模式切换：
+
+```css
+@media (prefers-color-scheme: dark) {
+  :root {
+    --bg-primary: #1a1a2e;
+    --bg-secondary: #16213e;
+    --text-primary: #e8e8e8;
+    --text-secondary: #a0a0a0;
+    --accent-green: #4ade80;
+    --accent-red: #f87171;
+    --accent-yellow: #fbbf24;
+  }
+}
+
+@media (prefers-color-scheme: light) {
+  :root {
+    --bg-primary: #ffffff;
+    --bg-secondary: #f3f4f6;
+    --text-primary: #1f2937;
+    --text-secondary: #6b7280;
+    --accent-green: #16a34a;
+    --accent-red: #dc2626;
+    --accent-yellow: #d97706;
+  }
+}
+```
+
+## 数据来源
+
+仪表盘的数据从以下位置读取（由生成脚本在生成时内嵌到 HTML 中）：
+
+| 数据类型 | 来源路径 |
+|---------|---------|
+| 核查结果 | `Output/*/results.json` |
+| 质控评审 | `logs/qc/reviews/*.json` |
+| 演化日志 | `logs/evolution/*/iteration_*.json` |
+| 版本信息 | `versions.json` |
+| 准确率趋势 | `logs/qc/trends.json` |
+| 规则目录 | `rule-catalog.json` |
+| 成本数据 | 从工作流日志中汇总 |
+
+数据以 JavaScript 变量的形式嵌入到 HTML 文件头部：
+
+```html
+<script>
+const DASHBOARD_DATA = {
+  generated_at: "2025-04-01T20:00:00Z",
+  batch_id: "BATCH-2025-04-01",
+  results: [...],
+  qc_reviews: [...],
+  trends: {...}
+};
+</script>
+```
+
+## 生成触发时机
+
+### 自动触发
+
+- 每轮测试完成后（演化循环中）→ 生成进展仪表盘
+- 每批次处理完成后 → 生成结果仪表盘
+- 每次质控评审完成后 → 更新质量监控仪表盘
+
+### 手动触发
+
+开发者用户随时可以要求生成仪表盘。常见的请求方式：
+- 「给我看一下现在的进展」
+- 「生成一下结果报告」
+- 「准确率怎么样了」
+
+无论请求如何措辞，都应生成对应类型的仪表盘。
+
+## 仪表盘文件命名与存放
+
+```
+dashboards/
+├── results_2025-04-01_batch01.html
+├── progress_2025-04-01.html
+├── quality_2025-04-01.html
+└── latest/
+    ├── results.html          # 最新结果仪表盘的软链接/副本
+    ├── progress.html         # 最新进展仪表盘的软链接/副本
+    └── quality.html          # 最新质量仪表盘的软链接/副本
+```
+
+`latest/` 目录下始终保留最新版本，方便开发者用户快速访问。
+
+## 设计原则
+
+### 先总后分
+
+仪表盘打开后，开发者用户首先看到的是一句话总结：
+
+```
+本批次共处理 50 份单据，综合准确率 92.3%，全部规则均达标。
+```
+
+或者：
+
+```
+⚠ 本批次 R003 规则准确率 (78%) 低于阈值 (85%)，已触发演化循环。
+```
+
+总结之后再展开细节。
+
+### 色彩编码
+
+- 绿色：达标、通过、正常
+- 黄色：接近阈值、需关注、中等置信度
+- 红色：低于阈值、不通过、异常
+
+### 可操作性
+
+仪表盘不只是展示数据，还应提供操作建议：
+
+- 「R003 建议重新运行演化循环」
+- 「R001 已连续 5 个批次达标，建议将抽样比例从 50% 降至 20%」
+- 「3 条模糊规则待确认，请查看详情」
+
+### 生成时间戳
+
+每个仪表盘底部显示生成时间，避免开发者用户看到过时的数据而不自知：
+
+```
+仪表盘生成时间：2025-04-01 20:00:00 | 数据范围：2025-04-01 批次 #01
+```