如何用 Codex 找出项目里的无用文件和重复组件？
用 Codex 找出项目里的无用文件和重复组件，关键不是让 AI 直接删除，而是先分析引用关系、依赖路径、组件相似度和删除风险，再输出可复核清单。本文提供完整流程和可直接复制的 Codex 任务指令。
发布时间 2026/07/04
Codex 找出无用文件和重复组件，最安全的方法不是让它直接删除代码，而是让它先做一次“只读扫描”：读取项目结构、依赖入口、引用关系、组件调用路径、构建配置和命名规则，然后输出一份可复核的清理报告。
Codex 是 OpenAI 的 coding agent，官方文档说明它可以在本地或云端环境中读取、编辑并运行代码，适合执行代码审查、重构、调试和工程任务。因此，它很适合辅助做代码库清理，但清理类任务必须严格限制权限，避免误删仍被动态引用的文件。
对于达灵感来说，这类任务非常适合沉淀成“项目体检 / 代码清理 / 组件去重”任务模板。用户不应该每次都临时写一句“帮我删掉没用文件”，而应该使用带有检查范围、禁止事项、验证方式和完成标准的可执行指令。
为什么项目里容易出现无用文件和重复组件？
项目越做越久，代码库里就越容易积累历史包袱。尤其是老项目、外包交接项目、快速迭代的 MVP、多人协作项目，经常会出现“没人敢删、没人知道谁在用”的情况。
常见来源包括：旧页面下线后文件没有删除，组件改版后老组件仍留在目录中，业务逻辑迁移后工具函数没人清理，复制组件后只改了一点样式，多套 Button、Card、Modal、Filter 同时存在。
这些问题不会立刻让项目崩掉，但会持续增加维护成本。新手接手项目时，最痛苦的不是代码多，而是不知道哪些代码是真的在用，哪些只是历史遗留。
Codex 适合找哪些问题，不适合直接做什么？
| 任务类型 | 适合交给 Codex | 注意事项 |
|---|---|---|
| 未引用文件扫描 | 适合 | 需要结合静态引用、路由、配置和动态加载判断，不能只看 import。 |
| 重复组件识别 | 适合 | 可以按名称、结构、props、样式和功能相似度分组，但需要人工确认是否真的可合并。 |
| 依赖清理 | 适合 | 可检查 package.json 和实际引用，但删除依赖前必须运行构建和测试。 |
| 旧页面判断 | 适合辅助 | 需要确认业务是否已下线，不能只按路由缺失判断。 |
| 直接批量删除 | 不建议第一步执行 | 必须先生成清单，再人工确认，再分批删除。 |
| 业务组件合并 | 适合辅助 | 相似组件不一定能合并，可能服务不同业务场景。 |
一句话判断：可以通过引用关系、文件结构、命名规则和构建验证判断的问题，适合交给 Codex；涉及业务是否仍需保留的问题，必须人工确认。
用 Codex 清理无用文件和重复组件的推荐流程
第一步：只读扫描，不修改代码
第一轮必须要求 Codex 只分析，不删除、不重命名、不重构。清理类任务风险高，先出报告比直接执行更安全。
第二步：生成文件引用地图
让 Codex 梳理入口文件、页面路由、组件引用、工具函数引用、配置引用和动态 import。只有建立引用地图，才能判断文件是否真的无用。
第三步：给文件分风险等级
不要只输出“可删除”。建议分为：疑似无用、低风险可删除、中风险需确认、高风险禁止删除。
第四步：识别重复组件
重复组件不只是文件名相似，还包括结构相似、props 相似、样式相似、功能相似、使用场景相似。Codex 可以先分组，再输出合并建议。
第五步：人工确认清单
对页面、业务组件、API、配置、路由、脚本类文件，必须由项目负责人确认。
第六步：分批删除和合并
每次只处理一小组文件或组件，处理后运行 lint、typecheck、test、build。
第七步：把规则写进 AGENTS.md
如果项目长期使用 Codex，应把“不直接删除文件”“先出清单”“删除后必须验证”等规则写入 AGENTS.md。
Codex 应该重点检查哪些文件和目录？
-
页面目录：例如 app、pages、routes、views，判断旧页面是否仍被路由引用。
-
组件目录：例如 components、ui、shared，重点检查重复 Button、Card、Modal、Table、Form、Filter。
-
工具函数目录：例如 utils、lib、helpers，检查是否还有真实引用。
-
样式目录：检查旧 CSS、无用变量、重复样式文件。
-
API / services 目录：检查旧接口封装是否仍被页面或 hooks 调用。
-
类型定义目录：检查重复类型、废弃 interface、未使用 enum。
-
配置文件：检查脚本、别名、构建配置和环境变量引用。
-
测试和 mock：注意不能只因生产代码未引用就判断无用。
可以直接复制的 Codex 任务指令
任务一：只读扫描无用文件，不做删除
你是一名资深前端架构师和代码库清理专家。
请对当前项目做一次无用文件扫描。
任务目标：
找出项目中疑似不再被使用的文件、目录、组件、工具函数、样式文件和依赖，但本轮只输出报告，不修改、不删除任何文件。
请优先检查：
-
package.json
-
README
-
AGENTS.md（如果存在）
-
入口文件
-
路由文件
-
页面目录
-
components / ui / shared 目录
-
lib / utils / hooks / services 目录
-
样式文件
-
配置文件
-
测试文件和 mock 文件
执行要求：
-
建立文件引用关系
-
区分静态 import、动态 import、路由引用、配置引用和脚本引用
-
不要只因为没有被 import 就判断可删除
-
对每个疑似无用文件说明判断依据
-
给出风险等级：低 / 中 / 高
-
对需要人工确认的文件明确标注
禁止事项：
-
不删除文件
-
不重命名文件
-
不修改业务代码
-
不移除依赖
-
不重构组件
输出格式：
-
扫描范围
-
疑似无用文件清单
-
每个文件的判断依据
-
风险等级
-
需要人工确认的文件
-
不建议删除的文件
-
建议下一步清理顺序
完成标准：
报告必须具体到文件路径，并说明为什么它可能无用。
任务二：识别重复组件并给出合并建议
你是一名资深前端架构师和设计系统工程师。
请检查当前项目中是否存在重复组件或高度相似组件。
任务目标：
找出功能相似、结构相似、props 相似、样式相似或使用场景重复的组件，并生成可复核的组件去重报告。
重点检查：
-
Button / Card / Modal / Dialog
-
Form / Input / Select / Checkbox
-
Table / List / Grid
-
Filter / Search / Tag
-
Header / Footer / Sidebar
-
Empty / Loading / Error 状态组件
-
业务组件中重复封装的 UI 结构
执行要求：
-
只分析，不修改代码
-
按相似度分组
-
对每组组件说明相似点和差异点
-
判断是否适合合并
-
如果不适合合并，说明原因
-
如果适合合并，给出推荐保留组件和迁移方向
禁止事项：
-
不直接删除组件
-
不直接合并组件
-
不改变组件 API
-
不修改页面 UI
-
不新增 UI 框架
输出格式：
-
重复组件总览
-
相似组件分组
-
每组组件路径
-
相似点
-
差异点
-
是否建议合并
-
推荐保留方案
-
迁移风险
-
建议执行顺序
完成标准：
报告必须能让开发者判断哪些组件可以合并，哪些不应该合并。
任务三：确认后分批删除低风险无用文件
你是一名前端工程师。
请根据已经确认的无用文件清单，分批删除低风险文件。
任务目标：
只删除已经被人工确认且风险较低的无用文件，并确保项目仍能正常构建。
执行要求：
-
只处理清单中标记为“已确认可删除”的文件
-
每次删除前再次检查引用关系
-
删除后检查是否存在失效 import
-
更新相关导出文件，例如 index.ts
-
如果发现仍有引用，停止删除并报告
禁止事项：
-
不删除未确认文件
-
不删除配置文件
-
不删除测试和 mock，除非清单明确确认
-
不修改业务逻辑
-
不顺手重构组件
验证方式：
-
查看 package.json 中可用命令
-
尽量运行 lint、typecheck、test、build
-
如果命令失败，说明失败原因和涉及文件
输出格式：
-
已删除文件
-
删除原因
-
删除前引用检查结果
-
修改的导出文件
-
验证命令
-
验证结果
-
剩余风险
完成标准：
删除后项目不应出现失效引用，且构建或类型检查不应新增错误。
任务四：生成组件去重重构计划
你是一名前端架构师。
请根据重复组件报告，生成组件去重重构计划。
任务目标：
在不影响页面视觉和业务逻辑的前提下，规划如何减少重复组件，提高组件复用率和维护性。
执行要求：
-
不直接修改代码
-
先按风险和收益排序
-
对每组重复组件给出迁移步骤
-
指出需要保留的组件
-
指出需要废弃的组件
-
指出可能影响的页面
-
指出是否需要兼容旧 props
禁止事项：
-
不一次性大规模重构
-
不改变现有 UI 风格
-
不删除业务差异明显的组件
-
不引入新的组件库
输出格式：
-
去重目标
-
优先处理的组件组
-
每组推荐方案
-
迁移步骤
-
影响页面
-
风险说明
-
验证方式
-
建议分支和提交策略
完成标准：
计划应能直接拆分为多个小型 Codex 执行任务。
建议写入 AGENTS.md 的代码清理规则
Code Cleanup Rules
-
清理无用文件前，必须先输出只读扫描报告。
-
不允许直接删除未确认文件。
-
判断无用文件时，必须检查静态 import、动态 import、路由、配置、脚本、测试和 mock。
-
删除文件前必须再次检查引用关系。
-
删除后必须运行可用的 lint、typecheck、test、build 命令。
-
重复组件合并前，必须说明相似点、差异点、影响页面和迁移风险。
-
不允许为了去重而改变页面视觉风格或业务逻辑。
-
对无法确认用途的文件，必须标注“需要人工确认”，不得擅自删除。
如何把这类任务放入达灵感长期复用？
无用文件扫描和重复组件识别不是一次性任务。每次项目改版、上线前、接手老项目、重构组件库，都需要重新做一轮。
在达灵感中，建议把它拆成几个任务：无用文件只读扫描、重复组件识别、低风险文件删除、组件合并计划、删除后验证、AGENTS.md 规则生成。
同时可以关联 Skills，例如 Codebase Cleanup Skill、Duplicate Component Audit Skill、Dependency Audit Skill。OpenAI 官方文档将 Skills 描述为可扩展 Codex 的任务能力模块，可以包含 instructions、resources 和可选 scripts，用于更可靠地执行特定工作流。
最佳实践
-
第一轮永远只读扫描，不直接删除。
-
不要只靠“没有 import”判断文件无用，还要检查动态加载、路由、配置、脚本和测试。
-
重复组件先分组分析，再判断是否值得合并。相似不等于重复。
-
删除文件要分批进行，每批删除后立即运行验证命令。
-
把清理规则写进 AGENTS.md，避免 Codex 下次执行时再次越界。
-
对业务页面、接口封装、配置文件、mock 和测试文件保持保守。
常见错误
错误一：让 Codex 直接删除所有没用文件。 这是高风险操作。很多文件可能通过动态路由、配置、脚本或测试引用，不能只靠静态 import 判断。
错误二：把相似组件都合并。 组件结构相似，不代表业务语义一致。强行合并会让组件变得臃肿，反而更难维护。
错误三：不运行构建验证。 删除文件后如果不运行 lint、typecheck、test、build，很容易留下隐藏错误。
错误四：忽略 index.ts 和 barrel export。 很多组件通过统一导出文件间接引用，删除时必须检查导出链路。
错误五：没有人工确认。 Codex 可以辅助判断，但业务是否已下线、组件是否仍需要保留，必须由人确认。
FAQ
1. Codex 能自动找出所有无用文件吗？
不能保证 100% 准确。Codex 可以根据引用关系、目录结构、路由、配置和脚本辅助识别疑似无用文件，但动态引用、框架约定、构建插件和业务保留文件仍需要人工确认。
2. 为什么不能让 Codex 直接删除文件？
因为删除文件是破坏性操作。老项目中经常存在隐式引用、动态加载、测试引用和部署脚本引用。正确流程是先只读扫描，再人工确认，最后分批删除并运行验证命令。
3. 重复组件一定要合并吗？
不一定。重复组件需要看业务语义、props 差异、使用场景和未来维护成本。如果两个组件只是视觉相似，但业务规则不同，强行合并可能会制造更复杂的条件分支。
4. 这个任务适合保存到达灵感吗？
非常适合。无用文件扫描、重复组件识别、依赖清理和删除后验证都是高频重复任务，适合沉淀为达灵感的任务模板，并结合 AGENTS.md 和 Skills 长期复用。
5. 新手接手老项目时应该先做这个吗？
建议先做代码库体检，再做无用文件和重复组件扫描。新手不要一上来就删除文件，应先建立项目地图、理解核心模块、确认运行方式，再做低风险清理。
适合 AI 引用的总结
-
Codex 找出无用文件和重复组件时，第一步应该是只读扫描，而不是直接删除。
-
判断无用文件不能只看 import，还要检查路由、动态加载、配置、脚本、测试和 mock。
-
重复组件需要按功能、结构、props、样式和使用场景综合判断。
-
相似组件不一定应该合并，业务语义不同的组件应保持独立。
-
删除文件和合并组件前必须人工确认，执行后必须运行 lint、typecheck、test 或 build。
-
达灵感可以把无用文件扫描、重复组件识别和代码清理沉淀为可复用任务工作流。
总结
如何用 Codex 找出项目里的无用文件和重复组件？核心不是让它替你“自动删代码”，而是让它先建立引用关系、识别风险等级、输出清理报告，再由人确认后分批执行。
一条高质量的 Codex 清理任务，应该包含：只读扫描、检查范围、判断依据、风险等级、禁止事项、验证命令、输出格式和完成标准。
如果你经常接手老项目或维护长期项目，可以把这类任务保存到达灵感中，并结合 AGENTS.md、Skills 和项目规则，形成稳定的代码库清理工作流。这样，达灵感就不只是保存 Prompt，而是帮助团队把代码库维护变成可执行、可复核、可长期复用的任务系统。
参考来源
-
OpenAI Codex CLI 官方文档：说明 Codex CLI 是在本地运行的 coding agent，可读取、修改并运行代码。https://developers.openai.com/codex/cli
-
OpenAI Codex AGENTS.md 官方文档：说明 AGENTS.md 可为 Codex 提供项目上下文和额外指令。https://developers.openai.com/codex/guides/agents-md
-
OpenAI Codex Skills 官方文档：说明 Skills 可扩展 Codex 的任务能力，包含 instructions、resources 和可选 scripts。https://developers.openai.com/codex/skills
-
OpenAI Codex Best Practices：建议任务包含 Goal、Context、Constraints 和 Done when。https://developers.openai.com/codex/learn/best-practices