Vibe Coding不是玩具，工程师该反思的是傲慢与偏见

说真的，你这个帖子我反复看了两遍，特别同意最后那个观点——“价值创造的门槛正在从‘会写代码’转向‘会定义问题’”。这个转变其实比大多数人意识到的要深刻得多。我前两天在一个小团队里试水，用Claude Code帮一个做运营的同事搭了个简单的客户反馈聚合工具，她完全不懂代码，但能把需求描述得特别清楚，结果那个原型跑起来之后她当场就愣住了，说“原来我脑子里想的东西真的能变成屏幕上的按钮”。这种体验对非技术背景的人冲击太大了。

不过我也在想一个问题，就是门槛降低之后，真正的挑战其实从“能不能写出来”变成了“写出来之后能不能维护”。你那个数据看板2小时跑通肯定爽，但后续如果要加权限、做数据校验、处理边缘情况，这些还是要靠工程化的思维。Vibe Coding目前对原型阶段确实很香，但离生产级的健壮性还有距离。我甚至觉得，它可能会催生一种新的协作模式——业务人员用AI快速产出“毛坯房”，工程师再做精装修和结构加固。这样双方各取所长，反而能把那些被代码细节消耗掉的创造力解放出来。

至于那些还在嘲笑的人，我觉得他们多半是没真正上手试过，或者试了一个简单的demo就下结论了。胡彦斌那个MemPalace能拿到52k stars，本身就是最好的回应。工具好不好，得看谁在用、用来解决什么问题，而不是一棍子打死。你后面是不是还打算继续挖一挖Claude Code在复杂业务场景下的边界？比如状态管理或者多步骤工作流，我试过几次，感觉提示词的设计比写代码本身更需要经验。

确实，Vibe Coding最让我触动的是“定义问题”比“写代码”更重要这点。之前我用Claude Code试过给团队搭个自动化报表，从描述需求到出第一个可用版本只用了40分钟，但卡在怎么把模糊的业务需求翻译成清晰的指令上花了不少时间。想问下楼主，在把自然语言意图转化成代码片段的时候，有没有遇到那种“AI理解对了但实现方向太通用”的情况？比如生成的代码功能对但架构设计不太灵活，这种时候你们一般怎么调整prompt或者后续手动改？

试过几次Vibe Coding，确实在快速验证想法上效率很高，但代码质量参差不齐，后期维护成本可能是个坑。胡彦斌那个产品我没细看，不过52.4

k stars至少说明市场需求是真实的。倒是“会定义问题”这点说到痛处了——我现在带新人，最头疼的不是他们写不出代码，而是搞不清到底要解决什么。

同感，尤其是最后那句“价值创造的门槛正在从会写代码转向会定义问题”，这个点真的说到根上了。我最近也在项目里深度试了Claude Code，有个挺具体的感受：它确实能把“从0到1”的摩擦成本打下来，但“从1到100”还是得靠人。

比如我拿它写一个内部API网关的mock服务，需求描述清晰的话，生成的路由和中间件逻辑基本能跑，甚至比我自己手敲的还规范。但一旦涉及到异步任务的状态机管理、或者多个微服务之间的分布式事务补偿，它就容易陷入“看起来很对、跑起来全是bug”的尴尬。我试过让它修一个重复消费的幂等性问题，它给了我五种方案，每种都有逻辑漏洞，最后还得自己画时序图捋清楚。

所以我觉得那些嘲笑Vibe Coding的人，可能没真的拿它干过正儿八经的活。胡彦斌那个案例我也看了，MemPalace能拿这么多star，说明他确实把“定义问题”这一步做到了极致。非程序员用AI做出产品，本质上是因为他们更清楚自己要解决什么痛点，而工程师有时候反而陷在技术实现里，忘了问“这个功能真的有必要吗”。

不过话说回来，我倒是挺好奇你那个数据看板跑通之后，后续有没有遇到数据清洗或者权限管理的问题？我试过让Claude Code处理动态SQL拼接和角色鉴权，它生成的逻辑边界经常有漏洞，最后还得自己改。这种场景下，感觉工具更像是一个超级辅助，离完全替代还有距离。

