把完整仓库和一堆截图砸给 GPT-4.1 和 o4-mini，长上下文编码一次改对了吗？

我把整个仓库和一堆截图一次性砸进去了。两个模型都翻车了，但翻车位置完全不一样。

不是那种「按钮没加上」的低级翻车。结构它听懂了，文件也改到了，跑起来甚至像那么回事。真正打脸的是：hover 写成了 disabled，合计行对不齐，斑马纹错了一列，间距漂了几像素——需求文字全对，像素级细节全走眼。

国内改前端、改中后台，很多人习惯把一张图、一段代码丢进对话框。很少有人把完整仓库 + 多张带状态的界面截图一次性塞进长上下文，然后要求一次改对。这篇就是这次「狠测」的现场记录：能一次过的是什么，看走眼的又是什么。

为什么要做这个「狠测」

日常场景太常见了：产品经理丢来几张标注图，开发说「按这个改」。按钮不是一种状态，而是 default / hover / disabled / loading 四套；表格也不是「把数据列出来」，而是对齐、固定列、斑马纹、合计行一起出现。

小白可能觉得这是玩具 demo。进阶的人会对号入座：你一定改过一个「看起来懂了」的 AI 补丁——diff 很漂亮，打开页面却处处不对劲。

这次故意不用碎片对话，而是模拟真实交付：

  • 一份写清楚交互的需求文档
  • 多张带状态的界面截图（圈出按钮四态、表格错位）
  • 一个能跑起来的完整前端仓库，而不是单文件 HTML

问题很具体：长上下文编码，能不能一次改对？视觉推理，是真看懂了图，还是「读了字、猜了图」？

这不是测模型会不会写 React，是测它能不能在「整仓 + 多图」里，把结构和像素同时做对。

测试怎么做的（你可以复现）

先把三个词说成人话。

长上下文：一次塞进去的内容足够多——需求、多张图、整仓关键文件——模型不必你来回粘贴。代价是 token 变多，也更容易在后半段「看漏」。 视觉推理：模型不只读字，还要看截图里的颜色、对齐、间距、控件状态。文字写「禁用」，图上画的是灰色且不可点；这两件事必须对上。 Token：粗算消耗。这次单次请求大概是数万到十万出头量级（含多图），不必精确到个位；重点是「一次丢整仓」并不便宜，所以更该问值不值得。

需求文档怎么写

我压成「改什么 / 不要改什么 / 怎么验收」，避免散文。脱敏后的核心片段如下：

页面：订单管理（中后台）


按钮「导出」：


  • default：主色填充，白字
    • 

  • hover：主色加深 8%，cursor: pointer
    • 

  • disabled：灰底灰字，不可点击，无 hover
    • 

  • loading：保留按钮宽度，左侧转圈，文案改为「导出中…」，disabled
    • 



表格：


  • 操作列右对齐；金额列右对齐、等宽数字
    • 

  • 左侧「订单号」列固定，横向滚动时不跟着走
    • 

  • 斑马纹按数据行，不含表头、不含合计行
    • 

  • 合计行背景单独区分，金额与数据行列宽对齐，不允许错位
    • 



禁止：


  • 不要改路由、不要动登录、不要重构无关组件
    •

截图怎么标

三张图，每张只打一类问题，避免一张图上十个圈：

1. 按钮四态并排：default / hover / disabled / loading，红框 + 短注

2. 表格：订单号固定列、金额列对不齐、合计行错位，用线和箭头标

3. 间距与文案：按钮与表格的间距、错误文案「导出中」写成了「加载中」

标注原则就一句：圈状态，不圈情绪。「这里不对」没用，「disabled 不该有 hover 加深」才有用。

仓库怎么打包、prompt 怎么设计

仓库是一个能本地跑的中后台页：列表页组件、按钮样式、表格样式、一个合计行计算。打包时带上 package.json、页面组件、样式文件，去掉 node_modules 和构建产物。

