第 7 章：终端命令执行

第 5 章和第 6 章分别介绍了对话与代码编辑——Claude Code 通过阅读和分析来理解代码，通过 Edit/Write 工具来修改代码。但实际开发中还有大量工作不是"读文件"或"改文件"能完成的：安装依赖、启动服务、运行构建、执行测试、操作数据库……这些都需要在终端中执行命令。

这就是本章的主题。终端命令执行是 Claude Code 从"代码助手"跃升到"开发 Agent"的关键能力——也是它最强大、同时最危险的能力。

本章目标：理解 Claude Code 如何执行终端命令，掌握中断与重试的技巧，建立危险命令防护意识，并能针对不同环境配置合适的权限策略。

7.1 让 Claude Code 替你运行命令

Bash 工具：Claude Code 的"手"

Claude Code 拥有一套工具系统（Tool System），每个工具负责一类操作。Read 工具负责读取文件，Edit 和 Write 负责修改文件——而 Bash 工具负责在终端中执行命令。

当你向 Claude Code 发出一个需要执行命令的请求时（比如"安装依赖"），它会调用 Bash 工具，在你的项目根目录下运行对应的命令。命令的标准输出（stdout）和标准错误（stderr）都会被捕获，Claude Code 通过读取这些输出来判断命令是否成功执行。

Bash 工具的工作流程：

你的指令 → Claude 分析 → 生成命令 → Bash 工具执行 → 读取输出 → 分析结果 → 向你汇报

Claude Code 如何决定运行命令

Claude Code 不会盲目地运行命令。它的决策过程大致如下：

理解你的意图：你说"帮我跑一下测试"，Claude 会去读 package.json 或项目的配置文件，找到正确的测试命令
检查项目上下文：它会先通过 Read 了解项目结构，而不是凭空猜测命令
生成合适的命令：根据项目类型选择合适的包管理器（pnpm/npm/yarn）、构建工具（vite/webpack）、测试框架（vitest/jest/pytest）
等待你的确认：除非你开启了 Bypass Permissions 模式，否则每个 Bash 调用都会弹出权限确认弹窗

示例：让 Claude Code 安装依赖

帮我用 pnpm 安装项目的依赖

Claude Code 的响应过程：

读取 package.json 确认项目使用 pnpm
生成命令 pnpm install
等待你点击 "Allow" 确认
在终端中执行，实时显示输出
根据输出判断安装是否成功

终端输出面板：实时看到一切

在 VSCode 的 Claude Code 面板中，终端输出区是核心交互区域之一。Claude 执行的每个 Shell 命令都可以展开查看完整输出：

命令执行中：实时滚动显示 stdout/stderr，就像你手动在终端中看到的一样
命令执行后：可以展开查看完整日志，失败的命令会高亮显示
长输出：可以通过滚动条或搜索来快速定位关键信息

这个面板让你不必在 Claude Code 面板和 VSCode 的集成终端之间反复切换——一切发生在同一个界面内。

注意：Claude Code 执行命令的工作目录是项目根目录，不是当前打开文件所在的目录。如果你的命令依赖特定的相对路径，确保路径是相对于项目根目录的。

7.2 常见命令场景

以下是开发中最常见的让 Claude Code 执行命令的场景。每个场景都附带一个可以直接使用的示例指令。

安装依赖

这是 Claude Code 最常运行的命令类型之一。每当你克隆新项目、切换到新分支、或在 package.json 中添加了新包，都需要安装依赖。

帮我安装项目依赖

Claude Code 会自动判断项目使用的包管理器并执行：

pnpm install
npm install
yarn install

更具体的用法：

帮我把 axios 加到项目依赖里，然后安装

Claude Code 会执行 pnpm add axios（或对应的 npm/yarn 命令），一步完成添加和安装。

运行构建

当你修改了代码、更新了配置，需要验证项目能否成功构建时：

帮我跑一下构建，看看有没有错误

Claude Code 会执行 pnpm build，读取构建输出。如果构建失败，它会自动分析错误信息并尝试修复——这正是 7.4 节要详细展开的反馈循环。

针对特定构建工具：

帮我执行 npm run build:prod，看看生产构建有没有问题

