Claude Code

使用Claude Code在存量产品上进行迭代开发

一、引言：企业80%的真实场景

新项目从0到1的开发只占企业开发工作的20%，剩下80%是存量产品的迭代开发：大版本升级、平台迁移、新增模块、功能改造。这些场景的核心挑战不是”如何写代码”，而是”如何让AI理解你的项目”。

Claude Code（以下简称CC）默认状态下，它不认识你的项目、不知道你的技术约束、不了解你的业务规则。如果直接问”帮我重构这个模块”，CC会：

  • 按自己的偏好选择技术栈
  • 无视已有的组件封装
  • 改动一处影响三处

本文的核心思路：把散落的上下文工程化，让CC从”猜”变成”遵守”。通过系统化的方法论，将项目背景、技术约束、业务规则显性化，让AI成为真正懂你的协作者。

七大痛点分析

痛点 典型表现
需求黑箱 没有完整的PRD文档，需求散落在代码、会议记录、口头约定中
技术栈失控 CC自己选用了不存在的组件，或无视项目约定的新版本库
重复造轮子 无视已有的工具类、公共组件，重复实现相同功能
回归恐惧 改了一个Bug，导致其他三个功能失效
工程化断层 一次会话的经验教训，下次会话完全丢失
项目背景丢失 业务术语、软硬件约束、历史决策CC一概不知
多组件协同盲区 改动一个组件时，看不到其他组件的依赖和调用关系

二、五阶段SOP总览

流程全景图

1
2
3
4
5
6
7
8
graph TD
    A[阶段一：项目上下文建设<br/>一次性投入] --> B[阶段二：需求对齐<br/>每次迭代]
    B --> C[阶段三：约束建立<br/>一次性投入+持续更新]
    C --> D[阶段四：开发执行<br/>每次迭代]
    D --> E[阶段五：验证与沉淀<br/>每次迭代]
    E -.-> A
    C -.-> C
    E -.-> C

痛点×阶段映射矩阵

阶段 解决的痛点 主要/辅助
项目上下文建设 项目背景丢失、多组件协同盲区 ★
需求对齐 需求黑箱 ★
约束建立 技术栈失控、重复造轮子 ★
开发执行 多组件协同盲区、回归恐惧 ★
验证与沉淀 工程化断层、回归恐惧 ★

标注：★=主要解决，○=辅助解决

三、阶段一：项目上下文建设

目标

建立项目的”百科全书”，让CC在第一句话就知道：这是什么项目、用啥技术、有什么约束。

具体步骤

步骤1：扫描项目生成CLAUDE.md

使用CC的扫描能力生成根级和模块级CLAUDE.md：

1
2
# 根级CLAUDE.md（项目整体信息）
claude @. --init-project --output CLAUDE.md

生成的CLAUDE.md包含：

  • 项目名称、用途、业务领域
  • 技术栈（语言、框架、数据库、中间件）
  • 目录结构说明
  • 关键模块职责

对于多模块项目，还要生成模块级CLAUDE.md：

1
2
3
# 模块级CLAUDE.md（模块特定信息）
claude @modules/user-service --init-project --output modules/user-service/CLAUDE.md
claude @modules/order-service --init-project --output modules/order-service/CLAUDE.md

步骤2：写入业务术语表和软硬件约束

在CLAUDE.md中手动补充（CC无法自动识别）：

1
2
3
4
## 业务术语表
- SKU: Stock Keeping Unit，商品最小库存单元
- GMV: Gross Merchandise Volume，成交总额
- ...
1
2
3
4
5
## 软硬件约束
- 数据库: MySQL 8.0，必须使用MyBatis Plus
- 缓存: Redis 5.0，禁止使用@Cacheable注解
- 第三方: 必须走公司统一网关
- 性能要求: 接口响应时间<500ms

步骤3：多组件项目的全局索引策略

Monorepo场景：在根目录CLAUDE.md中添加模块索引

1
2
3
4
## 模块索引
- `@modules/user-service`: 用户服务，负责用户认证、资料管理
- `@modules/order-service`: 订单服务，负责订单创建、状态流转
- `@modules/payment-service`: 支付服务，对接支付宝、微信

多仓场景：在每个仓库根目录建立CLAUDE.md，并在关键依赖中添加外部引用

1
2
3
## 外部依赖
- 用户服务API: https://git.corp.com/user-api
- 支付SDK: https://git.corp.com/payment-sdk

