Vibe Coding 屠龙纲要

2025-07-02 约 13491 字预计阅读 27 分钟

Vibe Coding氛围编程作为一种新兴的编程范式，由OpenAI联合创始人、前特斯拉AI部门总监Andrej Karpathy于2025年2月在社交平台X上首次提出。以Cursor Agent模式（Composer）为代表的编程智能体作为Vibe Coding的基础工具，为软件开发带来了革命性的便利，让开发者能够通过自然语言表达编程意图，指导AI编写、测试、优化代码。

这种协作模式降低了编程门槛，大幅提升开发效率，让开发者能够专注于创意和产品设计，而非繁琐的代码实现细节。Karpathy将这一变革称为"软件3.0时代"。

然而，在实际项目中，如何有效实施Vibe Coding仍面临诸多挑战。一些开发者反馈Vibe Coding在新项目、小项目中表现良好，但在复杂的企业级项目中的效果一般，甚至反而会影响系统的稳定性。也有一些开发者提出是否有一个简单、粗暴的屠龙神技可以显著提升Vibe Coding的效果，让AI生成的结果产生质的飞跃，一句话完成一个复杂需求的开发。

图片来源：《把这十句话丢到Cursor Rules，让AI编程水平提升10倍》

对于这些问题，我也总结了一些自己的经验，戏称为《Vibe Coding屠龙纲要》。正如知名游戏魔兽世界中的传奇道具“奎尔萨拉”，获取它的前置条件就是找到这本“屠龙纲要”。但事实上Vibe Coding也好，AI辅助编程也好，并没有所谓的屠龙技、屠龙剑，无非是需要把一些经验、方法和工具应用于实践，这也是我写这篇文章的初衷。考虑到AI的发展非常快速，我也会有理解错漏的地方，所以只能称为纲要，且暂定为1.0版本，后续再优化完善。

1. 心法：Context is All You Need

Prompt专家李继刚老师曾在2024年AI创新者大会上分享过他对于AI生成效果和Prompt之间的关系，并提出一个公式：

AI生成效果 = LLM(Task+Prompt)

他解释道要想获得一个相对较好的AI生成效果：

用户需要对向AI提出的任务Task有一定的理解，这是用户和AI对话的本意：比如你要想AI提问一些有关编程的问题，你需要对编程有一定的了解，你才能知道如何向他提问，才能在一定程度上甄别AI的回答是否准确。
用户需要对这个任务Task，通过提示词Prompt正确表达出来，这是用户和AI对话的语意：比如那个经典的程序员笑话“下班遇到卖西瓜的买1个，如果遇到卖桃子的买2个”，结果程序员下班买了2个西瓜，因为遇到了卖桃子的。这就是二义性导致的语意不清。
大模型LLM是一个放大器，对Task和Prompt叠加的效果进行放大，并进行解意，然后给出回答。

所以这就是为什么即便使用同一个大模型，不同的用户会有不同的感受，有的人觉得很好，有的人觉得不好，这种很主观的感受就来自于每一个用户对Task的理解能力，对Prompt的表述能力本身就存在差异，而模型放大了这个差异。

这个公式是一个对AI、大模型、Prompt高度抽象的心智模型。但在AI Coding领域，我对这个公式做了一个小调整，变成：

AI生成效果 = LLM(Task+Context+Prompt)

并且我对Context的解释是：Context是Task本意和Prompt语意的一个重要补充——语境。

这是因为李继刚老师更关注在AI对话这个通用场景，在这个场景中，Prompt语意中其实可以包含一定的Context语境信息，比如上面那个程序员笑话，只要我们消除二义性，对表述进行细化，比如“下班遇到卖西瓜的买1个西瓜，如果遇到卖桃子的再买2个桃子”。或者我们就在这句话前加一个限定条件，比如“这是一个程序员笑话”或者“这是一个生活常识”。那么不管是人类还是AI，都可以更好的对它进行解意。

然而在AI Coding场景中，软件项目的复杂度是上面这个笑话的数百倍甚至数万倍，人类很难用精准且完整的语意把整个软件项目的需求描述清楚。所以这也是为什么如果开发者还沿用普通的Prompt技巧使用AI Coding工具，不管是Cursor、Copilot还是其他工具，获得的效果会不太好的原因，尤其是在一些稍微复杂的项目中。