执行测试

测试是开发流程的核心环节。Claude Code 可以帮你运行全部测试、某个文件的测试、或某个具体测试用例。

帮我跑一下全部测试，看看哪些没过

帮我运行 src/utils/ 目录下的测试

执行 pytest -k test_user_login -v，把失败的用例信息给我

Claude Code 执行测试后，会总结测试结果：通过数、失败数、以及失败用例的详细错误信息。如果测试失败，它通常会主动分析原因并提出修复方案。

代码检查

代码质量工具（Linter）的输出往往很长，让 Claude Code 帮你运行并筛选关键问题：

运行 eslint src/，帮我列出所有 error 级别的问题

帮我跑一下 cargo clippy，看看有哪些 warning 需要处理

注意：Claude Code 不仅会列出问题，还会主动帮你修复——这是它区别于手动执行 lint 的关键优势。

启动服务

开发服务器是日常工作最常用的命令之一：

启动开发服务器

Claude Code 会执行 pnpm dev 或 npm start。但有一个重要的注意事项：

注意：开发服务器通常是一个持续运行的进程（不会自动退出）。如果通过 Claude Code 启动，它会持续占用对话直到你手动中断（Ctrl+C）。更推荐的做法是自己在终端中启动 dev server，让 Claude Code 专注于它擅长的事情。

一个更好的用法：

帮我检查一下为什么 dev server 启动失败，根据错误日志给我修复方案

然后你自己在终端中启动 dev server，Claude Code 帮你分析和修复问题。

数据库操作

Claude Code 可以执行数据库查询和管理命令：

用 psql 连接到本地数据库，帮我列出所有表的行数

帮我执行这个 SQL 迁移脚本：db/migrations/002_add_user_roles.sql

危险警告：让 Claude Code 操作数据库时，务必先确认命令内容。任何涉及 DROP、DELETE、TRUNCATE 的命令都必须仔细审查。强烈建议在执行前先让 Claude 在只读模式下验证查询逻辑。

文件操作（安全类）

安全的文件操作——创建目录、复制、移动文件——Claude Code 可以放心执行：

帮我在 src/ 下创建 components/、utils/、hooks/ 三个目录

把 src/old-config.ts 复制到 src/config/，然后删除旧文件

注意：涉及 rm、递归删除、批量覆盖的命令会触发危险命令确认。参见 7.5 节。

查看状态

只读状态查询是最安全的 Bash 操作——通常可以配置为无需确认的 allowlist：

查看当前的 git 状态

帮我看看 dist/ 目录有多大

列出 src/components/ 下所有的 .vue 文件

这些命令只读取信息，不修改任何东西，最适合加入权限白名单。

7.3 中断与重试

命令执行并不总是一帆风顺。有时候命令会卡住，有时候 Claude 生成的命令不对，有时候你只是想换一种方式。掌握中断和重试的技巧，能让你保持对执行流程的控制。

如何中断

在 VSCode 中，当 Claude Code 正在执行命令时，你可以通过以下方式中断：

操作	快捷键/方式
快捷键	`Ctrl+C`（在终端输出区聚焦时）
按钮	点击输出面板上的"取消"按钮
全局	`Cmd+Shift+P` → 停止当前任务

按下 Ctrl+C 后，Claude Code 会收到中断信号，正在运行的命令被终止，控制权回到对话中。

什么时候应该中断

不是所有卡住的命令都需要中断。以下是一个判断框架：

情况	是否中断	理由
命令执行超过预期时间（如 npm install 5min）	中断	可能网络问题或依赖冲突
Claude 生成了错误的命令	立即中断	停止浪费时间的操作
命令陷入无限循环	立即中断	消耗资源且不会自行停止
构建/测试正在运行但比较慢	不中断	大型项目构建本就耗时
dev server 正在运行（正常行为）	不中断	dev server 就是持续运行的

中断后：Claude 如何调整

中断命令后，Claude Code 会读取已经产生的输出，然后做两件事：

分析为什么命令需要被中断：如果输出中已经包含错误信息，它会直接定位问题
提出调整方案：修正命令参数、更换策略、或给出手动操作的建议

示例对话：

