本文以 cc-switch 配合 kimi-k2.5 为例，带你走一遍 Claude Code 的完整配置和使用流程。包括模型怎么接入、项目从哪里开始、命令怎么用、文件夹怎么管理。

一、理解 Claude Code 中的"项目"

在 Claude Code 里，"项目"可以理解成一个单独的文件夹。

如果你在做代码开发，这个文件夹里放的是代码。如果你在写文章、整理资料、做脚本实验或数据清洗，这个文件夹里放的也可以是文档、截图、表格和脚本。Claude Code 看到的不是抽象的"项目"概念，而是"当前打开的这个文件夹里都有什么"。

实际使用中，最常见的就是两种情况：已有代码仓库怎么开始，手上还没有现成项目时怎么开始。两种情况的起点其实一样：先把 Claude 放进一个单独整理好的文件夹里。

二、模型配置：以 kimi-k2.5 为例

2.1 选择合适的渠道

Claude Code 现在能接的渠道不少，大致分三类：

• 有公开文档的渠道：阿里云百炼 Coding Plan、智谱 GLM Coding Plan、MiniMax Token Plan、火山引擎 Coding Plan

• 官方原生路径：Claude 订阅、Anthropic Console、Bedrock、Vertex

• 非官方中转方案

第一次配置时，建议优先选文档清楚、模型名和额度规则都写明白的渠道。非官方中转方案不确定因素多，模型对应关系和限额规则混在一起，排查问题很费时间。

2.2 在 cc-switch 里建一套配置

不用一次把所有模型都接好，先把一套确定能用的配置建起来就行。按这几个字段填：

1. 新建一套给 Claude Code 用的 profile

2. 选择已经开通的渠道

3. 填入对应的 base_url

4. 填入 api key

5. 模型名写成 kimi-k2.5

6. 把这套 profile 设成当前生效配置

cc-switch 的价值不在于它比官方更高级，而在于本机有多条接入方式时，能把切换动作放到同一个地方。请求地址、密钥和模型名，都要一项一项填对。

2.3 三个容易配错的值

真正容易配错的不是按钮，而是下面三个值没有对应好：

只要 base_url、api key、model 里有一个没对上，后面看到的报错往往不直观。

2.4 检查 Claude Code 本地配置

如果图形界面已经配好，这一步主要是排查问题时确认 Claude Code 最终读到的值。

mkdir -p ~/.claude
nano ~/.claude/settings.json

这两行的意思是：先把 Claude Code 的配置文件夹建出来，再把配置文件打开。

{
  "env": {
    "ANTHROPIC_API_KEY": "YOUR_API_KEY",
    "ANTHROPIC_BASE_URL": "YOUR_BASE_URL",
    "ANTHROPIC_MODEL": "kimi-k2.5"
  }
}

很多配置问题，最后都不是出在"是不是用了 cc-switch"，而是 Claude Code 本地读到的值和想填的不一致。

Claude Code 官方把 settings.json 当成正式配置文件，按作用范围分了三层：

• ~/.claude/settings.json：管跨项目个人配置

• .claude/settings.json：管团队共享配置

• .claude/settings.local.json：管当前仓库的本地覆盖

模型接入如果是个人机器上的配置，通常先写在 User 这一层。

2.5 验证模型是否生效

配置写完后，直接启动 Claude Code：

claude

进入会话后，先确认两件事：

/model
/status

/model 用来确认当前会话落在哪个模型上，/status 用来看版本、账户和连接状态。这两条都对得上，后面的命令和任务才有意义。

三、项目目录：Claude 看到的就是启动目录

Claude Code 的会话、上下文、git 状态和文件范围，都和启动目录直接相关。站在哪个目录里启动，Claude 看到的"项目"就是什么。

如果你平时不怎么用终端，可以先把"目录"和"文件夹"当成一回事。终端里说的目录，在 Finder 里看到的就是文件夹。

文件夹越干净，Claude 越容易看准当前任务。无关文件越多，会话越容易跑偏。

3.1 不合适的开始方式

cd ~
claude

cd ~/Downloads
claude

cd /
claude

问题通常出在三个地方：

• 会话里混进大量和当前工作无关的文件

