Vibecoding · 交付质量
实现、审查、E2E 与人工验收：四道不同的质量门
代码能编译、审查没发现问题、自动测试通过和用户真正能用，是四种不同证据。
本页目录
学完这一篇，你应该能够
- 区分四类验证证据
- 为界面改动设计真实操作路径
- 在失败后保留可恢复状态
实现只回答“改了什么”
实现阶段要保持范围清楚、小步保存，并运行项目已有的编译与测试。生成大量代码并不能替代理解接口、数据和现有行为。
审查从三个方向寻找问题
可以分别检查标准与安全、需求是否完整实现、代码是否容易维护。审查应引用具体文件和行为，不用空泛的“看起来不错”。
E2E 验证真实路径
端到端验证从用户入口开始，操作真实界面或 API，观察最终结果。截图只能证明某个瞬间，表单提交、跳转、错误提示和移动布局仍需实际操作。
人工验收决定是否解决了问题
自动测试适合重复验证明确规则；用户负责判断文字、节奏、任务适配和业务取舍。验收反馈应记录为新的规格或修复项，再进入下一轮。
- 构建证据
- 代码审查证据
- 自动化行为证据
- 用户验收证据
动手练习
为一个页面改动分别写出：一条构建检查、一条代码审查问题、两条 E2E 操作和一条只能由用户判断的验收问题。
完成标准
- 不再用单一测试代表全部正确
- 关键用户路径有可重复步骤
- 失败能定位到具体质量门
资料说明
根据 PandaUp 资料中的开放式开发流程、课件生成脚本与脱敏 Agent 工程案例重新编写。本文讲解可迁移的方法，不公开内部数据、个人记忆、真实票据或第三方受限内容。