你：帮我安装依赖
Claude：执行 pnpm install → 卡了 3 分钟不动
你：按 Ctrl+C 中断
Claude：看到输出中有 "request to https://registry.npmjs.org/... timed out"
        → "看起来是网络超时了。我建议换个镜像源再试，要我帮你配置淘宝镜像吗？"
你：好的，帮我配置
Claude：执行 npm config set registry https://registry.npmmirror.com
        → 然后重新执行 pnpm install → 成功

重试策略

当命令失败后，不要盲目让 Claude 重试同样的命令。更有效的做法是：

先分析输出："看看刚才的错误输出，告诉我问题出在哪里"
让 Claude 提出修正方案："基于这个错误，你打算怎么修复？"
确认后再执行：审查修正后的命令，再点击 Allow

# 不好的做法
你：失败了，再试一次
Claude：执行同样的命令 → 同样的错误

# 好的做法
你：分析一下刚才的错误，给我一个修正方案
Claude：读取输出 → "问题是 X。我可以尝试 Y 来解决，需要我执行吗？"
你：好的，执行

7.4 读取命令输出来判断结果

Claude Code 不仅是执行命令——它更重要的能力是理解命令的输出。它读取 stdout 和 stderr，像一个有经验的开发者一样判断：这次执行是成功还是失败？如果失败了，原因是什么？应该如何修复？

Claude 如何"读懂"输出

当一个命令执行完毕，Claude Code 会：

检查退出码：exit code 0 表示成功，非零值表示失败
解析 stderr：错误信息是最重要的信号，Claude 会提取关键的错误文件和行号
分析 stdout：警告信息、构建统计、测试结果——这些虽然不算"错误"，但也包含有价值的信息
匹配已知模式：Claude 见过大量常见错误模式（模块未找到、类型不匹配、语法错误等），能快速匹配

反馈循环：运行 → 读输出 → 修复 → 再运行

这是 Claude Code 终端执行能力中最有价值的部分——自动化的调试循环。

经典流程：构建失败 → 自动修复 → 重新构建

你：项目 build 失败了，帮我找出原因并修复

Claude Code 的完整工作流：

第 1 轮：执行 pnpm build
         ↓ exit code 1，stderr 报告 src/utils.ts:42 有类型错误
第 2 轮：读取 src/utils.ts，分析第 42 行的代码
         ↓ 发现函数参数类型标注不匹配
第 3 轮：用 Edit 工具修改 src/utils.ts
         ↓ 修复类型标注
第 4 轮：重新执行 pnpm build
         ↓ exit code 0，构建成功
第 5 轮：向你汇报
         ✓ "构建成功了！问题是 src/utils.ts 中的 formatUser 函数参数类型标注有误，
            返回类型 `string` 但实际可能返回 `null`。我加了 `| null` 联合类型，构建通过了。"

这个过程完全自动——你只需发出一个指令，Claude Code 完成从诊断到修复到验证的全流程。

另一个例子：测试失败 → 修复代码 → 重新测试

你：pytest 失败了，帮我修
Claude：执行 pytest → 3 个失败
       → 分析每个失败用例的错误信息
       → 逐一修改对应的源代码
       → 重新执行 pytest → 全部通过
       → "3 个失败都修复了。问题分别是：..."

什么时候需要你介入

Claude Code 的自动修复能力很强，但不是万能的。以下情况建议你亲自介入：

多次修复仍失败：Claude 可能陷入了死循环，需要你提供更多上下文或更高层次的指导
涉及业务逻辑的错误：Claude 不了解你的业务规则，它的"修复"可能在技术上是正确的，但逻辑上是错的
错误信息不明确：如果 stderr 只输出了一句模糊的 "something went wrong"，Claude 也抓瞎
涉及第三方服务：API 密钥问题、第三方服务宕机等，Claude 无法解决

7.5 危险命令防护

这是本章最重要的一节。终端的威力有多大，危险性就有多大。一个不加审查的 rm -rf / 可以直接毁掉你的系统，一个错误的 git push --force 可以覆盖团队的工作。

什么是危险命令

危险命令是指那些具有破坏性影响且难以撤销的操作。以下是最常见的危险模式：

