安卓工程师多智能体自进化研发系统构建指南
🤖 本文档指导安卓手机软件工程师（应用/框架/内核/驱动）利用 Claude Code 构建个人智能体研发系统，实现代码学习、知识构建、问题自动分析、多版本回测和持续进化的全自动闭环。
一、系统定位
一句话定义：基于 Claude Code 的个人智能体研发系统 = 你的 24 小时 AI 搭档，自动学代码、读问题单、建知识、修 Bug、评估自己还缺什么。
核心理念：
- 不是给你一个工具，而是教你构建自己的系统
- 系统越用越强，具备自我进化能力
- 系统知道自己不知道什么，会主动向你求助
- AI 不缺智商，缺的是世界观。人的任务是给 AI 穿透局部视野的全局视角
graph TB subgraph 输入层 A[代码仓库 Gerrit/Git] B[Jira 问题单] C[技术文档/Wiki] D[Commit 历史] end subgraph 智能体核心 E[知识构建引擎] F[问题分析引擎] G[版本差异引擎] H[自我进化引擎] end subgraph 输出层 I[问题定位报告] J[知识图谱更新] K[版本影响分析] L[进化建议/知识缺口] end A --> E B --> F C --> E D --> G E --> F F --> I G --> K H --> J H --> L E --> H F --> H
二、工程纪律层（CC 规则体系）
⚡ 构建智能体系统之前，必须先建立工程纪律。以下规则直接配置到 CLAUDE.md，让 CC 自动遵守。
2.1 改动分级规则
| 级别 | 触发条件 | 流程 |
|---|---|---|
| 大改动 | 新模块、架构变更、跨文件接口修改 | 走完整七步闭环 |
| 中改动 | 功能迭代、逻辑调整、单模块重构 | 影响分析→改代码→回测 |
| 小改动 | Bug修复、参数调整、单文件修改 | 直接改→更新修改历史 |
2.2 七步闭环工作流（大改动必走）
graph LR S1[①提交需求] --> S2[②架构+影响分析] S2 --> S3[③更新测试文档] S3 --> S4[④三文档对齐] S4 --> S5[⑤生成代码+测试] S5 --> S6[⑥解决问题] S6 --> S7[⑦回测+增量报告]
2.3 六文档框架
项目启动必须建立以下文档骨架（内容可不完整，结构必须存在）：
| # | 文档 | 作用 |
|---|---|---|
| 1 | PRD 产品需求文档 | 定义”做什么” |
| 2 | 架构设计文档 | 定义”怎么组织” |
| 3 | 算法/模型调用设计 | 定义”核心逻辑” |
| 4 | 测试系统设计 | 定义”怎么验证” |
| 5 | 回测/Eval 系统设计 | 定义”怎么审计” |
| 6 | 代码修改历史 | 定义”改了什么” |
关键：文档核心目的是让 AI 理解项目全貌，不只是给人看。
2.4 代码修改前必答 Checklist
每次代码修改前，CC 必须回答：
- 此修改是否符合之前的架构承诺？
- 是否具备后向兼容？
- 是否会导致代码过度膨胀？
- 多次修改后是否仍具备可维护性？
- 需求、架构、测试三文档是否已对齐？（大/中改动必答）
- 是否已先仿真/回测再提交？（大/中改动必答）
2.5 ALWAYS / NEVER
ALWAYS：文档先行 | 接口变更必须先输出影响分析 | 多方案融合 | 给AI系统级方向 | 合入前跑回测
NEVER：跳过三文档一致性检查 | 无回测的大中改动合入 | 追求局部最优忽视全局 | Vibe Coding | 文档只给人看不给AI读
2.6 嵌入式经典库设计哲学
源自 FreeRTOS/SQLite/nanopb/libuv 等15个经典C库，适用于核心模块：
- 文件数即复杂度：核心源文件 ≤ 5
- 移植成本量化：适配层 = N个接口函数
- 禁止垃圾桶文件：不允许 utils/helpers/common
- 资源上限可预测：缓冲区/队列必须有上限
- 依赖接口而非实现：平台差异用目录隔离
三、五大能力模块
模块一：代码仓库接入
🎯 目标：让 CC 读懂你负责的代码仓库，理解模块结构、调用关系和历史演变。
Step 1：配置 CLAUDE.md 项目规则
在代码仓库根目录创建 .claude/CLAUDE.md：
# 项目概览
- 模块名称：[你的模块名]
- 所属层级：应用层/框架层/内核层/驱动层
- 核心职责：[一句话描述]
- 关键路径：[核心代码目录]
# 代码结构
- src/main/java/... → 主逻辑
- src/test/... → 单测
- Android.bp / Makefile → 构建配置
# 关联仓库
- 上游依赖：[仓库地址]
- 下游调用方：[模块列表]
# 问题单关联
- Jira 项目 Key：[PROJECT_KEY]
- 版本分支映射：main → Android 16, release/15 → Android 15
Step 2：配置 Git 接入权限
// ~/.claude/settings.json
"permissions": { "allow": ["git log *","git diff *","git show *","git blame *","git fetch *"] }
Step 3：建立代码索引习惯
你：分析仓库整体架构，输出模块依赖图和核心数据流
你：列出最近30天commit，按功能分类总结变更趋势
你：找出修改最频繁的10个文件，分析为什么是热点
模块二：Jira 问题单接入
🎯 目标：自动拉取、分析、关联 Jira 问题单，建立”问题→代码→修复”完整链路。
Step 1：配置 Jira MCP Server
// ~/.claude/settings.json
"mcpServers": {
"jira": {
"command": "npx",
"args": ["-y", "@anthropic/mcp-jira"],
"env": { "JIRA_URL": "https://jira.your-company.com", "JIRA_TOKEN": "xxx" }
}
}
Step 2：日常使用模式
你：拉取我负责的未解决问题单，按优先级排序
你：分析 PROJECT-456，结合代码历史给出可能根因
你：这个问题单关联了哪些 commit？修改是否完整覆盖问题场景？
模块三：知识体系构建
🎯 目标：从代码、问题单、文档中自动提炼知识，构建个人技术知识图谱。
知识构建三层模型：
graph TB subgraph 原始数据 A1[代码文件] A2[Commit历史] A3[问题单] A4[Code Review] end subgraph 知识提炼 B1[模块职责摘要] B2[问题模式库] B3[修复方案库] B4[架构决策记录] end subgraph 知识图谱 C1[模块关系图] C2[问题归因图] C3[版本演进图] end A1 --> B1 A2 --> B4 A3 --> B2 A3 --> B3 B1 --> C1 B2 --> C2 B4 --> C3
实操：用 Memory 系统积累知识
# ~/.claude/projects/your-project/memory/MEMORY.md 示例
- [模块A架构](module_a_arch.md) — 核心数据流和关键接口
- [高频问题模式](bug_patterns.md) — 历史问题归类和根因
- [版本差异](version_diff.md) — V15到V16关键变更
- [修复模板](fix_templates.md) — 常见问题的标准修复路径
模块四：问题自动分析与定位
🎯 目标：主动分析 Jira 问题单，结合代码和历史知识，自动输出定位方向。
自动分析流程：
graph LR A[1.学习分析] --> B[2.仿真评估] B --> C[3.方案实施] C --> D[4.一周回溯] D --> E[5.竞争淘汰] E --> A
每日工作流：
你：检查新分配的问题单，逐个初步分析
# CC 输出：
# [PROJECT-789] XX功能异常
# 置信度：高/中/低
# 可能根因：模块A在V16中行为变更
# 关联commit：abc123
# 知识缺口：模块B的回调时序未知，请补充
模块五：多版本差异分析
🎯 目标：自动对比安卓版本间代码差异，关联问题单，预测风险。
你：对比 release/15 和 main 在我模块的差异，分类并关联Jira
你：分析 commit abc123 影响了哪些调用方？有兼容性风险吗？
你：基于变更模式，哪些区域最可能产生新问题？
| 步骤 | 动作 | 自动化方式 |
|---|---|---|
| 变更检测 | 监控分支新commit | CC定时/Git hook |
| 影响分析 | 分析范围和风险 | CC读diff+blame |
| 关联问题 | 匹配历史问题单 | Jira MCP |
| 风险预警 | 输出报告标注高危 | CC→飞书通知 |
| 验证建议 | 给出重点测试场景 | 问题模式库生成 |
四、自我进化闭环
🔄 核心：系统不是静态工具，而是越用越强的进化体。进化来源于每一次问题解决的经验沉淀和自动竞争淘汰。
4.1 五步自动进化模型
flowchart TD A[新问题单] --> B[提取关键信息] B --> C{问题类型} C -->|Crash| D[堆栈+blame] C -->|功能异常| E[代码路径+diff] C -->|性能| F[热点+资源] C -->|兼容性| G[版本差异] D --> H[匹配历史模式] E --> H F --> H G --> H H --> I{有类似案例?} I -->|是| J[输出修复方案] I -->|否| K[输出方向+待补充信息] J --> L[报告+置信度评分] K --> L
| 步骤 | 功能 | 触发方式 |
|---|---|---|
| 1. 学习分析 | 从已解决问题提取模式，生成AB两条策略 | 每次问题解决后自动 |
| 2. 仿真评估 | 用历史问题回放测试两策略的定位效果 | 自动 |
| 3. 方案实施 | 部署优胜策略到知识库，保存快照用于回退 | 自动 |
| 4. 一周回溯 | 7天后对比部署前后指标，决定保留或回滚 | CC定时（每周一） |
| 5. 竞争淘汰 | 最多3个策略版本并行，效果差的淘汰 | 回溯时自动判定 |
4.2 进化机制四大核心
💡 以下四个机制是系统自我进化的引擎，确保系统越用越强、自动修正短板。
机制一：公式参数自适应
系统评估维度（准确率/效率/覆盖度/进化速度/缺口感知）中，最弱维度自动触发参数调整：
- 目标渐进：不追求一步到位，每周目标比上周提升5-10%
- 权重加重短板：最弱维度在下周获得更高的关注权重
- 示例：如果”交互效率”最弱（平均8轮），下周进化重点聚焦”如何用更少轮次定位”
# CLAUDE.md 进化配置
每周回溯后，自动识别最弱评价维度：
- 如果是"定位准确率"最弱 → 下周重点扩充问题模式库
- 如果是"交互效率"最弱 → 下周重点优化分析链路
- 如果是"知识覆盖度"最弱 → 下周重点填补知识缺口
机制二：教训累积
- 每日从问题解决过程中提取 3-5 条教训
- 教训格式：「场景 → 错误判断 → 正确路径 → 根因」
- 高置信度教训（连续3次验证有效）自动应用到分析规则中
- 低置信度教训保留观察，不自动应用
# 教训记录示例
场景：V16上SurfaceFlinger相关crash
错误判断：以为是app层生命周期问题
正确路径：实际是框架层VSYNC时序变更导致
根因：V16修改了VSYNC分发策略，旧逻辑在新时序下有竞态
置信度：高（第3次验证通过）→ 自动应用
机制三：自动提案
- 每周回溯时的”高优先级改进建议”自动进入 AB 仿真
- 分析中发现的”愚蠢行为”（明显错误的分析路径）自动生成修正方案
- 修正方案不直接应用，而是作为 B 版本与现有 A 版本竞争
# 自动提案流程
回溯发现：本周3次把"内存泄漏"误判为"UI卡顿"
自动提案：增加内存指标检查前置步骤
进入仿真：A版本(现状) vs B版本(增加内存前置检查)
7天后：对比两版本在类似场景的表现，胜者留下
机制四：多版本竞争
- 最多 3 个版本并行运行
- 每个新提案作为新版本加入竞争
- 7天后自动淘汰表现最差的版本
- 版本更替全自动，人只需在周报中确认
graph TB A[问题单] --> B[Reviewer Agent] A --> C[Localizer Agent] A --> D[Tester Agent] B --> E[协同决策] C --> E D --> E E --> F[综合分析报告]
4.3 进化触发配置
在 CLAUDE.md 中配置：
# 进化规则
每次完成问题单分析和修复后：
1. 提取"问题特征→根因路径→修复方案"三元组
2. 提取1-2条教训（错误判断+正确路径）
3. 与知识库已有模式对比，判断新模式or变体
4. 更新memory中的问题模式库
5. 评估：用更新后知识重新分析此问题，能否更快定位？
每周一自动回溯：
1. 计算五维评价指标
2. 识别最弱维度，调整下周权重
3. 汇总本周教训，高置信度的自动应用
4. 从"愚蠢行为"生成修正提案，进入AB仿真
5. 淘汰上周表现最差的竞争版本
6. 输出进化周报
五、智慧评价体系
5.1 评价维度
| 维度 | 指标 | 计算方式 | 目标值 |
|---|---|---|---|
| 定位准确率 | 首次分析方向正确比例 | 正确数/总分析数 | 第1月40%→第3月70% |
| 交互效率 | 从问题到定位平均轮次 | 总轮次/问题数 | 从8轮→3轮 |
| 知识覆盖度 | 模式库覆盖问题类型比例 | 已建模式/总类型 | 持续增长 |
| 进化速度 | 周指标提升幅度 | 本周-上周 | 正增长 |
| 缺口感知 | 主动识别缺口并求助次数 | 有效求助次数 | 每周≥3次 |
5.2 交互式知识缺口反馈
系统在分析问题时，如果置信度低于阈值，主动告知：
⚠️ 知识缺口提醒：
分析 PROJECT-789 时发现以下信息无法获取或理解：
1. 模块B的 onConfigChanged() 回调时序 — 缺少代码上下文
2. V15到V16 SurfaceFlinger VSYNC策略变更 — 知识库未覆盖
3. 复现条件涉及特定硬件平台 — 缺少硬件文档
请补充以上任一信息，将显著提升分析准确度。
补充后自动更新知识库，下次同类问题不再重复询问。
5.3 周报模板
📊 智能体研发系统进化周报（第N周）
━━━━━━━━━━━━━━━━━━━━━━━━
📈 五维评价：
定位准确率：65%（↑5%）
交互效率：4.2轮（↓0.8轮）
知识覆盖度：78%（↑3%）
进化速度：+5%（稳定）
缺口感知：4次（达标）
🧬 本周进化：
新增问题模式：3条
教训累积：12条（4条高置信度已自动应用）
AB仿真：v1.3-beta 胜出，已升为主版本
淘汰版本：v1.2（准确率低8%）
🎯 下周重点：
最弱维度：交互效率
自动调整：增加"快速排除"前置步骤
待补充知识：模块C的异步回调机制
六、分领域适配指南
应用层工程师
| 关注点 | CC配置重点 | 知识构建方向 |
|---|---|---|
| Activity/Fragment生命周期 | CLAUDE.md标注关键路径 | 生命周期异常的问题模式 |
| UI卡顿/ANR | 配置trace分析能力 | 主线程阻塞的常见根因 |
| 多进程通信 | 标注IPC接口和AIDL | 跨进程调用异常模式 |
| 第三方SDK | 记录版本和已知问题 | SDK升级兼容性问题库 |
框架层工程师
| 关注点 | CC配置重点 | 知识构建方向 |
|---|---|---|
| 系统服务交互 | 标注SystemServer服务入口 | 服务依赖和启动顺序 |
| 权限与安全 | 配置权限路径和SELinux | 权限拒绝排查路径 |
| 跨版本API兼容 | 标注@hide和@SystemApi变更 | API变更影响范围 |
| 多模块协同 | 建立接口契约文档 | 接口变更连锁反应 |
内核层工程师
| 关注点 | CC配置重点 | 知识构建方向 |
|---|---|---|
| 调度/内存 | 标注内核配置和关键路径 | OOM/调度异常分析 |
| panic/oops | 配置dmesg/crash解析 | panic堆栈快速归因 |
| 性能调优 | 标注sysfs/procfs节点 | 性能异常根因定位 |
| 上游合入 | 跟踪upstream和backport | 合入冲突预测 |
驱动层工程师
| 关注点 | CC配置重点 | 知识构建方向 |
|---|---|---|
| 硬件寄存器 | 导入datasheet描述 | 寄存器配置错误模式 |
| DTS/设备树 | 标注设备树和绑定文档 | 设备树快速排查 |
| 中断/DMA | 记录中断号和DMA通道 | 中断风暴/DMA超时根因 |
| 电源管理 | 标注suspend/resume路径 | 功耗异常和唤醒源 |
七、实战案例：桌面仿真系统的智能体化
🔬 以下以 HyperLauncher 桌面仿真系统为例，展示如何将一个真实的大型安卓项目接入智能体研发系统。
7.1 项目概况
HyperLauncher 是 HyperOS 的核心桌面系统，采用 Rust + Flutter 混合架构：
| 组件 | 代码量 | 语言 | 职责 |
|---|---|---|---|
| HyperLauncher核心 | 188,099行 | Rust | 后端业务逻辑 |
| HyperLauncherUI | 50,000+行 | Dart/Flutter | UI层 |
| engine_platform | 102个模块 | Rust | HyperOS框架接口 |
| abi | 71个子目录 | Rust | 接口定义层 |
7.2 CLAUDE.md 配置示例
# HyperLauncher 智能体配置
## 项目概览
- 模块：HyperLauncher 桌面系统
- 所属层级：应用层 + 框架层
- 核心职责：桌面管理、手势交互、最近任务、负一屏
- 关键路径：src/launcher/, src/recents/, src/personal_assistant/
## 核心模块
- launcher/domain/ → 桌面核心逻辑（文件夹/图标/模式/MAML）
- recents/ → 最近任务+全面屏手势（29个文件，核心152K行）
- api/ → 对外接口（65个子文件）
- foundation/ → 业务基础能力
## 版本支持
- OS3 / OS4 双版本
- miuiHome / pocoHome 双flavor
- flutter_rust_bridge 跨语言通信
## 问题单关联
- Jira Key：LAUNCHER
- 分支映射：main → OS4, release/os3 → OS3
## 改动分级补充
- recents/base_recents_impl.rs (152K行) 属于超大文件，任何修改按"大改动"处理
- api/ 目录变更必须走七步闭环（接口影响全局）
7.3 知识冷启动示例
Day 1：模块全景
你：分析 src/ 下的目录结构，画出 launcher/recents/personal_assistant 三大模块的依赖关系
你：flutter_rust_bridge 的通信机制是什么？数据流向如何？
Day 2-3：热点分析
你：最近3月 recents/ 目录的修改频率如何？哪些文件是 hotspot？
你：手势系统 (gesture/) 和动画系统 (animation/) 之间的接口是什么？
Day 4-5：问题模式
你：git log 中 recents 相关的 bug fix commit，分析共性模式
你：OS3→OS4 之间 recents 模块有哪些行为变更？
Day 6-7：建立知识库
你：把以上分析结果记录到 memory，建立问题模式库初版
7.4 问题自动分析示例
# 收到问题单：LAUNCHER-1234 "OS4上最近任务滑动卡顿"
你：分析 LAUNCHER-1234
# CC 输出：
置信度：中
可能根因：
1. recents/animation/ 中 OS4 新增的 VSYNC 对齐逻辑（关联 commit abc123）
2. base_recents_impl.rs 中任务列表刷新逻辑在大量任务时的性能退化
关联变更：OS3→OS4 共 12 个 commit 涉及 recents 动画
建议验证：
- 检查任务数 > 20 时的帧率
- 对比 OS3 同场景表现
知识缺口：
- 我不了解 OS4 新增的帧率控制策略，请补充
八、手把手实操：从零搭建
Phase 1：环境搭建（第1天）
# 1. 安装 Claude Code
npm install -g @anthropic-ai/claude-code
claude --version
# 2. 进入项目，初始化配置
cd ~/your-android-project
mkdir -p .claude
touch .claude/CLAUDE.md
# 3. 配置权限
claude
/permissions add "git log *"
/permissions add "git diff *"
/permissions add "git show *"
/permissions add "git blame *"Phase 2：知识冷启动（第1-2周）
每天30分钟与CC对话：
- Day 1-3：模块全景（架构图、接口、调用关系）
- Day 4-7：问题历史（git log fix/bug、修复模式、热点文件）
- Day 8-14：版本差异（分支对比、变更分类、风险预测）
Phase 3：问题驱动进化（第3周起）
标准工作流：
- 收到问题单 → CC初步分析（含置信度+知识缺口）
- 补充缺失信息或纠正方向
- 定位成功 → 触发学习，更新模式库，提取教训
- 周末回溯 → 评估表现，生成进化报告
Phase 4：全自动运行（第2个月起）
- 每天8:30 自动分析新问题单
- 每周一 自动输出进化周报
- 新commit自动触发影响分析
- 教训自动累积和应用
- AB版本自动竞争淘汰
九、成熟度模型
graph LR L1[Lv1 工具使用] --> L2[Lv2 知识积累] L2 --> L3[Lv3 自动分析] L3 --> L4[Lv4 主动进化] L4 --> L5[Lv5 预测预防]
| 阶段 | 能力标志 | 预计时间 | 关键动作 |
|---|---|---|---|
| Lv1 工具使用 | 能用CC读代码/搜索/生成diff | 第1周 | 环境配置+基本命令 |
| Lv2 知识积累 | Memory 20+条有效记录 | 第2-3周 | 每次解决问题后记录 |
| Lv3 自动分析 | 首次分析准确率>50% | 第1-2月 | 积累问题模式库 |
| Lv4 主动进化 | 系统能主动发现缺口并求助 | 第2-3月 | 配置进化规则+评价指标 |
| Lv5 预测预防 | 合入前能预警潜在问题 | 第3-6月 | 版本差异+模式交叉分析 |
十、核心原则
💡 记住这些原则，避免走弯路。
1. 文档先行，代码跟进 — 先写好 CLAUDE.md，让CC理解项目
2. 每次问题都是训练数据 — 坚持记录，量变引起质变
3. 进化才是关键 — 初期准确率低正常，每周进步才重要
4. 人机协作 — 系统给方向你做判断，系统缺什么你来补
5. 晚上跑，早上看 — 最终形态：自动分析/检索/评估，你只审阅结论
6. 给AI全局视角 — AI不缺智商缺世界观，人给穿透局部的全局视角
7. 文档固化认知→实验驱动方案→回测闭环质量
附录A：行业前沿实践参考（搜索智能体学习成果）
🌐 以下内容来自多路智能体搜索系统的学习成果，涵盖学术论文、开源项目和行业实践，作为本系统的思想输入。
A.1 核心参考架构
SWE-agent（普林斯顿大学）— 自主Bug修复Agent
核心创新：Agent-Computer Interface（ACI）概念，类似人机界面（HCI）但面向LLM智能体。
| 组件 | 功能 | 对我们的启发 |
|---|---|---|
| ACI接口 | 自定义文件查看/编辑/搜索命令 | CC的MCP工具体系就是我们的ACI |
| ReACT循环 | 思考→动作→观察→再思考 | 问题分析的迭代式推理链 |
| 仓库导航 | 智能定位关键代码区域 | 知识图谱驱动的代码导航 |
| 修复验证 | 自动生成测试验证修复 | 回测/Eval闭环 |
启发：我们的系统本质是一个 领域专精的SWE-agent，专精于安卓代码，且具备持续进化能力（SWE-agent不具备）。
AutoCodeRover — 自主Bug定位与修复
核心方法：频谱分析 + LLM推理 的混合定位
定位流程：
1. 从问题描述提取关键词和症状
2. 用代码搜索API定位候选文件（类似我们的 git blame + grep）
3. LLM分析候选代码与问题的关联度
4. 生成修复方案并验证
启发：我们的”问题自动分析”模块可以借鉴此混合方法：先用确定性工具缩小范围，再用LLM做深度推理。
AgentFL — LLM驱动的故障定位
核心创新：结合静态分析+测试结果+LLM推理的三角验证
启发：我们的置信度评分可以用三角验证：
- 代码分析支持？（+30%）
- 历史模式匹配？（+40%）
- 版本差异关联？（+30%）
A.2 多智能体协作模式
行业趋势：多Agent分工协作进行代码审查
graph TD A[当前主版本 v1.2] --> B{新提案产生} B --> C[v1.2 继续运行] B --> D[v1.3-beta 并行运行] C --> E{7天后对比} D --> E E -->|v1.3胜| F[v1.3升为主版本] E -->|v1.2胜| G[淘汰v1.3] F --> H[进入下一轮进化] G --> H
| Agent角色 | 职责 | 对应我们系统 |
|---|---|---|
| Reviewer Agent | 代码质量和模式审查 | 知识构建引擎 |
| Localizer Agent | 故障定位和根因分析 | 问题分析引擎 |
| Tester Agent | 测试覆盖和验证 | 版本差异引擎 |
| Coordinator | 协调各Agent结果 | 自我进化引擎 |
启发：未来可将单一CC对话拆分为多个专精Agent并行工作，各自积累领域知识。
A.3 知识图谱驱动的代码理解
GraphRAG（微软）+ CodeKG 方法
传统RAG：文本切片→向量检索→LLM生成
GraphRAG：代码→知识图谱→图遍历→结构化上下文→LLM推理
| 方法 | 优势 | 劣势 |
|---|---|---|
| 纯文本RAG | 简单快速 | 丢失结构关系 |
| GraphRAG | 保留调用关系/依赖/演变 | 构建成本高 |
| 我们的Memory | 轻量+可演化 | 需人工触发积累 |
启发：我们的Memory系统本质是一个”轻量级知识图谱”。进化方向：
- 近期：继续用Memory积累，人工触发
- 中期：自动从commit/问题单中提取知识三元组
- 远期：构建模块级的代码知识图谱
A.4 自我进化Agent的最新研究
ADAS（Automated Design of Agentic Systems，2025）
核心发现：Agent可以通过自我反思自动改进自己的Prompt和工具使用策略。
| 进化方式 | 方法 | 我们的对应 |
|---|---|---|
| Prompt进化 | 根据成功/失败调整分析提示 | CLAUDE.md规则自动优化 |
| 工具进化 | 学习何时用什么工具最有效 | CC工具调用模式学习 |
| 策略进化 | 从经验中归纳分析策略 | 问题模式库自动扩充 |
| 评估进化 | Agent自己生成benchmark | 历史问题回放验证 |
启发：我们的”教训累积”机制正是ADAS的轻量级实现——从失败中学习，高置信度自动应用。
OpenHands（原OpenDevin）— 开源自我改进编码Agent
核心特性：
- 沙箱执行环境中试错
- 从执行反馈中强化学习
- 工作流自动优化
启发：我们的AB仿真竞争就是类似思路——两个版本在真实问题上竞争，胜者留下。
A.5 综合对比：我们的系统 vs 行业方案
| 维度 | SWE-agent | Devin | 我们的系统 |
|---|---|---|---|
| 定位 | 通用Bug修复 | 通用开发 | 安卓专精+持续进化 |
| 知识积累 | 无（每次从零） | 有限上下文 | Memory持续积累 |
| 自我进化 | 无 | 无 | AB竞争+教训累积+参数自适应 |
| 多版本管理 | 无 | 无 | 3版本并行竞争淘汰 |
| 知识缺口感知 | 无 | 无 | 主动识别+向人求助 |
| 领域深度 | 浅（通用） | 浅（通用） | 深（安卓四层专精） |
| 部署成本 | 高（需GPU） | 高（SaaS） | 低（本地CC即可） |
我们的核心差异化优势：
- 持续进化 — 不是一次性工具，越用越强
- 领域专精 — 深耕安卓四层（应用/框架/内核/驱动）
- 低成本 — 只需一台电脑 + Claude Code 订阅
- 人机协作 — 系统主动求助，人机互补而非替代
A.6 将研究成果转化为实践
以下是从行业研究中提炼的可直接落地的改进方向：
| 来源 | 可落地方案 | 优先级 | 实施难度 |
|---|---|---|---|
| SWE-agent ACI | 封装常用分析命令为CC自定义工具 | 高 | 低 |
| AutoCodeRover混合定位 | 确定性工具缩范围+LLM深度推理 | 高 | 低 |
| AgentFL三角验证 | 置信度=代码分析+历史模式+版本关联 | 高 | 中 |
| GraphRAG | Memory中增加模块关系索引 | 中 | 中 |
| ADAS自动Prompt优化 | 教训累积后自动调整CLAUDE.md规则 | 中 | 低 |
| 多Agent协作 | 拆分为定位Agent+审查Agent+测试Agent | 低 | 高 |
| OpenHands沙箱试错 | AB仿真用历史问题做沙箱验证 | 已实现 | — |
💡 核心结论：行业最前沿的研究方向（自我进化、多版本竞争、知识图谱、缺口感知）我们的系统架构已全部覆盖。差异在于我们更接地气——直接用CC+Memory实现，无需额外基础设施。
附录B：全自动修复流水线设计
🔧 核心升级：系统从”分析助手”进化为”全自动修复流水线”。输入输出自动对接，问题从进入到修复全程自动化，仅在合入前需要人工审核。
B.1 全链路自动化架构
flowchart LR subgraph 自动输入对接 I1[Jira Webhook] -->|新问题单| P I2[Git Hook] -->|新commit/合入| P I3[CI/CD] -->|构建失败| P I4[Crash上报] -->|新crash| P end subgraph P[自动分析流水线] A1[问题分类] --> A2[根因定位] A2 --> A3[方案生成] A3 --> A4[代码编写] A4 --> A5[自动评测] A5 --> A6[回测验证] end subgraph 自动输出对接 A6 -->|通过| O1[生成MR/PR] A6 -->|失败| O2[回退+重新分析] O1 --> O3[人工审核] O3 -->|通过| O4[自动合入] O3 -->|拒绝| O5[反馈学习] end
B.2 输入自动对接
📥 系统通过 Webhook/MCP/Hook 三种方式自动感知外部事件，无需人工触发。
方式一：Jira Webhook → CC 自动启动分析
# 配置 Jira Webhook（项目管理员操作一次）
Webhook URL: http://your-server:8080/api/jira-event
触发事件：Issue Created / Issue Updated / Issue Assigned to Me
# CC 侧配置（~/.claude/hooks/jira_trigger.sh）
#!/bin/bash
# 当收到新问题单分配时，自动启动分析
ISSUE_KEY=$1
claude --yes --prompt "
自动分析模式启动：
1. 拉取 $ISSUE_KEY 问题单详情
2. 执行完整根因定位流程
3. 如果置信度>70%，自动生成修复代码
4. 如果置信度<70%，输出分析报告等待人工补充
"
方式二：Git Hook → 新合入自动影响分析
# .git/hooks/post-merge 或 CI pipeline 配置
#!/bin/bash
COMMITS=$(git log --oneline ORIG_HEAD..HEAD)
claude --yes --prompt "
新代码合入检测：
变更commit: $COMMITS
执行：
1. 分析变更影响范围
2. 匹配历史问题模式，预测风险点
3. 如果高风险，自动创建预防性问题单
4. 输出影响分析报告到飞书
"方式三：Crash 上报自动触发
# 监控 crash 上报系统的新增 crash
# 当同一堆栈出现 N 次以上，自动触发分析
触发条件：同堆栈 crash ≥ 5次/小时
自动动作：
1. 解析堆栈，提取关键帧
2. git blame 定位最近修改者和 commit
3. 关联 Jira 问题单（如已有则自动关联，无则自动创建）
4. 启动自动修复流程
B.3 自动分析 → 自动修复流程
flowchart TD A[问题输入] --> B[Step1: 问题分类与优先级] B --> C[Step2: 智能根因定位] C --> D{置信度评估} D -->|≥70%| E[Step3: 自动生成修复方案] D -->|<70%| F[输出分析报告→等人工补充] E --> G[Step4: 自动编码实现] G --> H[Step5: 自动评测] H --> I{测试通过?} I -->|通过| J[Step6: 回测验证] I -->|失败| K[自动修正→重试最多3次] K --> H J --> L{回测通过?} L -->|通过| M[生成PR + 通知人工审核] L -->|失败| N[回退→标记为需人工介入] F --> O[人工补充信息] O --> C
各步骤详细设计：
Step 1：问题分类与优先级
# CC 自动执行
输入：问题单标题 + 描述 + 附件（堆栈/日志/截图）
输出：
- 问题类型：Crash / ANR / 功能异常 / 性能退化 / 兼容性
- 严重程度：P0-P3
- 涉及模块：[模块列表]
- 是否可自动修复：是/否/需更多信息
Step 2：智能根因定位
# 混合定位策略（借鉴 AutoCodeRover）
Phase 1 - 确定性缩范围：
- 堆栈分析 → 锁定文件/函数
- git blame → 找到最近修改
- git log → 关联近期变更
Phase 2 - LLM深度推理：
- 阅读目标代码上下文
- 匹配历史问题模式库
- 分析版本差异关联
- 输出根因假设 + 置信度
Step 3：自动生成修复方案
# CC 生成修复方案（遵守工程纪律）
输入：根因分析结果 + 受影响代码
过程：
1. 生成 2-3 个修复方案（借鉴 AB 思路）
2. 每个方案自评：影响范围/兼容性/复杂度/风险
3. 选择最优方案（最小修改、最小影响、最高兼容）
4. 执行修改前 Checklist：
- 是否符合架构承诺？
- 是否后向兼容？
- 是否代码膨胀？
输出：选定的修复方案 + 变更文件列表
Step 4：自动编码实现
# CC 直接修改代码
原则：
- 最小修改原则：只改必须改的
- 遵守现有代码风格
- 不引入新依赖（除非必要）
- 同时更新单测（如果修复涉及逻辑变更）
输出：
- 修改后的代码文件
- 新增/修改的单元测试
- commit message（包含问题单编号）
Step 5：自动评测
# 自动运行评测套件
评测层级：
Level 1: 编译通过检查
./gradlew build 或 cargo build --release
Level 2: 单元测试
./gradlew test 或 cargo test
Level 3: 相关模块集成测试
./gradlew :affected-module:connectedTest
Level 4: 静态分析
lint / detekt / clippy 无新增 warning
Level 5: 修复验证
复现问题 → 应用修复 → 验证问题不再出现Step 6：回测验证
# 确保修复不引入回归
回测内容：
1. 受影响模块的全量用例
2. 关联模块的冒烟用例
3. 性能基准对比（修复前 vs 修复后）
4. 历史同类修复的副作用检查
通过标准：
- 所有已有测试 pass
- 性能指标无退化（允许 ±2% 波动）
- 无新增 crash/ANR 风险
B.4 输出自动对接
自动生成 MR/PR：
# 评测+回测全部通过后自动执行
git checkout -b fix/$ISSUE_KEY
git add .
git commit -m "[$ISSUE_KEY] 自动修复: $FIX_SUMMARY
根因: $ROOT_CAUSE
修复方案: $FIX_APPROACH
评测结果: 全部通过
回测结果: 无回归
Auto-fixed by AI Agent System"
git push origin fix/$ISSUE_KEY
# 自动创建 MR，指定 reviewer 为问题单负责人自动通知人工审核：
# 通过飞书/企业微信发送审核通知
📋 自动修复完成，等待审核
━━━━━━━━━━━━━━━━━━
问题单：LAUNCHER-1234
根因：recents 模块在 OS4 上 VSYNC 时序变更导致帧丢失
修复：调整 animateFrame() 的时序对齐逻辑
变更文件：2个 (+15行 / -3行)
评测：5/5 通过 ✅
回测：无回归 ✅
置信度：85%
MR链接：[点击审核]
━━━━━━━━━━━━━━━━━━
⚡ 请在24小时内审核，超时将自动提醒
B.5 人工审核门禁
🚧 人工审核是唯一的强制门禁。系统再智能，合入前必须经过人的判断。
审核流程：
白板流程图： （内容无法获取）
审核人只需关注：
- 修复方向是否正确？（根因判断对不对）
- 修复方式是否合理？（有没有更好的改法）
- 有没有遗漏的影响？（系统没考虑到的边界）
审核结果反馈循环：
- Approve → 系统学到：这类问题我能独立修复
- Request Changes → 系统学到：修复方向对但实现细节需改进
- Reject → 系统学到：这类问题我还不能自动修复，降低自动修复阈值
B.6 全流程自动化配置模板
# CLAUDE.md 自动修复配置
## 自动修复规则
自动修复触发条件：
- 问题类型：Crash / ANR / 编译错误
- 置信度阈值：≥ 70%
- 影响范围：单文件修改 ≤ 50行
- 模块范围：仅限我负责的模块
禁止自动修复的场景：
- 架构变更（跨文件接口修改）
- 性能优化（需要 benchmark 数据支撑）
- 新功能开发（需求不明确）
- 安全相关修改（需要专项审查）
## 自动修复流程配置
最大重试次数：3
评测超时时间：10分钟
回测范围：受影响模块 + 一跳关联模块
通知方式：飞书消息 + Jira评论
审核超时：24小时提醒，48小时升级
## 输入对接
Jira Webhook：已配置，自动触发
Git Hook：post-merge 自动分析
Crash监控：同堆栈 ≥5次/小时 自动触发
CI失败：编译错误自动尝试修复
## 输出对接
MR自动创建：fix/$ISSUE_KEY 分支
Jira自动更新：添加分析评论 + 关联MR
飞书通知：审核请求 + 进化周报
知识库更新：每次修复后自动记录
B.7 安全护栏
💡 全自动化必须有安全边界，防止系统”自信地犯大错”。
| 护栏 | 规则 | 触发动作 |
|---|---|---|
| 修改量限制 | 单次修改 > 100行 | 暂停，转人工 |
| 影响范围限制 | 变更 > 3个文件 | 暂停，转人工 |
| 重试次数限制 | 评测失败 > 3次 | 放弃，标记需人工 |
| 置信度下限 | 定位置信度 < 50% | 仅输出报告，不修复 |
| 模块边界 | 修改非我负责的模块 | 禁止，通知模块owner |
| 回测退化 | 性能退化 > 5% | 回退修改，报警 |
| 连续失败 | 连续3个问题修复被reject | 暂停自动修复，进入学习模式 |
B.8 端到端时间线
| 阶段 | 耗时 | 说明 |
|---|---|---|
| 输入感知 | < 1分钟 | Webhook/Hook 实时触发 |
| 问题分析+定位 | 5-15分钟 | 取决于代码库大小和复杂度 |
| 方案生成+编码 | 5-10分钟 | CC 生成代码 |
| 自动评测 | 10-30分钟 | 编译+测试+lint |
| 回测验证 | 10-30分钟 | 模块级回归测试 |
| 人工审核 | 0.5-24小时 | 唯一的人工环节 |
| 合入+收尾 | < 5分钟 | 自动合入+更新状态 |
理想场景：晚上10点收到 Crash 问题单 → 凌晨自动完成分析+修复+评测 → 早上8:30你收到审核通知 → 审核通过一键合入。全程人只花5分钟审核。
附录C：搜索智能体文献学习 → 本系统的思想输入
📚 以下内容来自搜索智能体系统（~/Desktop/搜索智能体/）自动采集的1,096篇文献中筛选出的高价值成果，直接转化为本系统的设计改进。
C.1 可直接采纳的技术方案
从搜索智能体的9大进化提案和245篇达标文献中，筛选出对”安卓工程师智能体研发系统”直接有价值的6项：
| # | 源文献/提案 | 核心方法 | 对本系统的价值 | 优先级 |
|---|---|---|---|---|
| 1 | RAG成本优化（已部署v1.0.1） | BM25+低维向量混合检索+LLM缓存 | 知识库检索效率提升，减少无效LLM调用 | 高 |
| 2 | MultiHop-RAG论文 | 多跳查询分解与文档链构建 | 复杂Bug定位需跨模块多跳推理 | 高 |
| 3 | 前置语义过滤提案 | Sentence-BERT匹配过滤低相关结果 | 问题分析时快速排除无关代码/commit | 高 |
| 4 | 动态Pipeline处理 | 根据内容质量调整处理深度 | 小问题轻量分析、大问题深度分析 | 中 |
| 5 | 关键词自驱动进化 | 从高质量结果自动提取新搜索方向 | 知识库自动扩展搜索范围 | 中 |
| 6 | PPO强化学习优化检索权重 | 将检索策略建模为MDP | 问题模式匹配准确度自动优化 | 低（远期） |
C.2 高价值思想转化
思想1：混合检索（BM25 + 向量） → 问题定位的混合策略
搜索智能体实践证明：纯语义检索不如混合检索。
转化到问题定位：
纯LLM推理定位：置信度不稳定，有时"幻觉"
混合定位策略（已采纳）：
Phase 1 确定性工具（git blame/grep/diff） → 缩小范围（类似BM25精确匹配）
Phase 2 LLM深度推理 → 在小范围内精准分析（类似向量语义理解）
效果：LLM只需分析5-10个候选文件，而非整个仓库
成本：分析时间从15分钟降至5分钟
思想2：多跳推理（MultiHop-RAG） → 跨模块因果链分析
搜索智能体发现：复杂问题的答案分散在多个文档中，需要多跳检索。
转化到Bug定位：
安卓Bug的因果链往往跨多个模块：
App层crash → 框架层状态异常 → 内核层资源竞争 → 驱动层时序问题
多跳定位模型：
Hop 1：从crash堆栈定位到App层代码
Hop 2：从App层调用追踪到框架层服务
Hop 3：从框架层服务关联到内核资源
Hop 4：从内核资源定位到驱动时序
每一跳都用"确定性工具缩范围 + LLM推理确认"
思想3：前置语义过滤 → 问题单噪声过滤
搜索智能体教训：87%的搜索结果无价值但仍消耗LLM分析。
转化到问题分析：
问题：git log 返回100个commit，其中只有3个真正相关
解法：前置过滤层
Step 1：按文件路径过滤（只保留涉及问题模块的commit）
Step 2：按时间窗口过滤（问题出现前后2周）
Step 3：按commit message语义匹配过滤
Step 4：剩余5-10个commit送入LLM深度分析
效果：LLM分析量减少90%，速度提升10x
思想4：动态Pipeline → 问题分级处理
搜索智能体教训：所有内容走相同处理深度是浪费。
转化到本系统（已与”改动分级”对齐）：
轻量Pipeline（小问题/高置信度）：
问题分类 → 模式匹配 → 直接输出方案 → 跳过仿真
耗时：2-3分钟
标准Pipeline（中等问题）：
完整分析 → 方案生成 → 评测 → 回测
耗时：30-60分钟
深度Pipeline（大问题/低置信度）：
多跳推理 → 多方案AB → 仿真对比 → 评测 → 回测 → 进化学习
耗时：2-4小时
思想5：自我反思机制 → 智慧评价的自省能力
搜索智能体每周自动评分（当前66/100），自动诊断”愚蠢行为”。
直接采纳到本系统：
每周自动生成"系统智商评分"：
搜索精度（问题定位首轮准确率） → X/10
过滤智慧（无效分析路径占比） → X/10
学习能力（新模式提取效率） → X/10
进化能力（周指标提升幅度） → X/10
资源效率（LLM调用有效率） → X/10
自动诊断"愚蠢行为"：
- 连续3次同类误判 → 自动提案修正
- 高成本低产出的分析路径 → 自动优化
- 知识库命中率持续下降 → 自动扩充
思想6：关键词进化 → 知识搜索范围自动扩展
搜索智能体的关键词从初始种子词自动进化出新方向。
转化到本系统：
初始"知识种子"：
- 你负责的模块名称
- 已知问题类型关键词
- 版本代号
自动扩展：
每次解决一个问题后，提取新的搜索关键词：
- 从根因中提取技术术语（如"VSYNC时序"、"Binder死锁"）
- 从修复方案中提取模式名（如"双重检查锁"、"延迟初始化"）
- 自动扩展到相关模块和上下游
效果：系统的"知识雷达"范围自动增长
C.3 搜索智能体的教训 → 本系统的设计避坑
| 搜索智能体的教训 | 原因 | 本系统如何避免 |
|---|---|---|
| 达标率仅22.4% | 关键词太宽泛 | 限定搜索范围为”我负责的模块+直接依赖” |
| unknown分类占44% | 分类器不够精确 | 问题类型严格限定为5类（Crash/ANR/功能/性能/兼容） |
| 进化停滞 | 保守策略不探索 | 强制每周至少1个新提案进入AB仿真 |
| 87%预筛浪费 | 没有前置过滤 | 三层过滤后再送LLM（路径/时间/语义） |
| 宽泛关键词污染 | 通用词返回大量噪声 | 所有搜索限定模块上下文 |
C.4 系统”智商”进化对标
搜索智能体当前智商评分：66/100（“勤奋但低效”）
本系统目标进化路径：
| 时间 | 目标智商 | 关键突破 |
|---|---|---|
| 第1月 | 40/100 | 能用、能分析，但经常错 |
| 第2月 | 55/100 | 准确率过半，开始有记忆 |
| 第3月 | 70/100 | 大多数分析可用，进化稳定 |
| 第6月 | 80/100 | 能预测、能自动修复、知道自己不知道什么 |
| 第12月 | 90/100 | 堪比资深工程师的分析判断力 |
💡 核心启示：搜索智能体用1096篇文献+9个进化提案验证了”5步自动进化”模型的有效性。其中混合检索、多跳推理、前置过滤、动态Pipeline、自我反思五大方法论已证明可行，可直接移植到本系统。搜索智能体犯过的错误（宽泛搜索、无前置过滤、进化停滞）是本系统要提前避免的设计陷阱。
附录D：新项目启动模板（CLAUDE.md 配置清单）
🚀 开启一个新项目时，必须先将以下信息提交给 Claude Code。全部写入 .claude/CLAUDE.md 文件。前5项必填，后3项选填。
D.1 完整信息清单
| 序号 | 类别 | 必填/选填 | 说明 |
|---|---|---|---|
| 1 | 项目身份 | 必填 | 名称、层级、职责、仓库、技术栈 |
| 2 | 代码结构 | 必填 | 目录说明、核心文件、构建命令 |
| 3 | 架构约束 | 必填 | 模块依赖、设计原则、禁止事项 |
| 4 | 编码规则 | 必填 | 代码风格、质量红线、测试要求 |
| 5 | 改动分级 | 必填 | 大/中/小改动的触发条件和流程 |
| 6 | 关联系统 | 选填 | Jira配置、上下游、CI/CD |
| 7 | 知识输入 | 选填 | 高频问题模式、历史教训、关键人 |
| 8 | 进化配置 | 选填 | 自动修复规则、评价指标、进化目标 |
D.2 CLAUDE.md 完整模板
以下为可直接复制使用的模板，工程师只需填入自己项目的具体信息：
# ═══════════════════════════════════════
# 一、项目身份
# ═══════════════════════════════════════
## 项目概览
- 项目名称：[英文标识] / [中文描述]
- 所属层级：应用层 / 框架层 / 内核层 / 驱动层
- 一句话职责：[这个项目做什么]
- 代码仓库：[Git URL]
- 主语言：[语言 + 框架 + 构建工具]
- 目标平台：[Android版本/硬件平台]
# ═══════════════════════════════════════
# 二、代码结构
# ═══════════════════════════════════════
## 关键目录
- src/main/ → 核心逻辑
- src/api/ → 对外接口
- src/test/ → 测试代码
- docs/ → 项目文档
## 核心文件（修改需谨慎）
- [文件路径] ([行数]) → [说明，修改按什么级别处理]
## 构建命令
- 编译：[命令]
- 测试：[命令]
- Lint：[命令]
- 部署：[命令]
# ═══════════════════════════════════════
# 三、架构约束
# ═══════════════════════════════════════
## 模块依赖关系
- 模块A → 依赖模块B（通过接口层）
- 模块C → 禁止直接依赖模块A
## 设计原则
- [原则1：例如所有跨模块通信走事件总线]
- [原则2：例如数据层与UI层严格分离]
- [原则3：例如平台差异用目录物理隔离]
## 禁止事项
- NEVER 引入 [xxx] 依赖
- NEVER 直接修改 [xxx] 接口
- NEVER 在 [xxx] 模块中使用 [xxx] 模式
# ═══════════════════════════════════════
# 四、编码规则
# ═══════════════════════════════════════
## 代码风格
- 命名规范：[snake_case / camelCase / PascalCase]
- 文件组织：一个文件一件事，文件名即职责描述
- 注释要求：接口必须doc注释，内部逻辑不强求
- 日志规范：[格式要求]
## 质量红线
- 模块核心源文件数 ≤ 5
- 禁止 utils/helpers/common 等垃圾桶文件
- 缓冲区/队列/缓存必须有配置上限
- 依赖接口而非实现，平台差异用目录隔离
- 引入第三方库前先问：自写需要多少行？<200行则自写
## 测试要求
- 核心模块测试/代码比 ≥ 5:1
- 修复Bug必须同步补测试
- [其他测试要求]
## 修改前 Checklist（CC 每次改代码前必答）
1. 此修改是否符合架构承诺？
2. 是否具备后向兼容？
3. 是否会导致代码过度膨胀？
4. 多次修改后是否仍可维护？
5. 三文档是否已对齐？（大/中改动必答）
6. 是否已先回测再提交？（大/中改动必答）
# ═══════════════════════════════════════
# 五、改动分级规则
# ═══════════════════════════════════════
## 大改动（七步闭环）
触发条件：新模块、架构变更、跨文件接口修改
流程：
① 提交需求
② 架构文档 + 影响分析
③ 更新测试文档
④ 三文档一致性对齐
⑤ 生成代码 + 启动测试
⑥ 解决问题
⑦ 回测/Eval + 增量报告
## 中改动
触发条件：功能迭代、逻辑调整、单模块重构
流程：影响分析 → 编码 → 回测
## 小改动
触发条件：Bug修复、参数调整、单文件修改
流程：直接改 → 更新修改历史
# ═══════════════════════════════════════
# 六、关联系统（选填）
# ═══════════════════════════════════════
## 问题单
- Jira 项目 Key：[PROJECT_KEY]
- 版本分支映射：
- main → [Android版本]
- release/xx → [Android版本]
## 上下游
- 上游依赖：[仓库/模块列表]
- 下游调用方：[谁在用我的接口]
## CI/CD
- 构建流水线：[地址]
- 代码审查：[Gerrit/GitHub PR]
# ═══════════════════════════════════════
# 七、知识输入（选填，加速冷启动）
# ═══════════════════════════════════════
## 高频问题模式
- 模式1：[场景] → [常见根因] → [标准修复路径]
- 模式2：[场景] → [常见根因] → [标准修复路径]
## 历史教训
- 教训1：曾因[xxx]导致[yyy]，以后必须[zzz]
- 教训2：[同上格式]
## 关键人
- 模块A owner：[姓名]
- 模块B owner：[姓名]
# ═══════════════════════════════════════
# 八、进化配置（选填）
# ═══════════════════════════════════════
## 自动修复规则
- 允许自动修复：是/否
- 置信度阈值：70%
- 最大修改量：单次 ≤ 50行，≤ 3个文件
- 允许修复的问题类型：Crash / 编译错误 / [其他]
- 禁止自动修复：架构变更 / 安全相关 / 新功能
## 进化评价指标
- 定位准确率目标：第1月40% → 第3月70%
- 交互效率目标：≤ 3轮
- 每周新增问题模式：≥ 3条
- 每周进化回溯：周一自动执行
## ALWAYS
- 文档先行
- 接口变更先输出影响分析
- 多方案融合，不让AI凭空设计
- 给AI系统级方向
- 合入前跑回测
## NEVER
- 跳过三文档一致性检查
- 无回测的大中改动合入
- 追求局部最优忽视全局
- Vibe Coding（闲聊式开发）
- 文档只给人看不给AI读
D.3 实战案例：HyperLauncher 桌面系统
以下为 HyperLauncher 项目实际使用的 CLAUDE.md（精简版）：
# 一、项目身份
- 项目名称：hyper-launcher / HyperOS桌面系统
- 所属层级：应用层 + 框架层
- 一句话职责：桌面管理、手势交互、最近任务、负一屏
- 代码仓库：git@gerrit:platform/packages/apps/HyperLauncher.git
- 主语言：Rust + Flutter（flutter_rust_bridge）
- 目标平台：HyperOS (Android 14/15)
# 二、代码结构
- src/launcher/ → 桌面核心逻辑（文件夹/图标/模式/MAML）
- src/recents/ → 最近任务+全面屏手势（29文件）
- src/personal_assistant/ → 负一屏
- src/api/ → 对外接口（65个文件）
- crates/ → 独立Rust模块
## 核心文件
- src/recents/base_recents_impl.rs (152K行) → 任何修改按大改动
- src/api/ → 接口变更必走七步闭环
## 构建命令
- 编译：bash build.sh --release
- OS3：bash build.sh --release --os-version=os3
- Poco：bash build.sh --release --flavor=pocoHome
# 三、架构约束
- Rust层处理业务逻辑，Flutter层只做UI渲染
- 跨语言通信全部走flutter_rust_bridge，禁止JNI直调
- 多版本(OS3/OS4)差异用feature flag，不用if-else
- engine_platform为框架接口层，禁止在此写业务逻辑
# 四、编码规则
- Rust命名：snake_case
- Flutter命名：camelCase
- 文件≤2000行，超过必须拆分
- 新增crate必须有README说明用途
- unsafe代码必须有安全性注释
# 五、改动分级
- base_recents_impl.rs 任何修改 → 大改动
- api/ 目录 → 大改动
- 单个crate内部修改 → 中改动
- 配置/参数调整 → 小改动
# 六、关联系统
- Jira Key：LAUNCHER
- main → OS4, release/os3 → OS3
# 七、已知问题模式
- 手势冲突：recents手势与负一屏手势在边缘区域冲突 → 检查gesture优先级
- 动画卡顿：任务数>20时帧率下降 → 检查animateFrame的缓存策略
- FRB类型错误：flutter_rust_bridge升级后类型不匹配 → 重新生成binding
# 八、进化配置
- 允许自动修复：是（仅Crash和编译错误）
- 置信度阈值：75%（Rust代码要求更高）
- 最大修改：30行/2文件
D.4 快速开启新项目的步骤
Step 1：创建配置目录
mkdir -p your-project/.claude
Step 2：复制模板
复制 D.2 模板到 your-project/.claude/CLAUDE.md
Step 3：填写信息
至少填完前5项必填内容（10-15分钟）
Step 4：启动 CC
cd your-project && claude
Step 5：验证 CC 理解了你的项目
你：总结一下你对这个项目的理解
（确认CC输出与你的预期一致）
Step 6：开始知识冷启动
你：分析代码结构，画出模块依赖图
💡 核心原则：花15分钟写好 CLAUDE.md = 节省未来几百小时的重复解释。CC 读一次就记住，你不需要每次对话都重新说明项目背景。