我在工作中也遇到过这样的情况，开发者用了某AI Coding工具A，使用简单的Prompt让它生成一些内容，发现效果不太好，于是得出一个结论，工具A不好用。于是他换了一个工具B，由于工具B可能在模型能力上有增强，恰巧这个问题得以解决，于是得出另一个结论，工具B好用。但他用了一段时间后又发现工具B在其他一些场景中，仅使用简单的Prompt效果依然不好，于是又修改结论工具B也不好用，可能是工具C、工具D好用。但最终变成所有的AI Coding工具都不好用，还是人写的代码靠谱。

试想一下，作为一名开发者，当我们去实现一个需求，修复一个Bug，我们要做的事情就是去判断什么情况下我需要去哪获取什么样的信息，并进行尝试。如果这个尝试给出了什么样的反馈，我会再去决定When / Where / What / How 获取信息，其实都是对上下文的获取、组合和处理。这里面有很多需要发挥主观能动性的问题，而目前仅依靠AI大模型、AI工具自身能力，AI很难独立完成这一任务，这是当前AI Coding类工具的限制性条件，我也相信未来一定会随着时间的推进而得到完善。所以作为用户、开发者，我们可以等到那一天，仅通过简单的描述就让AI工具能自主分析并完成我的需求，但当前该如何解决这一问题？

当Claude 4.0 和Gemini 2.5 Pro支持二十万甚至百万级Token上下文时，我们是否可以用更好的模型，更长上下文的模型来解决这一问题，把整个代码项目完完整整装进大模型的上下文中，让它更好的获取这个语境。然而我们被“误导”了，或者说我们“误解”了，如果我们去了解Transformer模型的架构，去了解Token和Attention机制的关系，那些标榜某模型可以把整本红楼梦塞进上下文中，或者把整个代码项目塞进上下文中的自媒体文章，事实上它并不是真的要把整本书、整个项目的每一个字都作为上下文来进行记录。本质上还是会对这些文字内容进行压缩、对关键信息进行提取。但哪些信息是关键的？会把某些时候需要使用的信息压缩掉吗？这背后涉及的原理过于复杂，我无法在本文中展开，但可以参考Gemini 2.5 Pro的负责人Nikolay Savinov的访谈《Gemini 2.5 Pro 负责人：最强百万上下文，做好了能解锁很多应用场景》，我提取2个重要的观点：

当前的瓶颈在于，对于短上下文模型来说，提供的额外上下文有限，不同的信息源之间为获得模型「注意力」会存在竞争；但对于长上下文模型来说，不相关的信息会降低模型表现。不相关或强干扰信息会与目标信息竞争模型的「注意力」，尤其在多关键信息检索任务中，反而会降低性能。现阶段，精选上下文依然重要。
在当前百万 token 上下文远还没有达到完美之前，盲目追求更大规模的长上下文意义不大。

最后，在今年的6月19日，Andrej Karpathy也转发了Shopify 的 CEO Tobi Lütke的Twitter，对Context Engineering表示强烈认可。

铺垫的内容很多，但Context无疑是当前AI Coding场景中非常重要的一个影响因素，可以说 Context is All You Need.

2. 技法：三板斧

既然Context在AI Coding中有着不可替代的重要性，前文也说过随着时间的推移，AI大模型、AI工具自身可能会更好的解决这一问题，让AI工具能够自主的、智能的去获取、处理上下文。但对现在的开发者来说，我们该如何利用Context，我们有哪些方式可以去提升Vibe Coding或者说AI Coding的效果？

AI界的至理名言“有多少人工，就有多少智能”，我们还是可以借助人的思维方式。当我作为一名开发者去开发一个新系统、接手一个老项目、维护一个功能、修改一个Bug，我是如何做的：

