我们以 “项目”很多时候就可以先理解成一个单独的文件夹。 实际使用里，最常见的就是两种情况：已有仓库怎么开始，手上还没有现成项目时怎么开始。两种情况的起点其实一样，都是先把 Claude 放进一个单独整理好的文件夹里。 Claude Code 现在能接的渠道已经不少了，大体可以分成三类： 第一次配置时，建议优先选文档清楚、模型名和额度规则都写明白的渠道。 用 这里不追求一次把所有模型都接好，先把一套确定能用的配置建起来就够了。 操作时就按这几个字段填： 模型名建议直接保持清楚、稳定： 真正容易配错的，通常不是按钮，而是下面这三个值没有对应好： 这里最需要看清的是最后一列。 如果前面的图形界面已经配好，这一步主要是排查问题时，确认 Claude Code 最终读到的值，不是每次都要手改文件。 这两行最重要的意思只有两件事：先把 Claude Code 的配置文件夹建出来，再把配置文件打开。 很多配置问题，最后都不是出在“是不是用了 Claude Code 官方把 配置写完之后，直接启动 Claude Code： 进入会话之后，先确认两件事： Claude Code 的会话、上下文、git 状态和文件范围，都和启动目录直接相关。 如果平时不怎么用终端，可以先把“目录”和“文件夹”当成一回事。 文件夹越干净，Claude 越容易看准当前任务；无关文件越多，会话越容易跑偏。 对入门使用来说，进入项目目录，基本就可以理解成先把当前任务放进一个单独的文件夹里，再在这个文件夹里启动 Claude Code。 这几种开始方式都不合适： 问题通常会出在这三个地方： 更合适的做法是： 第一次碰到 比如： 它的意思就是： 官方 quickstart 也把“进入项目目录再启动 如果手上已经有仓库，进入会话前可以先看一下当前位置： 如果上面这三条命令暂时看不懂，也没关系，先记住最小动作就够了： 只要这三步没错，后面大多数问题都会少很多。 已有项目时，最常见的一组开始命令就是下面这样： 这 4 行命令分别对应下面 4 个动作： 这里最关键的其实不是 如果 进入会话之后，不急着让 Claude 改代码，先让它把项目看清楚。 第一轮可以直接这样问： 第一轮主要看三件事： 项目稍微大一点时，再加一条： 这个命令更适合拿来看上下文占用情况，判断会话是不是已经装得太满。 项目结构确认下来之后，再交第一个小任务。比如： 有了这一步，再进入改动任务就会稳很多： Claude Code 日常最有价值的地方，往往不是一上来做“大重构”，而是按下面这个顺序一步一步做： 手上没有现成仓库，也不要在随便一个空目录里直接开跑。 最小 demo 可以这样起： 如果手上处理的不只是编程任务，而是写文章、整理资料、做内容素材、跑一点小脚本，这个思路也完全一样。先单独建一个文件夹，再在这个文件夹里开 Claude。项目不一定等于“代码仓库”，很多时候它就是“这一轮工作专属的那个文件夹”。 进入会话后，可以这样交代： 或者： 这种场景里，任务拆小一点会更清楚：先建最小骨架，再让 Claude 解释目录结构，最后再加一个小功能。 当前项目如果确实还要读别的目录，再加： 这个命令适合主项目已经确定，只是临时再读一个额外目录。 Claude Code 的命令不少，但真正值得先记住的，是下面这些常用命令。记不住时先用 它适合做的事情是： 连续协作用 比较清楚的顺序就是： 如果发现模型、主题、输出风格或其他会话设置不对，就进一次 这组命令放到一起看，比单独记一个 它的前提一直都是：主文件夹已经选对了。 比如： 这一组不一定是第一天就天天用，但代表性很强。 这一组平时不一定最常用，但很有代表性。 输入 文件夹范围会直接影响 Claude Code 的判断。项目目录单独分开、Git 先初始化、需要时再加额外目录，后面的读取、修改和会话恢复才会更清楚。 Claude 会把启动目录当成当前工作空间。 对新人来说，先看一件事就够了：这一轮工作有没有一个单独的文件夹。 哪怕只是临时 demo，也尽量先 可以把 Git 想成这个文件夹的“操作记录本”。 monorepo 场景尤其容易乱。 比如： 共享配置、外部脚本、相邻仓库确实可能会用到，但那是补充动作，不是默认的开始方式。 顺序不要反过来。 如果一个目录里同时塞源码、截图、下载包、日志和临时脚本，Claude 看到的上下文也会跟着变乱。 比较稳的整理方式是： 这些看起来像本地文件习惯，实际直接影响 Claude Code 会不会把项目看准。 如果把上面的内容缩成一组最基本的动作，顺序就是下面这样： 第一次接触终端时，先记住这一条就够了： 进入会话之后： 下一次再打开 Claude，还是按同样的顺序走：进文件夹、看状态、先看项目、再交一个范围明确的小任务。
cc-switch 配一套 kimi-k2.5 的工作配置为例，把 Claude Code 最常用的几步走一遍：模型怎么接，项目从哪里进，命令怎么用，文件夹该怎么管。
如果手上做的是代码仓库，这个文件夹里放的是代码；如果手上做的是写作、资料整理、脚本试验、数据清洗，这个文件夹里放的也可以是文档、截图、表格和脚本。Claude Code 看到的不是“抽象项目”，而是“当前打开的这个文件夹里都有什么”。
1. 模型配置要配到能检查、能确认
非官方中转方案不是不能用，但不确定因素太多，模型对应关系、兼容方式和限额规则混在一起，排查起来会很费时间。
具体可用模型、套餐和接入方式，以各家官方当期页面为准。cc-switch 配置时，通常先选供应商，再进入具体配置页。1.1 在
cc-switch 里建一套可用 profile
base_urlapi keykimi-k2.5kimi-k2.5cc-switch 的价值，不在于“它比官方更高级”，而在于本机有多条接入方式时，它能把切换动作放到同一个地方。请求地址、密钥、API 格式和模型名，都要在这里一项一项填对。
1.2 配置时，三个关键值要一一对上
只要 base_url、api key、model 里有一个没对上，后面看到的报错往往并不直观。1.3 看一下 Claude Code 本地到底读到了什么
官方常规写法通常是 ANTHROPIC_API_KEY；某些兼容网关或中转层会改用 ANTHROPIC_AUTH_TOKEN，具体以对应接入文档为准。mkdir -p ~/.claude
nano ~/.claude/settings.json{
"env": {
"ANTHROPIC_API_KEY": "YOUR_API_KEY",
"ANTHROPIC_BASE_URL": "YOUR_BASE_URL",
"ANTHROPIC_MODEL": "kimi-k2.5"
}
}cc-switch”，而是 Claude Code 本地读到的值和原来想填的不一致。
如果某个兼容网关文档明确要求自定义 Authorization 头，再把 ANTHROPIC_API_KEY 换成该文档要求的字段，不要把一种写法当成所有渠道的通用答案。settings.json 当成正式配置文件，而且按作用范围分成了 User、Project、Local 三层：~/.claude/settings.json 管跨项目个人配置，.claude/settings.json 管团队共享配置，.claude/settings.local.json 管当前仓库的本地覆盖。
模型接入如果只是个人机器上的配置，通常先写在 User 这一层；项目里需要共享权限、hooks 或插件时，再写到 Project 这一层。1.4 进入会话核验模型和状态
claude/model/status/model 用来确认当前会话到底落在哪个模型上，/status 用来看版本、账户和连接状态。
这两条都对得上，后面的命令和任务才有意义。截图里已经能看到 kimi-k2.5 出现在模型列表中，说明前面的接入已经生效。
2. 启动时所在的目录，就是 Claude 看到的项目范围
站在哪个目录里启动，Claude 看到的“项目”就是什么。
终端里常说的 目录，在 Finder 里看到的就是 文件夹。
已经有现成文件夹，就直接进入；还没有，就先新建一个。cd ~
claudecd ~/Downloads
claudecd /
claude
cd 时，可以先把它理解成一句话：cd 的意思，就是“切换到另一个文件夹”cd claude-demo
“从当前所在的位置，走进名叫 claude-demo 的那个文件夹。”claude”写成了标准动作。
这一步看起来普通，但它决定了后面所有文件读取、上下文理解和 Git 操作的范围。pwd
git rev-parse --show-toplevel
git statusgit rev-parse --show-toplevel 返回的目录和目标仓库一致，再启动 claude。
claude
3. 我们以已有仓库为例走一遍完整过程
git clone <repo-url>
cd <repo-name>
git status
claude
git clone <repo-url>
意思是把远程仓库下载到本地，变成自己电脑上的一个文件夹cd <repo-name>
意思是走进刚刚下载下来的那个文件夹git status
意思是看一眼这个文件夹现在是不是一个正常的 Git 项目claude
意思是在这个文件夹里启动 Claude Codegit clone，而是中间那句 cd <repo-name>。
少了这一步，就很容易出现“仓库已经下载下来了，但 Claude 其实没有在那个仓库里工作”的情况。git clone、git status、分支、提交这些动作现在还不熟，也不用一次全吃完。
这里先把 Git 当成两样东西来用：项目范围 和 改动记录。这篇先把这两个作用用熟，分支、提交和回退会在后面的 Git 文章里单独展开。
如果一上来就直接说“帮我改这里”，Claude 很可能还没搞清楚文件夹里都有什么，做出来的判断就会飘。看一遍这个项目，告诉我它是做什么的。把目录结构和主要文件讲清楚。如果要改认证相关逻辑，应该从哪些文件开始看？
/context定位登录流程里提交表单的位置，把前端到接口的调用链列出来。找一下这个仓库里哪里在处理鉴权失败，只列相关文件和职责。把登录表单的空值校验补上，改完后说明改了哪些文件。跑一下相关测试；如果失败，再继续修。
4. 没有现成项目时，也要先把目录和 Git 建好
mkdir claude-demo
cd claude-demo
git init
claude
mkdir claude-demo
新建一个叫 claude-demo 的文件夹cd claude-demo
进入这个新文件夹git init
让这个文件夹从一开始就有清楚的项目范围claude
在这个文件夹里启动 Claude Codegit init 这一步最好不要省。哪怕只是临时 demo，有了版本记录，后面看 diff、回看改动、做小实验都会方便很多。用 Node.js 和 pnpm 建一个最小项目，只保留能跑起来的 hello world。帮我建一个最小的 Python CLI demo，目录结构清楚一点。
如果一开始就把“项目初始化 + 技术栈选择 + 全套功能”塞进一句话里，空目录里的会话很容易越说越散。/add-dir ../shared-lib
它不是用来补救“启动时站错目录”的。
5. 常用命令要放回实际场景里看
/help，需要集中改设置时再回到 /config。
5.1
claude 和 claude -p，一个负责长会话，一个负责快查询claude 是最常用的启动命令。
只要我们已经站在正确的项目目录里，绝大多数真实任务都从这里开始。在当前这个文件夹里，把 Claude Code 打开
claude -p 适合一次性查询。
如果只是想快速看一下、问一下、总结一下，它比起一整段长会话更轻：claude -p "解释一下当前目录这个仓库是做什么的"cat build-error.txt | claude -p "简要解释这个报错的根因"git diff --name-only | claude -p "按文件类型帮我把这些改动分组"claude，一次性处理用 claude -p。5.2
/model、/status，负责确认“现在到底连的是谁”/model 解决的是“当前会话到底在用哪个模型”。
模型切换完，如果不看一眼，很容易出现配置已经改了，但当前会话还没按预期生效。/status 解决的是“当前这次会话的运行状态对不对”。
版本、账户、连接异常，很多时候都能先在这里看出来。
claude/model/status/config，不要带着错误配置继续往下做。5.3
claude -c、claude -r、/resume、/rewind，负责继续和回退claude -c 适合继续当前目录最近的一次会话。
如果我们刚刚中断了终端，或者切出去做了别的事，又想接着干，直接用它最省事。claude -cclaude -r "<session>" 更适合同时处理多个任务。
同一台机器上同时跑几个项目时，按会话名或 ID 恢复会更清楚，不容易串。claude -r "web-auth-fix"/resume 是交互式恢复旧会话。
如果不想在命令行里记会话名，直接在 Claude Code 里选旧会话就行。/resume/rewind 用来回退。
上下文已经聊偏了、刚才那轮改动不满意、或者想撤回到更早的检查点，这个命令就会很有用。/rewind/resume 更容易理解：
Claude Code 不只是“开一轮新对话”，它本身就带着持续工作和回退的能力。5.4
/context、/add-dir、/clear，负责把会话范围管住/context 用来看当前上下文占了多少空间。
项目大一点、会话长一点时，这个命令很有用，因为它能提醒我们：会话是不是已经快装满了。/context/add-dir <path> 用来再加一个目录。
这个命令适合主项目已经确定，但当前任务还需要顺手读取一个共享库、脚本目录或相邻仓库。/add-dir ../shared-lib/clear 用来清空当前会话。
如果一个会话里已经混进太多旧需求、旧问题、旧文件路径，继续聊下去只会越来越散，这时候直接清掉，通常比硬拽回来更省事。/clear5.5
/init、/memory、/plugin、/mcp，负责把 Claude 用得更完整/init 用来给项目初始化 CLAUDE.md。
如果仓库第一次接入 Claude Code，这个命令很值得跑一次，因为它会把构建命令、测试方式和项目约定先整理出一个起点。/init/memory 用来查看和编辑记忆。
规则和长期上下文不是只能靠嘴说，它们也有专门的管理命令。/memory/plugin 和 /mcp 则代表扩展能力。
前者更像装插件，后者更像连接外部服务。浏览器、数据库、团队工具、额外 skills，很多都从这里连进来。/plugin
/mcp5.6
/login、/permissions、/doctor、/cost，负责认证、权限和排障/login 解决的是账户认证。
登录失效、权限变化、切账户时，第一反应就该想到它。/login/permissions 解决的是“老在批准同样的命令怎么办”。
如果某类命令已经反复确认过，就可以回到这里统一配置。/permissions/doctor 解决的是环境排障。
安装没问题、命令却不工作时，这个命令往往比来回猜快得多。/doctor/cost 解决的是长期使用的成本感知。
真正开始经常用 Claude Code 后，费用和上下文消耗就不再是抽象问题了。/cost5.7 输入
/ 时，命令列表会直接展开/ 之后，Claude Code 会直接把当前可用的内置命令和技能列出来。
平时记不住命令名，也不用硬背，调出列表再选就够了。
6. 文件和项目管理，重点看这五条
1. 一个项目，一个明确目录
项目范围不清，后面的读文件、改文件、看 Git 状态都会跟着变糊。
如果有，Claude 看到的范围就比较清楚；如果没有，Claude 很容易把下载目录、桌面文件、旧截图、旧脚本一起算进去。2. git 要早于 Claude
git init。
Claude Code 很多好用的地方，都建立在“当前目录是一个范围清楚的项目”这个前提上。
有了它，后面改了什么、改坏了什么、哪些文件动过，都会更容易追。3. 在项目根启动，在提示里缩小范围
更合适的方式，不是直接钻进很深的子目录启动，而是在仓库根目录启动，再把当前只处理哪一部分说清楚。当前只看 apps/web，不动 packages 下的共享库。4. 额外目录用
/add-dir
先把主文件夹选对，再补别的目录；不要一开始就让 Claude 面对一大堆混在一起的文件夹。5. 临时文件和代码仓库分开
7. 最短路径
# 1. 进入项目
git clone <repo-url>
cd <repo-name>
# 2. 看目录范围
git status
git rev-parse --show-toplevel
# 3. 启动 Claude Code
claude
不要在乱糟糟的大目录里直接开 Claude，要先进入那个专门为当前任务准备的文件夹。/model/status看一遍这个项目，告诉我主要文件、目录结构和最值得先理解的几个模块。定位登录流程相关文件，只列路径并说明它们各管什么。把登录表单的空值校验补上，改完后说明改了哪些文件，再跑相关测试。
把这几个动作做熟，日常使用就会清楚很多。参考资料
本文来自转载微信公众号-凌小添 ，不代表发现AI立场，如若转载，请联系原作者；如有侵权，请联系编辑删除。
