我几乎一整天都泡在终端里最近这几个月 Claude Code 基本成了我写代码的默认入口。每天敲得最多的不是 git 也不是 vim而是一串串发给 Claude 的指令。用得时间长了我把平时高频使用的指令慢慢沉淀成一份清单前后整理出 100 条。今天这篇就把这份清单摊开来讲哪些是管会话的哪些是管上下文的哪些是让 AI 帮你改代码、查 bug、做 code review 的每条指令在使用场景上有什么区别顺带把容易踩的坑也一起写出来。内容不算什么高深理论都是实打实每天会用到的东西新手可以直接照着抄老手也可以拿去做自查。1. 为什么我把 Claude Code 的指令整理成 100 条1.1 先想清楚你要的是命令还是工作流很多人第一次接触 Claude Code喜欢把它当成一个神奇的自动写代码机器人上来就丢一句写个登录功能然后等着奇迹发生。结果往往是 Claude 生成了几百行代码但里面的命名风格、项目分层、错误处理全都不对改起来比从头写还痛苦。问题不在模型而在指令方式。Claude Code 本质上是一个住在终端里的结对程序员它本身有很强的基础能力但你得用指令告诉它三件事你是谁、你要什么东西、输出成什么样子。我把这些指令分成两类一类是内置的斜杠命令和命令行参数比如 /clear、claude --continue它们控制工具本身的行为另一类是提示模板比如先读文件再改代码按照 Conventional Commits 写提交信息这类话术本质上是你在跟 Claude 约定工作方式。两类都值得整理真正的效率提升来自两者组合。1.2 为什么是 100 条分类逻辑其实很简单整理这 100 条时我参考的是自己一天完整的开发链路早上一进公司要恢复昨天会话、然后面对一个新需求要拆解和编码、写完后要跑测试和 review、接着要处理 Git 提交和分支合并、还要顺手维护文档和排期。对应到指令上就是七大类会话与上下文控制解决Claude 记不记得我们聊到哪了代码生成与编辑解决怎么让它写代码、改代码Git 与工程协作解决代码从本地到分支到 PR 的流转调试与质量保障解决出 bug 时怎么定位和修复架构与重构解决代码越来越乱怎么逐步优化文档与项目管理解决项目知识如何沉淀下来权限、模型与团队配置解决多人协作时怎么共用一套配置这个分类不一定是最完美的但足够把日常命令铺成一个闭环。我特别想说一句不是每条都是内置斜杠命令很多是高频提示模板但它们都值得被当成指令对待因为每条都有明确的输入输出预期。1.3 这份清单到底适合谁如果你是刚接触 Claude Code 的新手这份清单可以直接当成入门手册先把会话控制和代码编辑那两类用熟练就已经能覆盖 80% 的日常需求。如果你已经用了几个星期处于会用但总感觉不够顺手的阶段建议重点看上下文管理、权限配置和团队协作这几章这些通常是你效率提升最大的瓶颈。如果你是技术负责人想带团队统一工具规范那第 3 章的分类速查表和最后那部分关于 settings.json、hooks 的配置可以作为团队公约的底稿。2. 上手前三件事会话控制、上下文管理和项目记忆2.1 会话控制一天要操作几十次的那些命令我先说一个最容易被忽略的事实Claude Code 的对话是有记忆上限的。上下文窗口有限它会记住最近聊的内容但聊久了就会把前面的细节忘掉甚至把旧代码当成最新代码。这个时候会话控制指令就是你的方向盘。最基础的一组# 启动 Claude Code 并恢复最近一次会话 claude --continue # 启动并指定模型 claude --model sonnet # 非交互模式一次性提问适合脚本和 CI claude -p 读取 src/config.ts帮我检查里面所有配置项是否都加了注释交互模式下/status 可以查看当前会话的状态摘要/context 能看到上下文占用情况/compact 会把历史对话压缩成一份摘要释放空间继续对话/clear 则直接清空当前会话。遇到对话开始胡言乱语或者上下文明显占用过高时别硬聊先 /compact不行就 /clear 重开。我自己的习惯是每做完一个小任务就用一次 /compact让上下文保持清爽。这里有个小技巧当你有多个并行需求时不要开一个对话硬塞两个任务而是开两个独立会话用 --resume 按 id 恢复指定会话。否则 Claude 很容易把两个任务的上下文串起来改 A 的时候莫名其妙补全了 B 的代码。2.2 上下文管理让 Claude 真正懂你的项目很多人问为什么 Claude Code 在别人的项目里很好用在自己的项目里像失忆一样每次都要重新介绍项目背景。答案很简单你没给它写记忆文件。Claude Code 启动时会自动加载项目根目录下的 CLAUDE.md以及用户全局目录下的 ~/.claude/CLAUDE.md。这个文件相当于员工手册每次新会话都会自动读取。你可以在里面写项目结构、代码规范、构建命令、测试命令、容易踩的坑甚至团队的命名约定。我随便给个例子# 项目记忆 ## 技术栈 - 前端React 18 TypeScript Vite - 后端Node.js Express Prisma - 测试Vitest ## 常用命令 - 安装依赖npm install - 启动开发服务器npm run dev - 跑测试npm test ## 约定 - API 路径统一用 /api/v1 前缀 - 所有日期字段输出 UTC ISO 格式 - 组件文件使用 PascalCase 命名写好之后每次新会话打开Claude 就不再需要你反复解释「我们项目用的是啥技术栈」「测试命令是什么」这类基础问题它会直接按照手册里的约定输出。写得越具体它做出来的东西越贴你的项目。另外/memory 可以管理记忆文件/init 会扫描项目结构并生成一个初始化的 CLAUDE.md适合新项目快速起手。但记住机器生成的是底稿真正有价值的记忆一定要人工维护尤其是那些文档里没写但踩过的坑。2.3 权限配置给 AI 动手之前先划好边界Claude Code 能执行 Bash 命令、修改文件、调用各种工具这在带来便利的同时也是风险。尤其当你在一个团队项目里一次错误的 rm 或者一次不经意的全局替换可能直接毁掉整个工作区。默认情况下它会在执行敏感操作前向你确认你也可以用配置文件把规则固化下来。项目根目录的 .claude/settings.json 支持这样的写法{ permissions: { allow: [ Bash(git:*), Bash(npm run *), Read, Edit ], deny: [ Bash(rm -rf *), Bash(git push --force) ], additionalDirectories: [ /path/to/shared/packages ] } }allow 里放的是可自动执行的白名单操作deny 里放的是禁止执行的操作。我建议团队项目一定要补上 additionalDirectories不然 Claude 会拒绝访问项目目录之外的文件你在 monorepo 里想读取另一个子包代码时就会频繁被打断。还有一个经常被忽略的启动参数 --permission-modeplan。这个模式会让 Claude 先输出计划并且不真正执行任何改动适合用在新任务开会之前让你先看清楚它打算改哪些文件、怎么改确认之后再切回正常模式。千万不要图省事一开始就加 --dangerously-skip-permissions它等于告诉 AI 你随便折腾我在真实项目里见过一次误删未提交改动代价极其惨痛。3. 100 条常用指令速查表这一章是全文的干货主干。我按七大类整理每一条都可以直接复制使用。需要先说清楚的是带 / 开头的是 Claude Code 内置命令不带 / 的是高频提示模板。表格里的用途写的是我最常用到的场景你可以按自己习惯调整措辞。3.1 会话与上下文15 条会话类指令管的是对话怎么开、怎么续、怎么清理。这个分类用好了Claude 就是记忆力稳定的老同事用不好就是聊五分钟就失忆的临时工。序号指令 / 模板用途1/help查看内置命令帮助2/status查看当前任务上下文摘要3/context查看上下文占用情况4/compact压缩历史对话释放上下文空间5/clear清空当前会话6/resume恢复指定历史会话7/rewind回滚到之前的对话节点8/init初始化项目记忆文件9/memory管理记忆文件内容10/model切换当前模型11/cost查看本次会话 token 开销12/permissions查看当前权限配置13/agents查看和管理 subagent14/mcp查看和管理 MCP 工具15claude --continue命令行恢复最近会话这里面我想重点提醒两个/context 和 /rewind。/context 是预感失控前一定要看的仪表盘数值一旦接近窗口上限就该考虑压缩。而 /rewind 是救命功能比如 Claude 在执行过程中改坏了一组文件你又没开版本控制可以通过它回退到改动之前的对话状态。当然治本方案还是用 Git。3.2 代码生成与编辑20 条这是日常使用频率最高的一组。核心思路是把模糊的帮我改一下替换成精确的改什么文件、什么位置、什么约束、输出什么格式。序号指令 / 模板用途16/edit按描述修改指定文件17先阅读相关文件再给出改动计划让 Claude 先理解代码再动手18只修改 xx 函数不要动其他逻辑限制改动范围19输出最小 diff避免大段无关改动20给出三种实现方案选最优让 Claude 先比较再实施21为代码补注释解释设计意图提高代码可读性22为这个模块补充单测正常、边界、异常生成完整测试用例23用 mock 替换外部依赖不要真实发送请求安全测试24把这个大函数拆成小函数并保持行为不变重构辅助25为接口补充类型定义类型完善26新增命令入口并校验参数编写 CLI 功能27在关键路径补日志可观测性优化28按项目既有代码风格重写风格统一29生成可执行的示例命令和文档交付可复现示例30增加错误处理和 fallback提升健壮性31检查这个文件的安全风险代码审查32将重复代码抽成公共函数消除重复33修改 API 示例并同步 README文档同步34先列影响范围再实施改动风险控制35拒绝模糊需求要求我补充输入防止 AI 瞎猜第 19 条“输出最小 diff”是我觉得最容易被忽略的。默认情况下 Claude 有自己偏好的代码风格它改一个函数时可能顺手把周边几行格式化一起改了导致 diff 里全是无关噪音。明确要求最小 diff之后它会收敛很多。另外第 35 条很有意思当 Claude 发现需求描述不够清晰时让它主动反问而不是自己编一个方案。这能节省大量来回返工的时间。3.3 Git 与工程协作15 条Claude Code 不是单纯写代码的工具它在 Git 工作流里同样能帮你省大量时间。但凡是涉及提交、回滚、合并的地方我建议先让 Claude 做只读分析确认方案后再让它执行写操作。序号指令 / 模板用途36生成符合 Conventional Commits 的提交信息统一提交规范37将当前未提交改动拆分成多个 commit一个功能一个提交38解决冲突保留双方语义合并冲突处理39回滚最近一次提交保留工作区改动撤销又不丢代码40生成当前分支变更摘要快速了解改动全貌41扫描即将提交的内容检查敏感信息防密钥泄露42分析两个分支差异并给出合并建议合并前评审43创建新分支并切换到它分支管理44清理已合并分支仓库整洁45重写最近一条 commit message修正提交信息46把大文件拆分到新模块并更新引用模块化改造47写 PR 描述改动原因、影响、测试方式提交流程48生成 changelog版本发布49检查 CI 失败原因并修复快速救火50帮我 rebase 并解决冲突分支同步第 41 条值得多说一句Claude 可以帮你扫描即将提交的内容是否包含 access key、token、内网地址等敏感信息这比人眼 review 认真得多。我们团队有一段时间把这段模板固化在提交前的检查环节里确实拦截过几次真实事故。3.4 调试与质量保障15 条调试阶段的指令核心是让 Claude 从写完就跑切换到异常时帮我找到问题根源。我常用的方式是把错误堆栈完整粘贴进去然后用第 52 条让它先做根因分析再动手改。序号指令 / 模板用途51/review代码审查52给出错误堆栈定位根因精确排错53先写最小复现用例可复现问题54写临时脚本来验证假设快速验证55检查内存泄漏高风险位置性能排查56用二分法找出最近破坏性提交定位回归57给测试失败补充断言完善测试58检查异步竞态并发问题59分析 SQL 索引和执行计划数据库优化60检查依赖安全漏洞供应链安全61分析构建产物体积包体优化62生成性能压测脚本压测准备63检查并发安全并发隐患64修完 bug 后补回归测试防止复发65还原现场写清楚复现步骤bug 报告我最常用的是 /review 和 52 条。Claude 的 code review 有时候比人更细能抓到未处理的 null、递归没有出口、类型断言太随意这类问题。不过注意它的审查结论不一定全对落地前还是要人工判断。3.5 架构与重构10 条重构类任务是我认为最需要先规划再执行的场景。直接让 Claude 重写一个大模块风险极高先让它输出依赖关系、识别问题、给出迁移路径然后分步骤执行才是正确姿势。序号指令 / 模板用途66梳理模块依赖输出依赖关系架构可视化67识别重复代码并提出合并方案去重68先设计接口契约再实现接口先行69规划目录结构并迁移结构调整70用依赖注入替代硬编码解耦71评估表结构是否需要拆分数据模型72把同步任务改为异步队列异步化73给热路径加缓存并设计失效策略性能优化74找出 O(n²) 循环并优化算法优化75做架构评审风险、收益、迁移步骤整体评审第 66 条特别有用。当你接手一个陌生项目时让 Claude 把后端模块依赖梳理成文字描述你就能很快知道 service 层有多少循环引用、controller 是不是全都堆在了一个文件里。这个信息比读 1000 行代码来得快得多。3.6 文档与项目管理10 条文档这类任务我已经习惯性丢给 Claude。写文档的难点从来不是文笔而是信息是否准确。Claude 能读代码、能看历史改动因此生成的文档更贴近实际实现前提是你给它足够的上下文。序号指令 / 模板用途76为模块写设计文档技术方案沉淀77更新 README 的快速开始文档维护78生成迭代 todo 列表任务拆解79根据本周改动写周报汇报生成80为 API 生成 OpenAPI 描述接口文档81整理技术债清单债务管理82写新同学 Onboarding 文档团队建设83根据代码变化更新注释注释同步84汇总项目命令集合工具文档85输出一份上线检查清单发布保障第 85 条我是每次发版前必用的。让 Claude 根据项目结构生成一份上线检查清单包含数据库迁移、环境变量、缓存清理、健康检查、回滚方案等比自己拍脑袋想全面得多可以直接作为发版 checklist 的初稿。3.7 权限、模型与团队配置15 条最后一组偏工程化配置。单人使用可能只需要前几条但一旦进入团队协作这些配置就是统一工具行为的核心。序号指令 / 模板用途86--allowedToolsBash,Edit限制工具范围87--permission-modeplan先规划后执行88--dangerously-skip-permissions跳过全部权限确认慎用89settings.json 中的 additionalDirectories允许访问额外目录90hooks 的 PostToolUse 审计记录工具调用91ANTHROPIC_API_KEY 环境变量配置密钥92ANTHROPIC_MODEL 默认模型指定模型93ANTHROPIC_BASE_URL 兼容网关接入第三方 API 端点94claude config set 全局配置设置全局参数95仓库级 CLAUDE.md项目级记忆96全局级 ~/.claude/CLAUDE.md个人级记忆97自定义 slash command自制快捷指令98Skills 目录加载项目技能99MCP server接入外部数据源100.claude/settings.json 团队配置团队默认配置第 97 条自定义 slash command 是我最近才玩明白的。你可以在 .claude/commands 里创建自定义命令文件比如 docs.md、review.md把长提示词保存成短命令团队共用一套减少重复输入。第 90 条 hooks 适合在团队里做审计每次 Claude 执行 Bash 或改文件时把操作记录写到日志确保任何自动操作都可追溯。4. 一天的实际工作流从需求到提交4.1 早上开工先恢复上下文我每天打开终端的第一条命令永远是 claude --continue。恢复之后先不发需求而是先看 Claude 输出的昨日会话摘要如果摘要有明显偏差就补充一句补充一下昨天下午最后改的是 xx 模块今天继续从这个状态开始。这步花 30 秒能避免它基于错误记忆开工。如果你需要在多个任务之间切换不要只靠一个会话。我会给每个需求开独立会话命名就按需求来比如feat-user-list。这样当我在另一个任务里忙了一上午切回来时用 --resume feat-user-list 就能精准恢复现场不会互相污染上下文。4.2 一个需求从理解到落地的完整指令链我拿一个常见场景举例要给前端加一个用户分页列表后端接口已经存在。我的完整指令链大概是这样的第一步先读 src/pages/UserList.tsx 和 src/api/user.ts 说说当前实现结构以及这个页面改动会影响哪些组件。 第二步新增一个 UserCard 组件props 定义好类型 展示用户名、邮箱、注册时间时间用相对时间格式。 第三步在 UserList.tsx 中接入分页 每页 10 条空状态、加载状态、错误状态都要覆盖 保持现有样式变量不引入新的 UI 库。 第四步为 UserCard 写单测覆盖正常渲染、空数据、邮箱超长三种情况。 第五步运行 npm run test UserList失败的话自己迭代到全部通过。注意看每一步都有明确的输入范围、输出目标和验证方式而不是一句帮我改一下用户列表。Claude 拿到这种指令大概率能一次做对即使有偏差也是局部问题。如果一上来就丢一句写分页它可能在不知道你后端返回值结构的情况下自己发明一套字段后面全白干。4.3 收尾审查、提交、记录代码写完后我会用 /review 做一轮自查然后让它运行测试并给出失败摘要。测试通过后让它生成符合 Conventional Commits 的提交信息我确认无误再 git commit。提交之后顺手让它更新 CLAUDE.md记录这次页面的分页逻辑约定这样下次接手的人就不会再重复踩坑。整个流程下来Claude 承担了理解需求、编码、测试、审查、提交信息生成、记忆维护这些重复性工作我只需要把握方向和做最终决策。这个模式下一个中小型需求的开发时间大约能压缩一半以上。5. 常见问题与避坑指南5.1 指令看着对但结果不对的排查路径遇到 Claude 输出明显偏离预期时我的排查顺序很固定。第一步看它有没有真正读相关文件很多错误是它没看到代码就凭常识给你写了一段这时在指令里明确加先读 src 下的 xxx 文件再动手就好。第二步看它是不是没有遵循某个约束比如你没指定不要引入新依赖它就默认装了一个包解决方式是提前把约束写进 CLAUDE.md。第三步考虑上下文污染如果同一个会话里聊了太多任务直接 /clear 开新会话把需求重新完整描述一遍往往立刻就正常了。这条排查路径还能总结成一条经验Claude Code 的表现很大程度上取决于你给它多少确定信息。它不是一个能猜透所有隐含条件的工具而是一个需要你不断把隐性知识显性化的助手。5.2 上下文爆掉与任务失忆怎么办很多人的体感是Claude 聊到后面越来越蠢。这不一定是模型问题而是上下文窗口快满了压缩或截断导致早期信息丢失。遇到这种情况先 /context 看占用然后 /compact。如果压缩完还是不行就把当前进展和待办事项写到 CLAUDE.md 或临时文档里然后 /clear再让 Claude 读文档继续。这个过程就是把短期上下文固化成长效记忆。如果你做一个大型重构任务我的建议是拆阶段每个阶段单独开会话。第一阶段让 Claude 输出全量迁移计划和文件清单第二阶段只让它改一个子模块第三个阶段再验证集成。不要在同一个对话里连续做 3 个小时的重构那样后期它的状态下大概率会开始漏改。5.3 团队协作与安全权限、审计和敏感信息团队场景里我最关心的永远是权限和审计。没有权限约束的 Claude Code 在共享仓库里等同于拿着一把刀乱跑。我的建议是至少做到三件事第一个.claude/settings.json 提交到仓库团队统一禁止危险命令第二个开启 hooks 审计把工具调用日志输出到固定文件第三个提交前强制扫描敏感信息。我自己团队里有一次事故很有代表性。有人让 Claude 修改数据库连接配置结果它顺手把生产环境的连接串信息写进了日志文件如果不是提交前扫描拦截这个信息就进 Git 历史了。从那以后第 41 条“扫描即将提交的内容检查敏感信息”成了我们的硬性要求。5.4 第三方模型和兼容网关的适配经验很多人不满足于 Claude 默认提供的模型希望接自己团队已部署的模型或统一 API 网关。这个在 Claude Code 里是可行的核心思路是设置 ANTHROPIC_BASE_URL 指向兼容的 API 端点再配置 ANTHROPIC_MODEL 指定模型名称。团队里如果有统一网关也可以把这套环境变量写进 .claude/settings.json让所有新人都拿到一致的配置。但这里我有一个明确的提醒不管接什么模型都要先做小范围验证。不同模型的指令遵循能力、代码生成风格、上下文处理方式都有差异可能同一个提示词在 A 模型上完美运行到 B 模型上就开始断章取义。我自己的经验是接入非官方网关时把指令写得更加显式尤其是先读文件再改不要引入新依赖这类约束性内容尽量放在指令最前面减少被忽略的概率。我个人在实际操作中还有个很小的习惯每天下班前总会花两分钟用 claude -p 把当天完成的内容整理成几条要点贴到项目 TODO 里然后把 CLAUDE.md 里过时的部分顺手更新。别小看这两分钟它保证了我第二天开工时Claude 和我都能从同一个、准确的上下文出发。工具再强也需要你每天花一点点时间维护它的记忆这才是长期高效协作的关键。