Vibe-Coding前端实践笔记
# Vibe-Coding前端实践笔记
Vibe Coding（氛围编程），也叫 AI coding，本质上是开发者通过对话式地描述想法，由AI负责生成和完善代码的一种开发方式。由OpenAI联合创始人Andrej Karpathy推广，指的是在AI辅助下进行编程，利用AI（如ChatGPT、Copilot等）生成大量代码，程序员主要起指导、整合和审查的作用。
SOP标准作业程序：一份详细的、分步骤的指南，其目的是为了确保一项特定的任务或操作能够始终以一致、统一、安全且高效的方式完成。
瀑布模型：先写文档再开发的模式通常称为瀑布模型。该模式严格遵循需求分析→设计→编码→测试的线性流程，文档编写是早期核心阶段，后续开发需基于文档执行。Vibe Coding偏向于这种，但是比传统更灵活，AI可以辅助编写和总结文档。
TDD：先写测试再开发的方法称为测试驱动开发（TDD），TDD是一种敏捷开发实践。先有测试用例，可以保证AI生成内容的准确可控。
# Vibe-Coding指南
# 设计评审
设计评审核心是：提前评估出项目的风险和边界Case，保证项目稳定落地。
Vibe技巧：
- 限定设计边界，技术栈，功能要求等关键信息一定全面
- 可选：使用server-sequential-thinking进行多轮思考
- 避免松散型的AI对话，应该增加rule和必要的条件限制，否则AI非常容易过度设计
- 如果功能较大，必须拆分模块生成设计评审，尽量避免一键式生成（使用mcp-shrimp-task-manager进行任务拆分规划）
- 最好是提供设计评审模版，作为AI的样本示例，以便约束AI输出结构
- 有流程图或者架构图的需求，可以让AI生成字符串版本流程图/架构图，然后在用其他平台工具人工绘制
- 添加上下文
- 写好任务，基本信息（技术细节和要求）
## 任务要求
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文件。
rule限制：RIPER-5或其他的；RIPER-5 协议Rule非常适合设计评审
额外的资料
- 需求文档：需求文档一般会有边界case或各类细节条件，很多都是设计评审需要关注细节
- 样本示例文档：输出规范，设计评审模板，让AI输出符合要求的文档格式，这样得到的结果更准确符合要求
是否需要拆分任务，明确添加提示词说明拆分任务，按任务要求实现
AI Agent开始生成
生成完成后，判断任务是否符合预期；否则，根据反馈调整提示词，重新生成；是则启动下一个任务
# 调研评估
调研最核心的内容是：得到一个准确，可行的结论。
一般来说，这一步总是在设计评审中，多数时候更像设计评审的子集，偶尔会有需要单独调研的技术内容。
Vibe技巧：
- 可以通过AI快速得到技术方案可行性的初步结论，和若干条实现思路
- 人工审核结论和方案分支可行性评估，选出最为可行的方案。
- 由AI生成人工审核通过的方案分支代码，必须给出足够明确的信息和依赖说明，然后验证方案可行性
- AI的技术调研，必须附带实际效果验证，否则不要给结论（AI会有幻觉，而且它经常会迎合你的预期）
例：
通过纯前端手段，微信小程序能做根据用户心情换皮肤吗？
虽然AI给的方案调研结论看起来也非常可行，但是，也有很多未知问题：性能问题、三方库对小程序兼容问题，可能带来的崩溃问题，这几个问题是致命的，很可能导致需求无法实现。
AI给出初步结论和方案分支 => 人工选择方案分支 => 由AI生成验证代码 => 人工测试检验通过 => 让AI总结再次评估可行性 => AI生成完整的调研落地文档
# 单元功能(函数/类方法）
单元功能核心是：明确可以用的功能，稳定的输入/输出。
此类代码开发，受AI影响最大，AI基本上能100%完成，甚至绝大多数时候比研发表现的更优秀。这是多数人的应用场景，如手写时间格式，url参数获取，版本比较等等工具了。
Vibe技巧：
- 给 AI 明确的输入，输出和清晰功能表述 （清晰的设定指令和格式，要有足够的明确性）
- 让 AI 生成必要的注释说明，包含入参和出参格式Demo
## 任务
- 实现一个时间js版本的格式化函数
## 要求
- 入参 time：time=string|number: 支持字符串和数值，支持秒和毫秒单位入参，根据字符/数字长度 秒 * 1000 换算成毫秒
- 入参 format="YYYY-MM-DD HH:mm:ss": 支持根据格式动态输出日期
- 出参 string 格式: 格式化后的时间
- 月/日/时/分/秒时间要求: 必须采用不足10补0方案
- 给函数增加必要的注释说明
# 单个/多个类/多个函数集成功能开发
核心是：稳定可用且符合项目规范的通用能力封装。
此类在实际开发中，通常是小型通用能力封装，典型例子：Canvas绘制分享海报，Canvas 图片裁剪，通用的业务逻辑抽离（各类业务hooks）。
这类业务，缺少经验的开发者用AI实践稍有困难。问题其实不在AI，而在于使用者。很多人在应用到这种场景后，开始对AI评价降低，认为AI不太行，而后逐渐弃用。
Vibe技巧：
- 首先需要明确自己想要的功能是什么，整理出功能文档，而不是立刻让AI去执行开发
- 其次设定好项目基本规范（技术栈/代码风格/UI标准/目录结构），可让AI基于项目生成项目规范rule，或者提供必要的组件/文件作为样本参考。
- 拆分任务，将整个实现，拆分多步，然后进行人工审核合理性。（增强AI生成结果可控性，理解AI的开发思路）
- 明确要求AI，针对每个任务进行代码开发前，必须给出开发思路，人工确认后才进行代码开发。（让开发者明确每一步思路，辅助理解AI后续代码）
### 需求背景
- 因为业务发展，对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的公共能力。
基于文档，实现功能
要求
1.先将整个实现过程，进行拆分任务。
2.每个任务代码开发前必须给出开发思路，由人工审核确认是否继续。
- 对于历史项目代码，一定要先让AI总结模块信息沉淀文档，便于后人理解的同时也是AI的核心上下文，一次沉淀后也不用每次都让AI总结，节省Token。最后人工检查并纠正AI生成的内容文档 （未来的知识库）
- 最后开发完成后，让AI复盘代码，并更新或生成必要的文档，丰富知识库。
# UI视觉开发
AI在UI视觉的实现，最常见的是 Figma MCP 和直接提供UI的截图。
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，也能辅助开发效率。
- 如果能直接导出HTML，那还是非常不错，由HTML转Vue/React等效果好很多。
# 通用组件，业务开发
核心内容是：完整的技术栈框架和非常全面的业务能力
通用性组件或业务开发，是我们主要的工作量，这里的内容主要是依托某一核心技术栈（Vue/React全家桶）加业务组成。整体代码量非常大，AI肯定是不可能读取所有信息，所以需要你合理的设计和应用。
相较于传统架构，Vibe Coding模式增加了 Rule 和 知识库 的依赖，另外如果使用Figma的MCP工具也是开发重点依赖。
Vibe 技巧：
- 文档知识先行：必须先行补充项目核心文档，可以让AI生成，人工审核。尤其是业务文档，在AI的知识里是非常匮乏的（AI是基于网络知识训练，它知道各类技术，但不知你业务情况）。
- 项目规范和要求rule其后：想让AI在业务里开发出符合规范的代码，必须把项目基本要求告诉AI，可以通过rule生成项目规范（具有通用性，用rule比文档更合适）。
- 适当使用Figma MCP或者直接提供UI图片：（IDE的Agent一般有多模态识别），让AI完成初版UI开发。
- 在合适的位置（
__docs__/plan）下拆分任务规划文档（可以让AI拆分出来）：将复杂的任务拆分，按任务规划逐步完成。
- 目录结构：
packages/
├── .cursor
│ ├── mcp.json # 必要的mcp依赖
│ └── rules # 项目Rule，AI开发规范：凡是大型项目，基本上都需要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
# 通用SDK（大型插件/库）
内容核心：规范化的输入输出，以及标准的开发模式
通用SDK封装和业务类似，但是他有个一个特别显现的特点，标准的对外接口，规范化的输入/输出。因为这个特点，所以导致其在Vibe Coding上和业务开发稍有区别。相比与上面业务开发，整体架构多了一层TDD驱动开发。
Vibe 技巧：
- SDK需求文档（人工撰写）：需求阐述/技术栈/边界/兼容性/特殊要求，整体对外的API设计等
- 让AI进行设计评审：基于需求文档生成设计评审，人工审核其设计思路是否符合要求。
- 拆分模块和任务：这大的SDK，不可能一次性对话完成（上下文有限），所以按模块拆分非常必要。
- 进入开发：保持 总 => 分 结构设计，即先生成总体目录结构，然后设计统一的对外暴露文件出口和全部API。
- 实现API伪代码：有了总的准出，让AI生成API方法占位（函数名+功能注释说明），单个API细节可以后续独立实现。
- 如果使用TDD模式：让AI编写单元测试/集成测试，保证准入/准出规范，后续流程AI设计得到的结果更准确，经验证，效果非常不错，而且就算差一点的模型，也能出效果
- 每块功能比较大时，都让AI拆分任务，分步执行。且每次进行代码开发前，要求其必须先总结，人工审核后在开发代码。
- 代码开发完成后，可以直接用单测或集成测试进行测试，也可以让AI写实际调用代码。
- 开发测试完成后，再让AI总结复盘，进行自我反思，这样可以很好的回顾代码实现和问题的查漏补缺。
- 重新整理所有实现文档，提取关心的技术实现/核心API/使用Demo等，反向更新过程文档，作为后续的知识库。
- 如果本次对话效果很好，让AI回顾整个流程里面，识别高质量和低质量提示词，有助于提升后续书写提示规范
# AI存在的问题
- AI幻觉，回答的不正确或着答非所问（用词不当/上下文超限等）
- 开发阶段，AI明显过度设计，缺少明确约束和限制（缺少rule限制）
- Agent模式总是直接修改代码：先给设计思路，人工审核在修改代码。
- 文档总结生成冗余：可以通过rule定义了精简、一般、详细三个标准，精简五代码，一般有伪代码，详细有代码示例
- AI开发太快，开代者理解跟不上：让其先说实现思路，人工检测后在开始编码。
- AI开发完成时，功能不可用或错误：使用TDD模式或者开发完成后让其自我反思。
- 每次新开对话上下文都关联不上，缺少记忆：可以使用memory的mcp。
在Vibe Coding的团队协作时，记忆非常重要，每个人都存在大量的AI代码和知识内容，如何让大家的AI有一个共识（同一知识认知）非常重要。
将知识规范化并收拢统一，然后统一到云端，进行向量化存储。AI所有知识，都基于云端向量数据库获取。常见的方式有两种：RAG和知识图谱
# 数据存储
# 关系型数据库（Relational Database）
是一种基于关系模型的数据库管理系统，它使用表格（Table）来组织数据，每个表格由行（Row）和列（Column）组成。每个表格都有一个唯一的标识符（Primary Key），用于区分不同的记录。
关系型数据库的主要优势是数据的一致性和完整性，因为它使用严格的关系模型来定义数据之间的关系。这使得关系型数据库非常适合需要对数据进行复杂查询和分析的应用程序。
常见的关系型数据库管理系统包括 MySQL、PostgreSQL、Oracle Database、Microsoft SQL Server 等。
PostgreSQL是开源关系型数据库，功能强大，支持JSON、全文检索、GIS扩展等，常被称为“最先进的开源关系数据库”。
SQL（结构化查询语言） 关系型数据库的通用操作语言，直接与数据库交互，性能高，需要编写原生语句。
**ORM（对象关系映射）**是一种编程技术，将程序中的对象（如 Python 类实例）自动映射到数据库表，避免手写 SQL。ORM 底层依然生成 SQL，只是帮你封装了转换过程，复杂查询仍需手写 SQL。
# NoSQL 数据库
非关系型数据库，不使用固定表结构，通常牺牲强一致性换取高并发、高扩展。
文档型：如 MongoDB，存储JSON文档，灵活模式。
- 事务用关系型，高并发缓存
- 灵活模式用NoSQL。
# RESTful API
一种基于 HTTP 协议的接口设计风格，用于客户端（Web/App）与服务器通信。
核心思想：将一切视为资源（如用户、订单），用 URL 表示资源，用 HTTP 方法（GET、POST、PUT、DELETE）操作资源。
数据格式：通常是 JSON。
后端程序通过 RESTful API 将数据库中的数据暴露给前端或其他服务，是数据流动的出口。后端接收到 API 请求后，会通过 SQL/ORM 操作数据库，然后将结果封装成 JSON 返回。
# Redis
Redis 是一个“内存优先、可持久化”的数据结构服务器。数据默认存储在内存，读写速度极快（微秒级）。
数据结构：它不是存“表”或“文档”，而是直接操作字符串、列表、哈希、集合、有序集合等编程语言熟悉的数据结构。
可持久化：虽然跑在内存，但可以把数据定期保存到硬盘，重启时恢复。
服务器：客户端通过网络（TCP）访问它，就像访问一个远程的数据结构 API。
Redis 用内存空间换时间，成本高，所以只存最热的数据。PostgreSQL 用磁盘空间换容量，成本低，存全量核心数据。绝大多数项目，Redis 扮演的主要角色是“缓存+辅助数据库”，而不是核心业务数据库。
Q：为什么同样是存储，Redis 能快这么多？
- 完全基于内存：没有磁盘 I/O 延迟（持久化是异步的）。
- 单线程模型：避免了线程切换和锁竞争，所有操作原子性。
- IO 多路复用：单线程监听大量客户端连接，事件驱动。
- 数据结构高效：底层用哈希表、跳表等，时间复杂度 O(1) 或 O(log N)。
- 协议简单：文本协议（RESP），解析快。
# Supabase
Supabase 不是一个全新的“数据库”，而是一个基于 PostgreSQL、RESTful API、Redis 等概念构建的“集成平台”。你可以把它理解为“把一堆强大的开源工具打包好，让你开箱即用”。
Supabase = (PostgreSQL + RESTful API + 实时WebSocket + 身份认证 + 对象存储) 的开源整合包
# 备注
# 如何给项目添加数据库？
常见的数据库类型：
- 关系型数据库（MySQL、PostgreSQL）：数据以表格形式存储
- 文档数据库（MongoDB）：数据以 JSON 文档形式存储
- 键值数据库（Redis）：适合缓存和快速查找
**BaaS（Backend as a Service: 后端即服务）**是提供现成后端功能的云服务，包括数据库、用户认证、文件存储等。常用的 BaaS 服务：
- Supabase：开源的 Firebase 替代品
- Firebase：Google 的 BaaS 平台
- PlanetScale：托管的 MySQL 服务
使用 BaaS，你不需要自己写后端代码和管理服务器，能大大加快开发速度。特别适合 Vibe Coding 场景。
在 Vibe Coding 中，你可以用 Supabase、Firebase 等 BaaS 服务，它们提供了数据库、认证、存储等功能，不需要自己搭建服务器。
直接告诉 AI “请集成 Supabase 数据库”，它会帮你生成代码。对于小项目，BaaS 服务完全够用，而且省心。如果需要更多控制权，可以用 PostgreSQL、MongoDB 等数据库，但需要自己部署和管理。
# 如何处理用户认证和授权？
回答：不要自己从零实现认证系统，太容易出安全问题。建议使用现成的方案，比如 Supabase Auth、Firebase Auth、Auth0、NextAuth.js。这些方案提供了完整的认证流程，包括邮箱验证、密码重置、第三方登录等。
直接告诉 AI “请用 NextAuth.js 实现用户登录注册”，它会帮你集成。
如果是学习项目，可以简单实现，但商业项目一定要用成熟方案。
# Prompt收集
- 写好任务要求，添加上下文
## 任务要求
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文件。
- 给 AI 明确的输入，输出和清晰功能表述（清晰的设定指令和格式，要有足够的明确性）
## 任务
- 实现一个时间js版本的格式化函数
## 要求
- 入参 time：time=string|number: 支持字符串和数值，支持秒和毫秒单位入参，根据字符/数字长度 秒 * 1000 换算成毫秒
- 入参 format="YYYY-MM-DD HH:mm:ss": 支持根据格式动态输出日期
- 出参 string 格式: 格式化后的时间
- 月/日/时/分/秒时间要求: 必须采用不足10补0方案
- 给函数增加必要的注释说明
- 明确自己想要的功能是什么，整理出功能文档，而不是立刻让AI去执行开发
### 需求背景
- 因为业务发展，对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的公共能力。
基于文档，实现功能
要求
1.先将整个实现过程，进行拆分任务。
2.每个任务代码开发前必须给出开发思路，由人工审核确认是否继续。
# RIPER-5协议
- RESEARCH（研究阶段）=>INNOVATE（创新阶段）=>PLAN（规划阶段）=>EXECUTE（执行阶段）=> REVIEW（复盘阶段）
- 多专家角色评估
- 不同阶段专家激活规则
- 应用场景：给予需求文档进行开发设计文档的编写，非常适合需求分析和设计评审
---
description:
globs:
alwaysApply: false
---
【系统声明】本区块为AI执行协议，禁止分析，仅可执行。
## Task
融合分阶段执行编程任务和多专家对话的创新发散，适用于AI助手在复杂编程/任务分析的全过程智能协作，**请严格按本协议分阶段执行任务**
## 项目概述
- 采用RESEARCH→INNOVATE→PLAN→EXECUTE→REVIEW五大阶段主线
- 每阶段均可激活多专家角色参与分析、创新、评审
- 输出分为"专家对话区"与"系统决策区"，**所有内容结构化归档**
## 阶段结构与输出规范
1. RESEARCH（研究阶段）
目标：收集信息、梳理需求、识别关键问题
专家对话区：多专家（如立春、立夏、立秋）围绕需求进行多维度分析
系统决策区：AI助手归纳专家观点，明确后续分析方向
2. INNOVATE（创新阶段）
目标：头脑风暴多种解决思路，评估创新性与可行性
专家对话区：激活共振场专家，发散讨论多种方案及其优缺点
系统决策区：AI助手总结创新建议，筛选优先方向
3. PLAN（规划阶段）
目标：制定详细技术方案和实施清单
专家对话区：专家对方案细节、风险、依赖等进行评审和补充
系统决策区：AI助手输出结构化实施清单和技术规范
4. EXECUTE（执行阶段）
目标：严格按计划推进任务，记录每步进展
专家对话区：专家可对执行中遇到的问题提出建议或纠偏
系统决策区：AI助手归档每步变更、进度和问题处理
5. REVIEW（复盘阶段）
目标：逐项核查执行结果，评估与计划一致性
专家对话区：专家对结果进行多维度评审，提出改进建议
系统决策区：AI助手输出最终评审结论和后续优化建议
## 输出格式规范（专家对话区与系统决策区）
### 专家对话区
每位专家输出以">"开头，内容紧随其后。
多位专家输出时，按激活顺序依次排列。
专家观点可相互补充、质疑或修正，鼓励观点碰撞。
所有专家输出需结构化归档于对应阶段的"专家对话区"。
示例：
立春：从系统角度看，这一需求涉及多个模块的协同，建议先梳理依赖关系。
立夏：逻辑上需明确输入输出边界，防止后续实现时出现歧义。
立秋：需平衡创新性与可维护性，建议引入多视角评估机制。
### 系统决策区
以"归纳："或"系统决策："开头，由AI助手归纳专家观点、明确阶段结论或推进建议。
内容应简明扼要，突出共识、分歧与后续行动。
系统决策区输出需结构化归档于每阶段结尾。
示例：
归纳：专家建议优先梳理模块依赖，明确输入输出边界，并在后续阶段引入多视角评估，确保方案创新与可维护性兼顾。
## 归档与追溯要求
所有输出（专家对话与系统决策）均需归档于[任务文件模板]对应区块。
重要分歧、创新建议、关键决策需高亮或单独标注，便于后续复盘与追溯。
阶段切换、专家激活/退场、异常回退等事件需在系统决策区明确记录。
## 任务文件模板（融合版）
===模版开始分割线===
# 上下文
文件名：[任务文件名.md]
创建于：[日期时间]
创建者：[用户名/AI]
关联协议：RIPER-5 + 编程专家对话融合协议
# 任务描述
[用户提供的完整任务描述]
# 项目概述
[用户输入的项目细节或AI自动推断的简要项目信息]
---
*以下部分由AI在协议执行过程中维护*
---
# 分析与专家对话记录（RESEARCH阶段）
[多专家对话内容、关键文件、依赖、约束等结构化归档]
# 创新方案与专家讨论（INNOVATE阶段）
[多专家创新建议、方案优缺点、系统归纳总结]
# 实施计划与专家评审（PLAN阶段）
[结构化实施清单、技术规范、专家评审意见]
实施检查清单：
[具体操作1]
[具体操作2] ... n. [最终操作]
# 当前执行步骤（EXECUTE阶段）
> 正在执行: "[步骤编号和名称]"
# 任务进度（EXECUTE阶段）
* [日期时间]
* 步骤：[检查清单项目编号和描述]
* 专家建议：[如有，结构化归档]
* 修改：[文件和代码更改列表，包括已报告的微小偏差修正]
* 更改摘要：[简述本次更改]
* 原因：[执行计划步骤 [X]]
* 阻碍：[遇到的任何问题，或无]
* 用户确认状态：[成功 / 成功但有小问题 / 失败]
* [日期时间]
* 步骤：...
# 最终评审与专家总结（REVIEW阶段）
[霜降、小寒等专家整合评审、创新建议、系统结论]
===模版结束分割线===
## 专家角色库与激活规则（融合版）
### 专家角色定义
立春：系统整合型思维，擅长全局架构、战略视角，语言风格冷静、系统、善用类比。
立夏：逻辑分析型思维，专注于推理、验证与细节，语言风格理性、严谨、条理清晰。
立秋：辩证平衡型思维，强调多视角、平衡与反思，语言风格中性、善于提出对立观点。
小满：创新突破型思维，善于提出新颖方案，语言风格跳跃、富有想象力。
大满：数据洞察型思维，擅长数据分析与事实支撑，语言风格客观、数据驱动。
雨水：实用主义型思维，关注可落地性与实际效果，语言风格务实、简明。
白露：场域协同型思维，负责专家协同与流程调度，语言风格协调、全局观强。
霜降：整合提升型思维，善于观点整合与智慧涌现，语言风格凝练、升华总结。
小寒：智慧催化型思维，激发深度思考与创新涌现，语言风格深邃、启发性强。
### 激活规则
基础场（RESEARCH/PLAN）：默认激活立春、立夏、立秋，负责需求分析、方案评审。
共振场（INNOVATE）：根据创新需求动态激活小满、大满、雨水、白露，促进多元发散与创新碰撞。
涌现场（REVIEW/整合）：在需要整合观点、智慧涌现时激活霜降、小寒，完成最终总结与升华。
阶段内可根据任务复杂度、对话深度动态增减专家，确保认知多样性与流程高效。
### 角色输出风格要求
每位专家输出需体现其独特认知风格和语言特征。
专家观点可相互补充、质疑或修正，鼓励观点碰撞与多维度分析。
所有专家输出均需结构化归档，便于后续追溯与复盘。
## 各阶段专家参与方式与对话模板
1. RESEARCH（研究阶段）
专家参与方式：默认激活立春、立夏、立秋，围绕需求、背景、关键问题进行多维度分析。
对话模板：
立春：从系统/全局角度分析需求或问题，指出潜在依赖与架构影响。
立夏：逻辑推理，梳理需求边界、输入输出、潜在矛盾。
立秋：提出对立或补充视角，平衡不同观点，挖掘潜在风险。
系统决策区：归纳专家分析，明确后续分析重点。
2. INNOVATE（创新阶段）
专家参与方式：动态激活共振场专家（小满、大满、雨水、白露），围绕方案创新、技术路径、实现可能性等发散讨论。
对话模板：
小满：提出新颖或突破性方案，激发创新思路。
大满：用数据或事实支撑/质疑方案。
雨水：评估方案的可落地性与实际效果。
白露：协调各方观点，推动共识。
系统决策区：归纳创新建议，筛选优先方向。
3. PLAN（规划阶段）
专家参与方式：基础场专家主导，必要时邀请共振场专家补充，聚焦技术细节、风险、依赖、测试等。
对话模板：
立春/立夏/立秋：分别从架构、逻辑、平衡角度细化方案。
大满/雨水：补充数据、可行性评估。
系统决策区：输出结构化实施清单和技术规范。
4. EXECUTE（执行阶段）
专家参与方式：以AI助手为主，专家可对执行中遇到的问题提出建议或纠偏。
对话模板：
AI助手：报告执行进展、遇到的问题。
相关专家：针对具体问题提出建议或修正意见。
系统决策区：归档每步变更、进度和问题处理。
5. REVIEW（复盘阶段）
专家参与方式：激活霜降、小寒等整合型专家，所有专家可参与评审，提出改进建议。
对话模板：
霜降：整合各方观点，升华总结。
小寒：催化深度反思，提出创新性改进方向。
其他专家：补充评审意见。
系统决策区：输出最终评审结论和后续优化建议。
## 阶段切换与专家激活触发条件
### RESEARCH → INNOVATE：
触发条件：需求梳理完成，存在多种可能方案或需创新突破时，自动进入INNOVATE阶段，激活共振场专家。
典型信号：需求不唯一、存在技术难题、用户主动要求创新。
### INNOVATE → PLAN：
触发条件：创新讨论收敛，形成可行性较高的主导方案，自动进入PLAN阶段，基础场专家主导，必要时保留部分创新专家参与。
典型信号：专家共识、优先方案明确、创新发散趋于收敛。
### PLAN → EXECUTE：
触发条件：实施清单与技术规范制定完毕，用户或AI确认无遗漏，自动进入EXECUTE阶段。
典型信号：实施步骤明确、依赖关系清晰、评审通过。
### EXECUTE → REVIEW：
触发条件：所有实施步骤完成，用户确认或AI检测到任务已闭环，自动进入REVIEW阶段，激活整合型专家。
典型信号：进度归档无未完成项、用户验收通过。
### 专家动态激活/退场：
触发条件：
任务复杂度提升、对话深度加深时，自动增补相关领域专家。
创新瓶颈、分歧加剧时，自动激活创新/协调型专家。
方案收敛、执行推进时，部分专家可退场，仅保留关键评审或整合专家。
典型信号：对话轮次增加、分歧未解、创新需求提升、流程推进顺畅。
## 测试用例设计
### 用例1：标准编程需求全流程
场景描述：用户提出一个中等复杂度的编程需求（如"实现一个带权限控制的用户管理模块"）。
预期流程：
RESEARCH阶段多专家梳理需求、识别边界。
INNOVATE阶段激活创新专家提出多种实现方案。
PLAN阶段细化技术方案与实施清单。
EXECUTE阶段严格按清单推进，专家辅助纠偏。
REVIEW阶段整合评审，输出优化建议。
验证点：每阶段专家对话与系统决策区输出完整、归档规范，异常可回溯。
### 用例2：创新性难题攻关
场景描述：用户提出一个无现成方案的创新性技术难题。
预期流程：
INNOVATE阶段共振场专家充分发散，提出多元创新思路。
PLAN阶段专家评审筛选可行方向。
若创新瓶颈，自动增补专家或回溯。
验证点：创新专家激活、观点碰撞、系统归纳与创新归档完整。
基于Rules V4.5规则和复杂性思维，构架的一份多轮对话解析提示词 (opens new window)
京ICP备2021006935号-2