---
title: "我的一点点 Vibe 的编程经验分享——从执行者到决策者"
---

![alt text](/images/practice-01-vibe-coding-methodology.png)

这不是一篇"纯小白 Vibecoding 的体验分享"。我想分享的是另一种实践经验——当你自己本身就具备了足够的后端研发能力时，如何基于 AI 这个强大工具来给自己加效率杠杆，大幅提升自己的工作效率，让 AI 成为一个极其高效的"执行层"，而决策权依然在你手里，将自己从重复性的编码工作中解放出来，专注于架构设计和决策把控，让自己从执行层面的琐事中解脱出来，成为真正的架构师和决策者。同时也让自己在日常的琐碎工作里能过的更舒服一些，有更多的精力去写作去思考，哪怕简单休息下也好。  

## 一、对 Vibe Coding 的粗浅理解

由于 Vibe Coding 概念的火爆，导致现在我们提到这个词的时候，首先想到的是：一个有着强烈探索欲但零编程基础的同学使用自然语言描述自己的想法, 通过各种 CodingIDE 来和模型交互，让大模型帮你噼里啪啦生成一堆东西，最后成功地创造出一个完整的产品出来，很有成就感，但其实对大模型干了什么一无所知，对系统的了解完全是黑盒, 虽然有个完整的执行过程, 但对内部机制还是缺少深入的了解，实际运行中各种 bug 横飞，而大模型本身又有自我认知纠错的盲点，最后很容易陷入原地打转心态爆炸的情况，遇到创造的天花板。

对于一个像我这样的已经具备足够研发能力的人来说，我和大模型也同样进行协作，但协作方式有些不同，具体来说就是慢一点，大模型已经生成代码的速度够飚了，没必要更快了，我要做的是让大模型慢一点，稳定优先，小步慢跑，步步为营，从而构造出一个可控的开发节奏与更复杂更稳定的系统架构。

我已经开发过无数个 CRUD 的需求，所以我对一个完整的开发流程非常清楚，我知道从需求分析、架构设计、代码实现到测试部署的每个环节的细节, 以及各个模块之间的依赖关系和数据流转方式，这让我能够更好地指导大模型生成符合预期的代码。

所以在面对新需求时，我会先基于自身的开发经验快速梳理出核心模块和关键逻辑, 去设计出整个系统的蓝图, 当然在这个过程中也会和大模型不停的进行交互, 让他帮我排查下实现思路中是否还有问题, 然后拆分成一个个边界清晰功能明确的组件, 并且将这些组件之间的数据流转关系也编排的很清楚，最终让大模型在这个框架内进行细节填充和实现。当在开发的时候，出了 bug , 也是我来定位，主要是大模型有时候会很傻逼, 在一个地方反复打转, 而且偷工减料, 这还是聪明一点的模型, 如果你遇到傻逼一点的, 大模型删库跑路对你来说不是梦.  所以, 我就会自己先去看下 bug 或者报错原因, 有个初步的判断, 然后引导模型去分析与定位问题。所以本质上大模型像是我指导的一个刚入职的新人, 很能干, 但时不时地会犯傻, 所以我要把方向盘一直窝在我自己手里。


在过去的 vibeCoding 中, 固然积攒了有很多小技巧,比如你要学会"骂它", 你要学会配置一些代码规范的rule规则, 让大模型遵守, 但这些吧没有也无所谓, 其中我觉得能够构成方法论的 vibeCoding 思路有两个, 不多，只有两个。 

第一个是**方案先行，实现为后**。我发现虽然不能从 PRD 直达技术方案，但在每一个功能实现前，先让大模型输出一个技术实现方案，由我进行 review 和微调，然后再基于这个方案让它写代码，效果比直接一句话让它生成代码要好得多，也更可控，bug 也更少。为什么会这样？因为大模型生成的实现方案，大模型自己更容易理解。你让它先把思路捋清楚写下来，它后面写代码的时候就有了一个明确的锚点，不容易跑偏。而如果你直接让它一步到位写代码，它其实是在"边想边写"，中间很容易出现逻辑断层或者前后不一致的问题。这个技巧在其他场景也适用，比如生成图片的时候，先让大模型输出图片的视觉描述，再基于这个描述去生成图片，比直接让它一步到位生成图片效果要可控得多。本质上这是一种"思维链"的应用——把一个复杂任务拆成"先想清楚再动手"两步，每一步都更可控，最终结果也更稳定。

