继承遗留项目风格 是做什么的？
防止 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 → 多数派获胜，少数派归入 DONTs
- 强信号 → 进行“烧烤”：接近对半平分，或核心维度上存在语义分歧
- 小项目例外：源文件 ≲50，“3 对 2”不算多数派 → 进行烧烤
4. 逐一解决冲突（烧烤协议）
对于每个强信号冲突，仅提出一个问题，附带四个选项：
证据：
pathA使用风格 X，pathB使用风格 Y 警告：风险：混合两者会破坏项目风格 选择：1遵循 X2遵循 Y3这是演进，更新规则4我有一个新规则
暂停直到用户回答，然后处理下一个冲突。绝不同时提出多个问题。
5. 生成 .ai-style-rules.md，包含三个必选部分：
- [黄金文件] — 实际示例文件路径，并标注它们演示了什么
- [命名与状态控制规则] — 具体、可检查的约定
- [DONTs] — 不得传播的反模式
6. 安装持久钩子
通过 AskUserQuestion 询问用户执行强度：
| 选项 | 机制 |
|---|---|
| 1 软钩子（推荐） | 将 @.ai-style-rules.md 引用写入项目 CLAUDE.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 上下文加载时，每个代码编写任务必须在推理链中以一条合规声明开头，指明正在遵循的示例和正在避免的 DONTs。
工作原理
此技能通过 .ai-style-rules.md 的存在自动检测是首次运行还是增量运行：
- 首次运行（分支 A） — 衡量项目规模，沿四个元架构维度（文件解剖、状态与控制流、基础设施、错误处理）扫描代码库，应用信号阈值降噪抑制弱冲突，逐一通过烧烤协议解决强信号冲突，生成包含黄金文件/命名规则/DONTs 的
.ai-style-rules.md，并提供可选的执行钩子。 - 增量运行（分支 B） — 读取现有规则，检查最近的 Git 差异以发现新的或冲突的模式，对发现的任何冲突运行相同的逐一烧烤协议，并在不覆盖现有规则的情况下追加演进日志。
- 每轮执行强制 — 当通过
CLAUDE.md挂钩后，每个代码编写任务都以合规声明开头，指明所遵循的示例和避免的 DONTs。
输出规范
- 项目根目录下的
.ai-style-rules.md（头部包含提交指纹和规模层级） - 可选的
CLAUDE.md，包含@.ai-style-rules.md引用 - 演进日志以
### [YYYY-MM-DD] 风格演进日志条目追加
反模式
- 失败：不要跳过规模测量步骤——对 30 个文件的项目进行采样会使其“饥饿”；对 5,000 个文件的仓库进行完整扫描会爆炸
- 失败：不要同时提出多个冲突问题——烧烤必须严格逐一进行
- 失败：不要在增量模式下覆盖旧规则——始终追加演进日志
- 失败：不要默认选择“硬钩子”而不询问——执行强度应由用户决定
- 失败：不要评判语法或技术栈质量——此技能仅对齐元架构
- 失败：不要从示例文件复制错误——复用结构，标记缺陷
最佳实践
- 在扫描前用一行说明宣布检测到的模式（首次与增量）和规模层级
- 对于大型项目，先读取
--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 强制 DONTs
- 用户：“确保所有新代码与项目规则保持一致。”
- 操作：安装软钩子 →
.ai-style-rules.md每次会话自动加载 → 每个代码编写任务以合规声明开头，复用示例模式并避免 DONTs。