继续我们的AI编程专栏，这次是一个实际的项目开发，将整个开发流程和经验进行总结分享，因为是边开发边探索Cursor，有些东西不一定成熟，但也算是完成了一个真正使用AI完成了复杂项目设计。
整个过程也可以说无一份手写代码，一些Bug修复也完全交给AI来完成，接下来让我们进入正题。
一、需求
1.1 需求背景
-
团队内有很多图生图，图生视频玩法，但因为一些历史原因，这玩法是逐步形成的，在前端-后端-智能化各职能线不是很统一，每次接入成本高。
-
玩法需要上传图片资源，导致资源与账号绑定了关联性，其他合作伙伴没法直接接入
-
另外玩法可能需要对图片进行编辑和操作，所以在此基础上还要设计一个通用的基础图片编辑器
1.2 目标
-
FE测封装独立的SDK，对外提供SDK，通过SDK的能力达到三方快速接入的要求
-
Server和智能化同样抽离业务，独立通用能力，将上传图片与账号解耦，直接使用CDN的形式，无需登录
-
探索基于Cursor的AI编程开发和效率提升，快速原型验证
二、前置条件
- 业务细节不说，这个是隐私，只说整个开发流程和设计思路
- 在设计此SDK之前，对Cursor的使用没有系统的研究过，算是随便用用的状态
- 需求表述本身也比较简单，没有明确的需求文档，只有几个大的核心诉求
- 本次的目标也是基于这个SDK和Cursor进行系统性的验证编程效果和开发效率
三、新项目全流程
3.1 第一步 细化需求文档
不管啥编程，首先要需求明确。像这种技术性探索 + 研发提效的需求，更多的需要研发自己明确需求细节，所以第一件事情就是写需求文档。
我按照如下需求的期望，简单阐述了我的需求预期文档，但是并不详细，没有提供太多设计思路和技术方案约束。
3.1.1 SDK玩法模块文档
- 上传模块：接入三方对象存储，支持上传图片（文档内附三方接入文档地址）
- 任务模块：上传图片后需要调用制作，因为图生视频耗时长，一般是异步任务
- 网络请求模块：毫无疑问得调用接口，不管是自己写还是用Axios都得封装一下。
- 错误处理模块：SDK的通用错误处理，异常错误捕获等。
3.1.2 图片编辑器模块文档
- 编辑器模块：基本图片编辑器说明，技术使用和依赖。
- 编辑器工具条模块：说明应该具备哪些工具条（涂抹，画笔，擦出）
- 编辑器画布模块：画布能力说明，拖拽，缩放等。
3.1.2 DEMO演示和调试模块文档
- 使用vue3进行模块构建
- 都掩饰测试哪些功能等等
3.2 第2步 让AI产出设计方案&人工审查
有上面的粗力度的需求后，我接下来让AI产出整个需求的详细设计方案。因为需求里我肯定思考不全面，而且也没有技术实现细节。所以我让AI详细的输出了设计方案，然后在人工审查合理性。
3.2.1 如何产出好的设计方案
在这一步我开始Cursor的深度使用，开始使用高级功能rules。
- 我用一个现成的且认可度较高的框架模式，让AI对本次需求产出了设计方案文档
- 产出后，人工审查了他的设计思路方案和技术选型等，但是因为我没有过多约束，导致有些技术选型和方处理不太合适，我有进行了几次文档更改和更新
Cursor论坛:
forum.cursor.com/t/i-created...
linuxdo:
提示词示例:
markdown
1. RESEARCH（研究阶段）
目标：收集信息、梳理需求、识别关键问题
专家对话区：多专家（如北辰、天权、天枢）围绕需求进行多维度分析
系统决策区：AI助手归纳专家观点，明确后续分析方向
2. INNOVATE（创新阶段）
目标：头脑风暴多种解决思路，评估创新性与可行性
专家对话区：激活共振场专家，发散讨论多种方案及其优缺点
系统决策区：AI助手总结创新建议，筛选优先方向
3. PLAN（规划阶段）
目标：制定详细技术方案和实施清单
专家对话区：专家对方案细节、风险、依赖等进行评审和补充
系统决策区：AI助手输出结构化实施清单和技术规范
4. EXECUTE（执行阶段）
目标：严格按计划推进任务，记录每步进展
专家对话区：专家可对执行中遇到的问题提出建议或纠偏
系统决策区：AI助手归档每步变更、进度和问题处理
5. REVIEW（复盘阶段）
目标：逐项核查执行结果，评估与计划一致性
专家对话区：专家对结果进行多维度评审，提出改进建议
系统决策区：AI助手输出最终评审结论和后续优化建议3.2.2 改进思路
- 可以尝试 sequential-thinking 的MCP服务进行思考设计
- 让AI技术设计产出前，应该给AI更明确的技术选型和技术栈限制
3.2.3 结果情况
- 这个过程经过人工审核处理后，最终得到了完整的设计方案
3.3 第三步 将设计文档拆分任务
因为SDK开发体量是比较大的，加上需要引用文档或者通过对话调试修改，上下文肯定会不够用，所以拆分任务就非常必要
- 拆了四篇文档代表四个大任务，base项目结构基础、core-service 上传和任务、example 示例代码、image-editor图片编辑器
- 基于四大模块，我又按照模块进行子任务拆分，此时拆分的任务已经是需求功能描述阶段
3.3.1 此间问题
-
文档需要人工审查，而且有些东西没必要，发现AI明显过度设计，因此我也做了禁止过度设计要求，并去掉了明显不需要的内容（国际化）
-
在不断输出完善文档这段时间，逐步发现了一些AI问题，并且加了rule限制。（AI直接输出代码-明确rule限制代码输出，先询问后编码你也可以切换到ASK，但我觉得不方便；文档总结冗余-通过rule定义了精简、一般、详细三个标准，精简五代码，一般有伪代码，详细有代码示例；）
3.3.2 改进思路
- 开发时，任务拆分我一直采用人工+AI对话进行控制拆分，但这里可以考虑使用 mcp-shrimp-task-manager 拆分任务
3.4 第四步 进入开发
开发一定要有条理性，保持先建设骨架，在填充细节的设计思路。这样做的主要目的是，避免因为上下文限制导致的超限，丢失问题。
流程如下
ruby
=> 基于项目基准文档初始化目录结构
=> 基于模块文档初始化模块文件
=> 基于模块实现SDK出口，对外导出方式
=> 基于模块详细设计模式实现API伪代码（提供API方法占位）
=> 拆分功能任务，按顺序实现API能力
=> 完成开发后运行测试
=> 让AI系统的review一下整个实现，查漏补缺
=> 输出使用文档和项目实际实现的设计文档
=> 如果本次对话流程顺利，效果很好，让AI回顾整个流程里面，高质量和低质量提示词，有助于提升后续书写提示规范
=> 最后，夸一夸AI，摸摸头3.4.1 初始化项目结构
-
结合上面提到的base-design文档，初始化项目基础结构，完成基础框架。
-
此步骤完成，我们SDK的整体结构基础已经奠定，技术栈和开发阶段的工程搭建全部完毕（vite，vue，ts配置等等）。
此间问题
-
当我让AI根据这些文档进行功能实现时，AI毫不犹豫的开始创建，直接完成了一个大模块功能， 但是我发现有些非预期的内容，修改了好几次。
-
AI 一顿输出，产出了大量代码，我不知道他要实现的节奏和思路是什么，代码开发完我自己完全不熟悉。
改进思路
-
进入开发阶段，我们必须使用Agent模式，但是你需要通过提示词禁止AI直接编码 ，而是让其先说实现思路，人工检测后在开始编码，这样我清晰的知道AI要设计什么，同时对于不需要的内容（国际化）我也能清晰看到 ，让其编码时直接去掉不实现，对此我增加如下rule。
对于任何要拆分任务，逐步实现的能力，在进行代码编写前，简要概括总结实现内容。
-
当其给出实现思路时，再拆分任务分多步执行 （此时不用输出文档），核心目标避免AI一次性实现大段功能。如果有错误不符合预期浪费上下文不说，还会打乱思维。
3.4.2 按模块实现功能
-
从项目功能来看，我要实现的模块有三个，core-service 和 image-editor 和 example
-
我优先开始实现core-service模块，因为上一步初始化了项目结构，同时各个模块都有文档，即使一个core-service模块实现超越了上下文限制我也不用担心开启新对话AI会无法理解。
此间问题
-
在core-service开发阶段，从设计文档到自身，没有明确先定义好结构的概念，直接由AI设计，AI充分发挥了过度设计的特点写了一堆无用代码(SDK应该暴露哪些API，哪些方法和SDK的导入方式，没有提供伪代码)
-
在实现image-editor时，我改进了问题，整体流程非常顺利，唯独出现了一个fabric版本AI使用错误问题。
改进思路
-
让AI在设计阶段，根据自己的需求，给出明确的对外API提供和导入导出方式，如果自己不知道暴露什么，可以让AI根据需求给建议提供方式，在剪枝筛选。
-
当你有对外API的伪代码时，有些功能，AI甚至只需当前文件上下文就能分析出如何实现。
-
针对API使用错误问题，当然要使用context7的MCP来解决啦，非常好用。
-
另外在image-editor开发阶段，**采用了自我审查回顾能力，**对于重要功能开发完成后，让其自查。
3.5 开发完成测试
-
整体功能开发完成后，让AI进行打包构建测试
-
编写example模块，测试功能使用是否正常符合预期
-
如有问题逐步调试解决，调试功能建议新开聊天对话，不要混乱上下文。
3.6 系统回顾
-
让AI系统回顾功能实现，分析当前实现是否完善，有哪些不足（荣誉代码），有哪些优势（鲁棒性，拓展性）
-
让AI总结提示词，并更新到关键文档位置，也方便后续优化提示内容
3.7 总结更新文档
-
这一步尽量在开发中，实时更新一些必要内容，更新文档可以单起对话，避免浪费上下文
-
我个人设计时，明确要求的双目录结构映射，文档和项目模块，分别咋packages和design两个文件夹保持对称。
3.8 总结一下
机遇上面遇到的问题，逐步改进，终于在实现第二个模块，image-editor 模块时，非常的流畅且高质量的完成开发。
- AI有足够的能力设计大型框架，只要拆分好任务，维护好必要的文档。
- 大型项目文档和rule非常需要，而且非常重要，直接影响产出质量
- 拆分子任务文档，避免一次性输出大量代码
- 禁止AI直接写代码，先分析总结，由于人工确认
- 要求AI避免过度设计，精简代码书写方式
- 优先完成对外API伪代码实例，提前占位类和方法
- 使用MCP进行任务管理以及对三方库文档引用
- 让AI自我审查，对重要功能自我review。
- 可以同时打开多个对话，彼此相互独立，保证一个对话只做一个核心相关的功能，避免多功能混合上下文
- 重要的功能完成开发，非常有必要让AI自我回顾检查
四、历史项目改造
很多人说历史项目不适合使用AI，历史包袱严重，其实本质原因是文档不健全。历史项目用AI改造其实很简单，我一般分三步。
4.1 第一步 生成项目rule
-
没什么技巧，AI一键直达，直接针对项目生成rule，此时你就得到项目的初步的文档。
-
一些业务文档，或者UI规范，UI搞尺寸映射到开发rem或vw使用比例情况，需要自己补充说明。
4.2 人工审查改动rule
上一步rule生成只是AI的理解，总会有偏差，需要人工审查修正，甚至补充一些核心依赖。
-
这里我建议将rule提出来转成项目文档，放到统一的项目结构里面，随着业务开发增多，文档也会越来越多。
-
rule更偏向AI理解的提示词，业务功能介绍文档更偏向人理解文档，建议rule放核心通用基础提示规则。
4.3 随功能迭代
当这些基础文档具备后，就可以进入正常的业务开发，AI能通过文档理解项目结构。
-
当开发功能时，把必要的项目结构文档喂给AI上下文，然后在分析业务代码进行开发。
-
如果此业务非常重要，还可以让AI沉淀该业务到项目文档里，方便后续AI直接使用。
五、一次非常成功顺利对话
Designing image editor SDK structure
Exported on 2025/6/18 at GMT+8 20:48:50 from Cursor (1.1.3)
对话 1
这里提示词使用明确要求，给出设计思路，伪代码，更新文档，但是不做代码编写
User
结合module-base-design了解项目结构，在image-editor下设计图片编辑器能力SDK。
结合module-image-editor-disign 和画布模块设计文档，总结你的设计思路，给出关键性的对外API和SDK初始化伪代码。并更新三篇文档内容。本次不做代码编码。
Cursor
好的，以下是我的设计思路总结、关键对外API与SDK初始化伪代码，并说明三篇文档的更新方向。请确认输出形式（精简-一般-详细），如无特别说明，默认采用"一般"模式。
......
......
设计思路总结
- 项目结构与分层
- 画布核心
- 图像编辑与标注
- 交互与UI
- API 设计原则
关键对外API（伪代码）
- coding 伪代码，重点是这里，伪代码实现
......
......
对话 2
上面审查通过，让AI继续编码
User
直接更新
Cursor
......
......
文档末尾新增"任务拆分清单提示词（AI开发专用）"章节，内容涵盖：
- 类型系统建设
- 画布核心模块
- 图像编辑模块
- 标注工具模块
- 交互控制模块
- UI组件模块
- 工具函数与事件系统
- 主编辑器类与工厂方法
- 单元测试与集成测试
- 文档与示例
每一项均为后续 AI/团队开发和任务分配提供结构化、可执行的拆分提示词，便于逐步推进代码建设。
如需针对某一模块进一步细化开发子任务或输出详细开发指令，请随时告知！
对话 3
因为我做rule和需求文档了里明确了任务拆分清单和每次开发前先总结实现思路，完后回顾实现，所以AI按照任务逐步往下执行，总是优先询问，而不是直接编码。
User
按照任务清单，完成第一个任务
Cursor
......
......
第一个任务"类型系统建设"已完成，具体内容如下：
- 画布配置（CanvasConfig）
- 编辑器配置（EditorConfig）
- UI 配置（UIConfig）
- 主配置（ImageEditorConfig）
- 事件类型（ImageEditorEvent）
- 滤镜、图像调整、导出等常用类型
类型定义结构清晰，便于后续各模块开发时直接引用，保证类型安全和 IDE 友好。
如需继续推进下一个任务（如画布核心模块开发），请直接告知！
对话 4
User
下一个任务
Cursor
......
......
编写基础单元测试（如有需要）
......
......
对话 5
因为是内部SDK，不是通用的框架，功能还没要复杂到需要单元测试，所以我直接去掉了。这就是分步 + 询问 + 开发前讲思路的好处，你能选择接下来要做什么，不做什么
User
编码，直接放弃单元测试模块
Cursor
......
......
至此，image-editor SDK 主体架构与各核心模块的 TypeScript 代码骨架已全部完成。如需继续推进文档、示例或某模块的具体实现细节，请随时告知！
对话 6
AI自我检查回验，排查问题或设计不合理的地方
User
回验证本次功能实现，是否正常可用
Cursor
根据本次 image-editor SDK 及 demo 的实现流程，回顾和验证如下：
......
......
结论
本次功能实现整体结构、API 设计、集成方式均已打通，demo 代码可正常运行和调用主要接口，具备良好可用性和可扩展性
......
......
对话 7
我遇到的三方库使用API不准确的问题，这个时候用context7做了调优校准
User
继续开发，使用context7
Cursor
......
......
对话 8
项目设计完成，再次自我检查，回顾设计合理性，以及查漏补缺
User
回顾一下，是否有遗漏任务未完成
Cursor
根据本次 image-editor SDK 的设计与开发任务清单，结合你的需求和每一步的推进，现对已完成与待完善的任务进行回顾：
......
......
已完成的主要任务
- 类型系统建设
- 画布核心模块（canvas）
可能的遗漏或可选后续任务
- 更丰富的 UI 组件/面板实现
结论
本轮开发已完成所有核心功能和主线任务，SDK 具备文本标注、画笔涂抹、撤销重做、UI 交互等完整链路
......
......
对话 9
给予认可，让其分析本次的提示词和工具使用上，优点和缺点，方便沉淀提示词，总结经验
User
在这次对话中，你设计和回答非常棒，基本上都在预期输出范围内，能给我总结哪些 rule或文档或提示词，让你理解的非常准确么。
Cursor
非常感谢您的认可！让我分析一下这次对话中哪些规则和文档让我能够准确理解并执行任务：
最有效的提示词特征
- 明确的架构约束 - 双目录结构、模块边界
- 具体的技术选型 - TypeScript + Vite + Fabric.js
- 版本化的增量更新 - v0.1、v0.2标注
- 边界明确的功能范围 - 仅文本标注、画笔涂抹
- 结构化的API示例 - 工厂方法、事件系统
- 兼容性预警机制 - 主动考虑技术风险
- 询问确认机制 - 避免过度设计
这些规则的组合让我能够：
- 准确理解项目架构和技术边界
- 按照既定模式进行模块化开发
- 主动识别和解决技术问题
- 保持文档与代码的同步更新
- 在适当时机询问确认，避免偏离需求
对话 10
坏的地方也要分析，后续减少或者避免再次出现
User
是否存在模糊，歧义不清晰部分，给出优化建议
Cursor
......
......
立即优化（高优先级）
- 明确技术选型版本号，避免兼容性问题
- 统一事件命名规范，提高API一致性
中期优化（中优先级）
......
......
长期优化（低优先级）
......
......