老项目新需求AI前端开发指南

基于 Claude Code 驱动的老项目改造方法论

核心理念

先确认再动手 --- 避免做已存在的功能
先设计再实现 --- 需求和方案定稿后才写代码
按层次推进 --- 类型 → API → 状态 → 组件 → 页面
每层验证 --- 构建 + lint 通过才进入下一层
关键决策人工把关 --- AI 自主跑，但 4 个节点必须停

规模分级

进入流程前先判定需求规模，不同规模走不同流程：

判定标准（三维度组合）

维度	S 级	M 级	L 级
文件影响	1-2 个文件	3-8 个文件	8+ 或跨模块
状态变更	无新状态	有新状态	新页面级状态
已有代码	纯新增	改已有组件	改公共组件/跨应用

判定规则：任一维度命中高级别，整体取高级别。

各级必做步骤

步骤	S 级	M 级	L 级
第零步：现状确认	必做	必做	必做
第一步：拆需求（八维）	跳过	简化（目标+边界）	完整
第二步：拆方案	跳过	数据流设计	完整
第三步：后端对接	确认接口即可	文档+curl	文档+curl+mock
第四步：前端实现	直接实现	按层次推进	按层次推进
第五步：文档回灌	跳过	CLAUDE.md（如有新约束）	CLAUDE.md + docs/

完整流程（L 级）

第零步：现状确认

目的：避免重复造轮子。AI 扫代码无法替代人手验证。

执行：

点产品 --- 打开生产/测试环境，按需求路径点一遍，确认功能是否存在
搜代码 --- 用关键词搜索项目代码，排查是否有写了一半没上线的半成品、藏在 feature flag 后面的实现、已有但未接入路由的组件

产出：一句话现状结论（"功能不存在" / "部分存在，xxx 已有" / "功能已存在，需改为优化/重构方向"）

第一步：拆需求（八维拆解）

从"一句话需求"拆解为结构化需求文档。

八个维度

#	维度	说明
1	业务目标	一句话描述这次做什么、为谁做
2	用户场景	典型场景 + 用户痛点
3	接口契约	方法、路径、入参、返回结构、错误码（后端提供或协商）
4	边界场景清单	至少 8 条 edge case，每条标"基于代码推断"或"待产品决策"
5	老项目约束	CLAUDE.md 禁区和历史包袱中相关项，标明来源
6	不在这次范围里的事	先列候选，人审核后砍掉或留到下期
7	交互/UI 规格	页面状态（loading、empty、error、success）、操作流程、动效、响应式
8	跨应用影响	微前端通信变更、共享状态变更、submodule 变更、组件库升级

人工审核点（决策停点 1/4）

审核三件事后反馈：

业务目标方向是否正确
边界场景的产品决策
不在这次范围里的最终裁定

第二步：拆方案

产出内容

涉及链路 --- 从入口到数据层的完整链路，表格标注每个节点（文件、状态、关键逻辑）
改造点清单 --- 编号 P01、P02...，标注类型（新增/修改）+ 文件路径 + 一句话改什么
数据流设计 --- Store/Props/Emit 链路、API 层封装方式、TypeScript 类型定义
影响范围 --- 每条标"高/中/低"风险
改造步骤与顺序 --- 按层次排序，标明依赖关系
待审核的关键决策点 --- 集中列出，方便人 review

人工审核点（决策停点 2/4）

审核方案中的状态/数据流设计决策：

Store 结构是否合理
Props 传递层级是否过深
是否需要新增 adapter

第三步：后端对接

三步对接

确认接口文档 --- 获取 Swagger/手写文档，确认入参、返回结构、错误码
curl 验证 --- 在测试环境实际调接口，特别关注：
- null vs 空数组 vs undefined
- 嵌套结构层级
- 分页/列表的空态
- 错误码实际表现
约定 mock 方案（后端未完成时） --- 约定返回结构，前端用 mock 数据并行开发

Mock 策略

接口返回结构写入 TypeScript 类型文件作为契约
mock 数据放在独立文件，联调时删除
联调验证节点：后端完成后必须用真实接口跑一遍确认

第四步：前端实现

锁住现有行为（修改已有组件时）

修改已有组件/函数前，必须先做：

grep 出所有调用方
记录现有 props/emit/slots 契约
记录作为基线："这些不能破坏"

纯新增文件跳过此步。

人工审核点（决策停点 3/4）

确认已有组件的调用方和影响范围是否如预期。

按层次实现

复制代码

类型定义 → API 层 → Store/状态 → 组件 → 页面集成

