Vibe Coding经验总结

起因

最近在开发工作中，我大量使用了 Vibe Coding，不断与 AI IDE 进行需求-反馈-修正的循环交互。在这个过程中，我一直在思考如何能够将 Vibe Coding 的效果发挥到最大。我认为最关键的是需要整理出一套方法论，解决以下两个核心问题：

• 如何在一轮对话中即可完成生成？
• 如何保证后续的需求也能一轮搞定？

基于我的实践经验，我认为要实现这个目标，需要关注三个核心要素：

• 清晰的需求
• 约束(Rules)
• Workflow

此外，我们必须明确人和 AI 在工作流中的职责分工。如果让人去处理 AI 更适合做的工作，或者让 AI 去处理人更适合做的工作，都会导致最终结果与预期出现偏差。

经过实践，我认为人和 AI 的职责分工应该按以下方式：

• 人：负责业务知识、领域知识、经验、架构
• AI：负责 API、常见的解决方案、编码

描述需求

需求描述的三要素

需求是一切的源头，AI 生成的效果好坏与你给它描述的需求质量息息相关。在与 AI 对话的过程中，我们必须保证需求满足以下几点：

• 结构化
• 无歧义
• 精确性

比如，明确指定让 AI 使用某种技术，或者通过量化的数值和名词来进行约束。举例如下：
“必须使用 markArea 而非 graphic”
“我希望当这个 layer 是第一个时，它的上界定位依据变成 y: 0；当这个 layer 是最后一个时，它的下界变成 y: ‘100%’”

反问模式

这是我实际体验下来最关键的技巧，没有之一。

我们输入给 AI 的初始需求可能比较简单或者笼统，很难精准完善地描述最终需求，我把这种需求叫做种子需求。将种子需求输入给 AI 后，AI 会基于种子需求进行扩写。

反问模式的具体操作其实很简单，就是在你描述完种子需求后，一定要让 AI 向你提出一些问题。比如：”你可以询问我一些问题以明确需求”。

经过我近期的测试，发现 Claude 在需求扩写和反问模式上表现最强。另外，这一步生成的需求，一定要让 AI 将其保存为 Markdown 文件，存放到项目下。

名词定义

这和我们平时软件开发中用到的设计模式类似。比如我们一提到工厂模式，对方就能够获取到很多信息。通过定义一些名词和概念，在后续与 AI 的交流中，我们就可以通过这些名词概念去传递大量的信息。

比如下面这个是最近我们要开发的表格组件，我对页面上不同的区域进行了名词定义，方便后续描述具体的需求和交互：

过程文档化

在开发过程中，最初的需求经过层层传递后，可能最终已经变得面目全非。就像下面这个我们平时调侃软件开发时经常用到的图：

AI Coding 的过程中也常常出现这种”需求漂移”问题，多次沟通导致需求变形（上下文长度限制、压缩等原因导致）。

解决这类问题比较好的方法就是将整个开发过程中涉及的文档都保存下来，开发过程就是：”生成文档-基于文档生成代码-基于代码生成文档”不断循环（这有点元编程的意思）。

所有的代码都基于文档进行生成，类似下面这种：

基于docs目录下我提供的项目需求文档(requirements.md)和程序架构文档(architecture.md)的内容，请帮我初始化项目文件结构。
请先帮我规划下，别直接创建和修改文件。

这样能保证我们对代码库有一个宏观的元模型，能清晰地理解所有需求、变更和方案。每次进行需求变更或者做了一些大的修改后，一定要记得执行下面这句 Prompt 来更新文档：

请基于当前的方案/代码实现，更新项目相关的文档。

图片辅助说明

在开发过程中，我们经常会遇到一些复杂的页面效果，或者一些布局类的内容难以描述。正所谓一图胜千言，这时我们可以将图片发给 AI。但这里有一个需要注意的点：不要直接让 AI 基于你的图片去开始执行后续操作，一定要先让 AI 讲出它对图片的理解，确认无误后再进行下一步操作，避免错误的链式传递。

比如，我将下面这个图片发给了 Cursor，让它进行理解：

从它给出的回答可以看到，其实它并没有识别到带颜色的背景这部分内容，并且对于里面分段数据之间的空隙也没有识别到：

精准定位页面元素-Stagewise

有时候我们要针对页面上的局部内容进行修改，这时如果直接让 AI 进行修改，很可能会导致它无法精准定位你所要改动的页面元素。这种情况可以安装Stagewise这个工具，通过可视化交互的方式来精准选择页面上的元素，然后输入修改的内容，Cursor 会自动生成 Prompt。