具体到单模块怎么落地：先描述业务实体让 AI 出一版表结构我审查调整，然后让它一次性生成 DAO、Service、Controller 三层代码（这是 AI 干体力活的主场，传统一天的工作量它两分钟搞定而且边界校验异常处理日志埋点都很完整），接着生成接口文档再让它生成前端页面，最后我跑一遍增删改查做端到端验证，遇到问题我先定位到具体层再告诉它改。带业务规则的场景比如权限控制，我就明确告诉 AI 业务规则，不能指望它自己猜。


基于这样的开发模式，其实也无形中给 Vibe Coding 搭建了一个很重要的带有记忆的运行环境，通过文档来持久化这些关键对话记录、技术决策、踩过的坑，这样就形成了一个包含全部输入的上下文环境：需求文档、代码、数据库表结构、接口定义、历史技术方案等等。之前做过的技术方案也存好，遇到类似场景直接复用，不用从头再来一遍。

这个环境就是一个 VibeCoding 开发中的知识库，让你在任何时候都能快速回到之前的状态，继续之前的开发工作。怎么让这个同步机制自动运转起来？其实我的文档整理思路和 开发出laper.ai的大佬很类似, 但我觉得他写的更好, 我就把他的思路搬过来了: 
```
分形文档结构：
根目录放一个主 md 文件，强调任何功能、架构、写法更新必须在工作结束后同步更新相关目录的子文档；
每个文件夹里都有一个极简的架构说明（三行以内），下面列出每个文件的名字、地位、功能，文件开头声明"一旦我所属的文件夹有所变化请更新我"；
每个代码文件的开头写三行极简注释——input（依赖外部的什么）、output（对外提供什么）、pos（在系统局部的地位是什么），并写明"一旦我被更新务必更新我的开头注释以及所属文件夹的 md"。
你会发现这是一个自指的分形结构，局部影响整体、整体影响局部，像《哥德尔、埃舍尔、巴赫》里说的复调与自指。一旦这样做，AI 在修改任何文件时都会自动触发一连串的文档同步，上下文永远是活的，化学反应自蔓延开来。
```

第二个是**小步慢走,步步为营**。具体做法是：在项目开发过程中，将大的功能模块拆分成若干个可独立完成的小任务，每个小任务都包含明确的目标、技术方案和实现步骤。完成一个小任务后，立即同步更新相关的文档和代码注释，确保整个项目的上下文始终保持最新状态。这样可以避免在开发过程中出现信息滞后或理解偏差的问题，同时也能让后续的维护和迭代变得更加容易。

同时，每一步最后都能去验证下，在 vibeCoding 中，单测或者细粒度的功能性测试变得愈发重要，很容易你就能让大模型给你搭建测试的工具或者脚本，甚至测试 demo 页面，这些都不会费什么力气，但这能给你大大节省之后 bug 堆积集中爆发时，导致大模型原地打转的问题。

## 二、我做了个什么项目、怎么做的

### 项目背景与需求

做的是一个**流媒体文件服务管理系统**，说白了就是让运营团队能够对摄像头的图片视频文件的管理，从摄像头设备的拉流、转码、存储、分发，到视频文件的播放、下载、删除、备份以及媒资文件的过期归档。这不是一个简单的文件管理工具，而是一个一站式的媒体资源管理平台。

在这个系统中涉及到的核心功能模块有两部分: 媒资文件管理模块和文件访问权限管理模块。

**核心功能模块：**
- **权限体系**：超管、空间管理员、普通成员三档角色权限隔离，API Key 管理与认证，成员增删权限控制，开放接口供第三方集成
- **媒体资源管理**：多格式支持（视频、图片），自动转码到多种规格，元信息提取（时长、分辨率、码率等），多种视图展示（列表、网格、时间线），过期文件自动清理策略
- **体验细节**：批量操作（批量上传、批量删除、批量转码），实时播放与历史播放记录，视频备份下载，搜索与过滤

### 开发策略：自上而下设计, 功能拆分; 自底向上实现, 逐模块推进

因为当前模型还做不到一次性无 bug 交付复杂系统，上下文过长容易导致模型迷路陷入无效调试。所以采用**自上而下逐层细化功能, 自底向上逐模块推进实现**的策略：

