AI Coding的经验和SOP

启动位置

启动方式操作
IDEA 集成终端在 IDEA 内置终端 cd 到项目根目录后执行 mc --code 其他 IDE 比如VS Code、Catpaw 的集成终端也可以
独立终端手动 cd 至目标项目目录后执行 mc --code

建议：在项目根目录启动，因为Claude Code是根据启动目录名进行项目级记忆。

Claude Code 启动后会自动读取项目根目录的 CLAUDE.md、.claude/settings.json、.claude/agents/ 等配置，同时也按照启动目录进行记忆。

项目不强制是 git 仓库，建议 git 管理。如果多仓库的话每个子目录作为 git 仓库也是可以的。

项目目录结构全景

一个完整的 Claude Code 项目配置结构如下：

// 代码块
your-project/
├── CLAUDE.md              # 📋 项目级指令（团队共享，提交 Git）
├── CLAUDE.local.md        # 👤 个人项目偏好（gitignore）
├── .claude/
│   ├── settings.json      # ⚙️ 项目设置：权限、Hook、模型
│   ├── settings.local.json# 👤 个人项目设置
│   ├── CLAUDE.md          # 📋 等效于项目根目录 CLAUDE.md
│   ├── rules/             # 📏 模块化规则文件（按域拆分）
│   │   ├── code-style.md
│   │   ├── testing.md
│   │   └── security.md
│   ├── agents/            # 🤖 自定义子代理
│   │   ├── code-reviewer.md
│   │   └── debugger.md
│   └── skills/            # ⚡ 自定义技能
└── .mcp.json              # 🔌 项目级 MCP 服务器配置

新手提示：起步只需 CLAUDE.md + .claude/settings.json 两个文件，其他配置随需求逐步添加

CLAUDE.md 放哪
  • 路径：项目根目录 CLAUDE.md（始终加载）。
  • 三级配置：
    • 全部 Claude Code 遵循： ~/.claude/CLAUDE.md
    • 会话启动目录生效：CLAUDE.md CLAUDE.local.md
    • 子目录读取该目录内容才生效： ./xxx/.../CLAUDE.md（适合模块级约定）

三、开始编程

编程思路：探索 → 计划 → 编码 → 评测

1. 探索（Explore）： 先让 AI 理解现状再动手。直接说需求，AI 会自动派内置的 Explore 子 Agent（只读、快速）去搜索代码、梳理调用关系，把结论摘要回主对话。

2. 计划（Plan）： 进入 Plan 模式，让 AI 输出修改方案（改哪些文件、怎么改、风险点），人工确认后再执行。

3. 编码（Code）： 按确认的方案分阶段执行，每完成一个可验证单元就跑测试验证。

4. 评测（review/test）

  • 具体开发顺序看自己的开发习惯和使用的 plugin/skill
  • 以上顺序比较偏 SPEC coding，也可以使用 TDD （测试驱动开发）等开发思想
简单示例
// 代码块
你：我要给交易服务加一个"大额订单风控拦截"功能，金额超过 10 万的订单
    需要调风控接口校验。帮我理清现有下单流程，产物文档化。

AI（自动派 Explore 子 Agent 搜索）：
    下单主流程在 TradeService.createOrder()，入口 TradeController。
    当前校验链：参数校验 → 重复单校验 → 余额校验 → 落库。
    建议在"余额校验"后、"落库"前插入风控校验。

你：/plan  按技术方案链接出方案

AI（Plan 模式，只规划不动手）：
    方案：
    1. 新增 RiskClient 调用风控接口
    2. TradeService.createOrder() 中余额校验后加 checkRisk()
    3. 失败抛 BizException(ErrorCode.RISK_REJECTED)
    4. 新增 RiskClient 单测
    涉及文件：4 个新增/修改
    风险：风控接口超时需设 500ms 短超时 + 降级

你：（确认方案）创建SPEC.md，划分任务阶段和每个阶段的子任务，包括开发、评估、测试。

AI（创建 SPEC.md, 开发任务.md）

你：开始实现

AI（开始编码）...

1.项目初始化

/init — 项目初始化