危险模式	风险等级	可能后果
`rm -rf`	极高	永久删除文件，不可恢复
`sudo` 开头的任何命令	极高	绕过系统权限，可能影响全局系统
`git push --force`	高	覆盖远程分支历史，队友工作丢失
`git reset --hard`	高	丢弃所有未提交的改动
`DROP TABLE` / `DROP DATABASE`	高	删除数据库表/库，数据不可恢复
`chmod 777`	中高	不安全的权限设置
`curl ... \| bash`	中高	执行来自网络的未经审查的脚本
`docker rm -f`	中	强制删除容器，可能丢失数据
`npm unpublish --force`	中	从注册表中删除包

Claude Code 的权限确认机制

对于任何可能具有破坏性的命令，Claude Code 会弹出权限确认弹窗。弹窗中会显示：

完整的命令内容
命令所属的类别（Bash）
Allow 按钮：批准执行
Deny 按钮：拒绝执行
Always Allow 复选框：将此模式加入白名单

┌─────────────────────────────────────────┐
│  Claude Code 需要权限执行以下命令：       │
│                                         │
│  Bash(rm:-rf:src/old-code/)              │
│                                         │
│  rm -rf src/old-code/                   │
│                                         │
│  [Deny]              [Allow]            │
│  □ 总是允许此模式                        │
└─────────────────────────────────────────┘

原则：对这个弹窗要像对 sudo 密码提示一样认真对待。看不懂的命令，先 Deny，再问。

配置 deny 规则

Claude Code 支持通过 deny 规则来禁止特定模式的命令——无论你是否在 Bypass Permissions 模式下，这些命令都不会被执行。

Deny 规则的优先级高于 allow 规则。如果你的 allow 中包含了 Bash(pnpm:*)，但 deny 中包含了 Bash(rm:-rf:*)，那么 pnpm exec rm -rf ... 仍然会被拦截。

基础配置——在项目 .claude/settings.json 中添加：

json

{
  "permissions": {
    "deny": [
      "Bash(rm:-rf:*)",
      "Bash(sudo:*)",
      "Bash(git:push:--force:*)",
      "Bash(git:reset:--hard:*)",
      "Bash(chmod:777:*)"
    ]
  }
}

更严格的配置：

json

{
  "permissions": {
    "deny": [
      "Bash(rm:-rf:*)",
      "Bash(rm:-r:*)",
      "Bash(sudo:*)",
      "Bash(git:push:--force:*)",
      "Bash(git:reset:--hard:*)",
      "Bash(chmod:777:*)",
      "Bash(curl:*|bash:*)",
      "Bash(wget:*-O-*|bash:*)",
      "Bash(docker:rm:-f:*)",
      "Bash(dropdb:*)",
      "Bash(DROP:*)",
      "Bash(TRUNCATE:*)"
    ]
  }
}

deny 规则语法

规则格式为 ToolName(参数1:参数2:...)，支持通配符 *：

规则	匹配范围
`Bash(rm:-rf:*)`	`rm -rf` 后跟任意参数
`Bash(sudo:*)`	所有以 `sudo` 开头的命令
`Bash(git:push:*)`	所有 git push 操作
`Bash(git:push:--force:*)`	仅 force push
`Bash(curl:\|bash:)`	管道到 bash 的 curl 命令
`Bash(DROP:*)`	所有以 DROP 开头的 SQL 语句

建议：优先使用具体匹配而非宽泛通配符。Bash(git:push:--force:*) 比 Bash(git:*) 更好，因为前者只禁止危险的 force push，不影响正常的 git 操作。

永远不要绕过危险命令的权限

有些开发者为了"方便"，会把所有 deny 规则移除或对危险命令点 "Always Allow"。这是极其危险的做法：

没有 undo：终端命令没有 Ctrl+Z。rm -rf 删除的文件不会进入回收站
连锁反应：一个错误的命令可能触发一系列后果（删除配置文件 → 服务启动失败 → 数据不一致）
Claude 也会犯错：AI 生成的命令可能包含拼写错误、路径错误、或逻辑错误

如果 Claude Code 要执行一个你不确定的命令，最安全的做法是：

