面向对象：会使用 Git、会基本命令行、参与真实项目开发的前端 / 后端 / 全栈开发者
目标：把 Claude Code 真正落到团队开发流程里，用 CC Switch 接入 DeepSeek，让 AI 参与需求理解、代码阅读、功能开发、测试、重构、文档、Code Review，但仍然保留工程规范、安全边界和人工审查
声明：本文仅提供基础教程和个人使用建议，请先查看 Claude Code 官方文档

前文

1. AI 是什么？

刚开始用 AI 写代码，会把它理解成自动生成代码的工具，实际 AI 能做的事情远不止于此。

AI 编程助手 = 大语言模型 + 项目上下文 + 工具调用 + 人工约束。

大语言模型本身并不懂你的项目，它只会根据输入内容预测合理的输出。
Claude Code 这类工具能够用于开发的原因在于：它不是单纯聊天，而是能进入你的项目目录，读取文件、理解结构、修改代码、运行命令、查看报错、继续调整。
AI 在真实项目里像一个可以操作电脑的开发者：

• 快速阅读大量代码
• 根据语言描述生成/改写代码
• 运行测试、查看报错日志、继续修复
• 写文档、操作 Git 写提交说明、生成 PR 描述
• 也可能误解需求、写出看似正确但实际错误的代码

团队开发中使用 AI 的核心不是让 AI 取代开发者，而是：

让 AI 承担重复、繁琐、信息量大、需要跨文件检索的工作，让开发者负责判断、约束、设计和审核最终质量。

目前主流的 AI 大模型 Coding Plan 对比：

2. 为什么要使用 Claude Code？

市场上已知的 AI 大模型都有自己的网页端，可以聊天对话。
但是这类聊天工具的问题是：它看不到完整项目，只能根据你粘贴的代码回答。工程稍微有点规模以后，可能会出现几个问题：

1. 你不可能把所有文件都粘贴进去
2. 它不知道项目目录结构
3. 它不知道项目启动命令、测试命令、数据库约束等
4. 它无法自己运行命令验证
5. 它给你的代码还要你手动复制粘贴

Claude Code 的价值在于它是一个终端里的 AI Agent：

开发者
  ↓ 用人类的语言描述需求
Claude Code
  ↓ 读取项目 / 检索并查看相关文件 / 编辑文件 / 运行命令 / 查看报错
提交代码至仓库
  ↓ git diff / test / lint / commit / PR
回复开发者

它适合做的事情：

3. 为什么要使用 CC Switch ？

CC Switch 是个开源工具。现代 AI 编程可能同时依赖 Claude Code、Claude Desktop、Codex、Gemini CLI、OpenCode、OpenClaw 和 Hermes 等工具，但每个工具都有自己的配置格式。切换 API 供应商通常意味着手动编辑 JSON、TOML 或 .env 文件，而多个工具之间也缺乏统一管理 MCP、Skills 的方式。

CC Switch 提供一个桌面应用来管理支持的 AI 工具。无需手动编辑配置文件，你可以通过可视化界面导入供应商、切换供应商，并使用内置供应商预设、统一 MCP / Skills 管理以及系统托盘快速切换等能力。其配置写入基于 SQLite 数据库和原子写入机制，目标是降低配置损坏风险。

4. AI 项目架构

团队 AI 项目开发的架构建议：

Git 仓库
├── src/                         # 项目源码
├── tests/                       # 测试
├── docs/                        # 项目文档（用于Claude Code参照/引用）
├── CLAUDE.md                    # 给 Claude Code 的项目说明
├── .claude/
│   ├── settings.json            # 团队共享配置
│   ├── skills/                  # 团队自定义 AI 技能
│   └── agents/                  # 自定义子代理
├── .gitignore
└── README.md

各目录/文件的作用

核心原则：

