不做测试用例生成器
核心输出不是用例列表，而是围绕问题、风险、证据和处理建议组织的验收报告。
智验产品经理验收报告点击查看大图01
项目背景与核心场景
项目背景
AI 编程工具正在缩短产品从想法到可操作原型的时间，但开发速度提高之后，验收和质量保障逐渐成为新的瓶颈。
产品经理仍需重新阅读需求、拆解检查场景、逐项操作页面并记录异常。对于包含 AI 能力的产品，仅确认“功能已经实现”也不够，还要判断实际表现是否符合需求、关键流程是否可用，以及结论是否有充分依据。
基于这一场景，我设计了智验，希望利用 AI 辅助完成需求理解、自动验收和结果分析，降低重复操作成本，并提高验收结论的可追溯性。
核心使用场景
产品经理提交 PRD 和待验收产品地址，确认验收计划后，由 AI 操作真实产品、记录页面表现并采集证据，最终整理问题、风险和判断依据，辅助决定当前版本是否可以交付或上线。
02
用户问题与产品目标
目标用户
- 负责产品验收和上线判断的产品经理
- 快速迭代、使用 AI 编程工具的产品团队
- 缺少完整自动化测试资源的 AI 产品经理
产品目标承担需求整理、重复操作、证据采集和问题归纳，让产品经理将注意力放在风险判断和产品取舍上，而不是替代其做最终上线决策。
- 01
需求文档和实际页面需要反复切换核对，重复操作在复杂项目中耗时明显增加。
- 02
验收场景依赖个人经验，边界情况容易遗漏。
- 03
问题描述、截图和需求依据分散，沟通与复核成本较高。
- 04
AI 缺少实际页面证据时难以获得信任，执行失败也容易与产品缺陷混为一谈。
- 05
全量人工确认会将自动化节省的时间重新消耗在审核上。
03
核心流程
上传需求
输入产品地址
确认验收计划
AI 操作产品
采集页面证据
整理问题与风险
获取验收建议
04
关键产品设计
结论关联实际证据
将需求、验收场景、页面动作、实际观察、截图和最终问题关联，降低无依据判断和复核成本。
区分缺陷与无法判断
除通过和未通过外，增加执行受阻、结论不确定和需要人工确认等状态。
人工确认改为例外处理
系统优先自动完成，只有需求歧义、高风险、证据不足和真正涉及产品取舍的情况交给产品经理。
结果页服务产品决策
先展示总体建议、核心风险和问题列表，再按需展开需求、操作过程、观察和截图。
05
产品迭代与验证
V1｜完成基本链路
已经能够理解需求并组织评测，但系统复杂度、全量人工审核和陌生页面执行能力仍影响实际使用。
V1.1｜改善自主操作
围绕入口发现、目标到达、状态理解和失败恢复调整浏览器能力，并用两个独立产品进行固定场景测试。
V2｜复杂性收回系统内部
采用异常再确认，报告优先展示上线建议、问题严重程度和处理优先级，详细证据按需展开。
- 完成从需求理解、场景生成到真实浏览器操作和验收报告的核心闭环。
- 同一冻结计划的执行受阻情况由 28/28 降至 0/28。
- 项目测试记录曾达到 598 项通过、7 项按测试条件跳过，并完成基于真实浏览器的自动化质量检查。
- Career OS 与 EquityLab 的专属选择器、固定路由、文本映射及场景脚本均为 0。
- 以上数据来自固定评测集和本地独立产品测试，用于比较版本能力，不等同于线上客户成功率。
06
我的工作与下一步
我的职责
下一步迭代方向
- 扩展测试产品和页面类型，重点验证复杂动态页面、权限状态和长流程任务下的自主操作能力。
- 完善体验问题和探索式问题的评估方法，继续平衡问题发现能力与误报控制。
- 通过更多产品经理任务测试，验证验收计划是否易于理解、报告能否支持快速决策。
07
项目素材
以下为产品核心页面与功能截图，点击任意图片可查看完整原图。
08
我对 AI 产品的思考
AI 产品的价值不在于覆盖全部环节，而在于让 AI 接管重复操作和证据整理，让产品经理保留风险与上线判断。
人工审核不是越多越可靠；系统应自动处理证据充分、风险较低的任务，把注意力留给例外情况。
AI 执行失败不能直接转化为产品问题，承认“暂时无法判断”比生成错误结论更可靠。
固定评测集、失败案例分析和版本回归，才能持续比较 AI 能力是否真正改善。
系统可以保持严谨和复杂，但用户首先需要看到问题、影响、依据和需要处理的事项。