别再让 AI 在老项目里乱改了：推荐一个专门驯服遗留代码的 Skill
如果你接手过老项目，大概率都经历过这种场景：
- 项目能跑，但没人说得清它为什么这么写
- 改一个接口，牵出三层 service、两套返回结构、四个历史兼容分支
- AI 看起来很聪明，但一落到遗留代码上，改法经常“逻辑正确，项目里不对”
真正难的，从来不是“把功能写出来”，而是：
在不破坏现有约定的前提下，把功能改对。
它是什么
Legacy Rule Miner 是一个专门面向老项目、遗留后端项目的 Skill。
它做的不是直接帮你写代码，而是先帮你做一件更关键的事：
把项目里那些没人整理、但实际每天都在约束改动的“隐性规则”挖出来。
比如：
- Controller、Service、DAO 实际应该怎么分层
- 返回结构到底是统一包一层，还是不同接口走不同 envelope
- 哪些目录是给前端用的，哪些是给第三方开放平台用的
- 项目到底习惯用哪套 ORM、异常处理、日志方式、事务写法
- 哪些历史坑不能碰，哪些 workaround 看着丑但千万不能删
最后它会生成一份 AI 可直接消费的规则文件，让 Copilot、Cursor、Claude、Trae 这类工具在改代码前，先理解这个项目的“生存法则”。
它解决的不是“会不会写”，而是“会不会按这个项目的方式写”
很多团队对 AI 的真实顾虑，其实不是功能写不出来，而是下面这些问题：
1. AI 喜欢自作主张“优化”老项目
老项目明明全是字段注入，它给你改成构造函数注入。
项目还在用回调，它给你一把梭改成 async/await。
历史接口明明是 {code, msg, data}，它顺手给你换成 REST 风格原生返回。
这些改法放在新项目里也许没问题，但在老系统里，风险极高。
Legacy Rule Miner 的核心价值，就是先把项目当前的真实模式总结出来，再约束 AI 按这个模式办事。
2. 老项目里最值钱的信息，往往不在文档里
真正影响改动成功率的，通常不是 README，而是这些东西：
- 某个模块其实不能轻易重构
- 某几个字段是跨表冗余同步的
- 某些 API 虽然都叫用户接口，但一个给前端，一个给第三方
- 某段代码看着重复，其实是历史兼容逻辑
这个 Skill 的思路很务实：
先扫描代码，再结合结构、命名、注释、路由、鉴权、中间件、响应格式，把这些隐含规则尽量还原出来。
3. 你不需要再手写一份“AI 使用说明书”
很多人已经意识到，AI 在复杂项目里需要规则文件。
问题是，手写规则文件太累，而且很容易写成空话：
- “遵循现有风格”
- “不要破坏兼容性”
- “保持分层清晰”
这类话对 AI 几乎没有约束力。
Legacy Rule Miner 不是写口号，它会尽量输出具体规则，比如：
- 新增接口应该放在哪个目录
- 哪类 Controller 服务哪个受众
- Service 是否允许直接调 Repository 以外的组件
- 错误码、日志、事务、常量应该参考哪些现有文件
- 哪些文件是迁移文件、编译产物，应该排除在风格分析之外
它适合哪些项目
如果你的项目符合下面任意一种情况，这个 Skill 基本都能派上用场：
- 接手别人留下的老后端项目
- 项目代码量不小，但缺少系统文档
- 想让 AI 帮忙改代码，但又怕它“聪明反被聪明误”
- 团队里有多种历史写法，希望先抽取主流约定
- 想给 Copilot / Cursor / Claude / Trae 一份真正有约束力的规则上下文
目前支持这些常见后端栈：
- Java：Spring Boot、SSM、Spring Cloud
- PHP：ThinkPHP、Laravel、Yii
- Python：Django、Flask、FastAPI、Tornado
- Node.js：Express、Koa、Egg.js、NestJS
- Go：Gin、Beego、Echo、net/http
- .NET：.NET Core、.NET 5+
它最让我觉得对路的一点：不是让 AI 重写世界，而是让 AI 学会尊重现状
这个 Skill 的理念我很认同：
Forward-compatible > Rewrite
翻成大白话就是：
优先和现有项目兼容，而不是把项目改造成 AI 心目中的“更优雅版本”。
这对老项目特别重要。
因为很多时候，遗留系统最大的问题不是“不够先进”，而是“牵一发而动全身”。
你真正需要的，不是一个爱重构的 AI，而是一个知道边界、知道禁区、知道该模仿谁的 AI。
它会产出什么
Skill 会根据 IDE 自动把规则文件输出到对应目录，例如：
- Cursor:
.cursor/rules/ - Trae:
.trae/rules/ - GitHub Copilot:
.github/instructions/ - Claude Code:
.claude/rules/ - 其他环境：
.ruleminer/
主文件通常是：
legacy-rules.md
如果某些模块需要单独约束，还会继续生成类似：
legacy-rules-payment.md
legacy-rules-auth.md
而且它不是一次性生成完就完事。
如果规则文件已经存在，它会尽量做增量更新，并保留你手动维护的自定义规则区域。
怎么安装
最简单的方式：
npx skills add xiwen-haochi/legacy-rule-miner
安装完成后，在你的 AI IDE 里打开老项目，直接发一句类似的话：
分析这个老项目，生成 项目rule
这个 ThinkPHP 5.1 的电商后台项目太难维护了，500多个PHP文件，很多方法都上千行。我需要给它生成一套规则文件，这样用 Cursor 改代码时能保持和现有代码风格一致。只分析 application/api/ 这个模块就行
它就会开始做结构扫描、分层分析、规则提取，再根据不确定项和你交互确认。
一个很实用的使用场景
假设你接手的是一个典型电商后台：
- Spring Boot 2.x
- MyBatis
- 一堆历史接口
- 命名混乱
- 部分模块还有祖传 workaround
这时候你最怕的不是 AI 不会写，而是它：
- 乱改返回结构
- 随便升级依赖
- 引入项目从没用过的新写法
- 把 admin 接口和 open API 的模式混在一起
有了这类规则文件后，AI 的行为会更像“先学习这个项目，再动手”，而不是“直接按通用最佳实践输出”。
对遗留项目来说，这个差别非常大。
为什么我觉得它值得推荐
我推荐它，不是因为它“功能很多”，而是因为它抓住了老项目协作里最痛的点：
AI 缺的不是编码能力，缺的是项目上下文。
而这个 Skill，正是在系统化补这个上下文。
它不是炫技型工具，而是偏工程化、偏落地、偏结果导向的工具。
如果你平时就会让 AI 参与老项目维护，那它很适合作为第一步：
先把规则挖出来，再让 AI 进场改代码。
这样成功率会高很多，返工会少很多，团队对 AI 的信任度也会高很多。
结尾
如果你也有下面这种感受：
- AI 写新项目很快
- 但一进老项目就容易跑偏
- 团队不是不想用 AI，而是不敢让它随便改
那我建议你试试 Legacy Rule Miner。
它不承诺神奇，它做的是更有价值的事：
让 AI 在遗留代码里先学规矩，再干活。
仓库地址：
https://github.com/xiwen-haochi/legacy-rule-miner
Trae 安装失败时的手动安装方法
如果你在 Trae 中通过自动安装方式失败，可以使用手动方式安装。
- 先 clone 仓库
git clone https://github.com/xiwen-haochi/legacy-rule-miner.git
- 将它压缩为 zip
zip -r legacy-rule-miner.zip legacy-rule-miner
-
打开 Trae 的 Skill 安装入口，选择导入 zip
-
选择刚刚生成的
legacy-rule-miner.zip完成安装
