Vibecoding是革命还是泡沫？资深开发者拆解AI编程真相

Vibecoding：又一场胡扯革命？

当LinkedIn和科技博客再度为「一人两周复刻Adobe全家桶」狂欢时，一位在数字标牌行业摸爬滚打二十余年的开发者泼了盆冷水。他用Photoshop克隆项目PhotoCraft和德国c't杂志的实测结果，拆开了Vibecoding光鲜外壳下的真实结构——以及那些被刻意忽略的代价。

Vibecoding到底是什么，谁在鼓吹它

Vibecoding指用LLM或所谓AI代理生成代码，只做功能层面的「跑通验证」，不深究代码质量与架构合理性。作者并不否认这种方式的吸引力：他自己1998年就在C++功底不深的情况下发布过DJ软件，理解那种「用自己的工具把想法做出来」的冲动。

真正让他反感的是无脑跟风者——他们不懂技术却制造错误预期，产出更多劣质软件和安全漏洞。「只有傻瓜才相信聪明工具能替代多年知识与经验。」

LLM（Large Language Model，大语言模型） 和 AI代理（AI Agent） 是Vibecoding的两个核心工具概念。LLM指基于海量文本训练、能生成代码的神经网络模型（如GPT系列、Claude等）；AI代理则是在LLM基础上增加了规划、工具调用和执行能力的系统，可自动完成多步骤任务。作者强调，这些工具擅长从公开语料中学习模式，但对未公开的私有协议、专利算法或仅存在于行业实践中的知识无能为力——这正是它们在克隆Photoshop等复杂软件时遇到的根本局限。

80%魔咒：LLM加速的只是最容易的那一段

作者以ArtCraft和PhotoCraft为例。后者自称用纯Rust「洁净室重实现」Photoshop，支持图层、蒙版、调整图层、真实PSD文件。乍看之下速度惊人。

但一个异端问题随之而来：GIMP存在了30年，拥有庞大社区，至今仍难以比肩Photoshop；Affinity、Pixelmator等商业软件也只能在细分场景立足。难道整整一代聪明开发者都没想到去克隆Adobe的界面和功能？

答案是「80%规则」：从零开始冲到80%很快，剩下20%会吞掉绝大部分时间与精力。LLM恰恰把到达80%的时间压缩到极致——哪怕对非程序员也是如此。问题在于，那20%包含的正是：

文件格式：PSD历经30年演化且仅部分公开，智能对象、图层效果、调整图层的无损往返极其困难，LLM只懂公开文档
色彩管理：ICC、CMYK、软打样、印前流程，GIMP和Scribus挣扎多年
性能：亿像素文件、分块、GPU管线、内存管理，需要多年工程积累
视频编解码：H.264、HEVC、ProRes涉及授权与专利，LLM无法解决
生态：插件、动作、脚本，以及与代理商和印刷厂的既有工作流

此外还有两重法律风险：专利适用于任何克隆实现，与代码怎么写无关；而基于Photoshop文档、论坛乃至逆向工程材料训练的LLM，很难被称为「洁净室实现」，这一声明并不构成保护。

德国c't杂志的实测给出了预期中的结论：涉及代理商等既有项目文件的专业工作流，被测试版本无法可靠替代原版，「试用者不应拿生产数据去碰」。换言之，Vibecoding版PhotoCraft只是把GIMP早已具备的80%又加速做了一遍。

洁净室实现（Clean Room Implementation） 是软件法律中的一个特定概念：开发团队在完全隔离的环境下，不接触任何受版权保护或专利保护的原始代码、设计文档或逆向工程材料，仅依据公开的功能规格说明独立开发。其法律意义在于，如果过程被证明是「洁净」的，可以有力抗辩抄袭指控。作者指出，基于Photoshop文档、论坛乃至逆向工程材料训练的LLM，其输出必然隐含了原始产品的设计信息，因此很难声称是洁净室实现——这一声明在法律上并不构成保护。

用户为什么兴奋：评价体系的错位

开发速度带来巨大关注，因为用户看软件的方式和程序员完全不同：

没人读代码。用户只看界面、功能列表和能不能用，而这正是Vibecoding的强项
高频发布制造营销理由。软件最大的恐惧是项目死掉，周更等于「这里在动」，哪怕只是修上周的bug
快速响应胜过无bug。当天报bug当天修复会让人惊喜，用户不会意识到这个bug本不该出现
星星吸引星星。200星的项目比20星的更可信，这与质量无关，是自我强化的循环
多数人不在乎代码是谁写的。「这是谁写的」主要是开发者才会问的问题，用户不会去看上帝类、缺失的schema版本管理、重复代码和成百上千个空的catch ()

一条简单规则：复杂度的成本不会线性增长。LLM推后了临界点，但没有消除它。

具体会出什么问题：数据说话

原文引用了多项独立研究，彼此交叉印证：