流程图

1
2
3
4
5
6
7
8
9
10
11
graph TD
    A[项目扫描] --> B{项目类型?}
    B -->|单模块| C[生成根级CLAUDE.md]
    B -->|多模块| D[生成根级+模块级CLAUDE.md]
    C --> E[补充业务术语表]
    C --> F[补充软硬件约束]
    D --> E
    D --> F
    E --> G[建立模块索引]
    F --> G
    G --> H[验证: 用CLAUDE.md回答项目问题]

检查清单

  • CLAUDE.md包含项目基本信息
  • 技术栈版本明确标注
  • 业务术语表完整
  • 软硬件约束无遗漏
  • 多模块项目建立索引
  • 测试：询问CC”这个项目用什么数据库”，能从CLAUDE.md得到正确答案

四、阶段二：需求对齐

目标

从散落的代码中”逆向”出完整的PRD，消除需求黑箱。

具体步骤

步骤1：多维度扫描生成PRD初稿

关键原则：四个维度分别扫描，不要用一个大prompt。

维度一：从API入口追踪完整调用链

1
2
3
claude @controllers/OrderController.java @services/OrderService.java \
  "分析订单创建的完整调用链，从Controller到Service到Repository到数据库操作。
  输出到 docs/order-create-flow.md，不要修改任何代码。"

维度二：从数据模型反推业务规则

1
2
3
claude @entities/Order.java @migrations/V2__create_order.sql \
  "分析订单表结构和字段约束，反推业务规则（如订单状态机、金额精度要求）。
  输出到 docs/order-business-rules.md。"

维度三：从异常处理和校验逻辑挖掘边界条件

1
2
3
claude @services/OrderService.java \
  "提取所有异常处理和参数校验逻辑，总结边界条件和异常场景。
  输出到 docs/order-edge-cases.md。"

维度四：从配置文件和外部依赖发现隐藏行为

1
2
3
claude @application.yml @resources/config/payment.properties \
  "分析配置项和外部依赖，总结隐藏的开关、限流、降级等行为。
  输出到 docs/order-hidden-behaviors.md。"

步骤2：合并去重 + 生成覆盖度自检表

1
2
3
claude @docs/order-*.md \
  "合并四个维度的扫描结果，生成完整的订单功能PRD，并生成覆盖度自检表（已识别/待确认）。
  输出到 docs/order-prd-complete.md。"

覆盖度自检表示例：

功能点 调用链 业务规则 边界条件 配置行为 状态
订单创建 ✅ ✅ ⚠️ ✅ 待确认边界条件
订单支付 ✅ ✅ ✅ ❌ 待确认配置
订单取消 ✅ ⚠️ ✅ ✅ 待确认业务规则

步骤3：用Git历史和已有测试交叉补充

1
2
3
4
5
6
7
8
9
# 从Git提交历史补充隐性需求
claude --git-history 20 \
  "分析最近20次提交，总结新增的需求和Bug修复，补充到PRD。
  输出到 docs/order-prd-history.md。"

# 从测试用例补充边界条件
claude @tests/OrderServiceTest.java \
  "分析测试用例，提取隐含的业务规则和边界条件，补充到PRD。
  输出到 docs/order-prd-test-coverage.md。"

步骤4：用PRD反向生成测试，跑测试验证PRD准确性

1
2
3
4
claude @docs/order-prd-complete.md @src/ \
  "基于PRD生成测试用例（使用JUnit 5），然后运行这些测试。
  如果测试通过，说明PRD准确；如果失败，说明PRD有误或代码有bug。
  输出到 tests/generated/OrderServicePrdTest.java。"

这是最关键的验证机制：测试通过=PRD准确，测试失败=需要修正PRD或代码。

步骤5：人工补充隐性规则

5类典型隐性规则：

规则类型 为什么代码里看不到 示例
业务潜规则 某些做法约定俗成，不写在代码里 订单金额不能包含税费，税费单独计算
历史决策 早期技术债务，无法追溯 用户ID必须是偶数，为了与老系统兼容
外部依赖约束 第三方API限制 支付接口每秒最多调用10次
合规要求 安全、审计规定 所有用户操作必须记录日志
性能红线 非功能性需求 批量导入单次不超过1000条

将这些规则写入@docs/implicit-rules.md。