• Git 范围不清楚，很多动作没有项目背景

• 后面加目录、加规则只会越来越乱

3.2 合适的开始方式

• 已有仓库，就进入仓库根目录再启动

• 没有仓库，就建一个干净目录并初始化 git

• 入门阶段，最好让一个 Claude 会话只处理一件明确的事情

cd claude-demo

这句话的意思是：从当前所在的位置，走进名叫 claude-demo 的那个文件夹。

如果手上已经有仓库，进入会话前可以先看一下当前位置：

pwd
git rev-parse --show-toplevel
git status

git rev-parse --show-toplevel 返回的目录和目标仓库一致，再启动 claude。

如果上面这几条命令暂时看不懂，先记住最小动作就够了：

1. 找到准备处理的那个文件夹

2. 进入这个文件夹

3. 在这个文件夹里启动 claude

四、已有仓库：完整操作流程

已有项目时，最常见的一组开始命令如下：

git clone <repo-url>
cd <repo-name>
git status
claude

这 4 行命令分别对应：

1. git clone <repo-url>：把远程仓库下载到本地，变成自己电脑上的一个文件夹

2. cd <repo-name>：走进刚刚下载下来的那个文件夹

3. git status：看一眼这个文件夹现在是不是一个正常的 Git 项目

4. claude：在这个文件夹里启动 Claude Code

这里最关键的其实不是 git clone，而是中间那句 cd <repo-name>。少了这一步，很容易出现"仓库已经下载下来了，但 Claude 其实没有在那个仓库里工作"的情况。

4.1 进入会话后的第一步

进入会话之后，不要急着让 Claude 改代码，先让它把项目看清楚。

第一轮可以直接这样问：

看一遍这个项目，告诉我它是做什么的。把目录结构和主要文件讲清楚。如果要改认证相关逻辑，应该从哪些文件开始看？

第一轮主要看三件事：

• Claude 有没有看对项目类型

• Claude 能不能找到主要文件和关键目录

• Claude 给出的文件路径是不是靠谱

项目稍微大一点时，再加一条：

/context

这个命令适合拿来看上下文占用情况，判断会话是不是已经装得太满。

4.2 从小任务开始

项目结构确认下来之后，再交第一个小任务：

定位登录流程里提交表单的位置，把前端到接口的调用链列出来。

或者：

找一下这个仓库里哪里在处理鉴权失败，只列相关文件和职责。

有了这一步，再进入改动任务就会稳很多：

把登录表单的空值校验补上，改完后说明改了哪些文件。跑一下相关测试，如果失败再继续修。

Claude Code 日常最有价值的地方，往往不是一上来做大重构，而是按这个顺序走：

• 看项目

• 找关键位置

• 定位文件

• 做一个范围明确的小改动

• 检查结果

五、没有现成项目：从零开始

手上没有现成仓库，也不要在随便一个空目录里直接开跑。

最小 demo 可以这样起：

mkdir claude-demo
cd claude-demo
git init
claude

1. mkdir claude-demo：新建一个叫 claude-demo 的文件夹

2. cd claude-demo：进入这个新文件夹

3. git init：让这个文件夹从一开始就有清楚的项目范围

4. claude：在这个文件夹里启动 Claude Code

如果你手上处理的不只是编程任务，而是写文章、整理资料、做内容素材、跑一点小脚本，这个思路也完全一样。先单独建一个文件夹，再在这个文件夹里开 Claude。项目不一定等于代码仓库，很多时候它就是这一轮工作专属的那个文件夹。

git init 这一步最好不要省。哪怕只是临时 demo，有了版本记录，后面看 diff、回看改动、做小实验都会方便很多。

进入会话后，可以这样交代：

用 Node.js 和 pnpm 建一个最小项目，只保留能跑起来的 hello world。

或者：

帮我建一个最小的 Python CLI demo，目录结构清楚一点。

这种场景里，任务拆小一点会更清楚：先建最小骨架，再让 Claude 解释目录结构，最后再加一个小功能。

如果当前项目确实还要读别的目录，可以加：

/add-dir ../shared-lib

这个命令适合主项目已经确定，只是临时再读一个额外目录。它不是用来补救"启动时站错目录"的。

