第十一节：验收 AI 做出来的网站

即使固定评测通过、审计记录完整，很多 AI 写代码的项目还是会在“自动测试通过、页面能打开、AI 说已完成”这里结束。

从截图和复现路径到修复、回归与冻结

验收必须使用生产模式

开发服务器会提供热更新、额外调试能力和不同的资源加载行为。它能正常打开，不代表正式构建也可靠。

D09 重新执行 TypeScript 检查和 Next.js production build，再在正式模式下验证：

•

登录与角色；工单列表；

•

工单详情和 AI 建议；企业知识库；固定评测；

•

管理与审计；首页与退出。

production build 下的工单列表，而不是设计稿或开发服务器]

验收的对象不是某一张漂亮截图，而是页面、数据、接口和状态能否共同完成任务。

“这个界面有问题”也可以变成有效需求

比如在1028px 宽度打开工单详情，左栏下沉，三栏关系被破坏。

1280px 断点下左侧业务栏下沉

我不需要先知道 CSS Grid、断点或最小宽度怎么写。我提供了四类信息：

当前页面和浏览器宽度；

实际截图；

期望仍然保持三栏业务关系；

不允许通过缩小到无法阅读来解决。

AI 负责定位布局规则、修改并重新截图。我的责任是判断业务结构是否恢复。

同一 1280px 条件下恢复冻结的三栏结构

不会前端，不等于只能说“感觉怪怪的”。只要能说清场景、现象、影响和期望，AI 就能把它转换成技术问题。

字体和按钮比例也属于验收

这一轮发现正文大量使用 8～11px，而按钮接近 14px。结果是操作入口很抢眼，真正需要阅读的客户消息、知识来源和风险说明反而显得弱。

修复时没有简单把所有文字放大，而是重新建立层级：正文负责持续阅读，标题和关键结论负责定位，辅助信息可以更小；按钮字号不应该压过业务内容。

这类问题不会让自动测试失败，却会让使用者更容易漏看证据和风险。在企业 AI 工作台里，它不是纯审美问题，而是信息优先级问题。

横向溢出不能只把 overflow: hidden 加上去

工单详情曾出现 74px 横向溢出，AI 标签跑到页面外侧。

详情页响应式修复后，AI 标签和正文重新进入可见区域

如果直接隐藏溢出，内容会消失；如果盲目缩小字体，又会破坏可读性。

最终修复的是列宽约束、长文本换行和组件最小宽度。窄屏宽表仍允许在表格区域横向滚动，但整个 document 不再横向溢出。

“局部滚动”和“整个页面被撑开”是两种完全不同的体验，需要分别验收。

列表进入详情再返回，为什么会有跳动感

最明显的问题出现在工单列表点击某张工单，再从详情返回：页面像重新加载了一次，表格短暂消失，位置也发生变化。

原因不是动画不好看，而是导航触发了整页加载，并且返回后列表状态没有立即恢复。

修复后改为应用内导航，保留列表数据和筛选上下文；详情页返回时不再先显示空表。

这个案例说明，用户说的“跳动感”往往包含数据加载、路由方式、占位高度和滚动位置多个问题。AI 可以分析技术原因，但用户感受到的连续性才是最终标准。

最后要走一条完整工单，而不是七个孤立页面

D09 使用 TK-1007 完成了一次受限真实模型调用：登录、查看工单、检索知识、DeepSeek 流式生成、来源和风险校验、人工改写、确认、状态变化，最后在管理端追溯整条链路。

TK-1007 的模型失败、成功重试、人工确认和审计追溯

七个页面分别正确，不代表跨页面闭环正确。只有同一个工单 ID 能贯穿所有阶段，才能证明这不是七个互不相关的演示页面。

产品角色怎样验收 AI 开发

我最终使用的验收格式很简单：

代码块

Plain Text

页面/路径：在哪里发现？

角色与数据：谁在操作哪条记录？

复现步骤：怎样稳定出现？

实际结果：截图里发生了什么？

业务影响：为什么这会造成误解、失败或风险？

期望结果：用户应该看到和完成什么？

回归范围：修复后还要检查哪些关联页面？

AI 修复后必须重新走原路径，并检查关联页面。没有新的截图或测试证据，不能把缺陷标记为完成。

可以直接交给 AI 的全链路验收要求：

代码块

Plain Text

请使用 production build，而不是开发服务器，按真实角色逐页验收全部页面，并用同一个业务对象完成跨页面主闭环。

D09 冻结后，产品第一版已经完成本地 production build 下的全链路验收。