验证技能Skill：让规格、代码与治理规则自动对齐的质量守门员
- 一句话定位：这是一个「验证协调器」，用一次调用把规格文档、代码实现和项目治理规则放在同一张检查表上核对，输出带
file:line的可执行修复建议。 - 六大验证模式：规格验证、文件验证、漂移检测、法规验证、比较验证、理解验证，输入不同参数自动切换模式。
- 六大验证视角：完整性、一致性、对齐、覆盖、漂移、法规，可并行启动，最后统一去重合成报告。
- 输出可落地：每条发现都标注状态（PASS/WARN/FAIL）、严重性（HIGH/MEDIUM/LOW）、位置、问题描述和修复建议，而不是泛泛而谈的"建议优化"。
- 不阻塞开发：除法规 L1/L2 违规外，其余发现均为建议性质，适合作为评审前置关卡而非强制门禁。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
基础信息
| 项目 | 内容 |
|---|---|
| 中文名 | 验证技能Skill |
| 英文名 | validate |
| 技能 ID | 11724 |
| 调用方式 | 用户可调用（是） |
| 参数提示 | 规格 ID（例如 005）、文件路径、constitution、drift 或描述要验证的内容 |
| 允许的工具 | Task、TaskOutput、TodoWrite、Bash、Grep、Glob、Read、Edit、Write、AskUserQuestion、TeamCreate、TeamDelete、SendMessage、TaskCreate、TaskUpdate、TaskList、TaskGet |
它到底解决什么问题？
在真实的研发流程里，最耗时的往往不是写代码，而是"对不上"：需求文档写了三页，代码只实现了一半；规格里说"快速返回"，实现里没有任何超时约束；团队写了一份 CONSTITUTION.md 治理规范，但没人真的逐条检查过代码。这些问题靠人眼逐行比对，成本高、易遗漏、且没有留痕。
验证技能（validate）就是把这些"对不上"的工作结构化：它先读懂目标对象（规格、文件、治理规则或一句自由描述），再派出多个验证视角并行检查，最后把散落的发现去重、分级、合成一份可执行的报告。
一键安装的思路与步骤
安装环节的具体命令、入口链接与版本要求，请以官方说明为准；此处给出通用流程，便于你判断自己是否具备条件：
- 确认运行环境：需要一个支持"技能（Skill）/子代理"机制的 AI 编码助手环境。若想使用技能内置的团队模式，还需要在设置中启用
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS（技能详情中明确标注了该前提）。 - 准备项目上下文：技能在验证前会主动读取项目
CLAUDE.md（架构、惯例、优先级）、docs/specs/[NNN]-[name]/下的规格文档、项目根目录的CONSTITUTION.md。这些文件缺失不影响基础验证，但会削弱"对齐"和"法规"两个视角的判断依据。 - 添加技能：在技能市场/技能库中按技能 ID
11724或英文名validate检索并添加。具体搜索入口与安装命令以官方说明为准。 - 验证是否生效：新增一次会话，输入一个最简单的目标，例如
validate constitution或validate drift。若技能正常响应，你会先看到它读取上下文的动作，随后被询问"选择执行模式"（标准模式 / 团队模式），这就说明安装成功。 - 建立调用习惯：把
validate编入既有流程——写规格后跑一次规格验证，实现完成后跑一次漂移检测，发布前跑一次法规验证。一次接入，长期复用。
2. 该技能的主要功能和特点
核心能力：六种验证模式，按输入自动派生
技能会根据你传入的参数自上而下匹配，第一个命中的规则决定模式：
| 你输入的 | 触发的模式 | 验证对象 |
|---|---|---|
规格 ID（如 005、005-auth） |
规格验证 | 规格文档本身的质量 |
文件路径（如 src/auth.ts） |
文件验证 | 单个文件的质量 |
drift 或 check drift |
漂移检测 | 规格与实现是否对齐 |
constitution |
法规验证 | 代码是否符合 CONSTITUTION.md |
X against Y |
比较验证 | 两个来源之间的差异 |
| 一段自由文本 | 理解验证 | 方法或理解是否正确 |
六大验证视角，各管一段
- 完整性：所有章节是否填写、是否存在 TODO/FIXME、清单是否完成、是否残留
[需要澄清]标记。 - 一致性：术语是否统一、交叉引用是否有效、是否存在自相矛盾的表述。
- 对齐：文档里写的代码模式在仓库里是否真实存在，是否出现"虚构实现"。
- 覆盖：需求是否被映射、接口是否被指定、边缘案例是否被处理。
- 漂移：规格需求与实现之间的范围蔓延、功能缺失、矛盾与额外工作。
- 法规：L1/L2/L3 规则违规识别，并给出自动修复机会。
差异化特点：和普通工具比强在哪
- 发现是结构化的，不是散文式的：每条发现强制包含状态、严重性、标题、
file:line位置、一句话问题描述、修复建议、来源视角。技能约束里写得很直白——“为每个发现包含文件:行，没有泛泛观察”。 - 有去重合成机制：多个视角可能命中同一处代码，技能会按位置分组（5 行内视为潜在重叠），保留最高严重性、合并补充细节、同时给两个视角记功，再按 FAIL > WARN > PASS 排序并分配
F[N]/W[N]编号。用户看到的永远只是一份合成报告，而不是六份原始输出的堆砌。 - 模糊语言可量化：规格验证内置模糊检测，识别犹豫词（“应该”“可能”）、模糊量词（“快速”“许多”）、开放列表（“等。”）、未定义术语（“系统”），并给出 0–5% 优秀、5–15% 可接受、15–25% 推荐澄清、25%+ 高模糊性的评分。
- 法规违规分级处理：L1 提供自动修复，L2 需手动修复，L3 仅作建议；只有 L1/L2 是阻塞性的。
- 两种执行模式：范围小、1–3 个视角时用标准模式（即发即弃的子代理更简单）；完整规格、漂移+法规同时验证、4 个以上视角适用、跨多文档+实现时推荐团队模式（持久协调的多个验证器并行）。
- 决策留痕：漂移决策会被记录到规格的
README.md，方便回溯"当时为什么这么判断"。
3. 如何使用该技能？
步骤 1：确定验证目标并调用
调用的唯一必填输入就是目标。几种典型写法：
validate 005—— 验证编号 005 的规格文档validate src/auth.ts—— 验证单个文件质量validate drift—— 检查规格与实现的漂移validate constitution—— 检查代码是否符合治理规则validate PRD against SDD—— 比较两个来源validate 我们的登录超时策略是否合理—— 自由文本，进入理解验证
步骤 2：让技能先读上下文
技能会先读取完整目标再动手，不做内容假设。它会加载 CLAUDE.md、相关规格目录、CONSTITUTION.md 以及现有代码风格，用于后续"对齐"和"一致性"判断。这一步不要跳过，否则视角判断会失真。
步骤 3：选择执行模式
技能会根据范围复杂度给出建议，推荐项会标记「(推荐)」，通过 AskUserQuestion 让你确认：
- 完整规格、或漂移+法规一起、或 4+ 视角、或跨多文档+实现 → 推荐团队模式
- 聚焦验证、1–3 个视角 → 推荐标准模式
步骤 4：并行启动验证视角
标准模式下，技能在单个响应里发起多个 Task 调用，每个视角使用统一的任务委托模板：写明目标、范围、标准、焦点，以及期望的结构化输出格式。没有发现时返回 NO_FINDINGS。
步骤 5：合成与去重
所有视角返回后，技能按"收集 → 按位置分组 → 保留最高严重性 → 排序 → 分配 ID"的算法合成。
步骤 6：阅读报告
输出遵循固定结构，示例（漂移检测场景的简化版）：
| 视角 | 通过 | 警告 | 失败 |
|---|---|---|---|
| 完整性 | 8 | 1 | 0 |
| 一致性 | 5 | 2 | 0 |
| 对齐 | 6 | 0 | 1 |
| 漂移 | 4 | 1 | 2 |
| 总计 | 23 | 4 | 3 |
随后是「🔴 失败（必须修复）」「🟡 警告（应该修复）」「✅ 通过」三段清单，每条失败项形如：F1 登录超时未实现 (src/auth.ts:88) — 补充 30s 超时与重试上限（规格 3.2 要求）。整体评估落在 EXCELLENT / GOOD / NEEDS_ATTENTION / CRITICAL 四档之一，最后是结论段落。
步骤 7：按后续步骤建议行动
技能会根据发现类型给出选项：法规 L1/L2 违规 → 应用自动修复（推荐）/ 显示违规 / 跳过检查；检测到漂移 → 确认并继续 / 更新实现 / 更新规格 / 推迟决策；规格失败 → 先解决失败 / 显示详细发现 / 无论如何继续；全部通过 → 进入下一步。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 验证技能 validate（本技能） | 规格—实现—治理三层对齐的质量守门器 | 六模式 + 六视角并行验证、漂移分类、模糊评分、法规 L1/L2/L3 分级、发现去重合成 | 需支持技能机制的 AI 编码环境；团队模式需开启实验性开关；建议项目内有 CLAUDE.md / specs / CONSTITUTION.md | 规格评审、实现前后对齐检查、治理合规审查、方案比较 | 优势：跨"自然语言文档"与"代码"双域验证，输出带 file:line 和修复建议；不足：偏流程规范，要求项目本身有一定文档沉淀 |
| ESLint / TypeScript 类型检查等静态分析 | 代码层自动化质量检查 | 语法规则、风格约束、类型正确性 | 极低，npm install 后配置即用 |
提交前钩子、CI 流水线 | 优势：快、确定性强、零幻觉；不足：只懂代码，不懂"规格说了什么"，无法判断需求是否被完整实现 |
| 人工 Code Review / 规格评审会 | 人工经验判断 | 上下文理解、业务权衡、人际对齐 | 无技术门槛，但占用人力与会议时间 | 关键模块评审、架构决策 | 优势：能处理模糊的业务取舍；不足：逐行比对成本高、易遗漏、结论不留痕、难以规模化复用 |
| 通用大模型对话式审查 | 直接把代码或文档贴给 AI 提问 | 开放式问答与建议 | 低，随时可用 | 临时性代码解读、单文件提问 | 优势：灵活；不足：无固定视角清单、无 file:line 强制约束、多轮结果易重复冲突、无去重与分级机制 |
一句话选择建议：要检查"代码写得对不对"用静态分析，要检查"代码是不是按规格和治理规则写的"用 validate。
5. 该技能的典型应用场景与实际体验情况
场景一：规格评审前置（产品经理 / 技术负责人）
痛点：PRD 与 SDD 写完就进入开发，模糊表述被带到实现阶段才暴露，返工成本高。
使用方式：validate 005 触发规格验证，重点看模糊检测评分和"完整性"视角。若评分落在 15%–25% 区间，说明存在"推荐澄清"的表述，返回文档补齐再评审。
实际体验：上手几乎没有门槛，只需要一个规格 ID。效果最直观的是把"这段描述到底清不清楚"从主观争论变成可量化的分数；注意点是要先有结构化的规格目录，否则技能读不到上下文。
场景二：实现过程中的漂移检测（后端 / 前端开发）
痛点：开发到一半需求悄悄变了，或者为了省事多做了规格里没写的功能（范围蔓延），最后没人说得清差异在哪。
使用方式：validate drift。技能会加载规格需求与实现文件，把差异分成范围蔓延、缺失、矛盾、额外四类，并用 ✅ 对齐 / ❌ 缺失 / ⚠️ 矛盾 / 🔶 额外 标记，决策记录写入规格 README.md。
实际体验：这是技能价值密度最高的场景。输出直接指向 file:line，不需要二次定位；注意事项是漂移判定依赖规格写得足够具体——如果规格本身模糊，漂移结论也会打折扣。
场景三：治理规则体检（架构师 / Tech Lead）
痛点：团队写了 CONSTITUTION.md，但没人真正逐条核对代码，规则逐渐变成墙上的标语。
使用方式：validate constitution。技能解析规则、按类别应用检查（模式规则用正则匹配，检查规则用语义分析），按 L1/L2/L3 分级输出。
实际体验：L1/L2 是阻塞性的，能真正卡住问题；L1 还可以选择"应用自动修复"直接改代码（技能具备 Edit/Write 权限），省去手工修改。注意事项：L3 只是建议，不要把它当成必须清零的指标，否则容易陷入无意义的"刷分"。
场景四：方案比较与理解确认（新人 / 跨团队协作）
痛点：新人接手模块时，不知道自己的理解和既有实现是否一致；或者两版设计文档之间到底差在哪，靠肉眼比对容易漏。
使用方式：输入 X against Y 走比较验证，或直接贴一段自己的理解走理解验证。
实际体验：比较验证适合文档换代时的差异盘点，理解验证适合"我这样理解对吗"的确认。这类场景结论偏解释性，建议把它当作讨论起点而非最终裁定。
6. 该技能能为用户带来的价值
效率提升：把原本需要人工逐行比对的规格—实现核对，压缩成一次调用 + 一份合成报告。六个视角并行执行，避免了"一个人从头看到尾"的串行瓶颈；去重机制又避免了六个视角各说一遍同一处问题造成的阅读负担。
门槛降低：使用者不需要记住检查清单——技能内置了完整性、一致性、对齐、覆盖、漂移、法规六套检查逻辑，也不需要精通治理规则条文，validate constitution 一条命令就能拿到分级违规清单。对刚接手项目的新成员尤其友好。
质量前置：所有发现都有 file:line 和修复建议，问题在评审会之前就被定位到具体行，会议从"找问题"变成"定方案"。漂移决策落盘到规格 README.md，形成可追溯的质量档案。
风险可控：法规违规按 L1/L2/L3 分级，只有高等级才阻塞，避免"一刀切门禁"拖慢交付；其余发现保持建议性质，团队可以按自己的节奏消化。这种"该硬的地方硬、该软的地方软"的设计，是它区别于粗暴校验工具的关键。
长期价值：随着使用次数增加，项目的 CLAUDE.md、规格文档、CONSTITUTION.md 会被反复读取和校验，这三份资产的质量本身也会被反向拉动——文档从"写完就放着"变成"持续被验证的活文档"。
7. 常见问题 FAQ
Q1：这个技能怎么安装？收费吗？
在支持技能机制的环境里，按技能 ID 11724 或英文名 validate 检索并添加即可；若要用团队模式，需先在设置中启用 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS。具体的安装入口、命令与费用策略以官方说明为准，建议安装前先确认所使用环境的技能市场是否已上架该技能。
Q2：它和 ESLint、单元测试有什么区别？会重复吗？
不重复，分层不同。ESLint 和单元测试检查的是"代码本身对不对"，只认代码；validate 检查的是"代码是否符合规格文档与治理规则"，需要同时读懂自然语言文档和代码。实践上建议：静态检查和单测放在提交钩子与 CI，validate 放在规格评审、实现中段和发布前，三者互补。
Q3：团队模式必须开吗？标准模式功能够用吗？
不是必须。技能本身给出了判断标准：范围只有 1–3 个视角、聚焦单一目标时，标准模式更简单；完整规格、漂移+法规同时验证、4 个以上视角适用、或跨多文档+实现时才推荐团队模式。团队模式的优势是多个验证器持久并行、交叉引用更充分，代价是需要开启实验性开关并承担更长的协调时间。
Q4：它会不会卡住我的开发流程，让提交失败？
不会。技能约束中写明：除法规 L1/L2 违规外，所有其他发现都是建议性的，不阻塞。即便出现 L1/L2 违规，也会先通过 AskUserQuestion 提供"应用自动修复 / 显示违规 / 跳过检查"三个选项由你决定，而不是直接拦下。
Q5：适合谁用？我的项目没有 CONSTITUTION.md 还能用吗？
最适合三类人：写规格的产品/技术负责人、做实现与对齐的开发、负责架构治理的 Tech Lead。没有 CONSTITUTION.md 不影响使用——只是"法规"这个视角没有输入，你可以改用规格验证、文件验证、漂移检测或比较验证。同理，规格目录不规范时，“对齐”“覆盖”"漂移"的判断依据会变弱，建议先把 docs/specs/[NNN]-[name]/ 和 CLAUDE.md 补齐再跑。