构建通过但页面不对怎么判断

很多人一看到：

build passed

就会下意识觉得：

那应该没问题了

这在真实项目里是远远不够的。

因为“构建通过”只说明一件事：

项目至少还能被构建出来

它不代表：

• 页面效果对了
• 数据展示对了
• 文案位置对了
• 路由跳转对了
• 用户真正想要的结果对了

前置教程：让 Codex 完成任务验收
如果你还没有建立“构建通过不等于任务完成”的意识，先完成前置教程。

依据来源：OpenAI Codex 官方手册中关于 verification、review、diff、task workflows、best practices 的说明。

本篇目标

学完后，你应该能做到：

1. 区分“构建层通过”和“页面结果正确”不是一回事。
2. 知道页面不对时先看哪一层。
3. 知道怎么让 Codex 回到目标，而不是继续乱修。
4. 知道如何用截图、描述和差异定位问题。
5. 知道什么时候不是构建问题，而是任务理解偏了。

先分清 3 种情况

当你遇到“构建通过，但页面不对”时，通常属于下面三类之一：

1. 构建层没问题，但页面表现不对

例如：

• 样式乱了
• 间距不对
• 按钮位置不对
• 颜色不对

2. 构建层没问题，但业务结果不对

例如：

• 文案错了
• 数据绑定错了
• 条件渲染不对
• 跳转逻辑不对

3. Codex 改动本身偏离目标

例如：

• 你让它改一个按钮，它顺手改了整个区块
• 你让它压缩间距，它改了全局样式
• 你让它补一个文案，它调整了版式

这类问题本质上不是 build 问题，而是任务收口问题。

第一原则：不要再说“但它已经 build 通过了”

这句话容易误导你自己。

因为构建通过最多只能说明：

代码没有明显构建级错误

不能说明：

交互对了
视觉对了
结果对了
任务目标对了

所以页面不对时，要立刻切回“结果验收”视角。

第一步：把“不对”说具体

很多人会说：

页面不对
样式不对
结果不太对

这种表述太模糊，Codex 很容易继续猜。

更好的说法应该像这样：

构建已经通过，但首页 hero 区按钮位置不对。
我期望按钮在标题下方左对齐。
现在它跑到了卡片区域上面。
请先不要继续修改，先判断这更像局部样式问题、布局层问题，还是你上一次改动超出了目标范围。

第二步：先让 Codex 复述“当前结果”和“目标结果”

当页面不对时，不要先让它继续修。

先发这段：

构建通过了，但页面结果不符合预期。

请先不要修改文件。
请先用中文复述：
1. 你理解的当前页面结果是什么。
2. 你理解的目标结果是什么。
3. 当前差异更像是样式问题、结构问题、数据问题，还是你上一次改动超出了任务范围。
4. 你准备优先检查哪一层。

这一步很重要，因为很多时候它根本不是“不会修”，而是“理解的目标和你不一样”。

第三步：先看 diff 有没有超出范围

页面不对时，很常见的一类根因是：

它为了完成一个小目标
顺手改多了

所以你要先让它检查：

1. 修改了哪些文件。
2. 有没有动到全局样式。
3. 有没有动到公共组件。
4. 有没有把一个局部任务扩成结构调整。

如果范围已经跑偏，先收范围，比继续修更重要。

第四步：看它是不是真的改到了“正确层”

举几个最常见的错位：

你要改局部样式，它改了全局样式

你要改文案，它改了组件结构

你要修路由，它改了页面布局

你要调展示顺序，它改了数据逻辑

这类问题如果不先识别出来，后面就会进入“越修越远”的状态。

第五步：截图或现象描述一定要具体

如果你是用视觉结果在验收，那你反馈给 Codex 时，一定要具体：

• 哪个页面
• 哪个区域
• 哪个元素
• 当前表现
• 目标表现

你甚至可以固定成下面这种格式：

页面：首页
区域：hero 区
元素：主按钮
当前：按钮跑到了四个特性卡片上方
目标：按钮应在标题和说明文案下方，左对齐
要求：先判断原因，不要直接重写整块布局

这会比一句“页面不对”强太多。

一段非常好用的修正提示词

构建已经通过，但页面结果不符合目标。

请先不要修改文件。

请按下面顺序处理：
1. 先复述你理解的当前结果和目标结果。
2. 先判断差异更像样式问题、结构问题、数据问题，还是上一次改动超出了范围。
3. 检查上一次修改涉及哪些文件。
4. 如果你发现改动超出范围，请先指出超出的部分。
5. 给出最小修正方案，不要直接大改。

最容易犯的错

1. 构建一通过就默认可以交付

2. 页面不对时继续让 Codex“再优化一下”

3. 不告诉它哪里不对，只让它自己猜

4. 不先看 diff，就直接开始第二轮修改

这些都会让结果越来越失控。

你真正要学会的判断顺序

以后只要遇到“构建通过但页面不对”，就按这个顺序：

先把不对描述具体
再让 Codex 复述当前和目标
再检查 diff 是否超范围
再判断它改到了哪一层
最后才给最小修正任务

完成标志

做到这里，如果你已经形成下面这些习惯，就说明本篇起作用了：

1. 不再把构建通过当成交付完成。
2. 会先具体描述页面哪里不对。
3. 会先让 Codex 复述当前结果和目标结果。
4. 会先看 diff 是否超范围。
5. 会要求最小修正，而不是继续乱优化。

下一篇看什么

下一篇建议看：Codex 修改范围失控怎么收回来

这篇会专门讲当它改多了、修远了、顺手做太多时，怎么把任务收回来。