Free Preview
先试读：Claude Code接手陌生项目的标准流程
Claude Code 很擅长读代码和改代码，但它需要先知道项目的边界。
很多人第一次用 Claude Code 接手项目，会直接说：“帮我把首页改一下”“帮我修这个 bug”“帮我加一个按钮”。如果项目很小，这样可能也能跑通；但只要项目稍微复杂一点，这种做法就容易出问题。
这篇能解决什么问题
- 把一句模糊需求改成 AI 能执行、你能验收的任务卡。
- 知道执行前要先检查哪些文件、风险点和验证命令。
- 避免 AI 顺手改无关内容，最后只交付可审、可回退的改动。
付费后能看到哪些内容
- 陌生项目最怕的不是不会改，而是不知道自己改到了哪里
- 第一轮不要问“怎么改”，先问“这个项目怎么运转”
- 启动、测试、构建入口，比页面代码更优先
- 先标出“不能随便改”的区域，再谈效率
可以先照着试的一句话
这是我要改的功能：___。请先阅读项目结构，列出会动哪些文件、风险点和验证命令；等我确认范围后，再开始做最小改动。
试读到这里先判断是否对你的任务有用；完整文章会继续展开步骤、案例、模板和避坑细节。
陌生项目最怕的不是不会改，而是不知道自己改到了哪里
Claude Code 很擅长读代码和改代码，但它需要先知道项目的边界。
很多人第一次用 Claude Code 接手项目，会直接说：“帮我把首页改一下”“帮我修这个 bug”“帮我加一个按钮”。如果项目很小，这样可能也能跑通；但只要项目稍微复杂一点，这种做法就容易出问题。
原因很简单：陌生项目里真正危险的不是某一行代码，而是隐藏关系。一个看起来普通的按钮，可能牵连登录态；一个页面路径，可能影响搜索索引；一个样式类名，可能被多个页面共用；一个数据字段，可能同时影响前台展示、后台校验和导出功能。
所以接手陌生项目，第一条规则是：先让 Claude Code 只读，不要让它马上改。你要让它像一个新来的工程师一样，先熟悉项目，再动手。
这个项目帮我优化一下。
你看哪里有问题就改哪里。
把代码整理一下，顺便修复 bug。
这些说法会把范围放得太大，Claude Code 可能会主动重构、改动无关文件，最后你很难判断到底发生了什么。
第一轮不要问“怎么改”，先问“这个项目怎么运转”
项目地图不是画得好看，而是把你马上要用到的入口找出来。
假设你拿到一个模拟项目：/Users/demo/projects/member-site。目录里有 src、public、scripts、package.json、README.md、deploy 等文件夹。你不应该让 Claude Code 逐个文件解释，而是让它按“工作入口”整理。
用户入口
哪些页面或路由面向用户，首页、登录页、会员页、支付页、内容页分别在哪里。
数据入口
配置、JSON、数据库访问、搜索索引、文章列表、权限字段从哪里来。
工程入口
怎么启动、怎么构建、怎么测试、怎么格式化、怎么部署。
风险入口
登录、权限、支付、生产部署、批量脚本、删除逻辑、外部 API。
请先只读这个模拟项目，不要修改文件。
目标：帮我建立项目地图。
请输出：
1. 项目主要目录分别负责什么
2. 用户页面入口在哪里
3. 启动、测试、构建、部署命令可能在哪里
4. 登录、权限、支付、外部 API 等高风险代码在哪里
5. 如果我要改一个页面，通常会牵连哪些文件
限制：
- 不要改代码
- 不要执行会写入、删除、部署、上传的命令
- 不要读取项目外的无关目录这一步的价值是建立上下文。你之后让 Claude Code 改任何东西，它都会更清楚哪些文件能碰、哪些文件要谨慎、哪些验证必须跑。
启动、测试、构建入口，比页面代码更优先
不能验证的修改，本质上都还没完成。
陌生项目里最应该先找的，不一定是业务代码，而是验证方式。因为你迟早要问：这个修改有没有坏掉？如果不知道怎么启动、怎么跑测试、怎么检查构建，你就只能靠肉眼看代码。
让 Claude Code 检查这些文件：README.md、package.json、pnpm-lock.yaml、vite.config.*、next.config.*、Makefile、scripts/、.github/workflows/。不是每个项目都有这些文件，但它们经常能暴露项目的真实使用方式。
| 要找的入口 | 常见位置 | 为什么重要 |
|---|---|---|
| 启动命令 | README.md、package.json | 决定本地能不能打开页面，能不能复现用户问题。 |
| 测试命令 | package.json、pytest.ini、vitest.config.* | 决定修改后能否回归验证。 |
| 构建命令 | package.json、CI 配置 | 决定线上打包是否会失败。 |
| 部署命令 | deploy/、CI、项目文档 | 决定哪些操作会影响线上环境，必须人工确认。 |
这一步你可以让 Claude Code 输出“可执行但暂不执行”的命令清单。比如它可以告诉你 npm run dev 可能用于启动，npm test 可能用于测试，但除非你确认，不要让它直接执行会消耗资源、写入环境或影响线上系统的命令。
先标出“不能随便改”的区域，再谈效率
AI 参与开发最大的风险，不是慢，而是改到了你没有意识到的地方。
一个成熟的接手流程，会把项目文件分成三类：低风险、中风险、高风险。低风险通常是静态文案、单页样式、局部组件；中风险是共享组件、公共工具函数、构建配置；高风险是认证、权限、支付、数据库迁移、线上部署、批量删除、外部通知。
请根据当前模拟项目，列出高风险文件和中风险文件：
- 高风险：登录、权限、支付、数据库、部署、批量删除、外部发送
- 中风险：共享组件、公共样式、搜索索引、构建配置
- 低风险：单页文案、单页局部样式、独立示例文件
请说明每类文件为什么风险不同，以及修改前应该做哪些验证。第一次改动要小，最好只解决一个可验证问题
陌生项目的第一刀，不适合重构，也不适合“顺便优化”。
让 Claude Code 第一次动手时，建议选择一个范围明确、容易验证、失败也容易回滚的任务。比如模拟项目里“某个工具文章卡片链接写错了”，这就比“把整个工具页结构优化一下”更适合首次修改。
第一次修改的目标不是炫技，而是建立信任链：它能不能只改目标文件？能不能解释为什么这么改？能不能跑对应验证？能不能告诉你没有碰高风险文件？
合适的首次任务
修一个坏链接、补一个搜索索引、改一个单页错字、调整一个局部展示问题。
不合适的首次任务
重构全站、重写权限、改支付、迁移数据库、替换整个前端框架。
修改前
要求它列出计划改哪些文件、为什么改、哪些文件不会碰。
修改后
要求它列出实际改动、验证结果、剩余风险和是否需要人工复查。
一套完整的陌生项目接手提示词
你可以把下面这段当作 Claude Code 接手新项目的固定开场。
请接手这个模拟项目，先只读，不要修改文件。
第一步：建立项目地图
- 说明主要目录和关键文件的作用
- 找出用户页面入口、数据入口、启动入口、测试入口、构建入口
- 标出登录、权限、支付、数据库、部署、外部 API 等高风险区域
第二步：输出工作建议
- 如果我要改一个页面，应该先看哪些文件
- 如果我要修一个 bug，应该如何复现和验证
- 如果我要新增一个功能，哪些共享模块可能受影响
第三步：给出下一步计划
- 只列计划，不改文件
- 每一步说明风险等级
- 明确哪些操作需要我确认后才能执行- Claude Code 已说明项目主要目录和关键文件作用。
- 已找到启动、测试、构建、部署入口，或说明没找到。
- 已标出登录、权限、支付、数据库、部署等高风险区域。
- 第一次修改只针对一个明确问题，不做顺手重构。
- 修改后能列出实际改动文件、验证方式和剩余风险。