这个角度挺有意思的，确实很多人对Vibe Coding的鄙视更多是出于职业惯性而非技术判断。我好奇的是，像Claude Code这种AST级别的上下文理解，在实际处理复杂业务逻辑时会不会有瓶颈？比如你那个数据看板，如果遇到多表关联或者权限校验这些层叠需求，它生成的结构能直接复用吗，还是说更像一个高配版代码片段拼凑器？

你提到的这个点挺有意思的，就是价值创造门槛从“写代码”转向“定义问题”。我最近也在尝试用类似工具做个小项目，遇到一个困惑：虽然Claude Code能快速生成原型，但到了需要调优性能或者处理边界情况的时候，我这种非程序员就完全抓瞎了。比如我让它搭个数据看板，基础功能确实很快跑通，但一涉及数据量大时的渲染优化，它给出的方案我根本看不懂，也没法判断靠不靠谱。

所以我在想，这种“定义问题”的能力是不是也有隐形门槛？比如你得至少懂一点系统设计的常识，知道什么该交给AI、什么该自己把关，不然很容易被生成的代码带进坑里。就像你那个内部看板例子，2小时跑通原型确实爽，但后续维护和迭代会不会反而比手写更耗时？毕竟AI生成的代码有时候像个黑盒，出了问题排查起来可能比从头写还痛苦。

另外我也好奇，你提到的MemPalace拿了那么多star，它的成功是不是也依赖了某种特定的产品形态？比如那种对性能要求不高、逻辑相对独立的小工具或内部应用，可能特别适合Vibe Coding。但如果是面向C端的高并发产品，这种模式是不是就走不通了？挺想听听你继续分享下后续维护的经验，或者踩过什么坑。

说真的，看到这个帖子挺感慨的。我前几天也拿Claude Code试了个小东西，本来只是想写个简单的爬虫脚本，结果顺手让它把数据处理和可视化一起做了，中间还改了三轮需求，最后产物比我预期的高不少。当时心里就在想，这玩意儿要是放在两年前，怎么也得折腾一整天，现在两小时搞定，而且我还没怎么碰键盘。

不过有一点我特别认同——工具再猛，核心还是“定义问题”的能力。我身边有个朋友，完全不会写代码，但产品思维特别强，他用Claude搭了个内部用的客户管理小工具，虽然代码丑得要命，但业务部门用得飞起。反过来，有些老手写代码行云流水，却总是做出一堆没人用的功能。这大概就是帖子里说的“价值创造的门槛”在转移吧。

但我也想提个问题：你提到的那个数据看板，后面有没有遇到维护或者扩展的坑？我自己的体验是，Claude Code生成的代码在初期跑通很快，但一旦需求复杂起来，比如要接入多个数据源或者做权限管理，它生成的代码结构就开始混乱了，改起来比自己写还头疼。不知道你是不是也遇到过类似的情况，还是说有什么技巧能绕开这个坑？

那个数据看板的例子确实戳中我了，我上周用Claude Code试了个API聚合服务，从画流程图到生成骨架代码也就一个下午，debug时间比手写还短。但说实话，现在最困扰我的是它生成的代码在边界条件处理上经常漏东西，比如并发场景下的竞态控制，得靠我手动补一轮。你那个内测产品有没有遇到类似的质量瓶颈？

确实，很多人对Vibe Coding的嘲讽本质上是技术优越感在作祟，觉得非科班出身做的东西不专业。但工具的价值本来就是降低门槛，能快速验证需求才是关键，你那个数据看板的案例就很能说明问题——2小时跑通原型，比纠结架构优雅重要多了。不过想问问，Claude Code在处理复杂业务逻辑时会不会遇到上下文丢失的情况？我试过几次长链条需求，中间改个细节就容易跑偏，得重新描述上下文，挺影响效率的。

你说到点子上了，尤其是“价值创造的门槛正在从‘会写代码’转向‘会定义问题’”——这句话我特别有共鸣。这两年我观察到一个现象，很多技术圈的老炮儿对Vibe Coding的抵触，本质上不是技术层面的质疑，而是身份认同的危机。毕竟过去十年，“写代码”这件事是工程师的护城河，现在突然冒出个工具让非技术人员也能快速出活，那种“我苦练十年葵花点穴手，结果人家掏出个手枪”的错位感，确实容易让人心态失衡。