当然，这个功能主要对非开发人员的帮助会大一点。对开发人员而言，定位页面元素基本上不存在什么问题，通过 Chrome 的控制台去定位也很方便。

另外，Stagewise 有一个特别有意思的地方，就是它的安装操作支持 Agent 模式。不用你一行命令一行命令地去执行，按照操作只需要你选择安装，它会自动生成一段 Prompt，然后你通过 Cursor 的 Agent 模式就可以把所有的安装操作自动搞定。我觉得这种模式非常好，可能会成为后续所有插件工具安装的主流方式。

将 Cursor 日志整理为技术文档

作为技术人员，我们经常有写技术博客的习惯。我们也可以将和 Cursor 的对话记录保存下来（利用 Cursor 的导出功能），通过 Prompt 将其自动整理成技术文档或者技术博客。

基于上述你分析的内容，结合我提供的日志文档的内容，帮我写个关于<主题>的Markdown格式的技术文档，注意：
- 重点关注原理、思考、方法论方面的内容（没有的不要硬加），必要时可以加上图进行辅助说明
- 附上必要的关键代码，针对每个关键代码，用简洁的文本描述其流程和逻辑，辅助理解代码，并给关键的代码加上必要的注释；如果没必要，也不要硬加
- 用Mermaid语法绘制必要的图，比如架构图、流程图、时序图等
- 尽量不要依赖外部资源，比如图片等
- 可以添加参考资料的超链接
- 内容需紧密结合项目实际代码和方案进行，不要随意自由发挥

## 主题
如何实现AIGC组件的layer封装

Rules

AI 基建的重点，其核心就是：Rules。
可以按照如下流程构建你的 Rules：

• 业务抽象和分类
• 针对具体业务分类的系统架构设计
• 编写高质量的 Rules
• 编写高质量的示例(AI + Template 模式)

为什么要沉淀 AI 经验？

我们之前其实写过大量的文档，每次项目开发的过程中以及项目结束后的复盘都会沉淀出很多技术文档，但是这些文档我们更新到公司的文档系统上以后，基本上后续就再也没有将其使用起来了。属于写完就扔的状态。这也导致虽然我们制定了很多的规范，但是这些规范都没有被真正地执行起来。

总的来说存在如下三个问题：

• 技术文档 AI 基建化，解决文档写了没用的问题
• 经验和积累仅保留在个人的大脑中，无法在团队中流转
• 项目中的经验做完就忘，没有沉淀，下次/换个人继续犯同样的问题

而目前基于 AI 的编码方式中的 Rules，让我们看到了解决上述文档问题的希望。

Rules VS. 文档

在前面描述需求的环节里面，其实也涉及了很多的文档。那这部分文档和这里的 Rules 的区别是什么呢？我觉得这需要先进行一个明确的定义。个人理解如下：

Rules：

• 跨项目通用的规范
• 当前项目下可复用的规范

文档：

• 业务相关的内容，当前项目特有

基础框架的必要性

前几天运营同事提出了一个环形图的需求，当时我们认为这只是一个给运营使用的一次性功能，因此没有采用任何框架，直接让 Cursor 从零开始在 HTML 文件中编写代码。结果写出的代码非常混乱，完全是 AI 自由发挥的产物。

然而，项目完成后我们发现这个需求可能在其他场景中也会用到，需要将其进行封装和代码优化，并改写为 AIGC 组件。结果在执行代码优化和组件封装的过程中，耗费了大量时间。

具体的问题主要体现在以下几个方面：

• 没有使用 TypeScript 进行类型约束，数据结构设计不符合 AIGC 的标准格式，代码采用流水账式的 JavaScript 编写而非组件化结构。
• 项目缺乏 ESLint、Sonar 和 Prettier 等代码规范工具，导致后续提交代码时，仅修改代码规范相关的内容就花费了超过两个小时。
• 重构前没有预先设置好.cursor 的开发约束。

基于这次的经验教训，我总结出后续开发组件时必须遵循的几个要点：

• 必须以组件形式进行开发，能够打包为 npm/CDN 形式供其他项目使用。
• 开发过程中必须严格按照组件化框架进行编码，否则后期修改的工作量会非常庞大。

通过这次经历，我深刻认识到 AI Coding 中基础框架的重要性。如果每次开发都需要重新处理基础配置，会产生大量重复劳动。因此，开发组件时不应该从零开始，而应该预先建立完善的开发环境和约束条件，让 AI 专注于理解组件需求和编写核心代码，而不是被基础配置工作分散注意力。

