了解如何使用 Claude Code 之前，先弄清它是什么：Claude Code 是运行在终端中的编程 Agent，可以检查项目、提出计划、编辑文件和运行获准的命令；Claude.ai 是对话应用，因此两者的操作风险不同。

Anthropic 的设置指南介绍支持的环境、认证方式和网络要求，这些信息可能变化，开始使用时应查看官方页面。［1］通用 AI 安全流程见如何使用 AI：获得实用结果的入门指南；本文说明如何使用 Claude Code，并以只读探索、明确授权、差异检查以及人工控制测试和发布作为安全边界。

关键要点

先在一次性项目或已单独备份的仓库中试用 Claude Code。

从只读探索和书面计划开始。

保留权限提示，逐项检查命令和差异。

自己运行测试，再决定是否可以提交或分享改动。

如何使用 Claude Code 安全地操作项目

Claude.ai 适合对话、文档处理和起草文本。Claude Code 从终端运行，并可以使用本地项目上下文。它还可以通过 CLI 参数以非交互方式调用，或与工具集成，因此权限和运行环境尤其重要。［2］

不要因为 Claude.ai 中某个帐户、地区、模型或功能可用，就推断 Claude Code 也一定可用。请分别查看你要使用的产品界面的当前访问和认证要求。

第 1 步：准备安全的测试项目

第一次不要把 Agent 指向生产环境、用户主目录、包含密钥的仓库，或有未提交用户改动的工作树。创建一个小型 fixture：包含一个源文件、一个测试和一个明确的预期变化。第一次运行时，把它放在 Blog 仓库之外。

启动工具前：

用 pwd 确认当前目录。
检查 git status --short。
确认 .env、凭据、私钥、客户导出数据和构建密钥不存在，或已经明确拒绝访问。
记录预计会触碰的文件和测试。
明确 Agent 不得做什么，例如联网、安装依赖、提交、推送、部署。

不要因为 Agent 能读取文件，就把 API key、密码、令牌、私有证书、客户数据或完整的机密代码库粘贴给它。Anthropic 的当前 FAQ 会说明本地项目处理方式和权限控制，但具体帐户与组织政策仍需单独确认。［3］

第 2 步：从官方来源安装并认证

按照 Anthropic 当前的入门说明操作。文档可能推荐包管理器或其他受支持的安装方式；不要不看官方页面，就照搬博客中的旧命令。避免使用 sudo npm install -g，并把凭据放在受支持的凭据存储中。

如果指南推荐诊断命令，安装后运行它。确认会话使用的是哪个帐户和服务提供方。不要把 API key 直接放进提示词、Shell 历史、Markdown 文件或截图。

第 3 步：先做只读探索

进入 fixture 目录，提出一个不会修改它的问题：

解释这个小项目。指出入口、校验规则、已有测试和假设。不要编辑文件、运行网络命令、安装依赖或创建提交。告诉我下一步会检查什么。

阅读回答，然后自己与文件对照。Agent 可能误解入口，或漏掉生成文件。这个只读步骤还可以验证工作目录和工具权限是否符合预期。

这个来自 Anthropic VS Code 指南的官方英文界面示例，展示了针对选中代码的只读问题；它不能证明会话处于计划模式，也不能证明 Blog 仓库已被读取。

第 4 步：提出一个边界明确的改动

理解项目之后，再提出带验收条件的小改动：

为 src/validate.js 中空用户名添加校验。保留现有错误格式。更新或添加最小相关测试。不要修改依赖、公共 API、无关文件或 Git 历史。编辑前先展示计划和准备触碰的文件。

一个好的任务有明确目标、范围有限的文件集合、测试条件和排除项。第一次不要把重构、升级依赖、全局格式化和新功能合并在一起。

第 5 步：审核权限和差异

学习阶段保留默认权限提示。计划模式适合在编辑前讨论方案，但它不会让危险命令变安全。逐项审核每次文件编辑和命令：

