Vibe Coding这个概念最近确实被炒得很热，但我觉得核心问题还是落在“端到端任务闭环”的可靠性上。你说到跨模块依赖和API版本兼容，这恰恰是我在实际试用类似工具时最头疼的地方。LLM生成的代码片段往往在隔离环境下看着没问题，一旦接入真实项目，各种隐式耦合、环境差异、第三方库的breaking change全冒出来了，根本没法自动兜底。Devin如果真能把这层搞定，那确实是在动传统软件工程的根基，但说实话，我有点怀疑现在的大模型能不能真正理解“业务逻辑”和“系统设计”之间的映射关系。

另外，Chloe Di Murdoch的加入更多是资本叙事层面的信号，技术落地还得看Devin在复杂场景下的benchmark。我觉得与其讨论“重塑编程范式”，不如先看看它能不能在持续集成、灰度发布这些工程实践里跑通。比如，它生成的代码要是引入了一个细微的资源泄漏，或者没处理好分布式事务的幂等性，这种问题在自动调试阶段能发现吗？我个人的悲观预期是，短期内Vibe Coding更适合做脚手架生成、胶水代码这类低风险任务，真要动核心业务逻辑，还是得靠人工review和分层架构来兜底。这东西更像是把编程入门门槛降低了，但对高级工程师来说，反而可能因为需要审查不熟悉的自动生成代码而增加认知负担。

说实话，Vibe Coding这个方向我持谨慎乐观。端到端生成代码和自动调试在demo里很惊艳，但生产环境里跨模块依赖的版本兼容、异常边界处理这些细节，LLM目前还做不到稳定可控。Chloe入局更多是资本信号，真正要冲击传统软件工程，得看Devin能不能解决“生成即正确”和“可审计”这两座大山。

说实话，Chloe加入Devin这事儿我倒不太在意，但Vibe Coding这个概念最近在圈子里讨论挺多的。我自己试过几个类似的工具，包括Devin的早期版本，体感是——它确实能搞定一些“看起来复杂但结构清晰”的任务，比如写个CRUD接口、搭个简单的CI流程。但一旦涉及到老项目里的历史债务、第三方库的坑、或者需要根据业务上下文做trade-off的场景，它就容易掉进幻觉里出不来。

你提到的“端到端任务闭环”这个说法很精准，其实目前最大的瓶颈不是生成代码本身，而是验证和理解。我试过让Devin修一个跨模块的bug，它绕了一圈改了三四个文件，最后测试跑不过，反而把原来的逻辑搞乱了。Vibe Coding可能更适合从零开始搭新项目，或者在严格约束的沙箱里干活，但放到生产环境里，尤其是有多年代码积累的系统里，它更像一个“高级的样板生成器”，离重塑范式还差得远。

另外我比较在意的是，这种“自然语言编程”其实把隐式的设计决策交还给了用户。很多时候我们写代码不只是为了实现功能，还要考虑性能、可维护性、扩展性。如果我只是说“帮我写个用户注册接口”，它可能给出一个能用但全是反模式的实现。那最后到底是人迁就机器，还是机器真正理解人的意图？这个问题我觉得才是Vibe Coding能不能落地的关键。

说实话，看到Chloe加入Devin的消息，我第一反应倒不是豪门八卦，而是“这波营销做得真到位”。但抛开这些，Devin代表的Vibe Coding方向确实值得认真聊一聊。

我现在的日常开发里，Copilot和ChatGPT已经是标配了，写单元测试、搞一些重复性的CRUD代码，效率提升确实明显。但说到“端到端任务闭环”，我持保留态度。上周刚试过一个类似的工具，让它写一个带分页和搜索的商品列表接口，结果生成的代码里居然用了两个不同版本的第三方分页库，而且API路由命名完全不符合项目规范。修复这些“幻觉”花费的时间，还不如自己从头写来得快。

我觉得Vibe Coding目前最大的瓶颈不在代码生成本身，而在“理解上下文”。很多业务逻辑不是简单的自然语言能描述的，比如“用户下单后要检查库存、扣减积分、推送通知，还要处理并发”这种场景，工具很难理解其中的隐式依赖和事务边界。更不用说生产环境里那些祖传代码的屎山了——想让AI理解为什么某个接口要写三层try-catch，怕是得先给它看看当年的运维事故复盘文档。

