用途
Validation-First Design 用于解决 AI 智能体输出不确定性的问题。它的核心原则是：如果智能体无法验证某条需求，该需求就不会被可靠满足。因此每一条规格需求都必须包含智能体可自动验证的可测试验收标准，把“智能体生成了一些代码”转变为“智能体生成了可证明满足规格的代码”。该规则适用于每一层级：规格需求必须有可测试的验收标准；计划必须定义哪些关卡验证每个任务；实现必须通过所有适用关卡才算完成；迭代必须显示通过关卡的可衡量进展。
主要能力：六道验证关卡
每份实现必须按顺序通过六个检查点，越靠后的关卡运行成本越高，因此尽早发现失败可节省大量时间。
关卡 1：编译检查
检查项目能否无错误编译/转译。使用构建命令 {BUILD_COMMAND}。它是最廉价的检查，能捕获语法错误、缺失导入/依赖、类型错误、配置错误。
关卡 2：隔离单元验证
检查所有变更文件的单元测试是否通过。使用测试命令 {TEST_COMMAND} 或 {TEST_COMMAND} --filter {changed-files}。单元测试快速、确定性强，能捕获函数行为错误、未处理的边界情况、现有代码的回归、契约违规。要求所有现有单元测试通过、新增单元测试覆盖 R{N} 的全部验收标准、测试不依赖外部服务或网络。
关卡 3：跨组件集成
端到端与集成测试验证组件协同工作，使用 {TEST_COMMAND} --e2e 或 {E2E_TEST_COMMAND}。可捕获组件间 API 契约不匹配、跨模块边界的数据流错误、认证/授权集成问题、使用真实数据的数据库查询错误。
关卡 4：资源与速度基准
性能基准需通过既定阈值，使用 {BENCHMARK_COMMAND} 或 {TEST_COMMAND} --performance。可捕获响应时间回归、内存泄漏或过度分配、阻塞主线程的 CPU 密集操作、数据库查询性能下降。当规格明确要求性能、改动触及已知热路径或功能涉及大规模数据处理时才需应用此关卡。
关卡 5：启动冒烟测试
应用需成功启动且基本冒烟测试通过。使用启动命令 {START_COMMAND}，验证 curl -f http://localhost:{PORT}/health，或运行 {SMOKE_TEST_COMMAND}。可捕获缺失环境变量或配置、端口冲突或绑定错误、启动初始化失败、缺失运行时依赖、数据库迁移问题。
关卡 6：人工审计 由人工审查输出的质量、设计意图与难以自动化的需求。可捕获主观质量问题、技术上正确但战略上错误的架构决策、过度或不足工程化、自动工具遗漏的安全问题、技术上满足但背离规格精神的需求。人工审计流程为：智能体完成关卡 1-5 并报告结果，人工对照规格意图审查，若反馈需改代码则进入修订循环（更新规格→重跑迭代循环→验证修复源于更新后的规格）。
使用方式
规格需求映射到关卡：写规格时每条验收标准应标明由哪道关卡验证。例如 R1 用户认证中：有效凭据返回会话令牌对应关卡 2（单元测试）、无效凭据返回 401 对应关卡 2、会话令牌可访问受保护端点对应关卡 3（集成）、登录页 2 秒内渲染对应关卡 4（性能）、应用启动时加载认证模块对应关卡 5（启动）。无法映射到任何关卡的需求属于未验证需求：要么需求过于模糊需改写为可测试标准，要么验证基础设施缺失需补关卡。
阶段关卡：阶段关卡是 Hunt 各阶段之间的强制验证检查点，确保上一阶段输出足够扎实后才进入下一阶段。过渡对应关系为：Spec→Plan 需所有领域有含可测试验收标准的规格；Plan→Implement 需计划引用规格、定义顺序、含测试策略；Implement→Iterate 需代码可构建（关卡 1）、测试通过（关卡 2）、实现追踪最新；Iterate→Monitor 需检测到收敛（逐迭代变更减少）；Monitor→Spec 需发现缺口或新需求。阶段关卡由迭代循环强制执行：智能体在阶段末运行关卡检查、报告通过/失败，若失败则不进入下一阶段，而在当前阶段迭代直至通过。
合并协议：使用智能体团队时，各智能体在隔离分支完成工作后需逐个合并：每次合并一个分支→运行 {BUILD_COMMAND} 必须通过→运行 {TEST_COMMAND} 必须通过→运行启动验证必须通过→全部通过才继续，否则先修复再合并下一个；全部合并后对完全集成的代码库再运行启动验证；每次合并后清理已合并分支（git branch -D <branch>）。逐个合并的原因是批量合并后测试无法定位是哪个合并导致失败。
完成信号：完成信号是智能体在任务或阶段全部退出标准满足时输出的特定字符串，供自动化检测工作是否完成。规则：信号必须是正常输出中不会出现的唯一字符串；智能体须在验证所有退出标准后才输出；信号应是会话最后输出；若无法满足所有标准则不应输出信号，而应记录阻碍完成的内容。
适用场景与设计模式
适用于需要 AI 智能体产出可验证结果的所有开发流程，尤其是规格驱动开发（SDD）。四种模式：
模式 1：先测试后实现——先读规格验收标准→生成测试用例→运行测试全部失败（RED）→实现功能→运行测试全部通过（GREEN）→按需重构。即 SDD 内的 TDD。
模式 2：关卡级联——按序运行关卡，早关卡失败就不运行后续关卡；早关卡更廉价，先修廉价问题。
模式 3：渐进式关卡深度——并非每次迭代都需全部关卡。早期实现需关卡 1、2；中期实现需 1、2、3，可选 4；后期实现需 1、2、3、5，可选 4；发布前需全部 1-6。
模式 4：回归预防——之前通过的关卡开始失败时视为 P0：停止前进、定位回归、修复、添加测试防止重现、若揭示规格缺口则回传更新规格。
限制
本文档为通用方法说明，命令均以占位符形式给出（如 {BUILD_COMMAND}、{TEST_COMMAND}），具体命令需替换为项目自身的构建与测试命令。性能阈值等具体数值也以占位符表示，未提供具体平台、收费或价格信息。该技能的落地效果依赖项目是否已具备对应的验证基础设施（如 E2E 测试、基准测试），缺失的关卡无法凭空存在。人工审计关卡无法自动化，其结果依赖人工判断。