流程图（三角验证）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
graph TD
    A[现有代码] --> B[维度一: API调用链]
    A --> C[维度二: 数据模型]
    A --> D[维度三: 异常处理]
    A --> E[维度四: 配置依赖]
    B --> F[合并生成PRD初稿]
    C --> F
    D --> F
    E --> F
    F --> G[Git历史补充]
    F --> H[测试用例补充]
    G --> I[完整PRD]
    H --> I
    I --> J[反向生成测试]
    J --> K{测试通过?}
    K -->|是| L[✅ PRD准确]
    K -->|否| M[❌ 修正PRD或代码]
    M --> J

检查清单

  • 四个维度分别扫描，非单一prompt
  • 覆盖度自检表已生成
  • Git历史已分析
  • 测试用例已补充
  • PRD反向生成测试并验证通过
  • 隐性规则已文档化

五、阶段三：约束建立

目标

建立三层防线，确保CC遵守项目规范。

具体步骤

三层防线架构

1
2
3
graph LR
    A[CLAUDE.md<br/>告知层] --> B[.claude/rules/<br/>禁止层]
    B --> C[Hooks<br/>拦截层]

第一层：CLAUDE.md（告知层）

  • 作用：告诉CC项目的基本约束
  • 示例：
1
2
3
4
## 技术约束
- 必须使用MyBatis Plus，禁止直接写SQL
- 所有接口返回统一格式Result<T>
- 禁止使用@Cacheable，必须用RedisTemplate

第二层：.claude/rules/（禁止层）

  • 作用：明确的禁止性规则，CC违反时直接拒绝
  • 规则文件格式：
1
2
3
4
5
## 规则: 禁止直接写SQL

### ✅ 正确做法
```java
userMapper.selectById(id);

❌ 禁止做法

1
2
@Select("SELECT * FROM user WHERE id = #{id}")
User findById(Long id);

使用示例

错误示范会自动被拦截

1
2
3
4
5
6
7
8
9
10

**第三层：Hooks（拦截层）**
- 作用：在代码提交前自动检查
- 示例`.claude/hooks/pre-commit.md`：
```markdown
## 检查项1: SQL注入风险
运行grep -r "SELECT \* FROM" src/，如果发现直接拼接SQL，拒绝提交。

## 检查项2: 未使用的导入
运行mvn checkstyle:check，如果有未使用的导入，警告但允许提交。

流程图

1
2
3
4
5
6
7
8
9
10
graph TD
    A[CLAUDE.md] --> B{违反告知?}
    B -->|否| C[生成代码]
    B -->|是| D[提示遵循CLAUDE.md]
    C --> E{违反Rules?}
    E -->|否| F[生成代码]
    E -->|是| G[拒绝生成]
    F --> H{违反Hooks?}
    H -->|否| I[✅ 允许]
    H -->|是| J[拒绝提交]

检查清单

  • CLAUDE.md包含技术约束
  • .claude/rules/目录已创建
  • 关键规则已写成Rules文件（格式：✅做法+❌做法+示例）
  • Hooks已配置（pre-commit）
  • 测试：故意违反规则，验证CC能拦截

六、阶段四：开发执行

目标

在约束下安全开发，控制风险。

具体步骤

步骤1：计划先行，人工批准

推荐使用Plan模式或workflow skill：

1
2
3
4
5
6
# Plan模式
claude --permission-mode plan
"重构订单状态机，从5个状态扩展到8个状态。先生成详细计划。"

# 或使用workflow skill
/workflow refactor-order-state-machine

CC会生成详细的实施计划，人工批准后再执行。

步骤2：小步快跑，每步验证

1
2
3
4
5
6
7
8
9
10
graph TD
    A[拆分任务] --> B[实现第一步]
    B --> C[运行测试]
    C --> D{测试通过?}
    D -->|是| E[提交代码]
    D -->|否| F[修复代码]
    F --> C
    E --> G{还有步骤?}
    G -->|是| B
    G -->|否| H[✅ 完成]

决策循环图：

  • 每次改动后立即运行测试
  • 测试通过才进入下一步
  • 失败则立即回滚或修复

步骤3：多组件协同策略

策略一：接口契约先行

1
2
3
4
# 先定义接口
claude @order-service @payment-service \
  "定义订单支付接口契约（方法签名、参数、返回值、异常），
  输出到 docs/payment-contract.md。"

策略二：按依赖方向执行

依赖链条：order-service → payment-service → bank-service

