继承遗留项目风格 是做什么的？
防止 AI 在遗留项目中产生代码风格漂移。通过扫描代码库中沿四个元架构维度的隐式约定，逐个解决与用户的冲突，并将共识固化为可执行的 .ai-style-rules.md 文件。完全语言和框架无关。
何时激活
- 用户输入
/inherit-legacy-style - 用户提及需要将 AI 上手到一个手写的遗留项目
- 用户担心 AI 生成的代码会从现有项目约定中“漂移”
- 用户希望提取并固化项目中的隐式编码规则
何时使用
当你需要保留遗留项目风格并防止 AI 引起的风格漂移时使用此技能。参见上方何时激活了解触发条件。
前置条件
- Git（推荐；非 Git 项目会回退到文件时间戳用于增量模式）
- 项目根目录的读写权限（生成
.ai-style-rules.md并可选的CLAUDE.md）
工作流程
第 0 步 — 自动检测模式
静默检查项目根目录是否存在 .ai-style-rules.md：
| 文件是否存在？ | 模式 |
|---|---|
| 否 | 分支 A — 首次全量扫描 |
| 是 | 分支 B — 增量嗅探 |
用一行消息宣布所选模式，然后继续——永远不要让用户选择。
分支 A — 首次全量扫描
1. 度量规模，选择扫描层级
git ls-files | grep -cE '\.(js|ts|jsx|tsx|vue|py|go|rs|java|kt|rb|php|cs|swift|c|cpp|h)$'
| 层级 | 源文件数 | 策略 |
|---|---|---|
| 小 | ≲ 50 | 完整精读每个源文件 |
| 中 | 50–500 | 基础设施层全量读取；业务层每个维度采样 2–3 个文件 |
| 大 | ≳ 500 | 严格采样 + 预算上限；先读取 --stat 摘要，再定向读取 |
2. 沿四个维度扫描
- 文件结构 — 文件内声明顺序（导入 → 类型 → 主逻辑 → 辅助函数 → 导出）
- 状态与控制流 — 异步状态、分页、标志位的命名约定
- 基础设施 — 横切工具类的存放位置（拦截器、格式化器、中间件）
- 错误处理 — try/catch 与全局拦截器与 Result 返回的偏好；空值检查习惯
3. 应用信号阈值降噪
在打扰用户之前，评估信号强度：
- 弱信号 → 自动抑制：少数派 <5% 且计数 <10 → 多数派胜出，少数派归入禁止项
- 强信号 → 裁决：接近平分，或核心维度上的语义分歧
- 小项目例外：源文件 ≲50，“3 对 2” 不是多数派 → 因此需要裁决
4. 逐个解决冲突（烧烤协议）
对每个强信号冲突，仅提出一个问题，并提供四个选项：
证据：
pathA使用风格 X，pathB使用风格 Y 警告：风险：混用两者会破坏项目风格 选择：1遵循 X2遵循 Y3这是演进，更新规则4我有一个新规则
暂停直到用户回答，然后进入下一个冲突。绝不堆叠问题。
5. 生成 .ai-style-rules.md，必须包含三个章节：
- [黄金文件] — 真实范本路径，标注它们示范了哪些内容
- [命名与状态控制规则] — 具体、可检查的约定
- [禁止项] — 不得扩散的反模式
6. 安装持久化钩子
询问用户执行力度（使用 AskUserQuestion）：
| 选项 | 机制 |
|---|---|
| 1 软钩子（推荐） | 在项目的 CLAUDE.md 中写入 @.ai-style-rules.md 引用 |
| 2 硬钩子 | 软钩子 + settings.json 中的 `PreToolUse[Write |
| 3 无钩子 | 保留规则文件，用户手动参考 |
分支 B — 增量嗅探
- 读取现有的
.ai-style-rules.md；如果包含提交指纹，执行git diff <last_hash> HEAD --stat定位增量 - 读取近期的 Git 变更（
git log -3 --stat→ 按需检查可疑文件） - 对于过大的差异（数百个文件）：仅读取
--stat摘要 + 采样最大的变更 - 将新代码与记录的规则进行比较 → 发现的冲突走烧烤协议
- 在
.ai-style-rules.md末尾追加演进日志（绝不覆盖旧规则）
轮次间执行
当 .ai-style-rules.md 在上下文中（通过 CLAUDE.md 加载）时，每个写代码任务都必须在推理链中以合规声明开始，指明正在遵循的范本以及正在避免的禁止项。
工作原理
此技能通过检查 .ai-style-rules.md 是否存在，自动检测是首次运行还是增量运行：
- 首次（分支 A） — 度量项目规模，沿四个元架构维度（文件结构、状态与控制流、基础设施、错误处理）扫描代码库，应用信号阈值降噪抑制弱冲突，逐个解决强信号冲突，生成包含黄金文件/命名规则/禁止项的
.ai-style-rules.md，并提供可选的执行钩子。 - 增量（分支 B） — 读取现有规则，检查近期的 Git 差异以发现新的冲突模式，对发现的任何冲突运行相同的逐个烧烤协议，并在不覆盖现有规则的情况下追加演进日志。
- 轮次间执行 — 当通过
CLAUDE.md挂钩时，每个写代码任务都以合规声明开始，指明遵循的范本和避免的禁止项。
输出规范
- 项目根目录下的
.ai-style-rules.md（包含提交指纹和规模层级标题） - 可选的
CLAUDE.md，包含@.ai-style-rules.md引用 - 演进日志作为
### [YYYY-MM-DD] 风格演进日志条目追加
反模式
- 失败：不要跳过规模度量步骤——对 30 个文件的项目进行采样会“饿死”它；对 5000 个文件的仓库全量扫描则会爆炸
- 失败：不要一次性堆叠多个冲突问题——烧烤协议严格逐条进行
- 失败：不要在增量模式下覆盖旧规则——始终追加演进日志
- 失败：不要默认使用“硬钩子”而不经询问——执行力度由用户决定
- 失败：不要评判语法或技术栈质量——此技能仅对齐元架构
- 失败：不要从范本文件中复制错误——复用结构，标记缺陷
最佳实践
- 在扫描前一行宣布检测到的模式（首次 vs 增量）和规模层级
- 对于大型项目，先读取
--stat摘要，再定向读取Read可疑文件 - 让信号阈值处理噪声——843 对 8 的命名分歧应自动解决，无需用户干预
- 当对信号强度不确定时，倾向于询问
CLAUDE.md软钩子（@.ai-style-rules.md）通常足够；只有用户希望机械强制执行时才使用硬钩子
相关技能
init— 使用代码库文档初始化新的CLAUDE.mdcode-review— 审查差异以确保正确性和风格问题simplify— 审查代码以发现复用和简化机会
示例
-
首次上手
- 用户：“帮我把 AI 上手到这个旧代码库，不改它的风格。”
- 动作：运行分支 A 全量扫描 → 度量规模 → 沿四个维度扫描 → 裁决冲突 → 生成
.ai-style-rules.md→ 提供钩子力度（软/硬/无）。
-
团队变更后的增量更新
- 用户：“我们新增了一个模块；保持现有风格规则不变。”
- 动作：运行分支 B 增量嗅探 → 比较 Git 增量与记录规则 → 裁决任何新冲突 → 追加演进日志，不覆盖。
-
通过 CLAUDE.md 执行禁止项
- 用户：“确保所有新代码与项目规则保持一致。”
- 动作：安装软钩子 →
.ai-style-rules.md每会话自动加载 → 每个写代码任务以合规声明开始，复用范本模式并避免禁止项。