我需要先了解这个项目的整体情况。比如主要功能、系统架构、技术栈、依赖关系、业务流、数据流等等。基于我对这个项目宏观信息的了解，我才能够知道后续的开发工作要如何开展，我新增或者修改的功能需要去看哪个模块，可能会有哪些风险。如果我完全不了解这个项目，我哪敢盲目开始干活，但现在我们好像在要求AI在毫无准备的情况下来一场说走就走的屎山之行。
在开始开发工作之前，我还需要了解这家公司的设计要求、开发规范与编码习惯。比如是否有一些内部的资源库、组件库需要在项目中使用，API是习惯用RESTFul还是有内部的接口规范，有没有编码风格的要求等等。这也是很多企业用户对AI Coding工具提出来的一个共性需求。
在具体的开发任务中，我还会遵循软件工程的一些实践经验，比如需要先对需求进行分析，设计初步实现方案，判断这个方案是否会对当前项目的其他功能或系统架构产生影响，还需考虑模块化与解耦，然后才会开始编写代码。这个过程不是一蹴而就的，甚至一开始我也无法想的很清楚，在编码的过程中还会发现一些问题，导致我不得不重新思考，甚至要推翻重来。这同样也是AI在生成代码时会遇到的情况。

当然，在真实软件开发场景中，这个过程会更加复杂，但我们只需要提取这个过程中具有共性和重要性的关键步骤，并对其进行总结，从宏观到微观，从面到线到点，并应用于Vibe Coding中，这就是本“纲要”的核心技法。

注：以下示例使用Cursor + ChatGPT 4.1或Cline + DeepSeek V3 0324进行演示。

2.1 面：项目描述

先看一个Vue框架的示例项目，切换到import分支，在这个项目里，有一个account.vue文件，我在没有任何上下文的情况下直接使用Cline，让它帮我实现以下需求：

1
2


@/src/views/account.vue 
在handleSubmit中检查当前页面是否有名为“test”的子组件，如果有则打印到控制台

这是一个非常简单的项目，但生成的结果依然有较大概率无法使用，主要原因是AI会将这个项目的框架默认为Vue 2，因为项目使用了部分Vue 2的语法，但实际上这是一个Vue 3的项目，而Vue 3中已经移除了$children的使用，所以会导致报错：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


methods: {
  handleSubmit() {
    console.log('表单提交:', this.formData)
    const testComponent = this.$children.find(child => child.$options.name === 'test')
    if (testComponent) {
      console.log('Found test component:', testComponent)
    }
    // 这里可以添加提交逻辑
  }
}

这种情况在实际项目中非常常见，其原因就是AI Coding工具并不了解这个项目的整体情况和基本信息，除非我们在Prompt中明确告诉AI需要它基于什么技术栈来给出答复，但这个动作太过麻烦，而且AI会左耳朵进，右耳朵出，我们需要不断地重复提醒AI。为了证明这一结论，我用Cursor也复现了这个问题：

那我们能否建立一个项目描述文件，把它当做给AI看的PRD、项目文档，让AI对项目有更清晰、准确的了解，以提高代码生成的准确性？

2.1.1 README

我们依然可以参考人工去了解一个代码项目的过程。一般开发者去了解一个陌生项目的主要途径就是看文档，看项目的README文件，所以我们可以创建一个README文件，在里面添加一些关于项目描述的内容，比如：

1
2
3
4
5
6
7
8


# 项目描述
## 功能模块
1. src/components：自定义组件
2. src/views：表单
## 技术栈
1. vue 3.5
2. element-plus 2.9
3. vue-router 4.5

然后在Cline中手动加入这个README文件作为上下文，再次使用相同的Prompt来生成：

很快我们就能得到一个正确的结果。但依靠人工来创建、维护这个README文件还是很麻烦，尤其是在复杂的项目中，需要投入的时间和人力成本会很高，那有没有更智能、简便的方法？

我们可以利用AI来生成这个README文件，还是在这个示例项目中，使用以下Prompt：

1
2
3
4
5
6
7
8
9


分析这个代码项目，按照以下格式将分析结果输出到README.md文件中：
# 项目描述
## 功能模块
1.
2. 
## 技术栈
1. 
## 依赖
1. 

就可以自动生成一份README文件，当然这个Prompt写的比较简单，实际上你也可以把系统架构、模块依赖关系、数据流等要求写入Prompt中，以获得一份更完整的项目描述。

但，还有更好的方案吗？

2.1.2 Memory Bank