**生成 CLAUDE.md **image.png

  • 怎么用：进入项目根目录，启动后输入 /init。

  • 发生什么：Claude Code 扫描项目结构（技术栈、目录、构建命令），生成 CLAUDE.md。

  • 已存在会覆盖吗：不会直接覆盖，会合并/更新，建议先 review 再采纳。

  • 何时用：首次接入新项目，或项目结构大改后刷新。

  • 不使用 /init 创建：

    • 其他编程工具的 AGENT.md 可以直接复制
    • 也可手动创建CLAUDE.md后用 /memory 追加
    • 可以直接手动编辑
CLAUDE.md 写什么

  • 核心原则： 简洁为佳。

  • 控制在 200 行以内

  • 模块级约定可拆到子目录 CLAUDE.md，读取该目录文件时才加载。

一个简单示例：

// 代码块
## 技术栈
- Java 17 + Spring Boot 3 + MyBatis
- MySQL 8 / Redis / RocketMQ

## 编码规范
- 价格字段一律用 BigDecimal
- 异常抛 BizException(ErrorCode.XXX)，禁止 RuntimeException

## 流程规范
- 所有阶段成果文档化到 xxx 目录
- 重要决策记录日志

## 不要做的事
- 不要新建 util 包，通用方法放 com.xxx.common
- 不要 git push

## （选填）从网上看到的开发八荣耻
- 以瞎猜接口为耻，以认真查询为荣。
- 以模糊执行为耻，以寻求确认为荣。
- 以臆想业务为耻，以人类确认为荣。
- 以创造接口为耻，以复用现有为荣。
- 以跳过验证为耻，以主动测试为荣。
- 以破坏架构为耻，以遵循规范为荣。
- 以假装理解为耻，以诚实无知为荣。
- 以盲目修改为耻，以谨慎重构为荣。
/effort — 调节思考深度
  • 参数：/effort low|medium|high|xhigh|max|ultracode
  • 各档场景：
    档位场景耗时
    low改个变量名、加注释最快
    medium简单修改适中
    high日常开发（默认）较慢
    xhigh/max架构设计、复杂 Bug 定位最慢
    ultracode任务托管，自动划分开发阶段、派遣 subagent 推进任务较慢

默认 high，可以通过配置文件修改默认思考等级

/Plan — 先方案设计后编码
  • 怎么进入：输入 /plan（带需求描述），或按 Shift+Tab 在普通/Plan 模式间切换。
  • 进去后做什么：直接描述需求，AI 只输出方案（改哪些文件、步骤、风险），不实际改代码。
  • 怎么确认：方案满意后回复"开始实现"或"按方案执行"，AI 才动手编码。
  • 怎么退出：Shift+Tab 切回普通模式。
  • 何时用：多文件改动、重构、方案不确定时。简单改一个函数不必进 Plan。
  • 进阶插件/skill：
    • grill-me（Matt Pocock）：极简 skill，写代码前"往死里盘问"需求，一次只问一个分叉，能在代码库找到答案就不打扰你。适合需求模糊时先把意图聊透。
    • superpowers（Jesse Vincent）：20+ skill 的完整开发流水线（brainstorm → writing-plans → 子 Agent 实现 → TDD + 代码审查），相当于给 Claude Code 请了一位流程严格的工程经理。适合大型功能开发。包装较重，按需启用。
    • 两者非替代关系：grill-me 是单点工具（拷问需求），superpowers 是完整方法论。可组合：grill-me 聊透需求 → superpowers 走流程实现。

Plan 模式背后是内置的 Plan 子 Agent（只读收集信息），它不能再派子 Agent，防止无限嵌套。

2.子 Agent 使用

适用场景
  1. 上下文隔离：比如开发了一个 Skill，让 Claude 派一个 Subagent 测试效果，因为在开发会话测试会有开发过程上下文记忆。
  2. 并行化提速：比如开发涉及多个模块，分多个 Subagent 在不同模块目录下完成开发任务
  3. 多角色定制：比如对抗性方案讨论，两个 subagent 分别找方案 A 的合理性证据 / 不合理性证据，主会话总结给你确定方案。
  4. 多思考等级定制：比如想找某个确认点，主会话做既慢且占用上下文，可以扇出 effort 为 low/medium 的 subagent 去做。
  5. 省上下文：比如想找某个确认点，但代码仓库很大，链路很长，可以扇出 subagent 去做。
