大家好，我是不会喷火的小火龙。

GPT-6 Astra 一出来，官方文档里反复讲的就是一件事：端到端复杂任务执行。说白了就是，你给一个复杂需求，模型从头做到尾，中途还能接受你的反馈继续改。

作为一个每月 Token 开销不低的实战党，我对这种宣传向来是"先做再说"。这次我决定用一个真实项目来验证：让 GPT-6 在 Codex 环境里，从一份详细需求开始，完整交付一个互动式 3D 锦鲤池。

这篇文章会从公开资料出发，经过需求交付和功能验收，再到我不满意之后的返工过程，用可观察的行为和实际改动来评估 GPT-6 的能力边界。所有截图来自真实项目页面，所有数据来自开发验收记录。

改模后的锦鲤池当前版本。静态截图能看全景和体型，但不能证明交互和性能。

一、先看公开资料：GPT-6 到底在强调什么

动手之前，我先把相关的公开资料过了一遍。

官方模型文档把 Astra 定位在复杂推理、编码、电脑操作、研究和文档创建。页面标了 1,050,000 token 上下文和 128,000 token 最大输出。当然，这些是产品规格，不是我在自己项目里测出来的数字。

使用指南着重讲了两个能力：跨代码和浏览器的多步骤执行，以及工作进行中接受新要求并调整方向。这两点跟我想观察的问题刚好对得上，我把它们记下来当观察项。

OpenAI 开发者博客上还有一篇用 Astra 做浏览器游戏的实践文章，作者 Thomas Ricouard 用 Codex 开发了一个完整的浏览器游戏，过程涉及目标设定、反复测试、截图检查和视觉返工，人依然负责最终审查外观和手感。这是我目前看到的跟锦鲤池最接近的官方案例。需要注意的是，这是厂商员工的实作，不能当独立第三方评测。

外部评测方面，TrueStandard 的首周评测可以了解外界反应，但它的性质要注意：作者明确写了自己没有跑基准测试，内容主要是公开演示和资料的整理汇总。拿来当独立实验引用就不合适了。

看完资料，我给自己列了四个观察点：实现完整性、交互因果关系、返修能力、验收边界。至于百万上下文窗口、异步工具调用这些，在这个项目里用不到的我就不硬塞了。

二、为什么选锦鲤池：它会同时暴露好几种问题

选锦鲤池不是随意的决定。这个项目的需求本身就够复杂：鱼群要在水里游动，触水要有涟漪反馈，投喂食物后鱼要游过来吃，昼夜循环要联动灯光和音效，手机竖屏也得能正常操作。而且所有 3D 模型、鱼身花纹、水面效果、环境音效全部要由代码程序化生成，一个外部贴图文件都不用。

我提交给 Codex 的是一份详细的规格文件，写清了鱼群数量（桌面 12 条、手机 8 条）、六种花色、水面动画、投喂机制、昼夜切换、声音控制、画质设置。这里要特别说明，这不是一句"帮我做个锦鲤池"就完事的任务。

这个项目的好处在于，它同时考验图形渲染、行为逻辑、界面布局和工程协调。鱼得会游，还得长得像锦鲤。投喂得有响应，鱼不能隔着半个池塘瞬移过来。昼夜切换得好看，灯光变了鱼的颜色也要跟着变。这些子系统单独做不难，让它们一起正确工作才是真正的考验。

三、第一版已经能玩了，我先看鱼到底有没有吃到食物

第一版交付后，项目在浏览器里跑起来了。庭院、水面、鱼群、投喂按钮、昼夜切换、声音控制，功能入口都在。

我没有看到"哇好漂亮"的截图就直接验收。我最关心的是交互逻辑有没有串起来，所以直接从投喂开始测。

点击投喂按钮，9 粒食物撒到水面。鱼群从不同方向靠过来，游到食物附近后吃掉一粒、消失一粒。

第一版的锦鲤池全景。庭院和水面已成型，鱼在游动，但鱼体和鳍面的细节还没达到预期。

