DeepDojo.AI发布 2026-11-10更新 2026-11-10English
第一次启动 Claude Code，从只读调查开始
第一次在项目里启动 Claude Code，你问它这个项目是做什么的。它很快回答：“这是一个管理用户数据的 Web 应用，使用 PostgreSQL 存储数据。”听上去很专业，可它看了哪些文件？“PostgreSQL”是从配置里读到的，还是看见一个 data/ 目录就推出来的？
首次会话最容易出问题的，恰恰是这种看似顺利的时刻。你还不知道它进了哪个目录、找到了哪些文件，就让它启动服务、修复问题，或者把一段没有依据的总结当成事实，后面选文件、写计划都会跟着偏。
所以第一次会话只做一件事：在正确的项目目录里，让它只读调查，并给每个结论配上文件依据。具体分四步：
- 找到项目根目录，用计划模式启动，确认界面显示的实际模式；
- 写一个范围清楚的只读请求，排除密钥和私人资料；
- 从用途、技术栈一路问到入口、检查方式和候选小任务；
- 结束前整理一份带依据的会话记录。
这一轮不改文件、不安装依赖。它留下的是一张有依据的项目地图，后面选任务、写计划、做验证，都从这里接着走。
01 第一次会话只做调查
首次会话先只读调查，核对项目目录、实际权限模式和回答依据，再考虑修改。此时还不知道 Claude Code 找到了哪些文件，启动所有服务或修复全部问题都为时过早。
先走这条路径：
在真实项目目录中启动 Claude Code
↓
确认它进入了正确项目现场
↓
先问用途、结构和依据
↓
记录它对项目的判断
↓
暂时不改文件第一次会话能留下有依据的项目地图，就已经很有用了。
02 从项目根目录启动
启动目录决定调查起点。子目录可能让相关配置不易被找到，多项目的父目录则可能混入无关文件。先确认当前项目根目录与任务范围，再开始读取。
启动目录只给调查定一个起点，访问边界由别的设置决定。工具还能访问什么，要结合实际权限与环境配置判断。
先看看终端当前在哪：
| 位置 | 可能遇到的问题 |
|---|---|
| 项目里的某个子目录 | 看不到上层配置或相关代码 |
| 放着多个项目的父目录 | 混入其他项目的文件 |
| 系统目录或下载目录 | 很难看清这次调查到哪里为止 |
可以这样理解：
启动目录就是 Claude Code 当前进入的项目现场。那么，应该进入哪一层目录？通常从项目根目录开始。可以先查找项目中已有的这些线索：
package.json
README.md
pyproject.toml
requirements.txt
src/
app/
test/
.git/各类项目的标志文件不同。把配置、源码入口和版本管理信息放在一起看，通常能找到根目录。
在终端切到项目目录，路径换成你自己的实际地址：
| 终端 | 查看当前位置 | 切换目录 |
|---|---|---|
| macOS、Linux、PowerShell | pwd | cd "项目路径" |
| CMD | cd | cd /d "项目路径" |
这次只做调查，可以这样启动：
claude --permission-mode plan第一次使用时，Claude Code 可能会引导你登录。进入会话后，先查看当前工作目录，并用 /help 确认基本命令，然后检查三个问题：
当前工作目录是不是我的项目目录？
Claude Code 是否成功进入交互会话？
我是否知道如何查看帮助和退出？用 /help 查看当前版本的命令，用 /exit 退出会话。即使用 plan 参数启动，也要确认界面显示的实际模式。按官方权限模式说明，计划模式会运行 shell 命令来探索项目、写出计划，但不编辑源码；所以探索命令有没有副作用、哪些文件允许读取，仍要单独检查。
03 写一个范围清楚的只读请求
首次请求应明确调查范围。只说“介绍项目”，没有说明是否允许安装或运行脚本；把只读限制和解释要求一起写清。
可以这样问：
请先不要修改任何文件、安装依赖或运行高风险命令。
请阅读这个项目，并用新手能听懂的话告诉我：
这个项目主要是做什么的？这个请求先读项目，也说清了这轮允许做什么。把 .env、密钥和私人资料排除在读取范围外；需要了解环境配置，就先看没有秘密值的示例文件。后续追问沿用同一限制。
有了用途概览，还要往下查技术栈、入口和模块关系。比如看见一个登录页，认证逻辑可能在前端、后端，也可能在第三方服务里。位置没查清，即使代码能运行，也可能改错层。接下来的问题会逐步补上这些依据，仍然只读。
04 从概览一步步收窄
每轮核对依据后，再从概览缩小到具体位置：
| 调查顺序 | 要弄清什么 | 依据从哪里找 |
|---|---|---|
| 用途 | 项目解决什么问题，谁会使用 | README、页面与主要功能 |
| 技术栈 | 使用什么语言、框架和工具 | 依赖、配置与源码 |
| 入口与目录 | 从哪里开始，主要模块如何分工 | 入口文件和实际调用 |
| 运行与检查 | 可能怎样启动、测试或构建 | 项目脚本和配置，当前不执行 |
| 候选小任务 | 哪一步范围小、风险低且可检查 | 相关文件、影响范围与验证办法 |
这些问题沿用首次请求的只读和敏感资料限制。关键结论要指向具体文件内容，证据不足时标为待确认；找到命令，只说明有这个入口，能不能运行成功要等实际执行。
首次会话阅读与当前问题相关的文件就够了。想把它扩成一张完整的项目地图，包括流程追踪和候选任务筛选，可以接着看怎样让 Claude Code 画出项目地图。
05 每个结论都要有文件依据
首次调查守住三项边界：不改文件，不运行未理解的命令，没有依据的总结只当线索。
若它建议运行命令，先问清用途，以及是否会编辑、安装、删除或影响外部状态，本轮仍停留在只读分析。回到开头那句“这是一个管理用户数据的 Web 应用”，就要追问具体文件和支持判断的内容。
| 看到的内容 | 能作出的判断 |
|---|---|
package.json 有 React 依赖，dev 脚本是 vite | 配置采用 React、Vite，有开发启动入口 |
| 只找到启动脚本，还没运行 | 启动方式有依据，服务是否能启动仍待验证 |
只看见 data/ 目录 | 还无法确认数据库；说它使用 PostgreSQL，需要对应依赖、配置或代码 |
路径只是回查入口，文件内容是否支持结论才是判断依据。它要读哪些文件、跑哪些命令，又该怎样判断能不能批准，可以看权限请求的判断方法。
06 留下一份会话记录
结束前，把查清的信息留下来。下一步选任务、写计划时，还要用到这些依据；只留一段泛泛的项目介绍，就得重新调查。
完成首次会话后，记下这些内容：
- 项目名称与类型；
- 技术栈；
- 入口与关键目录；
- 可能的运行和检查命令；
- 低风险候选任务。
每项附上判断依据，不存在或尚未确认的信息直接标明。
整理时再确认两件事：每项判断都有文件、配置或命令依据；会话保持只读，没有修改、安装或执行高风险命令。做到这两点，这份记录就能接住后面的项目地图和改动计划。