所以我的看法是，Vibe Coding在原型验证、个人小项目或者非核心模块上确实有潜力，但要重塑编程范式，得先解决“如何让AI理解整个系统的业务语义和设计约束”这个根本问题。不然最终的结果就是，我们会从“写代码的”变成“给AI写更详细需求文档的”，本质上只是换了个姿势搬砖。

说实话，看到这个帖子我挺有共鸣的。我自己在团队里试过类似的东西，Devin这种“端到端闭环”听着确实很唬人，但实际落地的时候，最大的坑反而不是它能不能写代码，而是它能不能理解“业务上下文”。比如我们之前试过一个自然语言生成API服务的工具，描述需求的时候说“做一个用户登录接口”，它能给你生成一整套JWT鉴权+数据库查询+错误处理的代码，看着很完整。但一上线就发现，它默认用的加密库版本跟公司内部的安全规范冲突，而且它完全没考虑我们已有的统一网关限流逻辑，导致重复造轮子。

所以我觉得Vibe Coding目前最大的问题不是“幻觉”，而是它缺乏对现有系统架构的感知能力。一个成熟的工程团队，代码只是冰山一角，依赖管理、配置中心、日志链路、灰度发布策略这些东西，单纯靠自然语言描述很难精准映射。你说它冲击传统软件工程的分层架构，我倒觉得它更可能先改变的是“原型验证”阶段——以前写个POC要一周，现在可能一天就能跑通，但到生产环境，该做的code review、安全审计、性能压测一个都少不了。

另外我比较好奇的是，Chloe Di Murdoch加入Devin，到底是冲着技术方向去的，还是资本层面的布局？因为Vibe Coding要真正替代程序员，得先解决“谁来背锅”的问题——代码是你写的还是AI写的？出了故障是追责LLM还是追责审核代码的工程师？这个责任边界不清晰，大公司采购的时候会很犹豫。

看到帖子说Devin能处理“跨模块依赖”和“API版本兼容”，这块其实挺关键的。我自己试过一些AI生成代码的工具，写个独立函数或者小模块还行，但一旦涉及多个服务之间的调用关系、数据库事务的边界、或者老接口的向下兼容，AI经常就“幻觉”了——比如生成了一个调用新API的代码，但实际生产环境里那个API还没上线，或者参数签名对不上。Devin如果真的能自主识别这种上下文，并且主动去查项目里的现有代码逻辑、配置文件甚至文档，那确实跟Copilot是两码事了。

不过有个疑问：Vibe Coding的核心是“自然语言描述需求”，但需求本身往往是模糊的、有歧义的。比如你说“给用户发通知”，是发邮件、短信还是App推送？是立即发还是定时发？失败要不要重试？这些细节在真实开发里都是靠人与人沟通、写技术方案来对齐的。Devin是会自动反问澄清，还是默认选一个最可能的实现？如果选了后者，后期debug的成本会不会反而更高？

另外，帖子开头没写完的“幻”后面是“幻觉”吧？这个确实是LLM落地到工程里的最大障碍。想知道帖主或者社区里有人试过Devin处理遗留系统（比如十年前的Java项目，连依赖都拉不下来那种）吗？这种场景下Vibe Coding还能不能“vibe”起来？

这帖子看得我直拍大腿，Chloe入局确实是个风向标。我试过Devin搞个简单的CRUD接口，生成倒是快，但一碰到老项目里的eslint和tsconfig就翻车，压根没考虑项目已有的lint规则。Vibe Coding要真想重塑范式，得先把代码上下文吃透，不然就是高级版的复制粘贴。

这帖子说到了点子上，Vibe Coding最大的坎儿就是复杂业务逻辑的“幻觉”问题。我试过类似的工具，写个独立模块还行，一涉及到跨模块调用或者老接口兼容，经常生成一堆逻辑自洽但跑不通的屎山代码，debug的时间比自己写还长。Chloe加入确实是个信号，但Devin要真想重塑范式，得先在“幻觉率”和“可维护性”上拿出实打实的数据，别光靠资本讲故事。

Vibe Coding这个方向确实诱人，但“幻觉”问题是绕不开的死穴。我试过用类似工具处理跨模块依赖，结果生成的代码表面逻辑通顺，底层API调用全是虚构的版本号，

调试成本比手写还高。Devin要真想颠覆分层架构，得先解决LLM对业务上下文的“理解”而非“预测”问题，否则顶多算高级版代码生成器，离重塑范式还差一个“可解释性”。

