裁员这么猛，AI修仙抗一波

嘱托

把AI当成一个普通的人来沟通，你就可以理解它所有问题。
- 1.你说不清，它就做不对。
- 2.人一次性记忆有限性，它也有限。
- 3.两个人需要多次沟通才能达成思路一致，AI也需要多次沟通。
- 4.当你一次性说了很多信息，另一个人一定会漏掉/忘记其中的一些。
- 5.让你给多次解释一段复杂定理，也不能保证每次都一字不差的一致性。
不要指望通过一句话，就让AI给你生成完全符合预期的内容，它猜不到你的心思
不是一股脑的把所有信息都给AI，它能记住的信息是有限的
不要期望AI一次性解决所有问题，保留耐心，经验丰富的开发者也需要调试
给AI的提的要求，它不能总是执行，总会有忽略或者优先级，也许多骂骂它，它会印象深刻
AI生成不是公式定理，相同话术也会有生成结果的偏差。一千个AI，说不定也有几百个哈姆雷特

一、本文主题

本次文章分两篇进行讲解和介绍，也是个人在Vibe Coding的主要实践，目前在公司内部多个组织下的团队做过分享。

无论是大家比较认可的国际IDE，还是国内的产品，也无论使用的国内外模型，本篇文章都受用。本人主要使用公司自己的IDE产品。

篇一

实践：基于前端角色和前端开发，讲解多种形式的vibe coding 的实际开发范式
架构：讲解前端开发中，体系化的 Vibe Coding 场景应用和架构设计

篇二

展望：介绍AI对前端职业的影响和变革，以及对自身学习成长的影响
实践：依托于AI，实现无学习周期的，前端转KMP跨端
思考：未来研发团队新形态的探索和思考

本篇为第一篇，主要针对前两点，系统性的讲解目前在前端领域 Vibe Coding 实践经验和架构设计。

二、概念知识

在开始主要内容之前，还是简单介绍一些概念，避免初次接触的人不熟悉。

Vibe Coding（氛围编程）： 我们也可以叫 AI coding，本质上是开发者通过对话式地描述想法，由AI负责生成和完善代码的一种开发方式。
知识图谱： 一种用图的结构来组织和表示现实世界中事物及其关系的大型知识库。（举例：警匪片中的人际关系网）
RAG(检索-增强-生成)： 将信息检索系统与大语言模型相结合的架构范式。核心是通过从外部知识库中检索相关信息，来增强LLM的生成过程
AI幻觉： 也称为模型幻觉，是指大型语言模型或其他生成式AI系统生成出看似合理但事实上不正确、无意义或脱离现实的信息的行为。
AI上下文超限： 也称为上下文长度限制或上下文窗口饱和，是指当输入给大型语言模型的提示词（包括用户查询、系统指令、历史对话和参考文档等）的总长度超过了模型能够处理的最大文本上限时发生的技术限制。
Prompt 提示词： 给人工智能（AI）模型的指令或问题，它是一段自然语言文本，可以是词语，短句，长句，核心在于让AI知道你想要它干什么。
自然语言： 人类在日常生活中自然发展、用来沟通的語言（中文、英语、西班牙语、阿拉伯语等）
SOP标准作业程序： 一份详细的、分步骤的指南，其目的是为了确保一项特定的任务或操作能够始终以一致、统一、安全且高效的方式完成。
瀑布模型： 先写文档再开发的模式通常称为‌瀑布模型‌。该模式严格遵循需求分析→设计→编码→测试的线性流程，文档编写是早期核心阶段，后续开发需基于文档执行‌。Vibe Coding偏向于这种，但是比传统更灵活，AI可以辅助编写和总结文档。
TDD： 先写测试再开发的方法称为‌测试驱动开发‌（TDD），TDD是一种敏捷开发实践。先有测试用例，可以保证AI生成内容的准确可控。

开发是一个轮回，兜兜绕绕老的设计模式，又发芽迎春了。

三、多形式的Vibe Coding实际应用

此篇章我们会基于功能开发，介绍多形式的Vibe Coding 应用场景。虽都是针对前端开发讲解，但在常规的大前端方向（跨端/安卓/iOS/桌面端）基本上一致。

我会结合我实际开发的体验中，预估一个AI能完成工作量的情况指标。

设计评审（AI 70%-90%）

