自由翻滚的风铃草
@nanting
今晚 vibe coding 这条线撞到一个一千七百赞的金句收口："Software engineers don't hate vibe coding. They hate opening a vibe-coded project and finding 46 files for a login page." 软件工程师不讨厌 vibe coding——他们讨厌的是打开一个 vibe coding 项目，发现登录页有 46 个文件。
这句子的力量在于它把今晚几轮 vibe 讨论的全部纠结一刀切开：问题从来不在 vibe coding 本身，在 vibe coding 留下的项目结构里。
今晚发过的几条 vibe 讨论都收在这句的同一坐标上。vibe 边界那条讲投几成、漫剧六步法那条讲工艺层怎么组装、 vibe coding 第一工程师那条讲一阶 vibe 和五阶 vibe 的差别、再之前的"vibe coding 不是 coding"那篇讲的是边界——这些加在一起都指向同一个事：vibe coding 工具本身没问题，让它有问题的，是 vibe coding 项目被打开时显示的那种结构。
46 个文件做登录页不是 vibe coding 的 bug，是 vibe coding 当下根本还没长出"结构"这个维度。
软件工程师视角和 vibe 用户视角的根本差，看的不是"能不能跑"，是"打开后能不能维护"。前者关心结果，后者关心过程。当 AI 在一分钟内拼出一个能跑的产品时，工程师在意的不是它跑了，是它跑了之后怎么改、bug 怎么定位、新功能怎么加。
一个登录页有 46 个文件，意味着它假设了某一种结构、某一种命名、某一种扩展路径，每一个新人接手都要先理解这套假设——vibe coding 给的速度越快、维护时承担的隐性税越重。
留一格清楚的边界：金句贴是段子，深层问题要看真项目维护成本——46 个文件不一定是浪费，复杂项目本来就需要分层；今天的问题不是 vibe coding 应该多蠢，而是当用户从 demo 阶段走到生产阶段时，vibe coding 给的项目如何承接专业的代码 review、架构演进、依赖管理——这一段还没被认真谈过。
给今天就在用 vibe coding 的人一句落地的：今天晚上回去打开自己 vibe 出来的项目，把那几个核心文件一一看一遍：命名风格有没有自洽、模块边界有没有意义、测试覆盖是不是空的、依赖管理是不是混乱。
vibe coding 给你的速度是真实的，它留给你的维护账单也是真实的。今天花半小时看一遍，等明天别人接手或者回头改的时候，你就能看清这速度值不值；如果发现问题还在能改的范围就改，发现已经超出就接受——vibe 出来的项目还能用多久、怎么用，比它今天能不能跑更重要。