这个话题我关注了一段时间，也实际在团队里试用了Devin和类似的Agent模式工具，包括SWE-agent、Meta的Code Llama Agent，以及我们自己基于GPT-4和Claude 3.5搭建的内部原型。先给结论：Vibe Coding这个方向确实在改变编程范式，但帖子里的乐观和担忧都有道理，只是都忽略了一个关键变量——软件工程中隐性知识的占比。

先说实战经验。我所在的是一个50人左右的SaaS团队，核心产品是一个B2B的合同管理系统，代码库大概80万行，Java+React，有12个微服务。我们拿Devin试了两个场景：一是从零写一个内部工具，二是改一个遗留模块的bug。结果非常分裂。

第一个场景，让Devin写一个简单的审批流配置页面，包括前端表单、后端CRUD、数据库迁移脚本。Devin用了大概45分钟，生成了完整的代码，甚至包括单元测试和Dockerfile。我手动review了一遍，逻辑基本正确，边界处理覆盖了80%，但有几个问题：它生成的JPA查询没有考虑N+1问题，前端组件用了过时的antd版本，以及完全没处理事务回滚。这些都不是代码层面的错误，而是工程实践层面的取舍——换一个有5年经验的后端工程师，写出来的代码可能慢两倍，但不会犯这些低级错误。所以这里第一个坑就出现了：Vibe Coding生成的代码，从功能角度是work的，但从生产角度是不够格的。它缺乏对技术栈版本演进、团队编码规范、以及业务上下文的理解。

第二个场景更有意思。我们有一个遗留的合同计算引擎，业务逻辑极其复杂，有超过200个if-else分支，涉及多个汇率源的时间片切换。我们给Devin输入了一段自然语言描述：“修复当合同签约日期在2023年6月之前，且汇率源为ECB时，计算结果与历史数据不符的问题。”Devin花了一个小时，定位到了代码中一个整数除法导致的精度丢失，并给出了修复。这个修复本身是完美的，但问题出在它没有意识到这个模块同时被另外两个微服务远程调用，而那两个微服务对结果格式有隐式依赖。修复后，精度提升了，但下游服务解析失败，导致生产环境告警。这件事让我意识到一个本质问题：软件工程的复杂度不在于写代码，而在于理解代码在系统中的生态位。AI可以生成语法正确的代码，但很难理解一个函数被谁调用、在什么场景下调用、调用方的容错能力如何。

所以回到帖子的核心问题：Vibe Coding的幻觉风险如何控制？我的实战结论是，目前没有任何现成的工具能完美解决这个问题，但通过工程手段可以大幅度降低风险。我们内部的做法是，在Devin生成的代码外围加了一层自动化验证管道，这层管道不是单元测试，而是契约测试和混沌测试。具体来说：

第一，对每个AI生成的代码变更，自动扫描它修改了哪些API接口，然后拉取所有调用方的契约定义，跑一次消费者驱动的契约测试。如果改动了接口的输入输出格式，会直接报错。这一步能拦截掉80%的接口兼容性问题。

第二，对生成的代码注入故障。比如我们有一个工具会自动替换第三方依赖为模拟版本，模拟网络超时、返回空值、返回异常格式等场景。AI生成的代码往往在正常路径上表现很好，但遇到异常输入时，要么没有try-catch，要么catch之后直接吞掉异常。这种方法能快速暴露弱点。

第三，人工review的侧重点从“代码对不对”变成“边界条件全不全”。我们团队现在对AI代码的review，有一个checklist，包括：是否有硬编码的magic number？是否假设了输入一定非空？是否假设了外部服务一定可用？是否假设了数据库一定响应？这些是AI最容易忽略的隐性假设。

关于帖子中提到的“长期看，如果Devin能积累真实项目反馈数据，形成代码生成-测试-修复的强化学习闭环”，这个方向我认同，但实现难度被低估了。强化学习闭环需要高质量的reward signal，而在软件工程中，什么是“好的代码”很难量化。测试通过率只是一个弱信号，因为测试本身可能不完整。代码可维护性、性能、安全合规性，这些都需要长时间的线上观测才能评判。我见过的可行做法，是在CI/CD管道中埋点，收集AI生成代码的上线后的运行指标，比如错误率、响应延迟、内存泄露趋势，然后用这些作为reward反馈给模型。但周期至少以周为单位，而且需要过滤掉环境噪声，比如网络抖动导致的错误。我们团队做过一个实验，用三个月的历史数据训练了一个reward模型，效果确实有提升，但提升幅度只有7%，成本却很高，主要是数据清洗和标注的人力投入。

