Vibe 编码方法真的有效

Source: Dev.to

📍 工程的现状

你可能已经听过很多次：软件工程师将被 AI 系统、代理和工具取代。

我们不会对此过多评论，因为没人对此有明确的看法。但行业中已经出现了一些预测/现象：

1️⃣ 小团队的效率和产出变得非常非常高。
2️⃣ 拥有主动性和明确意图的人比仅仅技术娴熟或聪明的人更受青睐。
3️⃣ 公司将比以往更快地前进。
4️⃣ 软件正在自我构建。

😳 示例

• Claude Code 正在使用 Claude 构建。
• Traycer 正在使用 Traycer AI 构建。

每个组织都有一个共同点，那就是它不是关于：

❓ 你应该使用 AI 吗？
关键在于如何使用 AI。

很多人不知道自己是在做 vibe 编码还是 AI 辅助编码。是的，Vibe 编码和 AI 辅助编码之间有巨大的区别。

📍 常规的 vibe 编码方式

vibe‑coding 工作流通常如下：

• 你使用一个具备代理功能的 IDE（例如 Cursor、Windsurf）或像 Claude Code、Gemini CLI 这样的 CLI 代理。
• 在聊天窗口中输入提示。
• 你的代理读取提示，进行计划，然后开始生成代码。

这种方法适用于非常小的功能或从头开始时，因为：

• 使用全新的上下文/实例的代理在一段时间内有效。
• 随着你不断生成代码，代理会逐渐偏离你最初给出的意图。
• 小而简单的功能可以由大多数 LLM 模型（如 Claude、Grok 等）实现。

📍 实际出问题的时候？

一旦有人开始处理更大的代码库、复杂的功能或端到端的产品，智能体就会遇到困难，因为：

• 它们会偏离人类给出的提示或意图。
• 随着上下文窗口被填满，性能会下降。
• 幻觉（hallucinations）会自信地出现，且没有验证循环。

👉 正因为如此，用户会生成成千上万行代码，却发现根本无法工作。对这些代码库进行重构变得非常繁琐，导致需要进行大量迭代。

这种挣扎产生了表面的生产力提升、无数迭代以及头疼不已的局面。

那么我们应该怎么“vibe”代码呢？

不，上面的图片并不是在告诉你该怎么编码 🤪

编码仍然是一种根本的问题解决方法，结构至关重要，即使在众多代码生成 LLM 出现之后也是如此。遵循第一性原理，过程如下：

1. 编写 PRD（产品/功能需求文档）。
2. 将 PRD 拆分为具体规格。
3. 编写技术文档并进一步拆分为子任务。
4. 将子任务分配给团队成员，让他们真正开始编码。
5. 验证实现结果。

这就是 内循环 解决你的问题的地方：代码生成。

但你有没有注意到缺失的那一环？

没错，正是——外循环。

Source: …

📍 外环

阻碍大型语言模型（LLM）完全胜任编码的缺失环节包括：

1️⃣ 编写产品需求文档（PRD）。
2️⃣ 将 PRD 拆分为规格说明。
3️⃣ 编写技术文档并进一步拆分为子任务。
⚠️ 将子任务分配给团队（使用内环或 LLM）。
4️⃣ 验证实现情况。

这正是一个新领域大放异彩的地方——规格驱动开发（Spec‑Driven Development）。

许多产品正在尝试解决规格驱动开发的问题，它们能够生成 PRD、制定完善计划、验证每个代理的代码步骤，并防止代理偏离用户意图。该领域的产品包括 Traycer、Kiro、Spec‑kit。

我的朋友们对 Traycer 痴迷，因为它的 EPIC 模式等功能非常直观。

Traycer 解决了其他人尚未能解决的问题

• 从普通的简短提示中捕捉人类意图。
• 防止代理偏离意图。
• 消耗更少的 token，避免上下文膨胀。
• 验证每一次改动，让你有信心不发布幻觉代码。

下面是 Traycer AI EPIC 模式的预览

Traycer AI 如今是我的伙伴，因为它更像我的高级工程师，而不仅仅是一个代理。以下是几个亮点功能：

• 它从一个简单的提示开始。
• 然后它围绕问题陈述对你进行访谈…

概览

• 高层次问题 – 产品愿景、目标受众、市场契合度、技术栈、边缘情况以及其他战略考虑。

• 生成的交付物 – PRDs、规格说明、技术流程图、线框图、时序图和用户流程图。

• 任务拆分 – 计划被拆分为更小的任务，可交给任何 AI 代理（例如 Claude、Grok、Cursor IDE 等）。

• 验证 – 对每一次更改进行验证，以防止代理偏离或走错方向。

📍 最近我们发布的产品包括：

• 构建自己的 Redis。
• 构建我自己的 WhatsApp，支持跨消息的语义搜索。
• 以及我们正在构建的更多项目，热爱 EPIC 模式 ❤️