The interface is localized. Skill descriptions and documents are machine-translated by AI into your language; code, commands, paths and technical terms stay in the original, and the author's document governs.
Explore skills
Productivity · SKILL.md

insight-validation

insight-validation

洞察验证 — 验证已生成洞察的数据准确性、逻辑合理性和业务可操作性, 确保洞察质量并分级管理。 适用情形:洞察生成后进行验证,或用户要求"验证洞察"、"核实 insights"时执行。 核心:数据核实 + 逻辑检验 + 可操作性评估。

Independent GitHub snapshot · Automated classification · Original documentation governs

Skill documentation

GitHub

name: insight-validation description: > 洞察验证 — 验证已生成洞察的数据准确性、逻辑合理性和业务可操作性, 确保洞察质量并分级管理。 适用情形:洞察生成后进行验证,或用户要求"验证洞察"、"核实 insights"时执行。 核心:数据核实 + 逻辑检验 + 可操作性评估。 argument-hint: "[洞察列表] [验证标准:数据准确性/逻辑合理性/业务可操作性] [业务背景]" last_reviewed: 2026-06 version: 1.0.0 risk_level: low

加载上下文

首次使用时: 读取 ../../CLAUDE.md 获取场景级配置(验证标准/置信度分级/使用限制)。


/insight-validation — 洞察验证

Examples

→ 示例:用户说"业务说降价能提升销量,但我算了下利润会下降,帮我验证一下",系统应调用本技能,执行价格弹性分析和利润敏感性验证。

→ 示例:用户说"之前给的那个成本优化建议被业务挑战了,帮我补充更多数据支撑",系统应调用本技能,补充数据验证和敏感性分析。

→ 示例:用户说"供应商涨价的真正原因是什么,帮我从公开信息和市场数据验证",系统应调用本技能,执行外部数据交叉验证。

第一步:获取待验证洞察

洞察清单:

□ 待验证洞察数量:[X] 条
□ 来源报告:[报告名称/日期]

□ 洞察列表:
| # | 洞察标题 | 洞察描述 | 类型 | 原置信度 |
|---|---------|---------|------|---------|
| 1 | [标题] | [描述] | [模式/异常/机会] | [高/中/低] |
| 2 | [标题] | [描述] | [模式/异常/机会] | [高/中/低] |

第二步:数据准确性验证

数据来源核实:

□ 洞察 1 数据核实:
  → 引用数据点:[X]
  → 数据来源:[系统/报告名称]
  → 数据时间:[YYYY-MM-DD]
  → 数据核实结果:[✅ 确认 / ⚠️ 存疑 / 🔴 错误]
  → 核实说明:[描述]

□ 洞察 2 数据核实:
  → ...

计算准确性检验:

□ 洞察 1 计算验证:
  → 引用计算:[描述,如"YoY = (本期 - 上期) / 上期 × 100%"]
  → 原计算值:[X]%
  → 重新计算值:[X]%
  → 计算准确性:[✅ 正确 / 🔴 错误,差异 [X]%]
  → 修正后数值:[X]%(如错误)

数据时效性检查:

□ 洞察数据时效性:
  → 数据最新时间:[YYYY-MM-DD]
  → 距今时长:[X] 天
  → 时效性评估:[✅ 有效(<[X]天)/ ⚠️ 需更新(>[X]天)]

第三步:逻辑合理性验证

逻辑推演检验:

□ 洞察 1 逻辑检验:
  → 结论推导逻辑:[描述]
  → 逻辑链完整性:[✅ 完整 / ⚠️ 部分缺失 / 🔴 逻辑错误]
  → 关键假设:[列出]
  → 假设检验:[✅ 成立 / ⚠️ 存疑 / 🔴 不成立]
  → 逻辑漏洞:[描述(如有)]

□ 洞察 1 因果 vs 相关检验:
  → 是否混淆相关性与因果性:[是/否]
  → 说明:[因果关系成立/仅相关/无法判断]

跨洞察一致性检验:

□ 洞察间一致性:
  → 洞察 1 与洞察 2 是否存在矛盾:[✅ 一致 / ⚠️ 部分矛盾]
  → 说明:[描述]

