企业官网建设流程全解析

摘要

旧项目通常存在重复代码、类型缺失、历史兼容逻辑和测试不足等问题。直接让 Codex“重构整个项目”，很容易扩大修改范围，甚至破坏原有业务。本文介绍如何先识别技术债、评估风险，再按照小范围、可验证的方式逐步处理。

接手旧项目时，开发者最容易犯的错误，是还没有理解业务，就开始整理代码。

常见提示词是：

帮我重构这个项目，删除没用的代码并优化结构。

这类任务范围太大。Codex 可能把历史兼容逻辑判断为无用代码，也可能为了统一风格，一次修改几十个文件。

更稳妥的方式，是先让 Codex完成技术债盘点。

一、先分析，不要立即修改

可以使用下面的任务：

请分析当前项目的技术债，暂时不要修改代码。 重点检查： 1. 重复代码； 2. 超大组件和超长函数； 3. 缺失的类型定义； 4. 长期未使用的依赖； 5. 缺少测试的核心模块； 6. 历史兼容逻辑； 7. 高耦合模块； 8. 构建和测试警告。

分析结果不要只列问题，还要按照风险分级。

二、技术债要分为三类

低风险技术债

例如：

• 重复工具函数；

• 无效导入；

• 明确未使用的变量；

• 注释与代码不一致；

• 缺少简单类型定义。

这类问题修改范围小，容易测试，可以优先处理。

中风险技术债

例如：

• 大型页面组件；

• 重复接口封装；

• 状态管理逻辑分散；

• 多个模块使用不同的数据结构。

这类问题需要先补测试，再分阶段重构。

高风险技术债

例如：

• 登录和权限；

• 支付与订单状态；

• 数据库迁移；

• 请求拦截器；

• 历史数据兼容；

• 公共类型和全局状态。

高风险模块不能只根据代码“看起来不合理”就修改，必须先确认真实业务规则。

三、一次只处理一个问题

不要同时整理目录、修改类型、升级依赖和重写测试。

可以先选择一个明确任务：

本次只处理订单模块的重复金额格式化逻辑。 允许修改： - src/utils/money.ts - src/views/order - tests/order 禁止修改： - 接口字段； - 支付逻辑； - package.json； - 其他业务模块。

任务越小，Git Diff 越容易审查，出现问题时也更容易回滚。

四、旧项目重构前必须建立测试基线

在修改之前先运行：

npm run type-check npm run test npm run build

记录项目原本存在的失败和警告。

否则修改后出现测试错误，很难判断是历史问题，还是本次重构引入的问题。

对于没有测试的模块，可以先让 Codex根据现有行为补充最小回归测试，再开始整理代码。

五、用 Git Diff 判断修改是否失控

每完成一个小阶段，都要检查：

git status git diff --stat git diff

重点确认：

• 是否修改了计划外文件；

• 是否出现大面积格式化；

• 是否删除历史兼容判断；

• 是否改变接口返回结构；

• 是否新增第三方依赖；

• 是否降低测试标准。

如果一个简单任务出现十几个文件变化，应该先暂停，让 Codex重新缩小范围。

六、什么时候需要评估更高使用方案？

偶尔分析一个旧项目，现有使用方式通常已经够用。

但如果每天都需要 Codex：

• 阅读大型历史仓库；

• 分析多个业务模块；

• 连续修改和运行测试；

• 处理大量失败日志；

• 分阶段清理技术债；

• 同时维护多个旧项目；

任务上下文和使用强度会明显提高。

这时应先通过任务拆分和AGENTS.md减少无效消耗。如果工作流已经优化，但分析、测试和重构仍经常因使用限制中断，就需要重新评估 Plus、Credits 或 Pro 哪种方案更符合长期维护需求。

总结

Codex 接手旧项目时，正确顺序不是先重构，而是：

先盘点技术债，再进行风险分级；先建立测试基线，再小范围修改；每完成一步，都通过测试和 Git Diff 验证。

AI 可以快速发现重复代码和结构问题，但是否删除历史逻辑、调整核心模块，仍然需要开发者结合业务判断。

旧项目越复杂，越不能一次性重写。把技术债拆成多个可验证的小任务，才是更可靠的处理方式。

CSDN 文章描述

Codex 接手旧项目时如何处理技术债？本文介绍技术债盘点、风险分级、测试基线、最小修改和 Git Diff 审查流程。

推荐标签

Codex技术债代码重构旧项目维护ChatGPT Pro

参考资料

1. Git 官方文档

2. TypeScript 官方文档

3. Martin Fowler：《Refactoring》

4. 软件工程技术债管理实践