Claude Code 深度指南：从安装到团队协作

Claude 普通聊天更像顾问，Claude Code 更像进入项目现场的施工队。它可以读取项目文件、理解上下文、提出计划、修改代码、运行命令、帮你持续推进功能。

它最适合三类人。第一，已有项目但不会继续开发的人。第二，会一点代码但需要 AI 加速的人。第三，想让 AI 按任务单长期推进项目的人。

Claude Code 不等于“全自动 CTO”。你仍然要提供目标、边界和验收方式。最好的用法不是让它“帮我做一个网站”，而是让它“按这个任务单，先读项目，列计划，确认后修改，最后跑测试并输出验收报告”。

如果你现在做的是 AI 百科、工具站、源码包装、会员内容站，Claude Code 的价值主要在三点：持续读懂项目、把任务落到文件、对复杂变更保持上下文。

进入项目目录：

cd /path/to/your/project
claude

第一次提问建议用只读模式：

先不要修改任何文件。请阅读当前项目，并用小白能听懂的话说明：
1. 这个项目是做什么的；
2. 前端、后端、数据、配置分别在哪里；
3. 本地启动命令是什么；
4. 当前最明显的风险是什么；
5. 适合先做的 5 个小任务是什么。

这比直接说“帮我继续开发”有效得多。Claude Code 需要先建立项目地图，你也需要确认它理解得对不对。

第二个任务可以让它做小改动：

请只修改 README，增加“本地启动步骤”一节。不要改代码。完成后告诉我修改了哪些内容。

第三个任务再进入真实代码：

请给首页增加一个入口按钮。要求：不改接口、不改数据结构、不影响现有样式。修改前先告诉我计划。

Claude Code 最怕模糊需求。比如“做个会员系统”太大，它会涉及登录、数据库、权限、支付、前端状态、后端接口、内容 gate、错误处理。你要把它拆成小任务。

错误写法：

帮我把网站做成能收费的。

正确写法：

目标：给百科词条的 oneClickUse 和 proTips 增加登录墙。
范围：先只做前端展示和后端 mock 判断，不接真实支付。
要求：
1. 未登录显示 teaser；
2. 已登录显示完整内容；
3. 不影响公开 SEO 正文；
4. 不改现有 wiki JSON 结构；
5. 完成后说明下一步如何接支付。
先输出计划，不要修改文件。

每个 Claude Code 任务最好包含 5 个字段：目标、范围、禁止事项、验收标准、测试命令。你可以把这套格式做成固定模板，后面每个客户项目都复用。

让 Claude Code 改代码时，要强制它先计划，再执行，再验收。

通用提示词：

请按三段式执行：
第一段：阅读相关文件并输出修改计划，不改文件。
第二段：我确认后再修改。
第三段：修改后运行检查命令，并输出修改文件、验证结果、风险点。

如果你已经允许它修改，可以写：

请实现这个功能，但必须遵守：
- 不删除已有功能；
- 不改数据库结构；
- 不引入新的大型依赖；
- 不把密钥写进代码；
- 每完成一步说明做了什么。

完成后必须看 Git diff：

git diff
git status

你不需要完全看懂每行代码，但至少要看它有没有改了不该改的文件。比如你让它改文案，它却改了鉴权逻辑，这就必须回滚。

Claude Code 很适合长期协作，但长期协作必须配 Git。每次任务开始前先确认工作区干净：

git status

新任务新分支：

git checkout -b ai/fill-guides

Claude Code 完成后：

git diff
git add .
git commit -m "docs: fill guide chapters"

如果它改坏了：

git restore .

如果你要让 Claude Code 自己提交，也要先让它说明提交内容：

请根据当前改动生成一个 commit message，但不要执行 git commit。先给我看。

不要让 AI 在你没看 diff 的情况下直接 push 到生产分支。AI 写代码快，犯错也快；Git 是你的保险。

Claude Code 的价值不只是改代码，还在于能越来越懂你的项目规则。你可以把项目约定写进文档，例如：目录结构、命名规则、禁止改动、上线流程、付费层规则。

建议在项目根目录放一个类似 `CLAUDE.md` 或任务说明文件，写清楚：

# 项目规则
- 不要破坏 SEO SSR。
- 公开正文可收录，付费内容不要下发给未登录用户。
- wiki*.json 可以多文件合并，按 slug 去重。
- 指南文件一个 .md 是一本书，## 是章节。
- 看到“待填充”就说明章节未完成。

每次开新会话，先让 Claude Code 读取这些规则：

请先阅读项目规则文件和 docs 目录，确认你理解当前项目的内容结构。先不要修改文件。

如果配置 MCP 或 Skills，原则是“先文档，后工具，最后线上权限”。给 AI 接文档检索通常风险低；给 AI 接浏览器、数据库、支付后台风险高。任何能改生产数据的工具都必须要求人工确认。

如果你习惯 VS Code，可以使用 Claude Code 的 IDE 集成。IDE 的好处是你能一边看文件，一边让 Claude Code 解释、修改、审查。对小白来说，比纯终端更直观。

适合 IDE 的任务：解释某个文件、修改一个组件、看 diff、处理 TypeScript 报错、补注释、重命名变量。不适合一上来在 IDE 里做超大范围重构，因为你容易被大量文件变化淹没。

推荐工作方式：

• 在 VS Code 打开项目。
• 先运行项目，确认原始状态能跑。
• 让 Claude Code 解释当前文件。
• 让它只改一个明确功能。
• 看 diff，跑测试，再提交。

如果扩展连接不上，先确认终端里的 `claude` 命令能正常运行。很多 IDE 问题本质上是 CLI 没装好、PATH 不一致、账号没登录。

团队里使用 Claude Code，最好给它明确角色。老板定目标，产品经理写需求，Claude Code 执行，Codex 或另一个模型审查，人类最终上线。

推荐任务单：

角色：你是执行工程师，不是产品经理。
任务：按下面需求修改代码。
限制：不能扩大范围，不能自行改产品逻辑。
验收：必须运行构建命令，必须输出修改文件清单。

团队常见问题是每个人都让 AI 按自己的理解改，最后项目风格混乱。解决办法是统一项目规则、统一分支命名、统一验收标准、统一提交格式。

如果你要把 Claude Code 卖给客户，交付物不要只是代码。更好的交付包括：任务清单、执行记录、修改文件、测试结果、风险说明、下一步建议。这些内容可以自动化生成，客户更容易感知价值。