AI编程全流程实践探索
·
前后端项目、设计稿、需求文档放入到一个git仓库。
project-all/
├── prd/ # 产品需求
├── designs/ # 设计稿（Pencil）
├── frontend/ # 前端
├── backend/ # 后端
├── ... # ...
└── CLAUDE.md # AI 辅助开发指南
每个环节的实践
| 环节 | 产品概念 | 需求分析 | 页面设计 | 需求拆解 | 技术方案 | 后端实现 | 前端实现 | 前后端联调 | CI/CD 流水线 |
|---|---|---|---|---|---|---|---|---|---|
| 工具 | Cursor+GIT | Brainstorming Skill + ASCII-design Skill + Pencil | Cursor + Pencil / frontend-design skill | Cursor + speckit | Cursor + speckit | Cursor + speckit | Claude code + speckit | Claude code / Cursor + Super powers | Claude code |
| 协作 | - 使用Cursor调研主流互联网&科技大厂提供的福利及系统平台（1h） - 通过飞书 MCP 的 update-doc 接口将 Git 管理的 Markdown PRD 自动同步至飞书 Wiki，供非技术成员阅读和评论- 采用「Git 为源、飞书为镜像」策略，每次 PRD 版本升级后执行一次同步 |
- 采用「约束先行 + 一问一答 + 选择题」的 Brainstorming 模式，将模糊的产品想法在 2 小时内结构化为 640 行、V1.0 的产品需求文档 - 通过 4 个文档、多轮对话的增量迭代（不推翻重来），PRD 演进至 V1.2，覆盖完整的异常处理、角色权限矩阵、页面-接口映射表 - 引入状态矩阵、页面结构表、元素清单等结构化描述范式，PRD 精确度显著高于传统文字叙述方式 - 在 PRD 生成 Prompt 中加入验收标准约束，可让 PRD 天然具备 TDD 基础 人效/质量突破：传统 PRD 撰写 3–5 天 → AI 协作 2 小时，提速约 10 倍；状态穷举完整度接近 100%，大幅减少开发阶段的需求澄清 |
- 将 PRD 页面结构表直接作为 Pencil 的生成 Prompt，零翻译成本从需求直达设计 - 按「全局框架 → 逐页打磨 → 缺失页面补充 → 统一风格」4 阶段渐进生成 24+ 页高保真设计稿 - 建立 30+ 设计变量（ $primary: #FF6900、$text-primary、$radius-md 等），改一处全局生效，设计变量直接映射前端 Tailwind CSS 变量人效/质量突破：传统设计 5–10 天 → AI 协作 4 小时，提速约 10 倍；设计与 PRD 高度一致，视觉走查问题减少 70%+ |
在Cursor中直接输入用AI生成的PRD以及原型设计 - 使用speckit.specify拆解需求（0.5h） - 使用speckit.clarify澄清需求（0.5h） - 线下疑问答疑（0.5h~1h） |
在Cursor中直接输入AI生成的PRD以及原型设计 - 使用speckit.plan生成技术方案 - 使用speckit.plan澄清技术方案 |
- 技术栈：JDK 1.8、Spring Boot 2.3.11、MyBatis-Plus、MySQL、Redis、FDS、CAS；DDD + 六边形架构，多模块 Maven（luck-common / luck-infra / luck-application / luck-interface） - 按「页面 → 接口」推导模式，从 PRD 交互描述自动推导 34 个接口的完整契约，包含请求/响应完整 JSON 示例、错误码矩阵、幂等性设计、业务逻辑说明 - 通过Gap 分析（PRD 接口清单 vs API 契约交叉校验），发现并补充 10 个遗漏点（评论点赞、订单验货 2 个关键接口 + 多个字段缺失），最终产出 36 接口、2500+ 行契约文档 - 双向同步机制确保 PRD 与 API-CONTRACT 始终一致 人效/质量突破：传统接口文档 2–3 天 → AI 协作 1 小时，提速约 15 倍；接口覆盖率显著提升，联调阶段需求澄清减少 |
- 将 13 个页面拆分为 30 个独立任务（Task），每个任务明确文件范围、实现步骤、验收标准，采用**TDD（测试驱动开发）**模式，先写测试再实现 - 技术栈：React 19 + TypeScript + Vite 8 + Ant Design Mobile + Tailwind CSS + Zustand，完整实现首页推荐流、商品/活动/福利详情、下单支付、搜索、米粒转赠弹窗、我的中心、订单列表等全链路页面 - Mock 先行可替换策略：先用 Mock 数据跑通全链路，再逐服务替换为真实 API，每步均验证 TypeScript 编译通过 - 通过 Playwright 编写自动化录屏脚本，用于演示视频生成 人效/质量突破：传统前端实现 5–8 天 → AI 协作 3 小时，提速约 10 倍；TypeScript 严格模式 0 报错，组件覆盖率高 |
在Claude code输入接口文档 + 知识库文档 - Writing-plans skill 生产开发计划 - Executing-plans skill 执行计划 - subagent-driven-development 子代理执行 - Test-driven-development skill 测试驱动开发 |
本仓库为单体仓库，前端与后端同库，构建与部署产出两个独立制品：前端静态资源 + 后端 API 服务 - 前端：浏览器访问 H5 页面（由 Nginx 提供静态资源）。 - 后端：提供 REST API，供前端通过 /api 前缀或同一域名反向代理访问 |
| - 桌面研究主流企业解决方案或找对应企业（原）雇员调研（4h~6h） - 对目前已有功能现状进行调研分析输出报告（6h~8h） |
- 根据调研结论形成原始需求BRD文档（6h~8h） - 通过BRD文档转化为PRD文档大纲（6h~8h） - 如BRD来源用户，则需要花费更多时间沟通确认BRD细节才能转化为PRD |
- 将PRD与设计侧进行沟通并确认设计规范（6h~8h） | - PRD完成后需进行一阶段"产品内审"、二阶段"用户评审"、三阶段"研测评审"、四阶段"高危元素评审"（按需）（8h~16h） - 每阶段审核无法保证一搞过，还需优化后多次上会评审直到统一共识 |
- 线下与产品侧多次澄清需求，根据MIT技术文档规范编写技术方案（1+ 人天） | - 生成代码、接入三方服务、沉淀通用能力（1+人天） - 需求变更带来的细节改动与调整（1+人天） |
- 前后端同一个工程，不同目录来区分 - 从零到可开发状态的工程骨架、依赖、分层、配置等由人工基于 MIT 脚手架完成 |
|||
| 优点 | - 调研覆盖度： 横向了解头部互联网大厂的业务发展方向， 纵向解构同类产品的产品功能，为拆解产品架构和功能提供输入 | - 信息无损：用 Markdown/结构化文档替代飞书 PRD，AI 更易理解，不丢失关键细节 - 所见即所得：需求变更可即时得到结果，PRD、线框图、设计稿可联动更新，快速验证 - 智能探索：自动读取 README、配置、Git 提交、技术栈，主动探索项目上下文 - 结构化对话：头脑风暴式逐问澄清，提出 2～3 个可行方案并说明优劣 |
- 链路缩短：产品/研发直接与 AI 对话生成设计稿，节省设计工时 10+ 人天 - 即时响应：需求变更时设计稿可即时变更，减少与设计、研发、测试的沟通成本 - 下游友好：Pencil 生成 AI 可识别的 JSON 设计稿，减少 Figma 等信息损失，开发可 1:1 还原 |
- 降低对人的依赖：AI 结合 PRD 和设计稿拆解需求，由传统人沟通变为与 AI 对话 - 效率提升：AI自动识别和定义问题，通过对话不断澄清并给出结构性建议，需求理解减少2+人天 |
- 效率提升：AI自动化生成&调整技术方案，节省工时3+人天 - 即时响应：需求变更时，可即时变更技术方案，快速响应需求 |
- 人天缩短：自动生成接口方案与后端代码，节省 20+ 人天 - **即时响应：**需求变更时，可即时变更接口方案和后端代码，快速响应需求 |
- TDD 保障质量：先写测试再实现，AI 生成代码更规范，显著降低缺陷率 - 并行加速开发：subagent 并行执行独立任务，节省前端开发 10+ 人天 - PRD 直接驱动：区域→组件→数据三列表格零翻译成本直接生成组件 Props - verification 兜底：完成前强制 build/lint/test 验证，杜绝静默失败 - 设计稿 1:1 还原：Pencil 生成的设计稿直接映射为 React 组件结构 |
- 质量保障：采用测试驱动开发，保障了代码质量，提升测试的效率，同时在更短的反馈周期内验证和改进代码 - 联调自动化：AI 驱动联调与测试，减少沟通成本，节省 6+ 人天 |
打破传统前后端分离模式，探索适合AI的全栈方式： 1. 前后端代码统一仓库管理，分别走不通的流水线部署 1. 统一管理，避免需求变更导致的信息不同步 |
| - 输出结论受模型学习日期（互联网信息资讯）影响，并非当下最新信息 - 无法给出符合特性的调研结论，做什么、怎么做… |
- 多人协同分别编写PRD再合并，未在统一的格式化文件中管理，需求容易冲突、遗漏，精确告诉 AI「源文档是什么」「放到哪里」「影响哪些章节」 - 为统一固定PRD规范格式的情况下，不同人通过对话生成的内容结构不同，对于人的阅读不友好 |
- 人工难以介入：Pencil难以支持人工介入调整控件的操作，强依赖对话式生成和更新设计稿 - 多人协同冲突：多人协同时若先按照PRD各自生成设计稿时，命名、组件、样式容易不统一，需要先建立统一的导航、布局、主色等规范框架后 - 工具能力较弱：Pencil无法支持复杂的不规则图形、渐变等设计，不支持外部图片导入使用，不具备figma高阶设计的工具能力，难以1:1还原截图 |
- 在做之前一定要充分的做好需求调研和历史业务逻辑梳理，才能避免后期很多问题 - 还是需要线下沟通，无法做到除用户外的零沟通 |
- 上下文与跨模块约束：多模块时单次对话上下文有限，可能遗漏跨模块约定，需靠 Skills 与显式引用补齐 - Skills 与文档需持续维护：随项目演进易过时，需约定“改代码同时改文档” - 过度设计风险：AI 生成技术方案存在过度设计风险，需人工把关非功能性需求（性能、安全、可维护性） - 规范与设计需人工把关：Speckit 产出需评审修正，技术设计仍以人工为主、AI 辅助 |
- 文档与代码易不同步：需求或接口变更后未及时更新文档时，AI 依赖的上下文会失真 - 首期搭建有成本：建立规范与 PRD→SPECIFICATION 链路需一次性投入，小项目可能觉得偏重 |
- AI 难以感知设计稿细微视觉差异，需人工验收像素级还原 - 复杂动画、手势交互等场景 AI 生成代码质量不稳定 |
- 联调过程中接口异常需人工定位，AI 自动化测试覆盖边界 case 能力有限 - mock 数据与真实数据存在差异，自动发现能力仍有不足 |
- 未能全部由 AI 生成代码：项目搭建、工程骨架和规范等由人工（MIT 脚手架）完成，只有业务逻辑等部分由 AI 生成，整体代码并非 100% AI 生成。 | |
| - Step1：想为谁提供什么服务、解决什么问题，调研行业现状、主流平台、产品架构、核心功能 - Step2：认为哪家产品功能更符合预期进行深度切片 - Step3：结合差异点和创新点提问，生成调研报告 |
- **约束先行，功能后谈：**先给平台、品牌、导航约束，再讨论具体功能，避免后续大面积返工 - **一问一答，选择题优先：**Brainstorming 每次只问一个问题，用选择题加速决策 - **分节呈现，逐节确认：**200-300 字一节，确认后再下一节，错误不会传播 - **表格比段落精确 10 倍：**页面结构用「区域-内容」表格，交互用「状态矩阵」，卡片用「元素清单」 - **穷举状态组合：**按钮有几种状态、弹窗有几种触发条件——用表格穷举，开发不遗漏 - **增量深化而非推翻重来：**V1.0 → V1.1 → V1.2，每次在现有结构上增量扩展，保持文档一致性 - **合并时指明来源和目标：**多文档合并时精确到「源章节 → 目标章节」，避免结构混乱 - **PRD 即设计稿输入：**页面结构表直接复用为 Pencil 设计稿的生成 Prompt，一份描述两处产出 |
- PRD 是设计稿的灵魂：结构化的 PRD（区域表格、元素清单）直接决定 Pencil 输出质量 - 先全局后局部：第一轮生成全部页面框架，再逐页打磨，避免风格割裂 - 表格比段落好：「区域 \内容」的表格描述比一段话更精确 - **修正要指到元素：**说「card5 换成活动卡片」比「卡片调一下」有效 10 倍 - **品牌约束写明用途：**不只给色值，还要说「用在哪些地方」 - **每轮聚焦 1-3 个问题：**一次改太多容易互相影响，小步快跑更稳 - **最后统一打磨：**全部页面到位后，再做一轮统一风格和间距的调整 - **每个页面单独创建画布：**减少Token的消耗，与AI对话时可直接定位修改的页面 |
- 需求拆解粒度决定交付质量：任务过大 AI 容易遗漏细节，2-5 分钟粒度最佳 - 先澄清再拆解：用 speckit.clarify 消除歧义后再 specify，避免返工 - 验收标准前置：每个任务附带验收条件，AI 完成后可自动核查 |
- 技术栈约束先行：在技术方案开头明确框架和依赖约束，避免 AI 选择非预期的库 - 从 PRD 直接推导：AI 读取结构化 PRD，自动识别需设计的接口和模块边界 - 增量澄清替代评审会：用对话式澄清替代多轮评审会，快速收敛到共识 - 双向同步保持一致：PRD 变更时同步更新技术方案，技术方案是 PRD 的工程化翻译 |
将流程与常见问题固化为 Skills 与文档，形成可复用的 AI 实践范式；沉淀的能力可直接迁移到其他项目： api-db-workflow：从 DB（init.sql / init-data / 迁移）到 PO/DTO/Controller/Service/API 文档的闭环及新增实体检查清单。 米盾登录接入：网关 CAS 认证 + Header 透传 + 本地用户映射，快速接入登录。 IDM 用户信息查询：统一查人能力（按工号/uid 精确查、模糊查、批量查），与米盾配合形成「认证 + 用户详情」能力。 Jackson 时间格式：全局 LocalDateTime 反序列化，兼容 ISO-8601，避免“index 19”等问题在福利、活动等接口重复出现。 |
- **技术栈约束在第一句话：**避免 AI 选了你不想用的库，后面再换成本极高 - **30 个任务的实现计划：**大项目拆成小任务，每个任务有文件范围、步骤、验证标准 - **TDD 而非后补测试：**先写测试再写实现，AI 生成的代码质量显著更高 - **Mock 先行，可替换：**先用 Mock 跑通全流程，再逐服务替换为真实 API - **PRD 结构表直接驱动：**区域→组件→数据来源的三列表格，零翻译成本 - **字段映射表必须有：**API 字段名和前端类型名不一致时，映射表是唯一真相 - **每改一个服务就验证：**不要一次性替换所有服务，逐服务替换+编译验证 - **8 个 Phase 的渐进式实现：**基础设施 → 状态 → 布局 → 卡片 → 页面 → 功能 → 打磨，每层依赖上一层 |
- **接口联调顺序：**先 Mock → 再 staging → 最后 production，分步验证降低风险 - **契约驱动联调：**API-CONTRACT 是唯一真相，联调前双方先对齐契约版本 - **自动化记录联调 log：**保留请求/响应快照，方便复现和定位问题 |
- 沉淀全栈项目部署与配置全栈项目部署与配置 |
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
9
0- 0
已为社区贡献7条内容
所有评论(0)