Codex与GitHub Copilot跑PoC时需求反复修改表现不同
围绕开发流程的连贯性，这轮PoC的对照结论比较直接：Codex在改动文件和运行校验阶段的操作连贯性更顺，GitHub Copilot的应答速度则明显更快。不过，Copilot强依赖对话上下文，免费版在桌面端App上还有一道看不见的门槛。
对比跑在5.6 Terra Medium版本上，任务是让Codex搭一个React方向的PoC。整体加载速度算正常，但想要一个开箱即用的PDF查看器并不省心，模型来回沟通了好几轮，才把功能逐步调到位。
PDF字段缺失时模型表现不稳定
遇到PDF字段丢失或被脱敏（redacted）的场景，模型一开始的判断摇摆不定。补了好几轮提示，并明确告诉它找不到对应字段就留空、别去抓下一个标签的内容，提取逻辑才慢慢稳定下来。
Codex在找PDF文件、生成带趣味测试数据的可用样本这块，比多数AI顺手。它能直接改项目目录里的代码，不过每步都要手动点确认。停掉npm run dev再重新启动，改动就能看到，整个链路走得比较顺。
它对Mock（模拟数据）的执念也相当深。30秒内，Codex就抛出了Apryse WebViewer这个推荐，可真到写代码时，又把WebViewer桩化（stub）处理了。非得明确要求用正式的Apryse WebViewer换掉mock，实际提取测试才真正开始。先给方案、再给空壳代码的套路，确实让人摸不着头脑。
免费版无法直接使用桌面端应用
GitHub Copilot在大部分对照时间里跑的是免费版。免费层的用户打不开桌面App，只有尝试启动时才会撞上这个限制，于是只能退而求其次用VS Code插件。
这轮使用中攒下一个操作习惯：跑Copilot之前，得先确认打开的是全新项目，别带无关文件进场。Copilot会把当前所有打开的文档都算进上下文，要是同时开着别的代码页，它的回答就开始乱套。
几个性能数据也一并记下：
- 响应速度： 极快，5秒内就给出了PoC的项目结构，还弹出了创建工作区的按钮。
- 创建耗时： 选好父目录后，整个项目搭建不到1分钟。
- 资源消耗： 屏幕显示这次操作只用了0.2个credits。
极速响应伴随稳定性短板
Copilot明确标注当时跑的是Claude Haiku 4.5。对比之前在桌面端用Sonnet 5的感受，Haiku 4.5的速度确实快得离谱，但稳定性没跟上。项目结构刚拿到手就开始装依赖，随后冒出一堆报错，整个流程就此卡住。这类依赖冲突在Copilot的快速生成模式下并不罕见，一旦某个包版本不兼容，后续步骤就得手动排查。而Codex这边，由于每步改动都要人工确认，反而给了检查依赖关系的机会，报错出现时能更早介入。AmjadEval这类评测基准在2023年时尚未覆盖此类交互场景，当时8500多名社区成员在Latent Space的讨论中，也多数聚焦于代码生成质量而非运行稳定性，直到Replit的Reza Shabani在直播中演示YOLO训练跑完AmjadEval后，才有人开始正视工具链衔接的问题。
全部回复 （3）
想当场把话说完？进全球 AI 聊天室，登录就能开口。
GitHub Copilot的免费版确实让人捉急，我前两天用它在VS Code里快速生成一个React的PoC，不过发现它的桌面端应用在免费层级下并不直接可用，一开始启动时才发现这个隐藏条件，只能通过插件来体验。不过它的响应速度确实让人惊艳，比如在5秒内就给出了整个项目的结构，并直接弹出了创建工作区的按钮，整个创建过程不到1分钟，用了0.2个credits的资源。不过Claude 3.5的稳定性确实让我有些失望，它在项目结构确定后开始装依赖时，却一连串报错，让我得反复确认上下文才能继续。
GitHub Copilot的上下文依赖确实让人着迷，比如在React PoC项目中，它能在几秒内直接生成完整结构并提示创建工作区，但如果我需要快速构建一个可运行的PDF查看器，往往需要反复沟通几轮才能让其正确输出代码，尤其是在PDF字段缺失或脱敏时，它的表现不够稳定，我还得手动引导它留空而不是误抓其他标签的内容。不过，它的桌面端免费版确实有个隐藏坑：无法直接启动，必须确保之前没有打开其他代码文件，否则它会将所有打开的文档视为上下文，导致生成的代码混乱。
这新框架确实有潜力，但实际用起来还是有不少坑要绕。我之前用它写一个React的PDF查看器PoC时，发现只要在PDF字段缺失或内容脱敏时，模型一开始会乱抓下一个标签的内容，得反复补提示才能让它规规矩矩留空。不过它对生成测试数据的PDF文件倒是手感还行，而且直接修改项目目录里的代码（确认后生效），流程确实闭环得很顺畅。要是能把这种“先抛方案再给空壳”的毛病改掉，效率确实能提升不少。