2000年上映了一部由诺兰执导的电影《记忆碎片》，主人公伦纳德·谢尔比患有短期记忆丧失症，无法形成新的记忆，每隔一段时间他就会忘记刚刚发生的事情，为了寻找杀害妻子的凶手，他把重要信息纹在自己身上、拍成照片或写在便签上。电影的结局非常复杂且具有争议，本文不做讨论，但伦纳德的状态就像是目前的AI，每一次新的对话它就像是失去了所有的记忆，我们必须把一些重要的信息告诉AI，让它在重重迷雾中寻找真相。

为了解决这个问题，Cline在2024年底推出了一个名叫Memory Bank的功能，它的底层逻辑就是通过Prompt按照不同的维度对代码项目进行分析、总结，并将这些关键信息存储下来。在后续的代码生成任务中，读取这些关键信息作为上下文，以获得更快、更好的生成结果，同时按需更新和补充这些关键信息。

2.1.2.1 主要特点

可以查看Cline官方文档来了解Memory Bank的详细信息，这里我总结了Memory Bank的几个主要特点：

自动化：Memory Bank的创建是自动化的，但目前需要手动触发来完成这一任务。
持久化：Memory Bank会将一些关键信息持久化保存在本地，可以延长AI对于整个项目，或者某个持续性任务的记忆。
通用性：Memory Bank的机制适用于各种类型、各种语言的项目，也可用于Cursor、Windsurf等其他AI Coding 工具。
全面性：Memory Bank总结的内容是多维度的，包括了项目简介、系统架构、设计模型、技术栈、近期变更、任务进度等信息，有助于开发者或AI快速了解项目基本信息。

2.1.2.2 使用方式

Memory Bank的使用方式也很简单，以Cline为例，先在项目中创建文件夹memory-bank，再按下图创建Cline的Global Rules，名称为memory-bank-instruction.md，拷贝并粘贴 Cline Memory Bank Custom Instructions 中的内容：

在对话框中输入Prompt init memory bank，Cline就会自动在memory-bank目录下创建记忆文件。

创建好Memory Bank后，在每个对话任务前，输入Prompt follow your custom instructions，让AI先了解项目基本情况，然后再给出具体的任务让AI执行。

但在这个例子中，AI还是使用了Vue 2的语法。这就是前文中提到的大语言模型LLM对应的是解意，虽然我们已经尽力给出了本意、语境和语义，但LLM在某些时候，某些场景下就会出现解意异常的情况，你可以换一个LLM，但这个LLM在另一个场景下依然会出现同样的问题。

那为什么在README这个方案中，我们只是很简单的创建了一个描述文件，AI生成的效果反而更好，而在Memory Bank这个方案中，项目描述文件的内容更多，操作更复杂，反而效果还变差了？这也是前文中说到的Attention机制，上下文长了未必好，信息太多会干扰AI的注意力。但千万不要被README这个方案迷惑，这个示例项目是个很简单的项目，在一个复杂的真实项目中，你的README一定不会那么简单。

那如何解决这个问题，我们可以告诉AI这个错误的原因，并使用Prompt update memory bank 来更新Memory Bank，让它记住这个错误，就像谢尔比不断在记录和修改他的便签条。

撤销account.vue文件的变更，基于新的Memory Bank再次尝试，这次AI没有犯错。

2.1.2.3 总结说明

Memory Bank的使用比较简单，只有3个命令。但还有很多优化空间，比如能否简化命令，或提供一些快捷操作，每次新对话需要使用follow your custom instructions进行初始化还是不太友好。
使用Cline，在新对话中，建议先在Plan模式中初始化Memory Bank，输入任务需求，让AI收集信息，分析需求，再切换到Act模式执行任务，以获得更好的效果。
Memory Bank既可以用于新项目，也可以用于老项目，但需要定期对其进行更新。虽然Memory Bank有自动更新机制，当AI新生成的代码有break change时会自动更新，但还是会有很多人工编写的代码或者像上文中提到的，我们随时需要来纠正、补充一些重要信息，避免AI重复犯错。
Memory Bank可用于Cursor、Windsurf等其他AI Coding工具，如Cursor，可以参考cursor-memory-bank这个项目，本文不再重复。
Memory Bank会增加Token的消耗，但会有效减少AI因对项目缺少整体认知，重复生成错误内容，并需要投入大量时间来纠错的问题，Smarter token use, not just more use.
目前关于Memory Bank的使用、实践还很初期，Youtube、B站、网络媒体关于Memory Bank的介绍都还只停留在概念和基本功能上，没有太多实际效果的演示，最多是用Prompt介绍这个项目总结Memory Bank的内容而已。反倒是cursor-memory-bank的介绍比Cline原版的Memory Bank还要详细、丰富，实属倒反天罡。上文相关的使用方法、最佳实践我也是参考了Memory Bank的作者Nick Baumann仅有的2篇帖子，但Memory Bank让我们看到了Context Engineering的雏形。
- A few questions about Cline memory bank
- Memory Bank: How to Make Cline an AI Agent That Never Forgets