使用方式

直接自然语言说明即可，主会话会自动写 Subagent 的提示词。使用示例：

// 代码块
派一个 effort 为 medium 的 Subagent 测试边界/功能点

用多个高思考等级的子代理帮我并行化开发/测试这几个模块

3.创建自定义子 Agent

适用场景
  1. 有已经开发好的 Agent 描述文件
  2. 自己总结了一个可复用的好 Agent 描述文件
  3. 通用子代理不满足业务要求
创建方式

手写 Markdown 文件或让AI创建到目录.claude/agents/，需重启 Claude Code 才加载。

文件格式（YAML frontmatter + Markdown 正文）：

// 代码块
---
name: code-reviewer
description: 审查代码质量与安全问题。在代码修改后主动使用。
tools: Read, Grep, Glob, Bash
model: sonnet
---
你是高级代码审查员。收到代码后：
1. 检查明显 bug（空指针、边界、未处理异常）
2. 检查安全问题（SQL 注入、硬编码密钥）
3. 检查性能问题（N+1 查询、循环内大对象）
输出格式：[严重程度] 文件:行号 问题 + 修复方案
怎么调用
  • 自动调用：AI 根据 description 匹配任务自动派发。
  • 显式调用：用 code-reviewer 子代理审查 src/service/ 下最近的修改。

4.Dynamic Workflow 使用

Workflow 是把多个子 Agent 按流程自动编排起来的上层模式——你只需描述复杂目标，Claude Code 自动拆解任务、调度多个子 Agent 并行执行、汇总结果。全程自动编排，无需手动串联。

什么时候用 Workflow
  • 任务可清晰拆解为多个独立子任务，且需要并行执行提速。
  • 单会话上下文装不下整个任务，需要分片处理后汇总。
  • 跨仓大项目（如前端 + 后端 + 测试同时开工）。
怎么触发

直接用自然语言描述复杂目标，Claude Code 会自动判断是否拆解为 Workflow；也可显式提及关键词 “用 dynamic workflow” 或者 “动态工作流”、“ultracode”。

/effort ultracode 也会自动划分开发阶段、派遣 subagent 推进。

示例（自动编排）
// 代码块
你：
		把 src/controller 下 10 个接口统一补参数校验和异常处理，自动拆分执行

​AI（自动编排）：    
    拆为 10 个子任务 → 派多个 general-purpose 子 Agent 并行处理，    
    每个负责一个接口（加 @Valid + 全局异常处理），各自跑编译。    
    全部完成后汇总改动清单返回主对话。
    
​你：
	（收到汇总清单，review 后提交）

四、开发过程管控

开发过程管控按"方向管控 → 上下文管控 → 记忆管控 → 成果归档“的逻辑顺序组织。

方向管控确保不走偏；上下文管控确保窗口不爆；记忆管控把经验固化；成果归档收尾交付。

4.1 方向管控：会话分叉与回滚

开发方向错了要能快速回退或并行验证，避免在错误路径上越陷越深。

4.1.1 /branch <name> — 会话分叉
  • name 是什么：会话标签（不是 git 分支名），用于在分支列表里识别和切换。与 git branch 完全无关。
  • 分叉后：当前对话状态复制到新分支，主干保持不动，两分支独立演进。
  • 怎么切换：输入 /branch 列出所有分支选择切换；或 /resume 从会话列表选。
  • 没有合并操作：/branch 分叉的是对话上下文，主会话看不到 /branch 之后的内容，你可以选择其中一个分支作为后续开发的主会话，或者 commit 之后，回到主会话让他读修改的代码。
  • 何时用：想试另一个方案又不想丢当前进度；多思路并行验证。
4.1.2 /rewind — 回滚到检查点
  • 怎么用：输入 /rewind，或按两次 Esc。弹出历史节点列表，选择回滚到哪个节点。
  • 回滚范围：可同时回滚对话 + 代码，也可只回滚其一。
  • 何时用：编码方向错误、需要撤销时；连续失败 2 次即应回滚，别在错误方向硬改。
  • 检查点跨会话持久化：关闭终端后下次仍可回退。但检查点只追踪 Claude 的修改，不能替代 Git。

4.2 上下文管控：提问、压缩、恢复

