先验证，后声明，零例外

强制要求任何完成声明前必须运行验证命令并呈现证据，杜绝"应该有效"等虚假确认，将诚实作为核心价值

基本信息

• 技能名称?Verification Before Completion
• 中文名称?先验证，后声明，零例外
• 作者?zlc000190
• 分类?其他
• 版本?0.1.0
• 标签?verification, testing, honesty, quality-assurance, self-check, tdd, ci-cd, risk-management

使用方法

使用说明
核心用法
该技能是一种强制性的自我检查协议，要求在声称工作完成、修复或通过之前，必须执行验证命令并确认输出结果。其核心流程为： 识别验证命令 → 完整执行 → 读取输出 → 核实确认 → 才允许声明 。
关键执行模式：
测试通过：必须运行测试命令，确认 0 失败
回归测试：必须完成红-绿周期验证（写测试→运行通过→回退修复→必须失败→恢复→通过）
构建成功：必须确认 exit 0，而非仅看 linter
需求完成：逐行核对清单，而非仅测试通过
代理完成：必须检查 VCS diff 独立验证
显著优点
根本性防错 ：从流程上消灭"应该有效"的幻觉，将诚实嵌入工作流
信任修复 ：解决"我不相信你了"的历史信任破裂问题
成本前置 ：避免"虚假完成 → 重定向 → 返工"的浪费循环
非例外设计 ：明确"违反字面即违反精神"，封堵所有绕行借口
多场景覆盖 ：涵盖测试、构建、回归、代理委托等全部宣称场景
潜在缺点与局限性
执行摩擦 ：每次声称前强制等待验证，可能打断心流
疲惫冲突 ：明确标注"累了想结束"是红旗场景，需对抗人性
无豁免机制 ：即使"就这一次"也不允许，极端情况可能僵化
代理开销 ：代理报告必须独立核实，增加协调成本
工具依赖 ：需有可行的验证命令，某些探索性工作可能难以定义
适合人群
AI 助手/Agent ：防止幻觉性完成声明
开发者 ：养成证据驱动的工作习惯
团队协作场景 ：建立可验证的交付标准
高信任要求环境 ：如安全关键、金融系统开发
常规风险
认知过载 ：24 条失败记忆的心理负担
规则绕过 ：尝试用"不同措辞"规避监管（已被封堵）
执行衰减 ：长期可能松懈，需持续强化
验证盲区 ：若验证命令本身设计不当，可能产生虚假安全感