AI 写完代码之后：构建通过不等于页面验收通过

生成的代码可以成功构建，但按钮仍可能无法点击、文字仍可能溢出，支付回调也可能没有发放正确权益。使用 AI 编程助手时，要为用户实际行为设置验收步骤，而不只是看构建是否绿色。

先描述行为变化

用简短的前后对比说明需求，例如：可选验证步骤不能阻止资料正确的表单提交。写清成功、失败和取消时分别发生什么。这样助手有可观察的目标，审核者也有可执行的检查表。

检查变更范围

同时检查界面和服务端规则。如果只是取消按钮禁用，而接口仍拒绝请求，修复就不完整。可从 Cursor 收录页了解代码助手方向，再通过官方文档确认当前能力。

选择有意义的测试

测试真正可能出错的行为：跳过可选字段、访问他人记录、重复支付回调或网络失败。不要只写与实现逐行对应的测试。把测试数据与生产数据分开，避免测试失败时创建真实购买或收录。

打开实际页面验收

检查桌面和窄屏手机布局，点击主要操作，确认可见结果并查看报错。Playwright 官方文档 提供浏览器测试方法，但自动化通过必须对应最初的需求，不能只验证页面“有一个按钮”。

区分支付验收层次

模拟成功回调验证的是应用逻辑；支付测试环境验证提供方集成；真实已付款订单才验证完整线上闭环。应说明通过了哪一层验收，页面返回 200 不等于到账，也不等于权益已交付。

记录验收结论

记录改了什么、完成了哪些检查、还有什么未验证。附上相关页面或流程入口。在 ToolNav，收录表单、结账和最终产品页应作为同一条链路验收，而不是三个彼此无关的页面。

示例：可选验证不能挡住提交

可选外链验证可以列四个验收场景：用户跳过、验证失败、服务超时和验证成功。只要其他资料正确，免费申请都应进入审核。分别检查按钮状态与服务端响应；资料错误时应保留输入，并指出要修改的字段。这个例子说明：页面告诉用户的规则必须与接口实际执行的规则一致。

示例：三档套餐不能串权益

多档收录套餐应核对服务端价格、结账商品、付款订单和实际展示位置。修改浏览器字段不能让低档套餐得到高档权益；重放成功回调也不能创建重复收录。模拟事件验证的是应用规则，不能证明真实到账。验收结论中应明确测试环境与真实交易检查的范围。

检查不顺利的状态

检查取消、会话过期、权限不足与网络请求中断，确认草稿、提示和重试入口是否合理。窄屏测试要使用长按钮文案，不能只看整洁的桌面样例。即使构建通过，这些状态中有流程无法完成，也不能当作任务结束；用户需要的是能应对常见中断的工作流。

交付说明应该包含什么

交付说明写清可观察的变化、通过了哪些检查，以及还有哪一步需要真实账号或交易。附上对应页面，用普通语言说明剩余条件。把测试用例与改动保存在一起，后续修改可以重复验证。不要拿页面状态或测试数量证明它们并未覆盖的结论。

官方参考

• 官方参考 1
• 官方参考 2

提供方功能与条件可能变化。本文是 ToolNav 原创流程指南，不代表付费实测排名或特定结果保证。