“页面已经完成，支持移动端。”

如果这句话只来自代码里的一个 @media，它还不能回答：窄屏会不会溢出，目录能不能关闭，读到一半返回时位置会不会丢。

我希望 AI 交付的，不只是一个完成声明，还有能支持这个声明的证据。

先写清楚要判断什么

以本站阅读结构为例，“目录可用”至少涉及几个具体结果：目录条目来自当前正文，点击后标题没有被顶栏遮挡，切换文章后内容更新，手机上能打开与退出。

这些条件来自任务约定。验证负责检查条件是否满足；如果条件本身还不清楚，就不能用一轮测试替人作出产品决定。

不同检查，回答不同问题

检查	能支持的结论	仍要另外确认
完整构建	这一轮源码能生成产物	页面能否实际操作
目标产物检查	路由、资源、公开内容符合检查条件	浏览器中的显示与行为
真实浏览器操作	受测 viewport 与路径下的交互结果	未覆盖设备和路径
用户验收	内容和阅读效果是否符合期待	未经验证的技术与运行状态

一张截图适合检查布局，但看不出后退是否恢复位置。一次成功点击也不能证明无结果搜索、直接访问和刷新都正常。证据要对准可能失败的地方。

从容易推翻结论的地方查起

对专题阅读，我会优先走一遍完整路径：主页进入专题，打开文章，切到另一篇，再后退。随后补直接访问、锚点、手机目录与键盘操作。

对内容聚合，需要检查一篇没有被人工推荐的新文章是否仍能进入专题完整列表。对跨专题引用，需要确认保留了进入时的上下文，同时仍然只有一份正文。

这些是本次改版需要取得的证据，不是这篇方法文章对所有状态已经通过的声明。实际交付应以对应轮次的构建和浏览器结果为准。

改动之后，旧证据还能用吗

修复滚动逻辑后，之前的阅读位置检查就需要重做；只改一处文字，不必因此重测无关的账号业务。重新验证的范围应跟随实际影响，同时完成项目规定的必要检查。

如果某个失败还无法解释，就留下缺口，继续定位。重复运行得到更多成功，不能自动抵消一个仍然可复现的失败。

把结论写到证据能到的地方

“已实现并完成本地构建，在指定桌面和窄屏下走通了阅读链，等待内容验收”，比“全面完成、完美适配”更有用。前者说明现在可以判断什么，也说明下一步由谁决定。

在本站，实现与验证之后还会区分用户验收、提交和发布。页面在本地正常，不等于已经上线；技术检查通过，也不替代读者对内容是否清楚、有趣的判断。