设计评审核心是：提前评估出项目的风险和边界Case，保证项目稳定落地。

如果在你所从事项目开发的标准SOP里有设计评审这一步。那么祝贺你，AI可以将这一步给你实现70%-90%的内容。

Vibe技巧：

限定设计边界，技术栈，功能要求等关键信息一定全面
可选：使用server-sequential-thinking进行多轮思考
避免松散型的AI对话，应该增加rule和必要的条件限制，否则AI非常容易过度设计
如果功能较大，必须拆分模块生成设计评审，尽量避免一键式生成（使用mcp-shrimp-task-manager进行任务拆分规划）
最好是提供设计评审模版，作为AI的样本示例，以便约束AI输出结构
有流程图或者架构图的需求，可以让AI生成字符串版本流程图/架构图，然后在用其他平台工具人工绘制

第一步：写好任务要求，添加上下文

bash 复制代码

## 任务要求
1、封装一个完整的稳定的前端jssdk； 
2、SDK的核心功能API包含，图片上传能力，创建AI玩法任务，轮询AI玩法任务结果，针对异常结果有统一的错误封装抛出； 
3、Server接口方面有不同的玩法接口，示例：AI视频玩法使用，xxxxx/taskcreate创建任务，xxxxxx/taskquery查询任务；
4、SDK提供初始化配置参数，比如说自定义公共参数信息，用来每个内部情况的公参数； 
5、SDK处理提供创建和轮询的API，还对外提供其他API，比如人脸检测，风控检测，人脸坐标数据识别返回，文件转存等，API是动态扩充的，需要合理的设计拓展方式。
6、最终打包产出的是支持es5的前端jssdk，可以使用rollup作为打包构建项目的基础。
7、合理的设计整个SDK的目录结构，保证项目鲁棒性和拓展性，使用专业设计模式设计。
8、本次内容过多，可拆分多次输出，不要丢失上下文内容，另外能给出架构图，或者流程图的地方，尽量用图表示。
9、输出设计文档，内部不用有太多代码，只有关键代码实例说明即可。最终输出markdown文件。

第二步：使用 RIPER-5 rule 添加上下文

RIPER-5 协议Rule非常适合设计评审，可以去网上找，存在很多版本。采用RESEARCH(研究)→INNOVATE(创新)→PLAN(规划)→EXECUTE(执行)→REVIEW(复盘)五大阶段主线

英文：

forum.cursor.com/t/i-created...

中文：

linux.do/t/topic/580...

第三步：提供额外的文档到上下文

需求文档，需求文档一般会有边界case或各类细节条件，很多都是设计评审需要关注细节。
样本示例文档：让AI输出符合要求的文档格式，这样得到的结果更准确符合要求。

第四步：生成设计评审

总结说明

上面是我历史上一个大型SDK封装的设计评审，全部由AI生成，人工审核。但当时处在AI早期应用，存在一些问题。

过于松散的AI对话：只表达了功能，缺少约束，AI过渡设计（监控/部署/国际化）我基本不需要
一次性生成：一次性直接生成所有，导致中间没有回旋余地，不必要的东西或者模块内容无法控制
未提供设计模版：没有给AI样本模版，导致AI完全按照自己的想法实现，做了不必要的总结归纳
未做拆分设计：最后我让AI重新将设计拆分了四个模块，生成独立文档。如果一开始我就要求AI拆分任务和文档，那么我可以更好的控制和修改每个模块生成的内容。

所以Vibe Coding在设计评审场景应用流程：

调研评估（AI 95%以上）

调研最核心的内容是：得到一个准确，可行的结论。

一般来说，这一步总是在设计评审中，多数时候更像设计评审的子集，偶尔会有需要单独调研的技术内容。

技术调研这一块，AI对开发者是降维打击。以前使用新技术总是恐惧，现在这块全交给AI就妥妥的。AI实现 95%以上的内容。

Vibe技巧：

可以通过AI快速得到技术方案可行性的初步结论，和若干条实现思路
人工审核结论和方案分支可行性评估，选出最为可行的方案。
由AI生成人工审核通过的方案分支代码，必须给出足够明确的信息和依赖说明，然后验证方案可行性
AI的技术调研，必须附带实际效果验证，否则不要给结论（AI会有幻觉，而且它经常会迎合你的预期）

通过纯前端手段，微信小程序能做gif添加文字么。

