113 lines
8.9 KiB
Markdown
113 lines
8.9 KiB
Markdown
## 前言
|
||
|
||
从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设计上](https://mp.weixin.qq.com/s?__biz=Mzg4MzAzNTA5Ng==&mid=2247484194&idx=1&sn=5db2099f5930874735b8e44ae12964de&scene=21#wechat_redirect)。
|
||
|
||
' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
|
||
|
||
### 真坑的部分
|
||
|
||
但是，问题也是真的多：
|
||
|
||
**需求理解偏差**：这个最要命。你说东它理解成西，然后一本正经地给你写了一堆代码，看起来很专业，实际完全不是你想要的。特别是涉及业务逻辑的时候，AI经常会"自作聪明"。
|
||
|
||
**多轮交互的噩梦**：当你发现它理解错了，想要纠正，往往需要好几轮对话。每一轮都可能产生新的偏差，最后你会发现，还不如自己重新写。
|
||
|
||
**Lint和代码质量**：AI写的代码经常不符合项目的编码规范，各种lint错误，需要大量的人工修复。有时候修复的时间比重写还长，似乎是开了雷达，专找你薄弱的技术栈下手。
|
||
|
||
**死循环问题**：这个真的很崩溃。AI发现有问题，然后修复，修复后又产生新问题，再修复，无限循环。我见过最夸张的是，一个简单的函数被改了20多轮，最后还是有问题。这种问题在claude code出来之前是所有vibe coding ide的通病，cc出来后好很多，因为上下文很多时候不用拆东墙补西墙了。
|
||
|
||
**复杂项目的熵增爆炸**：当项目变得复杂时，每次新增需求都可能打破现有的平衡。AI缺乏对整体架构的把控能力，缺乏对现有项目的规范把握，容易让代码变得越来越混乱。让这种情况更恶化的是，二次开发你本来的项目就是有很多历史包袱的破车，加个高速马达，开得越快，散的越块。
|
||
|
||
' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
|
||
|
||
## 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写代码距离完全替代一个程序员这件事，还有很长的路要走呢。
|
||
|
||
如果你也在关注AI coding工具，或者有什么有趣的体验想分享，欢迎在评论区聊聊。毕竟，这个钱烧得值不值，还得看能不能和大家一起找到更好的答案。
|
||
|
||
* * *
|
||
|
||
栗子KK，
|
||
|
||
一个在AI浪潮中游泳的AI产品Founder
|
||
|
||
欢迎点赞、在看、关注，一起聊科技、聊产品、聊未来 🚀 |