改动验收验证#

这个 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 / 日志：观察到了什么。

## 未验证或风险
- 没有就写“无”。
- 有就说明缺什么环境、数据、权限或测试。

## 下一步
- 如果通过：无需行动，或建议用户自行跑更重的全量检查。
- 如果部分通过/失败/无法验证：说明最小下一步，不写修复代码。

自检清单#

输出前确认：

• 是否回到了用户原始问题，而不是泛泛检查代码。
• 每个“通过”都有证据。
• 失败项是否写明失败原因。
• 未验证项是否明确标出。
• 是否避免了“应该可以”。
• 是否没有偷偷修代码。