技术栈需指明版本

技术需要指明版本，否则可能会用到很老的版本(比如 TS4、Vite2、ESLint7 等等，因为 LLM 的训练数据里面的老版本数据比较多)。

近期我就遇到了 2 次：

• 知识库，用到了低版本的 LangChain
• Reader 项目，用到了 49 版本的 SDK，当时默认支持的是 53 版本，导致后续重构才能测试

Rules 的生成

Rules 是需要根据项目的实际情况去不断沉淀的，最终形成一份团队通用的基础 Rules。比如我这边就将 Rules 分成了 4 种类型，然后从历史项目里面去分析整理出来，形成一个基础的团队 Rules：

• 通用规则：比如代码风格，编码规范，不同框架技术的编码约束等等。
• 业务规则：和业务相关的一些约束，比如我们是做数据可视化开发的，那这块就和数据可视化的业务特性相关。
• Git 规则：比如 commit message 的规范，Issue 的规范，PR 的规范等等。
• 工具规则：比如 SVG 生成、draw.io 生成等。

现有项目的 Rules 生成

如果是针对一些老项目的改造，则可以通过如下几个步骤去构建该项目的 Rules：

• 通过 Cursor 的/generate rules命令，基于当前项目已有的信息生成初始的 Rules。
• 通过 Prompt 强制使其分析项目信息再生成一些更契合项目的 Rules 作为补充。
• 将上面团队沉淀的基础 Rules 合并到该项目中。

这样就能够生成比较完善的项目约束。
这里给一个上面第二步(基于项目信息生成 Rules)的 Prompt 示例：

请基于本项目的技术方案文档和具体的代码实现，反向抽象出各个需求点的解决方案和代码，便于构建通用技术方案库，并最终落地为Cursor的.cursorrules文件，给后续的需求开发使用。
包括：
- 数据处理
- 布局算法(碰撞处理)
- 坐标转换
- CustomSeries
- 文本处理
- 交互处理
- 性能优化
- 其他你能想到的任何内容

注意：
- 最终的产物是Cursor的.cursorrules文件
- 如果内容过长，请将其进行合理的分割，分散到多个文件中
- 先给出分割的规划方案，待我确认后，再执行具体的分割和写入文件的操作

一些可能会用到的信息：
- 目标场景定位
这个通用技术方案库主要面向什么开发场景？
专门针对ECharts扩展组件开发

- 输出内容深度
希望.cursorrules文件包含什么层次的内容？
完整的可复制粘贴的代码块

- 技术栈范围
需要支持哪些技术栈？
仅TypeScript + ECharts

- 希望这些方案如何被使用？
作为代码生成的模板库

- 特定需求
重点关注：布局、算法、交互、通信

- 抽象粒度问题
你希望抽取的是：
两者都要
A) 完整的功能模块（如"轴指针联动高亮"的完整实现）
B) 更细粒度的工具函数（如"计算网格高度"的单个函数）

- .cursorrules文件结构
你希望最终的.cursorrules文件是：
按技术分类组织（布局类、交互类、算法类等）

- 代码模板的参数化程度
对于可复制粘贴的代码块，你希望：
两者结合，既有模板又有示例
A) 高度参数化，需要用户填入具体参数
B) 提供多个具体的使用示例

- 依赖和上下文
这些代码模板需要：
A) 包含完整的类型定义
B) 说明所需的依赖和工具函数
C) 提供集成指南

- 特定场景覆盖
专注于从markerLine中抽取的技术点

请先规划下，你可以询问我一些问题以明确需求。

Workflow

其实 AI Coding 的 Workflow 和常规的软件开发流程基本一样，无非就是每个环节里面之前是由人去处理这些事情，但是现在改成用 AI 去处理这个环节的内容。

这里有个比较有意思的项目，可以参考一下：BMAD-METHOD：敏捷 AI 驱动开发

Workflow 可以帮助你从一个起点开始，顺畅地走向终点。

⚠️ 注意：不要让 AI 帮你定整体流程，AI 的 Thinking 应该用在针对某个具体小环节的流程。

目前我个人的一个工作流基本是这样的：
Issue -> 需求分析与完善 -> 架构设计 -> 单元测试 -> 编码 -> 迭代 -> 测试 -> 发布

这里面的每个环节都可以由 AI 去完成，我们只需要制定每个环节的 Prompt 以及对应的一些模板就可以了。