2.2 线：约束条件

继续这个示例项目，让Cline帮我实现另一个需求：

1
2
3
4
5
6


修改 @/src/views/account.vue ：

在提交按钮前新增一个下拉框（SelectInput）  
- 名称为：申请表
- 内容为：OA、ERP、CRM 
- 支持多选

我期望的结果是AI能够复用 coderider-demo-vue 这个自定义的npm库中的SelectInput组件，但AI显然没有获取到这个上下文，因为在Memory Bank中也没有相关信息。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


<div class="form-actions">
  <div class="form-group">
    <label>申请表</label>
    <SelectInput 
      v-model="formData.applicationTypes"
      :options="[
        { value: 'OA', label: 'OA' },
        { value: 'ERP', label: 'ERP' },
        { value: 'CRM', label: 'CRM' }
      ]"
      :multiple="true"
    />
  </div>
  <RedButton type="submit" class="submit-btn">提交申请</RedButton>
  <button type="reset" class="reset-btn">重置</button>
</div>

除非我们在Prompt中明确告诉AI要使用这个npm库，或者去更新Memory Bank。但这些信息的粒度又比项目描述要更细，可能还包括一些开发规范与编码习惯，所以我们需要另一种方式来管理和维护这些具有约束性质的上下文，这就是Rules。

2.2.1 使用方式

2.2.1.1 创建规则

在示例项目中，有一个coderider-demo-vue.md文件，里面描述了要如何使用coderider-demo-vue这个自定义组件。还记得上文中README这个模式么，我们同样可以在对话过程中引入这个文件，但我们可以把它加入到Rules中，让AI默认加载这个上下文。

以Cline为例，先在项目中创建文件夹.clinerules，然后把coderider-demo-vue.md文件移动到这个文件夹下，补充一些说明：

1
2
3
4
5
6


# views页面开发规则
1. views下的页面需参考 src/views/account.vue 的样式和设计风格
2. views下的页面需使用 coderider-demo-vue自定义组件，使用方式如下：
## coderider-demo-vue
## 安装方式
...

再按下图确认Cline的Workspace Rules是否生效：

再次执行这个任务，可以看到AI实现了预期的效果：

当然在Rules里，我们可以结合MCP来进一步简化规则或者编排复杂的规则，我已经将coderider-demo-vue这个自定义组件上传到了Context 7中，在Cline中使用Context7的MCP，就可以把规则简化为：

1
2
3


# views开发规则
1. 需参考 src/views/account.vue 的样式和设计风格
2. 需使用 coderider-demo-vue自定义组件，务必使用Context7获取coderider-demo-vue的使用方式，use context7

或者我们增加更多规则来适配不同的场景要求：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 项目开发规则
1. 项目使用vue3框架开发，当要查询Vue3的语法和使用方式时，务必使用Context7获取Vue3的语法和使用方式，use context7
2. 项目使用Element Plus

# views开发规则
1. 需参考 src/views/account.vue 的样式和设计风格
2. 需使用 coderider-demo-vue自定义组件，务必使用Context7获取coderider-demo-vue的使用方式，use context7

# 其他开发规则
...

关于MCP和Context 7的使用方式本文不再展开，可以查看Context 7官方文档了解详细信息。

2.2.1.2 导入规则

真实项目中，我们除了可以手动创建一些常用规则外，还可以导入一些规则，这些规则可以来自于企业内部的沉淀，也可以使用社区中一些通用的规则，比如awesome-cursorrules：