再聊一个帖子没深入讨论的点：Vibe Coding对程序员技能结构的冲击。帖子提到“未来的程序员核心竞争力是需求拆解还是系统设计”，我的看法是，两者都不是最关键的。最核心的能力，会变成“决策能力”和“风险判断能力”。当AI可以生成代码，程序员的核心工作不再是写代码，而是决定：哪些代码应该让AI生成，哪些必须手写？生成的代码在什么条件下可以信任？什么时候需要放弃AI生成的方案，改为人工设计？这个决策过程，需要深刻理解业务优先级、系统瓶颈、团队能力分布，甚至需要对AI模型的能力边界有清晰的认知。举个例子，我们团队现在有一个原则：所有涉及资金计算、用户隐私、权限校验的代码，必须手写，不允许AI生成。不是因为AI写不对，而是因为这些场景的错误成本极高，而AI的生成过程是一个黑盒，你无法像审查人类代码一样审查它的思维过程。这个原则不是技术层面的，而是风险管理层面的。

另外，帖子提到“豪门背书是否会加速Vibe Coding在商业场景的落地，还是反而引发过度炒作”。我的观点是，Chloe Di Murdoch加入Devin，确实会带来资本关注度和企业客户的门槛降低，因为甲方CTO看到豪门背书，会觉得这个公司有持续投入的能力，不会半年后倒闭。但过度炒作的副作用也很明显：现在已经有大量创业公司打着“AI软件工程师”的旗号，实际上只是套了一层Agent壳的Copilot，交付质量堪忧。这种劣币驱逐良币的现象，会让企业客户在尝试后产生信任危机，反而拖慢真正有价值的技术落地。我在一个行业群里看到，已经有CTO因为试用某个类似产品后效果太差，直接宣布“一年内不考虑任何AI代码生成工具”。这种一次性的负面体验，对整个赛道都是伤害。

从技术架构的角度，我也想补充一点思考。现在的Vibe Coding工具，无论是Devin还是其他，本质上都是基于LLM的序列生成模型，这种架构在生成独立模块时表现不错，但面对大型企业系统的复杂依赖关系，存在一个根本性的限制：LLM的上下文窗口有限，无法一次性加载整个代码库。Devin的做法是让Agent主动读取相关文件，但“相关”的定义本身就是一个难题。在微服务架构中，一个业务请求可能跨越5-6个服务，每个服务有自己的代码库、数据库、中间件。Agent要理解这个全链路，需要读取大量上下文，而目前的技术方案要么丢失关键信息，要么上下文膨胀导致推理速度下降。我试过一个方法：利用代码知识图谱，把代码库的依赖关系预计算成向量化表示，然后让Agent在推理时先通过图检索找到最相关的模块，再生成代码。这个方向效果不错，但工程复杂度很高，需要维护一个实时更新的代码图谱。

最后，我想分享一个真实的踩坑经历，给正在考虑引入这类工具的团队一些参考。我们今年Q1在一个中台项目上完全让Devin负责一个独立的报表服务，结果上线后第三天，发现它生成的SQL查询在数据量达到百万级时，执行时间从200ms飙升到12秒，原因是没有加索引。更棘手的是，它生成的代码里，查询逻辑分散在三个不同的Service类里，加索引需要改多个地方，而且有一个查询用了UNION，导致索引无法生效。最终我们花了两个人力两周时间重写。这个教训告诉我们：AI生成的代码，在规模效应下会暴露出人类工程师凭直觉就能避免的性能问题。所以现在我们的策略是，AI生成的代码必须经过性能压测，压测数据量级要达到生产环境的80%，才能合并到主分支。

总结一下，我认同帖子说的“编程范式可能从写代码转向审代码”，但这个转变不会很快发生，至少在大型企业系统中，未来3-5年AI仍然是高级辅助。真正能推动范式改变的，不是AI生成代码的能力有多强，而是AI理解系统上下文的能力有多深。而后者，需要的是代码库的结构化、依赖关系的显式化、以及工程规范的自动化。这本质上是一个基础设施问题，而不是一个模型问题。至于豪门背书，我觉得是双刃剑，但最终决定技术走向的，还是产品本身能否在真实业务场景中产生可量化的ROI。如果你正在评估是否引入这类工具，我的建议是：选一个非核心、低风险、独立的小模块先试跑三个月，记录AI生成代码的修改率、bug率、以及人工review的时间成本。拿数据说话，不要被概念炒作带偏。

