关键在于为GitHub Copilot提供结构化上下文地图：第一步生成项目骨架文档，第二步注入语言结构认知，第三步构建依赖快照并可视化调用路径，第四步用PROJECT_RULES.md注入不可违逆的业务与技术约束。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
让GitHub Copilot快速理解陈旧项目的架构，关键不是喂它更多代码，而是先给它一张可读的“地图”——没有结构化上下文，AI面对COBOL或Java老项目时，会把业务逻辑、技术债、历史补丁全当成平等token处理，结果就是解释失焦、重构越改越错。
第一步：用Copilot Chat生成项目骨架文档
打开VS Code → 在项目根目录右键 → 选择“Open in GitHub Codespaces”（若本地无COBOL环境）或确保已安装GnuCOBOL；【必须在项目根目录下操作，否则Copilot无法感知文件关联】
按下 Ctrl+I 唤出Copilot Chat面板，输入：
/explain this project structure using only the files in the current directory. List each file, its likely role (e.g., entry point, data layer), and any obvious inter-file dependencies.
等待响应后，立刻检查它是否识别出主程序入口（如main.cob或app.js）和数据层文件（如data.cob或db-access.java）。如果Copilot把config.xml标为“核心业务逻辑”，说明当前目录结构混乱，需先手动整理——删掉临时build目录、归档旧备份文件夹，再重试。
第二步：强制注入语言结构认知
对COBOL项目，直接选中IDENTIFICATION DIVISION段落 → 按Ctrl+I → 输入：“按COBOL四分部结构，标注这段属于哪一部分，并说明该部分在编译和运行时的实际作用。”
对Java遗留系统，打开一个包含大量static块和synchronized方法的类 → 输入：“这个类违反了哪些现代Java设计原则？请逐条指出，并给出最轻量的重构方向（不改变行为）。”
这一步不可跳过。Copilot在缺乏显式结构提示时，会默认用Python/JS思维解析COBOL的DATA DIVISION，导致变量作用域误判。你提供的结构锚点，就是它建立语义坐标的基准线。
第三步：构建可执行的依赖快照
① 在终端运行：copilot scan --project-path . --ruleset legacy-arch-v3 --output deps.json
② 将生成的deps.json拖入Copilot Chat窗口
③ 输入：“基于此依赖图，画出三个最高频调用路径，用Mermaid语法输出，每条路径标注触发场景（如‘开户流程’‘日终批处理’）”
注意：如果命令报错“command not found”，说明未安装GitHub Copilot CLI。此时改用VS Code内建能力——打开任意一个被多处调用的函数，在其定义上方插入注释：// @copilot-dependency-snapshot: this function is called by [moduleA], [moduleB], [batch-job-C]，保存后重新唤出Chat并输入/explain。
生成的Mermaid图不要直接用于汇报，而是复制进VS Code新标签页，用预览插件实时查看。你会发现AI常把日志工具类误标为“核心服务”，这时手动在图中删掉log4j相关节点，再对剩余路径提问：“如果砍掉路径2，哪些业务功能会立即中断？”
第四步：注入项目生存法则
新建一个名为PROJECT_RULES.md的文件，写入三类真实约束：
• 禁止改动：ACCOUNT_BALANCE_CALCULATION表结构（DBA锁定）
• 必须保留：所有以legacy_开头的函数名（下游系统硬编码调用）
• 特殊逻辑：金额字段一律按分存储，但对外展示需除以100
保存后，在Copilot Chat中上传该文件 → 输入：“请将以上规则转化为JSON Schema，字段名保持原文，类型用string/number/boolean，加required数组。”
这一步产出的JSON会被Copilot自动缓存为上下文。后续所有重构建议、测试生成、注释补全，都会优先校验是否违反这些铁律。没有它，AI可能把legacy_withdraw()重命名为processWithdrawal()，导致下游支付网关调用失败。
