历史项目的问题通常不是“不能改”，而是没人真正说得清它现在是什么样。要让 AI 能参与这类项目，第一步往往不是实现新功能，而是先把现有系统重新理解、重新表达出来。
适用场景老旧项目、文档缺失
适合代码能跑，但系统结构、业务规则和历史决策已经不透明的项目。
核心目标从代码反推 Spec
先把现有系统讲清楚，再逐步建立 AI 能读懂和执行的协作材料。
推进原则先理解，再改造
越复杂的历史系统，越不能跳过理解阶段直接让 AI 动手改。
适用场景
历史项目通常面临一个共同问题：代码还在，但系统知识不在。越是这种场景，越需要先补理解层，而不是直接要求 AI 输出实现。
- 项目年限长，缺少系统化文档。
- 关键逻辑依赖老成员经验或口口相传。
- 系统结构复杂，不适合直接大范围改动。
核心方法
逆向工程的核心不是“看懂所有代码”，而是把最关键的系统结构、核心流程和业务约束重新抽出来，形成新的 Spec 表达。
- 先确定最重要的模块和主流程。
- 从代码、接口和数据库结构中提取关键信息。
- 把理解结果重新沉淀成结构化文档。
实施步骤
1. 分析现有代码
先识别核心模块、主要依赖关系和最关键的运行路径。
2. 提取核心逻辑
把真正影响业务行为的逻辑从杂乱实现细节里抽离出来。
3. 编写 Spec 文档
把系统现状转成结构化表达，为后续 AI 协作建立可读输入。
4. 建立 Wiki Repo
把已整理出的知识持续沉淀，避免每次都重新解释项目背景。