完整案例：接手老项目的第一周

Claude Code 老项目接手完整案例：从只读体检、架构梳理、风险台账、低风险任务、CLAUDE.md 草稿到交接记录，跑通真实项目接入第一周。

接手老项目时，最容易犯的错不是改得慢，而是还没看清边界就开始改。

这篇用“一周接手老项目”的方式，把真实项目接入、老项目体检、架构梳理、技术债扫描、第一批低风险任务和 CLAUDE.md 沉淀串起来。它不是替代单篇教程，而是告诉你这些动作应该按什么顺序发生。

案例背景

假设现在接手一个维护多年的后台管理系统：

README 有，但可能过时。
依赖版本比较旧。
有登录、权限、订单、报表等模块。
测试不完整，构建脚本没人完全确定。
团队希望先修小问题，再逐步进入需求开发。

这类项目不能一上来就让 CC “帮我优化一下”。第一周的目标只有一个：建立安全接入边界，完成一个低风险闭环。

第一天：只读体检，不修改文件

第一天不要改代码。先让 CC 只读体检项目。

请对当前老项目做一次只读接入体检，不要修改任何文件。

请输出：
1. 项目类型、技术栈和包管理器。
2. 启动、构建、测试、部署相关脚本。
3. 核心目录和入口文件。
4. 主要业务模块。
5. 高风险区域：登录、权限、订单、数据库、配置、部署脚本。
6. 当前未知项。
7. 第一批适合 CC 参与的低风险任务。
8. 不建议现在交给 CC 的任务。

要求：
1. 每个结论都要说明证据来自哪个文件。
2. 没有证据的内容标注“待确认”。
3. 不要安装依赖。
4. 不要运行可能修改文件或数据的命令。

体检报告不要追求“看起来完整”，而是要区分三类信息：

类型	处理方式
已确认	可以作为后续任务依据
待确认	先记录，不拿来指导修改
高风险	暂不交给 CC 自动处理

第一天完成后，应该知道这个项目能不能启动、哪些目录重要、哪些地方不能乱碰。

第二天：梳理主架构，不展开所有细节

体检之后，再让 CC 梳理架构。这里不要让它把所有文件都列出来，而是先抓主路径。

请只读梳理当前项目的主架构，不要修改文件。

重点输出：
1. 应用启动入口。
2. 前端路由或后端接口入口。
3. 核心业务模块。
4. 数据流或请求链路。
5. 配置和环境变量边界。
6. 认证、权限、数据写入相关高风险边界。

要求：
1. 先只画主路径，不要展开所有分支。
2. 每个节点标注关键文件。
3. 对不确定内容标注待确认。

架构梳理的目标不是生成一篇漂亮文档，而是回答后面做任务时最重要的问题：

改这个页面会影响哪些组件。
改这个接口会经过哪些服务层。
哪些目录是公共能力，不能随便改。
哪些配置和部署有关，必须人工确认。

如果 CC 输出太散，继续收敛：

请把刚才的架构说明收敛成一条主链路。

格式：
用户操作
-> 页面或路由入口
-> 业务处理层
-> 数据请求或服务层
-> 外部服务 / 数据库 / 本地状态

每一层只保留关键文件和职责。

第三天：建立风险台账

看清架构后，不要马上重构。先让 CC 把技术债和风险点分开。

请基于只读体检和架构梳理，建立一份风险台账，不要修改文件。

字段：
1. 编号
2. 问题或风险描述
3. 证据文件
4. 影响范围
5. 风险等级：低 / 中 / 高
6. 是否建议本周处理
7. 建议动作
8. 验收方式
9. 需要人工确认的内容

要求：
1. 不要把代码风格问题评为高风险。
2. 登录、权限、数据写入、部署脚本默认谨慎处理。
3. 不建议一次性重构。

这一步最重要的是把“看着不舒服”和“真实风险”分开。

类型	示例	本周动作
低风险技术债	README 过时、目录说明缺失	可以补
中风险问题	某模块错误处理不完整	先建任务
高风险边界	权限判断分散、部署脚本不清楚	人工确认
暂不处理	大版本依赖升级、大范围重构	单独评审

风险台账的价值，是让团队知道哪些问题该现在处理，哪些问题应该先别碰。

第四天：选择第一个低风险任务

第一周必须有一个真实闭环，但任务要小。

适合作为第一批任务：

