构建通过并不代表任务已完成。在实际项目中，“构建成功”仅意味着代码可以成功编译，而不能保证页面表现、业务逻辑或改动范围符合预期。
开发者应建立“构建通过不等于任务完成”的意识。当遇到此类问题时，通常可归纳为以下三类：
1. 页面表现异常
表现为样式错乱、间距不当、按钮位置偏移或颜色不符。此类问题通常涉及 CSS 布局或局部样式定义。
2. 业务逻辑错误
表现为文案错误、数据绑定失效、条件渲染异常或路由跳转逻辑错误。此类问题通常涉及业务代码逻辑层。
3. 改动偏离目标
表现为 Codex 在修改目标元素时，无意中改动了全局样式、公共区块或调整了不相关的版式。这本质上是任务边界控制（Scope Creep）问题。
核心原则：切换至“结果验收”视角
不再仅以“构建通过”作为交付标准。当页面不对时，应立即采取以下步骤：
第一步：明确描述具体差异
避免模糊的“样式不对”或“结果有问题”。应详细说明：
- 具体页面与区域：如“首页 Hero 区”。
- 目标元素：如“主按钮”。
- 当前表现：如“按钮位于卡片上方”。
- 期望表现：如“按钮应在标题下方左对齐”。
第二步：让 Codex 复述目标与现状
在继续修改前，要求 Codex 明确其理解的当前状态与目标状态的差异。这有助于确认双方对任务目标的理解是否一致。
第三步：审查 Diff 范围
检查 Codex 是否为了完成局部任务而动到了全局样式或公共组件。如果范围已跑偏，首要任务是收缩改动范围，而非继续修复。
第四步：定位正确层级
判断问题是源于样式层、结构层还是数据层。未准确定位层级前的盲目修改会导致问题复杂化。
常见误区
- 盲目信任构建结果：认为 Build Passed 即代表无误。
- 反馈过于模糊：不提供具体位置和期望表现，让 Codex 猜测。
- 连续优化：在页面不对时不断要求“再优化一下”，导致改动范围持续失控。
- 跳过 Diff 审查：不检查修改了哪些文件就直接开始下一轮修复。
排查建议顺序
- 详细描述具体差异。
2. 要求 Codex 复述当前与目标状态。
3. 检查 Diff 是否超出任务范围。
4. 判断改动所在的层级是否正确。
5. 提出最小化修正方案。