• 可以使用 AI 写代码，但生成的所有代码/文档都应经过人工审核
• 提示词要简洁，需求要明确，不附带无关的描述，更不应辱骂 AI
• 项目的文档与项目语言应当保持一致。比如对日项目，文档、代码注释和 CLAUDE.md 应优先采用日语编写
• 对于复杂/中大型业务的开发应当优先采用文档驱动开发的模型进行
• 每个会话不应过长，过长的上下文会增加 AI 误解需求或遗漏关键约束的概率。可新开会话，或通过 /clear 清空上下文、通过 /compact 压缩上下文
• 开发/修正结束后应当先由 AI 进行一轮自动化测试，再由人工进行代码审核，确认后再提交至 Git 仓库

正文

5. 安装前准备

建议本机准备：

6. 安装 CC Switch

进入 CC Switch 官方 GitHub Releases，下载最新版本：

CC-Switch-v{version}-Windows.msi

安装后启动 CC Switch。

7. Claude Code 的三种主流安装方式

7.1 CC Switch 安装方式

如果你使用的 CC Switch 版本提供 Claude Code 安装入口，可以打开 CC Switch，依次点击：

左上角设置图标 -> 关于 -> Claude Code 卡片的右下角安装按钮

安装完成后，新开一个命令行，验证：

claude --version

如果能看到版本号，说明安装成功。

7.2 npm 安装方式

npm 方式适合作为兼容安装方案。如果你已经安装了 Node.js，打开 Git Bash 或命令行，执行：

npm install -g @anthropic-ai/claude-code

验证：

claude --version

7.3 PowerShell 安装方式

这是官方推荐的安装方式。打开 PowerShell 命令行，执行：

irm https://claude.ai/install.ps1 | iex

验证：

claude --version

8. DeepSeek API Key 准备

你需要先到 DeepSeek 创建 API Key。API Key 不要写进代码仓库、README、聊天记录或截图里；建议保存到密码管理器、系统环境变量或 CC Switch 的本地配置中。如果怀疑泄露，立即删除并重新创建。

9. 使用 CC Switch 配置 DeepSeek

在 CC Switch 中：

点击右上角 +
  ↓
预设供应商选择 DeepSeek
  ↓
填入 API Key，其他不变
  ↓
点击右下角添加按钮
  ↓
在 CC Switch 首页点击 DeepSeek 对应行的启用按钮

CC Switch 通常可以直接切换供应商；如果切换后没有生效，再重新打开终端或重启 Claude Code。

然后执行：

claude

对于 Claude Code 没有进入过的目录，通常会提示是否信任此文件夹。确认项目来源可靠后，选择 Yes 或按提示继续。

测试，向 Claude Code 提问：

请回复我"ok"

配置无误的情况下，AI 会回复 ok。

10. CLAUDE.md 是什么？

CLAUDE.md 可以理解成给 AI 看的项目说明书。

AI 新开启会话时不会天然知道你的项目约定和历史决策；通过阅读 CLAUDE.md、项目文档和必要的记忆文件，它可以理解：

• 项目是什么
• 用到了哪些技术栈
• 如何启动项目
• 如何测试项目
• 目录结构
• 代码风格
• 哪些文件不能修改
• 提交规范
• 业务规则

这些内容都应该写进 CLAUDE.md。

10.1 初始化 CLAUDE.md

在项目根目录通过命令行运行：

claude

进入后执行：

/init

Claude Code 会帮你生成基础版本 CLAUDE.md。

自动生成的内容通常不够好，需要团队人工整理。CLAUDE.md 不宜过长，好的 CLAUDE.md 应该是简洁有效的。

你可以在自己的 CLAUDE.md 中加入以下四个基本原则：

### 1. 编码前思考

**不要假设。不要隐藏困惑。呈现权衡。**

LLM 经常默默选择一种解释然后执行。这个原则强制明确推理：

- **明确说明假设** — 如果不确定，询问而不是猜测
- **呈现多种解释** — 当存在歧义时，不要默默选择
- **适时提出异议** — 如果存在更简单的方法，说出来
- **困惑时停下来** — 指出不清楚的地方并要求澄清

### 2. 简洁优先

**用最少的代码解决问题。不要过度推测。**