补 README 的启动说明。
给核心目录补一份说明文档。
修一个非核心页面的小样式问题。
给某个页面补验收清单。
整理一份接口或模块说明。

不适合作为第一批任务：

登录权限改造。
订单、支付、资金相关修改。
数据库结构变更。
依赖大版本升级。
发布脚本调整。
大范围重构。

让 CC 按风险台账推荐任务：

请从风险台账里选 3 个适合本周完成的低风险任务。

要求：
1. 每个任务最多影响 1 到 3 个文件。
2. 不涉及登录、权限、订单、数据库、部署、生产配置。
3. 每个任务都有明确验收方式。
4. 说明为什么它适合作为第一批任务。

选定后再执行：

可以执行第 1 个低风险任务。

限制：
1. 只改本任务直接相关文件。
2. 不顺手处理其他风险台账项。
3. 修改后解释 diff。
4. 给出验收步骤。
5. 如果发现任务影响范围扩大，立即停止并说明。

第一批任务的意义，是验证 CC 能不能在这个老项目里小步、克制、可验收地工作。

第五天：验收和代码审查

低风险任务完成后，不要只看“文件改了”。要用真实项目标准验收。

/verify

请按真实项目接入标准验收本次修改：
1. 原始任务是否完成。
2. 修改文件是否符合预期范围。
3. 是否碰到登录、权限、数据库、配置、部署脚本等高风险区域。
4. 是否有无关改动。
5. 是否能用现有方式验证。
6. 是否有需要人工复查的地方。

再做一次审查：

/code-review

请审查本次老项目接入的第一批修改。

重点：
1. 是否过度修改。
2. 是否引入无依据的重构。
3. 是否误改公共组件或核心模块。
4. 是否遗漏风险。
5. 是否需要补充文档或验收说明。

只输出问题和建议，不要继续改代码。

第一次真实项目闭环，审查的重点不是“代码高级不高级”，而是有没有守住边界。

第六天：沉淀 CLAUDE.md 草稿

项目跑顺以后，再沉淀长期记忆。不要把所有体检报告都塞进 CLAUDE.md，只写长期有效的项目规则。

请基于这一周的接入过程，整理一份 CLAUDE.md 草稿。

只包含长期有效内容：
1. 项目技术栈。
2. 常用启动、构建、测试方式。
3. 核心目录说明。
4. 高风险目录和禁止事项。
5. 推荐验收方式。
6. 提交或交接格式。

不要写：
1. 临时任务细节。
2. 还没确认的猜测。
3. 真实密钥、Token、账号密码。
4. 本周一次性的聊天结论。

先输出草稿，不要直接写入文件。

CLAUDE.md 的作用，是让下一次任务更稳；不是把聊天记录存档。

第七天：交接记录和下一步计划

最后让 CC 生成一份接手记录，作为后续开发的入口。

请整理老项目第一周接手记录。

结构：
1. 项目概览。
2. 已确认的启动、构建、测试方式。
3. 核心架构和主链路。
4. 高风险边界。
5. 风险台账摘要。
6. 已完成的低风险任务。
7. 验收结果。
8. 建议下周处理的任务。
9. 仍需人工确认的问题。

要求：
1. 不要夸大已完成内容。
2. 不要把待确认写成已确认。
3. 每个建议任务都要说明风险等级和验收方式。

这份记录可以用于团队同步，也可以作为自己后续继续开发的地图。

一周节奏总表

时间	动作	产物
第一天	只读体检	项目接入体检报告
第二天	架构梳理	主链路和风险边界
第三天	技术债扫描	风险台账
第四天	选低风险任务	第一批任务计划
第五天	修改、验收、审查	可交付 diff 和验收记录
第六天	记忆沉淀	CLAUDE.md 草稿
第七天	总结交接	接手记录和下一步计划

常见失败方式

第一天就让 CC 改核心代码。
没分清待确认和已确认。
把 README 过时直接当成真实启动方式。
看到技术债就让 CC 一次性重构。
第一批任务选了权限、数据库或部署脚本。
没做 diff 审查和验收就进入下一项任务。
把临时结论写进 CLAUDE.md，导致后续任务被误导。

验收结果

能把老项目接手拆成一周节奏。
能先体检、再梳理、再建风险台账。
能选择低风险任务跑通第一批闭环。
能把长期有效信息沉淀成 CLAUDE.md 草稿。
能留下可交接、可继续推进的项目接手记录。

上一篇：真实项目接入前检查下一篇：老项目体检