Vibe Coding¶

参考文档¶

• Vibe Coding 范式导论.md
• 开发工具大全.md
• 自然语言编程规范.md
• 上下文管理和代码质量.md
• 代码审核与幻觉识别.md

我的理解¶

Vibe Coding 不是“我不写代码了”，而是把编码从逐行手写变成“描述目标、审查逻辑、迭代反馈”。它降低了生成代码的成本，但没有降低理解业务逻辑的必要性。

飞书文档中最重要的一句话是：永远不要用需求代替逻辑。

需求是“我要一个订单系统”。逻辑是“用户发起订单 -> 后端校验库存 -> 创建订单 -> 扣减库存 -> 调支付 -> 写入状态 -> 返回结果”。如果没有逻辑，只给愿望，AI 会用看似完整的代码掩盖真实的不确定。

工具分类¶

CLI 类¶

例如 Claude Code、Codex、GitHub Copilot CLI。特点是能在终端和项目目录里工作，适合读文件、改代码、跑测试、查日志。

适合任务：修 bug、写测试、重构、整理文档、跑构建。

IDE 插件类¶

例如 GitHub Copilot。特点是补全和局部解释很方便，但对整个项目的理解受插件和上下文限制。

AI IDE 类¶

例如 Cursor。特点是代码库索引、多文件修改、Composer 式生成比较强。适合前端页面和跨文件功能。

Workflow 类¶

例如 n8n。它不一定直接写代码，而是把模型、Webhook、数据库、第三方 API 串成自动化流程。

安装后的第一组练习¶

我不应该一上来就让 AI 写一个完整大系统。更合理的是从小工具开始：

1. 打开一个空项目。
2. git init。
3. 让 AI 生成一个最小 Todo 或喝水记录工具。
4. 自己运行。
5. 截图或描述问题。
6. 每次只让 AI 改 1 到 2 个点。
7. 跑通后 commit。

Vibe Coding 的工作流¶

一句话 MVP
  -> 生成最小版本
  -> 运行和观察
  -> 用实际 vs 预期反馈
  -> 小步修改
  -> 测试
  -> commit
  -> 沉淀成 spec

好的反馈方式¶

实际：点击删除后界面没有变化。
预期：点击删除后弹出确认框，确认后该条记录从列表消失。
约束：只改删除逻辑，不要调整样式和数据结构。

不好的反馈方式¶

还是不对，你再改改。

后者没有给模型新的有效信息。

Git 是后悔药¶

Vibe Coding 最容易的问题是改得太快，所以必须配合 Git：

git checkout -b experiment/vibe-demo
# AI 完成一个阶段后
git status
git diff
git add .
git commit -m "feat: add first todo prototype"

如果方向错了，切回主分支比在坏代码上继续修更健康。

Context 管理¶

长对话会带来上下文噪音。常见表现：

• AI 忘记之前的约束。
• AI 一直坚持错误方案。
• 修改范围越来越大。
• 老需求和新需求混在一起。

处理办法：

• 让 AI 总结当前架构、已完成功能、未完成任务。
• 开新对话，把总结和关键文件重新给它。
• 只提供相关文件，不让它扫描无关内容。
• 把关键约束写入项目 README 或 spec。

Spec 与 Vibe 的关系¶

Spec Coding 偏“先画图纸再施工”，Vibe Coding 偏“边探索边成型”。我更适合这样用：

• 需求不清楚时，用 Vibe 试原型。
• 需求稳定后，写成 spec。
• 真正实现时，按 spec 做小步迭代。

AI 生成代码的检查¶

每次 AI 改完，我至少要看：

• diff 是否只改了相关文件。
• 是否新增未安装依赖。
• 是否有明显安全问题。
• 是否处理错误状态。
• 是否能运行。
• 是否破坏已有功能。

飞书思考题¶

飞书本文没有设置独立编号的思考题，但文档反复要求形成自己的 Vibe Coding 工作流。我的答案是：先用 MVP 探索，再用 Git 和测试保护迭代；AI 负责加速生成，人负责定义逻辑、审查边界和验证结果。

知识卡片¶

MVP¶

MVP 是最小可行产品，不是最简陋产品。它应该能验证核心逻辑，而不是堆满边缘功能。

需求和逻辑¶

需求描述目标，逻辑描述如何到达目标。AI 可以帮我生成代码，但我必须负责逻辑是否成立。

视觉反馈¶

前端问题如果只用文字描述很容易漏信息。截图、DOM、样式、控制台错误、Network 请求一起给，AI 才能更准确定位。

对话总结¶

当对话很长时，总结不是形式主义，而是在重建上下文索引。总结应包括架构、约束、已完成、待完成、风险。