点 Deny
在对话中问："你要执行的这个命令具体会做什么？"
仔细阅读解释
如果还有疑虑，自己手动在终端中执行（至少你完全掌控）

7.6 权限配置实战

不同环境有不同的安全需求。本节给出三种典型环境的权限配置模板。

个人开发环境：效率优先，核心防护

个人开发环境中，你通常是唯一的操作者，追求的是"少弹窗、高效率"。但核心安全规则依然不能放松。

json

// .claude/settings.json（个人开发环境）
{
  "permissions": {
    "allow": [
      "Bash(git:status)",
      "Bash(git:diff)",
      "Bash(git:log)",
      "Bash(git:add:*)",
      "Bash(git:commit:*)",
      "Bash(git:branch:*)",
      "Bash(git:checkout:*)",
      "Bash(pnpm:*)",
      "Bash(npm:*)",
      "Bash(node:*)",
      "Bash(npx:*)",
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(mkdir:*)",
      "Bash(cp:*)",
      "Bash(mv:*)",
      "Bash(which:*)",
      "Bash(echo:*)",
      "Read",
      "Write",
      "Edit",
      "WebSearch",
      "WebFetch"
    ],
    "deny": [
      "Bash(rm:-rf:*)",
      "Bash(rm:-r:*)",
      "Bash(sudo:*)",
      "Bash(git:push:--force:*)",
      "Bash(git:reset:--hard:*)",
      "Bash(chmod:777:*)"
    ]
  }
}

策略说明：

allow 范围较宽：常用的包管理器命令、文件操作、Git 操作都默认允许，减少确认弹窗
deny 只拦截真正危险的模式：不会过度影响工作效率
适合单人项目、学习项目、个人博客等场景

团队开发环境：安全优先，可审计

在团队项目中，多个开发者都在同一个仓库上工作。一个人的误操作可能影响所有人。需要更严格的控制。

json

// .claude/settings.json（团队开发环境，提交到 Git）
{
  "permissions": {
    "allow": [
      "Bash(git:status)",
      "Bash(git:diff)",
      "Bash(git:log)",
      "Bash(git:add:*)",
      "Bash(git:commit:*)",
      "Bash(pnpm:test:*)",
      "Bash(pnpm:lint:*)",
      "Bash(pnpm:build)",
      "Bash(pnpm:dev)",
      "Bash(npm:test:*)",
      "Bash(npm:run:lint:*)",
      "Bash(npm:run:build)",
      "Bash(ls:*)",
      "Bash(cat:*)",
      "Bash(mkdir:*)",
      "Read",
      "Write",
      "Edit",
      "WebSearch",
      "WebFetch"
    ],
    "deny": [
      "Bash(rm:-rf:*)",
      "Bash(rm:-r:*)",
      "Bash(sudo:*)",
      "Bash(git:push:--force:*)",
      "Bash(git:push:-f:*)",
      "Bash(git:reset:--hard:*)",
      "Bash(git:branch:-D:*)",
      "Bash(chmod:777:*)",
      "Bash(curl:*|bash:*)",
      "Bash(wget:*|bash:*)",
      "Bash(docker:rm:-f:*)",
      "Bash(dropdb:*)",
      "Bash(DELETE:FROM:*)",
      "Bash(DROP:*)",
      "Bash(TRUNCATE:*)",
      "Bash(shutdown:*)",
      "Bash(reboot:*)",
      "Bash(kill:-9:*)"
    ]
  }
}

策略说明：

allow 范围收窄：只允许已知的安全命令，pnpm install 这样的命令也需要确认
deny 范围扩大：涵盖数据库操作、Docker 强制删除、系统命令等
提交到 Git：确保整个团队遵循相同规则
结合 Git hooks（如 pre-push hook 检查 force push）形成多重防护

CI/CD 环境：允许一切，沙箱隔离

CI/CD 环境中，Claude Code 在隔离的容器或虚拟机中运行，即使执行破坏性命令，影响范围也局限在临时环境内。因此可以采用宽松的权限配置。

json

// .claude/settings.json（CI/CD 环境）
{
  "permissions": {
    "allow": [
      "Bash(*)"
    ],
    "deny": [
      "Bash(sudo:*)",
      "Bash(shutdown:*)",
      "Bash(reboot:*)"
    ]
  }
}

