Vibe Coding 一段时间后，我的一些新感受
Vibe Coding 又用了有一段时间。
一开始接触它的时候，更多是新鲜感。看到 AI 能读项目、改文件、跑命令、修问题，会觉得这东西多少有点离谱。
但用久一点之后，新鲜感会慢慢退下去，剩下的就是一些更真实的体感。
它确实提高了效率。
但它也不是魔法。
它让开发变快了
Section titled “它让开发变快了”以前做一个功能，很多时间会花在重复劳动上。
比如找文件、改样式、补类型、处理小 bug、跑构建、看报错。
这些事情不难，但很碎。
碎事情多了，人就容易烦。
Vibe Coding 最大的变化，是它把这些碎事情接过去了一部分。很多时候，我只需要描述清楚目标，它就可以帮我把第一版做出来。
这带来的不是简单的“少写几行代码”。
而是反馈变快了。
以前一个想法可能要等自己慢慢写完，才能知道效果行不行。现在可以更快看到一个版本，然后再判断它是不是对。
这点很重要。
因为很多想法不是想出来的，是做出来之后才知道哪里不对。
但快不等于稳
Section titled “但快不等于稳”AI 写代码很快。
有时候快得让我有点不放心。
它会非常自信地修改文件，也会非常自然地补一些它认为合理的逻辑。
问题是，它的“合理”不一定等于我的“合适”。
比如一个页面，它可能会加很多解释文案，让功能看起来更完整；但我的博客更适合保持安静、简洁。
比如一个样式，它可能会顺手加背景、卡片、动效；但我可能只需要一个很轻的交互反馈。
所以用 Vibe Coding 越久，我越觉得验收很重要。
不是它写完就结束了。
而是它写完之后，我要重新看一遍：
- 有没有改过头
- 有没有偏离原来的设计
- 有没有引入不必要的复杂度
- 有没有破坏已有习惯
- 有没有只是“看起来很努力”
有时候 AI 的代码没错，但气质不对。
这就需要人来判断。
上下文比提示词更重要
Section titled “上下文比提示词更重要”以前我会觉得提示词很重要。
现在我觉得，上下文更重要。
一个项目里已经有自己的结构、命名、样式、内容风格和取舍习惯。如果 AI 不理解这些，它就很容易写出一个“能跑但不像这个项目”的东西。
所以我现在更愿意先让它读代码。
先看现有文件。
先理解已有逻辑。
再让它动手。
这和人接手项目其实是一样的。一个靠谱的人不会上来就重构，他会先看看这个项目原来是怎么长出来的。
AI 也一样。
给它足够的上下文，它会更像协作者。
不给上下文，它就更像一个手很快的陌生人。
人的判断没有变少
Section titled “人的判断没有变少”Vibe Coding 用得越多，我越不觉得人会变得不重要。
相反，人要负责的东西变得更靠前了。
以前我主要关心“怎么实现”。
现在我更多关心：
- 要不要做
- 做到什么程度
- 放在哪里合适
- 会不会影响长期维护
- 这个功能是不是符合产品气质
AI 可以帮我往前推，但方向还是要自己定。
如果方向不清楚，AI 只会更快地把混乱实现出来。
这也是我最近很明显的感受：Vibe Coding 不是让人不用思考，而是把思考的位置往上抬。
以前卡在代码细节里。
现在卡在产品判断里。
听起来好像还是会卡。
但卡得高级一点。
它也会制造整理需求
Section titled “它也会制造整理需求”还有一个很现实的问题：AI 参与越多，项目越需要规则。
比如文件怎么命名，文章放哪里，数据抽到哪里，样式怎么复用，哪些信息不能写进仓库。
如果这些规则不清楚，AI 每次都会根据当下情况做一个“看起来可以”的选择。
短期没问题。
长期就会慢慢乱。
所以我最近反而更重视项目规范。
比如博客按年份月份归档，URL 用 slug 固定；友链和技术栈抽到 data；部署信息用 .env；新增文章用脚本生成。
这些事情看起来不酷。
但它们能让 AI 更好地工作，也能让未来的自己少骂几句过去的自己。
现在再看 Vibe Coding，我已经不太把它当成一个炫技词了。
它更像一种新的工作方式。
不是我把所有事情交给 AI。
而是我负责目标、边界、判断和验收，AI 负责承担大量具体执行。
这个分工如果配合得好，效率确实会高很多。
但如果人自己没想清楚，它也会很快把问题放大。
所以我现在对 Vibe Coding 的感受很简单：
它不是让开发变得不用动脑。
它是让开发者必须更清楚地知道，自己到底想要什么。
决策会变得越来越重要。