你有没有遇到过这种情况：用Claude Code开发了一段时间后，打开项目目录一看，里面堆了三四十个文件，有些是你自己写的，有些是Claude生成的，还有一些你根本不知道是干嘛用的。

一位网友发帖说：“你那22万行代码的代码库可能是一团臃肿的乱麻。建议是把重构和删除死代码作为你工作流程的常规部分。”虽然说的是一个更大的项目，但这个原则适用于任何规模。Claude生成代码很快。它也会生成你不需要的代码。

用Claude Code开发就是这样的。它写代码确实快，但不会管你的项目是不是已经有一个同样的功能了。举个例子：Claude可能在这周创建了一个格式化日期的工具函数，下周又创建了另一个也格式化日期的函数，放到了不同的文件里。两个都能用，但谁也不调用谁。你的项目里就这样悄悄多了两个干同一件事的函数。

把这个模式放大到整个项目，你就会得到一堆重复的辅助函数、孤立的组件、压根没用到过的导入、以及调试时创建但事后忘了删的文件。

Claude没有眼睛，也不记得它上周创建了什么。每次新对话都是从头开始。它读取你的文件，构建你这次要的东西，却不记得三次对话前已经在某处写过一个完全够用的formatDate函数。

这篇文章就是教你做清理的。跟着步骤走完，你的项目会变得精简有序，Claude干活也能快不少。

01_claude_code.jpg

寻找死代码
死代码是指项目中存在但从未实际运行的代码。未使用的导入、未被调用的函数、未被任何页面渲染的组件、未被任何文件引用的文件。

Claude 可以帮你找到它们。开启一个新的对话（为此任务清理上下文），然后说：

扫描整个代码库，识别死代码。检查：每个文件中的未使用导入、未被任何文件引用的导出函数、未被任何页面或布局渲染的组件、未被任何文件引用的文件。列出每个实例，包括文件路径和行号。
Claude 会系统地读取每个文件，追踪导入关系图，并报告未使用的部分。在一个经过多次会话构建的典型项目中，我发现有 10-15% 的死代码。对于项目来说，大概是 3-5 个文件或函数。

在删除任何内容之前，先审查列表。有时 Claude 会误将代码识别为死代码，而实际上它被动态使用（通过变量导入、在配置 文件中引用，或作为未出现在导入语句中的服务器操作）。对于 Claude 标记的每个项目，问自己：“这是通过 Claude 无法追踪的机制使用的吗？”如果不确定，可以问 Claude：“formatDate 是否在静态导入分析可能遗漏的地方被使用？检查服务器操作、动态导入和配置文件。”

确认死代码后，告诉 Claude：“删除所有已确认的死代码。移除未使用的导入。删除孤立文件。”然后运行测试以验证没有破坏任何功能。如果测试通过，清理就是安全的。

合并重复代码
死代码是显而易见的浪费。重复代码则是隐蔽的浪费。它虽然能正常工作，但会让项目变得更大、更难维护。更重要的是，它会让 Claude 在每个任务中读取更多文件，从而消耗更多 token。

告诉 Claude：“查找在不同文件中实现相同功能的函数、工具或组件。按功能分组。对每组，推荐保留哪个版本、删除哪个版本。”

在 Claude 构建的项目中常见的重复代码：

多个 API 客户端包装器。 Claude 可能在一个文件中创建了 fetchTasks 函数，在另一个文件中创建了 getTasks 函数。两者都访问数据库，返回相同的数据。一个是在早期创建的，另一个是在Claude忘记第一个时创建的。

冲突的类型定义。 TypeScript 项目 会积累重复的类型定义。Claude 在一个文件中创建了 Task 类型，在另一个文件中创建了相同的 TaskType。两者描述相同的数据结构，且彼此不互相导入。

冗余的工具函数。 字符串格式化函数、日期解析函数、验证辅助函数。Claude 在需要时创建它们，而不检查是否已存在。

对于每组重复代码，选择更好的版本（通常是更完整的那个），删除其他版本，并更新所有导入。告诉 Claude：“将这些重复的工具合并到 src/lib/utils.ts 的单个文件中。更新整个代码库中的所有导入。”

合并后，再次运行测试。如果通过，你就减少了文件数量，并使未来的每个 Claude 会话更高效，因为需要读取的文件更少了。

重复代码的真实成本
这里有一个具体例子说明重复代码如何浪费 token。假设你在 src/utils/dates.ts 中有 formatDate，在 src/components/TaskCard.tsx 中有 formatTimestamp。它们功能相同，只是名称略有不同。

当你要求 Claude“更改整个应用中日期的显示方式”时，未经清理的情况是这样的：Claude 读取两个文件，找到两个日期格式化函数。它不知道哪个是标准版本，于是同时更新两者。如果它们签名略有不同，Claude 可能会引入不一致。而且你为 Claude 读取和修改两个文件支付了费用，而实际上一个文件就足够了。

经过清理后：只有一个 formatDate 在 src/lib/utils.ts 中。Claude 读取一个文件，进行一次更改，更新会传播到所有地方，因为所有内容都从同一来源导入。token 成本减半，不一致的可能性为零。

在一个月的日常开发中，这累积起来。与典型的 Claude 生成冗余项目相比，一个没有重复代码的干净项目大约能节省 20-30% 的 token 使用量。这还不包括其他的优化。节省效果是叠加的。

组织文件结构
03_image.jpg

Claude 对文件组织没有强烈偏好。它会根据你的项目结构，把文件放在它认为合适的位置。久而久之，这会导致一个扁平文件夹里堆满二十个文件，而不是按逻辑分组形成嵌套结构。

查看你的 src 目录。所有文件是否都在一个文件夹里？组件、工具函数、类型定义和服务器操作是否混在一起？

以下是我在 Next.js 项目中使用的结构：

src/
├── app/ （页面、布局、路由）
├── components/ （UI 组件）
│ ├── ui/ （通用组件：Button、Input、Card）
│ └── tasks/ （功能特定组件：TaskList、TaskForm、TaskCard）
├── lib/ （工具函数、辅助方法、共享逻辑）
├── types/ （TypeScript 类型定义）
└── actions/ （服务器操作）
告诉 Claude：“将项目文件重新组织成这个结构。把组件移到相应的子文件夹。把工具函数移到 lib/。把类型定义移到 types/。更新所有导入路径。不要更改任何功能。”

Claude 会移动文件并更新项目中所有导入语句。运行你的测试。如果测试通过，你的项目现在就是按用途组织，而不是按创建日期排列了。

为什么组织对 Claude Code 很重要？因为 Claude 读取文件的方式。当你让 Claude“在任务卡片上添加一个按钮”时，它需要找到任务卡片组件。在包含二十个文件的扁平结构中，Claude 可能要读取五个文件才能找到正确的那个。而在有组织的结构中，它会直接进入 src/components/tasks/TaskCard.tsx。读取的文件越少 = 消耗的 token 越少 = 响应速度越快。

用新结构更新你的 CLAUDE.md 文件，这样未来的对话就不会打乱你的组织：

文件结构
src/
├── app/ （仅包含页面和布局）
├── components/
│ ├── ui/ （通用可复用组件）
│ └── tasks/ （任务特定组件）
├── lib/ （工具函数和共享逻辑）
├── types/ （TypeScript 类型定义）
└── actions/ （用于数据库操作的服务器操作）
项目文件树的前后对比