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