执行顺序：

  1. 先改最下游的bank-service
  2. 测试通过后再改payment-service
  3. 最后改order-service

策略三：Agent Team并行

1
2
3
4
5
6
7
8
9
10
# 定义Agent Team
claude --agent-team
"需求分析师：分析需求，生成PRD
Architect：设计架构
java-dev：开发支付模块
web-dev：开发前端支付页
QA：生成测试用例并验证"

# 并行执行
claude --agent-team "执行订单支付功能开发"

步骤4：大范围改动用Worktree隔离

1
2
3
4
5
6
7
8
# 创建Worktree
git worktree add ../order-service-v2-refactor refactor/branch

# 在Worktree中开发
claude @../order-service-v2-refactor "重构订单服务"

# 测试通过后再合并
git worktree remove ../order-service-v2-refactor

检查清单

  • 已使用Plan模式或workflow skill
  • 任务已拆分为小步骤
  • 每步都有测试验证
  • 多组件协同按依赖顺序执行
  • 大范围改动使用Worktree隔离

七、阶段五：验证与沉淀

目标

验证功能正确性，沉淀经验避免下次重复踩坑。

具体步骤

流程图

1
2
3
4
5
6
7
8
9
10
graph TD
    A[开发完成] --> B[系统级QA验证]
    B --> C{验证通过?}
    C -->|否| D[修复问题]
    D --> B
    C -->|是| E[代码审查]
    E --> F[更新CLAUDE.md]
    E --> G[沉淀错误到Memory]
    E --> H[生成工程文档]
    H --> I[下次迭代复用]

步骤1：系统级QA验证

1
2
3
4
# QA Agent运行完整测试
claude --agent qa
"运行完整测试套件（单元测试+集成测试+端到端测试），
生成测试报告，输出到 docs/test-report.md。"

步骤2：代码审查

1
2
3
# 生成代码审查清单
claude @src/ "生成代码审查清单，关注点：性能、安全、可维护性，
输出到 docs/code-review-checklist.md。"

步骤3：更新CLAUDE.md

将新发现的技术约束和业务规则补充到CLAUDE.md：

1
2
claude @docs/test-report.md @CLAUDE.md
"将测试报告中发现的约束补充到CLAUDE.md。"

步骤4：沉淀错误到Memory

1
2
3
4
# 记录本次迭代遇到的问题和解决方案
claude --memory "订单状态机重构过程中，
遇到的bug：状态流转时未加锁导致并发问题。
解决方案：使用数据库乐观锁。"

步骤5：生成/更新工程基线文档

  • 架构设计文档：docs/architecture.md
  • 详细设计文档：docs/design/order-state-machine.md
  • 数据库设计文档：docs/database/order-schema.md
  • 接口文档：docs/api/payment-api.md

步骤6：数据库变更用Flyway管理

1
2
3
4
# 生成Flyway迁移脚本
claude @entities/Order.java @migrations/
"生成Flyway迁移脚本V3__update_order_state_machine.sql，
使用ALTER TABLE语法，避免DROP TABLE。"

检查清单

  • 系统级QA验证通过
  • 代码审查完成
  • CLAUDE.md已更新
  • 错误已沉淀到Memory
  • 工程文档已生成
  • 数据库变更已用Flyway管理

八、实战演示

项目背景

一个三端应用的v2.0版本迭代：

  • 后端：Java + Spring Boot + MyBatis Plus
  • 前端：Next.js + TypeScript + Ant Design
  • 移动端：Flutter

迭代目标：从v1.0的单店模式升级到v2.0的多店模式。

阶段一：项目上下文建设

1
2
# 扫描后端项目
claude @backend/ --init-project --output backend/CLAUDE.md

生成的backend/CLAUDE.md关键内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
## 项目信息
项目名称：电商订单系统
业务领域：B2C电商

## 技术栈
- Java 17
- Spring Boot 2.7
- MyBatis Plus 3.5
- MySQL 8.0
- Redis 6.0

## 关键模块
- `@backend/modules/order`: 订单服务
- `@backend/modules/user`: 用户服务
- `@backend/modules/product`: 商品服务

补充业务术语：

1
2
3
4
## 业务术语表
- 单店模式：一个账号只能管理一个店铺
- 多店模式：一个账号可以管理多个店铺
- 店铺ID (shop_id): 店铺的唯一标识，v2.0新增字段