上下文窗口是稀缺资源，要主动管理而非等系统自动处理。

4.2.1 /btw <问题> — 顺带提问不打断
  • 怎么用：主任务执行中产生关联疑问时，输入 /btw 问题内容。
  • 特点：不打断主任务，答案在主对话以浮层显示，不进入会话历史、不污染上下文。
  • 何时用：Claude 正在跑长任务，你想确认之前讨论过的某个细节——不用打断它，直接 /btw 问。
4.2.2 /compact [重点] — 主动压缩上下文
  • 怎么用：/compact 自动压缩；或 /compact 重点保留 API 设计决策 指定保留内容。
  • 何时用：上下文接近上限、完成阶段性任务后。建议主动用，别等系统自动压缩（自动时机不可控，可能正好压掉关键细节）。每完成一个阶段性任务（修完一个 Bug、开发完一个功能）就主动 /compact 重点保留 xxx。
  • 压缩后：对话可正常继续，但细节可能丢失，所以要用"重点保留"指定关键信息。
4.2.3 /resume 与 /clear — 会话恢复与清空
  • /resume：恢复历史会话。列出历史会话可选，恢复后上下文还在。跨天/中断后继续时用。
  • /clear：清空当前会话。切换全新任务时用。清空后仍可通过 /resume 找回。

核心原则：干净会话 + 好提示词，几乎总是优于长会话 + 反复修正。任务切换时果断 /clear。

4.3 记忆管控：规则沉淀

把开发中积累的经验固化到项目记忆，让 AI 下次自动遵循。

4.3.1 /memory — 查看/编辑记忆
  • 怎么用：输入 /memory，在编辑器中查看/编辑系统记忆与项目记忆全貌。编辑后立即生效。
  • 调试技巧：当 AI 行为不符合预期时，先 /memory 查看加载了哪些记忆——问题可能出在过时的自动记忆覆盖了 CLAUDE.md 规则。
4.3.2 主动记忆声明

怎么提示（话术示例）：

  • “记住这条规则：价格字段一律 long 单位分，写入 CLAUDE.md”
  • “把这个架构决策记到项目记忆里”
  • “这个坑以后别再踩，加到规则里”

写入机制：AI 通过 /memory 或直接编辑 CLAUDE.md 写入，不会覆盖已有内容，采用追加/合并。

**# xxx**** 快速追加语法**：在对话输入框中以 # 开头打一行内容（如 # 价格字段一律 long 单位分），回车后 Claude Code 会将其作为规则追加到 CLAUDE.md，无需手动开文件。区别：# 是单条快速追加；/memory 打开完整记忆管理界面。

踩坑规则示例条目：

  • [踩坑] RiskClient 调用必须设 500ms 超时，否则会拖垮整个下单链路（事故 2026-08-05）

4.4 成果归档

怎么触发：阶段任务完成后，直接说"总结本轮改动"或"生成本次变更摘要”。也可用 /recap 输出会话回顾。

应包含：

  • 改动文件清单
  • 关键变更摘要（做了什么、为什么）
  • 未完成项与后续待办

写到哪：对话内显示，或要求写入 CHANGELOG.md / PR 描述。

4.5 Hook 配置

Hook 是事件驱动的自动化脚本，在生命周期节点自动触发，不靠提示词、不靠 AI 记忆，每次都跑。配置在 .claude/settings.json（项目级）或 ~/.claude/settings.json（用户级）。

常用事件： PreToolUse（工具执行前，可 exit 2 阻断）、PostToolUse（工具执行后）、Stop（AI 完成一轮回复）、SubagentStop（子 Agent 完成）。

平时使用直接让 Cluade Code 帮你配置即可。

权限规则（deny/ask/allow）： 与 Hook 配合，在 permissions 字段配置，优先级 deny > ask > allow：

