很多 AI 编程教程演示的项目都非常“干净”。比如新建一个 Next.js 项目然后让 ChatGPT 写登录页面再让 Codex 增加数据库这种场景当然适合展示 AI 的能力。但真实开发环境往往完全不是这样。更多时候你面对的是一个运行了 5 年的项目里面可能有没有文档 没有测试 命名混乱 历史代码没人敢动 数据库字段意义不清楚 业务逻辑散落在几十个文件甚至前一个开发已经离职你接手以后第一件事并不是写新功能。而是先弄明白这个系统到底是怎么运行的。这也是我认为 ChatGPT、Plus、Pro、Codex 真正开始体现价值的一个场景。因为相比从零生成代码理解 Legacy Code往往才是开发里最耗时间的事情之一。一、什么是 Legacy CodeLegacy Code 一般翻译成遗留代码但很多人会误以为Legacy Code 很烂的代码其实不一定。一个系统可能代码写得很好。但是作者已经离职或者没有文档或者没人敢修改它一样可能逐渐变成 Legacy System。从开发者角度我更愿意把它理解为你无法快速判断修改后会不会出问题的代码。例如你看到if(status3){updateUser()}问题来了status 3到底代表已支付 已完成 已审核 已关闭没人知道。你只能继续往下追。二、老项目最难的不是“写代码”而是建立 Mental Model开发者接手一个新项目时真正需要建立的是Mental Model也就是对系统的整体理解你需要知道请求从哪里进来↓经过哪些 Service↓修改哪些数据↓触发哪些副作用↓最终返回什么如果没有这个模型你看到的永远只是一个文件但真实系统可能是Controller ↓ Service ↓ Repository ↓ Database ↓ Event ↓ Queue ↓ Worker ↓ Notification所以我现在接手陌生项目时很少第一步就修改代码。更常做的是Map the system first.三、第一个 Codex Prompt给整个项目画地图进入陌生仓库以后可以先让 Codex先不要修改代码。 请阅读当前仓库 帮助我建立这个系统的整体架构地图。 重点找到 1. 程序入口 2. API 入口 3. 核心业务模块 4. 数据库访问层 5. 用户认证流程 6. 消息队列 7. 定时任务 8. 外部服务 9. 配置文件 10. 测试目录。 然后输出 System Overview Request Flow Core Modules External Dependencies Critical Data Flow Potential High-Risk Areas 暂时不要修改代码。这一步的目标并不是让 AI帮我总结项目而是建立System Map例如它最后可能告诉你Browser ↓ Nginx ↓ Node API ↓ OrderService ↓ PaymentService ↓ MySQL ↓ RabbitMQ ↓ Settlement Worker你瞬间就比一个文件一个文件打开效率高很多。四、第二步找到“真正的核心代码”一个老项目可能有2000 个文件但真正决定业务的核心文件可能只有2050 个所以我会继续让 Codex 做不要修改代码。 在当前项目中识别“高业务价值代码”。 标准 1. 被大量模块依赖 2. 处理核心业务 3. 涉及数据库写入 4. 涉及支付 5. 涉及权限 6. 涉及账户余额 7. 涉及订单状态 8. 修改后影响范围大。 给我列出最关键的 20 个文件。 每个文件说明 - 作用 - 谁调用它 - 它调用谁 - 修改风险 - 是否有测试保护。 按风险排序。然后你可能得到High Risk例如PaymentService OrderStateMachine UserPermission SettlementWorker BalanceRepository以及Low Risk例如Formatter UI Component Date Utils这一步特别重要。因为不是所有代码都值得投入同样的理解成本。五、Legacy 项目最应该先找“状态机”很多复杂业务系统真正难维护的地方都是状态变化例如订单Created ↓ Paid ↓ Shipping ↓ Completed但是老项目里可能写成0 1 2 3 4 5 8 10然后你会发现status 5在 A 文件代表已完成在 B 文件又有if status 5在 C 文件status ! 8这种代码极其危险。六、Prompt自动还原业务状态机可以让 Codex不要修改任何代码。 请调查订单状态字段的所有使用位置。 目标 还原完整订单状态机。 请找出 1. 所有可能状态 2. 每个状态的业务含义 3. 哪些代码会修改状态 4. 每个状态允许转换到哪些状态 5. 哪些转换可能是非法的 6. 是否存在直接更新数据库绕过业务层 7. 是否有重复状态判断 8. 是否存在 Magic Number。 最终输出 State Meaning Allowed Transitions Modified By Risk 最后用文字画出完整状态流。这个 Prompt 对订单 支付 审批 工单 物流 用户状态都很好用。七、Magic Number 是 Legacy Code 的经典问题例如if(order.status7){谁知道 7 是什么可能要翻数据库再翻接口再翻历史提交最后才找到7 Cancelled这种东西 AI 很适合帮你批量定位。八、Prompt找出所有 Magic Number扫描与业务逻辑相关的 Magic Number。 重点寻找 - 状态码 - 角色码 - 类型码 - 权限码 - 支付状态 - 订单状态 - 时间常量 - 金额阈值。 不要修改。 请输出 Value File Meaning Evidence Risk 如果同一个数字在不同位置可能有不同含义 单独标记。 最后建议哪些值应该被替换成 Enum 或常量。例如把if(role3)变成if(roleUserRole.Admin)可维护性会高很多。但注意不要第一步就全项目自动替换。先识别。再逐步改。九、老项目最大的危险没有测试现实中非常常见核心业务代码↓0 个测试这时你让 Codex帮我重构风险非常高。因为你根本不知道改完以后行为有没有变化所以重构 Legacy Code 最重要的步骤之一是Characterization Tests中文可以理解成特征测试它的目的不是判断代码应该怎么运行而是记录现在实际上怎么运行十、先写 Characterization Tests再重构比如一个非常奇怪的函数functioncalculatePrice(user,order,channel){// 300 lines...}你不知道它为什么这么写。不要直接重构。先让 AI不要修改 calculatePrice 的实现。 请分析当前函数。 目标不是判断业务设计是否合理 而是固定当前行为。 根据现有代码增加 Characterization Tests。 重点覆盖 1. 普通用户 2. VIP 用户 3. 优惠券 4. 满减 5. 特殊渠道 6. 空订单 7. 边界金额 8. 历史兼容逻辑。 这些测试的目的 确保未来重构前后 对相同输入产生相同结果。 暂时不要优化函数。这一步很重要。流程变成Unknown Legacy Behavior ↓ Characterization Tests ↓ Behavior Locked ↓ Refactor比直接重构安全得多。十一、AI 重构最容易犯的错误顺手“修正”历史行为比如旧代码if(amount100){discount10}你可能觉得100 元应该也优惠于是 AI 修改成if(amount100)从代码审美看似乎更合理。但这实际上属于业务行为变更而不是重构所以我会非常明确地告诉 CodexRefactoring Rule: Do not fix suspicious business behavior unless the task explicitly asks for it. If current behavior looks strange, report it separately. Preserve behavior during refactoring.这条很重要。因为Bug Fix和Refactor必须尽量分开。十二、推荐的 Legacy Code 重构流程我现在更倾向于Explore ↓ Map ↓ Test ↓ Refactor ↓ Compare ↓ Review而不是Read ↓ Rewrite完整一点就是1. 找到入口 2. 追踪调用链 3. 理解数据流 4. 找出业务状态 5. 找出隐藏规则 6. 写 Characterization Tests 7. 确认测试通过 8. 小范围重构 9. 再跑测试 10. Review Git Diff十三、Prompt让 Codex 追踪一个 Bug 的完整调用链这是接手旧系统非常高频的 Prompt调查以下 Bug [Bug 描述] 不要先修改代码。 请从用户操作开始追踪完整调用链 UI ↓ API ↓ Controller ↓ Service ↓ Repository ↓ Database ↓ Async Job 如果某个阶段不存在可以跳过。 请找出 1. 数据从哪里进入 2. 在哪里被转换 3. 在哪里被校验 4. 在哪里写入数据库 5. 是否触发异步任务 6. 错误最可能在哪里产生 7. 是否存在多个相似实现。 最后输出 Execution Path Most Likely Root Cause Evidence Potential Side Effects Minimal Fix 暂时不要修改。对于“用户支付成功但订单没更新”这种问题尤其有用。十四、复杂 Bug 一定要区分“症状”和“根因”例如用户反馈偶尔重复扣款你看到日志Payment API 被调用两次很多人第一反应前端按钮 disable 一下但真正原因可能是请求重试或者Webhook 重复或者消息队列重复消费或者接口没有幂等所以 AI 调试时可以要求请严格区分 Symptom 表面现象 Root Cause 真正根因 Trigger 触发条件 Amplifier 让问题更严重的因素 不要把第一个发现的问题直接认定为 Root Cause。这在复杂系统里非常有效。十五、Legacy 系统一定要检查幂等性尤其是支付 退款 积分 余额 订单 消息队列 Webhook非常容易出现第一次请求成功但客户端没收到。于是自动重试服务器再次处理。然后重复扣款 重复发积分 重复发货所以可以直接检查以下业务流程是否具备幂等性 [业务流程] 重点检查 - HTTP retry - message retry - webhook retry - duplicate submission - concurrent request - worker retry 找出所有可能导致重复执行的位置。 对每个位置说明 Operation Current Protection Failure Scenario Data Impact Recommended Idempotency Strategy 不要修改代码。这条非常适合生产系统。十六、老系统还要重点检查“事务边界”例如创建订单 ↓ 扣库存 ↓ 扣余额 ↓ 写日志如果中间扣余额失败前面的库存怎么办如果没有正确的 Transaction很容易产生脏数据十七、Prompt数据库事务审查调查当前业务流程的事务完整性 [流程] 请找到所有数据库写操作。 分析 1. 哪些操作必须原子完成 2. 当前是否处于同一个 Transaction 3. 中间失败会发生什么 4. 是否可能出现部分成功 5. 是否存在并发修改 6. 是否需要锁 7. 是否存在重复写入 8. 是否存在补偿逻辑。 输出 Operation Transaction Boundary Failure Scenario Current Behavior Data Risk Recommendation 暂时不要修改代码。这个 Prompt 对订单 库存 账户余额 结算特别有价值。十八、AI 很适合帮你找“隐式业务规则”所谓隐式规则就是代码里有但文档里没有例如if(user.createdAt2022-01-01){fee0}这可能代表老用户免手续费但新人完全不知道。十九、Prompt自动提取业务规则不要修改代码。 阅读与以下模块相关的所有业务逻辑 [模块] 尝试提取代码中的隐式业务规则。 重点寻找 - if / else 业务条件 - 特殊日期 - 特殊用户 - 特殊渠道 - 特殊金额 - 特殊状态 - 白名单 - 黑名单 - 历史兼容判断 - feature flag。 每条规则输出 Rule Code Location Business Meaning Confidence Risk If Removed 是否已经有文档说明 最后整理成一份 Business Rules Summary。这一步甚至可以直接帮助你重新写项目文档。二十、不要一次性重构 5000 行代码AI 很容易给人一种错觉既然它改代码很快那就一次改完。但 Legacy Code 最忌讳Big Bang Refactor例如一次改 80 个文件问题来了如果上线出 Bug你很难判断到底哪一步出的问题更好的方式是Small Refactor ↓ Test ↓ Commit ↓ Next Refactor二十一、把大型重构拆成可回滚的小任务可以让 Codex我要重构以下 Legacy Module [路径] 不要直接修改。 请把重构拆成一组小 Task。 要求每个 Task - 可以独立提交 - 可以独立测试 - 尽量不改变外部行为 - 修改文件尽可能少 - 出问题可以单独回滚。 推荐结构 Task 1 Add tests Task 2 Extract constants Task 3 Extract pure function Task 4 Separate database access Task 5 Improve typing Task 6 Remove dead code 每一步说明 Goal Files Risk Tests Rollback Strategy这样 AI 会更像一个有纪律的开发团队而不是一次性代码生成器二十二、Dead Code 清理非常适合 Codex但不要盲删老项目经常存在旧接口 旧函数 旧配置 废弃 Feature但问题是没人敢删因为不知道还有没有地方调用。AI 可以帮你做静态调查。PromptDead Code Audit扫描项目中的潜在 Dead Code。 包括 - 未使用函数 - 未使用组件 - 未使用 API - 未使用配置 - 未使用环境变量 - 未使用数据库字段 - 已废弃 Feature Flag - 永远不会进入的条件分支。 不要删除。 每个候选项输出 Location Why It Looks Unused References Found Runtime Risk Confidence Safe To Remove? Yes / Maybe / No 只有高置信度项目才建议删除。最后一句很关键只有高置信度项目才建议删除因为动态语言项目里Reflection Dynamic Import Config Loading都有可能让静态分析误判。二十三、接手老项目时Git History 也是上下文代码只能告诉你现在是什么Git 历史很多时候能告诉你为什么变成这样比如某个奇怪判断if(countryUSversion4){你看不懂。但 Git Commit 可能写fix legacy mobile checkout compatibility立刻就懂了。所以在支持 Git 的开发环境中可以让 Agent 帮忙调查调查这个代码块的历史原因 [文件 / 函数] 不要修改代码。 检查相关 Git History。 找出 1. 最早什么时候加入 2. 为什么加入 3. 后续修改过几次 4. 哪些 Bug 与它相关 5. 当前是否仍然需要 6. 删除可能造成什么兼容风险。 不要仅根据当前代码猜测。这是 AI 接手 Legacy Code 很有价值的一个方向。二十四、ChatGPT 和 Codex 在老项目里的分工如果是我自己使用我会比较倾向ChatGPT做业务分析 架构理解 技术方案 风险讨论 需求拆解而Codex做搜索仓库 追踪调用 修改代码 跑测试 分析 Git Diff 执行验证可以理解成ChatGPT Thinking PartnerCodex Engineering Agent对于简单任务两者可以合在一起。但对于复杂 Legacy 系统先想清楚再执行仍然非常重要。二十五、Plus / Pro 用户真正应该看“任务复杂度”很多人比较 ChatGPT Plus、Pro 时习惯只问哪个回答更强对于开发者我认为可以换一个角度我的任务复杂度多高例如Level 1解释代码Level 2修改单个函数Level 3修复跨文件 BugLevel 4理解完整模块Level 5跨模块开发 测试Level 6大型 Legacy 系统重构越往后你需要的就越不是一次回答而是连续的 Agent 工作过程所以开发者使用 ChatGPT Plus、Pro、Codex 时真正值得观察的是我每天是在问多少个问题还是在交给 AI 多少个工程任务这两个使用模式完全不同。二十六、Legacy 项目非常适合建立 AGENTS.md如果这是一个长期维护的旧项目我会非常建议整理AGENTS.md例如# Legacy Project Rules ## Important This is a legacy production system. Backward compatibility is more important than architectural elegance. Do not refactor unrelated code. Do not change database schema unless explicitly required. Do not replace existing libraries without approval. ## Before Changes For every non-trivial task: 1. inspect current behavior; 2. inspect existing tests; 3. inspect related call sites; 4. identify backwards compatibility risk; 5. propose the smallest change. ## Legacy Behavior Suspicious behavior must not be changed during refactoring. Report it separately. ## Testing Before modifying critical modules, run existing relevant tests. After modification, run the same tests again. ## High Risk Modules Changes involving: - payments - balances - orders - permissions - authentication require explicit risk analysis.这类规则对于老项目特别有价值。因为 Legacy 项目的核心目标通常不是代码最漂亮而是稳定二十七、老项目重构最重要的一句话如果只让我保留一句 Prompt我会保留Preserve existing behavior unless the task explicitly requires a behavior change.翻译过来就是除非需求明确要求改变行为否则保持现有行为。因为 Legacy Code 最大的危险并不是代码不好看而是你不知道哪些奇怪代码其实承担着兼容责任二十八、一套可以直接复制的 Legacy Code 万能 Prompt如果你准备让 Codex 接手一个老项目可以直接保存下面这一段You are working on a legacy production system. Task: [描述任务] Before modifying anything: 1. inspect the related implementation; 2. trace the complete call path; 3. identify business rules; 4. identify database writes; 5. identify external side effects; 6. inspect existing tests; 7. identify backwards compatibility risks. Important rules: - Preserve existing behavior unless explicitly required. - Prefer the smallest reasonable change. - Do not refactor unrelated code. - Do not introduce new dependencies unnecessarily. - Do not change public APIs without explanation. - Do not modify existing tests merely to make them pass. For unclear or suspicious legacy behavior: Do not silently change it. Report it first. Implementation: Make the minimum change necessary. Verification: Run relevant existing tests. Add regression tests for the bug or feature. Run type checking / lint / build where applicable. Final Review: Review the Git Diff for: - accidental behavior change; - data integrity risk; - security issue; - concurrency issue; - backwards compatibility; - missing tests. Final Report: 1. Root Cause 2. Files Changed 3. Behavior Changed 4. Tests Executed 5. Test Results 6. Compatibility Risks 7. Remaining Unknowns这段基本能够覆盖大量老项目修 BugLegacy 重构接手历史系统场景。二十九、AI 时代Legacy Code 可能反而会变得更容易维护过去一个老项目最麻烦的地方是没人知道代码什么意思现在 AI 可以帮助搜索↓追踪↓总结↓还原业务规则↓生成测试↓辅助重构这意味着以前可能需要2 周才能大致理解的项目未来可能只需要更短时间就能建立基本系统地图。但这里有一个非常重要的前提AI 只能帮助你更快理解代码不能替你承担业务判断责任。尤其涉及支付 资金 权限 订单 用户数据仍然必须人工判断。三十、结语真正厉害的 Codex 使用方式不是“写更多代码”使用 ChatGPT、Plus、Pro、Codex 一段时间后我越来越觉得真正的效率提升不是以前一天写 500 行 现在一天写 5000 行而是以前需要一天才能看懂的问题 现在一两个小时能够建立方向尤其对于 Legacy Code 来说AI 最大的价值可能根本不是Generate Code而是Understand Code因为真实软件开发中大量时间其实花在读代码找调用查状态找历史原因确认修改影响这些工作上。所以如果你现在已经在使用 ChatGPT Plus、Pro 或 Codex 编程我非常建议不要只测试“它能不能帮我写一个新功能”还可以真正找一个没人愿意碰的旧模块让 Codex 先只读再分析再写测试最后小范围修改你可能会发现AI 编程真正价值最大的地方恰恰不是新项目。而是那些旧 复杂 缺文档 缺测试 没人敢改的真实系统。未来优秀开发者和 AI Coding Agent 的关系也许越来越像Developer 负责判断什么应该改变 Agent 负责快速理解什么已经存在最后形成一套更加高效的Human AI Legacy Engineering Workflow而这可能才是 ChatGPT、Plus、Pro、Codex 真正进入企业级开发以后最值得关注的能力之一。