每层完成后执行验证：构建通过 + lint 通过，才进入下一层。

层	做什么	验证
类型定义	接口类型、组件 Props 类型、Store 状态类型	`tsc` 编译通过
API 层	封装接口调用方法，对齐项目请求层风格	构建 + lint
Store/状态	Pinia store 或组件内状态，数据流逻辑	构建 + lint
组件	UI 组件实现，使用项目组件库	构建 + lint
页面集成	路由接入、菜单配置、组装组件	构建 + lint + 浏览器验证

人工审核点（决策停点 4/4）

页面集成完成后，人工浏览器验证：

打开页面按需求操作一遍
对照改造前截图确认无视觉回归
确认交互流程完整

阻塞处理策略

错误类型	处理方式
构建/lint 报错	AI 自主修复，不限次数
已有组件契约冲突（改 props 导致其他调用方报错）	立刻停，升级给人决策
接口实际返回与文档不符	停，联系后端确认

第五步：文档回灌

改造完成后同步更新：

CLAUDE.md --- 如果产生了影响所有未来改造的新约束，写进项目 CLAUDE.md
docs/ 任务文档 --- 更新对应任务文件夹的 README.md，记录：背景、进度、卡点、解决方案

判断标准：影响所有未来类似改造的 → CLAUDE.md；只这一次的特殊处理 → 任务文档。

Git 工作流

三个 commit 节点：

节点	时机	commit 内容
1	方案定稿后	docs/ 下的需求文档和方案文档
2	每层验证通过后	该层的代码变更
3	全部完成	提 PR，关联需求文档

提示词模板

分步模板

提示词 0：现状确认

复制代码

我要做一个新需求："[一句话需求]"。

在我去浏览器确认之前，先帮我搜一下代码：
- 用关键词 [xxx] 搜索项目，看是否有相关的已有实现、半成品、或未接入路由的组件
- 如果找到相关代码，告诉我文件路径和当前状态

等我浏览器确认后再继续。

示例：

复制代码

我要做一个新需求："给企业详情页加一个关联企业图谱展示"。

在我去浏览器确认之前，先帮我搜一下代码：
- 用关键词 relation-graph、enterprise-graph、关联图谱 搜索项目，看是否有相关的已有实现、半成品、或未接入路由的组件
- 如果找到相关代码，告诉我文件路径和当前状态

等我浏览器确认后再继续。

提示词 1：八维拆解

复制代码

我有一个新需求：[需求描述]。
我已经确认：[现状描述，如"功能不存在" / "部分存在，xxx已有"]。

读 docs/ 下资产 + CLAUDE.md，再扫代码里相关实现，按以下八维写需求文档草稿：

1. 业务目标(一句话)
2. 用户场景(典型场景 + 痛点)
3. 接口契约(方法、路径、入参、返回、错误码，对齐项目现有风格)
4. 边界场景清单(至少 8 条 edge case，每条标"基于代码推断"或"待产品决策")
5. 老项目约束(CLAUDE.md 禁区和历史包袱里相关的，每条标来源)
6. 不在这次范围里的事(先列候选)
7. 交互/UI 规格(页面状态、操作流程、动效、响应式)
8. 跨应用影响(微前端通信、共享状态、submodule、组件库)

输出 markdown，保存到 docs/requirements/[feature-name].md。

示例：

复制代码

我有一个新需求：给企业详情页加一个关联企业图谱展示。
我已经确认：功能不存在，但 relation 模块下有关联关系查找的接口和页面。

读 docs/ 下资产 + CLAUDE.md，再扫代码里 relation、graph、图谱相关实现，按以下八维写需求文档草稿：
... (同上)

提示词 2：人审核 + 定稿

复制代码

我对 docs/requirements/[feature-name].md 做了以下判断：

业务目标修正：[修正内容或"无修正"]
边界场景的产品决策：
- [E0x]：[决策]
- ...
不在这次范围里的最终决策：
- 砍掉：[列表]
- 留到下期：[列表]

按以上判断更新文档，整理为正式 PRD 格式。

提示词 3：拆方案

复制代码

基于 docs/requirements/[feature-name].md，按以下步骤拆方案：

1. 摸链路：找出涉及的完整链路，每个节点说明文件、状态(现有/新增/修改)、关键逻辑
2. 列改造点：拆成 P01、P02... 每条标类型 + 文件路径 + 一句话改什么
3. 设计数据流：Store/Props/Emit 链路 + API 层封装 + TypeScript 类型定义
4. 说影响范围：每条标高/中/低风险
5. 说步骤顺序：按层次排序（类型→API→Store→组件→页面），标依赖
6. 集中列出"待审核的关键决策点"

