需求-实现对照验收

概述

在代码完成后，对照原始需求验证实现完整性。

核心原则： 需求即契约，实现必须满足契约。

开始时声明： "我正在使用 execution-validation skill 进行需求-实现对照验收。"

为什么需要这个环节

•计划可能遗漏细节
•实现过程中可能产生偏差
•验证代码质量 ≠ 验证需求满足
•确保交付物与预期一致

工作流程

1. 读取原始需求

查找并读取：

•Design doc: docs/plans/*-design.md
•或 brainstorming 记录
•提取验收标准

如果找不到原始需求：

•询问用户原始需求是什么
•或根据已有代码推断需求

2. 逐项对照检查

对每个需求项检查：

•是否有对应的代码实现
•实现是否完整
•是否有遗漏的功能

输出对照表：

需求项	实现状态	说明
功能 A	✅ 已实现	位置：xxx
功能 B	⚠️ 部分实现	xxx
功能 C	❌ 未实现	原因：xxx

3. 输出验收报告

markdown

## 验收报告

### 已完成
- [ ] 需求 1：实现了 xxx 功能

### 部分完成
- [ ] 需求 2：部分实现了 xxx (原因：xxx)

### 未完成
- [ ] 需求 3：未实现 (原因：xxx)

### 结论
[是否可以验收 / 需要补充什么]

验收标准

•每个原始需求都有明确状态
•未完成项有合理解释
•用户确认后才能标记为完成

常见问题

Q: 找不到原始需求文档

A: 询问用户，或根据代码实现反推需求

Q: 实现与需求有偏差

A: 记录偏差项，与用户确认是否接受

Q: 需求有遗漏

A: 标记为未完成，说明需要补充

UI 实际运行验证（有前端项目）

注意：此环节仅适用于有前端的项目。纯后端项目跳过 UI 实际运行验证，直接进行需求对照。

什么是 UI 实际运行验证

在真实浏览器环境中运行应用，检查：

•页面是否正确渲染
•交互是否正常工作
•数据是否正确显示
•错误是否正确处理

验证方式

•启动开发服务器

bash

npm run dev

•手动验证或 E2E 测试验证

•运行关键流程的 E2E 测试
•检查测试截图
•验证 UI 元素正确渲染

•截图对比（可选）

•预期效果截图
•实际效果截图
•对比差异

检查要点

检查项	说明
页面加载	无白屏、无控制台错误
组件渲染	正确显示、无样式问题
交互响应	点击/输入有正确响应
数据展示	数据显示正确、无截断
错误处理	错误提示正确显示

输出格式

markdown

## UI 实际运行验证结果

### 验证环境
- 浏览器：Chrome
- 分辨率：1920x1080
- URL：http://localhost:5173

### 验证结果
| 功能 | 状态 | 说明 |
|------|------|------|
| 登录页面 | ✅ | 正确渲染，输入框可交互 |
| 登录成功 | ✅ | 提交后正确跳转 |
| 登录失败 | ✅ | 错误提示正确显示 |
| 用户头像 | ✅ | 正确显示用户名称 |

### 结论
[是否通过验收]

验收标准

•每个原始需求都有明确状态
•未完成项有合理解释
•用户确认后才能标记为完成
•UI 实际运行验证通过（有前端项目则必须）

与其他环节的关系

•之前：verification-before-completion（代码质量验证）
•之后：update-blueprint（更新蓝图）
•区别：质量验证 vs 需求验证

关键原则

•逐项检查：每个需求都要有明确状态
•证据说话：用代码位置、实现细节作为证据
•诚实报告：未完成就是未完成，不掩盖
•用户确认：最终由用户决定是否可以验收