策略说明：

allow 几乎全部放开：CI 环境需要运行各种构建、测试、部署命令
deny 只拦截可能影响宿主机的命令（sudo、shutdown）
前提条件：CI 容器与宿主机之间有严格的隔离，且 CI 环境本身是临时的（用完即销毁）

CI/CD 环境的安全前提：
Claude Code 运行在 Docker 容器或临时虚拟机中
容器没有宿主机的敏感目录挂载
CI 使用的 API Key 只具有项目级的有限权限
CI 环境的数据是临时的，不包含生产数据

7.7 最佳实践

让 Claude 解释命令

在批准任何你不完全理解的命令之前，先问一句：

这个命令会做什么？给我解释一下每个部分的含义。

Claude 会逐部分解释命令，就像这样：

你：你要执行的这个命令会做什么？

Claude：我要执行的是 `find src/ -name "*.test.ts" -exec rm {} \;`

各部分含义：
- `find src/`         在 src/ 目录下搜索
- `-name "*.test.ts"` 匹配所有以 .test.ts 结尾的文件
- `-exec rm {} \;`     对每个匹配的文件执行 rm 删除

⚠️ 这个命令会删除 src/ 下所有的 .test.ts 文件。如果这些测试文件是你需要的，
我建议不要执行。要不要我换一种方式？

先 dry-run，再执行

对于不确定的命令，先让 Claude 展示命令但不执行：

先告诉我你打算执行什么命令，不要运行

Claude 会输出：

我打算执行：
pnpm add -D vitest @vitest/coverage-v8

这个命令会将 vitest 和它的覆盖率工具添加为开发依赖。
需要我执行吗？

Review before Approving

每次弹出权限确认弹窗时，养成一个习惯：读完命令再点 Allow。这个习惯的成本是 2 秒，收益可能是避免数小时的修复工作。

特别留意：

路径是否正确（src/ 还是 ./src？）
参数是否合理（-rf 还是 -r？）
目标文件是否是你期望的（*.test.ts 还是 *.ts？）

为项目配置安全规则

每个项目都应该有一份安全基线。在你的项目根目录 .claude/settings.json 中至少配置以下 deny 规则：

json

{
  "permissions": {
    "deny": [
      "Bash(rm:-rf:*)",
      "Bash(sudo:*)",
      "Bash(git:push:--force:*)",
      "Bash(git:reset:--hard:*)"
    ]
  }
}

这是项目安全的底线——任何项目都不应该缺少这四条规则。

Git 是最佳保险

在让 Claude Code 执行一系列复杂命令之前（尤其是涉及文件修改的命令），先提交当前工作：

先帮我把当前的改动提交一下，然后我们再开始重构

或者自己手动：

bash

git add -A && git commit -m "work in progress: 重构前的安全点"

如果 Claude Code 之后的命令出了问题，你可以随时 git reset --hard 回到这个安全点。Git 是你在 AI 辅助开发时代最可靠的"撤销"按钮。

注意工作目录

Claude Code 的 Bash 工具在项目根目录执行命令，不是当前文件所在目录。这意味着：

# 如果你在 src/components/Button.vue 文件中工作，
# Claude 执行 ls 时看到的是项目根目录的内容，不是 components 目录

做法：

让 Claude Code 使用绝对路径或明确的相对路径（相对于项目根目录）
如果命令需要在特定目录下执行，明确告诉 Claude："在 src/components/ 目录下执行..."
不确定路径时，先让 Claude Code 执行 ls 或 pwd 确认

不要在 Claude Code 中运行长期服务

开发服务器（dev server）、数据库服务、Docker 容器——这些应该在你的终端中启动，而不是通过 Claude Code。原因：

Claude Code 的对话是线性的：命令不退出，对话就无法继续
你通常需要 dev server 持续运行几小时，而 Claude Code 的一次对话很难维持那么久
如果要重启服务，通过 Claude Code 操作远不如自己按 Ctrl+C 再按上箭头来得快

Claude Code 适合执行有明确终点的任务：安装依赖、运行测试、执行构建、代码检查——这些命令运行完毕后自动退出，Claude 继续读输出、分析结果。

