Gray's grind

2025年我的AI Coding使用评测

2026/01/03 EC

2025年里ai coding有一波非常大的能力增长，随着模型能力/agent工具/IDE整个上下游能力的变化，我的使用策略也在不断调整，所以写一篇blog记录下今年我的工具箱变化。视角很不专业，纯粹是一个使用者角度体验（belike 使用评测）。

inspired by:

写作逻辑比较随意，想到哪写哪。 （llm仅做用词的调整，并根据内容抛了些问题，作为观察章节写下）。

目录

2025年使用的不同阶段

第一阶段

关键词: Cursor

多年前首批用上了github copilot，那时候觉得很牛逼，发pyq说现在有人和我随时结对编程了。但事实上那个时候的copilot是一个不及格的半成品，补全一个func call甚至参数的数量都会写错，某种意义上更是打乱心流的噪声。chatgpt爆了之后，涌现出一堆ai coding的vscode插件，比如codeium/continue之类的。再后来24年下半年Cursor很火，试用了之后，我直接rm了vscode。

基本25年的上半年，我仍然是靠Cursor来满足我的ai coding editor的需求。Cursor的优势非常明显，就是Cursor提供了交互友好且一揽子的方案，同时从vscode迁移过来绝大部分东西都可以继承。对我来说最关键的点是交互，review diff/行内对话/光标预测上的体验都很好。
比如让写一部分代码，我可以很清楚地通过行内by word的diff看到他做了什么，而vscode+插件的方案只能拉一个很不明显的双栏对比。那个时间点上这些体验侧的功能在竞品上有很大差距。另外cursor上chat之类功能也可以接自己的api来避开限额的问题，再另外还可以无限续杯。
但复杂的设计问题上，我还是基本依赖外部的chatbot去讨论并形成方案，通过自建openwebui之类的服务，可以并行多个头部能力的模型一起讨论问题。

此时agent的体验对我来说更像是一个fancy toy。我不好说是受限于模型agent能力还是本身产品的问题，大部分时候的使用体验是拿不到正确上下文，鸡同鸭讲，甚至自己把自己干死循环都是常态。这样一个输出质量根本不稳定的工具，实在很难让人把他放置到工作流中。所以，这个时候的vibe coding对我还有点远。

所以第一阶段的情况大概是，我的工作流仍然是一个以我编辑体验为主的IDE，以及一个紧密协作、方便交互的inline chatbot辅助。更复杂的任务则直接用外部的chatbot，手动提供context。

第二阶段

关键词：CLI Agent

这个阶段的game changer是claude code等cli产品。
cc是我第一个用上的可以offload相对复杂或长流程的任务、可以all in one地去完成的agent。但我很快就发现了缺点（或者说是我的缺点），就是token的消耗太快了，而且稳定第三方获取anthropic token一直都比较贵，另外还有封号问题，所以很快发现烧不起token之后，我又回退到Cursor+chatbot的组合。

话说是不是到现在cc的订阅方案等价换算token后的价格应该都还是比友商贵的？

同期也有很多类似的ide/cli工具，但我并没有觉得比Cursor+chatbot产生什么质变，缺乏去做迁移的动力。毕竟还得新的适应过程，直到gemini-cli发布。

虽然gemini-cli初期也有很多问题，但他们迭代速度真的很快（可能也得益于开源吧）。同时因为有每三个月刷新的神秘$300额度，我直接在所有机器/vm上都装了gemini-cli。这个时候发现cli工具的美妙之处在于，先不说任务难不难，但真的可以做到全流程offload。直接terminal一开，ssh上去tmux里拉起就可以异步发布活，不需要任何额外东西。尤其各种部署/迁移的活可以全offload掉。

差不多时间段因为实习，迫于红线无法用各种闭源模型方案，折腾了很多替代方案，但体验都差口气，发现有明显的代差。
IDE/Editor体验上，Lxxxx/Axxx之类的方案不仅仅只能用能力差的基模，甚至不能正常c/c++ intellisense。插件based的方案问题见上。
cli工具上像qwen-code这些刚发布的时候，问题还是挺多的。也试了下套了一层router之后用cc的方案，但自测还是和用自家模型的体验差距明显。
当然，这事实上这只是个时间问题，这里的gap现在肯定缩小很多了，毕竟各方面能力都拉齐了很多。

同期有各种更上层的、通过拉起vm/ack干活的agent方案，给一些简单的长链路的活，觉得体验还可以。比如用接入k2的aone agent做了很多看代码的活，用manus做了很多爬虫的活。但对我来说，这类通用方案的问题在于，我绝大部分的任务都是强依赖各种软硬件环境的，虚拟化的通用环境没法闭环甚至没法编译起来，实用性差了不少。

第二阶段对我来说最令人兴奋的就是，cli工具让工作流产生了质变。
但用gemini-cli的时候仍然感觉一些更复杂的编写任务，即使有明确方案和实现路径和参考代码，即使在并不大的单库里，gemini-cli也很难实现好，更别说oneshot。

第三阶段

关键词：Codex

当发现社区都在讨论 “Codex牛逼” 和 “阅尽千帆，归来还是VSCode” 之后，感觉好像有点out了。叠加发现Cursor的一些烦点：

  1. 价格。低价的小杯订阅限额严重，自定义API则不支持很多新feature。
  2. 稳定性。一些新插件支持有问题（比如codex看不了diff）。
  3. 性能。cursor和gemini-cli都略重，某些小vm上会撞各种问题。