六、常用命令速查

Claude Code 的命令不少，但真正值得先记住的是下面这些。记不住时先用 /help，需要集中改设置时再回到 /config。

6.1 长会话和快查询

claude 是最常用的启动命令。只要站在正确的项目目录里，大多数真实任务都从这里开始。它适合：

• 先看项目结构

• 连续追问同一个问题

• 一边改代码，一边继续补要求

• 改完之后继续让它跑测试、看 diff、解释结果

claude -p 适合一次性查询：

claude -p "解释一下当前目录这个仓库是做什么的"
cat build-error.txt | claude -p "简要解释这个报错的根因"
git diff --name-only | claude -p "按文件类型帮我把这些改动分组"

连续协作用 claude，一次性处理用 claude -p。

6.2 确认当前状态

/model 解决的是"当前会话到底在用哪个模型"。模型切换完，如果不看一眼，很容易出现配置已经改了但当前会话还没按预期生效。

/status 解决的是"当前这次会话的运行状态对不对"。版本、账户、连接异常，很多时候都能先在这里看出来。

推荐的顺序：

1. 配完模型

2. 启动 claude

3. 立刻看 /model

4. 再看 /status

5. 没问题再交任务

6.3 继续和回退

claude -c 适合继续当前目录最近的一次会话。如果刚刚中断了终端，又想接着干，直接用它最省事。

claude -r "<session>" 更适合同时处理多个任务。同一台机器上同时跑几个项目时，按会话名恢复会更清楚。

/resume 是交互式恢复旧会话。如果不想在命令行里记会话名，直接在 Claude Code 里选旧会话就行。

/rewind 用来回退。上下文已经聊偏了、刚才那轮改动不满意、或者想撤回到更早的检查点，这个命令很有用。

6.4 管理会话范围

/context 用来看当前上下文占了多少空间。项目大一点、会话长一点时，这个命令能提醒我们会话是不是已经快装满了。

/add-dir <path> 用来再加一个目录。适合主项目已经确定，但当前任务还需要顺手读取一个共享库或相邻仓库。前提是主文件夹已经选对了。

/clear 用来清空当前会话。如果一个会话里已经混进太多旧需求、旧问题，继续聊下去只会越来越散，这时候直接清掉比硬拽回来更省事。

七、文件管理的五个要点

1. 一个项目，一个明确目录：Claude 会把启动目录当成当前工作空间。项目范围不清，后面的读文件、改文件、看 Git 状态都会跟着变糊。

2. git 要早于 Claude：哪怕只是临时 demo，也尽量先 git init。Claude Code 很多好用的地方，都建立在"当前目录是一个范围清楚的项目"这个前提上。

3. 在项目根启动：monorepo 场景尤其容易乱。更合适的方式不是在很深的子目录启动，而是在仓库根目录启动，再把当前只处理哪一部分说清楚。

4. 额外目录用 /add-dir：共享配置、外部脚本确实可能会用到，但那是补充动作，不是默认的开始方式。先把主文件夹选对，再补别的目录。

5. 临时文件和代码仓库分开：代码仓库只放代码和项目相关文件，截图和日志放到单独目录，演示项目单独建 demo 目录。

八、最短路径

把上面的内容缩成一组最基本的动作：

# 1. 进入项目
git clone <repo-url>
cd <repo-name>

# 2. 看目录范围
git status
git rev-parse --show-toplevel

# 3. 启动 Claude Code
claude

第一次接触终端时，先记住这一条：不要在乱糟糟的大目录里直接开 Claude，要先进入那个专门为当前任务准备的文件夹。

进入会话之后：

/model
/status

然后问 Claude：

看一遍这个项目，告诉我主要文件、目录结构和最值得先理解的几个模块。

接着：

定位登录流程相关文件，只列路径并说明它们各管什么。

最后：

把登录表单的空值校验补上，改完后说明改了哪些文件，再跑相关测试。

下一次再打开 Claude，还是按同样的顺序走：进文件夹、看状态、先看项目、再交一个范围明确的小任务。把这几个动作做熟，日常使用就会清楚很多。

本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！

链接: https://fly63.com/article/detial/13685