在这个行当混了几年，你是不是也遇到过这种绝望？

面对动辄几十万行的老祖宗代码，想加个功能比登天还难；公司自研的闭源框架，没有文档，全靠口口相传；每次改代码都像拆弹，生怕牵一发而动全身。

今天，我不想讲那些虚头巴脑的 AI 概念，只想跟你掏心窝子聊聊：在全是“屎山”代码的老系统里，我们怎么把 AI 这个“外星人”变成最懂业务的“老架构师”？

---

01. 现实的巴别塔：为什么 AI 总是听不懂人话？

最近大家都在聊 AICoding，仿佛代码从此自动生成，程序员可以喝茶养老。

但只要你在大型企业、通信、金融行业，你就知道这有多痛。

在推广AiCoding的过程中，我被问得最多、也最扎心的三个问题是：

1. 我们用的是公司自己搞的闭源框架，AI 根本不认识，它怎么写代码？
2. 系统跑了 20 年，全是硬代码，没有资产沉淀，AI 能看懂吗？
3. 新增功能还好说，存量功能改坏了怎么办？它改得明白这错综复杂的依赖吗？

是的，这三个问题就像三座大山，压得所有想搞智能化的团队喘不过气。

特别是我们通信行业的 BOSS 系统，简直是这三个问题的“满分彩蛋”。

---

以下解决方案在IDEA+通义灵码（因为公司开通了企业账号不用考虑 Token 的问题）上验证通过，基于公司保密原则部分代码会进行打码或者省略，尽量不影响大家理解。我们重要的是要理解方法。

---

02. 破局第一步：让 AI 认识你的“私有语言”

很多公司有自己的研发部门，研发部都喜欢自己捣鼓一些框架，然后在公司内部推广。这样有几个好处，定制程度比较高，公司有自己的护城河。但是缺点也比较明显，往往到后期缺少维护，文档缺失。

随着 AI 大模型时代到来，大模型对开源的框架天生支持比较好，而闭源框架呢，它根本不认识。

只有一个办法，让他认识。

结合你手上有的所有资料加上你对闭源框架的理解整理成一个知识文档。这是必不可少的一个步骤，而且你整理得越详细，AI 就能更加理解。

以下是我整理的闭源框架规则大纲（具体细节已删除）。灵码插件可以放在rules 目录下（ https://help.aliyun.com/zh/lingma/user-guide/rules ），所有请求中均会生效。

common_rule.md

---
trigger: always_on
---
### 1. 项目结构与分层规范
#### 1.1 技术栈
#### 1.2 目录结构规范
#### 1.3 包命名规范
#### 1.4 新增模块命令
#### 1.5 分层命名规范

### 2. 前端到后端的调用流程
#### 2.1 分层职责说明
#### 2.2 Page 页面开发规范

### 3. 数据库交互规则
#### 3.1 微服务中心对应数据库用户规范
#### 3.2 数据库路由规范
#### 3.3 数据库分库/分表路由规范
#### 3.4 MyBatis-Plus使用规范
#### 3.5 严格禁止的行为

### 4. 事务管理
#### 4.1 事务注解使用

### 5. 与其他中心的调用规则
#### 5.1 跨中心服务调用

### 6. 异常处理
#### 6.1 业务异常
#### 6.2 系统异常

### 7. 日志规范
#### 7.1 日志记录要求
#### 7.2 禁止的行为

### 8. 第三方组件使用规则

### 9. 安全规范

### 10. 代码输出核心要求
#### 10.1 功能实现完整性
#### 10.2 代码质量标准

这样模型就能能更好的理解你的代码。

---

03.破局第二步：没有文档？让 AI 自己“画”地图

没有系统的资产沉淀，或者文档分布零散，同时需求不停，代码依赖频繁变更，文档变化跟不上代码变更。这简直是 IT 行业的通病，毕竟没有几个程序员是喜欢写文档。

对大模型稍有了解的想到的往往是，搭建一个 RAG，甚至是对模型进行微调。这往往又涉及到更多的问题，如何准备优质的基础文档。这又陷入了一个新的死循环中。

