老项目是最容易把 AI 用“翻车”的场景之一。
不是因为 AI 完全看不懂老代码，而是因为老项目里往往藏着太多没有显式写出来的东西：
- 历史兼容
- 临时补丁
- 团队约定
- 已知但未重构的坏味道
- 数据和接口边界
如果一上来就让 AI 直接改代码，它很可能会把“看起来不合理”的地方顺手修掉，而那些地方可能恰恰是系统现在还能稳定工作的原因。
所以在老项目里，我反而更倾向于先走 Skill。
为什么老项目里“直接改”特别危险
因为老项目的问题，从来不只是代码本身。
它更常见的是：
- 模块职责混在一起
- 某些写法是历史妥协
- 某些接口行为是为了兼容旧数据
- 某些逻辑看起来奇怪，但上线后没人敢动
如果没有先建立上下文，AI 很容易做出技术上看似正确、业务上却很危险的修改。
Skill 在老项目里最重要的作用是什么
我觉得不是“让 AI 更聪明”，而是先把它的工作方式卡住。
我更希望它先做这些事：
- 先读结构
- 先讲模块职责
- 先列影响范围
- 先列风险点
- 先给最小验证方式
这本质上是在把“理解老项目”变成一个先于“改动老项目”的固定阶段。
哪些要求最值得先写进老项目 Skill
如果让我挑最关键的几条，会是这些：
- 不要无关重构
- 不要直接删旧
技术解析与应用)