1. **全局蓝图阶段**：脑中先构思整个系统的架构，包括核心模块划分、数据流转、关键依赖关系，然后输出到一个完整的方案文档里
2. **基础模块阶段**：从最底层的数据模型和 API 开始，先完成基础模块的搭建和测试，确保地基稳固
3. **功能模块阶段**：逐步实现其他功能模块，每个模块都基于已有的基础进行扩展
4. **集成阶段**：最后串联各个模块间的协作逻辑，进行端到端的集成测试

本质上和传统开发节奏差不多，只是每个环节都有 AI 加持。

### 人机协作的角色分工

在这次项目中，我并没有完全依赖 Vibe Coding，而是建立了清晰的分工：

| 环节 | 我的职责 | AI 的职责 |
|------|---------|---------|
| **方案设计** | 架构决策、权限边界设计、技术选型 | 方案评审、可行性分析、细节补充 |
| **代码实现** | 方案审查、代码审查、关键排错 | 体力活（增删改查、接口文档、界面生成、字段同步） |
| **问题定位** | 根因分析、问题诊断 | 基于指导进行修复 |
| **测试验证** | 测试设计、边界场景补充 | 测试脚本生成、demo 页面搭建 |

**关键原则：**
- 我不必逐行读懂每一行的代码，但必须弄清楚每个模块的核心职责与变更影响面
- 自底向上比"PRD 一把梭"更可控，能及时发现问题
- AI 擅长体力活，人擅长判断与闭环

### 项目成果与效率提升

整个项目从启动到结束，真正需要手写的部分大约占 **1%**，主要包括：

- 文案措辞微调（权限拒绝提示文案、错误提示、权限申请SOP知道）
- 无用 import 清理（AI 有时会导入不必要的库）,重复冗余函数定义与代码的清理, 无用注释的清理
- AI 幻觉导致的零星编译错误（虚构的 API、错误的库版本）
- 逻辑上的微调和边界情况处理（AI 遗漏的特殊场景）

这意味着，相比传统开发方式，我节省了约 **99% 的编码时间**，可以将精力集中在架构设计、决策把控和问题定位上。

## 三、踩过的坑

在与 AI 的协作过程中，我踩过不少坑。这些坑不是 AI 能力不足的表现，而是我们对 AI 特性理解不足导致的。总结下来，主要有以下几类：

### 常见问题与应对

**1. API 幻觉（Hallucination）**
- **现象**：AI 会虚构根本不存在的 API、库函数或参数，写出看起来合理但实际无法运行的代码
- **例子**：某个库的文档里根本没有的方法名，或者错误的参数签名
- **应对**：我得手动核实每个关键 API 的真实存在性，必要时查阅官方文档。建议在 prompt 中明确指出"使用官方文档中存在的 API"

**2. 错误假设上的反复打补丁**
- **现象**：AI 会在错误的理解基础上反复修改，越改越乱但始终没有跳出错误框架
- **例子**：假设某个字段是可选的，但实际上是必需的。AI 基于这个错误假设生成代码，后来发现 bug 了，就在这个错误假设上反复打补丁，改了 A 又改 B，改了 B 又改 C
- **应对**：我得亲自定位根因，然后明确告诉它"你之前的假设是错的，真正的问题在这里"

**3. 过度设计与不必要的抽象**
- **现象**：AI 生成的代码会包含过多的设计模式、工厂函数、装饰器等，导致代码复杂度远超需求
- **应对**：在代码审查时直接删掉这些不必要的抽象，保持代码的简洁性

**4. 代码卫生问题**
- **现象**：无用的 import、重复冗余的函数定义、无用的注释、死代码
- **应对**：需要手动清理，建议在 prompt 中强调"代码简洁、无冗余、无注释"

**5. 边界场景遗漏**
- **现象**：AI 实现的是"happy path"，对于空值、异常输入、并发场景等边界情况处理不周
- **应对**：在测试阶段发现后补充，或者在 prompt 中提前列举需要处理的边界场景

### 最大的坑：无效调试循环, 模型自我认知盲点

Bug的调试与解决是在任何一种coding方式中都避免不了的问题, 虽然vibecoding实践应用, 大家也逐渐对 vibecoding 产生了`去魅`, 不再将 vibecoding 变成无所不能的神器, 反而深刻意识到vibecoding的高速输出代码的同时也在以更大的概率更高的速度将 bug 引入到了你的系统时, 对于从 0 到 1 的项目来说, 你可能刚开始感觉 vibecoding 很爽, 大量的功能设计快速的从你的文档转换成代码实现.  但当你的项目愈来愈大的时候, 你喂给大模型的上下文也就越来越长, 同时系统之间/模块之间/组件之间的依赖也越来越复杂, 系统中之前隐藏的一些问题也开始累积并爆发了出来, 就会出现有些 bug AI 并不是那么容易得解决, 如果你只是把报错信息喂给 AI, 而不是自己亲自去分析定位, AI 可能会陷入**无效调试循环**中, 出现`按了葫芦起了瓢`的情况, 如果你强行让代码去修复, 而你只是扮演一个验证者的角色, 那么你就会发现, 模型在反复的做无用功, 而你的代码也越改越乱。

