verify-data

name	verify-data
description	数据 deliverable 写入前的三角对账（本地 DB + ≥2 独立网源），消灭"Wuxing 错配 Jiaxing / xlsx 没对公报 / 作者顺序错"那类因 cross-check 缺失被退回的事件。用户说"/verify-data X" / "校核 X" / "三角对账 X" / "X 对不对"，或自己在写 deliverable（报告 / xlsx / 简历 / 论文 / 法律意见）前需要落入具体声明时触发。

verify-data · 数据 deliverable 三角对账协议

核心理念：deliverable 里每一条具体声明（数字 / 人名 / 日期 / 项目 / 引用）写入前都必须通过本地 DB + ≥2 独立网源的三角对账。任何一边对不上 → STOP，不允许擅自挑一源继续。

与铁律的关系：本 skill 是全局 ~/.claude/CLAUDE.md 「执行铁律 #11 实测验证」+ 「#12 主动调研」在数据维度的具体执行手册。bug 几乎全来自对"我记得 / 大概是 / 看着像"的错误假设（Karpathy K1 数据先看 5 条）。

---

何时触发

用户说以下任一：

• /verify-data <声明>
• "校核 X / 核对一下 X / 这个数对不对"
• "三角对账 / cross-check / 验一下"
• "X 银行 / X 项目 / X 公司 是不是 Y"

自动触发（不等用户说）：自己在写以下 deliverable 且首次落入一条具体声明时：

• 学术报告 / 论文（任何引用 / 数据 / 作者）
• xlsx 数据汇总（任何政府公报 / 年报数字）
• 简历 / 求职材料（任何公司名 / 职位 / 日期 / 项目）
• 法律意见 / 合规文件（任何条款编号 / 案例编号）
• 投资笔记（任何标的代码 / 价格 / 持仓数据）
• 水务 / 工程报告（任何用水量 / 公司架构 / 项目负责人）

不触发：用户对话里的随口提及（"我记得 Jiaxing 大概..."）；非 deliverable 的探索性讨论。

---

执行编排

输入：一个具体声明（必带主体 + 谓词 + 客体），例如：

• "杭州 2024 年总用水量 = 28.6 亿立方"
• "上海 ZDWP 项目负责人是张三"
• "HSBC HK Premier 最低资产门槛是 100 万港币"
• "2024 年浙江省软著 ZL2024XXXXX 第一作者是李四"

1. 识别声明的领域，决定查哪个本地 DB

领域	DB / CLI
投资 / 持仓 / 标的 / 财经笔记	python3 ~/Dev/tools/kb/bin/inv.py search "<关键词>"
求职 / 公司 / 职位 / 面经 / 应聘记录	python3 ~/Dev/tools/kb/bin/apply.py query "<关键词>"
软著 / 著作权台账 / ZL 编号	python3 ~/Dev/tools/kb/bin/sc.py query "<关键词>"
水务 / 工程 / 项目交付	跳过 DB 步骤，直接走步骤 2（水务无本地 DB，按 ZDWP 项目里 01-06.md / xlsx / docx 走 Read + Grep）
学术 / 论文 / 法律 / 通用事实	跳过 DB 步骤，直接走步骤 2

判别：领域不明确 → AskUserQuestion 让用户指定，不自己猜。

2. WebSearch ≥2 独立信源

必须 ≥2 个独立信源，"独立"指域名不同 + 互不引用对方。推荐信源优先级（高→低）：

类型	例
官方网站	gov.cn / 公司官方 about / 银行官方 tariff
政府公报 / 年报	水利部 / 统计局 / 央行 / 证监会 / 工信部
学术数据库	CNKI / Web of Science / Google Scholar
权威媒体	财新 / 财经 / 第一财经 / FT / Reuters / Bloomberg
行业协会	中国水利学会 / 中国工程院
监管披露	银保监 / SFC / SEC 公告

反信源（不算独立信源）：