阶段二：需求对齐

维度一：API调用链扫描

1
2
claude @backend/modules/order/src/main/java/controller/OrderController.java \
  "分析订单创建API的完整调用链，输出到 docs/order-create-flow.md。"

生成的docs/order-create-flow.md：

1
2
3
4
5
6
7
8
## 订单创建调用链

1. OrderController.createOrder()
2. → OrderService.createOrder()
3. → ProductClient.checkStock() (RPC调用)
4. → UserClient.checkUserStatus() (RPC调用)
5. → OrderMapper.insert()
6. → PaymentClient.createPayment() (RPC调用)

维度二：数据模型反推业务规则

1
2
claude @backend/modules/order/src/main/java/entity/Order.java \
  "分析订单实体，反推业务规则，输出到 docs/order-business-rules.md。"

发现的问题：

1
2
## 发现的问题
当前订单表没有shop_id字段，无法支持多店模式。

维度三：异常处理挖掘边界条件

1
2
claude @backend/modules/order/src/main/java/service/OrderService.java \
  "提取异常处理逻辑，输出到 docs/order-edge-cases.md。"

维度四：配置文件发现隐藏行为

1
2
claude @backend/application.yml \
  "分析配置项，输出到 docs/order-hidden-behaviors.md。"

逆向PRD生成

1
2
claude @backend/docs/order-*.md \
  "合并生成订单功能PRD，输出到 docs/order-prd-v1.md。"

生成的PRD关键内容：

1
2
3
4
5
6
7
8
9
10
11
12
# 订单功能PRD (v1.0单店模式)

## 功能描述
用户可以创建订单，系统会检查库存和用户状态，然后创建订单记录。

## 业务规则
1. 一个用户只能有一个店铺（隐含规则）
2. 订单金额必须大于0
3. 库存不足时订单创建失败

## 数据模型
订单表包含字段：id, user_id, product_id, amount, status, created_at

人工补充隐性规则

创建docs/implicit-rules.md：

1
2
3
4
5
6
7
8
9
## 业务潜规则
- v1.0版本中，user_id等同于shop_id（一个用户一个店）
- v2.0需要解耦：一个用户可以有多个shop

## 历史决策
- 订单状态使用字符串存储，不是枚举（历史遗留）

## 性能红线
- 批量创建订单单次不超过1000条

PRD反向生成测试验证

1
2
3
claude @backend/docs/order-prd-v1.md @backend/modules/order/src/main/java/ \
  "基于PRD生成测试用例，使用JUnit 5，输出到 backend/modules/order/src/test/java/OrderPrdTest.java。
  然后运行测试，验证PRD准确性。"

测试结果：✅ 通过（说明PRD准确）

阶段三：约束建立

创建Rules文件

.claude/rules/database-rule.md：

1
2
3
4
5
6
## 规则: 数据库变更必须使用Flyway

### ✅ 正确做法
```bash
# 创建Flyway迁移脚本
claude @entities/Order.java @migrations/ "生成Flyway脚本V2__add_shop_id.sql"

❌ 禁止做法

1
2
-- 禁止直接修改数据库
ALTER TABLE `order` ADD COLUMN `shop_id` BIGINT;

使用示例

所有数据库变更必须生成Flyway迁移脚本

1
2
3
4
5
6
7
8
9
10

`.claude/rules/mybatis-rule.md`：

```markdown
## 规则: 禁止直接写SQL

### ✅ 正确做法
```java
userMapper.selectById(id);
userMapper.insert(user);

❌ 禁止做法

1
2
@Select("SELECT * FROM user WHERE id = #{id}")
User findById(Long id);

使用示例

所有数据库操作必须使用MyBatis Plus方法

1
2
3
4
5
6
7
8
9
10
11

#### 配置Hooks

`.claude/hooks/pre-commit.md`：

```markdown
## 检查项1: Flyway脚本命名规范
运行grep -r "^--" migrations/，检查脚本以V开头。

## 检查项2: 未使用的导入
运行mvn checkstyle:check，如果有未使用的导入，警告。

阶段四：开发执行

步骤1：Plan模式生成实施计划

1
2
3
claude --permission-mode plan
"实施订单表添加shop_id字段，支持多店模式。
生成详细计划，包括：数据库迁移、后端代码修改、前端代码修改。"

CC生成的计划：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 实施计划：订单表添加shop_id字段