**问题的表现：**

当项目规模增大、依赖关系复杂化后，如果你只是一味让模型自己去解决 debug，会陷入一个恶性循环：

- **模型没有准确定位到报错的根本原因** — 因为链路太长、上下文太复杂，或者你给的报错信息太抽象表面
- **模型缺乏持久记忆** — 每一轮对话都是独立的，无法保持对整个问题的完整认知
- **模型看似在不断打补丁，但始终没有能力跳出错误的框架** — 基于错误的假设反复修改
- **你陷入无限的测试-修改循环** — 一遍遍地配合模型做测试，但每次测试完后问题仍在
- **代码越改越乱，甚至引入新的 bug** — 每个修改都可能引发新的问题，形成连锁反应

这就是"按了葫芦起了瓢"的情况：

```
第一次修改：改了 A（基于错误假设）
第二次修改：改了 B（因为 A 的修改引发了新问题）
第三次修改：改了 C（因为 B 的修改又引发了新问题）
...
第 N 次修改：代码越来越乱，但根本问题始终没有解决
```

如果你只是扮演"验证者"的角色，让模型自己去修复，那么你会发现模型在反复做无用功，而你的代码也越改越乱。

**为什么会这样？**

这涉及到 AI 的工作原理和局限性：

1. **缺乏元认知能力** — AI 是基于自回归生成文本的，它缺乏"思考自己的思考"的能力。当它基于某个假设生成了代码，这个假设就成了它后续推理的基础。即使这个假设是错的，它也很难自己意识到并质疑这个假设。

2. **没有持久记忆** — 每一轮对话都是独立的，模型无法跨越多轮对话保持对问题的完整认知。当你说"这里还是有 bug"时，模型可能已经"遗忘"了之前的上下文，只能基于当前的报错信息去猜测。

3. **错误假设的堆砌** — 每一轮修改都是基于上一轮的输出。如果第一步的假设就错了，后续的所有修改都会在这个错误的基础上堆砌，形成一个越来越复杂的错误框架。模型没有能力"推翻重来"，只能在错误的基础上继续修修补补。

**唯一的解决办法：你亲自下场 debug**

这很关键——不是让 AI 去修复 bug，而是你先找到真正的根因。具体步骤：

1. **识别危险信号** — 如果发现模型在同一个问题上修改超过 2-3 次还没解决，立即停止。这表明模型可能陷入了错误的框架。

2. **自己定位根因** — 这是最关键的一步。通过日志、断点、代码追踪等方式找到问题的真正原因。不要只看表面的报错信息，要理解：
   - 问题发生在哪个模块？
   - 为什么会发生？
   - 根本原因是什么？

3. **明确告诉模型根因** — 不要说"这里有 bug"或"请修复这个错误"，而是明确指出根本原因：

> "你之前的假设是错的。真正的问题在这里：[具体描述根本原因，包括为什么会这样]。基于这个理解，请重新实现这部分代码。"

4. **让模型基于正确的理解重新生成** — 一旦模型理解了正确的根因，它就能跳出错误的框架，生成正确的代码。

**这也是为什么方向盘必须在人手里：**

Vibe Coding 的高效来自于 AI 的高速输出，但这也意味着 bug 的高速输入。当系统变得复杂后，你不能再是一个被动的"验证者"，而必须是一个主动的"决策者"和"问题定位者"。

你需要：
- **在架构层面把控方向** — 确保系统设计合理，模块边界清晰
- **在问题定位时亲自下场** — 这是最关键的。当出现 bug 时，你必须自己分析、定位、理解根因
- **在代码审查时发现不合理的设计** — 及时发现模型的过度设计或错误假设
- **在测试时补充边界场景** — 主动测试，而不是被动等待 bug 出现

只有这样，你才能真正发挥 AI 的优势（高速输出代码），同时规避它的劣势（无法自我纠错、缺乏元认知）。