烧了2000美金在AI写代码上,我发现了一个残酷真相
content creator工作内容,ai内容创作,短视频内容创作 图文教程

烧了2000美金在AI写代码上,我发现了一个残酷真相

AI中国 AI中国 2 hours ago 136 阅读
4.8 (1280 Rating)
15,328 People learned

 

前言

从cursor爆火到现在不到一年时间,我基本把市面上能找到的AI代码工具都长期用过了个遍。

说实话,作为一个AI Agent方向的创业者和全栈工程师,我对这个AI Coding赛道有种近乎偏执的关注,尤其是devin出来(号称首个能干活的工程师),在春节前体验后给我带来的冲击不亚于GPT时刻。从最早的百度Comate、Continue、FittenCode这样的代码补全插件,到爆火出圈的Cursor、Windsurf,再到传说中的Devin,还有cline、roo-cline、kilocode、kiro,当然还有最爱的Claude Code和Augment等等,该花的钱我都花了,该踩的坑我都踩了。

粗略算了下,光是各种订阅费、token消耗、测试成本,已经烧掉2000美金左右了。但这钱花得值,因为我看到了一些很有意思的东西。

AI写代码,真香还是真坑?

先说结论:现阶段的AI Coding工具,像极了一个很有天赋但经验不足的初级开发者。

真香的部分

我承认,在某些场景下,这些工具确实让我刮目相看:

代码阅读和理解:这个真的强。扔给它一个几万行的项目,它能快速理解架构,找到关键函数,这比我自己读文档快多了。有时候接手别人的代码,我会先让AI给我梳理一遍整体结构。

多文件协同开发:当需求涉及多个文件修改时,AI的全局视野确实比人类强,它能同时考虑到各个文件之间的依赖关系,这点我服。说到这,整个行业要感谢Windsurf Casecade的贡献,首次让agent能在coding领域变得可用。

MVP和POC开发:这个是真的香。想要快速验证一个想法,从0到1搭个小工具或者原型,基本一天就能搞定。之前我用Cursor写了个任务Todo管理的小工具,从想法到可用版本,真就几个小时。还有之前文章提到一周内做的类似Manus的全栈自主智能体 做了两年AI Agent,我发现99%的AI Agent项目都死在了Message Flow设计上。

真坑的部分

但是,问题也是真的多:

需求理解偏差:这个最要命。你说东它理解成西,然后一本正经地给你写了一堆代码,看起来很专业,实际完全不是你想要的。特别是涉及业务逻辑的时候,AI经常会"自作聪明"。

多轮交互的噩梦:当你发现它理解错了,想要纠正,往往需要好几轮对话。每一轮都可能产生新的偏差,最后你会发现,还不如自己重新写。

Lint和代码质量:AI写的代码经常不符合项目的编码规范,各种lint错误,需要大量的人工修复。有时候修复的时间比重写还长,似乎是开了雷达,专找你薄弱的技术栈下手。

死循环问题:这个真的很崩溃。AI发现有问题,然后修复,修复后又产生新问题,再修复,无限循环。我见过最夸张的是,一个简单的函数被改了20多轮,最后还是有问题。这种问题在claude code出来之前是所有vibe coding ide的通病,cc出来后好很多,因为上下文很多时候不用拆东墙补西墙了。

复杂项目的熵增爆炸:当项目变得复杂时,每次新增需求都可能打破现有的平衡。AI缺乏对整体架构的把控能力,缺乏对现有项目的规范把握,容易让代码变得越来越混乱。让这种情况更恶化的是,二次开发你本来的项目就是有很多历史包袱的破车,加个高速马达,开得越快,散的越块。

Devin的成与败

说到Devin,我觉得它的设计思路是对的,但执行还差很远。

成也沙盒:独立的开发环境确实是个好想法,可以避免污染本地环境,也能让AI更自由地试错。这种"给AI一个独立工作空间"的思路值得学习。这也启发了manus,说实话manus出来第一眼,用过devin的人就知道它借鉴了前者的computer的gui。

败也沙盒:但沙盒并没有解决核心问题。死循环依然存在,简单需求复杂化的毛病也没改。你会发现,给它一个简单的需求,它可能会搭建一套复杂的架构,然后在里面绕来绕去。

我特别关注Devin提到的几个概念:

  • • 自我学习和成长性知识库:理念很好,但现实很骨感。AI确实需要能从之前的错误中学习,建立自己的经验库。
  • • 像人一样解决问题:这个我认同。真正的程序员会去查资料、看文档、参考别人的代码,而不是凭空想象。
  • • 注意力托管:这个概念很有意思,让AI能脱机够持续专注在一个任务上,而不是分散人的注意力。

但问题是,距离一个合格的实习生,还差得很远。

为什么单纯依靠模型还不够?

经过这么久时间的深度体验,我觉得问题的根源在于:编程不只是一个语言任务,它是一个复杂的工程问题。

模型的局限性

  1. 1. 上下文窗口限制:虽然现在模型的上下文越来越长,但真实项目的复杂度往往超出模型的处理范围。
  2. 2. 缺乏持续学习能力:模型无法从项目中积累经验,每次都是"从零开始"的状态。
  3. 3. 没有真正的理解能力:模型只是在做模式匹配,对业务逻辑的理解还是很表面。
  4. 4. 缺乏工程思维:真正的程序员会考虑可维护性、可扩展性、性能等工程问题,还有外部沟通产生的需求变更,大厂程序员只有不到1/5的时间在写代码,大部分时间在开会。而AI往往只关注功能实现。

需要的不只是更好的模型

我觉得要真正解决这些问题,需要的是一套完整的系统:

  • • 持续学习的知识库:能够积累项目经验,形成专属的编程规范和最佳实践。
  • • 多模态的交互方式:不只是文字,还需要图像、语音、甚至是直接操作界面。
  • • 强化学习机制:能够从反馈中改进,而不是每次都重新开始。
  • • 工程化的思维模式:考虑代码的长期维护和演进。

我的一些思考

作为一个在这个领域深度实践的人,我有几个不成熟的想法:

1. 不要指望AI完全替代程序员

至少在可预见的未来,AI更应该被定位为"超级助手"而不是"替代者"。最好的使用方式是让AI处理繁琐的基础工作,让人类专注于架构设计、业务逻辑和创新。

2. 垂直化可能是突破口

通用的AI coding工具很难做到完美,但在特定领域做到专业化是有可能的。比如专门做React组件的AI、专门做数据处理脚本的AI等。

3. 工具链的重要性

单纯的代码生成是不够的,需要与现有的开发工具链深度集成。测试、部署、监控、调试,这些都需要AI能够参与。

4. 数据和反馈机制是关键

AI需要能够从真实的项目实践中学习,而不只是从训练数据中学习。如何建立有效的反馈机制,让AI不断进化,这是个值得深入研究的问题。

写在最后

2000美金换来的最大启发是:AI写代码这件事,我们还处在非常早期但PMF已经比较确定的阶段。我现在产品迭代的开发习惯,基本已经离不开AI工具了。

但是AI写代码距离完全替代一个程序员这件事,还有很长的路要走呢。

 

Rating

4.8 (1280 Rating)

Comment (0)

睡觉动画