{  “permissions”: {    “allow”: [“Bash(npm run )", “Bash(git diff )", “Edit()", “Write()"],    “ask”: [“Bash(git push *)", “Bash(rm *)"],    “deny”: [“Read(.env)", “Read(./secrets/**)", “Bash(git push –force *)"] } }

  • allow 自动放行；ask 弹确认框；deny 直接禁止。
  • 配置层级（高→低）：企业策略 > 命令行参数 > .claude/settings.local.json > .claude/settings.json > ~/.claude/settings.json。

建议： 起步只配一条 PreToolUse 拦截 rm -rf / git push --force，性价比最高

五、反模式

以下行为会显著降低效率与质量，严格规避。每条附"症状"帮助识别：

反模式症状（怎么发现正在踩坑）正确做法
静默修改文件编译突然报"找不到符号”，排查发现 AI 改了包名/移了文件却没说要求 AI 所有结构性变更（移动/重命名/删除文件）必须先列出并确认
多工具交叉修改IDE 和 AI 同时改同一文件，保存时互相覆盖，改动莫名丢失单一时段由单一主体持有编辑权；切回 IDE 前先让 AI 停手并提交
反复纠错不 RewindAI 在错误方向上越改越乱，上下文堆积大量失败尝试，开始"遗忘"早期指令连续失败 2 次即 /rewind 回到正确节点重选方向，别继续修补
不设权限卡控AI 自信地执行了 git push --force / rm -rf，造成不可逆损失用 Hook + 权限规则对敏感操作设 ask/deny（见第六章）

六、SOP 示例：全流程开发任务

注意：此例是为梳理以上提到的内容，这个任务实际开发过程中直接开 /goal 或者 dynamic workflow 基本就够用了

本章以一个开发任务为例，把前文讲过的命令和能力按开发顺序串起来演示一遍。目标是让大家看清每一步用什么、怎么用、为什么用。

任务背景：给交易服务加一个订单导出功能，支持按日期范围筛选，导出 CSV。 涉及能力：初始化、规则配置、Plan、子 Agent、Workflow、/goal、/branch、/rewind、/compact、/btw、/memory、Hook、归档。

6.1 第一步：接入项目

进入项目根目录启动，这一步对应第二章的安装配置和项目目录结构。

// 代码块
mc --code

首次接入跑 /init 生成 CLAUDE.md（对应 3.2.1）：

// 代码块
你：/init
AI：已扫描项目，生成 CLAUDE.md，含技术栈、构建命令、目录结构。

review 后用追加几条红线（对应 4.3.2）：

// 代码块
你：/memory 不要 git push，价格字段用 BigDecimal
AI：两条规则已追加到 CLAUDE.md。

最后配一条 Hook 拦截危险命令（对应 4.5）

// 代码块
帮我加一个 hook，拦截所有 git push 和 rm -rf 命令

6.2 第二步：探索 + 计划

用 /plan 进入计划模式，让 AI 先理解现状再出方案（对应 3.1 编程思路、3.2.3 Plan 模式）。Plan 模式下 AI 会自动派 Explore 子 Agent 搜索代码（对应 3.3）。

// 代码块
你：/plan 给交易服务加订单导出功能，支持按日期范围筛选，导出 CSV。先理清现有订单查询逻辑。形成 md 文档。

AI：md 文档

方案确认后，让 AI 创建 SPEC 文档划分任务阶段（对应 3.1 的 SPEC coding 思路）：

// 代码块
你：创建 SPEC.md，划分任务阶段和每个阶段的子任务，包括开发、评估、测试。
AI：已创建 SPEC.md、开发任务.md。

6.3 第三步：编码 + 阶段验证

退出 Plan 模式开始编码，每完成一个可验证单元就跑测试（对应 3.1 的"编码"阶段）。过程中如果任务复杂，可以调高 effort（对应 3.2.2）。

// 代码块
你：/effort xhigh
你：开始实现，先做 OrderExportService

AI：修改 OrderExportService，编译通过。

你：跑 OrderExportService 的单测
AI：1 个边界用例失败：空日期范围未处理。

这里如果 AI 连续改不对，就 /rewind 回到改之前的状态重来，别硬改（对应 4.1.2）：

// 代码块
你：/rewind
AI：已回滚到测试失败前的检查点。

你：修复空日期范围边界，重跑测试
AI：已修复，单测全部通过。

6.4 第四步：评测

编码完成后进入评测阶段（对应 3.1 的"评测"阶段）。先用自定义子 Agent 做代码审查（对应 3.4）：

// 代码块
你：用 code-reviewer 子代理审查 OrderExportService

AI：审查结果：
    [WARNING] OrderExportService:45 大数据量未分批，建议加分页
    [INFO] OrderExportService:30 日期格式硬编码，建议提取常量

采纳 WARNING，让 AI 修复分批逻辑。但分批有两种方案拿不准，用 /branch 分叉会话并行验证（对应 4.1.1）。

主干会话先保留当前进度：

// 代码块
你：/branch 同步分页方案
AI：已从当前会话分叉，进入分支「同步分页方案」。

分支：同步分页方案

// 代码块
你：实现同步分页导出，跑压测记录 10 万行耗时
AI：同步分页实现完成。压测：10 万行耗时 8s，期间接口阻塞。

你：/branch 异步任务方案
AI：已从主干分叉，进入分支「异步任务方案」。

分支：异步任务方案

// 代码块
你：实现异步任务导出，跑压测记录 10 万行耗时
AI：异步任务实现完成。压测：立即返回任务 ID，后台 6s 跑完。

方案A 同步阻塞 8s，方案B 异步立即返回。选方案B。

之后就把分支：异步任务方案，作为主会话即可

6.5 第五步：目标驱动收尾

进入收尾阶段，用 /goal 驱动 AI 自主迭代到全部测试通过（对应 3.6）。/goal 执行过程中，AI 会根据需要自动派子 Agent 或开启 Workflow 完成各阶段子任务（对应 3.5）。

// 代码块
你：/goal 完成订单导出功能，要求：
    1) 支持按日期范围筛选
    2) 导出 CSV 含订单号/金额/状态
    3) 单测覆盖筛选逻辑和大数据量分批
    4) mvn test 全部通过