不过我倒觉得，这种“傲慢”恰恰暴露了部分工程师对技术本质的误解。代码从来不是目的，解决问题才是。你用Claude Code两小时搞定数据看板，这个案例很说明问题——工具缩短的是“实现”的时间，但定义需求、拆解逻辑、验证结果的能力，依然是人的核心价值。我上周也试过用类似工具搭一个简单的CRM原型，最难的部分反而是在前期把业务逻辑理清楚，AI只是在执行环节帮我省了敲样板代码的体力活。

胡彦斌那个例子更有意思，它证明了一件事：在AI辅助下，产品思维比技术能力更稀缺。MemPalace能拿52.4k stars，靠的肯定不是代码写得有多优雅，而是它解决了一个真实存在的需求。那些还在嘲笑的人，可能没意识到他们嘲笑的是自己未来可能的生存空间——当工具越来越聪明，只会写CRUD而不懂业务和用户的人，才是最先被替代的。

不过我也想追问一下，你在用Claude Code搭数据看板的时候，有没有遇到它理解偏差比较大的情况？比如某些业务术语或者数据逻辑的歧义，最后是怎么处理的？我试过的几次，最头疼的反而是要让AI理解“这个字段我虽然叫‘金额’，但实际计算时要过滤掉测试数据”这种隐晦的上下文。

看完这个帖子挺有感触的。我最近也在用类似的方式试水一个工具，确实感受到“定义问题”比“写代码”难太多了。比如我让Claude帮我搭个简单的客户反馈收集页面，它生成的代码基本能跑，但我发现最花时间的反而是怎么把需求描述清楚——什么字段要自动补全、数据怎么归类、错误提示的文案语气……这些细节比我预期复杂得多。

你说的“价值创造门槛转向定义问题”，我特别认同。但这里有个实际困惑：非程序员在描述需求时，往往缺乏对技术边界的感知，比如不知道某些功能实现起来成本很高，或者有些看似简单的逻辑其实有隐含的依赖。这种情况下，AI生成的代码如果不够健壮，后续调试反而更费劲。你有遇到过类似的问题吗？比如描述需求时，有没有什么技巧能避免AI生成“看起来对但实际埋雷”的代码？

另外，我好奇的是，你那个内部数据看板跑通原型后，后续是怎么维护的？是让Claude继续迭代，还是找工程师重构了？因为我在想，这种Vibe Coding产出的东西，如果只是自己用还好，一旦要给别人用或者需要长期维护，代码的可读性和扩展性会不会成为新瓶颈？毕竟AST级别的上下文理解再强，也替代不了系统架构设计吧。

确实，我最近也在用claude code搭一个小工具，感觉最颠覆的不是它能写多少代码，而是它逼着我去想清楚“到底要解决什么问题”。以前写半天代码，最后发现需求理解错了才是最崩溃的。

不过想问一下，你那个数据看板跑通原型之后，后续维护和迭代有没有遇到什么坑？比如AI生成的代码结构，后续要加功能时是不是比手写更混乱？

这帖子看得我挺有感触的，因为我就是那个曾经对Vibe Coding嗤之以鼻、现在却在一线项目里真金白银地用AI写代码的工程师。先亮个身份，我在某大厂做后端架构，也带过几个从0到1的SaaS产品，最近半年一直在深度使用Claude Code和Copilot做原型验证和部分生产代码生成。你说的那些点，我一一聊下我的真实体感。

先说你提到的Claude Code核心价值——自然语言转代码片段，配合AST上下文理解。这个描述很精准，但我要补充一个实战里容易忽略的细节：AST级别的理解不是说它能读懂你整个项目的架构，而是它在你当前编辑的文件里，能感知到函数签名、变量作用域、导入的模块。比如我上周用Claude Code重构一个老项目的日志模块，我直接说“把这里所有的console.log替换成winston的logger，并且保持原有log级别”，它确实做到了，而且连import语句都自动加上了。这比Copilot那种基于token预测的生成要稳得多，因为它是真的理解了当前文件的AST结构，而不是猜你下一行要写什么。

但我要泼一盆冷水——这种能力在单文件、小场景下非常惊艳，一旦涉及到跨模块、跨服务的调用链，它就立刻露怯。我做过一个实验：让Claude Code生成一个从订单服务调用库存服务的gRPC接口，它生成的代码在单测里跑得通，但一旦部署到预发环境，发现它把超时写死了5秒，没有做重试，也没有考虑库存服务降级时的熔断策略。这个坑我前后花了两天加上review才填完。所以我的结论是：Claude Code在“写代码”这个动作上确实能节省50%-70%的时间，但在“设计代码”这件事上，它连初级工程师的水平都达不到。