这些规则不仅可以在Cursor中使用，也可以在Cline等其他AI Coding工具中使用，只需要按照工具的要求把这些规则放在指定的目录并设置生效即可。

这些规则往往包含了一些语言、框架的最佳实践，比如：

命名方式是用驼峰还是Pascal，还是企业内有自己的格式要求，是否有一些示例。
注释是行注释还是函数级注释，注释的要求与格式是怎样的。
使用框架或其他方式来避免XSS、注入等安全问题。

总之，需要根据实际需要来导入并裁剪这些规则，让AI能生成更符合企业或用户要求的代码。

2.2.1.3 生成规则

在一些老项目中，已经有一定的开发规范与编码习惯，如果我们想遵循这些规则，或在其他项目中复用，我们可以利用AI来基于这个项目自动生成规则。

在Cursor的0.49版中，提供了·Generate Cursor Rules这个功能，我们可以在对话框中输入/Generate Cursor Rules，Cursor就会自动生成这个项目的规则，甚至包含一些项目描述。

看到这里，不免有个问题，Rules和Memory Bank有什么区别，看起来Cursor生成的Rules里也包含了Memory Bank里的一些信息。

我们可以从以下几个方面来理解和区别这两个概念：

Rules和Memory Bank本质都是是上下文，用来存储记忆。
Memory Bank是一个逻辑功能，可以用Rules来实现它，比如Memory Bank Custom Instructions就是存储在Rules中。
Memory Bank存储的更多是一些项目的概要信息，而Rules存储的内容粒度会更细，比如上文中提到的一些设计要求、开发规范与编码习惯。
虽然理论上可以把Rules的信息也存储到Memory Bank中。但Memory Bank更适合在Vibe Coding场景下使用Agent来处理一些任务，而很多时候我们依然需要代码补全、AI对话等方式来实现一些需求，就没有办法加载整个Memory Bank，毕竟在补全、对话等场景下，我们还是要追求更快的响应速度。这时候我们就可以把Rules中的内容，或者指定某个Rules来进行代码补全、对话，让AI生成符合要求的代码（虽然Cline没有代码补全和和AI对话功能）。

2.2.1.4 完善规则

最后，与Memory Bank的使用方式一样，及时或按需的更新和完善规则在真实项目中更为重要。

在这个示例项目中，如果我想让AI生成一个新页面，AI可以完成这个页面的开发工作，但它并不会给这个新页面创建路由，所以无法直接访问该页面。为了让AI记住这个问题，我们需要对规则进行补充：

1
2
3
4


# views开发规则
1. 需参考 src/views/account.vue 的样式和设计风格
2. 需使用 coderider-demo-vue自定义组件，务必使用Context7获取coderider-demo-vue的使用方式，use context7
3. 新建的页面需要增加路由以便可以通过url访问

还有一些场景，比如我询问AI安卓项目如何清除gradle缓存时，AI给出答复是：

这个目录是gradle的全局缓存目录，如果真删除了这个目录，所有项目都需要重新下载依赖，这一天就不用干活了。这是一个有风险的答复，但AI没有给出说明，所以我可以得出一个结论，这个AI工具不好，或者这个AI模型不好么？实际上由于上下文的缺失，其他工具、其他模型也会给出同样的答复。

所以解决问题的办法还是要通过规则来约束：

1
2


# 规则
1. 对于任何有风险的操作，如删除文件、删除全局缓存，应给出标识'【注意风险】'，并给出替代方案

2.2.2 规则类型

Rules的类型主要有2种，前文中也有提及：

用户级/全局规则：在Cline中叫Global Rules，在Cursor中叫User Rules，放在系统目录或AI Coding工具目录进行存储，对用户的所有的项目都生效。
项目级规则：在Cline中叫Workspace Rules，在Cursor中叫Project Rules，放在当前项目目录中，对这个项目生效。

真实项目中这两种规则可能会同时存在，比如项目级规则存储的是企业或项目统一的要求和规范，而用户级规则存储的是企业没有明确要求，但开发者有自己的一些偏好。

另外在Cline和Cursor中，Rules的触发机制也不一样：

