验证刚刚 AI 完成的修改是否真正解决了用户原始问题。使用场景:用户要求验证、确认、测试、证明、检查是否完成、看看是否真修好了、确认刚才改动是否生效。必须把用户诉求转成验收标准,逐项收集证据并给出通过、部分通过、失败或无法验证结论;不做泛泛代码审查。
--- name: tvs-verify description: 验证刚刚 AI 完成的修改是否真正解决了用户原始问题。使用场景:用户要求验证、确认、测试、证明、检查是否完成、看看是否真修好了、确认刚才改动是否生效。必须把用户诉求转成验收标准,逐项收集证据并给出通过、部分通过、失败或无法验证结论;不做泛泛代码审查。 --- # 改动验收验证 这个 Skill 不是用来找所有代码坏味道的。 `tvs-code-reviewer` 负责找漏洞、坏味道和潜在问题;`tvs-verify` 负责确认“刚刚 AI 做的修改,是否真的解决了用户交代的问题”。 ## 目标 把“应该修好了”“看起来完成了”转换成可复查的证据链。 核心原则: ```text 没有证据,就不能说完成。 验证的是用户问题是否被解决,不是顺手做一次全仓代码审查。 ``` ## 工作流程 ### 1. 还原用户原始问题 先用 1 到 3 句话复述: - 用户原本要解决什么问题。 - AI 刚刚改了什么范围。 - 什么结果才算“真的完成”。 如果上下文不足以知道原始问题,先问用户补充,不要自行脑补验收标准。 ### 2. 写出验收标准 把用户诉求拆成可检查条目: ```text 验收标准: - [ ] 目标行为 A 已实现 / 已修复。 - [ ] 旧的错误路径不会再发生。 - [ ] 相关配置 / 文档 / 入口已同步。 - [ ] 没有明显破坏相邻流程。 ``` 验收标准必须来自用户请求、改动目标、相关代码契约或显式文档,不要临时加戏。 ### 3. 建立证据映射 对每个验收标准找最窄证据: - 文件内容证据:读取改动文件,确认关键逻辑、配置、命令、路径是否存在。 - 差异证据:查看 diff,确认改动确实落在目标范围。 - 静态证据:类型、语法、JSON、Markdown fence、配置格式是否有效。 - 运行证据:测试、lint、typecheck、build、脚本、接口、hook dry-run。 - UI 证据:浏览器交互、截图、DOM 状态、控制台/网络请求。 优先选择能直接证明目标的窄检查。不要为了显得认真默认跑全量构建。 ### 4. 执行验证 验证优先级: 1. **目标直连检查**:最能证明用户问题的读文件、命令、脚本、浏览器操作。 2. **已有测试**:已有且覆盖目标路径时优先使用。 3. **静态正确性**:语法检查、JSON 解析、类型检查、配置解析。 4. **集成/构建检查**:只有目标确实依赖集成行为时才跑。 5. **人工验证步骤**:无法自动化时,给出可观察的手动验证步骤和预期结果。 验证阶段默认不修改源码。除非验证对象本身就是“运行初始化脚本 / 生成产物 / 刷新基线”,否则不要为了验证而改文件。 ### 5. 判定结果 只能使用以下结论之一: - **通过**:所有关键验收标准都有证据支持。 - **部分通过**:核心目标有证据,但仍有未验证项或次要缺口。 - **失败**:有证据表明用户问题仍未解决,或检查失败。 - **无法验证**:缺少环境、权限、依赖、数据或可执行入口。 禁止说“应该可以”“看起来没问题”“理论上能跑”。这些都是没证据的废话。 ## 验证优先级 按场景选择证据: ### 代码修复 - 找到原 bug 的触发路径。 - 确认新逻辑覆盖该路径。 - 优先跑相关测试或最小复现。 - 如果没有测试,至少给出代码证据和手动复现步骤。 ### 配置 / hooks / Agent 工程 - 校验文件路径、命令名、frontmatter、JSON、脚本语法。 - 对脚本使用 `node --check`、`--status`、dry-run 等低风险检查。 - 确认文档模板和实际生成路径一致。 - 注意不要误删用户已有 `.memory/**`、hooks 或 agent 配置。 ### UI 改动 - 用浏览器或截图验证用户可见行为。 - 检查交互前后状态、控制台错误、网络请求。 - 只用代码推测 UI 完成是不够的。 ### 文档 / 规则 / Skill - 验证 frontmatter 字段、名称、触发描述、示例命令是否一致。 - 检查是否仍残留旧名称、旧路径、旧命令。 - 对嵌入代码块进行语法或 JSON 解析验证。 ## 规则 - 没有证据,不能说已经完成。 - 检查失败时必须明确说明失败原因或失败输出摘要。 - 如果没有现实可行的验证路径,必须直接说明,不要硬装验证过。 - 汇报要简洁,优先总结证据,不要贴一大坨无关日志。 - 能用窄检查证明的问题,不要默认跑又慢又大的全量检查。 - 不要把验证变成代码审查;除非发现会影响用户目标的问题,否则不要展开旁支坏味道。 - 不要在验证中偷偷修复问题。验证失败就报告失败;是否继续修复由用户决定。 - 如果验证过程中发现改动没有覆盖用户原始诉求,要明确指出“没有解决用户问题”。 ## 输出格式 使用固定格式: ```markdown ## 验证结论 通过 / 部分通过 / 失败 / 无法验证 一句话说明:这次 AI 修改是否解决了用户原始问题。 ## 验收标准 - [x] 标准 A:证据摘要 - [ ] 标准 B:失败或未验证原因 ## 证据 - `path/to/file`:证明了什么。 - `command`:运行结果摘要。 - 浏览器 / UI / 日志:观察到了什么。 ## 未验证或风险 - 没有就写“无”。 - 有就说明缺什么环境、数据、权限或测试。 ## 下一步 - 如果通过:无需行动,或建议用户自行跑更重的全量检查。 - 如果部分通过/失败/无法验证:说明最小下一步,不写修复代码。 ``` ## 自检清单 输出前确认: - [ ] 是否回到了用户原始问题,而不是泛泛检查代码。 - [ ] 每个“通过”都有证据。 - [ ] 失败项是否写明失败原因。 - [ ] 未验证项是否明确标出。 - [ ] 是否避免了“应该可以”。 - [ ] 是否没有偷偷修代码。
don't have the plugin yet? install it then click "run inline in claude" again.