路径是否在预期的 fixture 内？
命令是在读取、写入、删除、安装还是连接网络服务？
通配符是否可能扩展到目标之外？
差异是否保留了原有 API、错误处理和安全检查？
Agent 是否意外触碰了生成文件、锁文件、配置或密钥？

不要用 --dangerously-skip-permissions 作为捷径。权限请求不清楚时拒绝，并让 Agent 解释更安全的替代方案。MCP 工具和外部集成也应像 Shell 命令一样审核，只允许任务所需的具体工具和范围。

这个官方示例展示了拟议的文档字符串差异和明确的 Yes/No 权限选择；它没有展示测试运行，也不代表该改动已获准用于其他仓库。

第 6 步：运行测试、检查工作树并控制外部操作

让 Agent 先提出测试命令，然后在运行前检查。优先运行确定性强的本地测试。命令完成后：

阅读退出状态和相关输出。
如果结果会影响发布或安全决定，自己再运行一次测试。
检查 git diff --check 和 git diff。
运行 git status --short，确认文件列表。
检查新依赖、生成物、日志或密钥。
覆盖正常情况、边界情况和失败情况。

绿色测试只说明被测行为通过，不代表 Agent 理解了全部业务规则。影响认证、权限、支付、数据保留、迁移、并发或生产路径的改动，应交给人工负责人审核。

让 Git 和外部操作由人控制

你可以让 Claude Code 解释提交或准备补丁，但提交、推送、拉取请求、部署、数据库迁移和发消息仍应遵循正常的人工审核流程。Agent 不应从“完成这个任务”这类模糊要求中推断授权。

如果工作树已经有用户改动，不要让 Agent 清理、重置、变基或丢弃它们。保存已知快照，在隔离分支或 fixture 中工作，并在交接前检查准确差异。

使用 Claude Code 时最常出现哪些问题？

Agent 读取了错误目录

停止并检查 pwd、仓库根目录和文件列表。不要因为解释听起来合理，就继续使用错误项目的结果。

Agent 提出范围很大的重构

拒绝计划，重新说明最小行为变化、目标文件、测试和排除项。范围大的差异更难审核，也更容易被误批准。

命令请求联网或更高权限

只有在依赖、目标和必要性都明确且获准时才允许。不要为了让命令成功而泄露密钥。

测试通过但行为不正确

为实际不变量增加验收测试，检查差异并重新对照需求。要求一个反例，而不是继续接受自信的解释。

Claude Code 不可用

分别检查受支持的位置、帐户认证、服务提供方配置和网络要求。VPN 只能帮助测试获准的网络路径问题，不能授予帐户、模型、计费或功能资格。可参考Claude 无法在所在地区使用？排查方法。

交接结果时要重新确认权限边界

Agent 会话结束不代表审核结束。交接补丁前，记录 fixture 或仓库路径、准确的变更文件、运行过的命令、通过的测试，以及无法执行的检查。也要列出新生成的文件、依赖变化、警告和可能影响下一次运行的假设。

把已批准的差异与 Agent 对话分开保存。对话可以解释意图，但可复现的证据是文件和命令输出。如果把补丁复制到另一个工作树，要重新检查目标分支、状态、忽略文件、权限和密钥，不要假定第一个环境的边界会自动跟过去。

如果 fixture 太接近生产环境就停下来

如果任务需要生产凭据、客户数据、部署权限、破坏性命令或宽泛的网络许可，就回到一次性项目。真实的 fixture 应该展示要测试的行为，却不应携带你正在避免的实际后果。

如果 Agent 无法解释某条命令为什么需要、会改变什么，以及失败后如何恢复，就不要批准。要求更小的只读检查，或要求它给出更窄的文件计划。默认应保留当前工作树，并把下一项决定说清楚。

