第一次让 CC 阅读项目

Claude Code 第一次任务教程：第一次只做只读项目分析，不改文件，先确认 CC 能正确理解项目结构、入口和风险。

直接复制这段

第一次任务必须只读。它的目的不是让 CC 证明会写代码，而是让你确认它能不能看懂项目、能不能区分事实和推测、能不能遵守边界。

请只读分析当前项目，不要创建、修改、删除任何文件。

请按下面格式回复：

## 你读取了什么
- 列出你查看过的关键文件和目录。

## 项目概况
- 这个项目是做什么的：
- 技术栈：
- 前端入口：
- 后端入口：
- 配置文件：

## 已确认的脚本或检查方式
- 只写你从项目文件中确认存在的命令或脚本。
- 如果没有确认，请写“未确认”，不要猜。

## 风险和注意事项
- 可能不能随便改的目录：
- 可能涉及密钥或隐私的文件：
- 第一次练习建议做什么低风险任务：

请用中文解释，不要输出太长。

第一次不要急着让 CC 改代码。项目越复杂，第一步越要慢一点。只读分析能暴露三个关键能力：

合格回答应该长什么样

• 它列出了真实读取过的文件。
• 它能说清项目用途和技术栈。
• 它能指出入口文件或写“未确认”。
• 它只写项目文件里能确认的脚本。
• 它识别出密钥、隐私、生产配置风险。
• 它建议了一个低风险练习任务。

不合格回答通常有这些特征：

• 只说“这是一个前端项目”，但不说从哪个文件判断。
• 直接猜 npm run dev、npm test，没有说明依据。
• 没看目录就建议大改架构。
• 没提醒密钥、配置、数据库、构建产物等风险。
• 在只读任务里创建总结文件或修改 README。

你要看什么

• 它有没有真的读取文件，而不是泛泛而谈。
• 它有没有把推测说成事实。
• 它有没有识别出项目入口和风险文件。
• 它有没有遵守“不修改文件”。

继续追问项目结构

请继续只读解释项目结构。

要求：
1. 按目录解释，不要逐文件流水账。
2. 标出最重要的入口和配置。
3. 标出普通新手先不要碰的目录。
4. 如果有前端、后端、脚本、测试，请分别说明。
5. 不要修改文件。

如果项目很大

大型项目不要让 CC 一口气读全部内容。先让它建立地图，再分区阅读：

这个项目比较大，请继续只读分析。

请先给出项目地图：
1. 哪些目录是核心业务。
2. 哪些目录是配置、脚本、测试或文档。
3. 哪些目录可能是构建产物或依赖，不需要深入阅读。
4. 建议下一步优先阅读哪 3 个位置。
5. 不要修改文件。

如果是前后端同仓库，可以这样追问：

请判断这个仓库是否包含多个应用或多个服务。

请说明：
1. 每个应用或服务的目录。
2. 它们各自的启动入口。
3. 它们是否共享配置、类型、组件或工具函数。
4. 第一次练习应该选哪个低风险区域。
5. 不确定的地方写“未确认”。

继续追问可用命令

请只读确认项目已有脚本或检查方式。

要求：
1. 只列出从项目文件确认存在的脚本。
2. 说明每个脚本大概做什么。
3. 不要猜命令。
4. 不要直接执行。
5. 建议第一次验收应该用哪个最小检查。

如果它开始乱猜

请重新回答。

要求：
1. 只保留你能从项目文件中确认的事实。
2. 对不确定的信息写“未确认”。
3. 不要根据常见项目结构猜测命令、入口或框架。

让 CC 给第一次任务建议

只读结束后，可以让 CC 帮忙挑第一个小任务。这个任务要足够小，最好能轻松验收：

基于刚才的只读分析，请推荐 3 个第一次练习任务。

要求：
1. 必须低风险。
2. 每个任务都要说明会涉及哪些文件。
3. 每个任务都要说明怎么验收。
4. 不要推荐数据库、权限、支付、登录、部署相关任务。
5. 不要修改文件。

适合第一次练习的任务：

• 改一段页面文案。
• 补一段 README 说明。
• 调整一个很小的样式问题。
• 给已有文档补一个链接。
• 修一个明确、可复现的小 Bug。

如果它试图修改文件

请停止修改。

本任务要求只读分析。
请说明：
1. 你是否已经修改文件。
2. 如果有，修改了哪些文件。
3. 如何撤回这些修改。
4. 接下来请重新只读分析。

第一次只读后的下一步

只读分析完成后，不要马上做大功能。下一步只做：

• 选一个低风险小任务。
• 进入 Plan Mode。
• 让 CC 给最小修改方案。
• 人工确认后再执行。

第一次任务的通过标准

第一次只读任务通过，应该满足：

如果这些都满足，再进入第一轮小改动；如果不满足，先纠正 CC 的理解，不要带着错误地图继续开发。

验收结果

• CC 没有修改文件。
• 你拿到了项目概况、入口和真实脚本。
• 你知道第一个低风险任务应该做什么。
• 你能判断 CC 有没有乱猜。