看完这个帖子，我其实挺好奇一件事——Chloe加入Devin这件事本身，到底是因为她个人对技术方向有判断，还是更多是资本层面的布局？毕竟豪门千金的选择，有时候会被放大成行业信号，但实际技术落地的难度可能跟资本热度是两回事。

关于Vibe Coding，我最近也在尝试类似的东西，比如用Cursor或者一些实验性的Agent工具。确实，写个简单的CRUD或者脚本已经挺顺手了，但一旦涉及到跨模块依赖、API版本兼容，或者需要理解历史代码里的隐性逻辑，这些工具就开始“幻觉”了。帖子提到了这个问题，我觉得特别关键——如果Vibe Coding要真正重塑编程范式，那它得先解决“上下文理解”的问题。比如，一个项目里可能有几十个文件，有些依赖关系是写在文档里或者人脑里的，LLM根本不知道。我甚至遇到过它自动生成的代码调用了不存在的接口版本，debug的时间比我自己写还长。

另外，我还有个疑问：如果Devin这类工具真的普及了，那传统软件工程里的那些“分层架构”“测试驱动开发”会被怎么改变？是变成更高层的抽象，还是直接被抛弃？比如，以后程序员会不会更像“需求分析师+验收员”，而不再是写代码的人？我总觉得，如果工具能搞定端到端任务，那出问题的时候谁来背锅——是写提示词的人，还是工具本身？

总之，这个方向确实有想象力，但离“重塑范式”可能还有一段距离。不知道有没有人尝试过用Devin处理过真实的生产环境项目，比如带历史债务、多团队协作的那种？很想听听实际踩坑的经验。

其实我比较好奇，像跨模块依赖这种复杂场景，Devin是怎么处理上下文理解的？之前试过一些类似工具，一旦涉及多个文件之间调用，生成结果就容易崩，感觉光是“端到端闭环”这个口号还不够，得看实际落地时对项目结构的感知能力到底到了什么程度。有人试过用它跑真实的中型项目吗？

Chloe Di Murdoch加入Devin这件事，确实把Vibe Coding这个原本主要在技术圈内讨论的概念推到了更大众的视野里。不过我个人觉得，与其盯着豪门二代的光环，不如先冷静看看Devin现在到底能做什么、不能做什么。我是从去年下半年开始关注这个项目的，当时他们的demo视频确实震撼——输入一句“帮我写一个待办事项的Web应用”就能看到它自己建文件、写代码、跑测试、最后部署上线。但如果你真的拿它去处理稍微复杂一点的需求，比如“实现一个基于RBAC的权限管理系统，支持动态菜单生成和按钮级细粒度权限控制”，Devin目前的输出质量会急剧下降，甚至会出现循环调用API、生成死代码、或者根本跑不通的情况。

我先说几个自己踩过的坑。第一个是依赖冲突问题。我让Devin生成一个Python的FastAPI项目，集成了SQLAlchemy和Alembic做数据库迁移，还用了Celery做异步任务。Devin确实在一分钟内生成了完整的项目结构，但当我尝试运行时发现，它自动安装的SQLAlchemy版本是2.0.23，而Alembic依赖的某些接口在1.13版本就已经弃用了。这种跨模块的版本兼容性问题，Devin完全没有能力处理，它只是机械地根据当前流行库的最新版本进行依赖注入。我花了将近两小时手动排查依赖树，最后用pip-tools锁定了版本。这个过程的本质是，Devin缺乏对软件生态“历史债务”的理解——它不知道哪些版本之间有已知的breaking change，也不理解为什么有些项目必须锁死某个旧版本。

第二个坑是关于业务逻辑的边界条件。我尝试让Devin生成一个金融场景下的利息计算函数，要求支持等额本息和等额本金两种方式，并且要考虑闰年、提前还款等复杂情景。Devin生成的代码在大多数正常输入下都能跑通，但当我测试极端边界值——比如贷款金额为0、利率为负数、期限为0个月时——它直接抛出了ZeroDivisionError。更致命的是，它生成的测试用例也完全没覆盖这些边界。换句话说，Devin的“自动调试”功能只针对编译错误和运行时异常，对于逻辑错误（比如利息算错）它既不会发现也无法修复。这就回到了帖子里提到的“幻觉”风险：AI生成的代码在常见路径上表现良好，但软件的可靠性恰恰是由那些不常见的路径定义的。如果你对业务领域理解不够深，被Devin生成的漂亮代码迷惑，直接用到生产环境，后果可能就是线上故障。