AI：目标已设定，开始推进……（自主派子 Agent 修剩余测试）
AI：目标达成，mvn test 全部通过。

如果任务更大、可拆成多个独立子任务，也可以直接用 Dynamic Workflow 自动编排（对应 3.5.2）：

// 代码块
你：用 dynamic workflow 把订单导出、用户导出、商品导出三个模块并行实现
AI：已拆为 3 个子任务，派 3 个子 Agent 并行处理，全部完成后汇总改动清单。

6.6 第六步：上下文管控

整个开发过程上下文用得多了，主动压缩（对应 4.2.2）。别等系统自动压缩，自动时机不可控可能压掉关键细节。

// 代码块
你：/compact 重点保留导出功能的接口契约和分批逻辑
AI：已压缩，保留指定重点，上下文已释放。

过程中如果想确认之前讨论过的某个细节，又不想打断主任务，用 /btw（对应 4.2.1）：

// 代码块
你：/btw 之前说的 CSV 编码是 UTF-8 还是 GBK？
AI：（浮层显示）之前确认用 GBK，兼容 Excel 直接打开。不影响主任务。

跨天中断后用 /resume 恢复（对应 4.2.3）；切换到完全不相关的任务用 /clear 清空。

6.7 第七步：归档 + 记忆沉淀

任务完成后归档（对应 4.4）：

// 代码块
你：总结本轮改动
AI：改动文件：OrderExportService（新增）、OrderController（加导出接口）、OrderExportServiceTest（新增）
    关键变更：复用 OrderMapper 查询 + OpenCSV 生成 + 异步分批导出
    未完成：导出文件清理策略待定

把这次踩的坑和关键决策沉淀到项目记忆，下次自动遵循（对应 4.3）：

// 代码块
你：把这个分批导出的决策记到项目记忆
AI：已写入 CLAUDE.md：导出类功能须异步分批，避免 OOM。

6.8 流程小结

步骤用到的能力对应章节
接入项目mc --code、/init、# 追加规则、Hook二、3.2.1、4.3.2、4.5
探索 + 计划/plan、Explore 子 Agent、SPEC3.1、3.2.3、3.3
编码 + 验证/effort、编译/测试、/rewind3.2.2、3.1、4.1.2
评测自定义子 Agent、/branch 多方案3.4、4.1.1
目标驱动/goal、Dynamic Workflow3.6、3.5
上下文管控/compact、/btw、/resume4.2
归档 + 记忆/recap、/memory4.4、4.3

一次完整开发，把前文的初始化、Plan、子 Agent、Workflow、/goal、/branch、/rewind、/compact、/btw、/memory、Hook、归档全串起来了。日常开发不必每次都用全，按任务复杂度选用的即可。