Prompt 骨架（脱敏）：

你是前端工程师。下面是完整仓库关键文件 + 需求文档 + 3 张带标注截图。


任务：按需求一次改完，输出统一 diff。


约束：


1. 只改与按钮状态、表格对齐/固定列/斑马纹/合计行相关的文件


2. 不要重构、不要改无关文件、不要编造不存在的依赖


3. 先列出将改文件，再给 diff


4. 对照截图检查：按钮四态、列对齐、固定列、斑马纹范围、合计行

评判标准

  • 一次改对：本地跑起来，对照标注图，按钮四态和表格规则全部命中
  • 需多轮：结构对了，视觉细节要补
  • 视觉是否对：不是「代码里有 disabled class」，而是页面上看起来对
  • 幻觉：改了无关文件、改了没要求的文案、发明了需求里没有的交互

国内用户如果想自己复现这套方法、又不想自己折腾模型 key，可以用 api.884819.xyz 直接调用 GPT-4.1、o4-mini 做同样实验：注册用用户名+密码即可，按量付费，具体价格以页面实时显示为准。方便的是流程能对齐本文，而不是换一套完全不同的工具链。

GPT-4.1 vs o4-mini：实战对决，以及视觉翻车现场

两个模型拿到的是同一份材料。结论先说：

  • 结构级修改常常能对上：该动的组件找到了，按钮拆状态、表格加固定列和合计行，方向是对的
  • 视觉推理最容易翻车：按钮状态、表格对齐、间距、交互细节——看起来懂了，其实改错

它们改了什么，漏了什么

GPT-4.1 更像「能读仓库的中级前端」。它列出了正确文件：按钮组件、列表页、表格样式。按钮四态有了结构，loading 时文案也改成了「导出中…」，固定列用了 position: sticky。一次没过，主要死在视觉：
  • hover 和 disabled 的颜色差不够，disabled 仍能吃到 hover
  • 合计行的金额列和数据行差了半个单元格
  • 斑马纹扫到了合计行
o4-mini 更快、更敢改，也更飘。按钮 loading 做了，但把 disabled 和 loading 混成同一套灰样式；表格对齐只改了 text-align，没处理等宽数字和列宽；固定列写了 class，缺了背景色，一滚动就「透」出后面的单元格。它还动了一个无关的空状态文案——典型幻觉。

关键 diff 长这样（精简，只留打脸点）：

/ GPT-4.1：结构对，状态叠加上翻车 /

.btn-export:disabled:hover {


/ 需求：disabled 无 hover。模型仍写了加深 /


background: var(--primary-dark);


}



.table tbody tr:nth-child(even) {


/ 斑马纹按数据行，却没排除合计行 /


background: #f7f8fa;


}


/ o4-mini：对齐只做了一半，固定列缺背景 /

.col-amount { text-align: right; } / 没有 tabular-nums / 列宽约束 /


.col-id { position: sticky; left: 0; } / 缺背景，滚动时内容穿透 /

按钮组件上，GPT-4.1 接近需求，o4-mini 把 loading 文案写成了「加载中」——截图里已经标了正确文案，它仍跟了自己的语言习惯。

// 预期

{loading ? "导出中…" : "导出"}



// o4-mini 实际


{loading ? "加载中" : "导出"}

改完后的界面 vs 预期：最能打脸的地方

如果只看代码 diff，你会觉得 GPT-4.1「差不多了」。一对着标注图，问题立刻出来：

| 检查项 | 预期 | GPT-4.1 一次结果 | o4-mini 一次结果 | | 按钮 disabled | 灰、不可点、无 hover | 灰了，但仍有 hover 加深 | 和 loading 几乎同一套灰 | | 按钮 loading | 宽度不塌，文案「导出中…」 | 文案对，宽度略抖 | 文案漂成「加载中」 | | 金额列 | 右对齐 + 列宽对齐 | 右对齐，合计行错位 | 右对齐，数字仍在「跳」 | | 固定列 | 滚动不走，不穿透 | sticky 有了，阴影弱 | sticky 无背景，穿透 | | 斑马纹 | 不含表头和合计 | 扫到合计行 | 含表头感，节奏乱 | | 无关文件 | 不动 | 基本没动 | 改了空状态文案 |