对抗过度工程的倾向：

- 不要添加要求之外的功能
- 不要为一次性代码创建抽象
- 不要添加未要求的"灵活性"或"可配置性"
- 不要为不可能发生的场景做错误处理
- 如果 200 行代码可以写成 50 行，重写它

**检验标准：** 资深工程师会觉得这过于复杂吗？如果是，简化。

### 3. 精准修改

**只碰必须碰的。只清理自己造成的混乱。**

编辑现有代码时：

- 不要"改进"相邻的代码、注释或格式
- 不要重构没坏的东西
- 匹配现有风格，即使你更倾向于不同的写法
- 如果注意到无关的死代码，提一下 —— 不要删除它

当你的改动产生孤儿代码时：

- 删除因你的改动而变得无用的导入/变量/函数
- 不要删除预先存在的死代码，除非被要求

**检验标准：** 每一行修改都应该能直接追溯到用户的请求。

### 4. 目标驱动执行

**定义成功标准。循环验证直到达成。**

将指令式任务转化为可验证的目标：

| 不要这样做... | 转化为... |
|--------------|-----------------|
| "添加验证" | "为无效输入编写测试，然后让它们通过" |
| "修复 bug" | "编写重现 bug 的测试，然后让它通过" |
| "重构 X" | "确保重构前后测试都能通过" |

对于多步骤任务，说明一个简短的计划：

1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]
3. [步骤] → 验证: [检查]

强有力的成功标准让 LLM 能够独立循环执行。弱标准（"让它工作"）需要不断澄清。

源自：受 Karpathy 启发的 Claude Code 指南

11. 标准 AI 开发流程

不要一上来就让 AI “帮我做xx功能”。

以下是开发一个完整功能时推荐的处理流程：

1. 新建分支，提出需求，让 AI 查询官方文档（如已联网或配置了 Context7）并结合项目代码分析可行性，并要求不得修改代码（建立上下文）
2. AI 阅读项目分析相关文档
3. 确认 AI 给出的方案，利用 Superpowers 的 `writing-plans` / `/write-plan` 编写实现计划
4. 确认或修改计划
5. 利用 `/subagent-driven-development` 实现计划
6. 要求 AI Review 代码，并结合 `Playwright` 进行浏览器 / E2E 测试
7. 查看 git diff，人工 Review 代码
8. AI 根据反馈修正
9. 提交 PR
10. 团队 Code Review
11. CI 通过后合并分支

以上流程主要来自 Superpowers skills；不同安装方式下命令名可能略有差异，以 /help、插件 README 或 CC Switch 中实际显示为准。本文末尾给出一些开发推荐 skills。

12. 做功能前：先让 AI 分析可行性并理解相关代码

错误提示词：

帮我做用户管理功能。

这个需求太宽泛，AI 在无法清晰理解需求时很容易乱改。

推荐提示词：

我要新增“用户管理”功能。

需求如下：

1. 管理员可以查看用户列表；
2. 支持按用户名、手机号搜索；
3. 支持启用 / 禁用用户；
4. 不需要删除用户；
5. 前端使用现有表格组件；
6. 后端接口遵守现有 /api/admin 的风格；
7. 不做批量操作。

请先不要修改代码，而是进行可行性分析。

以上确认没问题后，通过 Superpowers 的 writing-plans / /write-plan 让 AI 编写实现计划。

13. 确认计划后再让 AI 修改

计划没问题，开始实现。

建议使用 /subagent-driven-development 进行实现，此技能会优先通过子代理形式拆分任务。好处是任务边界更清楚、每个子代理拥有相对独立的上下文，能减少上下文污染。

如果有特别要求，则额外标注。例如：

• 不要提交代码
• 尽量丰富注释，注释采用日文
• ...

14. 快速理解陌生代码

提示词：

请帮我理解这个项目的登录流程。

要求：

1. 从前端登录页面开始；
2. 追踪到 API 请求；
3. 再追踪到后端 Controller / Service / Mapper；
4. 说明 Token 是怎么生成和校验的；
5. 最后画一个文本版流程图；
6. 不要修改代码。