据GitClear对数百万行代码的分析，AI助手普及以来重复代码块比例显著上升，重构代码量下降。DORA报告估算AI采用率提升25%会带来约1.5%吞吐量下降和7.2%稳定性下降。METR的研究则发现，经验丰富的开源开发者使用LLM后实际慢了19%，却自认为快了20%。

作者由此指出核心矛盾：LLM提供了程序员，但没有架构师、没有有经验的评审者、没有那个会说「不」的人。这些都压在一个人身上。有100个虚拟开发者时，瓶颈不在写代码，而在工程师必须理解写了什么。这无法靠算力扩展，只能靠时间和一支靠谱的人类专家团队。

DORA（DevOps Research and Assessment） 是Google Cloud旗下研究DevOps实践与软件交付效能的项目，其年度报告是行业广泛引用的基准。METR（Model Evaluation & Threat Research） 则是一个专注评估AI模型能力与风险的非营利研究机构，其受控实验发现经验丰富的开源开发者使用LLM后实际完成任务的时间反而增加了19%，尽管他们主观感觉快了20%。GitClear 是一个代码分析平台，通过扫描数百万行代码追踪重复代码块、重构频率等指标。这三项研究分别从代码质量、交付稳定性和开发者效率三个维度，交叉印证了AI辅助编程的隐性成本。

「更多更好的AI就能解决」为什么站不住

面对一个5000到6000行的上帝类，LLM看似能轻松塞进上下文。但拆分时边界设在哪，必须由理解系统的人决定，否则只会得到十个互相import的小上帝类。隐藏耦合会在运行时才暴露：一个被半个服务器访问的数据库单例，拆开后初始化顺序和共享状态都会变。重构的安全性取决于能捕获旧行为的测试，而LLM偏爱复制测试或手写schema，结果是「测试测试本身」。更现实的是，每周数百次提交意味着重构期间代码又在变，你必须暂停新功能开发——作者11年前就经历过：两个熟练工程师花了近两年清理他自己添加功能留下的烂摊子。

LLM能重构，但需要有人知道往哪走，并愿意暂时不交付新东西。这才是真正的瓶颈。

数字标牌案例：债务不只在代码里

作者所在的细分行业自Vibecoding流行以来方案数量暴增。这里多了一层风险：初期没人承担后果。多数人在家里的树莓派上测试，坏了也无所谓。成本只有在上线后黑屏会烧钱时才显现。

他举了2014年自家公司的案例：某经销商自研播放器，低估USB闪存的写入寿命，卖出约500台。一年后客户每月要修10到20台，每台约300欧元的技术员上门费。为节省闪存，他们停写了日志和播放报告——对一个靠卖广告位的网络来说，这等于砍掉了存在的理由。替换设备花了三年。

一个开局做出的、无人质疑的架构决策，就足以造成这样的后果。这正是Vibecoding缺失的角色：那个说「不」的人。而当成千上万台设备跑着旧版本和过时协议、自托管服务器无人管控时，你自己的SaaS服务器可以重构，客户现场的安装却不能。

USB闪存写入寿命 是嵌入式系统中的一个经典陷阱：闪存芯片的每个存储单元只能承受有限次擦写（通常数千到数万次），频繁写入日志、播放报告等数据会迅速耗尽寿命。在数字标牌场景中，播放器持续写入运行日志和广告播放记录，若未做写入均衡或限制写入频率，设备可能在一年内批量失效。作者案例中的经销商正是低估了这一点，为节省闪存而停写日志和播放报告，却无意中摧毁了广告网络赖以计费的核心功能——这揭示了架构决策的连锁后果往往远超代码本身。

务实地使用LLM：四条原则

作者给出的做法相当克制：

慢。设定规则，短牵引绳，坚持测试，避免代码和测试中的重复
讨论。先和两个LLM讨论方案与最佳实践，直到完全理解要做什么
小步。别被生成速度震住，看它实际做了什么；LLM爱重复、爱过度设计补丁、爱写自我测试的单元测试
带明确目标重构。你定结构，LLM做跨文件苦力——这是它最大的价值

适合交给LLM的：样板代码与平台杂务（CRUD、配置对话框、翻译、文档）、bug初筛、技术陪练。应当保持警惕的：核心功能，比如时序、内存管理、任何涉及线程或媒体管线的C++代码——LLM会生成在负载下行为不同的「看似合理」代码。

现实预期是：不牺牲质量的前提下，产出或许能翻两三倍。不是 hype 独角兽那种数周上千次提交的节奏，而是可见且可持续的节奏。

结论：新工具是真的，胡扯革命也是真的

作者认为这确实是新时代，但主要由错误预期和认知缺失驱动的喧嚣所裹挟。单纯优化生产速度很吸睛，同时也在累积技术债，账单最终由用户和客户支付，并侵蚀人们对「专业」软件开发的信任。他自己11年前也犯过类似错误，以为加功能是成功的唯一因素，付出了高昂代价才纠正过来。

那个不太隐蔽的秘密是：成功的软件远不止写功能。