Vibe Coding：和 AI 协作是一件需要边界感的事

我第一次让 AI 写完整的项目代码时，心里是虚的。不是怕它写错——错可以改——而是怕我把那些代码当作”别人的东西”来用，出了问题连原理都解释不了。后来我把这个原则定成了底线：AI 生成的每一行代码，我都要能讲清楚它为什么在那。

“Vibe Coding”这个词后来被人用得有点滥了。有的人把它等同于”让 AI 写所有代码然后跑路”，有的人把它包装成一种神秘主义的工作流。但我的理解更朴素：把那些重复性的、样板式的、不需要创造力的决策交给 AI，而我保留产品判断和架构选择的权力。

这个博客就是在这个思路下搭出来的。

最典型的一个场景是内容发布。我不想每次写文章都要打开编辑器、写 Markdown、提交 GitHub、等构建。对工程背景的人来说这很自然，但我想象了一个画面：如果某天我想让一个非技术背景的朋友也来写一篇文章，这个流程就是劝退的。

于是我搭了一条流水线：Pages CMS 在浏览器里提供一个表单界面，填标题、选分类、上传封面，保存即提交到 GitHub 仓库。然后 GitHub Actions 自动构建、自动部署到 Pages。每一步都不需要人类守在那里点按钮。

AI 参与了这条流水线的哪些部分呢？脚手架和配置代码是它写的，我负责审；部署脚本的结构它搭的，我调整了错误处理的细节；Pages CMS 的页面配置我手写的——因为它决定了内容结构，而结构性的决策我不想外包。

这种分工模式的好处是，我花在”让东西跑起来”上的时间大幅缩减，省下来的精力可以放在真正需要判断的事情上。坏处是我必须保持对每个环节的理解——AI 帮我写了，但我不能假装自己没看过。

把”写文章”变成”填表单 + 点保存”，在技术层面上算不上什么壮举。但在内容运营的层面上，它意味着这个博客的门槛降低到了”会打字就行”。而对我来说，这才是 Vibe Coding 最有价值的地方——不是为了追求效率而追求效率，而是把那些不该由人来做的重复搬走，把时间还给真正重要的事。