要让交接真正有用，应区分事实和建议。记录起始提交或文件快照、预期验收条件，以及实际运行过的命令；不要用 Agent 摘要取代这些证据。如果测试因依赖、平台或凭据不可用而跳过，应明确写出限制，避免下一位审核者把未测试路径误认为已经通过。

分享补丁前，先检查最小相关差异，再检查完整状态。确认忽略文件、临时日志、本地配置和生成输出没有被带到下一个环境。可复现的交接应让另一位人员无需授予 Agent 更广权限，就能审核改动。

如果改动影响认证、权限、付款、数据保留、迁移、并发或生产路径，应把负责人审核加入交接。Agent 可以准备证据和窄补丁，但不应批准后果超出其观察范围的决定。

对于普通改动，同一规则可以很轻量：说明审核者、指向验收测试，并明确下一步是审核、合并、部署还是回滚。把这些行动清楚分开，可以防止“已完成”被误解为更改外部系统的授权。

即使改动很小，也应记录这次交接。隐藏的本地配置或未经测试的恢复路径，可能让安全补丁变成不安全的部署。必须明确下一步是审核、合并、部署还是回滚，不能用 Agent 的摘要代替这个决定。

把被拒绝的权限视为证据的一部分，而不是需要绕开的障碍。记录命令或工具、预期用途、被拒绝的能力，以及更窄的替代方案。不要反复改写同一个联网、写入、删除或提权请求，直到提示看起来无害。如果只读命令可以回答问题，就使用它；否则应停止，把未解决的决定交给控制该边界的人。

对于每条获准且可能改变状态的命令，应在执行前定义恢复方法。识别它可能影响的文件、服务、数据库或远程对象；决定如何发现部分完成；并确认回滚不依赖同一个缺失凭据或故障路径。执行后直接验证目标状态，不要只依赖 Agent 摘要或退出码。

交接中应把被拒绝和已批准的行动分开。后续审核者必须能看出：本地测试已经通过，但部署、迁移、网络调用或生产回读从未获准。这样可以避免不完整的验证边界被转述成完整结果。

总结

Claude Code 在项目边界和权限边界清楚时最有用。先在隔离 fixture 中只读探索，再规划小改动，审核每项权限和差异，运行测试，并让 Git 与生产操作保持人工控制。

Anthropic 的数据保留说明属于帐户和政策边界，与本文介绍的本地权限提示是两件需要分别审核的事情。［4］

常见问题

Claude Code 和 Claude.ai 一样吗？

不一样。它们有关联，但界面和能力不同。Claude Code 运行在终端中，并可以与本地项目交互。

可以让 Claude Code 修改生产仓库吗？

不要把这当作默认做法。应使用安全工作树、最小权限、备份、审核和正常发布流程。生产凭据和密钥不应暴露给编程 Agent。

每个任务都应该使用 Claude Code 计划模式吗？

当范围、文件集合、权限或风险不明显时，使用计划模式。即使没有正式的计划模式，也应在编辑前要求 Agent 先写计划。

Claude Code 可以提交或打开拉取请求吗？

它可能支持 Git 工作流，但技术能力不等于授权。提交、审核、推送和部署批准应留在团队流程中。

测试成功能证明补丁安全吗？

不能。测试结果只覆盖运行过的情况。权限、依赖、密钥、副作用和未测试的失败路径仍需单独审核。

免责声明：本文仅作一般信息，不构成法律、财务、就业或专业建议。运行命令前请先审核。

来源：

Anthropic — Set up Claude Code — https://docs.anthropic.com/en/docs/claude-code/getting-started
Anthropic — CLI reference — https://docs.anthropic.com/en/docs/claude-code/cli-usage
Claude Help Center — Claude Code user FAQ — https://support.claude.com/en/articles/14554922-claude-code-user-faq
Anthropic — Data retention practices for covered models — https://support.claude.com/en/articles/15425996-data-retention-practices-for-covered-models

Sources checked 2026 年 8 月 23 日。

延伸阅读：

如何使用 Claude Code：从只读探索到差异审核的安全入门