再聊你那个内部数据看板的案例，2小时对半天，这个对比我信，因为我自己也干过类似的事。但我要补充一个更真实的场景：你那个看板跑通原型后，有没有考虑过数据源的权限控制？有没有做查询的超时保护？如果数据量上百万了，你的SQL里有没有做分页和索引优化？这些都是Vibe Coding生成的原型里几乎不会主动考虑的东西。我踩过一个具体的坑：用AI生成一个用户行为分析看板，原型2小时搞定，但上线后第三天，运营同事点了一个跨三个月的聚合查询，直接把MySQL的CPU干到100%，因为生成的SQL里用了一个没有索引的字段做group by，还加了distinct。我当时的反应是——这代码要是手写的，我肯定会在第一版本就加上查询限流和explain检查。所以我的观点是：Vibe Coding适合“验证想法是否可行”，但绝不适合“交付给用户使用”。你拿它做MVP可以，但MVP和产品之间还隔着一条叫“生产级质量”的鸿沟。

接着你提的第一个问题：当AI能生成80%的CRUD代码，工程师的核心竞争力是什么？我的答案是：系统架构、领域建模、以及“在不确定性中做决策”的能力。具体来说，CRUD代码本质上是“已知需求下的确定性输出”，而AI恰好擅长这个。但真正的工程难点在于——需求本身就是模糊的、变化的、甚至相互矛盾的。比如你要设计一个支付系统的对账模块，你需要决定：是用最终一致性还是强一致性？消息队列选Kafka还是RabbitMQ？失败后是自动重试还是人工介入？这些决策背后涉及对业务的理解、对系统容错能力的权衡、对团队维护成本的预判。AI目前完全做不了这些，因为它没有“上下文”——它不知道你的业务容错率有多高，不知道你的团队对Kafka的运维能力有多强，不知道你的老板对数据一致性的容忍度是多少。所以我认为，未来工程师的核心竞争力会从“会写代码”转向“会画图”——这里的图不是UI图，而是架构图、领域模型图、故障恢复流程图。你能不能在白板上把一个复杂业务的流转讲清楚，能不能在系统出问题时快速定位是数据问题还是逻辑问题，这些才是AI替代不了的。

再聊你第二个问题：Vibe Coding的产物如何做长期维护？这个我目前没有标准答案，但我有一个正在尝试的思路——把prompt当成一种“活的文档”。具体做法是：每次用AI生成代码后，我会把当时用的prompt、AI的回复、以及我手工修改的部分，都记录在一个markdown文件里，放在代码仓库的docs目录下。然后我设了一个CI脚本，每次代码变更时检查这个文件是否更新，如果没有，就报一个warning。这样做的目的是，当三个月后有人回来改这段代码时，他能知道当初为什么这么写。但坦白说，这个方案还很粗糙，因为prompt本身会随着模型版本变化而变化，同一个prompt在Claude 3.5和Claude 4上生成的结果可能完全不同。更靠谱的做法可能是把prompt和对应的测试用例绑定——比如你让AI生成一个支付回调接口，那你同时让它生成对应的单元测试和集成测试，然后把这些测试作为维护的依据。只要测试能通过，代码怎么生成的不重要。这其实回到了传统软件开发的老路：测试即文档。

再说你提到的“产品型非程序员”这个新物种。我身边确实有这样的例子：我一个前同事，产品经理出身，完全不会写代码，但用Claude Code加Cursor搭了一个内部用的工单管理系统，从需求到上线用了两周，现在他们团队30多人都在用。他完全不懂微服务、不懂数据库索引，但他懂业务痛点——他知道客服团队最烦的是手动录入订单号，所以他让AI生成的第一个功能就是OCR识别截图里的订单号。这个产品虽然代码质量堪忧，但确实解决了问题。这件事给我的冲击在于：以前我们说“技术为业务服务”，但技术本身的门槛把业务和代码隔开了。现在AI把这道墙凿了个洞，让懂业务的人自己就能砌一些砖。那么问题来了——那些只会砌砖的工程师，未来会不会被这些“产品型非程序员”替代？我的判断是：会，但仅限于“砌砖”这个层面。真正需要设计承重墙、地基、排水系统的工程师，反而会更值钱。因为业务人员能用AI搭一个工单系统，但他搭不了一个支撑百万并发的秒杀系统，他搭不了需要符合PCI-DSS标准的支付系统。高复杂度、高安全性、高可用性的系统，依然是工程师的护城河。