以提交 Issue 为例，现在并不是由我们去编写具体的 Issue 信息，而是结合 GitHub 的 Issue 模板，我们通过简单的提示词，再加上让 AI 给我们提问，反向确认 Issue 内容，就可以生成质量比较好的 Issue 了。

架构设计和执行流程

LLM 的上下文长度问题，会导致项目一旦复杂度和规模上升，模型在理解上就会出问题，进而引发程序设计的不合理。因此整体的架构设计方案必须要人参与进来，可以由 AI 先生成架构草稿，然后我们进行补充和完善，最终确认以后再执行具体的文件创建和代码生成操作。另外如果说操作的内容比较多，我们一定要对操作环节进行划分。

这里 Claude Code 是做得比较好的，因为它默认就会将任务进行拆分，先生成一个 Todo List。而 Cursor 需要你明确地告诉它先生成 Todo List。

给不同的需求制定不同的细节执行标准

不同类型的需求，Workflow 的细节上有一些差异，这是需要我们针对性去制定一些规则的。

比如我们最近的需求，就包括如下不同的类型：

• 现有组件封装为 AIGC 组件
• ECharts/StandardChart 组件封装为 AIGC 组件
• StandardChart 答疑
• 业务组件开发
• 自驱类需求

在需求分析、方案设计和编码等等环节，这些不同的任务都存在一些差异。因此我们针对不同任务制定的 Workflow 的细节也会存在差异。只有针对不同类型的需求进行抽象设计以后，才能在不同的任务上都达到比较好的表现。
另外，针对一些简单任务，制定一个合适的 Workflow，再结合 AI 工具，可以实现自动/半自动化的效果。比如给业务方进行 StandardChart 答疑，目前有超过 50%的这类需求，我都是通过 AI 工具完成的：

graph LR
    A[业务方发送的问题和截图] --> B[Cursor还原Demo效果]
    B --> C[Cursor生成解决方案]

其他的一些想法

时间大量消耗在布局算法问题上

布局算法类的最难，一旦涉及非常规的布局(往往是业务数据注入后出现的边界情况)，AI 就会搞不定。
这种情况有两个解决方案：

• 找个现成的让它参考
  比如上周末用来测试 AI 编码写的小说阅读器，里面的分页算法就无法直接 AI 搞定，然后我找了一个现成的博客让其参考。

• 自己想清楚算法，清晰的描述给 AI
  像上面这个分页，实际上我给了参考博客，写出来的还是有问题的，最终还是得自己理解算法 + React Native 的 API，然后再去辅导 AI 写，或者直接自己写。

原理很重要，其实这个算法本身想通了很简单的，但是如果纯靠 AI，不去想原理，很可能一直写不到点上(非开发人员基于 AI 工具做项目，很容易遇到类似的问题，在某个问题上绕来绕去，就是解决不了)。

技术栈友好度

技术栈上尽量选择最流行的技术，因为流行的技术具备 2 个关键优势：

• LLM 的训练数据中有大量的相关信息，LLM 对其理解非常深入
• 生态完善，不用自己造轮子，Bug 也相对较少

比如：

• 前端框架：React
• 全栈框架：Next.js
• 样式：TailWind CSS
• 组件模式：shadcn-ui/ui (基于 React + Tailwind CSS + Radix UI，将组件源代码直接复制到你的项目中)
• 简单的可视化分析：ReCharts
• 个性化的简单可视化：SVG
• ……

有了 AI 还需不需要技术基础和思考？

答案肯定是需要的，如果说你不具备基本的技术基础，在 AI 编码中很容易出现如下问题：

• 无法准确描述技术性问题和方案
  因为有一些内容，如果我们具备常规的技术基础或者当前领域的知识，就可以通过一些专业名词，精准地给 AI 描述需求，比如：markArea、滑动窗口分页、虚拟滚动等等。如果不具备这些知识，很可能你压根就不知道该怎么样去描述这部分需求。

• 无法保证程序质量
  网上经常看到一些视频说什么不会软件开发的人员，或者说零基础的人员通过 AI 编码工具几个小时就构建了一个产品。但其实仔细去分析和观察会发现，他们所构造的这些所谓产品其实都只是停留在 Demo 阶段，并不是一个真正足以上线应用的产品，或者说是一些复杂度很低的小功能。如果你真的要开发一个产品的话，那要考虑的因素不光是实现基础功能，还要考虑性能、稳定性、安全性等等各方面的指标。而这些指标往往是整合了整个项目的程序和功能去综合考量的。目前 AI 在这方面做得还不是很好，仍然需要人去介入。如果你不具备程序设计和软件架构的能力，则很难考虑到这些方面。