## 阶段1：数据库迁移
1. 生成Flyway脚本V2__add_shop_id.sql
2. 添加shop_id字段，默认值为user_id
3. 为shop_id创建索引

## 阶段2：后端代码修改
1. 修改Order实体，添加shopId字段
2. 修改OrderMapper的查询方法，支持shopId过滤
3. 修改OrderService，支持多店订单查询
4. 修改OrderController，添加shopId参数

## 阶段3：前端代码修改
1. 修改订单创建页面，添加店铺选择器
2. 修改订单列表页面，添加店铺筛选
3. 修改API调用，传递shopId参数

## 阶段4：测试
1. 单元测试
2. 集成测试
3. 端到端测试

人工审查计划后，批准执行。

步骤2：小步快跑实现

步骤2.1：数据库迁移

1
2
3
claude @backend/modules/order/src/main/java/entity/Order.java @backend/migrations/ \
  "生成Flyway脚本V2__add_shop_id.sql，使用ALTER TABLE语法，添加shop_id字段。
  输出到 backend/migrations/V2__add_shop_id.sql。"

生成的V2__add_shop_id.sql：

1
2
3
4
5
6
7
8
-- 添加shop_id字段
ALTER TABLE `order` ADD COLUMN `shop_id` BIGINT NOT NULL DEFAULT 0 COMMENT '店铺ID';

-- 为shop_id创建索引
CREATE INDEX idx_shop_id ON `order`(`shop_id`);

-- 为现有数据填充shop_id（等于user_id）
UPDATE `order` SET shop_id = user_id WHERE shop_id = 0;

运行迁移脚本：

1
mvn flyway:migrate

✅ 迁移成功。

步骤2.2：后端代码修改

1
2
3
claude @backend/modules/order/src/main/java/entity/Order.java \
  "添加shopId字段，使用Long类型，添加字段注释。
  不要修改其他代码。"
1
2
3
claude @backend/modules/order/src/main/java/mapper/OrderMapper.java \
  "添加selectByShopId方法，使用MyBatis Plus的QueryWrapper。
  输出示例代码。"
1
2
3
claude @backend/modules/order/src/main/java/service/OrderService.java \
  "修改createOrder方法，添加shopId参数，并保存到订单记录。
  修改queryOrders方法，支持shopId过滤。"

运行测试：

1
mvn test

✅ 测试通过。

步骤2.3：前端代码修改

1
2
3
claude @frontend/src/pages/order/create.tsx \
  "添加店铺选择器，使用Select组件，数据来源：/api/shops。
  将选中的shopId传递给订单创建接口。"
1
2
claude @frontend/src/pages/order/list.tsx \
  "添加店铺筛选器，使用Select组件，支持筛选不同店铺的订单。"

运行前端测试：

1
npm test

✅ 测试通过。

步骤3：多组件协同

后端多服务协同

后端有3个微服务：order-service, product-service, user-service。

按依赖顺序执行：

  1. 先改product-service（添加shopId检查）
  2. 再改user-service（添加shop列表查询）
  3. 最后改order-service（使用shopId）
1
2
3
4
5
6
7
8
# 先改product-service
claude @product-service/ "修改商品查询接口，支持shopId过滤"

# 测试通过后，改user-service
claude @user-service/ "添加shop列表查询接口"

# 测试通过后，改order-service
claude @order-service/ "修改订单创建接口，使用shopId"

步骤4：Agent Team并行开发

1
2
3
4
5
6
7
claude --agent-team
"需求分析师：分析多店模式需求，生成PRD
Architect：设计多店模式架构
java-dev-order：开发订单服务
java-dev-product：开发商品服务
web-dev：开发前端页面
QA：生成测试用例并验证"

并行执行：

  • 需求分析师生成PRD
  • Architect设计架构
  • java-dev-order开发订单服务
  • java-dev-product开发商品服务
  • web-dev开发前端页面
  • QA生成测试用例并验证

阶段五：验证与沉淀

系统级QA验证

1
2
3
claude --agent qa
"运行完整测试套件：单元测试+集成测试+端到端测试。
生成测试报告，输出到 docs/test-report-v2.md。"

测试结果：

  • 单元测试：✅ 通过（120个用例）
  • 集成测试：✅ 通过（35个用例）
  • 端到端测试：✅ 通过（10个用例）

代码审查

