用 Codex 和 GitHub Copilot 跑 PoC 验证，需求变来变去真能撑住吗

直接说结论：如果追求无缝的开发体验，Codex 在处理文件修改和实际运行验证时更流畅，但 GitHub Copilot 的响应速度快得离谱，只不过它对上下文的依赖极其敏感，且免费版在桌面端应用上有坑。

用 Codex 跑 React PoC 踩到了哪些点

在用 5.6 Terra Medium 版本测试时，我让 Codex 帮我写一个 React 的 PoC。整体加载速度还可以，但想要一个真正能跑起来的 PDF 查看器并不简单，我跟它反复沟通了好几次才把功能跑通。

最让我在意的是数据的提取能力。当 PDF 里的数据缺失或者被脱敏（redacted）时，模型最初的表现不够稳定。我得不停地给它递“提示”，引导它在找不到字段时直接留空，而不是自作聪明地去抓下一个标签的内容，这样才算把提取逻辑理顺了。

有个细节挺有意思，Codex 在寻找或生成带有趣味数据的有效 PDF 文件方面，比其他 AI 要强。而且它能直接修改目录里的代码（当然是在我点击确认后），我只需要停掉 npm run dev 然后重启，就能看到更新结果，这个闭环跑得很顺。

不过 Codex 有个怪癖：它太喜欢写 Mock（模拟数据）了。最离谱的是，它在 30 秒内就给我推荐了 Apryse WebViewer，结果在写代码时居然把 WebViewer 给 stub（桩化）掉了。我得明确要求它把 mock 替换成真正的 Apryse WebViewer 才能开始实际的提取测试。这种“先给你方案，再给你个空壳”的操作确实让人摸不着头脑。

GitHub Copilot 的速度与上下文陷阱

这次测试我大部分都用了免费版，结果在 GitHub Copilot 这儿栽了个跟头：免费层级用户没法直接用它的桌面 App，我尝试启动时才发现这事。最后我只能在 VS Code 插件里跑。

这里有个实操经验：用 Copilot 之前，一定要确保你处于一个新项目，且没有打开任何无关文件。因为它会把当前所有打开的文件都当成上下文，如果你之前开着其他代码页，它的回答会变得非常混乱。

关于性能和模型，有几个数字值得记录：

• 响应速度： 极快。它在 5 秒内就给出了 PoC 的项目结构，并弹出了创建工作区的按钮。
• 创建耗时： 我选好父目录后，整个项目创建过程不到 1 分钟。
• 资源消耗： 屏幕显示这次操作只用了 0.2 个 credits。

而且当时它明确告诉我它正在使用 Claude Haiku 4.5。对比我在桌面端用 Sonnet 5 的体验，Haiku 4.5 的速度确实惊人。但快并不代表稳，在拿到项目结构开始安装依赖后，我立马遇到了各种报错，这让之前的快感瞬间打折。