• 无法完成高复杂度的系统
  同样地，这个和上面的内容其实是有点相似的，当我们的项目不断地迭代，功能会一直增加，随着功能和用户量的增长，系统的复杂度也会日益提升，这种情况下，对于整体的系统架构和各方面需要考虑的指标就会要求非常高。所以在未来个人感觉开发人员在软件开发里面所承担的角色应该定位为系统架构师，而不是常规的编码人员，因为编码方面的内容 AI 工具可以帮你完成得特别好，只要你将模块拆分得足够细，需求描述得足够精准，AI 写出来的代码很可能比你写的代码更好，所以开发人员应该更专注于整体系统的架构。如果你不具备相关的经验和知识的话，这方面的内容就无从下手了。

综上所述，虽然现在我们有了各种 AI 编码工具，但是基本的技术基础和思考能力仍然是非常关键的，这决定了我们在软件开发领域能够走多远。

另外，在当前的 AI 编码浪潮下，我感觉对于不同的人员其影响是不一样的：

• 如果你是一个本身就具备丰富开发经验和系统架构经验的人员的话，那么这些 AI 工具对你来说就是如虎添翼。它们能够让你的效率达到 10 倍的提升，这是我自己近期开发的一个直观感受。

• 但如果你是一个刚刚毕业的应届生，那么你在使用这些 AI 工具的时候一定要注意具备独立思考的能力，并且对于 AI 生成的内容一定要去仔细地分析，弄清其原理。否则 AI 生成这种快速的正反馈会让你沉迷其中(很多功能和 AI 对话就能搞定，似乎开发是很容易的一件事情)，但如果你忽略了它背后的实现原理，就会导致这些技术你都是浅尝辄止，一旦遇到问题，很可能你就无法解决。这种情况也会导致你产生一种技术上的浮躁感，因为都能帮你生成功能了，可能你就不会去深入钻研，这会导致你在技术上无法深入原理，会在技术低端区反复横跳，自我感觉良好，但实际上个人能力并没有真正得到提升，反而导致了技术能力和思考能力的双重下降。这对于致力于从事软件开发行业的新人来说是非常致命的。

这里看一个最近真实的例子，其他组的一位同事不自主思考，纯用 AI 开发的反面例子：

主管给他看了差不多一个小时的代码(CR)，一开始语气还正常 后面就有点激动了。
主要还是不熟悉项目本身，然后再加上只用AI IDE一把梭，导致自己最后也不知道自己的代码流程是啥样，最后程序流程不知道、业务流程不知道、要做什么也不知道。

领导与开发对于AI Coding的认知偏差

现在最大的问题，是领导层对于AI的能力认知，和底层真正干活的人感知到的AI能力，是有偏差的。这就导致底层干活儿的人很难受。

领导觉得AI什么都行->你实际发现AI并不能解决所有问题->你跟领导解释这个事情->领导觉得是你不行

管理层错误地将“代码生成速度”等同于“开发效率”。但是真正的软件开发，除了功能性需求之外(虽然AI连这部分都还搞不定)，还有很多非功能性需求。

在领导的认知里面，AI就是“代码许愿池”，念个咒语(Prompt)就能搞定一切需求。而初级开发也是将AI Coding当成了抽卡游戏，纯靠运气生成功能。
这种模式最大的问题是：它创造了一个巨大的、不断积累的技术债。
为什么我会感觉vibe coding让程序员越来越浮躁了？安小强的回答

AI IDE写POC项目很好，但是一旦涉及复杂的要真正上线应用的ToC项目，还是要人重度参与并评审逻辑和代码的，否则后面随着需求迭代，增加功能和改BUG是个灾难。
配套的AI Coding基建一定要做好(代码约束)，不然迭代到后面，AI写的项目会变成屎山。
资深开发，用AI IDE提效非常明显，新人反而提效不明显，因为对于AI生成的内容，缺乏判断力，后面会陷入打地鼠的改BUG模式。
另外后端的效果好一点，是纯逻辑和流程的，前端没那么好，因为视觉层面的内容和交互，比较难以准确的传递给AI。
看具体需求吧，常规UI或者中后台的页面是可以的，但是精细化的页面就不大行了，比如我们画一些可视化的效果，就很难用AI直接处理，类似瀑布图这种，数据驱动的可视化，带有动画和交互，很难给AI描述清楚；纯静态的页面效果倒是还可以。
用AI可以在前20%的时间搞定80%的功能，但是剩下20%功能需要你用80%的时间去搞定。