夜雨聆风最近刷到不少这种内容:《实测!5款AI编程工具谁是王者》《XX模型吊打XX模型,差距断层》。点进去看,跑分、对比图、结论一套一套的。
说实话我没太想明白,这类内容图什么。就算测出A确实比B强一点,那又怎样?工具排名跟你能不能解决自己的问题,压根不是一回事。这种内容看多了,除了让人觉得"我是不是又落后了",好像也没剩下什么。
用了这段时间的agent工具,越用越觉得一件事挺明显的:
AI说到底是个放大器,不是路本身。你算力配得再高、订阅买得再贵,如果自己没想清楚要往哪走,这些投入其实用不太上。真正拉开差距的,还是你有没有找准需求,把手头的事情做扎实。
这段时间为了想清楚这个问题,市面上主流的agent编程工具我基本都试了一圈——国内的腾讯WorkBuddy、阿里Qoder(国内版、国际版)、trae(国内版、国际版),国外的codex、cursor、opencode。挨个试下来,光是这个过程就花掉了不少时间精力,倒也算是应了前面那句话——工具本身不重要,重要的是你到底想解决什么问题。
试用下来有三点体会,分享一下,有些一开始接受起来挺别扭的。
一、Agent对工作流,基本是重构,不是辅助
一开始以为agent编程无非是"帮你写代码快一点",用下来发现完全不是这么回事,它对原有工作流经常不是助力,是直接推翻重写。
举个自己踩的坑。我有个Django项目,以前学html的时候特意去学了scss,图的是能定义变量方便复用。结果用agent改项目时,经常改了半天页面没变化,排查了好一阵才发现——就算我明确指定了样式文件的修改目录,agent还是会跑去直接改css。项目里用的 django-sass-processor会调 libsass,自动把scss覆盖成css,所以我看到的永远是"改了但没生效"的假象。
后来想通了,与其教agent遵守我的目录规范,不如干脆不用scss了。都已经在用agent写代码,这层为了复用变量而存在的封装,反而成了累赘。
这背后其实是个更大的思路转变。人写代码习惯性追求抽象——面向对象也好,把各个app的静态文件统一汇总到根目录下的文件夹也好,本质上都是站在"人"的角度做的组织方式,方便人去理解、复用、维护。但agent不是这么工作的。对agent来说,如果一个app的所有内容(模型、视图、模板、静态文件)都自包含在自己的目录里,修改这个app的功能时,它只需要读这一个app的上下文就够了,不用把整个项目的结构都装进"记忆"里去理解。反过来,东西越汇总、越抽象,agent改起东西来上下文就越大,越容易改串、改漏。
以前觉得理所当然的一些工程习惯,放到agent时代可能就是负担了,该扔就扔。
二、模型选得对不对,关键看合不合你的需求
这条我一开始想得比较绝对,后来发现不太对。
前段时间处理一个日期问题:数据库里存的deadline是UTC时间,view层转成纽约时区后打印出来是对的,8月4日。但前台页面渲染出来一直是8月5日。排查了挺久,最后发现是个联动bug——项目开了 USE_TZ=True,模板里又用了 |date过滤器,这个过滤器会"贴心"地把我已经转好时区的时间又转回UTC,日期就又跳回8月5日了。
这种问题不逐级打印根本查不出来。我当时用某个工具反复排查都没找到根因,换了个模型倒是很快顺着链路打印下去定位到了问题。
一开始我觉得这就是"模型能力有高下之分",但仔细想想,更准确的说法应该是:能不能满足你的需求,才是重点。这个模型解决不了,不代表另一个模型也解决不了;反过来也一样,不存在哪个模型永远比另一个强。真要说有什么建议,那就是——如果你是真心想从需求出发解决问题,尽量从各大厂商的旗舰模型开始试,能省不少来回踩坑的时间。
三、要治的是我自己的完美主义
现阶段的agent,还写不出一次到位、后面完全不用管的项目。就算某次运气好写出来了,后续维护迭代也还是麻烦,得一次次改。
但仔细想,这本来也不该是目标。尤其是试水型的产品,正经路径应该是:先想清楚需求(或者让agent帮忙出个调研报告),做出来先上线,有反馈了再迭代,不行就趁早撤。
问题是我自己老是忍不住想把细节磨到100%,而这些细节偏偏是最耗时间、性价比最低的部分。尤其一牵扯到生产环境,还得反复核对跟老项目的兼容性,一不小心就陷进去出不来。
这条主要是说给自己听的:需求驱动,快点迭代,才是正经事。产品行不行让市场说了算,不用完美主义来把关。
写在最后
说到底我们在焦虑什么?不是AI又出了新工具,也不是这个模型比那个模型多考了几分。真正值得花时间的,是你有没有找准自己的需求,有没有把手头这件事做扎实。
工具会一直换,榜单也会一直变第一名。但如果自己没有一条走得通的路,再强的放大器,放大的也只是原地打转而已。