放弃死磕每一行代码，尝试用 Vibe Coding 撸个博客后的真实体感
这次实操的核心实验点在于：如果我放弃对实现细节（Implementation）的控制，只通过描述意图（Intent）来驱动，最终产出的东西是否具备可维护性。
在技术选型上，我选择了 Google AI Studio 的 Build 模式。这个工具的交互逻辑很有意思，它采用了左侧对话、右侧实时预览加代码编辑器的分屏设计。最让我觉得高效的是它的标注模式，当你对预览界面某个元素的间距或颜色不满意时，直接点击该元素即可发起修改指令，而不需要在对话框里费劲地描述“右上角那个蓝色按钮请往左移 5 像素”，极大地降低了沟通成本。
为了验证 AI 的逻辑能力，我没有使用任何现成的 Demo 模板，而是直接通过一个简单的 Prompt 启动：
Build a minimal, modern personal blog in React.
Home page: list of posts with title, date, short excerpt.
Post page: full article content, clean typography, no sidebar.
Focus on high readability and a professional developer aesthetic.这个项目规模虽然不大，但涉及到了 React 的路由跳转、布局适配以及内容结构。如果 AI 的逻辑出现偏差，在页面跳转或组件状态管理时会立刻露馅。由于我不需要 CMS 这种重型设施，整个项目维持在纯 React 状态，省去了后端部署的麻烦，这让我可以把所有注意力集中在前端的交互逻辑上。
在实际操作过程中，我把 AI 定位为一个“执行速度极快但缺乏审美和自检能力的协作伙伴”。它能瞬间吐出整个页面的骨架，但它完全意识不到自己是否写了冗余代码，或者是否在某个边缘情况触发了 Bug。因此，我的核心策略是将每一次生成结果视为一个待审核的 PR（Pull Request）。
架构的决定权必须牢牢掌握在开发者手中。如果你在 Prompt 里要求它“使用某个具体的组件库”，那么你其实是在做传统的指令式编程；而真正的 Vibe Coding 应该是告诉它“我需要一个具备专业开发者审美、高可读性的排版”，然后由它给出方案，你再通过审核来决定是否采纳。
这次尝试让我产生了一个深刻的反思：在这种新型工作流下，开发者的核心竞争力正在发生位移。以前我们比拼的是对 API 的熟练度、打字速度以及 Debug 的经验，而现在，核心竞争力变成了提出清晰问题的能力，以及在什么时候停止信任预览界面的“自觉”。
很多时候，预览界面看起来非常完美，但如果你不强迫自己去读一遍源代码，你可能意识不到它为了实现一个简单的布局而写了多少重复的 CSS，或者在路由处理上留下了多少隐患。Vibe Coding 并不是让你放弃思考，而是让你从繁琐的语法实现中抽离出来，把精力花在更高维度的架构审核上。
