メニュー
验证证据优先级体系——L1-L5 五级证据、Done 判定门槛矩阵、完成前四问、无法验证处理规范、运行态验证方法指引。触发场景：(1) 标记 InReview 或 Done，(2) 选择证据等级，(3) 判断是否验证充分，(4) 处理无法验证的项，(5) 用户说"验证"、"证据"、"Done"、"验收"
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | dvfy |
| description | 验证证据优先级体系——L1-L5 五级证据、Done 判定门槛矩阵、完成前四问、无法验证处理规范、运行态验证方法指引。触发场景：(1) 标记 InReview 或 Done，(2) 选择证据等级，(3) 判断是否验证充分，(4) 处理无法验证的项，(5) 用户说"验证"、"证据"、"Done"、"验收" |
| argument-hint | [任务ID] [证据等级] |
| context | fork |
| agent | Explore |
| model | haiku |
| allowed-tools | ["Bash","Read"] |
| effort | low |
| hooks | {"TaskCompleted":[{"hooks":[{"type":"command","command":"python3 ${CLAUDE_SKILL_DIR}/../hooks/scripts/task_completed.py 2>/dev/null || true"}]}]} |
证据优先级体系：验证的核心规则。未验证 = 未完成。
| 等级 | 名称 | 说明 | 示例 |
|---|---|---|---|
| L1 | 运行态证据 | 真实输出已发生可识别变化 | 发起请求后返回值变了、页面渲染结果变了、文件产物生成了 |
| L2 | 调用链证据 | 底层状态切换已被观测到 | 日志显示命中新代码路径、数据库记录已写入、状态机已转移 |
| L3 | 自动化断言 | 测试/脚本/断言自动判定 | 单元测试全绿、verify.sh exit 0、assert 通过 |
| L4 | 表面观察 | 日志/截图/页面现象（需人工解读） | 截图看起来正确、日志无报错、页面能打开 |
| L5 | 间接推断 | 代码 diff / 口头说明 | "我改了这段代码"、"理论上应该没问题" |
默认优先级：L1-3 主判 → L4-5 辅助说明。只有 L5 时不得宣称完成。
| 证据等级组合 | 判定动作 | 标注要求 |
|---|---|---|
| 全部 L1-3 通过 | Agent 自审后 Done | session 文件逐条标注 PASS + 验证方法 |
| L1-3 部分 + L4 补充 | Agent 自审后 Done | L4 项标注「待人工确认」+ 后续验证方式 |
| 仅 L4 或 L4-5 | 不允许 Done | 标注 InReview + 「待验证」+ 原因 + 后续方式 |
| 仅 L5 | 禁止宣称完成 | 保持 InProgress，补充真实验证 |
| 证据等级 | 验证方式 | 使用场景 |
|---|---|---|
| L1 运行态 | 运行态验证 | 关键链路是否真的经过新代码 |
| L2 调用链 | 运行态验证 | 底层状态是否真正切换 |
| L3 自动化断言 | 自动化验证 | task_verify.sh、单元测试 |
| L4 表面观察 | 手动验证 | UI 交互、实机测试 |
| L5 间接推断 | — | 不作为独立验收依据 |
标记 InReview 前必须回答：
| # | 问题 | 回答格式 |
|---|---|---|
| 1 | 验证的是哪一层？ | 文档 / 代码 / 配置 / 调用链 / 运行态 / 输出 |
| 2 | 是否真的走到了新链路？ | 是/否 + 证据（日志/断点/请求追踪） |
| 3 | 结果是否出现可识别变化？ | 变化描述 + 变化前后对比 |
| 4 | 哪些部分已验证，哪些未验证？ | 已验证清单 + 未验证清单 |
暂时无法验证时，必须使用三段式模板明确写出：
未验证项: [具体条目]
原因: [为什么现在无法验证：环境/凭据/依赖/时间窗口等]
后续验证方式: [具体步骤或条件，不是"以后再测"这种空话]
禁止行为：
代码层验证（lint/build/测试）通过后，还需确认运行时真的走到新链路：
| 方法 | 适用场景 | 操作 |
|---|---|---|
| 关键点加日志/断言 | 有源码访问权限 | 在加载点插入，确认执行路径经过新代码 |
| 发起真实请求 | API / CLI / Web 服务 | 确认输出因改动而变化 |
| 检查产物生成 | 构建任务 / 插件项目 | 验证 hooks 是否触发、产物是否存在且正确 |
| 端到端走查 | UI / 多模块集成 | 从用户操作入口走到最终输出，全程有据 |
对于插件类项目（如 diwu-workflow 本身）：验证 hooks 是否被触发、产物是否被生成、JSON 是否合法。
归档管理——Task 归档与 Recording 物理归档的双轨机制、触发条件、手动步骤、验证清单。触发场景：(1) 终态任务数超阈值，(2) session 文件数超阈值，(3) 用户说"归档"、"archive"、"清理"
纠偏与误判排查方法论——退化信号检测、四行重写模板、止损序列、六类泛化误判排查表、与 BLOCKED 的边界判定。触发场景：(1) 出现退化信号（反复纠偏/目标漂移/证据缺失等），(2) 需要纠偏恢复，(3) 排查误判，(4) 判断是 correction 还是 BLOCKED，(5) 用户说"纠偏"、"偏了"、"不对"、"重写"、"止损"、"误判"
积木式能力验证方法论——判断「直接做 vs 先验证」、将不确定性分层隔离、沉淀可复用能力资产。触发场景：(1) 讨论技术可行性或方案选型，(2) 评估某个实现的不确定性，(3) 决定直接集成 vs 先做 Demo 验证，(4) 分析能力复用或知识沉淀策略，(5) 用户说"积木"、"Demo"、"能力验证"、"不确定性"
产品文档工具——正向（需求→文档）或逆向（代码→文档）两种模式。触发场景：(1) 为已有产品还原/补全文档，(2) 为新功能/模块编写产品文档，(3) 用户说"写文档"、"还原文档"、"doc"、"产品文档"
阶段边界决策锚点——四段式判断（启动/实施/验收/纠偏），含正例/反例/边界例。覆盖：基线失败处理、不确定性决策、入口门控、大幅度判定、执行偏差分级、并行串行选择、超前实施、Done 人工确认、blocked_by 判定、循环依赖、continuous_mode 续跑、recording 写入时机、decisions.md 写入时机。触发场景：(1) 需要做阶段边界决策，(2) 判断幅度大小，(3) 选择并行还是串行，(4) 判断是否需人工确认，(5) 用户说"判断"、"决策"、"幅度"、"并行"、"确认"
产品需求分析方法论——竞品分析、用户画像、需求优先级排序、迭代层次设计、方案对比、非功能性需求分类。触发场景：(1) 讨论产品规划或功能设计，(2) 进行需求分析或竞品调研，(3) 设计迭代路径或优先级排序，(4) 用户说"PRD"、"需求文档"、"竞品分析"、"产品规划"、"需求优先级"、"迭代规划"、"方案对比"