6.9 该任务真实使用提示词示例

// 代码块
/goal 给交易服务加订单导出功能。
开发目标：
1. 支持按日期范围（起止时间）筛选订单
2. 导出 CSV，含字段：订单号、金额（BigDecimal，单位分）、状态
3. 复用现有 OrderService.queryOrders() 查询逻辑，不重复造轮子
4. 大数据量导出须异步分批，避免 OOM
5. 单测覆盖日期筛选边界（含空范围）和分批逻辑
6. mvn test 全部通过

过程要求：
- 先理解现状再出方案
- 创建 SPEC 文档
- 编码必须有上下文独立子代理进行review / test
- 关键的开发决策记录到 log.md 供我审阅
- 合适的阶段启用 dynamic workflow 工具
- ...

边界要求：...

代码风格要求：...

...要求：...

问题处理：
- 不确定的先查 ...
- 还不确定找我人工确认

完成后给我一份总文档供我检查。

七、核心命令速查

命令怎么用使用时机关键细节
/goal <目标>设定持续目标，AI 循环推进直至达成复杂任务需自主迭代设定后 AI 反复推进不提前交卷；目标达成自动清除；可用 /goal clear 提前清
/branch <name>从当前对话分叉，保留主干上下文尝试替代方案又不想破坏当前进度分叉后两分支独立；可切换；代码改动作用于真实文件（和 git branch 无关，是会话分叉）
/btw <问题>顺带提问主任务执行中产生关联疑问不打断主任务，答案在主对话显示
/rewind回滚到之前的对话与代码状态编码方向错误、需撤销同时回滚对话+代码；可看到历史节点列表选择回滚到哪；快捷键 Esc Esc
/compact [重点]压缩上下文释放窗口上下文接近上限、完成阶段性任务后可指定保留重点，如 /compact 重点保留 API 设计决策；压缩后对话可正常继续，但细节可能丢失
/memory查看/编辑系统记忆与项目记忆追加规则、更新项目上下文编辑后立即生效
/resume恢复历史会话跨天/中断后继续列出历史会话可选；恢复后上下文还在
/clear清空当前会话切换全新任务清空后可通过 /resume 找回
/init生成/更新 CLAUDE.md首次接入新项目见第三章
/effort调思考深度复杂任务调高见第三章
/model切换模型任务类型变化时见第二章

建议： 主动用 /compact，别等系统自动压缩（自动时机不可控，可能正好压掉关键细节）。

八、以上内容和 AI-SDLC 的关系

定位差异

对象本质解释
个人 Coding SOP人工驾驭编程工具开发过程怎么做主要是在做这些事： 1. 发挥 claude code 编程能力 2. 给编程工具提供编程指引
Pipeline AI Workflow将人驾驭编程工具的方法论总结成一套标准的执行手册。并提供相应知识、对接工具的标准操作流程主要是在做这些事： 1. 提供知识 2. 一套完整的工程化执行手册 3. 与开发流程工具的标准接入指引 4. 分阶段管控，人只在某个阶段（PRD、开发、测试）完成后才介入 5. 每个阶段提供标准化评估、打分

对比 Pipeline AI Workflow

优势

  1. 可控性强。每一步都在人手里，方向偏了能立刻拉回来，适合需求模糊、需要边探索边定的任务。
  2. 轻量灵活。没有重型编排开销，小任务直接上手，大任务按需挑能力组合。
  3. 过程透明。每个决策点都看得见、改得了，适合学习和沉淀个人经验。

劣势/可优化点

  1. 手动成本高。人发指令多，不像 Pipeline 给个需求就能自动跑完需求分析到部署。
  2. 没有结构化交付物。Pipeline 会自动产出学城技术方案、测试用例、提测单、交付报告并保证研发规范合规；依赖人记得提，容易丢。
  3. 不强制合规。SOP 是建议性的；Pipeline 是流程编排，天然对齐研发规范。
  4. 团队不可规模化。SOP 强依赖个人熟练度，新人上手慢；Pipeline 是标准化流水线，可复制。
  5. 缺端到端闭环。没有提测、部署、报告回写等。
  6. 缺乏知识提供，依赖人工使用工具进行项目梳理
  7. 缺乏标准化评估、打分内容