7.8 本章小结

本章覆盖了 Claude Code 终端命令执行的完整知识体系：

Bash 工具是 Claude Code 在终端中执行命令的核心机制，它让 Claude 从"能读能写"升级到"能运行"
常见命令场景覆盖了安装依赖、运行构建、执行测试、代码检查、启动服务、数据库操作、文件操作、查看状态——几乎涵盖日常开发的所有终端操作
中断与重试：Ctrl+C 让你保持对执行流程的控制，中断后的分析比盲目重试更重要
反馈循环（运行 → 读输出 → 修复 → 再运行）是 Claude Code 最强大的能力——自动从错误中学习并修复
危险命令防护是本章最重要的主题。rm -rf、sudo、git push --force 等命令必须通过 deny 规则加以限制，永远不要为了一时方便而绕过安全防护
权限配置实战：个人开发环境追求效率，团队环境追求安全，CI/CD 环境依赖沙箱隔离——不同场景需要不同的策略
最佳实践：让 Claude 解释命令、先 dry-run、审查弹窗、配置安全规则、Git 保险点、注意工作目录——这些都是保护你工作的习惯

核心原则：信任 Claude Code 的能力，但永远保持对终端命令的审查和掌控。Claude Code 是你的副驾驶，不是你的自动驾驶——方向盘始终在你手中。

下一步：第 8 章将介绍 Claude Code 的 Git 集成——如何让 Claude Code 帮你管理版本控制、撰写 commit message、以及处理分支工作流。

第 7 章：终端命令执行 ​

7.1 让 Claude Code 替你运行命令 ​

Bash 工具：Claude Code 的"手" ​

Claude Code 如何决定运行命令 ​

终端输出面板：实时看到一切 ​

7.2 常见命令场景 ​

安装依赖 ​

运行构建 ​

执行测试 ​

代码检查 ​

启动服务 ​

数据库操作 ​

文件操作（安全类） ​

查看状态 ​

7.3 中断与重试 ​

如何中断 ​

什么时候应该中断 ​

中断后：Claude 如何调整 ​

重试策略 ​

7.4 读取命令输出来判断结果 ​

Claude 如何"读懂"输出 ​

反馈循环：运行 → 读输出 → 修复 → 再运行 ​

什么时候需要你介入 ​

7.5 危险命令防护 ​

什么是危险命令 ​

Claude Code 的权限确认机制 ​

配置 deny 规则 ​

deny 规则语法 ​

永远不要绕过危险命令的权限 ​

7.6 权限配置实战 ​

个人开发环境：效率优先，核心防护 ​

团队开发环境：安全优先，可审计 ​

CI/CD 环境：允许一切，沙箱隔离 ​

7.7 最佳实践 ​

让 Claude 解释命令 ​

先 dry-run，再执行 ​

Review before Approving ​

为项目配置安全规则 ​

Git 是最佳保险 ​

注意工作目录 ​

不要在 Claude Code 中运行长期服务 ​

7.8 本章小结 ​

第 7 章：终端命令执行

7.1 让 Claude Code 替你运行命令

Bash 工具：Claude Code 的"手"

Claude Code 如何决定运行命令

终端输出面板：实时看到一切

7.2 常见命令场景

安装依赖

运行构建

执行测试

代码检查

启动服务

数据库操作

文件操作（安全类）

查看状态

7.3 中断与重试

如何中断

什么时候应该中断

中断后：Claude 如何调整

重试策略

7.4 读取命令输出来判断结果

Claude 如何"读懂"输出

反馈循环：运行 → 读输出 → 修复 → 再运行

什么时候需要你介入

7.5 危险命令防护

什么是危险命令

Claude Code 的权限确认机制

配置 deny 规则

deny 规则语法

永远不要绕过危险命令的权限

7.6 权限配置实战

个人开发环境：效率优先，核心防护

团队开发环境：安全优先，可审计

CI/CD 环境：允许一切，沙箱隔离

7.7 最佳实践

让 Claude 解释命令

先 dry-run，再执行

Review before Approving

为项目配置安全规则

Git 是最佳保险

注意工作目录

不要在 Claude Code 中运行长期服务

7.8 本章小结