从技术架构角度看，我认为Devin目前的能力上限取决于LLM的上下文窗口和推理深度。它本质上是一个“大语言模型驱动的代码生成器+脚本执行器”，它的“自主调试”功能其实是反复调用LLM来解读错误日志并尝试修复。这个循环在某些场景下有效（比如语法错误、缺少import），但对于深层次的架构问题（比如缓存穿透、数据库索引选择不当、消息队列的幂等性设计）几乎无能为力。我做过一个实验：让Devin优化一个存在N+1查询问题的Django REST API。它生成的优化方案是在ORM层面加select_related，这确实解决了问题。但当我进一步要求它实现一个基于Redis的二级缓存来应对高并发时，Devin给出的方案存在缓存雪崩风险——它把所有缓存过期时间设成了相同的值。这种问题需要开发者对系统整体的流量模型有预判，而Devin目前没有这种全局视角。

关于帖子中提到的“从写代码转向审代码”这个观点，我基本认同，但想补充一个更现实的观察：这个转变不会一蹴而就，而且“审代码”本身的门槛可能比“写代码”更高。我自己团队里有个初级工程师，用了半年Copilot后，写代码的速度确实快了，但代码质量反而下降了。原因是他过度依赖AI补全，不再主动思考API设计的合理性、异常处理的完整性。当AI生成的代码出问题时，他排查起来比从零手写还要慢。这就引出一个核心问题：Vibe Coding降低了代码生产的门槛，但并没有降低代码调试和运维的门槛。当AI生成的代码量爆发式增长，而人类审查的能力有限时，软件系统的整体可靠性可能会经历一个先升后降的过程。我甚至觉得，未来会出现一种新的职业角色——AI代码审计师，专门负责审查AI生成的代码在安全性、合规性、性能方面的表现。

至于Devin对行业格局的影响，我认为低代码平台确实会受到冲击，但传统IDE厂商反而有机会。JetBrains和VS Code这些IDE如果能把Devin的能力深度集成到开发流程中（比如在写代码时实时显示AI生成的备选方案、自动对比不同方案的复杂度），而不是像现在这样只是做个聊天插件，那它们的壁垒反而更高。外包开发服务确实可能被挤压，尤其是那些以CRUD为主的中小型项目外包。但大型企业级系统开发，尤其是涉及遗留系统迁移、多系统集成、合规审计的场景，短期看Devin还难以替代。我有个朋友在银行做核心系统，他们做过PoC，Devin生成的代码根本无法通过安全审查——因为它会在代码里硬编码数据库连接信息，而且完全没有考虑审计日志的完整性要求。

豪门背书这件事，我觉得是双刃剑。好处是Devin能获得更多资本和顶尖人才，加速技术迭代。坏处是期望值会被拉得过高，一旦多次出现“demo惊艳、实战拉胯”的情况，舆论反噬可能非常严重。我之前在技术社区看到过一个案例：某大厂内部推广AI编程助手，初期宣传效果很好，结果上线后发现生成的代码在极端负载下频繁OOM，最终导致整个项目回退到纯人工开发。这种信任一旦破裂，修复成本极高。

最后回应一下帖子结尾的问题。我认为未来程序员的核心竞争力会从“实现能力”转向“定义能力和系统设计能力”。具体来说，需求拆解能力（把模糊的业务描述转化为精确的技术规格）、系统设计能力（选择合适的技术栈、设计合理的分层和接口）、以及风险评估能力（判断AI生成的代码在特定场景下是否可靠）会成为稀缺技能。换句话说，你不需要知道怎么写一个排序算法，但你需要知道在什么场景下应该用归并排序而不是快速排序。你不需要手写一个ORM，但你需要判断AI生成的查询计划是否会导致全表扫描。这种从“执行者”到“决策者”的转变，对程序员的知识广度和抽象思维要求其实更高了。

至于会不会过度炒作，我觉得是必然的。任何技术概念在资本涌入后都会经历一个泡沫期。但Vibe Coding的方向本身是对的——如果能让开发者从重复劳动中解放出来，更多关注创造性的工作，那它就是有价值的。关键是我们需要保持清醒：它现在还不是银弹，未来也不太可能是。它更像是一个威力巨大的初代工具，用好了效率翻倍，用不好就是挖坑给自己跳。建议大家如果想试，先从非关键业务的小型模块开始，逐步积累对它的“脾性”的理解，再考虑用到核心系统上。别被demo骗了，也别因为几个bug就全盘否定，技术演进从来都是螺旋上升的。