AI 非常适合这种“读代码 + 总结调用链”的工作。

15. 补充测试

提示词：

请阅读这个 service 的逻辑，为它补充单元测试。

要求：

1. 覆盖正常场景；
2. 覆盖空值；
3. 覆盖权限不足；
4. 覆盖数据库返回空；
5. 不要修改业务代码；
6. 写完后运行测试。

16. 局部重构

提示词：

请重构这个文件，但不要改变外部行为。

目标：

1. 拆分过长函数；
2. 提取重复逻辑；
3. 保留原有接口；
4. 保留原有返回结构；
5. 修改后运行测试；
6. 输出重构前后的差异说明。

17. 根据报错修复 bug

提示词：

下面是报错信息，请结合项目代码定位原因。

要求：

1. 先解释报错含义；
2. 找到最可能的代码位置；
3. 给出修复方案；
4. 等我确认后再修改。

报错如下：

【粘贴报错】

18. 写文档

提示词：

请根据当前项目生成接口文档。

要求：

1. 按模块分组；
2. 每个接口包含路径、方法、参数、返回示例；
3. 标注需要登录的接口；
4. 不要编造不存在的接口；
5. 如果代码里没有明确返回结构，请标注“不确定”。

19. AI 容易犯的错误

20. 必须遵守

以下事项不要直接交给 AI 自动执行：

rm -rf
git push --force
数据库 DROP / TRUNCATE
生产环境 kubectl / docker 操作
线上配置修改
支付逻辑上线
权限系统大改
批量数据修复
密钥读取
证书读取
删除迁移文件
关闭测试
绕过 lint
绕过 CI

如果必须做，也应该只让 AI 生成方案，然后人工审核并执行。

21. AI 生成代码的 PR 要求

建议团队规定：凡是 AI 参与较多的 PR，都要在 PR 描述里写清楚：

## AI 使用说明

本 PR 使用了 Claude Code 辅助开发。

AI 参与内容：

- 阅读相关模块
- 生成部分代码
- 补充测试
- 生成 PR 描述

人工确认内容：

- 需求理解
- 架构方案
- 代码 diff
- 测试结果
- 安全风险

22. Code Review 重点

Reviewer 不要只看“代码能不能跑”，还要重点看：

1. 是否符合需求；
2. 是否越权；
3. 是否破坏旧逻辑；
4. 是否引入重复代码；
5. 是否异常处理完整；
6. 是否影响性能；
7. 是否有测试；
8. 是否改了不该改的文件；
9. 是否出现 AI 编造的字段 / 接口；
10. 是否有安全风险。

23. AI 开发任务拆分建议

不要给 AI 一个巨大任务：

帮我开发完整后台管理系统。

要拆成小任务：

任务 1：阅读项目并输出技术栈
任务 2：设计用户管理接口
任务 3：实现用户列表接口
任务 4：实现前端用户列表页面
任务 5：增加启用 / 禁用
任务 6：补充测试
任务 7：生成 PR 描述

然后列为实施计划，由子代理执行。

24. Skills 是什么？

Skill 可以理解成“可复用的 AI 工作流程”。

当你发现团队经常复制同一段提示词，比如：

• “帮我做 PR Review”；
• “帮我生成接口文档”；
• “帮我检查越权风险”；
• “帮我生成测试用例”；

就可以做成 Skill。

目录示例：

.claude/skills/security-review/SKILL.md

示例：

---
name: security-review
description: 检查当前改动中的安全风险、权限问题、敏感信息泄露和危险操作。
---

# Security Review Skill

请审查当前 git diff，重点检查：

1. 是否存在越权访问；
2. 是否泄露敏感字段；
3. 是否读取 `.env` 或密钥；
4. 是否有 SQL 注入风险；
5. 是否有 XSS 风险；
6. 是否有不安全的文件上传；
7. 是否绕过权限校验；
8. 是否修改生产配置；
9. 是否引入危险命令；
10. 是否缺少审计日志。