于是抄社区作业，开始用vscode+copilot+codex+抄别人的agents.md
马上发现copilot实际上已经把交互体验上的问题补全得七七八八了，该有的基本都有。不过能力也还是差不多(用opus)，然后订阅给的quota也不多。

而codex给了我很多意外惊喜：

  1. 订阅性价比好
  2. rust真不错，好轻好轻
  3. codex表现出来的解决任务能力明显比gemini-cli好

我没深度用过cc，没啥发言权。但codex真的比同期的gemini-cli要强太多，在plan mode下讨论好的复杂任务，有很高概率是可以one-shot解决。然后开始给codex布置各种类型任务，完成度经常超预期。比如自己gdb做debug找问题，然后闭环自测。或者自己perf抓指标做profiling。
在小任务上或者design明确且稳定（就是后面也不会因为什么偏移）的任务上，codex的表现相当相当好。受限人类的带宽，总是会有些想写的东西是没法写的，现在codex就是这类任务的疯狂的加速器。

我现在的开发纯代码量上，确实codex完成了绝大部分东西，比我写的好太多快太多。但从100% vibe coding的终极目标来看，我的使用场景下还是需要很多额外的干预。主要是一些对性能有极限需求的原型系统上，codex的防御性太强，实现上很多hacky的动作除非强调，不然不会做；设计上也是，比如按需求可以做无锁的地方，它也不会榨干。（这部分展开见能力边界）

所以现在agents.md还是重要的，再叠加尤其如果你经常换不同类型项目开发的话，才能对齐好需求上的context。（比如一会写汇编，一会写前端）

一些其他产品上

  • 尝试了一些任务用github的copilot，使用上确实比较直觉，甚至你可以在手机上让提pr，就是速度有点过于慢，然后智力其实还是挺有限。
  • 看到很多worktree类型管多agent的产品/feature，我需求比较弱，很多时候还是倾向线性做病并尝试教它做对。当然还是有很多越写越多分叉问题的任务，可能也挑战带宽，后面会尝试下！

总结下这个阶段，codex软广。

一些随机观察

护城河

护城河是什么，感觉这是个对用户来说很难回答好的问题，怎么说都像是暴论。。
都说今年scaling law放缓，基模能力提升变慢，但我的体感是基模仍然很重要。迁移到codex上之后，每一次新发版都可以感觉到一些提升。所以我觉得不仅仅是说一些agent能力榜，可能还是有很多关键链路上的指标需要拿出来量化做优化。所以我对“应用能力和模型能力是紧密结合的”这个观点是买单的（所以买xxx call吧）。

attention is all you need

人的attention很重要。最终的产物还是需要review（当然可能有的开发者的角度来看，可能不一定要review source code了），所以人的带宽仍然还是瓶颈。
cursor对我最早的爽点就是review压力很小，tabtab又tab。cli的爽点之一是无缝嵌入到现有的工作流程里。
大家肯定都倾向选择把活干对的方案，然后才去考虑什么速度价格的问题。头部能力的模型和agent在这方面的号召力肯定拉满，而且可以规避掉迁移成本的问题。
我觉得我目前的工作流里还是有很多交互/review上的开销，可能未来还存在某种更优解吧。

MCP没用？

好多人说mcp没用。其实换个角度看这个问题，应该说你的工作流在原来CLI shell里是不是已经完备了，如果是那ok。
但cli显然不是掌握世界信息的，这世界上还是有很多东西没接口、不让爬，所以还是需要给某种交互形式。尤其对我来说coding agent已经不仅仅是用于开发，它某种程度上已经变成一个cli入口，但事实上的assistant，所以我需要它有更大的输入输出范围，mcp至少现在是可用解。

能力边界

秋招里不止一场面试有人抛出来聊ai coding能力边界的问题。我觉得了解和明确边界肯定是一个重要的东西。显然目前coding agent离理想状态还很远，所以还是需要付出精力把最后一英里（or 最前一英里）补齐。

  1. 我现在的体感是coding agent就是一个没context的senior的开发。所以只要缺乏正确的context，计划不完备的任务，产出就可能控制不住质量，非常自信的它会走向一塌糊涂。
  2. 大的项目里驾驭能力有限，不一句句聊好plan好，就总有捞不出来正确context的问题。
  3. 而有些问题，你和它就算讨论了plan后也规避不了。你看着task list没什么问题，但总有变量你控制不好且预期不到，你脑子里的先验它也不知道，于是它在某个十字路口选了和你对不齐的选项，后面就开始出问题了。所以我不太喜欢先vibe个架子再开始优化，感觉看了头大，还是喜欢拆解了做好。
  4. 再进一步，你也是会错的。llm还是不耐挑战，太顺从了，如果能反过来多挑战你的design就好了。
  5. 最后前面也说过，llm做high level design上和人还是差很多，更别说给idea了，大部分时候就是能做一个正确的但离好还很远的设计（当然话说回来，很多时候也不需要什么好的设计）。

End

最后，感觉虽然赛道很多玩家很红海，但感觉还没出现特别收敛的结果，期待明年新的变化，给我们使用者多一些加速。

Search

    Table of Contents