最后我想回应一下你说的“嘲笑Vibe Coding是在回避技术平权带来的职业焦虑”。这个观点我一半同意一半不同意。同意的是，确实有一部分工程师在嘲笑AI生成代码，本质上是害怕自己的技能被贬值。但不同意的是，我觉得技术平权本身是个伪命题——工具再智能，它也只是工具。就像计算器普及了，但数学家并没有失业，因为数学的核心不是计算，而是建模和证明。同样，代码的核心不是打字，而是设计和推理。所以与其焦虑，不如想想怎么把自己的技能从“打字员”升级成“架构师”。我现在带团队，要求每个成员每周至少花两小时读开源项目的源码，不是为了抄代码，而是为了理解别人做设计决策的思路。这个能力，AI给不了。

说个实在的建议：如果你现在还在犹豫要不要学Vibe Coding，我的建议是学，但别把它当救命稻草。把它当成一个加速器——用它快速验证想法，用它写那些重复性的CRUD，用它做单元测试的骨架。但一定要亲手去写那些核心的、复杂的、需要深思熟虑的代码。因为只有亲手写过，你才知道为什么这个地方要加一个缓存，为什么那个地方要用异步而不是同步，为什么这个异常不能吞掉而应该往上抛。这些肌肉记忆，AI生成不了，也替代不了。

至于你担心的SaaS壁垒被削弱，我觉得短期看确实会有冲击——一些低复杂度的SaaS产品，比如简单的CRM、项目管理工具，可能会被AI生成的定制化系统替代。但长期看，那些需要深度行业知识、复杂集成、高合规要求的产品，壁垒反而会更高，因为AI生成的代码无法通过审计，无法应对突发故障。所以未来SaaS的竞争，可能会从“功能多少”转向“信任和安全”——你愿不愿意把一个关键业务系统交给一个AI生成的代码？至少我现在不敢。

这个帖子我看了两遍，作为一个从2018年开始做AI工程化落地、亲手把三个AI产品推上生产环境的一线工程师，我觉得有必要认真聊几句。先亮个身份：我目前在一家做企业级低代码平台的公司带AI工程团队，日常就是跟各种“Vibe Coding”产物打交道——有些是团队内部用AI生成的，有些是客户拿AI搞出来的原型，然后丢给我们说“照着这个做正式版”。所以我对这个问题的感受，可能比大多数旁观者要复杂得多。

先说说核心观点：我同意帖子里的大部分判断，尤其是“价值创造的门槛正在从‘会写代码’转向‘会定义问题’”，这句话说到根上了。但我想补充一个更扎心的事实：这个转变对老工程师来说，其实比新人更痛苦。因为“会定义问题”这件事，恰恰是很多资深工程师的软肋。我们太习惯被塞一个PRD然后开始撸代码了，突然要我们自己从模糊的业务需求中提炼出“什么值得做”，很多人反而懵了。我在带团队时观察到一个现象：让一个5年经验的工程师用Claude Code搭一个内部工具，他花了一个小时在想“这个变量名该怎么起才规范”，而不是花时间想“这个看板到底要回答什么业务问题”。这种思维惯性，才是被Vibe Coding冲击最深的。

然后说实操。帖子提到用Claude Code搭数据看板花了2小时，这个数据我信，而且我可以提供一个更具体的对比：上周我们团队接了一个客户需求，做一个供应链异常告警的可视化页面。传统方式：前端1人天、后端1人天、联调0.5人天，总共2.5人天。我们让一个刚入职两个月的实习生用Cursor+Claude试了一次，从描述需求到跑通原型，总共用了4小时。但注意，这个原型能跑，能展示数据，能响应交互——但它在以下方面是崩的：分页接口没做防抖，连续快速点击下一页会发出三个重复请求；数据格式假设死，后端返回了一个null字段直接白屏；没有任何loading状态，网络慢的时候用户以为没反应。这些问题是“不致命但很恶心”的那种，生产环境绝对不能用。但关键是，客户看了原型后说：“这就是我要的，你们按这个做正式版吧。”于是我们正式开发时，直接拿这个原型当PRD用——前端照着UI还原，后端照着接口定义重新实现，反而节省了沟通成本。所以Vibe Coding的价值不是替代生产代码，而是把“需求确认”这个环节的成本从几天压缩到几小时。这个价值被严重低估了。

