接触 Vibe Coding 已经八个多月了。
回头看，这段时间给我带来的变化非常大。它不只是让我多认识了一些 AI 工具，也不只是让我写代码的速度变快了。更重要的是，它改变了我看待开发这件事的方式。
以前我更关注技术本身。
我会想这个功能应该怎么实现，代码怎么写，框架怎么选，接口怎么设计，数据库结构怎么拆。很多时候，注意力会自然落在“如何把代码写出来”这件事上。
而现在，我越来越多地开始关注产品本身。
这个功能为什么要做？用户会怎么使用？流程是不是顺？页面是不是清楚？这个需求背后真正要解决的业务问题是什么？这些问题慢慢变得比“代码怎么写”更靠前。
这就是 Vibe Coding 对我最大的影响。
在更早的时候，我使用 AI 的方式其实很简单。
去年的上半年，AI 对我来说更多还是一个开发辅助工具。它主要停留在 Web 式的 Chat 形态里，我会问它一些问题，让它帮我解释概念、检索资料、分析报错、生成一些代码片段。
那个阶段的 AI 很像一个随时在线的助手。
它能帮我查东西，也能帮我补充思路，但大多数时候，真正的开发过程还是由我自己主导。我要自己拆任务、自己打开项目、自己修改文件、自己调试和验证。
AI 参与了过程，但没有真正进入开发工作流的中心。
那时候我对它的理解也很朴素：它可以提高效率，可以减少搜索成本，可以帮我更快理解一些不熟悉的知识。
但我还没有意识到，它会在后面改变整个开发方式。
后来，Agent 的概念越来越火。
我开始看到各种 CLI 工具出现，也开始频繁听到 token、上下文、模型网关、提示词、工具调用、代码代理这些词。AI 不再只是一个聊天窗口，它开始进入终端、进入编辑器、进入项目目录，甚至可以直接阅读代码、修改文件、运行命令、检查结果。
这和以前完全不一样。
以前是我把问题复制给 AI，然后把答案再搬回项目里。现在则更像是 AI 直接坐进了项目现场，和我一起看代码、改代码、验证代码。
这时我也开始加入 Vibe Coding 的行列。
刚开始的时候，我其实并不知道这些工具应该怎么用。面对各种模型、API、CLI、代理配置，我会有点茫然。它们看起来都很强，但真正落到自己的项目里，还是需要一段适应过程。
我需要理解它们的边界。
哪些事情可以交给它？哪些事情必须自己判断？什么时候应该让它改代码？什么时候只是让它分析？上下文应该怎么给？任务应该怎么拆？
这些并不是看一篇教程就能立刻掌握的。
后来我逐渐知道了 New API 这类整合型网关，也开始理解它们在 AI 工作流中的意义。
模型越来越多，不同模型有不同能力、价格和使用限制。如果每一个工具都单独配置，就会很分散。整合型网关的意义在于，它能把不同模型入口统一起来，让工具调用变得更稳定，也更容易管理。
再后来，我接触到了 Claude Code 这类工具。
它让我真正感受到“AI 参与编码”这件事和普通问答的区别。
普通问答更像是你问一句，它答一句。CLI 编码工具则更像是你把它放进项目里，它可以沿着任务往前走：阅读文件、理解结构、修改代码、运行检查、再根据结果继续调整。
这时候，AI 就不只是回答问题，而是在参与完成工作。
当然，这并不意味着我可以完全放手。
相反，我越来越感觉到，使用这类工具时，人要承担更高层次的判断。你要知道目标是什么，知道验收标准是什么，知道哪里不能乱动，知道生成的代码是否符合项目长期维护的方向。
AI 可以很快，但方向仍然要由人来定。
过去我做一个东西，第一反应常常是技术问题。
页面怎么写？接口怎么接？状态怎么管理？样式怎么调？
现在我会先想产品问题。
这个页面存在的目的是什么？用户第一眼应该看到什么？如果他想继续阅读，路径是不是顺？如果他在移动端打开，会不会困惑？如果内容越来越多，列表是否还能承载？如果未来要部署、维护、持续写文章，流程是不是足够轻？
这种变化很明显。
因为当 AI 可以承担大量具体编码工作后，我的注意力就被释放出来了。我不再需要把所有精力都压在每一行代码上，而是可以站得稍微高一点，看整个产品的结构和体验。
这并不是说技术不重要。
技术仍然重要，而且越到后面越重要。只是技术不再是唯一中心。它更像是实现产品目标的手段，而不是最终目的。
以前我可能会因为某个技术点很有意思就想做点东西。现在我会先问：这个东西解决了什么问题？它对用户、对内容、对长期维护有什么价值？
Vibe Coding 也让我更关注业务流程。
一个功能不是孤立存在的。它前面有入口，后面有结果，中间有状态变化和用户决策。只把某个页面写出来，并不代表功能真的完成。
比如一个博客站，不只是能展示文章就够了。
还要考虑：
- 新文章怎么创建。
- 分类和标签怎么维护。
- 首页如何呈现内容价值。
- 列表页如何让读者快速判断是否要点进去。
- 文章页如何让阅读体验稳定。
- 部署后如何只专注维护内容。
这些都不是单纯的代码问题，而是产品流程问题。
当 AI 能帮我更快完成具体实现后，我反而会花更多时间思考这些流程是否合理。
我会更在意一个功能放在系统里是不是自然，一个页面是不是为后续内容增长留好了空间，一个交互是不是符合读者直觉。
这其实是更接近产品视角的思考。
这八个多月里，我最大的感受是：AI 把很多“执行层面的阻力”变小了。
以前想到一个功能，可能要先考虑技术栈、查文档、写样板代码、调样式、修报错。很多时候，还没真正验证想法，就已经被实现细节消耗掉了。
现在不同了。
我可以更快把想法变成可运行的东西，再通过实际效果判断它是否值得继续优化。
这会让开发节奏发生变化。
以前更像是先想很久，再动手实现。现在更像是先做出一个版本，然后不断观察、调整、迭代。
AI 给我的不是简单的偷懒，而是更短的反馈周期。
当反馈周期变短，人就更容易围绕结果做判断，而不是长时间停留在假设里。
使用 Vibe Coding 越久，我越觉得人并没有变得不重要。
相反，人变得更重要。
因为 AI 可以生成代码，但它不一定知道什么是适合你的。它可以给出方案，但它不知道你真正想要的产品气质。它可以完成任务，但它不会天然理解你的长期规划。
所以，人需要做这些事情：
- 定义目标。
- 拆解任务。
- 判断取舍。
- 控制范围。
- 验收结果。
- 维护产品方向。
如果没有这些判断，AI 很容易把事情做得很快，但不一定做得正确。
这也是我慢慢学到的一点：Vibe Coding 不是随便让 AI 写代码，而是学会用清晰的目标和上下文引导它，把人的判断和 AI 的执行力结合起来。
这段经历让我发生了几个明显变化。
第一，我更愿意从产品角度看问题。
我不再只问“这个功能怎么写”，而是会先问“这个功能为什么存在”。
第二，我更重视流程。
页面、内容、工具、部署、维护，它们应该连成一条顺畅的链路，而不是一个个孤立的点。
第三，我对学习 AI 相关知识更有动力。
从模型到上下文，从 CLI 工具到网关，从提示词到任务拆解，这些内容不再只是概念，而是会真实影响我每天的开发方式。
第四，我开始更相信个人项目的可能性。
以前一个人做完整产品会觉得很重。现在虽然仍然不轻松，但至少很多原本消耗人的细节可以被 AI 分担。一个人的上限，正在被工具重新拉高。
接触 Vibe Coding 的这八个多月，对我来说像是一次开发方式的迁移。
我从把 AI 当作问答工具，慢慢转向把它当作开发协作者。也从更关注技术实现，逐渐转向关注产品本身、业务流程和最终结果。
这种变化不是一夜之间发生的。
它是在一次次尝试工具、配置模型、修改项目、验证结果的过程中慢慢形成的。
现在的我依然还在学习 AI，也还在摸索更适合自己的工作流。但有一点已经很明确：未来的开发不会再回到过去那种完全依赖手工推进的状态。
AI 会继续进入开发流程，而我需要做的，是学会站在更高的位置使用它。
把注意力从代码细节里适当抽出来，更多地放到产品、体验、流程和价值上。
这可能就是 Vibe Coding 最吸引我的地方。
它不是让我不再关心技术，而是让我终于有更多精力去关心技术背后真正要完成的事情。
