如何看待王垠对 Cursor 等 AI 编程的评价不懂
最近身边好多人都在用Cursor写代码。
去年我干了一件事——把团队所有人叫到会议室，拍桌子说：“都给我用Cursor！不限量，最好的模型，全上！”
当时有人嘀咕。一个老前端皱着眉跟我说：“老大，这东西写出来的代码，不靠谱吧？”
我说先用一个月。
一个月后，前端岗位开始消失。不是裁员，是根本不需要那么多人了。产品经理自己用Cursor写文档、画交互原型。以前一个电商后台，配三个前端一个后端，需求评审、排期、联调、测试，折腾两周。现在，一个人从需求到上线，三天搞定。
效率确实高。
看到这儿你可能以为——王垠被打脸了吧？
别急。
三个月后，问题一个接一个冒出来。
先说漏需求这个坑。AI总在漏需求，而你根本不知道它漏了。
做一个电商后台的管理模块。需求文档写得很清楚：“支持按时间范围筛选订单，支持按订单状态筛选，支持按金额区间筛选。”
够清楚吧？
开发用Cursor几分钟生成了筛选页面，看起来完美。点单、试功能、确认上线。
用起来才发现——订单状态的下拉框里没有“已取消”。时间筛选不能跨月。金额区间是个文本框，输入非数字直接崩溃。
为什么？因为需求描述里根本没提这些边界。你觉得自己说清楚了，AI也表现得像听懂了，但交付的东西就是缺了几个关键点。
王垠引用Dijkstra的话，我觉得很到位：“自然语言让你轻松地说出荒谬性并不显而易见的话。”
你写需求时，脑子里装了无数默认假设——“已取消当然要算一种状态”“跨月筛选不是常识吗”。但这些假设都没写进需求。
AI填补了你没意识到的空白——用猜。猜对了你开心，猜错了你背锅。
这个坑我踩了不下五次。现在团队的做法：需求必须带验收用例，而且用例必须覆盖异常情况。自然语言里省略的每条细节，都得一个不落地补回来。
另一个坑：代码没有根，改不动。
Cursor生成的代码跑起来没问题。但三个月后想加新功能，会发现陷入一团浆糊。
我团队有个项目用Cursor生成了用户管理模块。功能齐全：CRUD、权限、日志。看着什么都有。
内部结构呢？查询逻辑散落在三个文件里，事务控制有时写在Service层，有时写在Controller层，日志格式都不统一。
改一个查询得翻遍几十个文件。代码审查没法审——每次生成的代码风格都不一样。
王垠把这个事说得很透：自然语言描述天生缺乏架构约束。
你让AI“写一个用户管理模块”，这句话里没有分层、依赖关系、接口设计的信息。AI只能按见过的代码平均样本来填充，而这些样本大量是互联网上复制粘贴的三流代码。
我在TDengine时亲手写过几万行C代码。“一个设备一张表”的设计不是拍脑袋想的，是亲手踩坑踩出来的。这种结构化决策，AI也能生成一条看起来对的SQL，但关键细节一定错——它不理解时序数据特性。
AI生成的代码是“看起来对”，不是“真的对”。你有没有能力分辨，取决于你的功底。
还有一个：上下文越长，它越傻。
你开新对话让AI写个基础功能，然后说“加个搜索功能”“搜索支持模糊匹配”“模糊匹配支持中文拼音”“性能要优化，数据量超过10万要考虑索引”。
前三条正常执行。到了第四条，它开始翻旧账——把之前对话里的错误信息拿出来用，甚至重新引入之前让你改掉的bug，因为它“觉得”那个写法才对。
我硬生生调试了一个小时。最后发现第三次迭代引入的bug，被第五次迭代“修复”了——以重新引入早先错误的方式。
差点砸键盘。
王垠说：窄接口，约束越明确，合作越高效。放到AI编程里一样。每次对话别拖太长。出现降智，果断开新对话，别纠缠。
AI不会取代你，但会用AI的人会。这个结论跟很多人想的相反。
我见过几个算法功底好的同事用Cursor飞起。他们知道生成的代码哪些地方要改、哪些不能用。一个docker compose配置，我告诉他们用Cursor生成带TDengine和Grafana的，能省一半时间。他们有基础，一眼看出配置哪里不对。
也见过一些新人，把AI当万能工具。需求模糊，代码混乱，分不清好坏，以为能跑就行。项目越做越大，bug越改越多，维护成本高得离谱。
王垠的结论听着刺耳，但核心成立：AI编程的本质不是“会不会写代码”，而是“能不能判断它写得好不好”。
AI是效率放大器，乘以的是你的能力。能力是0，乘多少还是0。
这点我在TDengine感受很深。那些设计背后“一个设备一张表”比传统方案好的判断，来自对底层逻辑的深刻理解。AI不具备这种理解，它只能从数据分布里做概率拟合。
还有一个变化：团队架构正在被悄悄重构。
我们团队以前按职能分：前端、后端、产品、测试。用AI编程后，前端大幅缩减，留下的开始转全栈。产品经理开始写原型。测试也减少了——AI能自动生成很多单元测试。
人少了，效率高了。
但问题也来了。
沟通成本没降低，只是转移了。以前产品写文档、开发看文档、测试写用例。现在产品经理自己写代码，但写的东西缺乏架构感；开发自己做测试，但用例质量参差不齐。以前分工明确，有人把关，现在大家都对着AI输出，没人把关。
人员结构也出问题。AI编程降低了入门门槛，却提高了高要求门槛。以前应届生进来先写半年前端练手，现在直接面对全栈项目，压力大，学不到东西。他会用Cursor生成，但不知道生成的是什么。
我们最近在调整：让有经验的开发者负责架构和评审，让新人做边界清晰的模块。AI不能用在全栈自动化，只能在局部做效率优化。这个认知我花了半年、踩了很多坑才得到。
说几个大家可能忽略的。
第一，AI编程让你更快地写垃圾。你算过垃圾积累的速度吗？传统开发写10万行代码要三个月，期间还会不断重构。AI编程一周就能写10万行，但能留下的不到一成。剩下九万行垃圾会在项目里生根发芽——你删掉，AI下一波代码会把同样问题重新引入，除非你有能力从架构层面约束。
第二，正确率问题。有人做过研究，AI做LeetCode题目通过率尚可，但稍微复杂的任务正确率就掉下来。简单的都有错误，更别说科研级任务。你做没人做过的东西，AI很难给满意结果——它学的是已有的数据分布，处理不了真正的创新。
第三，所谓的“Vibe Coding”就是扯。用自然语言描述需求，AI就能写出好代码？甜蜜期很短。一个月真香，三个月后发现项目成了一坨没法维护的面条代码。王垠说“自然语言的舒适是一种危险的舒适”——你觉得自己说清楚了，其实没有。AI也不会告诉你它没听懂，只给你一个看似没问题的答案。
那怎么办？
不是不用，是换个用法。
需求必须形式化。写验收用例、边界条件、异常处理。写清楚再给AI生成，生成完逐条验证。这事听起来累，但比后期debug省时间。
AI当工具，不当伙伴。它不会思考，只会拟合。架构必须人来做，AI只负责实现边界清晰的模块。用Spec模式，别用Vibe模式。
定期做代码审计。每两周看一次AI生成的代码，把结构混乱、重复、不规范的干掉。别让垃圾积累。
团队里要有懂的人。所有人都应该具备判断能力，关键是必须有能判断“这个代码好不好”的人。这个角色会越来越重要。
最后说句真心话。
王垠可能把话说重了，但方向是对的。
计算机科学不是背八股文、记API。它是一种形式化思维训练——把模糊意图翻译成精确、机器可理解的符号。
这种训练的价值，在AI时代不是降低了，是提高了。以前的程序员只需要写代码，现在的程序员需要指导代码生成、判断代码质量、修正代码错误。每一项要求都比以前更高。
AI编程会越来越强，但底子差的人和底子好的人差距会越拉越大。
AI是放大器——让强者更强，让弱者看起来很强。
但只是看起来。
真到生产环境——bug调试、性能优化、架构设计，每一件事都在检验你的真实水平。
别把概率当智能。
这是2025年，我踩得最深的一个坑。
读者评论 4