前言

从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写代码距离完全替代一个程序员这件事，还有很长的路要走呢。