Claude Code 使用指南

Claude Code 是基于终端的 Agent 工作流工具，本页介绍其核心使用方式和与 Cursor 的配合场景。了解 Claude Code 的工作原理，有助于在合适的任务中选择它作为补充工具。

如果说 Cursor 的主场是编辑器，Claude Code 的主场就是终端。你不是把一段代码贴给模型，让它回答怎么改；而是在项目目录里启动一个 Agent，让它自己读文件、搜索代码、执行命令、编辑文件，再根据执行结果继续推进。

这一点很关键。Claude Code 不只是“Claude 的命令行版本”。来自 Claude Code v2.1.88 源码研究的信息显示，它内部有持续的 Agent Loop：用户输入目标之后，模型会思考下一步、调用工具、观察结果，再决定是否继续。文件读取、编辑、搜索、Bash 执行、MCP 工具、上下文压缩、CLAUDE.md 记忆，都不是临时拼出来的脚本，而是围绕终端编程任务设计的一套系统。

它和 Cursor 的区别

Cursor 更适合你盯着代码改。你能看到当前文件、选中一段代码、比较 diff、顺手改掉不满意的地方。写一个组件、重构一个 hook、解释一个调用链、修复某个 TypeScript 报错，Cursor 的交互会更贴近 IDE。

Claude Code 更适合把任务放到命令行里跑。比如“找出这个仓库测试失败的原因并修复”“把一批脚本从旧参数迁到新参数”“检查这个服务启动失败的日志并改配置”。这些任务不一定需要你一直盯着某个文件，它们更依赖搜索、执行、观察输出和继续调整。

一个简单判断是：如果你会不断打开文件、选中代码、手动微调，用 Cursor；如果你会不断跑命令、看日志、让工具跨目录找线索，可以考虑 Claude Code。

基本上手方式

安装和登录方式以官方文档为准，不建议在教程里记死某个命令或版本号。实际使用时，一般是在项目根目录启动 Claude Code，然后用自然语言描述任务。

第一次使用可以从低风险任务开始：

请先只阅读这个项目，不要修改文件。帮我解释前端页面从登录到请求用户信息的调用链，并指出相关文件。

这个提示有两个好处。第一，它限制了文件写入，适合建立信任。第二，它让 Claude Code 先展示自己如何探索项目：它会搜索文件、阅读代码、整理路径。你可以观察它的工作方式，再决定是否让它进入修改阶段。

当你准备让它改代码时，把目标、边界和验证方式说清楚：

请修复 npm test 中 user-service 相关测试失败的问题。
只修改 src/services/user 和对应测试文件，不要改公共测试配置。
修复后运行相关测试，并总结你改了哪些文件。

这类提示比“帮我修一下测试”更可靠，因为它给出了文件边界和验收标准。

权限、边界和危险操作

终端 Agent 能力越强，越要重视权限。来自 Claude Code v2.1.88 源码研究的信息显示，它的 Bash 工具不是简单透传命令，而是有命令分析、危险操作检测、权限分类和沙箱判断等安全逻辑。你可以把它理解成几道闸门：有些操作可以直接执行，有些需要询问，有些会被拒绝或要求额外确认。

这并不意味着你可以放松审查。真正安全的做法是先给边界：

• 指定可以修改的目录，例如“只改 docs/vibe-coding/tools/”。
• 明确不能做的动作，例如“不要提交 git，不要删除文件，不要改依赖版本”。
• 对高风险任务先让它计划，再确认执行。
• 修改完成后查看 diff，而不是只看它的文字总结。

危险操作不只包括 rm -rf。批量替换、迁移配置、升级依赖、重写测试快照，都可能造成大范围变化。遇到这类任务，最好先要求它列出计划和将修改的文件，再继续。

上下文管理

Claude Code 可以读取项目文件，也可以通过记忆文件保存长期规则。根据 v2.1.88 源码研究，CLAUDE.md 会被作为项目或用户级记忆参与提示词构建；系统还包含自动上下文压缩相关模块，用于在长对话中保留关键信息。

写给 Claude Code 的项目规则不需要很长。一个有效的 CLAUDE.md 通常包含这些信息：

# Project Rules

- This is a VitePress documentation site.
- Do not edit files outside docs/ unless explicitly asked.
- Prefer concise Chinese prose and avoid marketing-style wording.
- After editing Markdown files, check for obvious broken links or placeholders.

这类规则不会替你审查结果，但能减少反复提醒。对于课程站、文档站、脚手架项目，项目级规则尤其有用，因为写作风格和文件边界往往比单次 prompt 更稳定。

和 Cursor 搭配

比较舒服的搭配方式是：Claude Code 负责探索和执行偏终端的任务，Cursor 负责审阅和继续精修。

例如你要处理一次文档目录调整。可以先让 Claude Code 找出所有旧链接、批量改路径、运行构建检查；然后回到 Cursor，看 diff 是否符合内容结构，手动调整个别段落的语气。反过来也可以：先在 Cursor 里制定方案，复制给 Claude Code 去跑命令和验证。

不要同时让两个工具改同一批文件。尤其是一个 Agent 在终端里运行时，你又在 Cursor 里手动大改相同文件，很容易产生互相覆盖。更稳的做法是按阶段交接：一个工具改完并总结，再由另一个工具接手。

一个适合 Claude Code 的任务例子

假设你有一个 Node.js 项目，CI 里 pnpm test 失败，但本地不知道从哪里查。可以这样发起：

请调查 `pnpm test` 失败原因。
先运行测试并阅读失败日志。
如果需要修改，只允许改 `src/auth/` 和 `tests/auth/`。
不要提交 git。
修复后重新运行与 auth 相关的测试，并告诉我还有哪些风险。

Claude Code 的价值在于它可以把“运行测试 -> 读日志 -> 定位文件 -> 修改 -> 再运行”的循环连起来。你要做的是控制范围、审查 diff、决定是否接受改动。

如果任务是设计一个新页面的交互文案、精修一段 Markdown、或在复杂组件里逐行比较视觉细节，我仍然会优先用 Cursor。终端 Agent 很强，但并不适合所有开发动作。