Cline是使用开关，打开就默认加载到每次对话中，或者关闭后在对话中手动引入这个规则：
Cursor是需要配置触发模式，比如Always就是默认加载到对话中，Auto Attached就是匹配规则触发，比如仅对于src/views中的文件触发，这样就可以避免在一个规则文件里去写条件判断，管理更清晰方便。所以Cursor的Rules功能更丰富，体验更好：

2.2.3 总结说明

Rules的使用频率、范围比Memory Bank更多、更广。如果AI Coding 工具支持，Rules可以应用于代码补全和AI对话。
导入一些通用Rules，进行裁剪，并在实际工作中不断调整、完善，沉淀成自己或者企业统一的开发规范，是Rules的最佳实践。
相同的Memory Bank和Rules，在不同的大语言模型下的效果可能有略有差异，更换模型后可能需要进行一些优化和调整。

2.3 点：开发任务

基于前文Memory Bank和Rules的构建，我们来尝试完成一个稍微复杂的任务。

1

新建一个页面address，标题是“员工办公地址变更”，内容如下：

序号	名称	是否只读	是否必填
1	申请人	是
2	申请部门	是
3	申请时间	是
	地址变更申请表
4	用户		是
5	原地址	是
6	变更地址		是
7	变更理由		是
8	备注

同样我希望这个开发任务能遵循Memory Bank中的技术栈和Rules中提到的自定义组件来完成开发，那我该如何告诉AI呢，把这个表转成文字？还是直接发给AI？其实不论哪一种，都会存在问题。

2.3.1 软件工程思想

让我们再回到人的思维，回到软件工程的思想，按照软件工程的“需求——设计——编码——测试——发布——维护”的6个关键过程，我们仅讨论“编码”及之前的过程，这其中AI最擅长的是“编码”，而不是“需求”和“设计”，这就需要人来主导完成这一步。

分析需求：当一名开发者接到一个需求任务，要做的第一件事就是怀疑它。怀疑它是无效的、不清晰的、有冲突的、无法实现的。当然我们不能无端诽谤，需要通过分析来找出证据。比如在这个需求中，这些字段使用的组件类型是什么？数据源是什么？有没有一些要注意的事项？
拆分任务：接着，需要拆分这个任务，绝大多数情况，开发者会先实现这个需求的前端页面设计，然后再去实现表单提交或者接口请求等后端业务逻辑。在使用AI Coding工具时，我们可以明确告诉AI需要执行哪些步骤，让AI分步去执行，这样AI Coding工具就会设置检查点，当某一步有问题或效果不佳时，我们可以恢复到这个检查点重新开始，而不影响前一个步骤。如果任务过于复杂，为了避免AI的Attention被分散，我们也可以逐个向AI下达任务指令，每次只完成其中的一小块功能。由开发者自己来串联整个需求功能的实现。
清晰描述：当我们已经明确需求，并且已经拆分任务以降低其复杂性后，如何把这些人能看懂的信息传达给AI，这就需要对Task和Prompt有一定的认知了。这件事其实对于开发者来说不难，毕竟大家都是身经百战，和产品经理有着长期对线经验。所以Vibe Coding在目前看来，还是需要使用人员有一定的开发背景和经验，可以不懂某些语言的Coding，但一定要懂Programming.
设计思考：在进入编码环节之前，我们还可以与AI对这个需求任务的设计实现进行讨论，在Cline中使用Plan模式把整个任务的提示词发送给AI，让它先进行分析，没有疑问后再切换到Act模式执行，这也是敏捷开发的思想，慢思考，快行动。另外，如果条件允许，按照Cline的Model Selection Guide，在Plan模式下，最好使用推理模型，以获得更好的效果。
持续迭代：最后，即便我们做足了准备，建立了Memory Bank和Rules，使用了最好的AI Coding工具，最强的大语言模型，AI也很难一次完成开发任务，尤其是复杂场景的任务。这就需要持续和AI对话，重复之前的过程，让AI持续迭代这个开发任务。

最终的Prompt和生成效果如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


创建一个新申请单页面address，需求如下：

## 标题：员工办公地址变更

