核心功能
需求是否真正实现，结果是否与用户目标一致。
刘俊豪的个人主页
已完成 · v0.2.0
VIBE CODING / 软件验收
让 AI 写出来的软件，真的经得起验收。
VibeCodingCheck v0.2.0 把用户最初的目标、需求和提示词拆成 REQ，再设计并评审测试用例，用运行结果、日志、数据、页面和截图核对 Codex 等 AI 编程工具交付的真实项目，最后留下可回归的证据链。
先设计用例，再执行验收；无法验证不等于未完成。
当前结论
把“做完了”拆成
VC把“做完了”拆成
可追踪的测试证据。
QA
已验证范围完成率
单独计算
只统计有充分证据的需求
验收覆盖率
如实呈现
没有真实环境就保留边界
需求与测试证据
3 类结果
测试结果运行、操作、日志和数据证据
已验证
无法验证记录环境限制与人工复验边界
待验证
交付检查文件、发布和版本基线
需处理
TC-FUNC-001 · VC-001
THE ACCEPTANCE LOOP
从一句需求，走到一份可以交付的结论。
从需求到用例再到回归，每一步都留下证据来源；能运行就运行，不能运行就把限制写清楚。
-
01
收集需求
读取最终需求、提示词、功能清单和历史报告，编号 REQ 并明确成功条件。
-
02
设计用例
按项目选择适用的功能、流程、数据、安装、视觉和非功能测试。
-
03
评审追踪
检查正向、反向、边界和恢复路径，建立 REQ → TC → Evidence 追踪。
-
04
实际执行
条件允许就启动、操作、检查日志与状态；无法执行就记录验收边界。
-
05
Bug 与回归
分级 Bug，生成 Codex 修复提示词，修复后沿用原编号定向回归。
一份报告 / 多层验收
把“看起来能用”，拆成可追踪的验收层。
用户流程
主要操作是否连贯，关键路径是否在中途断掉。
数据与状态
保存、读取、刷新、切换和错误恢复是否正确。
异常与边界
空状态、加载状态、异常输入和错误反馈是否完整。
测试用例驱动
把正向、反向、边界和恢复路径写成可执行用例，留下真实证据。
视觉与非功能
视觉、性能、安全、兼容和稳定性按条件验证，不把猜测当证据。
视觉验收模块
三种视觉验收模式，
按材料选择证据标准。
图片检查保留，但它是软件验收中的一层，不替代运行、操作和数据证据。
01同页面 / 同状态
页面对比
对比目标网页截图与实现截图的结构、布局、间距、字体、颜色和可见响应式问题。
02目标图 / 实际软件
参考重建
当目标是产品图、概念图或设计灵感时，检查主体、结构、材质、色彩及组件映射。
03只有实现截图
单图检查
只检查截图直接可见的遮挡、可读性、溢出、对齐、间距和明显视觉缺陷。
证据优先，不做猜测
“无法验证”
不是“未完成”。
先把需求映射到测试用例，再用实际证据验收。没有真实对局、外部接口或指定运行环境时，VibeCodingCheck 会降低本轮验收覆盖率，但不会把环境限制伪装成软件失败。
“有证据的通过，和暂时没有条件验证，是两种不同的结论。”
已实现有运行、操作或充分代码证据支持
通过部分实现核心方向存在，但仍有明确缺口
部分无法验证记录为覆盖率边界，不直接扣完成率
待验证交付物缺失缺少 .sln、README 或要求的发布步骤
缺失真实案例 / 脱敏展示
真实案例：
先发现重复，再验证修复。
以《阵亡刷抖音助手》为例：验收不止看程序有没有启动，而是把测试用例、日志、自动化测试、空闲观察和仍未具备条件的真实对局分开记录。
GitHub：打开英雄联盟阵亡刷抖音助手项目
316/316自动化测试通过
181修改前约 85 秒新增日志行
37修改后 817.51 秒新增日志行
0Error / Warning / Exception
TC
需求映射用例
已建立先把明确需求拆成正向、反向和边界路径，再开始执行。
VC-001
日志高频重复
已定位从明确的日志数量与时间证据开始，不把“看起来正常”当作结论。
FIX
抑制重复检测记录
已修复修复后继续运行 90 秒以上，保留前后数据作为复验依据。
NEXT
真实对局场景
待验证核心死亡与复活切换仍需要在真实条件下人工验证。
准备下一次交付