□ 与已知事实的一致性:
  → 洞察是否符合已知的业务事实:[✅ 符合 / 🔴 矛盾]
  → 说明:[描述]

第四步:业务可操作性评估

可操作性评级:

□ 可操作性维度:
  → 明确性:行动建议是否清晰 [1-5 分]
  → 可执行性:建议在现有资源下是否可执行 [1-5 分]
  → 可衡量性:执行效果是否可量化追踪 [1-5 分]
  → 时效性:执行时机是否恰当 [1-5 分]

□ 综合可操作性评分:[X]/5
  → 4.0-5.0:[✅ 强可操作] — 可直接转化为行动
  → 3.0-3.9:[⚠️ 中等可操作] — 需细化后执行
  → < 3.0:[🔴 弱可操作] — 建议重塑或搁置

执行障碍分析:

□ 洞察 1 执行障碍:
  → 资源障碍:[有/无] — [描述]
  → 组织障碍:[有/无] — [描述,如跨部门协调]
  → 技术障碍:[有/无] — [描述]
  → 优先级障碍:[有/无] — [描述]
  → 综合评估:[✅ 可执行 / ⚠️ 需解决 X 个障碍 / 🔴 存在重大障碍]

第五步:置信度重新评估

综合置信度评估:

□ 置信度调整因素:
  → 数据准确性:[提升/不变/降低]
  → 逻辑合理性:[提升/不变/降低]
  → 可操作性:[提升/不变/降低]
  → 样本量/覆盖度:[提升/不变/降低]

□ 置信度最终定级:
  → 初始置信度:[高/中/低]
  → 调整后置信度:[高/中/低]
  → 调整原因:[描述]

第六步:生成验证报告

═══════════════════════════════════════
洞察验证报告
验证日期:[YYYY-MM-DD]
验证洞察数:[X] 条
原报告:[报告名称]
═══════════════════════════════════════

【验证结果汇总】

| # | 洞察 | 数据准确 | 逻辑合理 | 可操作性 | 最终置信度 |
|---|------|---------|---------|---------|-----------|
| 1 | [标题] | [✅/⚠️/🔴] | [✅/⚠️/🔴] | [✅/⚠️/🔴] | [高/中/低] |
| 2 | [标题] | [✅/⚠️/🔴] | [✅/⚠️/🔴] | [✅/⚠️/🔴] | [高/中/低] |

【详细验证结果】

洞察 1:[标题]
□ 数据核实:[✅ 确认 / 🔴 错误]
  → 修正数据:[原值] → [修正值]
□ 逻辑检验:[✅ 合理 / 🔴 存疑]
  → 逻辑问题:[描述(如有)]
□ 可操作性:[✅ 可执行 / ⚠️ 需细化 / 🔴 障碍多]
  → 执行障碍:[列表]
□ 置信度:初始 [高] → 最终 [高] — 调整原因 [描述]

洞察 2:[标题]
...

【洞察质量分级】
□ 🔵 强洞察(置信度[高] + 可操作[高]):[X] 条
  → [洞察1]、[洞察2]
□ 🟢 良好洞察:[X] 条
□ 🟡 待改进洞察:[X] 条
  → [洞察3] — 建议 [细化方向]
□ 🔴 存疑/不可用洞察:[X] 条
  → [洞察4] — 原因 [描述]

【建议】
□ 可直接行动的洞察:[列表]
□ 需进一步验证的洞察:[列表] — 验证方法 [描述]
□ 建议搁置的洞察:[列表] — 原因 [描述]

═══════════════════════════════════════
置信度:[✅ 高 / ⚠️ 中 / 🔴 低]
整体验证结论:[✅ 洞察质量良好 / ⚠️ 存在质量问题 / 🔴 多个洞察存疑]
═══════════════════════════════════════

升级触发条件

  • 多个洞察(> [X] 条)数据核实为错误
  • 存在洞察的逻辑存在根本性错误
  • 高置信度洞察的可操作性被评为 🔴 弱
  • 洞察之间存在相互矛盾的结论
  • 洞察引用的数据无法在 [X] 天内核实
  • 洞察涉及重大业务决策(> [X] 万金额或战略级)

Finance Skills — insight-validation atomic skill

Saved skills