它验证的是一条完整的交互因果链：用户点击 → 食物出现在水面 → 鱼从游荡状态切换到觅食 → 鱼朝食物游过去 → 到达一定距离后食物被消耗移除 → 鱼短暂减速然后恢复游荡。每一步都涉及状态管理和事件驱动，哪一步断了画面上都能看出来。

除了投喂，初版还跑了十分钟长程模拟（36,000 步），验证鱼群没有越界、速度没有数值溢出。惊扰测试确认了触水后鱼会加速散开，6 秒内平复。还有防瞬移保护：就算浏览器切后台挂了 50 秒再回来，单帧位移也被限制在 0.1 单位以内，鱼不会开屏飞出去。初版 6 项行为测试全部通过。

手机端方面，桌面浏览器模拟的 390×844 视口下，锦鲤减少到 8 条，没有横向溢出，按钮和文字正常显示。不过，这是桌面浏览器模拟视口，不是真机测试，帧率数据也是桌面的，不能说"手机上跑 120 帧"。

到这一步我的判断是：GPT-6 通过 Codex 确实做出了一个有状态、有因果的可运行作品。行为测试能通过，工程管道是通的。

可是，这些测试回答的都是行为问题。审美问题，一项也没有覆盖。

四、然后我说了一句：锦鲤的建模不对

功能检查做完，我放大画面仔细看了看鱼。

然后我跟 Codex 说了一句："锦鲤的建模不对，你去谷歌上调研一下就知道了，我喜欢那种写实风格但又比较精致的。请你修改。"

为什么不满意？第一版的鱼体轮廓太均匀，从头到尾差不多粗细，少了锦鲤特有的肩宽尾窄的体型。鱼鳍是扁平的片状，没有扇面的透明质感。花纹和鳞片也偏粗糙，整体更像卡通鱼。

我的需求文件里写的是"偏写实、精致"的风格。6 项行为测试全部通过，投喂逻辑完美运转，可我一看画面就知道这不是我想要的锦鲤。

这个落差挺有意思的。传统软件里测试通过就基本可以交付，但做图形项目不一样。"鱼行为正确"和"鱼看起来像锦鲤"是两层完全不同的验收标准，后者目前没有什么自动化的手段。

改模后的全景。与上图初版对比，体型和花纹变化可见。两张图是不同动画时刻的截图，鱼群位置会变化，不能作为逐像素对比。

另外要交代一个事实：Codex 在执行调研时去谷歌搜了锦鲤图片，但图片搜索页超时了，养殖场的正文返回了 403。实际可用的参考主要是我提供的截图附图，不能写成"完整研读了专业解剖资料"。也没有把网上的图片直接用作贴图素材。

五、这次返工，改到了鱼身结构和贴图方向

收到反馈后，Codex 开始重建鱼的模型。改的东西比我预想的多。

先说体型。 原来的鱼体接近均匀筒形，现在换成了 11 个控制点的三次 Hermite 样条曲线。从鱼嘴到鱼尾，截面宽度先从极窄增长到肩峰（半宽 0.308），再连续收窄到尾柄极细处（半宽 0.078）。肩宽约为尾柄的 4 倍，这就有了锦鲤那种"前宽后窄、肩膀最壮"的特征体型。代码还在背脊线额外加了一道隆起，塑造出脊背的厚度感。

再说鱼鳍。 从扁平三角片改成了带径向细分的扇面网格，每片鱼鳍 48 条射线、12 层环带，共 637 个顶点。生成时还给扇面注入了一道微弧，消除了纸片般的平板感。改完一共 6 片鱼鳍：一对胸鳍、一对腹鳍、背鳍、以及带分叉的双叶尾鳍。鱼还加了侧置的嵌入式眼球、口唇弧线和两根从嘴角撇出的触须。

