阶段 6 · 沉淀与复用
把个体经验变成组织资产——Skill 范式整合、知识沉淀、真实避坑、持续改进。
个体经验不沉淀，人走了经验也走了。本阶段把推广中积累的能力固化成可复用的 Skill 范式、把规范/避坑沉淀成 AI 自动加载的知识、把"犯错"变成"自我改进"。这是转型从"一次性项目"变成"持续进化能力"的关键。
🧰 本阶段速查 （做什么 · 产出什么 · 用什么）
- 🎯 做什么：Skill 范式沉淀 + 知识沉淀 + 自我改进循环（个体经验 → 组织资产）
- 📦 产出与汇报：阶段总结报告（整体结项 / 晋升述职）+ 团队 Skill 仓库交接
- 🔧 工具/Demo：skillhub（自托管 Skill 注册中心）/ demos/ai-test-frame（"录制 + AI 生成"范式落地）
- 👥 角色手册：开发手册（沉淀 Skill 的主力）
1. 为什么：个体 → 组织
前 5 个阶段，能力主要长在个体身上（某个开发者很会用 AI）。如果这些能力不沉淀成组织资产，人员流动会让能力流失。阶段6 的核心是把"个人会用"变成"团队资产"：Skill 复用、知识沉淀、避坑库、自我改进循环。
2. Skill 设计范式整合
13 个组在推广中沉淀了大量高质量 Skill，思路值得整合复用。好的 Skill 有共同范式：
# Skill 三件套：SKILL.md（必需）+ Reference（按需）+ Script（零上下文）
---
name: sql-query # 必须与文件夹同名
description: "查询业务库只读数据，自动走 SSH 隧道 + 租户库发现" # 单行、具体、决定是否自动调用
---
# 指令（规则 + 输入输出示例）
只允许 SELECT，禁止写操作；corp_code 必带做租户隔离...| Skill 范式 | 团队类型 | 核心思路 |
|---|---|---|
| 工具型（SQL/CRUD/数据模型） | 业务开发团队 | 封装高频开发动作为 Skill，OpenSpec 开发，断点续传 |
| 规范型（设计 Token/平台规范） | 前端团队 | 让 AI 输出符合团队设计规范（var(--primary) 而非硬编码） |
| 平台型（低代码搭建） | 低代码平台团队 | 严格触发条件 + 接口白名单（绝不猜测写操作） + 三层文档兜底 |
| 流程型（/commit 规范提交） | AI 平台团队 | AI 分析变更生成 Conventional Commits，自动提交 |
| 记忆型（claude-mem） | 定制交付团队 | 持久化记忆，跨会话复用，按项目隔离 |
| 诊断 / 分析型（只读） | 性能 / 测试分析团队 | 只读分析不改代码（性能诊断、脚本分析、慢 SQL 定位），与工具型（会改代码）有别 |
| 编排型（单 / 多 Agent） | 架构团队 | 编排其他 skill / Agent 成流水线（devflow 单 Agent 编排 OpenSpec+Superpowers；多 Agent Swarm 模式更复杂） |
写好 Skill 的关键：description 要具体（✅"查询业务库只读数据，自动走 SSH 隧道" ❌"查询数据库"）；写清"何时触发"和"何时禁止"；任务关键的 Skill 用
disable-model-invocation + 显式调用，比自动检测可靠。编排型 skill 的范例：上表的工具型 / 规范型 / 平台型 / 流程型 / 记忆型 Skill 各管一摊，还有一种「编排型」——自己不实现，只把多个 skill 串成流水线。见 devflow（
demos/claude-skills）：编排 OpenSpec + Superpowers 成 6 阶段（需求→交付），带断点续传 + 规则覆盖。多阶段、跨框架的工作流适合这种编排型。范文型 / 诊断型 / 记忆型三范例实物：上表对应行各配一个开箱可用的 skill——brand-guidelines（规范型：设计 Token / 平台规范，让 AI 输出符合团队设计规范，不硬编码颜色）/ perf-diagnosis（诊断 / 分析型：只读性能诊断、慢 SQL 定位，不改代码）/ session-memory（记忆型：跨会话持久化、按项目隔离）。复制到
.claude/skills/ 即用，作为沉淀自己团队 Skill 的模板。3. 知识沉淀：规范 + 避坑 + 自我改进
3.1 规范资产化（三条红线示例）
// 示例团队 · 三条红线（写进 .claude/rules/，AI 自动加载）
// 1. 租户隔离：所有 SQL 每表必带 corp_code
// 2. MQ/定时任务 finally 必须清理上下文，否则数据串企业
finally { ExecutionContext.setContextMap(null); }
// 3. 事务必须指定管理器
@Transactional(transactionManager = "mdlTransactionManager")3.2 真实避坑（来自生产 bug 复盘）
// ❌ 静默吞异常（占本周确认 Bug 的 15%）：catch 吞掉 + handleSuccess 在 try-catch 外
try { doBusiness(); } catch (Exception e) { log.info("出错了", e); }
XxlJobHelper.handleSuccess(); // 无论如何都"成功" → 故障静默 9 个月才被发现
// ✅ catch 必须重抛或转 Error，失败必须 handleFail
try { doBusiness(); XxlJobHelper.handleSuccess(); }
catch (Exception e) { log.error("任务失败", e); XxlJobHelper.handleFail(e.getMessage()); }惨痛案例：某 SFTP 推送任务因静默吞异常，停更 9 个月才被客户发现。教训：关键集成任务必须有外部健康检查（数据时效性监控），不能只信任务自报成功。
3.3 自我改进循环
让 Claude 犯错后自己更新 CLAUDE.md避免同类错误："刚才那个错误是因为 X，更新 CLAUDE.md 添加规则防止类似情况。"——让工具的失败自动转化为团队规范的进化。
4. 13 组案例的六大共性方法论
13 个组的实战提炼出 6 大共性方法论，是团队通用的精华：
- 规范/知识资产化（地基）：先沉淀 AI 能读的说明书，再谈提效。
- Skill 沉淀工作流：高频能力做成 Skill 共享，写清触发/禁止。
- OpenSpec+Superpowers 规范驱动：探索不是浪费，是最高效的慢。
- 录制 + AI 生成：人做一遍，AI 看会，批量复制（测试/前端/运维）。测试场景的完整展开见 《AI 自动化测试：方法论与实践》。
- 多 Agent 并行：单点提效放大为大规模重构。
- 业务知识库/RAG 调研：四方案对比验证（GraphRAG/LightRAG/Hyper-Extract/RagFlow）。
5. 沉淀复用案例：从推广到资产
13 组推广跑通后，能力沉淀是阶段 6 的落脚点。以下是推广中真实沉淀下来的几类资产（均来自实践，非举例虚构）：
- 工具型 Skill：SQL 查询、CRUD 生成等高频开发动作封装成 Skill（如本教程 sql-query / crud-gen），新人调用即用，不必重复摸索。
- 编排型 Skill：把 OpenSpec + Superpowers 串成 6 阶段流水线（devflow），"规范驱动开发"从口号变成团队默认工作流。
- 避坑资产：生产 bug 复盘沉淀成规则（如 §3.2 的"静默吞异常"写进 rules/，AI 自动加载），同类问题不再重犯。
- 录制 + AI 生成范式：测试 / 前端 / 运维"人做一遍、AI 看会、批量复制"——测试用例生成从 4-8h 降到 10-30min。
这些资产让个体的"会用"变成组织的"默认能力"——人把经验沉淀成 Skill / 规则，AI 把这些经验批量放大、跨人复用。这正是总纲"人 + AI，人是根本"的落地。
沉淀不是终点——防退化机制
沉淀下来的 Skill / CLAUDE.md / 避坑库，不是一劳永逸的资产。转型推完 6 个月后，常见的退化是：Skill 写了没人调用、CLAUDE.md 失修不再反映现状、AI 占比从高点回落、新人上手周期变长、规范执行走样。沉淀不维护，等于没沉淀。本节给一份季度健康检查清单，把"防退化"做成可追踪的动作。
为什么单独拎出来：转型的"热情期"（前 3-6 个月）大家主动用，但热情衰退后，没有治理机制的团队会快速回到老习惯。沉淀是高峰期的产物，防退化是平稳期的治理——两件事。
季度健康检查清单（5 项）
每季度由审核小组（见 阶段1 §4.2）跑一次，5 项任一亮红灯就触发干预：
| # | 检查项 | 健康信号 | 退化信号 |
|---|---|---|---|
| ① | Skill 调用频次 | 团队 Skill 仓库的 Skill 仍有稳定调用 | 多个 Skill 长期零调用（description 失效 / 已被新流程取代 / 没人记得有） |
| ② | CLAUDE.md 最后更新 | 近 1 个季度有维护，内容仍反映当前技术栈/红线 | 最后更新在半年前、技术栈已变但 CLAUDE.md 没跟上 |
| ③ | AI 占比趋势 | 度量数据（见 阶段5）稳定在目标区间 | 从高点持续回落（如从 70%+ 掉回 40%） |
| ④ | 新人上手周期 | 新人靠 Skill/规范/避坑库能在预期周期内上手 | 新人上手变慢、频繁问重复问题（说明资产没复用起来） |
| ⑤ | 规范执行 | Code Review 四问（见 阶段1 §4.2）仍被认真执行 | 人审流于形式、AI 代码盲合、防偷改测试的 deny 名单被绕过 |
退化信号 → 干预措施
| 亮红灯的项 | 干预措施 |
|---|---|
| ① Skill 调用频次降 | 复盘阻碍：description 不够具体？被新流程取代了就归档（见本页 §2 范式）？没人记得有就重宣贯一遍 |
| ② CLAUDE.md 失修 | 季度审一次：对每行问「删掉这行 AI 会犯错吗」（见 阶段2），过时的删、新增的红线补 |
| ③ AI 占比回落 | 查根因：工具连不上（见 阶段2 §3）？网络/账号额度问题？换了新成员没培训？针对性修复，不靠喊口号 |
| ④ 新人上手变慢 | 补文档：把新人常问的问题沉淀进 Skill / 避坑库（见本页 §3），让下次新人能自助 |
| ⑤ 规范执行走样 | 重训 + 关键项用 Hook 强制（CLAUDE.md 只是建议，Hook 是确定性的——见 阶段2 §3.3） |
一句心法：转型不是一次性项目，是持续治理。沉淀只是起点，防退化才是把"转型成果"变成长期能力的关键——和本页 §3.3 的"自我改进循环"是同一件事的两面：让资产持续保鲜。
6. 角色视角 + 常见坑 + 清单
Leader
把个体经验沉淀为组织资产定成机制（Skill 仓库/避坑库/周报），纳入考核。
开发者
主动把自己的高频操作做成 Skill 共享；踩坑后写进避坑库；用自我改进循环。
PM
把业务知识沉淀进 RAG；把需求模板化减少沟通损耗。
坑：①Skill 写了没人用（description 不清晰，要写清触发条件）；②规范写了不维护（定期审查修剪）；③避坑库不更新（每次复盘都补）。
📋 阶段6 落地清单（持续进化）
- 团队 Skill 仓库成型，按工具/规范/平台/流程/记忆分类，description 清晰
- 规范资产化（rules/ 三红线等），新代码强制、旧代码宽容
- 避坑库（静默吞异常/硬编码定制/配置回归等）持续更新
- 自我改进循环：AI 犯错 → 更新 CLAUDE.md/rules
- 6 大共性方法论成为团队共识，新成员照着快速上手
转型不是一次性项目，而是持续进化的能力。回到总纲：人 + AI，人是根本——工具和方法论都会迭代，但"转变思想、懂原理、拥抱 AI"始终是地基。