如何用同一份动效需求公平比较 Claude Code 和 Codex
两段好看的视频，不足以构成对两个编程智能体的公平比较。其中一个可能拿到了更好的素材、更详细的提示词、多一次修复机会，或者另一个没有的工具权限。把截图并排放在一起，看不出这些差异。
动效尤其容易造成这种误判。一个模型能做出惊艳的首帧，却没满足时间要求；另一个做出来朴素一些，但工程可编辑，局部修改后也能正常工作。哪个更好，要看你原本想把什么任务交给它。
比较 Claude Code 与 Codex 的动效制作能力，应先给出相同的验收任务和素材，再检查准确文案、时间安排、控制功能，以及达到可用结果所需的修复投入。下面的实例追踪了一个 Codex 产物的播放、时间定位故障和修复过程。配对测试中的 Claude Code 未能完成认证，所以两个模型的直接比较仍未完成。
选择能检验所需能力的任务
“做一段漂亮的产品视频”留下了太多解释空间。更好的测试既有真实的表达目标，也有明确的技术交付范围。例如，制作一个六秒、可编辑的报价场景，准确显示价格，支持按时间确定画面状态，并让关联文案拥有共同的阅读时段。
画面可以很简单，仍然足以检验重要行为。准确文案考查事实是否保留；稳定停留考查对时间的理解；时间定位控件考查动画是否由时间驱动，还是只能从头按顺序播；局部修改则考查源文件是否仍然可控。
第一次测试不必塞进所有功能。如果同时要求旁白、音乐、字幕、图表数据、多种比例和复杂界面，出了问题就很难判断原因。先选一个小而有代表性的任务，再用第二个任务补测前者无法揭示的能力。
先决定比较的是代码生成，还是完整的智能体工作流程。只测代码时，可以禁用工具、要求输出一个自包含文档，以保持工具条件相同。测试完整流程时，则应让两个智能体在可比权限下查看素材、运行工程并修复错误。这是两种不同的实验，不宜合并成一份排名。
对准备引入工具的团队来说，完整流程通常更有参考价值。需要的成果不只是源码，而是通过实际工作过程得到的正确、可编辑产物。不过，在投入更大的比较前，小规模代码测试能先暴露需求和环境方面的问题。
固定需求和素材
两次运行使用完全相同的需求原文，并在调用任一智能体前保存。如果看过第一个结果后才发现歧义，就同时修改两边的需求，把新的一对结果视为另一次测试，不要只给其中一方补充说明。
本文附带的本地测试要求输出一个1280×720的自包含 HTML 文档。虚构场景名为 Still Studio，必须准确展示“US$29 per month”和“US$348 billed annually”。两行文字都应在0至0.8秒入场，保持稳定至4.8秒，并在六秒前退场。
需求还要求可见的 Play/Pause 和时间定位控件，初始暂停在2.4秒，使用系统无衬线字体，不加载远程素材，并标明这是虚构练习。这些约束便于检查结果，也能排除外部图片或字体带来的差异。
文案和计费关系都很重要。即使排版更好看，只要模型改错了年付金额，就没有满足事实要求；即使源码里有正确的文字，只在最后一刻显示计费条件，也没有满足时间要求。
如果使用真实产品素材，给两边提供相同副本，并保留素材身份。不要让一个智能体使用更新的截图或不同的 logo。如果素材不能再分发，说明获取权限的要求，将比较限制在获得授权的环境内。
记录实际运行的环境
工具名称不能代表完整的运行系统。记录 CLI 版本、本次运行报告的模型、相关设置、可用工具、权限，以及会话是新建还是续接。默认模型可能随时间改变，因此运行时报告的模型比根据产品名称作出的推测更可靠。
区分账号访问问题和模型表现。登录失败、限流或网络中断会影响实际流程，但模型没有生成视频，就无法据此判断它的视频质量。保留失败记录，不要把它换算成创意评分。
本次 Codex 通过 OpenAI 提供方使用 ChatGPT 认证。运行日志记录的 CLI 版本为0.163.0，模型为 gpt-6.1-sol，产物是一个独立 HTML 文档。
认证和配置值得单独核对，因为它们可能决定不同的访问路径。查阅工具自身的文档，记录实际使用的路径；不要把令牌或私密账号文件放进评测资料包。Claude Code 认证文档
修复前先保存原始输出
原样保存第一份响应，同时保存需求和运行状态。如果为了打开 HTML 文档而移除了 Markdown 代码围栏，也要记录这一步。不要悄悄修好语法，再把它称作模型原始初稿。
失败请求和已完成产物分开存放，让测试记录能区分环境准备失败与输出本身的缺陷。
只比较代码时，不经编辑就打开返回的文档。检查规定的文字是否出现，场景能否不依赖远程资源加载，控制功能是否齐全。再播放完整序列，直接定位到入场、停留和退场阶段。
源码中还有一个范围滑块和一个按时间渲染的函数。后续行为测试发现，这些控件虽然存在，却并非全部可用。实际播放能从初始状态推进到3.1秒之后，并在六秒结束时停止。但定位到指定时间暴露了另一处缺陷：显示时间始终停在旧值，没有移动到请求的位置。
先检查信息，再评价风格
先看不可妥协的要求。事实是否准确出现？彼此关系是否正确？观众能否在规定时段读完完整陈述？产物是否使用给定素材，而没有凭空编造界面行为？
再检查时间行为。直接定位到中间、起点、入场边界、退场边界和终点。确定性的动画无论通过什么路径到达某一时间，都应呈现预期状态。如果画面状态依赖前面的帧是否播过，这份源码可能不适合可靠的逐帧渲染。
这些检查之后，再比较视觉质量：层级、间距、字体、动作是否连贯，以及构图是否服务于信息。判断要围绕需求。一段有意保持克制的报价场景，不该仅仅因为另一版加了更多炫目效果就落败。
用几项独立维度构成简明的评分标准，不要只给一个来历不明的总分。事实准确性、时间安排、可编辑性、视觉表达和交付可靠性可能各有优劣。一个总分会掩盖团队真正需要理解的取舍。
后续测试实际发现了什么
播放到六秒后，时间定位故障可以稳定复现。按键盘 Home 不会回到零秒；对滑块发送0.8、4.8和5.4秒的 input 事件，画面也仍然停在六秒。编辑者需要直接查看某个状态，而不是每次从头播放，所以这不是小问题。看得见时间轴，并不等于它能用。
原因出在事件执行顺序。输入处理器先调用 pause()，再读取用户请求的滑块值。但在这份实现里，暂停也会重新渲染，将旧状态写回控件。于是后续读到的仍是旧值。动画计算本身可以正确，用来检查它的控件却已经失效。
作者另存副本进行修复：先读取请求值，再暂停，然后应用该值；模型的原始输出仍然保留。
// Preserve the requested value before pause() renders the old state.
const requestedTime = Number(seek.value);
pause();
state.time = Math.max(0, Math.min(motion.duration, requestedTime));
render();
修复后，键盘 Home 和 End 能分别定位到零秒和六秒。在0.8和4.8秒，两行价格文字都完全不透明，且没有位移；在5.4秒，两行文字的不透明度都为0.5，并向上移动18像素。
直接编辑 contenteditable 文本，将价格改为 US$39 per month 和 US$468 billed annually 后，两行在2.4秒仍同时可见。后续验收还应保存、重新加载并渲染这些修改。
查看显示的时间，是区分播放故障与时间定位故障最快的办法。本例中，原始产物正常播放时会向前推进，但之后却不响应对特定状态的请求。修复只调整事件处理器的执行顺序，保留了入场与退场曲线。放进双智能体测试中，这就成了一项具体的修复任务：修好时间定位，保留六秒时长和两行价格，再检查 Home、End 以及一个中间时间点。
提出相同的局部修改
第一稿只完成了半个任务。对两个成功运行都提出同样的修改，例如调整月均价格与年付总额，保留布局和时间安排，并让两条陈述继续同时可见。这能检验智能体能否只修改有明确边界的部分，而不必重写其他内容。
保留原始源码，将修订稿与之比较。检查文字、几何布局、时间、控件和素材引用分别发生了什么变化。看起来相似的结果，可能藏着损坏的时间定位控件，或结束时点的偏移。源码差异很大也不一定有问题，只要最终行为正确，但仍值得逐项检查。
事先规定允许投入多少修复。如果一个智能体拿到三轮越来越具体的提示，另一个只有一轮，就应如实报告，而不是把最后两份成果说成条件相同的首次尝试。指导也是获得可用结果的成本。
测试完整工作流程时，允许两个智能体在可比权限下运行、检查各自产物。记录实际使用的工具，以及需要的人为干预。发现并修好加载错误，本身就是有价值的工作，只看截图的比较会漏掉这一点。
测量成本，不编造精度
耗时容易记录，也容易误解。本次 Codex 请求约用179秒，其中包含日志记录的启动和模型发现超时。这并不是纯粹的生成速度。如果写成“Codex 做动画需要三分钟”，就超出了实际测量能够支持的结论。
更有用的比较是在工具允许时，分别记录环境准备、请求、修复、渲染和人工检查的耗时。得到可用产物的总时间，可能比响应延迟更重要。初稿很快，却需要多次细致修复，整体上可能比慢一些但正确的结果更费力。
没有真实计费背景，不要根据耗时或 token 数推算美元成本。订阅用量、API 计费、缓存输入和模型设置都可能不同。拿不到可信成本，就报告可观测的用量信息，将成本保留为未测量项。
记录运行中的失败，但要分清类型。认证配置问题不同于模型生成无效代码；渲染依赖失败也不同于设计难以阅读。这样区分，比较才能同时帮助团队选择工具和配套流程。
重复有代表性的任务后，再得出宽泛结论。一个简单场景能揭示一种失效方式，却不能证明某个智能体在产品发布片、技术讲解、图表、本地化乃至所有未来动效任务上普遍更好。
让人工协助可见
公平比较也应记录操作者在两次请求之间做了什么。安装缺失的软件包、寻找素材、纠正文件名或解释错误，都可能明显改善最终结果。如果这些帮助被隐去，就会把人的贡献算到智能体头上。
先决定哪些帮助属于测试范围。在真实流程中，操作者回答产品问题或批准文件访问很合理；在受控的代码生成测试中，手动修源码就已经改变了被评估的产物。两种做法本身都没错，问题在于把一种说成另一种。
保留简短的干预记录。例如，操作者给两个系统提供了同一张截图，为双方解释了一处计费措辞，或在打开任一产物前修复了本地服务器。只有一个系统需要修复时，也要记录。即使最终视觉效果同样好，这些额外投入也可能影响团队决策。
多轮运行中，还要区分操作者的学习和智能体的表现。测过第一个系统后，操作者可能更理解任务，因此给第二个系统更有帮助的指导。交替运行顺序，或开始前固定所有输入，有助于减少这种优势。小规模本地测试无法消除所有变化因素，但可以把它们呈现出来。
动效尤其需要这种透明度，因为精致画面很容易让人迅速下判断。需要人工仔细调整时间的结果，不应被描述成未经修改的一次生成。读者仍然可以欣赏成果，同时知道它是如何完成的。
提供别人可以检查的结果
可信的比较应包含需求、素材集或获取方式、环境记录、原始输出、修订提示、渲染设置和实际检查结果。读者不必只相信一张好看的对比图，也能理解结论从何而来。
让结论与具体要求对应：初始状态的准确文案通过，播放能到终点，修复前的时间定位失败。后续的配对测试可以沿用同一份需求和检查项，比较两个智能体如何诊断、修订产物。