## 内容：
序号|名称|字段类型|数据来源|是否只读|是否必填|说明
1|申请人|TextInput|当前用户|是||本示例为张三
2|申请部门|TextInput|当前用户的部门|是||本示例为IT部
3|申请时间|DateTimePicker|当前日期时间|是||
4|地址变更申请表|TableEditor||||
4-1|用户|PersonSelector|||是|
4-2|原地址|AddressSelector|系统中记录的用户地址|是||
4-3|变更地址|AddressSelector|||是|
4-4|变更理由|SelectInput: 岗位移动、个人原因|||是|
4-5|备注|文本框||||

## 步骤
1. 创建页面
2. 创建路由
3. 处理提交事件：在handleSubmit中检查当前页面是否有名为“test”的子组件，如果有则打印到控制台

虽然软件工程已经是上世纪60年代的产物，但它的思想与实践方式在AI时代，AI Coding领域同样重要。试想一个遵循软件工程思想和设计模式的项目，做好了模块化与解耦，项目结构清晰，注释齐全，具备较好的可维护性和开放性，这样的一个项目使用AI Coding工具对其进行开发和维护，效果一定比臃肿、混乱的“屎山”项目要好的多。

2.3.2 结果 or 过程导向

当Vibe Coding的概念被提出后，也有不少人对它的定义进行解释和补充。比如一位名叫Simon Wilison的开发者就表示：

A key part of the definition of vibe coding is that the user accepts code without full understanding.

If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book—that’s using an LLM as a typing assistant.

他认为真正的Vibe Coding是不需要开发者去了解AI生成的代码，也不需要对他进行评审和测试，一切以运行结果为导向。

但用过Cursor，实践过Vibe Coding的开发者可能都有这样的感受：

AI在我不懂的领域表现的很强，比如一个后台开发者用AI去写前端，效果非常不错。
AI在我擅长的领域表现的很差，比如AI去写一些支付、出库等关键业务，完全不放心。

当然对于Vibe Coding也有其他声音，《如何看待王垠对 Cursor 等 AI 编程的评价「不懂计算机科学的人用好 AI 编程是妄想」？》一文中，计算机领域知名人物王垠也表达了自己的看法。个人认为这个评价非常客观，他提到：

懂编程才能驾驭AI Coding工具，知道AI哪里做对了，哪里做错了
从小做起，目标不要太高、太快。
AI 只是把人的能力翻倍了而已，如果你的能力是 0，无论乘以多少都仍然等于 0 （再次印证了AI是放大器）。

那究竟Vibe Coding是结果导向还是过程导向？至少在现在这个时刻，我认为还是要尽可能的过程导向：

对于一些关键业务，最好人工审查，毕竟出了问题，被扣钱的是开发者，没有人会去向Cursor索要罚款。
对于一些非关键业务，或者是开发者不熟悉的领域，可以结果导向，因为想审查也看不懂。

3. 身法：走为上计

回顾前文中提到的工具、方法、理念，我们并没有找一个完美的AI Coding产品，比如Cline虽然提出了Memory Bank这个精妙的设计，但它没有补全、对话等基础功能，而这些功能在实际项目中的使用频率其实更高。Cursor虽然好用，但也会犯一些低级错误，面对一些复杂任务也会束手无策。

AI的发展虽然快速，但它依然处于初期，所以我们不得不用人工来弥补智能的不足，这是这本《屠龙纲要》存在的原因。

作为DevOps的引领者，我司极狐GitLab也打造了新一代AI DevOps助手——驭码CodeRider，结合我们对AI Coding领域的KNOW-HOW，围绕GitLab去叠加AI能力，帮助开发者在DevOps全生命周期中提质提效。后续我也会基于CodeRider和本文的内容来分享一些最佳实践。

最后，我来用一个最简单但也最重要的内容来结束整篇文章：

走为上计

走代表着在Vibe Coding中，在使用AI Coding工具的过程中，AI经常会陷入一个循环，不断给出旧的、错误的回答，一旦遇到这种情况，可以终止对话，改为代码补全、AI问答或人工来实现这个需求，纠缠下去没有意义，这是放弃。

走也代表着作为AI时代的开发者，没人清楚以后的世界，以后的软件开发会是什么样，我们或许可以跟随AI走得更远，这是坚持。

勇士，愿圣光与你同在。

目录