然后是鳞片和花纹。 鳞片画在 2048×1024 的离屏 Canvas 上。鱼头前 20% 的区域保持光滑不画鳞片，模拟鳃盖和吻端的质感。身体部分用交错排列的弧线绘制覆瓦状鳞片（砖墙式的半步交错），同时在凹凸贴图上对应位置画深灰描边，让鳞片在光照下有微浮雕的立体感。六种花色各有独立的配色逻辑，比如红白（Kohaku）是白底加几块有机形状的红斑，边缘用 28 个极坐标采样点加多频谐波扰动生成，不是死板的椭圆。丹顶（Tancho）则是全身纯白、头顶正中一颗圆润的红印。材质用了 clearcoat 层模拟鱼体表皮的湿润光泽。

改模后六种花色的近景。这个页面使用独立照明并去掉了水面遮挡，专门看鱼身细节，不是正式的池塘画面。

最后说一个有意思的 bug：花纹贴反了。 改完模型后我发现，本来应该画在背部的花纹跑到了肚子上。查下来是 Three.js 默认贴图行为导致的。鱼身的 UV 映射里，纵坐标 0.25 对应的是鱼的背脊线，0.75 对应鱼腹。Canvas 画花纹时也把斑块画在 y=0.25 的位置。但 Three.js 默认 texture.flipY = true，会把 Canvas 上下翻转再传给 GPU，于是 0.25 就变成了 0.75，背部花纹就跑到腹部去了。修复就一行：

▼
typescript
复制代码
map.flipY = false;

颜色贴图和凹凸贴图都要设。这个修复只在本项目的 UV 映射方式下成立，不能直接当通用建议。

夜间状态，灯光和色调联动。静态截图不能证明切换过程的流畅度。

改模后重新跑了构建（通过）、lint（通过）和测试（9 项全部通过，比初版多了几何校验）。新增测试验了什么？肩部宽度大于头部、肩宽是尾柄细处的 3 倍以上、沿全长密集采样 1000 个截面点无畸变跳变、背脊顶点的法线朝上且 UV 纵坐标精确等于 0.25（这条直接证明了几何和皮肤贴图的对齐）、6 片鱼鳍各 637 个顶点全部为有效浮点数。

测试通过说明几何和贴图在技术层面是对的。但"看起来像不像真正的锦鲤"？这是程序化生成加艺术化处理的模型，跟照片级写实还有距离。

六、如何评价 GPT-6，以及如何测下一款模型

用这个项目的实际经历，我按四个方面来评价。

工程完成度：给的是一份包含鱼群、水面、投喂、昼夜、音频、响应式布局等子系统的详细需求，交回来的是一个在浏览器里能跑的完整项目，构建和 lint 都通过。对这个复杂度的任务来说，能一次交付可运行的工程，表现是好的。

交互逻辑：投喂的全链路验证（9 粒食物从撒下到被吃完）证明状态管理和事件驱动是通的。鱼群觅食、边界回避、惊扰恢复、防瞬移保护也都有行为测试覆盖，6 项初版测试全部通过。

返修能力：收到"建模不对"这个定性反馈后，模型没有只调几个参数敷衍了事，而是重建了体型曲线（11 控制点样条）、鱼鳍结构（扇面细分 637 顶点）、鳞片花纹（覆瓦交错加有机斑块），还找到并修正了贴图方向的 bug。改动产生了明确的视觉差异，测试也从 6 项增加到 9 项。这说明代理能把审美反馈转化成具体的代码修改。

验收边界：代理自己做的验收集中在行为和工程层面，没有办法自动判断"鱼看起来像不像锦鲤"。这一层验收需要人来做。

做个总结：在 Codex 工具环境下，GPT-6 能串起一个复杂交互项目的实现、检查和返修，这在我这个项目里是成立的。功能检查完成后，视觉和体验层面的验收仍然需要人来判断和拍板。

如果你也想测一款 AI 编程工具的实际水平，我的建议是：选一个你自己熟悉的项目，记录输入和每次人工干预，把测试数字和视觉感受分开评价，最后把结论限定在你的实验条件内。这比看排行榜上的分数靠谱得多。