保存到 docs/requirements/[feature-name]-solution.md。

提示词 4：后端对接确认

复制代码

基于 docs/requirements/[feature-name]-solution.md 中的接口契约，做以下对接：

1. [后端已完成时] 在测试环境 curl 以下接口，确认返回结构：
   - [接口列表]
   重点关注：null/空数组、嵌套层级、错误码实际表现

2. [后端未完成时] 基于约定的接口契约，生成 mock 数据文件：
   - TypeScript 类型文件作为契约
   - mock 数据独立文件，后续联调时删除

输出对接结论：哪些接口已验证通过、哪些需要 mock 并行。

提示词 5：锁住现有行为

复制代码

基于 solution.md 的改造点，这次需要修改以下已有文件：
[文件列表]

改动前先做：
1. grep 出每个文件/组件的所有调用方
2. 记录现有 props/emit/slots 契约
3. 输出"不能破坏"的基线清单

等我确认基线后再开始实现。

提示词 6：按层实现

复制代码

基于 solution.md 和确认的基线，按层次开始实现：

第一批：类型定义
- [P01、P02...]
- 完成后跑构建 + lint 确认通过

第二批：API 层
- [P03...]
- 完成后跑构建 + lint 确认通过

第三批：Store/状态
- [P04...]
- 完成后跑构建 + lint 确认通过

第四批：组件
- [P05、P06...]
- 完成后跑构建 + lint 确认通过

第五批：页面集成
- [P07...]
- 完成后跑构建 + lint 确认通过

每批完成汇报结果，全部通过后告诉我去浏览器验证。
阻塞规则：
- 构建/lint 报错自主修复
- 已有组件契约冲突立刻停
- 接口返回与预期不符立刻停

提示词 7：文档回灌

复制代码

前端改造完成，把这一轮新发现回灌到文档：
1. CLAUDE.md：加项目级新约束（如有）
   判断标准：影响所有未来类似改造的写进 CLAUDE.md，只这一次的留在 solution.md
2. docs/ 任务文档：更新 README.md 记录背景、进度、卡点、解决方案

输出每份文件的改动 diff。

一键工作流模板

整段粘贴到 Claude Code，关键决策点会停下来等你输入：

复制代码

我要做一个新需求：[一句话需求]
完整跑通前端开发流程，全程自主推进，遇到关键决策点停下来等我。

第零步：现状确认（必做，不能跳）
- 搜代码看有无已有实现/半成品
- 提醒我打开浏览器确认
- 等我确认后才进下一步

第一步：拆需求
- 读 docs/ + CLAUDE.md + 现有代码
- 按八维写需求文档草稿到 docs/requirements/<feature>.md
- 停下来等我反馈业务目标、边界决策、范围决策
- 我反馈完后整理为正式 PRD

第二步：拆方案
- 摸链路 + 列改造点 + 设计数据流 + 说影响 + 说步骤
- 整合成 solution.md，第 6 节"待审核决策点"单独抽出来
- 停下来等我审核状态/数据流设计决策
- 我反馈完后更新 solution.md

第三步：后端对接
- 确认接口文档，如后端已完成则 curl 验证
- 如后端未完成则生成 mock 文件并行开发
- 接口返回与文档不符则停下来告诉我

第四步：前端实现
- 修改已有组件前先 grep 调用方、记录契约基线
- 停下来等我确认影响范围
- 按层次实现：类型→API→Store→组件→页面
- 每层跑构建 + lint 验证
- 全部通过后停下来等我浏览器验证

第五步：文档回灌
- 更新 CLAUDE.md（如有新约束）和 docs/ 任务文档

自主原则：
- 每步跑完自己 review 输出质量，不合格自己重跑
- 构建/lint 报错自主修复
- 已有组件契约冲突立刻停
- 接口返回与预期不符立刻停
- 不要重构现有代码，只调用
- 关键决策点停下来等我，不要替我拍板

跑完输出 summary：列每个产出文件 + 我应该重点 review 的地方。

关键原则速查

原则	说明
先点产品再动手	AI 扫代码无法发现"功能已存在"，必须人手验证
断言凭实际不凭应该	验证基于真实行为，不基于预期
不重构现有方法，只调用	控制影响范围，避免牵一发动全身
改动前锁行为	修改已有组件前记录调用方和契约基线
每层验证	构建 + lint 通过才进入下一层
关键决策人工拍板	4 个停点 AI 不能替你做
文档回灌	新约束写回 CLAUDE.md，不让教训白费