1
2
3
claude @backend/src/ @frontend/src/
"生成代码审查清单，关注点：性能、安全、可维护性。
输出到 docs/code-review-checklist.md。"

审查发现：

  • ⚠️ 订单查询接口缺少分页参数（性能问题）
  • ✅ SQL注入防护到位
  • ✅ 权限检查完善

修复性能问题：

1
2
claude @backend/modules/order/src/main/java/service/OrderService.java \
  "添加分页参数，使用MyBatis Plus的Page对象。"

更新CLAUDE.md

1
2
claude @docs/test-report-v2.md @backend/CLAUDE.md
"将测试报告中发现的约束补充到CLAUDE.md。"

更新的CLAUDE.md：

1
2
3
4
5
## 技术约束
- 必须使用MyBatis Plus，禁止直接写SQL
- 所有接口返回统一格式Result<T>
- 禁止使用@Cacheable，必须用RedisTemplate
- **所有列表查询接口必须支持分页** (新增)

沉淀错误到Memory

1
2
3
4
5
6
claude --memory "多店模式开发过程中，
遇到的bug1：订单查询接口缺少分页，导致大量数据时性能问题。
解决方案：使用MyBatis Plus的Page对象。

遇到的bug2：shop_id字段初始值为0，导致查询错误。
解决方案：Flyway脚本中UPDATE现有数据，shop_id = user_id。"

生成工程文档

1
2
3
claude @backend/ "生成多店模式架构文档，输出到 docs/architecture/multi-shop.md"
claude @backend/modules/order/ "生成订单服务详细设计，输出到 docs/design/order-service.md"
claude @frontend/ "生成前端API文档，输出到 docs/api/frontend-api.md"

数据库变更用Flyway管理

验证Flyway脚本已生成：

  • ✅ V1__init_schema.sql
  • ✅ V2__add_shop_id.sql

本次迭代解决的痛点

痛点 解决措施
需求黑箱 逆向PRD + 隐性规则文档化
技术栈失控 CLAUDE.md + Rules约束
重复造轮子 Rules禁止重复造轮子
回归恐惧 每步验证 + 测试先行
工程化断层 更新CLAUDE.md + 沉淀Memory
项目背景丢失 CLAUDE.md + 业务术语表
多组件协同盲区 按依赖顺序 + Agent Team并行

九、CC工具箱速查

分层约束体系表

层级 位置 作用 适用场景
CLAUDE.md 项目根目录 告知项目基本信息 所有项目
.claude/rules/ 项目根目录 明确禁止性规则 关键约束
Memory CC内部 沉淀经验教训 跨会话复用
docs/ 项目文档 工程基线文档 大型项目

命令/技能/代理速查表

工具 用途 示例
@路径 引用文件/目录 claude @services/OrderService.java
--init-project 扫描项目生成CLAUDE.md claude @. --init-project
--permission-mode plan Plan模式，只读分析 claude --permission-mode plan
--agent-team 多Agent并行 claude --agent-team
--memory 沉淀到Memory claude --memory "总结经验"
/workflow 使用workflow skill /workflow refactor-module

工作流分级表

复杂度 工作流 适用场景
简单 手动prompt 单文件修改、简单Bug修复
中等 workflow skill 模块重构、功能开发
复杂 Plan模式 + Agent Team 跨服务改造、大版本迭代

十、结语：4条关键原则

  1. 上下文先行：在开发前，先建设CLAUDE.md和Rules，让AI”懂”项目。
  2. 逆向工程：从代码逆向PRD，用测试验证PRD，消除需求黑箱。
  3. 小步快跑：拆分任务，每步验证，控制风险。
  4. 持续沉淀：每次迭代后更新CLAUDE.md和Memory，避免重复踩坑。

存量产品的迭代开发不是靠AI”猜”出来的，而是靠系统化的方法论”造”出来的。建立好工程化体系，CC才能真正成为你的AI协作者。

附录：CC Prompt编写规范

所有prompt示例必须遵守以下CC最佳实践：

  1. 用 @路径 引用具体文件/目录，不用 [模块路径] 占位符
  2. 指定输出文件位置（如 输出到 docs/xxx.md）
  3. 分析类prompt必须加 不要修改任何代码 或 只描述现有行为
  4. 测试类prompt必须指定测试框架
  5. 优先推荐使用skill/Plan模式，手动prompt作为备选
  6. 收窄扫描范围（核心代码 而非 所有代码）