• 自媒体 / 知乎 / 小红书 / 微博 / Reddit（参考可以但不算"信源 ≥ 2"里那 2 个）
• AI 生成内容（除非明确标注引用源）
• 同集团下不同子站点（人民日报 + 央视网算 1 个，因都隶属官媒系统时建议挑跨系统）

搜索手法：派 2-4 个 WebSearch / WebFetch 并发（依铁律 #1），分别针对不同关键词组合（"A B C 2024" / " annual report" / "<编号> "）。

3. 输出三角对账表（markdown table）

## 声明校核：<原声明原文>

| 字段 | 本地 DB（库 + 命中条数） | 网源 1（域名 + URL） | 网源 2（域名 + URL） | 是否一致 |
|---|---|---|---|---|
| <字段 1> | <值> | <值> | <值> | ✅ / ❌ / ⚠ |
| <字段 2> | <值> | <值> | <值> | ✅ / ❌ / ⚠ |

**结论**：✅ 通过 / ❌ 冲突 / ⚠ 信源缺失

4. 一致 → 标 "✅ 通过 + 信源 URL 列表"

可继续把声明写入 deliverable。把对账表（或至少信源 URL 列表）放到 deliverable 的脚注 / 参考资料溯源节，便于后续追溯。

5. 冲突 → STOP

• 用 AskUserQuestion，原文照贴各源的差异（不要自己总结 / 归一）
• 给用户 3-4 个选项：以源 A 为准 / 以源 B 为准 / 进一步查证 / 改写声明避开矛盾点
• 绝对不允许擅自挑一源继续写 deliverable — 这正是本 skill 要消灭的反模式

6. 任意源未找到 → 标 "⚠ 信源缺失：<哪一源>"

报告用户：

• 已查到的源 + URL
• 缺失的源 + 已尝试的搜索关键词
• 建议：继续找（指定其他搜索词 / 别的库）/ 退化为单源（用户接受风险）/ 改写声明降低具体度

让用户决定是否仍要继续，不要自己默认"找不到就算了"或"反正主源说 X 就 X"。

---

反模式（硬措辞）

• ❌ 未通过 cross-check 就把声明写进 deliverable = 任务失败。报告交付后被退回的代价远大于多花 5 分钟核对
• ❌ "我记得 / 大概是 / 应该是 / 看着像" 类口吻进 deliverable（必须有源）
• ❌ 拿单源（哪怕官网）当结论 — 官网也错过（旧版本未更新 / 子域 stale）
• ❌ 拿自媒体 / 知乎 / AI 答案当独立信源凑数
• ❌ 冲突时擅自挑一源 — 必 AskUserQuestion
• ❌ "信源缺失"默认略过 — 必显式标 ⚠ 给用户决策
• ❌ 把 cross-check 推回给用户做（"你自己查一下"）— 本 skill 是 Claude 主动跑的

---

输出长度

校核报告本身不限长度（事实多则长），但结论行必须一句话明确：

✅ 通过：<原声明>，3 源一致（DB + 官方 + 财新） ❌ 冲突：<原声明>，本地 DB 标 X 但官方公报标 Y，已询问用户 ⚠ 信源缺失：官方源未找到，已用 2 个权威媒体源代替，待用户决定是否继续

---

与其他 skill / 协议的协作

• 配合 /critique：critique 维度 4「资源浪费」+ 维度 1「决策效率」可触发本 skill 的事后审查（"上次 xlsx 数据是不是没对账"）
• 配合 prep-basic-info：基础信息准备的"参考资料溯源"步骤 = 本 skill 的输出（对账表 + URL）
• 配合 /wrap handoff：handoff 里关键数据声明都要带本 skill 的对账记录
• 不替代 engineering-mode：engineering-mode 是会话级行为约束，本 skill 是单点数据校核流程

---

改 SSOT

源码：~/Dev/tools/cc-configs/skills/verify-data/SKILL.md 分发：~/.claude/skills/verify-data/（symlink，install.sh 自动建） 注册：~/Dev/tools/cc-configs/harness.yaml 的 global_skills 列表