〇、核心理念：多模型协同架构
传统 AI 辅助开发是"单模型 + 聊天框"模式：开发者在 ChatGPT/Claude 网页中输入问题，复制粘贴代码，手动拼接。这种方式上下文断裂、缺乏流程管控、无法沉淀知识。本方案提出"Claude Code 主力 Agent + 多模型分级调度 + 企业知识库 + 个人记忆"的四层协同架构，让 AI 真正嵌入开发流程的每个环节。
🧠 Claude Code主力 Agent · 流程编排 · 代码生成
↕
🤖 DeepSeek深度推理 · 长上下文分析
☁️ 通义千问长文档解读 · 私有化部署
🔍 open-code-review自动化代码审查
↕
📚 企业知识库架构规范 · 历史方案 · API文档
🧩 个人记忆系统经验片段 · 踩坑记录 · 提示词资产
🎯 设计原则
主力不换、专事专办、知识不丢。Claude Code 作为"主驾驶"负责全流程编排和最终代码输出；DeepSeek/Qwen 在特定环节作为"专家顾问"介入；open-code-review 作为"质量门禁"自动把关；企业知识库和个人记忆确保每次对话都站在历史积累之上，而不是从零开始。
一、工具链全景：模型与工具的定位分工
四类智能体的角色边界必须清晰。混用会导致"谁都干、谁都干不好"的局面。以下按照职责 → 适用场景 → 调用时机三个维度精确分工。
1.1 Claude Code —— 主力 Agent（全流程驾驶员）
| 维度 | 说明 |
|---|---|
| 核心职责 | 流程编排、需求理解、代码生成、重构、测试编写、文档生成 —— 即完整软件工程生命周期的端到端执行 |
| 关键能力 | ① 200K 上下文窗口，可一次性加载整个项目的 CLAUDE.md + 设计规范 + 相关源码 ② 工具调用（读文件、写文件、执行命令、Git 操作）实现闭环执行，不只是"建议"而是"直接做" ③ Agent 模式可启动子 Agent 并行处理独立子任务 ④ 支持 Plan Mode 先规划再执行 |
| 调用时机 | 全程在线。从需求分析到代码提交，Claude Code 始终作为主控台。仅在特定子任务时调度其他模型 |
| 配置要点 | 项目根目录维护 CLAUDE.md（项目规约）+ .claude/design-tokens.md（设计规范）+ .claude/settings.json（权限与 Hook），确保每个新会话自动加载完整上下文 |
1.2 DeepSeek —— 深度推理专家
| 维度 | 说明 |
|---|---|
| 核心职责 | 复杂逻辑推理、算法设计验证、长文本代码 diff 分析、架构决策的"第二意见" |
| 关键能力 | ① 推理链（Chain-of-Thought）深度出色，适合多步骤逻辑推导（如复杂业务规则校验、状态机设计） ② 完全免费/极低成本，适合大规模批量调用 ③ 开源模型可私有化部署，数据不出企业内网 |
| 调用时机 | ① 复杂算法设计时，将问题描述同时发送给 Claude Code 和 DeepSeek，对比方案后择优 ② 大批量代码审查场景（如全量遗留代码分析），利用 DeepSeek 低成本优势做第一轮粗筛 ③ 需要私有化部署的场景（涉密项目），以 DeepSeek 本地部署替代云端模型 |
| 集成方式 | 通过 DeepSeek API（api.deepseek.com）或本地 Ollama/vLLM 部署。Claude Code 通过 Bash 工具调用 curl 或 Python 脚本访问 |
1.3 通义千问（Qwen）—— 长文档与中文场景专家
| 维度 | 说明 |
|---|---|
| 核心职责 | 超长文档（百万 Token 级）分析、中文技术文档撰写、企业知识库问答、私有化部署的备用主力 |
| 关键能力 | ① 百万级上下文窗口（Qwen3-235B），适合一次性加载完整需求规格说明书 + 全部接口文档 + 历史方案 ② 中文理解和生成质量在国产模型中领先，适合面向客户/监管的中文文档 ③ 阿里云百炼平台提供企业级 API 和私有化部署方案 |
| 调用时机 | ① 招标文件/需求规格书解读（200+ 页），Qwen 一次性全文加载并提取关键需求项 ② 生成面向客户的中文技术方案、验收文档 ③ 作为企业知识库的 RAG 底座模型（Qwen + 向量数据库），回答"历史类似项目怎么做的" |
| 集成方式 | 通过阿里云百炼 API 或本地 vLLM 部署。知识库场景推荐使用阿里云百炼内置的 RAG 能力或 LangChain-ChatGLM + Qwen 私部署方案 |
1.4 alibaba-group/open-code-review —— 自动化代码质量门禁
| 维度 | 说明 |
|---|---|
| 核心职责 | 基于阿里巴巴 Java/前端开发规约的自动化静态代码审查，作为 CI/CD 流水线的质量门禁 |
| 关键能力 | ① 内置阿里 P3C 规约（《阿里巴巴 Java 开发手册》）的全部检查规则 ② 支持 Java、JavaScript/TypeScript、Vue 等多语言 ③ GitHub Actions / GitLab CI 原生集成，PR 提交自动触发审查 ④ 可自定义规则扩展 |
| 调用时机 | 每次 Pull Request 提交自动触发。作为 CI 流水线的第一道门禁：open-code-review 通过 → Claude Code 深度审查 → 人工 Review。三层递进式质量管控 |
| 集成方式 | GitHub Actions 配置：alibaba-group/open-code-review@v1，配合 .code.yml 自定义规则。审查结果以 PR Comment 形式呈现，阻断不合规代码合并 |
1.5 模型调度决策矩阵
表：什么场景用哪个模型 —— 一表决策
| 场景 | 主力模型 | 辅助模型 | 原因 |
|---|---|---|---|
| 日常编码（CRUD/业务逻辑） | Claude Code | — | Claude 代码生成质量最高，直接产出可用代码 |
| 复杂算法设计 | Claude Code | DeepSeek | 双模型并行推理，取最优方案 |
| 遗留系统大规模代码分析 | DeepSeek | Claude Code | DeepSeek 零成本批量分析，Claude 精读关键路径 |
| 200+ 页招标文件解读 | Qwen | Claude Code | Qwen 百万 Token 一次性全量加载，Claude 做结构化提取 |
| 中文技术方案/验收文档 | Qwen | Claude Code | Qwen 中文表达更自然，Claude 做技术内容核验 |
| 代码规范检查 | open-code-review | Claude Code | 规则引擎秒级扫描，Claude 做语义级深度审查 |
| 架构设计评审 | Claude Code | DeepSeek | Claude 主导设计，DeepSeek 做"反方辩手"挑刺 |
| 知识库问答 | Qwen | 向量数据库 | Qwen + RAG 是本场景的最优组合 |
二、项目类型分流：新项目 vs 老项目维护
这是所有后续流程的前置判断。新项目（Greenfield）和老项目维护（Brownfield）的 AI 工作流完全不同——用错了模式，轻则效率减半，重则引入破坏性变更。本节定义了分流规则、脚手架体系、以及两类项目在工具/模型使用上的根本差异。
2.1 判断标准与分流决策
表：新项目 vs 老项目维护的判断矩阵
| 判断维度 | 🆕 新项目（Greenfield） | 🔧 老项目维护（Brownfield） |
|---|---|---|
| 典型场景 | 全新客户项目启动、新产品线研发、独立功能模块从零搭建、POC 原型验证 | 现有系统 Bug 修复、功能增强、技术栈升级、性能优化、遗留系统改造 |
| 代码基数 | 零或极少（仅脚手架模板） | 已有 1 万 ~ 100 万+ 行代码 |
| 核心挑战 | 快速搭建合规架构、避免"过度设计"和"设计不足"的两极摇摆 | 理解现有代码的隐式约定、"不敢改"的心理障碍、修改影响面不可控 |
| AI 生成代码占比 | 70-90% | 15-40%（修改点周围的局部生成） |
| 主要风险 | AI 生成的代码不符合团队规范、架构不一致 | AI 不理解历史上下文、引入回归 Bug、破坏隐式依赖 |
| CLAUDE.md 依赖度 | 极高（规范文件 = AI 的"唯一真相源"） | 高（但需补充遗留系统的非标准约定） |
图：项目类型分流决策树
📋 收到开发任务
↓ 第一问
是否需要新建 Git 仓库？
↙ YES ↙ ↘ NO ↘
🆕 新项目流程脚手架生成 → Plan → 编码 → 审查
🔧 老项目维护流程代码理解 → 影响分析 → 增量修改 → 回归验证
2.2 开发脚手架体系（新项目专用）
新项目的起点不是空白目录，而是预置了团队全部约定的开发脚手架。脚手架 = 项目模板 + 代码生成器 + 内置规范。Claude Code 在脚手架基础上生成代码，能天然保证架构一致性。
表：脚手架应包含的四个层次
| 层次 | 内容 | 具体包含物 | AI 如何使用 |
|---|---|---|---|
| L1: 项目骨架 | 目录结构 + 构建配置 + 基础依赖 | Maven/Gradle 配置、Dockerfile、CI 流水线模板、Helm Chart、日志配置、application.yml 多环境骨架 | Claude Code 在生成代码前先 Read 脚手架文件，确保新代码的包结构、依赖版本、配置命名与脚手架一致 |
| L2: 架构基类 | 通用基类 + 切面 + 拦截器 | BaseController / BaseService / BaseEntity、全局异常处理器、统一返回体 Result<T>、分页基类、审计字段自动填充 | Claude Code 生成的 Controller/Service/Entity 必须继承对应基类，不自行发明新的返回格式或异常处理模式 |
| L3: 代码规范 | CLAUDE.md + 设计 Token + 编码规约 | 命名约定、包结构约定、注释模板、API 设计规范、数据库命名规范、Git Commit 规范 | Claude Code 自动加载 CLAUDE.md，每次生成代码前将其作为系统提示。open-code-review 在 CI 阶段二次校验 |
| L4: 示例模块 | 一个完整的 CRUD 示例（"样板间"） | 一个完整的用户管理模块（Entity → Mapper → Service → Controller → Test → 前端页面），作为所有新模块的参考实现 | Claude Code 生成新模块时，开发者可以说"参照 UserModule 的模式实现 XxxModule"，AI 自动对齐风格 |
📐 脚手架的实际形态
脚手架可以是一个 Git 仓库模板（团队维护一个 spring-boot-scaffold 仓库），也可以是 Maven Archetype / Yeoman Generator / 自定义 CLI。关键不是形式，是每次新项目都从脚手架起，不允许从空白目录开始。
对于 Claude Code 而言，脚手架的价值在于：① 所有基类和规范文件在项目启动时就已经存在，AI 可以立即 Read 并遵循 ② 示例模块提供了"正确答案"的参考 ③ CI 配置就绪，第一行代码提交就能跑通完整流水线。
2.3 两类项目的工具/模型使用差异
表：新项目 vs 老项目的工具分配策略
| 环节 | 🆕 新项目策略 | 🔧 老项目维护策略 |
|---|---|---|
| 主力 Agent | Claude Code 全程主导：从脚手架起生成全部代码。几乎不需要切换模型 | Claude Code 局部介入：先理解现有代码，再做增量修改。需要频繁在 Claude Code 和人工分析之间切换 |
| DeepSeek 角色 | "反方辩手"：并行评审 Claude Code 生成的架构方案（角色与 1.2 节一致） | "代码考古学家"：利用零成本优势，批量分析整个遗留代码库的模块依赖、循环引用、死代码，输出重构优先级清单 |
| Qwen 角色 | 长文档分析 + 知识库 RAG 检索历史同类项目方案（角色与 1.3 节一致） | "遗留系统解读器"：利用百万 Token 上下文窗口，一次性加载整个模块的源码 + 注释 + 提交历史，输出模块职责描述和隐式约定清单 |
| open-code-review | 从第一次提交即启用，确保新代码 100% 合规 | 增量模式：只检查本次修改的文件（通过 filter=changed），避免对遗留代码的"历史债务"产生噪音告警 |
⚠️ 老项目维护的"三大铁律"
铁律 1：先读后改。在让 Claude Code 修改任何代码之前，必须先让它 Read 目标文件 + 所有调用方/被调用方文件。禁止在未建立上下文的情况下直接生成修改。推荐做法：让 Claude Code 先输出一份"修改影响分析报告"，确认后再动手。
铁律 2：测试先行。修改老代码前，先让 Claude Code 为修改目标区域生成（或补充）单元测试。确保改动前后的行为差异能被自动检测。这是防止回归 Bug 的最后防线。
铁律 3：小步提交。老项目的一次修改不超过 5 个文件、不超过 200 行 diff。超过这个规模，拆成多个小 PR、依次合并。大爆炸式修改在老项目中几乎一定会引入 Bug。
三、企业知识库架构：RAG + 记忆双轨制
AI 辅助开发的最大瓶颈不是模型能力，而是模型不了解你的项目。每次对话从零开始——不知道你的架构规范、不记得上次怎么解决的、不理解公司特有的业务规则。企业知识库和个人记忆系统就是解决这个问题的双轨方案。
2.1 知识库分层架构
🔍 检索增强生成（RAG）查询 → 向量检索 → 重排序 → 注入 Prompt
↓ 索引
📋 L1: 项目规约CLAUDE.md · 编码规范 · 设计 Token
📦 L2: 架构资产架构图 · 接口文档 · 数据模型
📝 L3: 历史方案历史售前方案 · FS 文档 · 技术决策记录
🔧 L4: 踩坑经验Bug 修复记录 · 性能优化案例 · 兼容性问题
表：知识库四层内容与更新机制
| 层级 | 内容 | 格式 | 更新频率 | 负责人 |
|---|---|---|---|---|
| L1 项目规约 | CLAUDE.md、编码规范、设计 Token、命名约定、Git 工作流 | Markdown / YAML | 架构变更时 | 技术负责人 |
| L2 架构资产 | 系统架构图、模块依赖关系、接口协议定义（OpenAPI/Protobuf）、数据库 ER 图、领域模型 | 结构化文档 + 代码注解 | 每个迭代 | 架构师 + 开发 Lead |
| L3 历史方案 | 历史项目的售前方案、FS 文档、ADR（架构决策记录）、技术选型论证、客户特定需求模式 | PDF / Markdown / 向量化文本 | 项目结项时 | PM + 应用顾问 |
| L4 踩坑经验 | Bug 根因分析、性能优化案例、兼容性问题及解决方案、部署踩坑记录、第三方库版本兼容性 | Markdown（结构化标签） | 持续积累 | 全员 |
2.2 RAG 技术方案选型
表：企业知识库 RAG 方案对比
| 方案 | 适用规模 | 优势 | 劣势 | 推荐场景 |
|---|---|---|---|---|
| 阿里云百炼 + Qwen | 中大型企业 | 开箱即用、免运维、企业级 SLA、与阿里云生态集成 | 有月度费用、数据在云端 | 已有阿里云账号体系的企业 |
| Dify + DeepSeek/Qwen | 中小团队 | 开源、可视化编排、支持多种向量数据库、权限管理 | 需自行部署维护 | 需要私有化部署且无专业 ML 团队 |
| LangChain + Chroma + Qwen | 技术团队自建 | 完全可控、可深度定制 Pipeline | 开发工作量大、需 ML 能力 | 有 ML 工程师的团队 |
| Claude Code 项目文件（CLAUDE.md） | 所有项目 | 零成本、随 Git 版本控制、Claude 自动加载 | 容量有限、仅当前项目 | 每个项目的基础配置 |
💡 推荐起步方案
第一阶段（0-2 周）：完善每个项目的 CLAUDE.md + .claude/design-tokens.md，确保 Claude Code 启动即加载项目上下文。
第二阶段（2-6 周）：搭建 Dify + Qwen 知识库，导入 L1-L3 层内容。为售前团队提供"历史方案检索"能力。
第三阶段（6-12 周）：建立 L4 踩坑经验持续积累机制，开发团队每个 Bug 修复后自动生成结构化经验条目并入库。
2.3 个人记忆系统
企业知识库解决"团队共知"，个人记忆解决"个人经验"。Claude Code 内置的 Memory 系统（~/.claude/projects/）可按项目维度持久化个人偏好和踩坑经验。详见第六章。
四、开发流程一：需求分析与方案设计
从原始需求到可执行的技术方案，传统流程需要 1-3 周。AI 增强流程可将周期压缩 50-70%，且方案质量更稳定（不会遗漏关键维度）。
3.1 流程总览
1
需求文档加载与分析
将招标文件/需求规格书/客户访谈记录导入。200 页以上文档由 Qwen 首次全量加载并提取结构化需求清单。
Qwen 长文档Claude Code2
需求结构化拆解
Claude Code 将 Qwen 的提取结果转化为功能需求矩阵 + 非功能需求清单 + 约束条件清单。与历史项目需求做相似度匹配。
Claude Code知识库 RAG3
技术方案设计
基于需求矩阵，Claude Code 生成 2-3 个技术方案选项，含架构图（Mermaid）、技术选型理由、成本估算。DeepSeek 并行评审每个方案。
Claude CodeDeepSeek 评审4
方案评审与定稿
技术 Lead 对比 Claude 和 DeepSeek 的意见，做最终决策。Claude Code 根据决策生成正式方案文档（含架构图、接口定义、里程碑计划）。
Claude Code人工决策3.2 详细操作步骤
Step 1: 需求文档加载与分析
| 子步骤 | 操作 | 工具 | 预计耗时 |
|---|---|---|---|
| 1.1 | 将需求文档（PDF/Word/Markdown）放入项目 docs/requirements/ 目录 | 文件系统 | 2 分钟 |
| 1.2 | 若文档超过 50 页，调用 Qwen API（百万 Token 上下文）做全文结构提取：功能需求、非功能需求、约束条件、验收标准 | Qwen API | 3-5 分钟 |
| 1.3 | Claude Code 读取 Qwen 提取结果 + 原始文档关键章节（通过 Read 工具），对话式澄清模糊需求 | Claude Code | 15-30 分钟 |
| 1.4 | 输出：结构化需求清单（Markdown 表格），含需求编号、描述、优先级、关联依赖、验收标准 | Claude Code Write | 5 分钟 |
🔑 关键技巧：需求对话式澄清
Claude Code 读取需求后，不应直接开始设计。先进入澄清对话模式："我理解你要做 X，但以下 3 个方面需要确认：① 并发用户量预估？② 与现有系统 X 的集成方式？③ 数据合规要求？" —— 这模拟了资深架构师的"需求反问"能力。
Step 2: 需求结构化拆解
| 子步骤 | 操作 | 工具 | 预计耗时 |
|---|---|---|---|
| 2.1 | Claude Code 生成功能需求矩阵（FR-Matrix）：功能模块 × 优先级 × 技术复杂度 × 预估人天 | Claude Code | 10 分钟 |
| 2.2 | 检索知识库中历史类似项目的需求矩阵，标注可复用模块 | 知识库 RAG（Qwen） | 3 分钟 |
| 2.3 | 生成非功能需求清单：性能、安全、可用性、可扩展性、合规性 —— 每个维度给出具体指标 | Claude Code | 10 分钟 |
| 2.4 | Claude Code 输出需求覆盖度评估："你的需求文档覆盖了 X% 的典型场景，以下场景缺失需要补充：..." | Claude Code | 5 分钟 |
Step 3-4: 方案设计与评审
Claude Code 基于项目 CLAUDE.md 中的架构规范，生成 2-3 个技术方案。每个方案包含：架构图（Mermaid 格式，可直接渲染）、技术选型理由、关键模块设计、数据流、成本估算。
DeepSeek 的"反方辩手"角色：将 Claude Code 生成的方案发送给 DeepSeek，要求它找出方案中的"逻辑漏洞、过度设计、未考虑的边界条件"。这种"对抗式评审"能显著提升方案的健壮性。
✅ 方案设计阶段的质量检查清单
- ☑ 架构图是否明确标注了所有外部系统集成点？
- ☑ 是否考虑了数据量增长（当前 100 倍）的可扩展性？
- ☑ 是否包含了安全攻击面的分析？
- ☑ 是否标注了技术选型中"可替换"和"不可替换"的组件？
- ☑ 是否有明确的"不做什么"（Out of Scope）声明？
- ☑ 成本和时间的估算是否有 ±30% 的置信区间？
3.3 实操示例：从一份招标文件到可执行的技术方案
以下是一个完整实操演示：某制造企业 MES 系统招标项目（招标文件 180 页 PDF），展示如何用本流程在 1.5 天内完成传统需要 1 周的需求分析+方案设计。
示例 Step 1: Qwen 长文档首次提取
📋 操作：调用 Qwen 处理 180 页招标文件
开发者将招标 PDF 转换为文本后，通过 Qwen API（或阿里云百炼工作台）发送以下提示：
# 提示词（发送给 Qwen，利用百万 Token 上下文窗口）
你是一位资深 MES 系统架构师。请通读以下招标文件全文，按结构化格式提取：
1. 功能需求清单
- 每条需求格式：需求编号 | 功能模块 | 需求描述 | 优先级(必选/可选/加分) | 关联系统
2. 非功能需求
- 性能指标（并发数、响应时间、数据量）
- 安全要求（等保级别、加密标准、审计要求）
- 可用性要求（SLA、RTO、RPO）
3. 评分规则提取
- 技术分评分项及分值
- 商务分评分项及分值
- 加分项清单
4. 隐性要求
- 标书中未明确写出但行业惯例必须具备的能力
- 可能导致废标的隐藏条款
招标文件全文如下：
[粘贴 180 页招标文件文本]
你是一位资深 MES 系统架构师。请通读以下招标文件全文，按结构化格式提取：
1. 功能需求清单
- 每条需求格式：需求编号 | 功能模块 | 需求描述 | 优先级(必选/可选/加分) | 关联系统
2. 非功能需求
- 性能指标（并发数、响应时间、数据量）
- 安全要求（等保级别、加密标准、审计要求）
- 可用性要求（SLA、RTO、RPO）
3. 评分规则提取
- 技术分评分项及分值
- 商务分评分项及分值
- 加分项清单
4. 隐性要求
- 标书中未明确写出但行业惯例必须具备的能力
- 可能导致废标的隐藏条款
招标文件全文如下：
[粘贴 180 页招标文件文本]
预计耗时：3-5 分钟（Qwen 返回结构化 JSON/Markdown）
示例 Step 2: Claude Code 需求澄清与补充
💬 开发者对 Claude Code 说（实际 Prompt）
# 在 Claude Code 对话中直接输入
我正在进行一个 MES 项目的售前方案，招标文件的核心需求 Qwen 已经提取出来了，
在项目 docs/requirements/mes-bid-extracted.md 里。
请帮我做以下工作：
1. 读取提取结果，检查是否有遗漏的关键需求（特别是制造业 MES 常见的
工单管理、设备联网、质量追溯、物料拉动这四个模块）
2. 生成 FR-Matrix（功能需求矩阵），按 MoSCoW 方法标注优先级
3. 查询知识库中"历史类似 MES 项目"的方案，标注可复用模块
4. 对不明确的需求列出澄清问题清单（我下午要和客户开会确认）
请先进入 Plan Mode 规划你的工作步骤，我确认后再开始。
我正在进行一个 MES 项目的售前方案，招标文件的核心需求 Qwen 已经提取出来了，
在项目 docs/requirements/mes-bid-extracted.md 里。
请帮我做以下工作：
1. 读取提取结果，检查是否有遗漏的关键需求（特别是制造业 MES 常见的
工单管理、设备联网、质量追溯、物料拉动这四个模块）
2. 生成 FR-Matrix（功能需求矩阵），按 MoSCoW 方法标注优先级
3. 查询知识库中"历史类似 MES 项目"的方案，标注可复用模块
4. 对不明确的需求列出澄清问题清单（我下午要和客户开会确认）
请先进入 Plan Mode 规划你的工作步骤，我确认后再开始。
✅ Claude Code Plan Mode 输出示例
Plan: MES 招标需求分析与方案设计
Step 1: Read docs/requirements/mes-bid-extracted.md
Step 2: 对比 MES 行业标准功能清单（ISA-95 模型），标注缺失项
Step 3: 生成 FR-Matrix（Markdown 表格，含 MoSCoW 优先级）
Step 4: 搜索项目 Memory 和知识库中的历史 MES 项目方案
Step 5: 生成客户澄清问题清单（按紧急程度排序）
Step 6: 输出全部结果到 docs/output/ 目录
涉及文件:
- READ: docs/requirements/mes-bid-extracted.md
- READ: CLAUDE.md（编码和架构规范）
- SEARCH: memory/（历史 MES 项目经验）
- WRITE: docs/output/FR-Matrix.md
- WRITE: docs/output/clarification-questions.md
确认后我开始执行。
Step 1: Read docs/requirements/mes-bid-extracted.md
Step 2: 对比 MES 行业标准功能清单（ISA-95 模型），标注缺失项
Step 3: 生成 FR-Matrix（Markdown 表格，含 MoSCoW 优先级）
Step 4: 搜索项目 Memory 和知识库中的历史 MES 项目方案
Step 5: 生成客户澄清问题清单（按紧急程度排序）
Step 6: 输出全部结果到 docs/output/ 目录
涉及文件:
- READ: docs/requirements/mes-bid-extracted.md
- READ: CLAUDE.md（编码和架构规范）
- SEARCH: memory/（历史 MES 项目经验）
- WRITE: docs/output/FR-Matrix.md
- WRITE: docs/output/clarification-questions.md
确认后我开始执行。
示例 Step 3: Claude Code 生成方案 + DeepSeek 对抗评审
📋 Claude Code 方案生成 Prompt
# 需求确认后，对 Claude Code 说：
基于确认后的需求矩阵，请生成两个技术方案选项：
方案A（稳健型）：基于 Spring Boot + Vue3 自研，
使用成熟的工业协议适配层（Modbus/OPC UA），数据库用 PostgreSQL + TimescaleDB
方案B（激进型）：基于开源 MES 框架（如 OpenMES）+ 二次开发，
前端用低代码平台加速交付
每个方案需包含：
1. 架构图（Mermaid 格式）
2. 技术选型理由（含替代方案对比）
3. 关键模块设计（至少含工单管理、设备联网、质量追溯）
4. 数据流图
5. 人天估算（±30% 置信区间）
6. 风险清单（Top 5 风险 + 应对措施）
输出到 docs/output/solution-option-A.md 和 solution-option-B.md
基于确认后的需求矩阵，请生成两个技术方案选项：
方案A（稳健型）：基于 Spring Boot + Vue3 自研，
使用成熟的工业协议适配层（Modbus/OPC UA），数据库用 PostgreSQL + TimescaleDB
方案B（激进型）：基于开源 MES 框架（如 OpenMES）+ 二次开发，
前端用低代码平台加速交付
每个方案需包含：
1. 架构图（Mermaid 格式）
2. 技术选型理由（含替代方案对比）
3. 关键模块设计（至少含工单管理、设备联网、质量追溯）
4. 数据流图
5. 人天估算（±30% 置信区间）
6. 风险清单（Top 5 风险 + 应对措施）
输出到 docs/output/solution-option-A.md 和 solution-option-B.md
🔴 DeepSeek 对抗评审 Prompt（同时发送）
# 将 Claude Code 生成的方案发送给 DeepSeek：
你是一位严苛的技术评审专家。请对以下两份 MES 技术方案进行"攻击性评审"：
评审维度：
1. 逻辑漏洞：方案中有哪些"想当然"的假设可能在落地时出错？
2. 过度设计：哪些地方为追求"技术先进性"而引入了不必要的复杂度？
3. 边界条件遗漏：高频并发、网络断线、设备异构、数据过期等场景是否覆盖？
4. 成本低估：人天估算中哪些模块明显偏乐观？
5. 替代方案：哪些技术选型有更好的替代品（请具体说明）？
请逐条列出问题，每条标注严重程度（🔴致命/🟡重要/🟢建议）。
不要只说"有问题"，要给出具体改进方向。
[粘贴 Claude Code 生成的方案全文]
你是一位严苛的技术评审专家。请对以下两份 MES 技术方案进行"攻击性评审"：
评审维度：
1. 逻辑漏洞：方案中有哪些"想当然"的假设可能在落地时出错？
2. 过度设计：哪些地方为追求"技术先进性"而引入了不必要的复杂度？
3. 边界条件遗漏：高频并发、网络断线、设备异构、数据过期等场景是否覆盖？
4. 成本低估：人天估算中哪些模块明显偏乐观？
5. 替代方案：哪些技术选型有更好的替代品（请具体说明）？
请逐条列出问题，每条标注严重程度（🔴致命/🟡重要/🟢建议）。
不要只说"有问题"，要给出具体改进方向。
[粘贴 Claude Code 生成的方案全文]
✅ 综合评审后的人工决策
技术 Lead 拿到 Claude Code 的方案 + DeepSeek 的挑刺意见后，做最终决策。例如：采纳方案 A 的技术架构，但采用低代码平台做报表和看板（方案 B 的优点）。最后由 Claude Code 根据决策整合为最终方案文档。
全程耗时：方案生成 20 分钟 + DeepSeek 评审 5 分钟 + 人工决策 30 分钟 = 不到 1 小时（传统方式需要 2-3 天）。
五、开发流程二：编码实现与代码审查
这是 AI 参与度最高的环节。Claude Code 在此阶段充当"AI 程序员"——不是聊天框里的建议者，而是直接操作文件系统、执行命令、提交代码的 Agent。
4.1 编码工作流（单任务）
1
任务启动
开发者向 Claude Code 描述需求（自然语言 + 需求编号引用）。Claude Code 自动读取相关源文件，进入 Plan Mode 输出实现计划。
Claude Code Plan Mode2
方案确认
开发者审核 Plan，确认架构选型和文件范围。必要时调用 DeepSeek 做"第二意见"验证。
人工确认DeepSeek（可选）3
编码实现
Claude Code 逐文件编写代码，同时编写单元测试。每完成一个模块，自动运行测试验证。引用知识库中的编码规范确保风格一致。
Claude Code Edit/WriteBash 运行测试4
自动审查
代码提交 PR 前，open-code-review 自动运行静态检查。Claude Code 执行语义级深度审查（逻辑错误、性能隐患、安全漏洞）。
open-code-reviewClaude Code4.2 三层代码审查体系
表：递进式三层代码审查机制
| 层级 | 工具 | 检查内容 | 触发时机 | 阻断级别 |
|---|---|---|---|---|
| L1: 规约检查 | alibaba-group/open-code-review | 命名规范、代码格式、注释密度、异常处理模式、资源关闭、集合操作安全、并发风险模式 | 每次 git push / PR 创建 | 强制阻断（不合规代码不允许进入人工 Review） |
| L2: 语义审查 | Claude Code（/code-review） | 逻辑正确性、边界条件覆盖、性能隐患（N+1 查询、内存泄漏、锁竞争）、安全漏洞（注入、越权、敏感信息泄露）、代码可读性与设计模式合理性 | L1 通过后 | 建议阻断（严重问题自动阻止合并，建议性问题标注后放行） |
| L3: 人工审查 | 开发者 / Tech Lead | 业务逻辑正确性、架构一致性、跨模块影响评估、用户体验合理性 | L2 通过后 | 最终决策（聚焦业务和架构，不再浪费时间查代码风格） |
⚙️ open-code-review CI 集成配置
在项目根目录创建 .github/workflows/code-review.yml：
name: Code Review
on: [pull_request]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: alibaba-group/open-code-review@v1
with:
languages: java,javascript,typescript,vue
severity: error,warning
on: [pull_request]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: alibaba-group/open-code-review@v1
with:
languages: java,javascript,typescript,vue
severity: error,warning
4.3 多 Agent 并行开发模式
对于大型功能（涉及 5+ 文件、跨多个模块），利用 Claude Code 的 Agent 工具启动多个子 Agent 并行工作：
| 模式 | 适用场景 | 并发数 | 示例 |
|---|---|---|---|
| 前后端分离 | 新增 CRUD 功能，前端页面 + 后端 API 同时开发 | 2 个 Agent | Agent A 写后端 API + 测试，Agent B 写前端页面 + 联调 |
| 模块拆分 | 大型功能涉及多个独立模块（如订单模块 + 支付模块 + 通知模块） | 3-5 个 Agent | 每个模块独立 Agent，主 Agent 负责接口定义和最终集成 |
| 测试并行 | 核心功能开发完成后，单元测试 + 集成测试 + E2E 测试并行编写 | 3 个 Agent | Agent A 单元测试，Agent B 集成测试，Agent C E2E 测试 |
⚠️ 并行开发的注意事项
① 接口先行：主 Agent 必须先定义好模块间的接口契约（API 签名、数据模型），子 Agent 再并行开发。
② 独立工作区：使用 Git Worktree 为每个子 Agent 提供独立工作区，避免文件冲突。
③ 合并由主 Agent 统一执行：子 Agent 只产出代码，不自行合并。主 Agent 负责 Review 子 Agent 产出并集成。
4.4 实操示例：实现一个带审批流的工单管理模块
以下演示用 Claude Code 从零实现一个工单审批流功能（Spring Boot + Vue3），并走通 Plan → 编码 → 审查 → 记忆沉淀的完整链路。
示例 Step 1: 任务启动（Plan Mode）
💬 开发者对 Claude Code 的初始 Prompt
# 需求背景（引用 FR-Matrix 中的需求编号）
需求编号 FR-WO-003：工单审批流
功能描述：
- 工单创建后进入审批流程：班组长初审 → 车间主任复审 → 生产部长终审
- 支持审批通过/驳回/转审三种操作
- 驳回时需填写驳回原因，工单退回至创建人修改
- 审批记录需完整保留（谁在什么时间做了什么操作）
- 审批超时 48 小时自动提醒
技术约束：
- 后端：Spring Boot 2.7 + MyBatis-Plus + MySQL
- 前端：Vue3 + Element Plus
- 审批流引擎：Flowable（已在项目中引入）
- 编码规范：参考 CLAUDE.md
请先进入 Plan Mode，给我看你的实现计划。
需求编号 FR-WO-003：工单审批流
功能描述：
- 工单创建后进入审批流程：班组长初审 → 车间主任复审 → 生产部长终审
- 支持审批通过/驳回/转审三种操作
- 驳回时需填写驳回原因，工单退回至创建人修改
- 审批记录需完整保留（谁在什么时间做了什么操作）
- 审批超时 48 小时自动提醒
技术约束：
- 后端：Spring Boot 2.7 + MyBatis-Plus + MySQL
- 前端：Vue3 + Element Plus
- 审批流引擎：Flowable（已在项目中引入）
- 编码规范：参考 CLAUDE.md
请先进入 Plan Mode，给我看你的实现计划。
✅ Claude Code Plan Mode 输出
Plan: 工单审批流 FR-WO-003
Step 1 - 数据模型:
- READ: src/main/java/.../entity/WorkOrder.java (现有工单实体)
- READ: src/main/resources/db/migration/ (现有表结构)
- WRITE: 新增审批流相关表 (approval_record, approval_config)
- WRITE: 新增实体类 + DTO
Step 2 - 审批流引擎:
- WRITE: Flowable 流程定义 (BPMN XML)
- WRITE: ApprovalService (启动流程/完成任务/查询待办)
- WRITE: ApprovalCallback (审批通过后的工单状态更新)
Step 3 - Controller + 接口:
- WRITE: ApprovalController (REST API)
- 接口：POST /api/workorder/{id}/submit, POST /api/approval/{taskId}/complete,
GET /api/approval/pending, GET /api/workorder/{id}/approval-history
Step 4 - 前端:
- WRITE: ApprovalPanel.vue (审批操作面板)
- WRITE: ApprovalHistory.vue (审批历程时间线)
- WRITE: WorkOrderDetail.vue (集成审批面板到工单详情页)
Step 5 - 测试:
- WRITE: ApprovalServiceTest.java (单元测试: 正常审批/驳回/转审/超时)
- WRITE: ApprovalControllerTest.java (接口测试)
Step 6 - 审查:
- 自检 open-code-review 规则
- 运行完整测试套件
涉及文件: ~12 个文件
预计耗时: Claude Code 编码 30-45 分钟，人工审查 15 分钟
确认后我开始执行。
Step 1 - 数据模型:
- READ: src/main/java/.../entity/WorkOrder.java (现有工单实体)
- READ: src/main/resources/db/migration/ (现有表结构)
- WRITE: 新增审批流相关表 (approval_record, approval_config)
- WRITE: 新增实体类 + DTO
Step 2 - 审批流引擎:
- WRITE: Flowable 流程定义 (BPMN XML)
- WRITE: ApprovalService (启动流程/完成任务/查询待办)
- WRITE: ApprovalCallback (审批通过后的工单状态更新)
Step 3 - Controller + 接口:
- WRITE: ApprovalController (REST API)
- 接口：POST /api/workorder/{id}/submit, POST /api/approval/{taskId}/complete,
GET /api/approval/pending, GET /api/workorder/{id}/approval-history
Step 4 - 前端:
- WRITE: ApprovalPanel.vue (审批操作面板)
- WRITE: ApprovalHistory.vue (审批历程时间线)
- WRITE: WorkOrderDetail.vue (集成审批面板到工单详情页)
Step 5 - 测试:
- WRITE: ApprovalServiceTest.java (单元测试: 正常审批/驳回/转审/超时)
- WRITE: ApprovalControllerTest.java (接口测试)
Step 6 - 审查:
- 自检 open-code-review 规则
- 运行完整测试套件
涉及文件: ~12 个文件
预计耗时: Claude Code 编码 30-45 分钟，人工审查 15 分钟
确认后我开始执行。
示例 Step 2: 编码实现中的关键交互
🔑 开发者如何引导 Claude Code 写出高质量代码
| 引导技巧 | 不好的说法 | 好的说法 |
|---|---|---|
| 引用规范 | "写个审批接口" | "写审批接口，返回格式统一用 Result<T> 包装，异常走 GlobalExceptionHandler（参考 CLAUDE.md 第 3 节）" |
| 给出上下文 | "加个审批记录表" | "加审批记录表，字段风格参照现有的 work_order 表（用下划线命名、必须有 create_time 和 update_time、逻辑删除用 is_deleted）" |
| 边界条件前置 | "实现审批超时提醒" | "审批超时 48h 自动提醒，注意：① 只提醒当前审批节点的人 ② 已驳回/已转审的不要再提醒 ③ 提醒频率：超时后每 4h 提醒一次，最多 3 次" |
| 确认而非假设 | "审批驳回后直接改状态" | "驳回时工单状态改为 REJECTED，但工单创建人修改后重新提交时，是走原审批流从头开始还是从当前节点继续？如果是前者，请生成新的流程实例" |
示例 Step 3: Claude Code 生成的代码片段（后端核心逻辑）
// ===== ApprovalService.java（Claude Code 自动生成）=====
@Service
@Slf4j
public class ApprovalService {
@Autowired
private RuntimeService runtimeService;
@Autowired
private TaskService taskService;
// 提交工单并启动审批流
@Transactional(rollbackFor = Exception.class)
public void submitForApproval(Long workOrderId) {
WorkOrder wo = workOrderMapper.selectById(workOrderId);
if (wo == null) {
throw new BusinessException("工单不存在: " + workOrderId);
}
if (wo.getStatus() != WorkOrderStatus.DRAFT) {
throw new BusinessException("只有草稿状态的工单才能提交审批");
}
// 启动 Flowable 流程实例
Map<String, Object> vars = new HashMap<>();
vars.put("workOrderId", workOrderId);
vars.put("submitterId", SecurityUtils.getCurrentUserId());
vars.put("urgencyLevel", wo.getUrgencyLevel());
ProcessInstance pi = runtimeService.startProcessInstanceByKey(
"work-order-approval",
String.valueOf(workOrderId),
vars
);
// 更新工单状态
wo.setStatus(WorkOrderStatus.PENDING_APPROVAL);
wo.setProcessInstanceId(pi.getId());
workOrderMapper.updateById(wo);
log.info("工单 {} 审批流已启动，流程实例: {}", workOrderId, pi.getId());
}
// 完成审批任务
@Transactional(rollbackFor = Exception.class)
public void completeTask(ApprovalRequest req) {
Task task = taskService.createTaskQuery()
.taskId(req.getTaskId())
.singleResult();
if (task == null) {
throw new BusinessException("审批任务不存在或已被处理");
}
// 记录审批意见
ApprovalRecord record = ApprovalRecord.builder()
.workOrderId(Long.valueOf(task.getBusinessKey()))
.taskId(req.getTaskId())
.approver(SecurityUtils.getCurrentUserId())
.action(req.getAction()) // APPROVE / REJECT / TRANSFER
.comment(req.getComment())
.operateTime(LocalDateTime.now())
.build();
approvalRecordMapper.insert(record);
// 提交 Flowable 任务
Map<String, Object> vars = new HashMap<>();
vars.put("approvalResult", req.getAction());
taskService.complete(req.getTaskId(), vars);
log.info("审批任务 {} 已完成，操作: {}", req.getTaskId(), req.getAction());
}
}
@Service
@Slf4j
public class ApprovalService {
@Autowired
private RuntimeService runtimeService;
@Autowired
private TaskService taskService;
// 提交工单并启动审批流
@Transactional(rollbackFor = Exception.class)
public void submitForApproval(Long workOrderId) {
WorkOrder wo = workOrderMapper.selectById(workOrderId);
if (wo == null) {
throw new BusinessException("工单不存在: " + workOrderId);
}
if (wo.getStatus() != WorkOrderStatus.DRAFT) {
throw new BusinessException("只有草稿状态的工单才能提交审批");
}
// 启动 Flowable 流程实例
Map<String, Object> vars = new HashMap<>();
vars.put("workOrderId", workOrderId);
vars.put("submitterId", SecurityUtils.getCurrentUserId());
vars.put("urgencyLevel", wo.getUrgencyLevel());
ProcessInstance pi = runtimeService.startProcessInstanceByKey(
"work-order-approval",
String.valueOf(workOrderId),
vars
);
// 更新工单状态
wo.setStatus(WorkOrderStatus.PENDING_APPROVAL);
wo.setProcessInstanceId(pi.getId());
workOrderMapper.updateById(wo);
log.info("工单 {} 审批流已启动，流程实例: {}", workOrderId, pi.getId());
}
// 完成审批任务
@Transactional(rollbackFor = Exception.class)
public void completeTask(ApprovalRequest req) {
Task task = taskService.createTaskQuery()
.taskId(req.getTaskId())
.singleResult();
if (task == null) {
throw new BusinessException("审批任务不存在或已被处理");
}
// 记录审批意见
ApprovalRecord record = ApprovalRecord.builder()
.workOrderId(Long.valueOf(task.getBusinessKey()))
.taskId(req.getTaskId())
.approver(SecurityUtils.getCurrentUserId())
.action(req.getAction()) // APPROVE / REJECT / TRANSFER
.comment(req.getComment())
.operateTime(LocalDateTime.now())
.build();
approvalRecordMapper.insert(record);
// 提交 Flowable 任务
Map<String, Object> vars = new HashMap<>();
vars.put("approvalResult", req.getAction());
taskService.complete(req.getTaskId(), vars);
log.info("审批任务 {} 已完成，操作: {}", req.getTaskId(), req.getAction());
}
}
示例 Step 4: 三层审查的实操
L1: open-code-review 自动检查结果
代码 push 后，GitHub Actions 自动运行 open-code-review。假设发现以下问题：
❌ ERROR: ApprovalService.java:45
规则: "@Transactional 必须指定 rollbackFor = Exception.class"
当前: @Transactional (缺少 rollbackFor)
❌ ERROR: ApprovalRecord.java:12
规则: "日期字段必须使用 LocalDateTime，禁止使用 Date"
当前: private Date operateTime;
⚠️ WARNING: ApprovalController.java:23
规则: "REST 接口必须使用 @Valid 校验请求参数"
当前: public Result completeTask(ApprovalRequest req) (缺少 @Valid)
CI Status: ❌ FAILED — 2 errors, 1 warning
→ 开发者修复后重新 push，open-code-review 通过 ✅
规则: "@Transactional 必须指定 rollbackFor = Exception.class"
当前: @Transactional (缺少 rollbackFor)
❌ ERROR: ApprovalRecord.java:12
规则: "日期字段必须使用 LocalDateTime，禁止使用 Date"
当前: private Date operateTime;
⚠️ WARNING: ApprovalController.java:23
规则: "REST 接口必须使用 @Valid 校验请求参数"
当前: public Result completeTask(ApprovalRequest req) (缺少 @Valid)
CI Status: ❌ FAILED — 2 errors, 1 warning
→ 开发者修复后重新 push，open-code-review 通过 ✅
L2: Claude Code 深度审查（/code-review 命令）
# 开发者对 Claude Code 说：
/code-review
审查我刚提交的工单审批流功能，重点关注：
1. 并发安全：多人同时审批同一个工单会不会有竞态条件？
2. 事务边界：审批记录写入和 Flowable 任务完成是否在一个事务里？
3. 超时机制：48 小时超时提醒的实现方案是否合理？
4. 与现有工单模块的集成是否有破坏性变更？
# Claude Code 输出（示例）：
🔴 严重: ApprovalService.completeTask() 存在竞态条件。
两个审批人同时点"通过"时，Flowable 的 taskService.complete()
内部有乐观锁保护，但 approvalRecordMapper.insert() 在 complete()
之前执行，如果 complete() 抛出异常，审批记录将"幽灵插入"。
建议：将 insert(record) 移到 complete() 之后，或者使用
@Transactional 确保两者原子性（已满足，但顺序问题仍建议调整）。
🟡 建议: 超时提醒用 @Scheduled 每分钟扫描一次 pending 任务，
在工单量 < 1万 时可行，但建议预留 Quartz/XXL-Job 升级路径。
建议在 CLAUDE.md 中记录此技术债务。
/code-review
审查我刚提交的工单审批流功能，重点关注：
1. 并发安全：多人同时审批同一个工单会不会有竞态条件？
2. 事务边界：审批记录写入和 Flowable 任务完成是否在一个事务里？
3. 超时机制：48 小时超时提醒的实现方案是否合理？
4. 与现有工单模块的集成是否有破坏性变更？
# Claude Code 输出（示例）：
🔴 严重: ApprovalService.completeTask() 存在竞态条件。
两个审批人同时点"通过"时，Flowable 的 taskService.complete()
内部有乐观锁保护，但 approvalRecordMapper.insert() 在 complete()
之前执行，如果 complete() 抛出异常，审批记录将"幽灵插入"。
建议：将 insert(record) 移到 complete() 之后，或者使用
@Transactional 确保两者原子性（已满足，但顺序问题仍建议调整）。
🟡 建议: 超时提醒用 @Scheduled 每分钟扫描一次 pending 任务，
在工单量 < 1万 时可行，但建议预留 Quartz/XXL-Job 升级路径。
建议在 CLAUDE.md 中记录此技术债务。
示例 Step 5: 记忆沉淀——任务结束时
🧩 开发者对话结束前对 Claude Code 说
# 本次开发完成，帮我记录以下经验：
1. Flowable 的 taskService.complete() 内部有乐观锁，
数据库操作应放在 complete() 之后，避免幽灵记录
2. 审批流 BPMN 中的 UserTask 必须设置 assignee 表达式，
本项目用 ${deptLeader} / ${workshopDirector} / ${productionManager}
3. 审批超时提醒的 @Scheduled 方案在并发 > 1000 待办时需升级为
消息队列方案（已在 CLAUDE.md 记录技术债务）
# Claude Code 自动写入 memory/project/flowable-approval-patterns.md
1. Flowable 的 taskService.complete() 内部有乐观锁，
数据库操作应放在 complete() 之后，避免幽灵记录
2. 审批流 BPMN 中的 UserTask 必须设置 assignee 表达式，
本项目用 ${deptLeader} / ${workshopDirector} / ${productionManager}
3. 审批超时提醒的 @Scheduled 方案在并发 > 1000 待办时需升级为
消息队列方案（已在 CLAUDE.md 记录技术债务）
# Claude Code 自动写入 memory/project/flowable-approval-patterns.md
下次再有审批流需求，Claude Code 会自动加载这份记忆，不会再踩同样的坑。
六、开发流程三：测试、文档与部署
5.1 测试分层与 AI 参与度
| 测试层级 | AI 工具 | AI 参与方式 | 人工职责 |
|---|---|---|---|
| 单元测试 | Claude Code | 根据源码自动生成测试用例（覆盖正常路径 + 边界条件 + 异常路径）。开发者只需描述特殊业务规则 | 审核测试覆盖的业务规则是否正确，补充 AI 无法推断的领域特定逻辑 |
| 集成测试 | Claude Code | 基于接口文档（OpenAPI/Protobuf）自动生成集成测试脚本，Mock 外部依赖 | 配置测试环境、审核 Mock 数据的真实性 |
| E2E 测试 | Claude Code + Playwright | 根据用户故事生成 Playwright 测试脚本，覆盖核心业务流程 | 定义核心用户旅程、审核测试断言的准确性 |
| 性能测试 | Claude Code + JMeter/k6 | 基于非功能需求生成性能测试脚本，分析瓶颈 | 设定性能基线、分析 AI 无法判断的业务合理性 |
5.2 文档生成策略
传统开发中，文档是"写完代码再补"的负担。AI 增强流程中，文档与代码同步生成：
| 文档类型 | 生成方式 | 更新策略 |
|---|---|---|
| API 文档 | Claude Code 从代码注解 + OpenAPI 定义自动生成，输出为 Markdown 或 Swagger UI | 代码变更时同步更新 |
| 架构决策记录（ADR） | 每次技术决策时，Claude Code 自动生成 ADR（上下文 → 决策 → 后果 → 备选方案） | 决策时即时生成 |
| 部署运维手册 | Claude Code 基于 Dockerfile/Helm Chart/CI 配置自动生成 | 部署配置变更时 |
| 客户验收文档 | Qwen 基于需求矩阵 + 测试报告 + 用户故事，生成中文验收文档 | 里程碑节点 |
5.3 CI/CD 流水线中的 AI 节点
Git Push
→
open-code-reviewL1 规约检查
→
Claude CodeL2 语义审查
→
自动化测试单测 + 集成 + E2E
→
人工 ReviewL3 业务审查
→
自动部署Merge → Deploy
✅ CI 流水线的"AI 阻断点"设计
L1（open-code-review）和 L2（Claude Code）检查失败时，CI 流水线自动阻止合并。这确保了：① 代码风格和基础规范 100% 合规 ② 常见逻辑错误在 PR 阶段就被拦截 ③ 人工 Reviewer 的时间全部用于高价值的业务审查，不再浪费在代码格式上。
5.4 实操示例：从 PR 到上线的完整自动化链路
以下演示工单审批流功能从 git push → 自动审查 → 测试 → 文档生成 → 部署的完整流水线。
示例 Step 1: GitHub Actions 完整 CI 配置
📋 .github/workflows/ci.yml（完整配置）
name: CI Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
# ===== Job 1: 代码规范检查 =====
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: alibaba-group/open-code-review@v1
with:
languages: java,javascript,typescript,vue
severity: error,warning
# ===== Job 2: 单元测试 + 集成测试 =====
test:
needs: lint
runs-on: ubuntu-latest
services:
mysql:
image: mysql:8.0
env:
MYSQL_ROOT_PASSWORD: test123
ports: [3306]
steps:
- uses: actions/checkout@v4
- name: Run Tests
run: mvn test -B
- name: Upload Coverage
uses: codecov/codecov-action@v4
# ===== Job 3: Claude Code 深度审查（仅 PR）=====
ai-review:
if: github.event_name == 'pull_request'
needs: [lint, test]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Claude Code Review
run: |
# 获取 PR 的 diff，调用 Claude Code 做语义审查
git diff origin/main...HEAD > /tmp/pr.diff
# Claude Code CLI 审查模式
claude --print "Review this diff for bugs,
security issues, and logic errors:
\$(cat /tmp/pr.diff)" > /tmp/review.md
# 将审查结果作为 PR Comment
gh pr comment ${{ github.event.pull_request.number }}
--body-file /tmp/review.md
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
# ===== Job 1: 代码规范检查 =====
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: alibaba-group/open-code-review@v1
with:
languages: java,javascript,typescript,vue
severity: error,warning
# ===== Job 2: 单元测试 + 集成测试 =====
test:
needs: lint
runs-on: ubuntu-latest
services:
mysql:
image: mysql:8.0
env:
MYSQL_ROOT_PASSWORD: test123
ports: [3306]
steps:
- uses: actions/checkout@v4
- name: Run Tests
run: mvn test -B
- name: Upload Coverage
uses: codecov/codecov-action@v4
# ===== Job 3: Claude Code 深度审查（仅 PR）=====
ai-review:
if: github.event_name == 'pull_request'
needs: [lint, test]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Claude Code Review
run: |
# 获取 PR 的 diff，调用 Claude Code 做语义审查
git diff origin/main...HEAD > /tmp/pr.diff
# Claude Code CLI 审查模式
claude --print "Review this diff for bugs,
security issues, and logic errors:
\$(cat /tmp/pr.diff)" > /tmp/review.md
# 将审查结果作为 PR Comment
gh pr comment ${{ github.event.pull_request.number }}
--body-file /tmp/review.md
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
示例 Step 2: Claude Code 自动生成测试用例
💬 开发者 Prompt：让 Claude Code 自动生成测试
# 对 Claude Code 说：
请为 ApprovalService.java 的 submitForApproval() 方法生成完整的单元测试，
要求：
1. 正常路径：草稿工单提交审批成功
2. 异常路径：工单不存在、工单状态不是草稿、提交人没有审批权限
3. 边界条件：并发提交同一工单（模拟两个线程同时调用）
4. Mock 策略：Flowable 的 RuntimeService 和 TaskService 用 Mockito Mock，
数据库层用 @DataJpaTest 真实测试（H2 内存库）
5. 测试覆盖率目标：行覆盖 ≥ 90%，分支覆盖 ≥ 85%
测试框架：JUnit 5 + Mockito + AssertJ
请为 ApprovalService.java 的 submitForApproval() 方法生成完整的单元测试，
要求：
1. 正常路径：草稿工单提交审批成功
2. 异常路径：工单不存在、工单状态不是草稿、提交人没有审批权限
3. 边界条件：并发提交同一工单（模拟两个线程同时调用）
4. Mock 策略：Flowable 的 RuntimeService 和 TaskService 用 Mockito Mock，
数据库层用 @DataJpaTest 真实测试（H2 内存库）
5. 测试覆盖率目标：行覆盖 ≥ 90%，分支覆盖 ≥ 85%
测试框架：JUnit 5 + Mockito + AssertJ
✅ Claude Code 生成的测试代码（关键片段）
@ExtendWith(MockitoExtension.class)
class ApprovalServiceTest {
@Mock
private RuntimeService runtimeService;
@Mock
private WorkOrderMapper workOrderMapper;
@InjectMocks
private ApprovalService approvalService;
@Test
@DisplayName("正常提交草稿工单 → 启动审批流 → 状态变更为待审批")
void shouldStartApprovalWhenDraftWorkOrderSubmitted() {
// Given
WorkOrder wo = WorkOrder.builder()
.id(1L).status(WorkOrderStatus.DRAFT).build();
when(workOrderMapper.selectById(1L)).thenReturn(wo);
ProcessInstance pi = mock(ProcessInstance.class);
when(pi.getId()).thenReturn("proc-123");
when(runtimeService.startProcessInstanceByKey(any(), any(), any()))
.thenReturn(pi);
// When
approvalService.submitForApproval(1L);
// Then
assertThat(wo.getStatus()).isEqualTo(WorkOrderStatus.PENDING_APPROVAL);
assertThat(wo.getProcessInstanceId()).isEqualTo("proc-123");
verify(workOrderMapper).updateById(wo);
}
@Test
@DisplayName("非草稿状态工单提交审批 → 抛出 BusinessException")
void shouldThrowExceptionWhenWorkOrderNotDraft() {
WorkOrder wo = WorkOrder.builder()
.id(1L).status(WorkOrderStatus.APPROVED).build();
when(workOrderMapper.selectById(1L)).thenReturn(wo);
assertThatThrownBy(() -> approvalService.submitForApproval(1L))
.isInstanceOf(BusinessException.class)
.hasMessageContaining("草稿状态");
verify(runtimeService, never()).startProcessInstanceByKey(any(),any(),any());
}
}
class ApprovalServiceTest {
@Mock
private RuntimeService runtimeService;
@Mock
private WorkOrderMapper workOrderMapper;
@InjectMocks
private ApprovalService approvalService;
@Test
@DisplayName("正常提交草稿工单 → 启动审批流 → 状态变更为待审批")
void shouldStartApprovalWhenDraftWorkOrderSubmitted() {
// Given
WorkOrder wo = WorkOrder.builder()
.id(1L).status(WorkOrderStatus.DRAFT).build();
when(workOrderMapper.selectById(1L)).thenReturn(wo);
ProcessInstance pi = mock(ProcessInstance.class);
when(pi.getId()).thenReturn("proc-123");
when(runtimeService.startProcessInstanceByKey(any(), any(), any()))
.thenReturn(pi);
// When
approvalService.submitForApproval(1L);
// Then
assertThat(wo.getStatus()).isEqualTo(WorkOrderStatus.PENDING_APPROVAL);
assertThat(wo.getProcessInstanceId()).isEqualTo("proc-123");
verify(workOrderMapper).updateById(wo);
}
@Test
@DisplayName("非草稿状态工单提交审批 → 抛出 BusinessException")
void shouldThrowExceptionWhenWorkOrderNotDraft() {
WorkOrder wo = WorkOrder.builder()
.id(1L).status(WorkOrderStatus.APPROVED).build();
when(workOrderMapper.selectById(1L)).thenReturn(wo);
assertThatThrownBy(() -> approvalService.submitForApproval(1L))
.isInstanceOf(BusinessException.class)
.hasMessageContaining("草稿状态");
verify(runtimeService, never()).startProcessInstanceByKey(any(),any(),any());
}
}
示例 Step 3: Claude Code 自动生成 API 文档 + ADR
📋 文档生成 Prompt
# 对 Claude Code 说：
工单审批流功能开发完成，请帮我生成以下文档：
1. API 文档（docs/api/approval-api.md）
- 基于 ApprovalController 的注解和代码生成
- 格式：接口路径 | 方法 | 请求参数 | 响应示例 | 错误码
- 用 Markdown 表格
2. 架构决策记录（docs/adr/ADR-005-approval-engine.md）
- 标题：ADR-005: 选择 Flowable 作为审批流引擎
- 格式：上下文 → 决策 → 后果 → 备选方案（Activiti/Camunda/自研）
3. 部署变更说明（docs/deploy/v2.3-approval-changes.md）
- 新增数据库表（DDL）
- 新增配置项（application.yml）
- 部署步骤和回滚方案
工单审批流功能开发完成，请帮我生成以下文档：
1. API 文档（docs/api/approval-api.md）
- 基于 ApprovalController 的注解和代码生成
- 格式：接口路径 | 方法 | 请求参数 | 响应示例 | 错误码
- 用 Markdown 表格
2. 架构决策记录（docs/adr/ADR-005-approval-engine.md）
- 标题：ADR-005: 选择 Flowable 作为审批流引擎
- 格式：上下文 → 决策 → 后果 → 备选方案（Activiti/Camunda/自研）
3. 部署变更说明（docs/deploy/v2.3-approval-changes.md）
- 新增数据库表（DDL）
- 新增配置项（application.yml）
- 部署步骤和回滚方案
示例 Step 4: Qwen 生成客户验收文档
📄 Qwen 生成验收文档 Prompt
# 通过 Qwen API（百炼工作台）发送：
你是一位 MES 项目的交付经理。请基于以下信息，生成一份面向客户的
《工单审批流功能验收报告》：
输入信息：
- 需求编号：FR-WO-003（工单审批流）
- 功能描述：[粘贴 FR-Matrix 中对应条目]
- 测试结果：[粘贴测试报告摘要]
- 用户故事：[粘贴 Agile 用户故事]
验收报告要求：
1. 语言：中文，面向非技术客户的业务语言
2. 结构：功能概述 → 验收标准逐项对照 → 测试结果 → 遗留问题 → 签收建议
3. 篇幅：2-3 页
4. 格式：标准验收报告模板（含客户签章区）
你是一位 MES 项目的交付经理。请基于以下信息，生成一份面向客户的
《工单审批流功能验收报告》：
输入信息：
- 需求编号：FR-WO-003（工单审批流）
- 功能描述：[粘贴 FR-Matrix 中对应条目]
- 测试结果：[粘贴测试报告摘要]
- 用户故事：[粘贴 Agile 用户故事]
验收报告要求：
1. 语言：中文，面向非技术客户的业务语言
2. 结构：功能概述 → 验收标准逐项对照 → 测试结果 → 遗留问题 → 签收建议
3. 篇幅：2-3 页
4. 格式：标准验收报告模板（含客户签章区）
七、个人记忆系统：持续积累与经验复用
企业知识库是"组织记忆"，解决团队共性问题。但每个开发者有自己的技术偏好、踩过的坑、积累的提示词和脚本片段。个人记忆系统就是为每个开发者定制的"第二大脑"。
6.1 Claude Code Memory 机制
Claude Code 内置的 Memory 系统（~/.claude/projects/<项目路径>/memory/）提供文件级记忆持久化。每条记忆是一个独立的 Markdown 文件，带 frontmatter 元数据，在后续会话中自动加载。
表：Memory 文件的四种类型与使用场景
| 类型 | 用途 | 示例 | 触发时机 |
|---|---|---|---|
| user | 记录开发者角色、技术偏好、习惯 | "偏好使用 PostgreSQL 而非 MySQL"、"倾向于函数式编程风格" | 首次使用 Claude Code 时设定，后续对话自动加载 |
| feedback | 记录用户对 AI 行为的纠正和偏好确认 | "上次你用的设计模式过度复杂，下次遇到类似场景用更简单的方式" | 开发者在对话中给出纠正意见时 |
| project | 记录项目特定的约定、非标准配置 | "这个项目使用 Java 17 + Spring Boot 3.2，LLM 调用通过内部 API 网关，不直连外部模型" | 项目初期设定，架构变更时更新 |
| reference | 记录外部资源引用 | "阿里云百炼 API 文档：https://help.aliyun.com/..."、"内部 API 网关文档：..." | 任何需要"记住去哪查"的场景 |
6.2 个人记忆的最佳实践
🔑 记忆积累的"5 分钟规则"
每次 Claude Code 会话结束前，花 不超过 5 分钟 做一次"记忆回收"：回想本次对话中哪些信息值得下次记住。用自然语言对 Claude Code 说："帮我记住以下几点：① ... ② ... ③ ..."
表：值得写入记忆 vs 不值得写入的对比
| ✅ 值得写入记忆 | ❌ 不需要写入（代码/Git 已有） |
|---|---|
| "这个项目的异常处理统一用 GlobalExceptionHandler，不要在每个 Controller 里 try-catch" | "UserController.java 有 3 个接口"（代码已有） |
| "客户 X 的数据库字符集是 GBK，写 SQL 时注意" | "上周五提交了一个 bug 修复"（Git 已有） |
| "用 @Transaction 注解时，这个项目需要显式指定 rollbackFor = Exception.class" | "pom.xml 中 Spring Boot 版本是 3.2"（代码已有） |
| "内部 LLM 网关的 rate limit 是 100 req/min，批量调用时需要限流" | "项目构建用 mvn clean package"（CLAUDE.md 已有） |
6.3 记忆文件的自动维护策略
| 策略 | 说明 |
|---|---|
| 合并而非膨胀 | 同类记忆合并到一个文件，通过 [[wiki-link]] 建立关联。单一文件内容控制在 500 字以内 |
| 定期清理 | 每月检查一次 memory 目录，删除已过时的记忆（如"临时 workaround，等 Spring Boot 3.3 修复" —— 升级后即失效） |
| 标签化 | 每条记忆的 description 字段写清楚"什么场景下需要这条记忆"，确保 Claude Code 只在相关对话中加载 |
| 双人复核 | 重要项目约定（影响多人）应提升到 CLAUDE.md 或企业知识库，而非仅留在个人记忆中 |
八、团队协作：多 Agent 并行工作模式
单开发者 + Claude Code 是"一人公司"模式。但当团队扩大到 5-20 人时，需要一套多 Agent 协作规范来避免"5 个 AI 写出 5 种风格"的混乱局面。
7.1 团队 AI 使用规范
表：团队级 AI 协作规范（建议写入 CLAUDE.md 或团队 Wiki）
| 规范类别 | 具体约定 | 执行方式 |
|---|---|---|
| 代码风格 | 所有 AI 生成的代码必须遵循项目 .claude/design-tokens.md 和编码规范文件。禁止 AI 自行"发明"新的命名约定或目录结构 |
open-code-review L1 自动阻断 |
| 分支策略 | AI Agent 只能在自己的 Git Worktree 中工作。合并操作由开发者手动执行，禁止 AI 直接 push 到 main/master | Git 分支保护规则 + CI 检查 |
| Commit Message | AI 生成的代码提交信息遵循 Conventional Commits 格式（feat:/fix:/refactor:），含需求编号引用 |
Claude Code 项目配置 |
| 知识沉淀 | 每个功能开发完成后，开发者有责任将关键经验写入项目 Memory 或更新 CLAUDE.md | 开发流程 Checklist |
| 模型选择 | 哪些场景用哪个模型（参照第一章决策矩阵），避免所有人各自随意选择模型导致质量参差 | 团队培训 + 定期 Review |
7.2 多 Agent 协作的典型工作流
👤 Tech Lead需求拆分 · 接口定义 · 最终集成
↙ 分配任务 ↓ 分配任务 ↘
🤖 Agent A模块 A 开发 + 测试
🤖 Agent B模块 B 开发 + 测试
🤖 Agent C文档 + E2E 测试
↘ 产出 ↓ 产出 ↙
🔍 open-code-review + Claude Code 审查L1 + L2 代码审查
↓ 通过
👤 Tech Lead 合并 + 人工 ReviewL3 业务审查 · Merge
⚠️ 多 Agent 协作的核心风险与对策
风险 1: 风格不一致 → 对策：所有 Agent 共享同一份 CLAUDE.md，open-code-review 在合并前强制执行风格检查。
风险 2: 接口不匹配 → 对策：接口定义（API Spec / Protobuf）由 Tech Lead 先行确定并写入共享文档，Agent 只实现不设计接口。
风险 3: 上下文丢失 → 对策：每个 Agent 的产出必须附带"设计决策说明"（为什么这样实现），便于集成时理解上下文。
九、投入产出分析：效率提升的量化预测
基于行业基准数据和实际案例，以下给出 AI 增强开发流程在各个环节的效率提升预期。数据来源：GitHub Copilot 2025 调查报告、Google DORA 2025 AI 影响研究、以及内部试点数据。
8.1 各环节效率提升预测
表：AI 增强开发流程的环节级效率提升预测
| 开发环节 | 传统耗时（参考） | AI 增强耗时 | 效率提升 | 关键驱动工具 |
|---|---|---|---|---|
| 需求文档分析 | 2-3 天 | 0.5-1 天 | 60-75% | Qwen 长文档 + Claude Code 结构化 |
| 技术方案设计 | 3-5 天 | 1-2 天 | 55-65% | Claude Code + DeepSeek 评审 |
| 编码实现（中等复杂度） | 5-10 天 | 2-5 天 | 50-60% | Claude Code Agent |
| 代码审查 | 0.5-1 天/PR | 0.1-0.3 天/PR | 70-80% | open-code-review + Claude Code |
| 单元测试编写 | 编码时间的 30-50% | 编码时间的 5-10% | 75-85% | Claude Code 自动生成 |
| 技术文档编写 | 2-5 天 | 0.5-1 天 | 70-80% | Claude Code + Qwen 中文润色 |
| Bug 修复（定位 + 修复） | 0.5-2 天 | 0.1-0.5 天 | 60-75% | Claude Code 根因分析 |
| 综合（全生命周期） | 基准 | — | 50-65% | 全工具链协同 |
8.2 成本构成分析
表：多模型工具链的月度成本估算（10 人团队）
| 工具/服务 | 用途 | 月费（估算） | 备注 |
|---|---|---|---|
| Claude Code | 主力开发 Agent，每人每天 4-6 小时使用 | $100-200/人/月 | Claude Max 订阅（含 API 额度） |
| DeepSeek API | 辅助推理、批量分析、第二意见 | ¥50-200/团队/月 | 极低成本，主要消耗在批量场景 |
| 通义千问（百炼 API） | 长文档分析、中文文档、RAG 问答 | ¥200-500/团队/月 | 按 Token 计费，长文档为主要消耗 |
| open-code-review | CI 自动代码审查 | 免费 | 开源 GitHub Action，使用 GitHub 免费 Runner 额度 |
| 知识库平台（Dify 自建） | 企业知识库 RAG | ¥300-800/月 | 服务器费用（ECS 4C8G 即可起步） |
| 合计 | 10 人团队月度总成本 | 约 ¥15,000-25,000/月 | 人均 ¥1,500-2,500/月 |
💰 ROI 速算
假设 10 人团队，人均月成本 ¥25,000（含薪资+管理成本）。AI 工具月成本 ¥2,000/人，但效率提升 50%，相当于用 ¥2,000 换 ¥12,500 的产出。ROI ≈ 1:6。
更重要的隐性收益：① 方案质量提升 → 中标率提高 ② Bug 减少 → 交付周期缩短 ③ 知识沉淀 → 新人上手速度倍增 ④ 员工满意度 → AI 处理重复劳动，人聚焦创造性工作。
8.3 分阶段效率爬坡
| 阶段 | 时间 | 预期效率提升 | 关键里程碑 |
|---|---|---|---|
| 适应期 | 第 1-2 周 | -10% ~ +10% | 学习 Claude Code 交互模式，建立个人 Memory |
| 熟练期 | 第 3-6 周 | +20% ~ +40% | 掌握 Plan Mode、Agent 并行、知识库检索 |
| 精通期 | 第 7-12 周 | +40% ~ +65% | 自定义 Hook、自动化流水线、团队协作模式成熟 |
| 平台期 | 第 13 周+ | +50% ~ +70% | 持续优化 CLAUDE.md、知识库、记忆系统 |
十、落地路线图：从试点到全面推广
9.1 三阶段推进计划
表：12 周落地路线图
| 阶段 | 时间 | 目标 | 关键任务 | 参与人 |
|---|---|---|---|---|
| Phase 1 | 第 1-2 周 | 基础搭建 |
① 选定 2-3 名种子开发者（技术过硬 + 对 AI 有热情） ② 配置 Claude Code + DeepSeek + Qwen API 访问 ③ 完善试点项目的 CLAUDE.md 和设计规范文件 ④ 搭建 open-code-review CI 流水线 ⑤ 建立个人 Memory 文件模板 |
技术负责人 + 种子开发者 |
| Phase 2 | 第 3-6 周 | 试点验证 |
① 种子开发者在 1-2 个真实项目中全程使用 AI 工具链 ② 每日记录效率数据和遇到的问题 ③ 积累项目级 Memory 和踩坑经验 ④ 搭建 Dify 知识库，导入历史方案文档 ⑤ 每周团队分享：AI 使用技巧和案例分析 |
种子开发者 + 全团队（观察学习） |
| Phase 3 | 第 7-12 周 | 全面推广 |
① 基于试点经验制定团队 AI 使用规范（写入 CLAUDE.md） ② 全员培训：第 7 周入门培训，第 8-10 周角色专项培训 ③ 所有新项目默认启用 AI 工具链 ④ 建立 AI 使用效果度量看板（效率提升、Bug 率、代码质量） ⑤ 月度 AI 使用复盘会，持续优化流程 |
全员 |
9.2 成功的关键前提
⚠️ 四个"不开始"原则
1. CLAUDE.md 不完善不开始。项目规约文件是 AI 的"入职培训材料"。没有清晰的编码规范、架构约定、目录结构说明，AI 产出的代码质量将大幅下降。
2. 种子开发者未通过试用期不推广。种子开发者需要 2-4 周达到"熟练期"效率水平。在此之前向全团队推广会导致集体挫败感。
3. CI 门禁未就绪不进入生产项目。open-code-review + 自动化测试必须在新项目启动前就位。没有自动化质量门禁的 AI 辅助开发 = 代码质量失控。
4. 管理层未理解 AI 的开发模式不启动。AI 辅助开发不是"AI 写代码，人只需要点确认"。开发者需要新的技能：需求描述能力、方案评审能力、上下文管理能力。管理层需要重新定义绩效考核标准（从"代码行数"转向"功能交付速度和质量"）。
9.3 度量指标
表：AI 开发流程的关键度量指标
| 指标 | 定义 | 基线（传统） | 目标（6 个月） |
|---|---|---|---|
| 需求→上线周期 | 从需求确认到功能上线的日历天数 | 15-30 天 | 7-15 天 |
| 代码审查时间 | PR 从提交到合并的平均时间 | 1-2 天 | 2-4 小时 |
| 生产 Bug 率 | 每千次部署的生产环境 Bug 数量 | 基线 | 降低 30-50% |
| 测试覆盖率 | 代码行覆盖率 | 30-50% | 70-85% |
| 知识复用率 | 新项目中复用历史方案/代码的比例 | 10-20% | 40-60% |
| 开发者满意度 | 匿名问卷"AI 工具是否让你更享受编程" | — | ≥ 80% 正面 |