输出格式：

## 高风险问题

## 中风险问题

## 低风险问题

## 建议修改

## 是否建议阻塞合并

使用时：

/security-review

25. 推荐 Skills

以下 Skills 不建议一次性全装到生产项目中。更稳妥的方式是：先在个人项目或非核心分支试用，确认不会引入危险命令、不会读取敏感文件、不会破坏团队流程后，再放进团队共享配置。

安装第三方 Skills 前，一定要先阅读仓库里的 SKILL.md、脚本文件和安装说明。Skills 可能会影响 AI 的执行方式，甚至包含可执行脚本；团队项目中不要直接安装来源不明的 Skills。

26. Prompts 是什么？

Prompts 更像固定提示词模板。
适合团队统一一些常用问法，例如：

请先不要修改文件，只分析当前需求的影响范围。

或者：

请根据当前 git diff 生成符合团队格式的 PR 描述。

如果团队使用 CC Switch，可以在 CC Switch 里统一管理 Prompts，并同步到不同 AI 工具。

27. Hooks 是什么？

Hooks 是“确定性规则”。
AI 有时候会忘记执行某些操作，但 Hook 不会忘。

例如：

• AI 修改文件后自动格式化；
• AI 尝试读取 .env 时阻止；
• AI 完成任务后提醒；
• AI 执行危险命令前拦截；
• AI 修改配置文件时记录日志。

原则：

能用 Hook 固化的规则，不要只写在提示词里。

提示词是“建议 AI 做”。
Hook 是“系统强制做”。

28. 功能开发模板

请按照刚才确认的方案实现。

约束：

1. 只修改和本需求相关的文件；
2. 不要大范围重构；
3. 不要改动公共接口返回结构；
4. 不要读取或修改 `.env`；
5. 不要执行部署命令；
6. 完成后运行 lint 和 test；
7. 最后输出修改摘要和测试结果。

29. Bug 修复模板

请帮我修复这个 bug。

现象：

【描述现象】

复现步骤：

1.
2.
3.

期望结果：

实际结果：

报错信息：

【粘贴报错】

要求：

1. 先定位原因；
2. 说明涉及文件；
3. 给出修复方案；
4. 等我确认后再修改；
5. 修复后补充测试。

30. Code Review 模板

请审查当前 git diff。

重点检查：

1. 是否符合需求；
2. 是否有 bug；
3. 是否有权限问题；
4. 是否有安全风险；
5. 是否有性能问题；
6. 是否有重复代码；
7. 是否缺少测试；
8. 是否影响旧功能；
9. 是否有不该修改的文件；
10. 是否建议合并。

请不要直接修改代码，只输出 Review 意见。

31. 测试补充模板

请为当前改动补充测试。

要求：

1. 先阅读现有测试风格；
2. 不要引入新的测试框架；
3. 覆盖正常路径；
4. 覆盖异常路径；
5. 覆盖权限问题；
6. 覆盖空数据；
7. 测试命名符合项目习惯；
8. 写完后运行测试。

32. 文档生成模板

请根据当前项目代码生成开发文档。

要求：

1. 不要编造不存在的功能；
2. 所有接口以代码为准；
3. 不确定的地方标注“不确定”；
4. 输出 Markdown；
5. 包含启动方式、目录结构、接口说明、开发规范、常见问题。

33. AI 响应错误码

常见原因：

处理方式：

1. 检查 API Key；
2. 检查 DeepSeek 余额；
3. 检查模型名；
4. 检查 Base URL；
5. 检查代理；
6. 降低并发；
7. 换 deepseek-v4-flash 测试；
8. 更新 Claude Code 和 CC Switch。

34. AI 一直请求权限

不要直接开完全绕过权限。
推荐做法：

1. 把安全命令加入 allowlist；
2. 把危险命令加入 denylist；
3. 使用 plan-first；
4. 只允许 lint、test、build、git diff 等低风险命令自动执行；
5. 高风险命令永远人工确认。