Tvs Verify

SKILL.md

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

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

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

## 自检清单

输出前确认：

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