SKILL执行结果验证器
概述
对已执行 skill 的输出结果进行系统性验证，发现遗漏、错误、边界问题，并输出分层编号的验证报告。目标是替代人工逐项翻查，让用户可以用编号直接引用任何问题点。
核心原则：验证是独立的质控环节，不是对 skill 的辩护。发现问题就报告问题，不要粉饰。
初次使用：自动验证授权
用户首次调用本 skill 时，执行以下对话流程：
- 完成本次验证后，在报告末尾询问用户：
> 「是否希望以后所有其他 skill 执行完毕后，自动调用本验证器进行结果校验？」
- 提供选项：是（自动验证）/ 否（仅手动调用）
- 如果用户回答是：
- 检查用户的 SOUL.md 或全局偏好文件是否已包含自动验证规则
- 如果未包含，在 SOUL.md 的工作标准区域追加以下规则：
```
SKILL 执行后必须自动调用验证器验证。 当任何 skill 执行完成并产出文件（或修改了文件）后，在向用户报告完成之前，必须先加载 SKILL执行结果验证器 skill，按5个维度（输出完整性、内容准确性、逻辑一致性、规则符合性、边界与异常）对执行结果进行系统验证。验证通过后再报完成；发现问题则先报告再等待用户指示。以下情况可跳过验证：① skill 仅为查询/信息展示，无任何文件产出；② 正在执行的 skill 就是验证器本身（避免死循环）；③ 用户明确指示"不用验证"。
```
- 告知用户：SOUL.md 已更新，下次 skill 执行后将自动验证
- 如果用户回答否：保持手动触发模式，不做任何修改
验证流程
第1步：明确验证上下文
收集以下信息（从对话上下文或用户提供）：
- 被验证的 skill 名称
- skill 执行的任务描述（做了什么）
- 主要输出物（文件路径、文件类型、数量）
- 预期结果描述（用户的期望或 skill 文档中的说明）
- 已知约束或规则（如格式要求、字段规范、覆盖范围）
如果上下文不足，先问清楚再验证，不要凭猜测展开检查。
第2步：分层验证检查
按以下 5 个维度逐一核查，记录每个发现：
2.1 输出完整性
- 输出文件/目录是否存在？路径是否正确？
- 文件数量是否符合预期？（若有批量操作，全部核查或抽样5%以上）
- 文件大小是否合理？（0字节 = 空文件问题；异常大/小需标注）
- 文件格式/扩展名是否正确？
- 文件能否正常打开/解析？是否存在损坏？（必要时用对应工具打开确认）
工具：使用文件系统检查工具（列出目录、读取文件元信息、尝试打开文件）。
2.2 内容准确性
- 关键字段（标题、日期、金额、编号、名称等）是否正确填写？
- 替换/填充操作是否到位？有无漏改或错改？
- 内容是否通顺、完整？有无乱码、重复段落、明显语病？
- 计算结果验证：涉及数值计算的（合计、小计、百分比、平均值等），必须抽验至少1项计算公式是否准确。例如：合计行是否等于各明细行相加、百分比是否合理。
- 限值引用验证：涉及达标判定、阈值对比、标准限值时，必须核对引用值是否与原文一致，引用单位是否正确，判定结论是否推导正确。例如：限值 70mg/m³ 写成 70g/m³ → 数量级错误。
- 数值精确度：小数位数、单位、千分位分隔符是否与原始数据一致，有无精度丢失或四舍五入错误。
- 数据来源权威性：引用数据是否有明确来源？来源是否为权威渠道（官方机构网站、行业标准数据库、原始数据发布方等）？引用二手资料是否标注了间接引用？
工具：读取文件内容，搜索关键字段，执行算式验算或差异比对。
2.3 逻辑一致性
- 交叉引用：文档内引用的章节号、表号、图号、附录编号是否真实存在？引用的外部文件路径/文件名是否正确？引用的内容是否与原文一致？
- 分类合理性：输出物中的分类是否合理？有无类别重叠、遗漏或归属错误？例如：数据分类、条目归类、文件分类。
- 时间自洽：多个时间字段之间的先后关系是否合理？例如：结束时间 ≥ 开始时间、审核时间 ≥ 提交时间、有效期起始不晚于终止。时间不能倒流。
- 汇总与明细一致：汇总表中数据是否与明细表一致？不同表格/文件之间同名统计量是否一致？总数 = 各项之和？
- 语义一致性：同一事物在不同位置是否用词一致？术语使用是否前后统一？有无矛盾描述？
2.4 规则符合性
- 是否满足被验证 skill 明确要求的约束（如编号规则、命名规范、必填字段）？
- 有无违反用户项目中的约定（如命名风格、文件组织规则、数据格式约定）？
- 若涉及外部引用（法律法规、标准、规范等），来源是否权威且版本现行？
- 格式合规：
- 文档：页码、页眉页脚、目录、章节层级是否正确？字体字号是否统一？封面/模版是否合规？表格标题和图题位置是否规范？
- 表格：表头是否固定？冻结窗格是否设置？打印区域/分页是否合理？列宽是否自适应？
- 编号：章节编号、条目编号是否连续、不跳号、不重复？层级缩进是否一致？
2.5 边界与异常
- 空值/null 字段是否被正确处理？是否出现 "N/A" "null" "undefined" 等未处理占位符？
- 特殊字符（引号、斜杠、括号、标签、转义符等）是否导致格式异常或内容显示错误？
- 截断检查：长文本、长数字、长路径是否被截断？表格列宽不足导致数据显示不全？打印/导出后内容是否缺失？PDF 页面溢出是否导致内容丢失？
- 极值/异常值：数值字段是否出现异常大/小的数值？日期是否出现默认值（如 1900-01-01）？百分比是否超过 100% 或出现负数？
- 批量操作中是否有漏处理的文件？文件数 / 行数 / 条目数与预期是否一致？
- 编码问题：多字节字符（中文、日文等）是否出现乱码？文件 BOM 头是否正确？换行符是否一致（不混用不同平台的换行符）？
- 是否存在"应该警告但没有警告"的情况？
第3步：生成验证报告
验证结束后，输出结构化报告，格式如下：
# Skill 验证报告
**被验证 skill**：<skill 名称>
**验证时间**：<当前时间>
**总体结论**：✅ 通过 / ⚠️ 有问题需关注 / ❌ 存在严重错误
---
## 1. 输出完整性
1.1 [描述] — ✅/⚠️/❌
1.2 ...
## 2. 内容准确性
2.1 [描述] — ✅/⚠️/❌
...
## 3. 逻辑一致性
3.1 [描述] — ✅/⚠️/❌
...
## 4. 规则符合性
4.1 ...
## 5. 边界与异常
5.1 ...
---
## 6. 问题汇总
（仅列出 ⚠️ 和 ❌ 项）
6.1 [严重程度] [位置/文件] 问题描述 → 建议处理方式
...
## 7. 建议
（可选，总体改进建议或 skill 本身的优化点）
第4步：后续行动
- 若发现 ❌ 严重问题：明确告知用户，等待指示后再决定是否重跑 skill。
- 若发现 ⚠️ 轻微问题：列出问题 + 建议修复方式，询问是否需要立即处理。
- 若全部 ✅：报告通过，简短确认即可，不堆废话。
- 用户首次使用后，按「初次使用：自动验证授权」流程询问是否开启自动验证。
使用示例
场景 1：文件批量处理 skill 执行后
> "批量改名跑完了，帮我验证一下"
→ 加载本验证器，收集被处理的文件列表，逐项核查文件名是否符合命名规范，抽读文件内容确认替换正确。
场景 2：数据整理 skill 生成表格后
> "生成的表格对吗"
→ 读取表格文件，核查关键字段数据，比对原始数据量与输出行数是否一致，抽查计算公式是否正确。
场景 3：文档生成 skill 输出文档后
> "这份文档有没有问题"
→ 读取文档内容，检查格式、必填字段、内容完整性、交叉引用是否有效，与 skill 的预期输出对比。
场景 4：代码生成 skill 产出代码后
> "生成的代码检查一下"
→ 检查文件是否生成到位、代码结构是否完整、关键逻辑是否正确、有无语法错误或缺失的依赖引用。
场景 5：数据分析 skill 输出报告后
> "分析报告验证一下"
→ 核验数据来源是否标注、统计口径是否一致、图表数据与文字描述是否匹配、结论推导是否合理。
验证严格度说明
| 严重程度 | 标记 | 含义 |
|----------|------|------|
| 严重错误 | ❌ | 输出错误/缺失，必须处理 |
| 轻微问题 | ⚠️ | 有偏差但不影响主要功能，建议处理 |
| 通过 | ✅ | 符合预期 |
注意事项
- 验证是质控，不是找茬——发现问题是帮助，不是否定。
- 不要自主静默修复问题，先报告，让用户决定。
- 如果被验证的 skill 本身有缺陷（流程设计问题），在报告第7节中指出，但不擅自修改 skill 文件。
- 批量操作抽样比例：文件总数 ≤10 全查；11-50 抽30%；51+ 抽10%但不少于10个。
- 验证器自身不触发验证（避免死循环）。