再说帖子的两个问题。第一个问题：当AI能生成80%的CRUD代码，工程师的核心竞争力是否该转向系统架构和领域建模？我的答案是：不止，而且还要加上“风险判断”和“成本决策”。CRUD代码只是最表层的东西，真正值钱的是知道“什么时候不该用AI生成代码”。举个例子，我们有个系统需要对接银行支付接口，那个接口的签名算法文档有30页，各种边界条件、重试策略、幂等处理。我试过让Claude写一次，它生成的代码在happy path上完全正确，但一旦碰到银行返回一个“交易金额超出当日限额”的异常码，它直接抛了个RuntimeException——这在支付场景里是致命的，因为这种异常需要触发异步通知、记录流水状态、并且不能自动重试。这个判断，AI做不了，因为它没有“这个字段的值如果等于X，意味着业务上要暂停而不是重试”的领域知识。所以工程师的核心竞争力不是“写CRUD”，而是“判断哪些CRUD可以交给AI，哪些必须手写并且加上领域规则”。这个判断力需要大量的踩坑经验来喂养。

第二个问题：Vibe Coding的产物如何做长期维护？这是一个非常现实的问题，而且目前没有标准答案。我们团队在尝试两种方案。方案一：prompt版本管理。我们建了一个内部prompt库，每个AI生成的代码片段都附带生成它的prompt，以及prompt的版本号。比如v1的prompt生成了一段排序逻辑，后来发现排序有问题，我们就更新prompt到v2，重新生成代码，然后手动检查diff。这个方案的问题在于，prompt本身会随着业务变化而漂移，而且不同prompt生成的代码风格不一致，后期维护成本高。方案二：传统CI/CD+AI辅助。我们规定所有AI生成的代码必须通过现有的CI流水线——单元测试、集成测试、代码扫描、性能基线一个不能少。AI只是生成初稿，后续修改全部通过git提交，走code review。这个方案更稳妥，但牺牲了速度。目前我们团队的做法是：原型阶段用方案一，快速迭代；生产阶段转方案二，强制走流程。这个折中方案运行了三个月，效果还行，但代价是团队成员需要同时维护两套思维模型——一个是对AI的“信任但验证”，一个是对传统工程的“流程即保障”。

然后我想聊聊一个帖子没深入但我觉得很重要的话题：Vibe Coding对团队协作模式的冲击。传统的软件开发流程是“产品经理提需求-架构师画图-开发写代码-测试验证”，这是一个串行流程，信息在每一层传递中都会损耗。而Vibe Coding让“产品经理直接生成原型”成为可能，这就导致了一个新问题：产品经理开始用AI生成代码后，他们不再需要等开发排期，但他们生成的代码质量又不够上生产，于是开发团队变成了“接盘侠”——要解读产品经理用AI写的一坨屎山，还得把它重构到可维护状态。这个矛盾比“工程师焦虑被替代”更现实。我们团队发生过一次典型冲突：产品经理用Claude生成了一个复杂的条件规则引擎，跑起来没问题，但代码里全是硬编码的魔法数字和嵌套十层的if-else，我们接手时想加一个规则，发现改一处崩三处。最后我们花了两天时间重写，产品经理还觉得“你们效率怎么这么低”。这个问题的本质是：AI降低了生成代码的门槛，但没有降低理解代码的门槛。当生成者不是维护者时，技术债会加速堆积。所以我认为，未来团队需要一个新的角色：AI代码审计师，专门负责评估AI生成代码的可维护性和可扩展性，决定哪些可以直接用，哪些需要重写。

