Vibe Coding：从地狱到天堂的一次洞察

Source: Dev.to

项目 1：Slack 应用

我决定构建一个 Slack 应用。

• 基础设施： 两小时完成。
• 应用代码： 那里才是噩梦的开始。

我的做法很简单：向 AI 描述我的需求，复制粘贴生成的代码，部署并交付。但它并没有成功。错误接连出现。我不断把错误粘回给 AI，得到新代码，再次部署——循环往复。经过一周的来回，我陷入了我现在称之为 “氛围编码地狱” 的状态，盲目跟随 AI 而不理解基本原理。

我停下来，深呼吸，然后阅读了 Slack 官方的 SDK 文档。我学到了：

• Slack 提供了哪些功能
• SDK 模块如何工作
• Slack 应用的正确工作流程

有了这些知识，我重新回到 AI，基于新的理解给它明确的架构指示。该应用在三天内完成（包括学习时间以及因误解术语而进行的完整重写）。此后，任何新功能都只需几分钟即可实现。

关键要点： 你不能把理解外包给 AI。软件设计和架构决策仍然来自人类。AI 是强大的助手，但你需要领域知识来有效引导它。

项目 2：LLM 推理平台

我想构建一个完整的推理平台，用于托管 LLM 模型及其微调变体。我的知识水平几乎为零——我是在开始前一晚才了解到“推理”这个词的。

时间线： 三天实现生产就绪。

凭借我的 SRE 背景（系统架构、性能优化、基础设施模式），我能够有效地指导 AI。我理解 AI 提出的选项，并就以下方面做出明智决策：

• 架构模式
• 性能权衡
• 基础设施设计
• 系统集成

AI 完成了约 80 % 的实现工作，但我主导了 100 % 的架构决策。这展示了将领域专长与 AI 辅助相结合的力量——真正的倍增器。

新兴模式

在这些经历之后，我注意到我的时间分配出现了转变：

• 更少手动编码 – 我让 AI 处理样板代码。
• 更多架构与设计 – 我思考系统结构、权衡取舍以及集成。
• 验证与完善 – 我审查 AI 生成的代码，确保质量、性能和安全。

这感觉类似于从手动配置服务器转向编写基础设施即代码（IaC）的过程：技能集合在变化，但价值仍然不变。

经验教训

• 基础优先： 跳过基础会导致失败（Slack 应用）。
• 领域知识重要： 我的 SRE 背景使我在 LLM 平台上取得成功。
• AI 是放大而非取代： 它放大了你已有的知识。
• 更高层次的问题解决： 工程正向架构、集成和验证方向发展，而 AI 负责重复的实现细节。

接下来是什么？

我计划用 Rust 构建一个全栈应用——这是一门我从未学习过的语言。这将检验我发现的原则是否能够跨领域适用。敬请期待。

关注我，获取更多云架构洞见、SRE 战争故事以及在 AI 时代蓬勃发展的实用经验。

上一篇文章: AWS SRE’s First Day with GCP: 7 Surprising Differences