不知道为什么最近朋友圈里聊AI编程的人都在问同一个问题“为什么会Vibe Coding的不养Claw龙虾”我第一次看到这个标题的时候也愣了几秒然后反射性地笑出声。Vibe和Claw读音押韵意思却南辕北辙——一个说“跟着感觉走”一个说“用钳子死磕”。如果你还没看懂这个梗我帮你翻译一下Vibe Coding是现在AI编程圈最火的开发方式你用自然语言描述需求、让模型生成代码、自己再做判断和修改Claw龙虾则是我们这些老程序员最熟悉的状态——像龙虾举着钳子一样逐行手写、逐字符抠逻辑、一个分号一个括号都要亲手敲下去。先别急着站队。这个标题问得很妙因为它确实戳中了行业里正在发生的一场悄悄的革命。过去两年我见过太多开发者从“不信任AI写的代码”到“真香但不敢跟老板说主力代码是AI生成的”也见过完全相反的例子——有人把所有逻辑都丢给模型结果上线当天线上炸了凌晨三点在工位对着日志怀疑人生。所以这篇不打算给你灌鸡汤也不想把事情说得非黑即白。我想认认真真拆一下Vibe Coding到底在改变什么Claw龙虾为什么越来越不受待见以及一个更重要的问题——什么时候你该Vibe什么时候你必须乖乖拿钳子。内容可能会有点长但保证句句都是实操经验。我尽量说人话不搬术语砸你也会把那些踩过的坑原原本本摊开给你看。1. 先搞清楚今天这盘菜Vibe Coding到底在说什么1.1 从“写”到“指挥”这不仅仅是偷懒Vibe Coding这个词最早是从研究圈里传出来的大意是指一种高度依赖AI的编程方式你不再逐行控制代码而是把意图、约束、风格、目标说清楚让模型去补全那些体力活。打个比方以前的编程是“自己做饭”从买菜、洗菜、切菜、炒菜到尝咸淡全包Vibe Coding更像是“你站在厨房中央当主厨AI是那个手脚麻利、基本功扎实的帮厨”。你说“这个菜少放盐、多放蒜、口感要脆”帮厨就会按你的偏好执行。菜还是你的菜但具体动作是AI干的。很多人觉得Vibe Coding就是偷懒我不太同意。它改变的其实是开发者的注意力分配。以前写一个常规CRUD接口你至少要花半小时去抠路由、模型、序列化器、数据库连接那一大堆重复且无趣的模式现在你把接口语义描述得够清楚AI三分钟给你铺出一条可以跑的骨架你把时间省下来去思考接口背后的业务边界和异常分支。这不是懒是资源重新配置人的精力是有限的花在重复样板代码上是一种浪费。我这一年多的亲身体验是Vibe Coding最厉害的地方不是“快”而是它极大地降低了从想法到可运行代码之间的摩擦。以前有个新点子想到实现成本高、要改六七个文件可能就再等一等现在只要我想清楚逻辑基本上的功能一周能出原型。这种“想法变成现实的加速器”效应才是大家真正上头的原因。1.2 Claw龙虾是什么我们祖传的手艺那Claw龙虾到底指什么我第一次看到这个词的时候脑中浮现的画面是一只威武的龙虾举着大钳子钳住代码不肯松手。它代表的是我们这代程序员从入门就被灌输的那套手艺亲手写每一行代码、亲手调试每一个状态、亲手维护每一个边界情况。这套手艺当然有价值它让我们对代码有肌肉记忆对系统有整体掌控感出了问题哪怕不查日志闭着眼睛都能猜到八成是哪段逻辑在作怪。Claw Coding的优点说穿了就是“亲手做过的东西理解最深”。你手写过一个JVM内存分配的问题排查流程你就不会在配置堆内存时拍脑袋你亲手写过一遍数据库连接池的监控代码你就知道在高并发下哪些参数是纸面参数、哪些是真实瓶颈。这是任何AI短期都替代不了的底层积累。但是“不养Claw龙虾”这个说法其实调侃的是另一个层面手写一切的成本和收益在今天已经严重失衡了。就像养龙虾你固然能收获又大又新鲜的虾肉但你要喂饲料、换水、控温、防病投入产出比不划算。现在的产业级软件开发大部分代码本来就应该是“工业化”产物——标准化、可组合、可生成而不是每条都像手工艺品一样被精心打磨。拿钳子死磕一行模板代码确实有一种工匠般的爽感但站在项目交付的角度那就是劳动力的浪费。1.3 两种方式的真正分水岭你在控制复杂度还是在和复杂度搏斗所以Vibe和Claw的争论真正的核心不是“用不用AI”而是“谁的复杂度由谁来扛”。用Claw的方式写一个简单模块复杂度都在你手里每一行都清清楚楚但一旦项目膨胀到几万行、几十万行这种“全部在我掌控之下”的错觉就会被击穿——你根本记不住所有状态、所有调用链复杂度已经超出人脑的承载量了。这时候Vibe Coding反而更理性它允许你把部分底层细节外包出去只保留对需求、约束和最终效果的判断权。这才是我的核心观点Vibe Coding不是“放弃代码”而是把“写代码”这个动作从核心能力降级为手段把“判断代码是否满足意图”升级为核心能力。就像你用搜索引擎查资料不等于你就没有知识了你用AI生成代码也不等于你就不懂编程了。关键在于你有没有能力去评估、去修正、去兜底——这正是为什么有人Vibe得如鱼得水有人却Vibe得翻车不断。2. 为什么越来越多人不养Claw龙虾了因为这套生态真的变了2.1 需求侧变了业务要的是“快速试错”而不是“完美工匠”先看一个很现实的问题现在公司里的业务方真正需要的是什么不是某个接口写得有多优雅而是明天能不能出一个Demo去验证客户需求。我接触过的很多团队从大厂到创业公司产品迭代节奏已经从“一个月一个版本”压缩到“一周几个实验”。这种节奏下Claw的方式天然吃亏你花三天精雕细琢一个模块结果第四天需求方向变了那三天的工匠精神全部白费。Vibe Coding在这里的优势是“低成本试错”。同一个需求我能在一个下午用AI生成三个不同方案的骨架逐个验证可行性然后让业务方选方向。方向错了没关系代码本来就是AI生成的删掉重来不心疼。心态一变整个研发流程就活了你不再把代码当成需要终身维护的孩子而是把它当成验证假设的实验材料。这个转变在我看来是“不养Claw龙虾”最根本的驱动力——大家不是不想亲手写代码而是玩不起了等不起了。2.2 供给侧的跃迁AI编程工具从“补全单词”进化到“理解意图”两三年前的AI辅助编程说白了就是高级自动补全。你写一个函数名它帮你补几行你写一个if它帮你猜分支。这种工具不改变工作流顶多是让你少敲几个字。但这两年的工具已经完全不同了——模型能理解整个文件甚至多文件的上下文能根据你的一句话重构模块、写测试、修bug、甚至部署脚本。这个跃迁是决定性的AI从“输入法的进化”变成了“结对编程的队友”。我拿一个具体的例子说明。前阵子我做一个数据清洗的小工具功能是解析几种不同格式的日志、去重、按时间窗口聚合。放在以前我得先写一个解析器再写一个分桶逻辑然后处理各种脏数据分支少说四五个小时。但那次我就打开对话窗口把日志样例贴进去描述清楚“字段可能缺失、时间格式有五种、重复记录要去掉”AI直接给了一版可以跑的代码我只做了两处修正。那一刻我是真的意识到这套工作流不是更好用了而是“换物种”了。2.3 认知负担的转移让人做人擅长的事让AI做AI擅长的事人脑最擅长的是什么是判断、权衡、创造、在模糊场景里做决策。AI最擅长的是什么是没有情绪地完成重复劳动、快速搜索海量模式、生成符合常规模板的代码。Vibe Coding的核心价值恰恰是把后一类工作丢给AI让人腾出手来专心做前一类。可能你会担心长期这样搞会不会有一天自己的手艺全废了我的回答是要看“手艺”指的是什么。如果你的手艺是“背诵标准库API”那确实会被废掉也不需要可惜如果你的手艺是“判断一个系统在什么条件下会崩、知道怎么拆模块、能一眼看出AI生成的SQL里有慢查询风险”那这些手艺不但不会废反而会因为你有更多精力去接触复杂问题而变得更强悍。Vibe Coding更像是一个杠杆它能放大你已有的判断力但替代不了你建立判断力的过程。2.4 隐形的好处代码心态健康了人也不那么焦虑了最后聊一个容易被忽略的差别——写代码时的心态。Claw方式下每敲一行代码都在积累“沉没成本”所以你会越来越不敢改、越来越怕推翻。改一个跑了一年多的老模块光是心理负担就能压死人。但Vibe Coding天然带有“反正代码是AI生成的大不了重来”的心理暗示这种暗示其实非常有益它让你敢于重构、敢于尝试、敢于对遗留代码下手。我个人感受很深的一次是接手一个没人敢动的老服务。那服务逻辑绕得跟毛线团一样改动一个字段可能要牵连七八个地方。以前我打开源码看两分钟就关闭了宁可在外面包一层新的兼容逻辑。后来我换了思路直接让AI帮我梳理整个函数调用链输出影响面分析再基于分析结果做最小改动。前后用了不到一周老服务的核心路径就被我理清了还顺手拆掉了一堆死代码。这要搁以前Claw状态我估计得拖一个月。Vibe给我的不是一个更聪明的脑子而是一种“这堆乱麻在AI的辅助下是可解的”的信心。3. Vibe Coding实操指南我的完整工作流和独门技巧3.1 准备阶段先搭好“氛围”再开始“作曲”Vibe Coding这个“Vibe”不是玄学它指的是“上下文氛围”要到位。很多人用AI写代码总是翻车99%的原因是上下文没给够。你指望模型在完全不了解项目结构、依赖关系、代码风格的情况下给你产出完美代码这跟让一个没见过菜谱的人做一桌宴席没啥区别。我现在的习惯是在开始一个项目Vibe之前先把下面这些信息喂给AI项目整体用途和技术栈例如“这是一个基于某语言、某框架的后端服务对外提供REST API数据库用某数据库”。目录结构信息不用全贴把入口、核心模块、配置文件路径说清楚就行。已有的代码风格约定比如“函数参数用驼峰”“错误处理统一返回统一结构体”。本次任务的目标和验收标准写清楚“做什么”和“做完怎么算对”。这个“喂上下文”的步骤我通常会花10-15分钟。别觉得浪费这其实相当于你给帮厨讲清楚今天的客人口味和厨房规矩。上下文越足后续生成代码的返工率越低。我实测下来这一段投入的时间可以省掉后面至少一小时的改改改。3.2 写“功能契约”而不是“一句话需求”很多人用AI写代码时给的描述大多是“帮我写个用户登录接口”——然后AI就真给你写个裸露的登录接口没有校验、没有防重、没有频率限制。问题在哪问题在于你没有定义验收标准AI只能按“最常规”来猜。我的核心技巧是把需求写成“功能契约”的形式也就是包含输入、输出、约束、异常处理四要素的描述。比如需求写一个用户注册接口。输入为用户名、邮箱、密码输出为创建成功的用户对象或结构化错误信息。约束用户名3-20字符且唯一邮箱格式必须校验密码至少8位且包含字母和数字同一IP一小时内最多注册5次。异常情况数据库冲突时返回可读的提示参数非法时返回字段级的错误详情。你看同样是“用户注册”这样的契约一甩给AI它生成的东西必然比“帮我写个注册接口”靠谱两个数量级。这不是什么高深技巧就是你把需求讲清楚的本事。现实中很多所谓“AI写不了好东西”的抱怨其实是你自己连需求都没想明白。AI像是一面镜子你的模糊会原封不动地映射到结果里。3.3 分块生成小步快跑拒绝一次生成一个巨兽新手Vibe的时候最喜欢“一步到位”让AI一口气生成一整个模块的所有文件。我劝你千万不要。经验告诉我上下文窗口再大模型对超长输出的连贯性也有限度。它很容易写着写着就忘了前面定义的数据结构或者因为风格漂移导致前后的代码不一致。更麻烦的是一旦中间有个核心思路错了后面几千行代码全部作废你还得从头再讲一遍。我现在奉行的是“洋葱式Vibe”像剥洋葱一样一层一层来。先让AI生成数据模型和接口定义等我审查没问题了再让它按这些定义生成实现实现OK之后再覆盖业务逻辑分支最后是测试和错误处理。每一层生成的代码量控制在200-400行左右保证我一次能完整看完并理解。这种方式看起来“回合数变多了”但每回合的返工量都极小整体反而是最快、最稳的。3.4 审查大于生成这是你和Claw龙虾的胜负手可能很多人不信Vibe Coding最花时间的不是“让AI写代码”而是“审查AI写的代码”。我周围那些真正把Vibe Coding用好的开发者没有一个是不看代码直接跑的。大家都会逐行阅读AI生成的diff理解每一段逻辑再决定是接纳、修改还是重写。审查的好处有三层。第一它能拦住显而易见的低级错误比如把大于号小于号写反、把某个状态漏更新。第二它能让你保持对项目的理解不会出现“代码能跑但没人知道为什么能跑”的失控状态。第三也是最重要的只有通过逐行审查你才能提出更准确的修改指令——因为只有你知道哪里不对、该怎么不对AI才能改。我自己的习惯是对AI生成的代码执行“三层质检”第一层看接口和数据流是否与契约一致第二层看边界条件和异常分支是否覆盖第三层看有没有安全风险比如SQL注入、越权访问。这套习惯是Claw时代我就养成的到了Vibe时代它变成了更重要的核心能力。3.5 让AI记住你的“口味”风格一致性的驯化技巧同一个AI模型给不同人用效果天差地别除了上下文和需求描述外还有一个常被忽视的原因——“风格驯化”。模型没有记忆同一个模型不会记得上次给你写过什么风格。但你可以在每次对话里固定一些风格描述比如“错误处理用自定义错误类型”“日志统一用结构化JSON格式”“测试用例用表格驱动的方式”。更进阶一点的做法是在项目里维护一份给AI看的“项目风味文档”里面写清项目背景、技术栈、目录规范、编码风格、常用依赖版本。每次开启新会话时不用重复介绍把这份文档丢过去就行。我自己现在已经离不了这个文件了它本质上就是给AI队友的新人手册。你想想一个新人进团队你不给他看文档就让他干活他能干好吗AI同理。4. 别高兴太早Vibe Coding的边界、误区和红线4.1 禁区一核心链路、支付、权限再想Vibe也给我好好Claw我见过最惨的一次事故是同事让AI生成一段权限校验逻辑。AI按常规写法判断了“当前用户是否是管理员”但漏了“超级管理员和普通管理员之间的等级区分”结果一个普通管理员能执行本该是超级管理员才能执行的删除操作。这种问题不熟悉业务上下文的人包括AI根本意识不到只有对业务规则门儿清的人才会在审查时发现。所以我的红线清单里下面这几类代码永远不允许“无脑Vibe”涉及支付、资金、订单状态流转的代码权限模型和越权校验相关代码数据删除、迁移、批量更新等不可逆操作加密解密、令牌签发这类安全敏感逻辑。这种代码我会怎么做用AI辅助出初稿可以但最终每一行都必须经过自己或核心成员逐行确认并且强制要求补上单元测试、做Code Review必要的时候还要走一遍故障演练。Vibe Coding可以帮你省掉重复劳动但绝对代替不了关键路径上的严谨。你可以在其他地方贪快在这些地方贪快就是拿生产环境开玩笑。4.2 禁区二性能敏感路径和算法核心别让AI替你拍板AI生成的代码普遍特征是“正确平庸”但追求高性能的时候平庸往往就是原罪。举个例子让AI写一个内存缓存策略它大概率会给你一个最朴素的哈希表加锁方案。在小流量下没问题一旦到了每秒几万请求的场景锁竞争、GC压力、缓存淘汰策略全都成了需要精细权衡的问题这些不是靠“描述需求”就能让AI理解的。性能路径上的代码我的建议是把它当成Claw的自留地。你可以让AI生成基准测试、生成不同方案的骨架供你做对比实验但最终的算法选型和关键参数必须自己基于Profiling数据做决策。AI可以给你三个方案但告诉你“哪种方案在你的业务下最合适”这件事它做不到——因为它不掌握你的流量模型、硬件配置和延迟预算。4.3 禁区三团队协作的约定俗成别让AI帮你“创新”每个团队都有一些不成文的规矩某个公共模块为什么要这样设计、某个字段为什么不能直接改、某些历史包袱为什么要保持兼容。这些“约定俗成”通常不在文档里甚至在代码注释里都只有一半。AI不懂这些它看到代码“不合理”就会按“更合理”的方式重构——然后就把团队踩过的坑又踩了一遍。我踩过的真实案例AI在重构一个老接口时自动把某个废弃但仍在被客户端依赖的字段从返回结构里删掉了。在代码层面这是“优化”在业务层面这是“破坏兼容性”。还好我们在审查diff时发现加回来了否则那天估计要被打爆电话。所以我的规矩是面对团队内部历史代码AI可以帮忙梳理逻辑、写测试、做文档但“重构删改”这类动作必须由熟悉来龙去脉的人拍板。AI可以做手术刀但握刀的手得是人。4.4 警惕“Vibe陷阱”代码能跑≠你懂代码≠系统不会出事Vibe Coding最大的隐形风险不是AI写错代码而是你因为“它写对了”而停止思考。人有一种路径依赖一旦某段代码跑通了就会下意识地认为它没问题然后就不再深究。这在传统编程里也有但Vibe Coding会放大它——因为AI生成的代码看起来结构清晰、注释齐全特别容易让人放松警惕。比如AI帮你写了一段消息队列消费逻辑测试也都过了看起来很完美。但你知道它的消费顺序是单线程还是多线程失败重投的间隔是多少消费失败达到最大重试后是进入死信还是静默丢弃这些往往不会在“能跑”的初版里暴露只有压测和故障演练时才会现形。我自己用来对抗这个陷阱的方法是“提问式审查”每完成一段AI代码我逼自己回答三个问题——它依赖哪些外部资源如果资源不可用会怎样极端输入下它会怎样失败答不上来就继续问AI、继续看代码直到心里有底。5. 常见问题速查表与排坑实录下面这几条都是我实际Vibe过程中碰到过、也帮别人解决过的问题整理成速查形式方便你遇到的时候快速对照。现象根本原因我的解决方式AI改了一处导致另一个文件报错上下文窗口没有覆盖到所有依赖方开启新会话并附上完整项目结构核心关联文件或让AI先输出影响面分析再动手AI生成的代码引用了不存在的库模型“幻觉”编造了不存在的依赖审查阶段检查import和依赖清单用环境跑一遍最小验证让AI标注引用来源让AI修一个bug它改了三次越来越乱没给AI足够的报错堆栈和上下文它在盲猜把完整报错消息、相关代码段、预期行为一次性贴全禁止AI在信息不足时直接动手AI生成的代码风格和项目不一致没有在上下文里给出风格约束用“项目风味文档”每次都带上代码风格规范代码能跑但一压测就崩溃AI默认生成了“正确但无性能考量”的实现性能场景不让AI拍板自己先写基准、再选方案AI重构毁掉历史兼容性模型不理解历史包袱和团队约定重构类改动必须高手审查禁止AI“顺手优化”上下文太长导致AI忘了最初的需求对话窗口塞了太多无关内容及时开新会话把“功能契约项目风味文档”在新会话中重贴一遍API设计前后不一致没有先定接口契约就开始写实现强制“契约先行”先把接口和数据模型敲定再生成业务逻辑除了表格里的常规问题我再分享一个排坑心得当AI连续两次给出同样错误的代码时不要再重复同样的提示了。这时候你应该怀疑的不是AI笨而是你的描述中有一个它无法理解的歧义。试试换个角度重新描述问题——把它从“怎么做”换成“为什么会出现这个问题”往往会有奇效。有一次我让AI修一个偶发性的空指针连续两次都给出回避性的判空代码治标不治本。后来我换了个问法先问“这段代码里有哪些路径会导致这个变量为null”AI帮我列出了四个可疑路径我才定位到真正的问题——一个异步导致的内存可见性问题。学会“让AI帮你做分析而不是替你下结论”是Vibe Coding进阶的一道坎。再补一个工具面的大常识Vibe Coding不是某一款工具的专属名词凡是能通过自然语言驱动代码生成的工具都算。你可以用对话式的模型也可以用集成在IDE里的AI助手还可以用任务型的智能体。不同工具的体验差异很大但本质上它们都遵循同一个逻辑给AI足够的信息获得生成的代码然后你来做审查和判断。选工具不用迷信“最贵”“最新”关键在于它是否适合你的工作流。我自己目前是多种工具混着用写原型和脚本用对话式模型改既有代码用IDE集成助手自动化多步骤任务用智能体。别被工具绑架工具是手段Vibe才是目的。5.5 最后再分享一个实用小技巧让AI帮你生成“给自己看的解释”除了写代码我最近特别喜欢让AI做一件事——把一段复杂代码“翻译成人话”。接手别人留下的老代码时不用自己一行行啃直接选中代码块让AI解释它做了什么、数据怎么流转、有哪些潜在问题。这个用法看似基础但真的很能提升效率。尤其是有时候你自己看半天看不出来的逻辑AI用另一种视角一梳理你就豁然开朗了。这个小技巧的进阶玩法是“基于老代码生成结构化文档”顺带还能让AI把文档里的关键决策标注出来。这样做的好处是双重的你得到了文档更重要的是你在对照代码读解释的过程中快速建立起了对系统的整体认知。这一步做完你再去改代码就心里有数了。我一直觉得Vibe Coding最强的地方在于它不只是帮你写新代码更是帮你理解旧代码——这一点对维护老系统的人而言简直是救命稻草。哦对了还有一句经验之谈无论你Vibe得多熟练请务必保持每周至少一次“纯Claw时间”。哪怕只是写一个小脚本、做一个算法练习让自己保持手写代码的手感。这个习惯的价值平时可能看不出来但当你在审查AI代码时指出那个“边界条件漏了”的瞬间你会感谢自己没有把Claw的手艺完全丢掉。Vibe Coding让我们跑得更快但Claw的手艺让我们知道该往哪儿跑以及怎么在悬崖边刹住车。说到底“Vibe还是Claw”并不是一道非此即彼的选择题。成熟的开发者不是扔掉钳子改成躺平而是学会了什么时候用AI这个帮厨、什么时候自己亲自掌勺。我见过Vibe得极好的老工程师也见过被AI坑得怀疑人生的新手。区别从来不在工具而在于你有没有足够的能力驾驭工具。希望大家都能在Vibe Coding的大路上跑得更快同时兜里始终留着那把叫Claw的钳子——不是为了每道菜都亲手做而是为了在关键时刻钳得住方向盘。