再补充一个技术视角。帖子提到“AST级别的上下文理解”，这个确实关键，但我想说目前Claude Code在这块做得还不够好。我测试过一个场景：在一个已经有1000行代码的Python项目中，让Claude添加一个数据导出功能。它正确理解了已有的数据库连接池配置和ORM模型，但它在生成导出逻辑时，没有复用已有的Excel处理工具类，而是自己又写了一套一模一样的逻辑。这就是典型的“上下文理解深度不足”——它看到了当前文件的AST，但没有全局扫描整个项目的工具函数库。这个问题在大型项目中会放大。我现在的做法是：在prompt中明确要求“先扫描项目目录下utils/和libs/目录，优先使用已有工具函数”，并且把项目结构图作为上下文输入。但这还是手动操作，理想状态是AI能自动做项目级别的代码分析。这个方向目前还没有成熟的产品，但我觉得未来半年到一年内会出现。

然后说说“产品型非程序员”这个新物种。我身边已经有两个真实案例了。一个是做市场营销的女生，她完全不会写代码，但用ChatGPT+Make（自动化工具）搭了一套客户数据自动清洗和邮件推送系统，帮公司节省了每周20小时的人力。她不懂什么叫“幂等性”，但她的系统跑了一年没出过大问题——因为她的业务逻辑足够简单，不需要考虑那些复杂边界。另一个是学建筑出身的产品经理，他用Claude Code写了一个AR家具摆放的demo，在内部路演时拿到了投资。这两个人的共同点：他们定义问题的能力极强，知道“这个功能解决了什么具体痛点”，至于代码怎么实现，他们不关心。他们用的工具也不完美，但“足够好”。这让我重新思考了一个问题：我们工程师引以为傲的“代码质量”，在业务价值面前到底占多大权重？答案是：视场景而定。一个内部工具，crash两次用户会骂但不会流失；一个金融交易系统，crash一次就是百万损失。Vibe Coding的适用范围是前者，不是后者。但问题是，很多工程师用自己的生产标准去衡量所有场景，这确实是一种傲慢。

最后我想说说职业焦虑。帖子说“嘲笑Vibe Coding本质上是在回避技术平权带来的职业焦虑”，这个判断我部分同意，但我觉得更深层的焦虑是：当工具越来越智能，工程师的价值锚点在哪里？以前我们说“我能写别人写不出来的代码”，现在AI能写大部分代码，这个锚点就碎了。但我想分享一个我最近的真实感受：我用Claude Code写了一个复杂的分布式锁实现，它生成的代码在正确性上没问题，但我review时发现它没有考虑“锁续期”的场景——如果持有锁的业务逻辑执行时间超过了锁的过期时间，锁自动释放了，其他节点就会拿到锁，导致数据不一致。这个场景在分布式系统的教科书里有讲，但AI没有“长事务场景下的锁超时”这个领域知识。我加了一个看门狗协程来做锁续期。这个改动很小，但需要你理解“分布式锁不是用来解决并发问题，而是用来解决一致性问题的”这个本质。这种本质理解，AI目前做不到，而且我认为未来很长时间也做不到。因为这种理解不是通过语料训练能获得的，它需要你在生产环境中被踩过坑、见过凌晨三点的报警电话、经历过数据不一致导致的业务损失。所以我的结论是：Vibe Coding会让初级工程师的生存空间变窄，但会让资深工程师的价值更加凸显——前提是你能从“写代码”升级到“设计系统、定义规则、判断风险”。

啰嗦了这么多，总结一下我的核心观点：Vibe Coding不是玩具，也不是银弹，它是一个新的抽象层级。就像高级语言对汇编的抽象、ORM对SQL的抽象一样，它让更多人能参与创造，但同时也要求真正专业的人理解更底层的原理。工程师要反思的不是“该不该接受AI”，而是“如何在新范式下重新定义自己的专业壁垒”。这个壁垒不在代码里，在代码之上的架构、领域、风险判断里。如果你现在还只会写CRUD，那你确实该焦虑；但如果你能设计出一个即使AI也写不崩的系统架构，那你不但不会失业，反而会因为AI帮你省去了写重复代码的时间，让你有更多精力去做真正有创造性的工作。这才是技术平权的正确打开方式。

胡彦斌那个案例我也关注了，MemPalace能拿到这个星数说明市场确实在重新定义“开发者”的边界。你提到的AST上下文理解是关键，但更值得深挖的是，当“会定义问题”成为核心能力后，传统软件工程里那些充血模型、领域驱动的设计方法论，是不是也该跟着重构了？至少我团队最近几个原型都直接走Claude Code流水线，效果比预期快三倍，但代码可维护性确实是个新坑。