但是但我们往往忽略了一点，代码就是最好的文档不是吗？

如果我们能让 AI 自动分析代码，直接输出文档这不是更好吗？

是的，这是可行的，但是我们不能一股脑丢给 AI，我们可以让他从一个菜单，一个功能，一个接口开始。让他端到端的梳理输出对应的资产。甚至可以把这个步骤整理成一个 SKILL，这样即使代码变更文档也能马上更新。

我设计了一个 Skill（技能），叫做 gen_func_knowledge。它的作用是：给它一个功能编码，它给你画出整个调用链路的“藏宝图”。

gen_func_knowledge

### 1. 业务逻辑分析器
#### 1.1 概述
#### 1.2 使用方法
### 2. 输入与输出
#### 2.1 Input (输入参数)
| 参数              | 类型      | 必填  | 说明                      |
| --------------- | ------- | --- | ----------------------- |
| func_id        | string  | 否   | 菜单标识                    |
| func_name        | string  | 否   | 菜单名称                    |
#### 2.2 Output (输出产物)
knowledge/{FUNC_NAME}
├── 业务总览.md （必须）
├── 前台页面逻辑内容.md（必须）
├── 后台服务流程.md（必须）
### 3. 执行流程
#### 3.1 步骤一：功能解析
#### 3.2 步骤二：前端分析
#### 3.3 步骤三：后端服务分析
#### 3.4 步骤四：知识文档生成
### 4. 文档结构规范
#### 4.1 业务总览
#### 4.2 前台页面逻辑内容
#### 4.3 后台服务流程
#### 4.4 后台订单流程
### 5. 关键分析技巧
#### 5.1 快速定位文件
#### 5.2 识别隐藏逻辑
#### 5.3 追踪方法调用链
### 6. 输出与维护规范
#### 6.1 文档命名与路径
#### 6.2 内容详细程度要求
#### 6.3 注意事项
### 7. 更新日志

我甚至配置了一个 mcp-server-oracle 用了连接数据。这样在分析时 AI 也能够连接数据获取相应的数据库数据了。

以前新人看一个功能要问三天，现在 AI 能端到端地告诉你：

1. 前端页面在哪里；

2. 点击按钮后调了哪个 Controller；

3. 最终数据存到了哪张分库分表里。

这相当于给老系统装了一个“上帝视角”的导航仪。

---

04. 破局第三步：存量改造，从“改代码”到“改设计”

其实解决前面 2 个问题后，最后这个文件基本可以迎刃而解了。

现在的 AI 已经具备了双重身份：

1. 它懂你的框架（通过 Rules）；
2. 它懂你的业务（通过生成的知识图谱）。

这时候，你就可以把原本恐怖的“改代码”流程，升级为**“AI 辅助设计”**流程。

我在 IDEA + 通义灵码上跑通了一套工作流：

1. 需求分析阶段：使用 AI 生成概要设计文档（gen-design）；
2. 编码阶段：AI 根据设计文档生成代码（gen-code）；
3. 测试阶段：AI 自动生成单元测试和测试用例（gen-test-case）。

**重点在于“人工确认”：**每一步，我都会让 AI 把它的思考过程（Thought）展示出来。比如：“我要修改 A 表，因为 B 逻辑依赖它，同时要注意 C 的缓存失效”。

只要 AI 的思考逻辑是对的，生成的代码大概率就是安全的。 这样，我们既利用了 AI 的效率，又保留了人类的兜底。

---

05. 写在最后

很多兄弟觉得，在老系统里搞 AI 是天方夜谭。

但我想说，技术债是人欠的，AI 是来帮我们“还债”的，而不是来背锅的。

通过 Rules（定规矩） + Skills（做导航） 的组合拳，我们完全可以让AI成为那个最懂你系统的人。

哪怕你是 20 年的老系统，哪怕你是闭源的自研框架，只要方法对了，AI 就能成为你重构路上最锋利的手术刀。

---

关注我，获取以上完整的 SKILL。