错误可以收成五类，后面做工作流会反复碰到：

1. 按钮状态：能读「有四态」，分不清 hover / disabled / loading 的互斥

2. 表格对齐：知道右对齐，做不到列宽和合计行同一把尺

3. 间距：改功能不改呼吸感，按钮和表、单元格 padding 漂

4. 文案：截图里写死了仍被模型「润色」

5. 无关文件被改：上下文一长，手就开始痒

为什么文字懂了，像素却走眼

需求是离散符号：「disabled 无 hover」。截图是连续视觉：灰度、对比、1px 边框、滚动时露出来的那一条缝。模型对前者很强，对后者像「看懂题干、抄错选项」。

长上下文会加重这件事。仓库文件一多，模型优先保证「有对应 class、有 sticky、有合计行」，验收标准被压缩成「代码结构像那么回事」。标注图如果只圈「这里」，不写「不要什么」，它就会用最常见的后台默认值填空。

所以不是「长上下文没用」，而是：长上下文擅长把改动范围找对，不擅长替你做像素验收。

简单数据（一次任务，不是榜单）：两个模型都是一次没完全改对；GPT-4.1 大约 2 轮补到能交差（修 hover 互斥、排除合计行斑马纹、对齐合计列）；o4-mini 大约 3 轮，还要先把无关改动撤回。Token 都在数万到十万出头这个量级，图比多贴一份代码更吃量。

结论：一次改对吗？以及你明天就能用的做法

明确回答：部分能，细节不能。

  • 能一次对上的：找文件、加状态结构、给表格加固定列/合计行这类结构级修改
  • 很难一次对上的：按钮互斥状态、列宽与合计对齐、斑马纹范围、间距、文案、滚动时的穿透

给普通人一份可执行清单。

什么时候该一次性丢仓库
  • 改动跨 3 个以上文件，且互相依赖（按钮组件 + 页面 + 表格样式）
  • 你怕模型局部优化、改完和现有 class 体系打架
  • 你能接受一次请求更贵，但想减少「你漏贴了一个样式文件」
什么时候该拆任务
  • 先结构、后视觉：第一轮只许改状态机和 class，第二轮只对照截图修 CSS
  • 按钮四态和表格对齐不要写进同一条「一次改完」
  • 发现模型开始改无关文件，立刻停，收紧「禁止列表」再发
截图怎么标，更不容易看走眼
  • 一张图一个主题；四态并排，不要只截 default
  • 写「不要出现什么」：disabled 无 hover、斑马纹不含合计行
  • 把错误文案和正确文案写在图上，不要只写在文档里
纯文本 vs 视觉怎么搭配
  • 结构、接口、状态机：纯文本需求就够
  • 对齐、间距、滚动穿透、颜色互斥：必须上图，而且要标注
  • 视觉模型看完图，仍建议你本地跑一遍；AI 的「我对齐了」不等于浏览器里对齐了

实操上我现在固定成三步：整仓 + 标注图做结构；对着跑起来的页面再丢 1 张「错在哪」的图修视觉；最后人工看 hover / disabled / 滚动。GPT-4.1 更适合第一枪，o4-mini 更适合便宜地打补丁，但别指望它一次过像素。

下一篇我会用同一套「截图 + 完整仓库」去测 Claude、Gemini 同类模型，看视觉编码谁能更接近一次过；顺手也会把这次踩坑收成「截图标注的 7 个技巧」——哪些圈法模型真能看懂，哪些看起来很专业、其实完全无效。这只是第一枪。

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#长上下文 #GPT-4.1 #o4-mini #前端开发 #AI编程 #视觉推理 #8848AI #中后台