虽然AI给了方案调研结论，看起来也非常可行，但是，这个访问有很多未知问题：性能问题、三方库对小程序兼容问题，可能带来的崩溃问题，这几个问题是致命的，很可能导致需求无法实现。

所以Vibe Coding在调研场景应用流程：

AI给出初步结论和方案分支 => 人工选择方案分支 => 由AI生成验证代码 => 人工测试检验通过 => 让AI总结再次评估可行性 => AI生成完整的调研落地文档

单元功能(函数/类方法）（AI 98%以上）

单元功能核心是：明确可以用的功能，稳定的输入/输出。

此类代码开发，受AI影响最大，AI基本上能100%完成，甚至绝大多数时候比研发表现的更优秀。这是多数人的应用场景，现在你肯定不会在手写时间格式，url参数获取，版本比较等等工具了。

Vibe技巧：

给 AI 明确的输入，输出和清晰功能表述**（清晰的设定指令和格式，要有足够的明确性）**
让 AI 生成必要的注释说明，包含入参和出参格式Demo

markdown 复制代码

## 任务
- 实现一个时间js版本的格式化函数

## 要求
- 入参 time：time=string|number: 支持字符串和数值，支持秒和毫秒单位入参，根据字符/数字长度 秒 * 1000 换算成毫秒
- 入参 format="YYYY-MM-DD HH:mm:ss": 支持根据格式动态输出日期
- 出参 string 格式: 格式化后的时间
- 月/日/时/分/秒时间要求: 必须采用不足10补0方案
- 给函数增加必要的注释说明

你可以只给AI一句话（帮我实现一个实现格式化函数），但那样多数情况不会符合你的预期。AI会基于自己的理解进行开发，甚至它都不一定给你的是JS函数，因为你没告诉他用什么编程语言。

当然如果你在IDE中这样说，还是可以实现的，因为IDE会自己检索当前项目信息（技术栈，关联文件或代码）

单个/多个类/多个函数集成功能开发（AI 90%）

核心是：稳定可用且符合项目规范的通用能力封装。

此类在实际开发中，通常是小型通用能力封装，典型例子：Canvas绘制分享海报，Canvas 图片裁剪，通用的业务逻辑抽离（各类业务hooks）。

这类业务，缺少经验的开发者用AI实践稍有困难。问题其实不在AI，而在于使用者。很多人在应用到这种场景后，开始对AI评价降低，认为AI不太行，而后逐渐弃用。

Vibe技巧：

首先需要明确自己想要的功能是什么，整理出功能文档，而不是立刻让AI去执行开发，以裁剪为例子。

markdown 复制代码

### 需求背景
- 因为业务发展，对Canvas裁剪图像，Canvas实现动画等能力，需求日益增加
- 为提升研发效率以及代码复用，提出Canvas裁剪、动画等能力抽象到通用库中

### 技术栈要求
- 前端JavaScript
- Canvas API
- TypeScript
- Vite
- 前端单元测试

### 功能介绍

#### 基础裁剪功
1. 输入一张图片和一组坐标 [list]，输出裁剪结果 [list]。
2. 可以指定输出格式，通过入参数 [list] 的 [outType] 字段指定输出，canvas对象，blob数据流，base64。

#### 比例裁剪
1. 支持输出图形长宽比例，默认值比例关系为1:1。
2. 设定特殊比例后，已坐标中心为原点，外扩坐标，让裁剪后图形边的最大值，等于原图最小边的值。

#### 带操作区的裁剪
1. 带有裁剪框，可以设置裁剪框UI样式。
2. 支持手势操作，拖动缩放，支持外框宽高可设置。
3. 图片加载时，默认最大边缩放到裁剪框内。
4. 放大倍数最大值为图片最小边等于裁剪框最大边的2倍。

### 开发要求
- 考虑通用性，期望使用纯JS实现，便于适配Vue/React等框架
- 使用 typescript 作为类型约束规范
- 仅封装一个基本的入口文件index.ts，集成三个核心功能
- 采用纯函数编程，避免使用Class类
- 对外暴露三个核心API，基础裁剪，比例裁剪，带操作区裁剪。同时抽离三个API的公共能力。

其次设定好项目基本规范（技术栈/代码风格/UI标准/目录结构），可让AI基于项目生成项目规范rule，或者提供必要的组件/文件作为样本参考。
拆分任务，将整个实现，拆分多步，然后进行人工审核合理性。（增强AI生成结果可控性，理解AI的开发思路）

基于文档，实现功能

要求
1.先将整个实现过程，进行拆分任务。
2.每个任务代码开发前必须给出开发思路，由人工审核确认是否继续。
明确要求AI，针对每个任务进行代码开发前，必须给出开发思路，人工确认后才进行代码开发。（让开发者明确每一步思路，辅助理解AI后续代码）

对于历史项目代码，一定要先让AI总结模块信息沉淀文档 ，便于后人理解的同时也是AI的核心上下文，一次沉淀后也不用每次都让AI总结，节省Token。最后人工检查并纠正AI生成的内容文档 （未来的知识库）
最后开发完成后，让AI复盘代码，并更新或生成必要的文档，丰富知识库。

所以Vibe Coding在较为复杂开发场景应用流程：

UI视觉开发（AI 25%-50%）

AI在UI视觉的实现，最常见的是 Figma MCP 和直接提供UI的截图。这也是我当前最头痛的问题，我不是很喜欢写UI，但是AI能帮我做的又比较有限。

Figma MCP 本可以提供较好的数据支持，但为什么最终UI输出效果很差？

绝对定位 & 盒子模型：Figma返回的默认数据往往是绝对坐标。Web依赖文档流和盒子模型。把 Figma JSON 喂给 AI 时，AI 看到的是一堆坐标。它必须猜测这些坐标背后的布局逻辑。
设计师的作图习惯：Groups (组)按钮背景和文字组合在一起，API返回的就是两个重叠的图层。AI很难推断。使用Auto Layout，API 会返回明确的 layoutMode, padding 等属性。这是高质量还原的关键。
API 数据的"噪音"与"丢失"：JSON太大，必要的数据清洗；图片与图标复杂的 SVG 不能处理，AI 往往会写一个空的 div 或者放一个img占位符，导致视觉上缺一块。

Vibe 技巧：

核心就是利用figma的MCP，或者直接把标准UI稿图片交给AI，能实现多少，看AI能力。
能较少一定的布局开发成本，整体看AI或者IDE的能力，可是尝试拆分布局实现。
chrome-mcp-stdio 调试UI/报错/网络等问题，可以使用该MCP，也能辅助开发效率。
如果你们能直接导出HMTL，那还是非常不错，由HTML转Vue/React等效果好很多。

所以Vibe Coding在UI开发场景应用流程：

通用组件，业务开发（AI 80%）

核心内容是：完整的技术栈框架和非常全面的业务能力

通用性组件或业务开发，是我们主要的工作量，这里的内容主要是依托某一核心技术栈（Vue/React全家桶）加业务组成。整体代码量非常大，AI肯定是不可能读取所有信息，所以需要你合理的设计和应用。

相较于传统架构，Vibe Coding模式增加了 Rule 和知识库 的依赖，另外如果使用Figma的MCP工具也是开发重点依赖。

目录结构：

为什么要这样设计？

AI需要必要的上下文，所以项目知识文档非常重要
大型项目，AI开发过程中，经常需要拆分任务文档，然后按任务清单完成，需要要一个plan的维护
项目的知识库嵌套，便于快速索引和导入上下文，同时也更好的内聚模块信息。
凡是大型项目，基本上都需要rule，AI在没有合理约束前会有很多问题，生成的结果也不准确。
AGENT.md 适合部分IDE，支持嵌套，AI会自动基于目录层级由子向父递归，读取到上下文。
AGENT.md 一个目录层级只能有一个文件，如果想要多文件，可以使用索引，在AGENT.md 导入其他md文件，同理知识所有文档都可以索引其他内容，如果需要可以设计成统一暴露入口的形式（这样有时候会把不需要的信息添加到AI上下文）。

bash 复制代码

packages/
├── .cursor
│      ├── mcp.json       # 必要的mcp依赖
│      └── rules          # 项目Rule，AI开发规范
│         ├── base.mdr 
├         └── projec.mdr
├── src/                   
│   ├── api/               
│   ├── assets/            
│   ├── components/        
│   │    ├── AGENT.md      # claude code / Cursor IDE
|   │    └── __docs__     # 适合多种IDE
|   |          ├── core   # 核心业务文档，频繁更新
|   |          └── plan   # 开发阶段拆分任务文档，用完可以销毁
│   ├── log/               
│   ├── pages/             
│   │    ├──AGENT.md
|   │    └── __docs__
│   ├── router/            
│   ├── store/             
│   └── utils/             
├── scss/                  
├── __docs__/              # 跟目知识库  
├── vue.config.js         
└── package.json

Vibe 技巧：

文档知识先行：必须先行补充项目核心文档，可以让AI生成，人工审核。尤其是业务文档，在AI的知识里是非常匮乏的（AI是基于网络知识训练，它知道各类技术，但不知你业务情况）。
项目规范和要求rule其后：想让AI在业务里开发出符合规范的代码，必须把项目基本要求告诉AI，可以通过rule生成项目规范（具有通用性，用rule比文档更合适）。
适当使用Figma MCP或者直接提供UI图片：（IDE的Agent一般有多模态识别），让AI完成初版UI开发。
在合适的位置（__docs__/plan）下拆分任务规划文档（可以让AI拆分出来）：将复杂的任务拆分，按任务规划逐步完成。

通用SDK（大型插件/库）（AI 85%-90%）

内容核心：规范化的输入输出，以及标准的开发模式

通用SDK封装和业务类似，但是他有个一个特别显现的特点，标准的对外接口，规范化的输入/输出。因为这个特点，所以导致其在Vibe Coding上和业务开发稍有区别。

相比与上面业务开发，整体架构多了一层TDD驱动开发，我相信在前端这一行，实际开发中的SDK封装，几乎很少有正经去单元测试，集成测试等内容。对于TDD驱动开发也很少实际应用。

如果没有AI，这一层可能基本上缺失，那么为什么Vibe Coding后多了这一层。

第一点：TDD成本极大降低了，不用人工写单元测试
第二点：该类SDK具有标准的输入/输出，非常适合
第三点：AI具有幻觉和不可控性，但基于TDD模式，能够非常好的解决幻觉和不可控，让AI生成代码符合最终测试用例。

Vibe 技巧：

SDK需求文档（人工撰写）：需求阐述/技术栈/边界/兼容性/特殊要求，整体对外的API设计等
让AI进行设计评审：基于需求文档生成设计评审，人工审核其设计思路是否符合要求。
拆分模块和任务：这大的SDK，不可能一次性对话完成（上下文有限），所以按模块拆分非常必要。
进入开发：保持 总 => 分 结构设计，即先生成总体目录结构，然后设计统一的对外暴露文件出口和全部API。
实现API伪代码：有了总的准出，让AI生成API方法占位（函数名+功能注释说明），单个API细节可以后续独立实现。
如果使用TDD模式：让AI编写单元测试/集成测试，保证准入/准出规范，后续流程AI设计得到的结果更准确，经验证，效果非常不错，而且及时差一点的模型，也能出效果
每块功能比较大时，都让AI拆分任务，分步执行。且每次进行代码开发前，要求其必须先总结，人工审核后在开发代码。
代码开发完成后，可以直接用单测或集成测试进行测试，也可以让AI写实际调用代码。
开发测试完成后，在让AI总结复盘，进行自我反思，这样可以很好的回顾代码实现和问题的查漏补缺。
从新整理所有实现文档，提取关机的技术实现/核心API/使用Demo等，反向更新过程文档，作为后续的知识库。
如果本次对话效果很好，让AI回顾整个流程里面，识别高质量和低质量提示词，有助于提升后续书写提示规范

系统性架构

如果你在Vibe Coding中有比较深刻的应用，你会发现如下问题，其实在上面基本都遇到过了，总结一下。

AI存在的问题

AI幻觉，回答的不正确或着答非所问（用词不当/上下文超限等）
开发阶段，AI明显过度设计，缺少明确约束和限制（缺少rule限制）
Agent模式总是直接修改代码，先给设计思路，人工审核在修改代码。
文档总结生成冗余，可以通过rule定义了精简、一般、详细三个标准，精简五代码，一般有伪代码，详细有代码示例
AI开发太快，开代者理解跟不上，让其先说实现思路，人工检测后在开始编码。
AI开发完成时，功能不可用或错误，使用TDD模式或者开发完成后让其自我反思。
每次新开对话上下文都关联不上，缺少记忆，可以使用memory的mcp。人是可以记忆上次开发到哪里，以及记住整体设计方案。由此也引出了下面要讲的完整AI架构