四款 AI 编程助手同题实测:各有何长处
作者让 Cursor、Copilot、Codex 和 Antigravity 按相同要求构建看板应用,主观评价 Codex 首版质量最好、Antigravity 界面与浏览器测试更突出。文章同时比较 IDE 自主工作流和 GitHub 协作适配,并强调明确需求与迭代验证。
AI 深度解读
同一个 SprintBoard 冲刺看板应用,交给 Cursor、Copilot、Codex 和 Antigravity,谁做得更好?作者的结论是:Codex 的第一版最完整,Antigravity 的界面打磨和浏览器测试更突出,另外两款则各有工作流优势。
但这份比较更适合拿来筛选工具,不适合当作排行榜。作者没有提供可复核的评分和测试数据,真正能直接借走的,是他们让四款工具完成任务的那套流程。
四款工具各自赢在什么地方
作者给四款助手相同的项目和指令,都按同一个循环推进:打开项目 → 提供上下文 → 构建 → 审查 → 测试 → 迭代。任务是开发 SprintBoard,一个用于管理冲刺任务的 Web 看板应用。
针对这个项目,作者给出了四种不同的优势判断:
- OpenAI Codex(GPT-5 family):第一轮构建最干净,作者介入最少,产出也最接近生产质量。它的优势集中在首版完成度。
- Google Antigravity(Gemini 3.5 Flash):UI 打磨最好,还会在浏览器里测试自己的工作。作者认为它的代理式工作流推进很快。
- Cursor(multi-model、Composer):IDE 内的自主工作流最突出,规划和调试能力较强,也允许随时切换模型。
- GitHub Copilot(multi-model、集成在 VS Code 内):如果已经长期使用 VS Code,或者团队围绕 GitHub issues 和 pull requests 协作,它最容易融入现有流程。
这里的「最好」指向不同环节。首版代码完成度、视觉细节、自动推进能力和团队协作适配,并不是同一项指标。选型前先确定自己最缺哪一环,比直接照着顺序选更有用。
为什么相同项目仍然比不出客观冠军
相同项目、相同指令,能减少一部分比较偏差,但还不足以把差异归因到工具本身。
四款工具使用的模型并不相同。Codex 只标注到 GPT-5 family,没有给出具体型号;Cursor 和 Copilot 都支持多模型,原文也没交代实际选用了哪些模型,以及是否在过程中切换。因此,这次比较同时混合了模型能力、工具设计和作者操作方式的影响。
原文也没有提供耗时、成本、人工介入次数、缺陷数量、测试通过率或重复实验结果。「介入最少」「最接近生产质量」都是作者的使用感受,无法据此判断优势究竟有多大。
Antigravity 在浏览器里测试自己的工作,是一个具体的行为观察;但作者没有说明测试覆盖哪些交互、检查了哪些结果。能启动浏览器验证页面,并不等于已经完整验证了应用。
真正能复用的是哪套工作习惯
作者认为,工具排名没有工作方式重要。同样的四个习惯,让这些助手都能产出有用的结果。
第一,提示词要明确。除了描述要做什么,还要写清楚什么状态才算完成。第二,提供正确的上下文,把助手指向相关文件和项目规则,减少它猜需求、猜约定的空间。
第三,接受代码前阅读每一份 diff。第四,保持小步迭代,持续执行构建、测试、修复,而不是等整个应用生成后再统一验收。
这篇最值得保留的结论,是把「完成」定义清楚,并让审查和测试进入每轮迭代。
作者还提到 Claude Code,但它没有参加这次 SprintBoard 比较。作者将它用于更大的项目,包括 AI 法律文档生成器和多代理无人机运营平台,涉及 MCP servers、skills、sub-agents、hooks 和 plugins。这个补充说明了作者的使用场景,不能用来推断 Claude Code 在本次任务中的名次。
我的判断
我认同按工作环节选工具:需要更完整的首版,就重点检查首轮产出;重视页面效果,就检查视觉结果和浏览器验证;团队已有 VS Code、GitHub 协作流程,也应该把接入成本算进去。
但作者声称「工作流比工具更重要」,仍然属于经验之谈。原文没有比较同一工具在不同提示词、上下文和计划下的表现,因此没有直接证明这些因素的影响一定大于工具差异。
此外,这篇内容来自作者的「AI Coding Agents」课程,课程包含 8 个真实项目,覆盖上述四款工具及 Claude Code。它有明确的课程推广背景。可以把它作为试用方向,采购或团队统一选型仍需要自己的任务验证。
能拿来做什么
- 用团队熟悉的一个 Web 页面或小型功能做试用题,给各工具相同的需求、上下文和完成标准,再比较实际产出。
- 把作者的主观评价改成可记录的项目指标,例如首版缺陷、人工修复次数、完成耗时,以及浏览器里实际验证过的交互。
- 在日常 AI 编程中固定执行「构建 → 审查 diff → 测试 → 修复」,每轮处理较小的改动,减少问题累积。
- 已经使用 VS Code 和 GitHub 协作的团队,可以先验证 Copilot 的融入程度;需要比较其他工具时,再围绕首版质量、UI 和调试分别验收。