AI 辅助开发分享
-以产品配置系统为例

用固定工作流和清晰提示词,把 AI 真正用进存量业务系统的日常开发里。

向下阅读
01

AI 辅助开发工时节省情况

在 Cursor 辅助下,一阶段 31 项需求实际投入 22 个工作日;同范围按条估时约 49 个工作日。

31
一阶段开发需求(项)
49
常规非 AI 预估(工作日)
22
Cursor 辅助实际(工作日)

工时对比(工作日)

工时节省

02

固定工作流

就产品配置系统项目而言,主要有两种使用场景,需求实现和缺陷修复。良好的实现效果依赖于完善的工作流 + 清晰的提示词。

需求实现 · 从 0 到 1

拿到需求先圈清边界,再让 AI 出方案;确认方案后再开发。

  1. 1
    输入需求
    把做什么、期望效果描述清楚
  2. 2
    明确边界
    若改动涉及现有功能,只改动那些部分
  3. 3
    给出方案
    AI 先给实现方案,不急着改代码
  4. 4
    确认方案
    逐条核对细节与实施步骤
  5. 5
    实现
    按确认的方案实施
  6. 6
    验收
    对照最初需求,确认是否完成
缺陷修复 · 从模糊到准确

修缺陷最怕改一处坏三处。先把问题说清楚,让 AI 定位原因并给方案,确认后再改。

  1. 1
    描述缺陷
    期望 vs 实际,把差距说清楚
  2. 2
    原因 + 修复方案
    AI 定位原因、给出修复方案
  3. 3
    确认方案
    核对原因与修复范围,确认后再改
  4. 4
    修复
    只修复必要处,避免带出新问题
  5. 5
    验收
    测试修复效果,确保修复完成,也没改坏别的
共同关键 逐条核对方案细节与实施步骤,确认后再动手。这是避免返工最重要的一步。
两者区别 需求是从 0 到 1,缺陷是从模糊到准确。需求先明确边界,缺陷先讲清哪里错了
03

提示词强弱对比

具体实施上,对于同一个目标,不同的提示词实现的效果可能相距甚远。

弱 · 未明确边界和效果

把类目详情页面的 UI 优化一下

没说改哪:详情页整页都能动,范围太大

没说不能动:树展开、接口这些业务逻辑可能被顺手改掉

没说做成什么样:「优化」没有验收标准,改完后发现达不到预期

强 · 明确边界 + 预期效果

修改类目详情页的数据展示方式。只改类目详情页的 UI 展示部分,树结构展开功能等业务逻辑接口不变。数据换为 table 列表展示,类目列居左,操作列居中,操作按钮和类目名称添加 hover 效果,hover 时字体变为主题色。

先确定修改范围:只改详情页展示,树结构和接口不动

明确修改方式和预期效果:改成 table、列对齐、hover 时字体变为主题色

做需求,可以这样问

开发哪一部分?新增什么模块

哪些不能动?树结构、接口这些业务逻辑不动

需要什么样的效果:列表怎么排、hover 什么效果

有效果示例图更好:能够准确描述预期效果

修缺陷,可以这样问

期望是什么?本来期望的样式、布局应该怎样

缺陷原因?布局错位、和整体风格不搭等

附上具体正确 / 错误样例:哪一个接口返回格式应该是什么样,哪一个按钮点击展现效果不对

04

UI 优化需求:按工作流完整跑通

从一句需求出发,先出设计规范和可点原型,确认后再分页落地。

帮我把产品配置系统的 UI 改一下。先别动业务代码,出个设计规范和可点原型给我,确认后再分页落地。

功能、接口、路由都别变,只调视觉和交互。主色 #00246e,别用蓝紫渐变;圆角小一点,阴影只在浮层用。
范围就登录、用户管理、类目管理、价格管理这几页。
输入需求 一句话讲清范围 给出方案 设计规范 + 可点原型 确认方案 主色、布局、页面范围 分模块实现 登录 → 布局 / 列表页 验收 功能与视觉核对
案例配图

老系统

改前
老系统

新系统

改后
新系统
05

修缺陷:从模糊到准确的一次实战

产品名称没跟随语言切换。把现象、复现步骤和截图一次说清,再让 AI 定位原因。

描述现象 期望 vs 实际 贴截图 复现步骤 + 接口响应 缩小范围 只改名称映射处 迭代验收 复测语言切换
产品名称在产品配置列表里显示异常:期望是跟随系统语言环境显示对应语言的产品名,实际切换语言后仍是默认语言。

复现步骤:登录 → 产品配置 → 产品列表 → 切换语言 → 产品名称未跟随。
涉及界面与接口响应两处,账号:admin / 测试环境,截图见右侧。
经验 截图越全定位越快;只改必要处,避免改一处坏三处。
缺陷案例配图

现象 → 截图,配合复现步骤与接口响应,一次把问题说清。

06

未来持续探索 AI 使用新方向

学习新的 AI 使用技能,进一步提升工作效率。

经验 → 规则 → 复用
基础建设

沉淀通用规则,封装为 Skill / 规则包

把高频复用的内容固化下来,形成可移植的资产:

  • UI 风格规范:组件库选型、颜色体系、间距栅格、字体标尺,写进规则文件,新项目一键加载
  • 提问模板:需求分析、代码生成、Bug 定位、代码审查,沉淀标准提问格式,减少对齐损耗
  • 发版检查清单:环境变量、接口地址、构建产物、回滚预案,固化为可执行检查项

做法:每做完一个项目,抽取出可复用的部分,归入个人 / 团队规则库;新项目启动直接加载,不用从零磨合。

高级用法

探索多 Agent 协作,提升复杂任务处理能力

单 Agent 有上下文窗口和注意力局限,复杂任务容易顾此失彼,多 Agent 的价值是分而治之:

  • 拆分策略:需求分析、方案设计、代码实现、代码审查,各司其职,串并行结合
  • 协作方式:串行接力(设计→编码→审查)、并行分治(前后端同步)、交叉验证(对比结果找差异)
  • 知识库 + RAG:接口文档、业务约定、技术选型建进知识库,执行前先检索,减少幻觉和反复对齐