Claude code 神器啊！基于 “先问后做” 原则，用它做项目，快一个月几乎没有手动写过代码。从业多年，曾无数次想象过行业的发展，就是未曾想到过，编程工具如今发展到如此智能的地步，感觉 AI 已经快速走在解放人类双手的路上了。
尽管 AI 发展迅速，它也会像人一样犯错：修复一个 bug，却引入几个新 bug，但是只要你输入的需求文档思路清晰，实现步骤有条理，阐述逻辑严谨，cc 就会实现得非常好。
cc 支持接入不同厂商的大模型，而模型之间的解决问题能力往往天差地别。所以条件允许的话，请务必选用最好的大模型，最好的大模型，最好的大模型 …… 重要的事情说三遍！！！
Claude code（后面简称 cc）
1. Claude code
Claude Code 是一个由 AI 驱动的编码助手，可帮助你构建功能、修复错误和自动化开发任务。它理解你的整个代码库，可以跨多个文件和工具工作以完成任务。它是一个由 AI 驱动的编码助手，可帮助你构建功能、修复错误和自动化开发任务。它理解你的整个代码库，可以跨多个文件和工具工作以完成任务。
2. 初体验
2.1. 优点
cc 在处理复杂工程问题时优势显著。其核心在于能理解跨文件、跨模块的代码逻辑，从全局视角分析问题并设计方案。
- cc 能快速分析大型项目并生成文档，方便新成员快速接手。
- cc 从 0 到 1 实现项目的速度和代码质量，相较传统手写代码有指数级提升。
- cc 能根据用户输入描述快速定位并解决项目中的问题。
- cc 擅长解决复杂问题。曾遇到一个加密解密兼容性问题，将终端和服务端代码提供给 cc 分析后发现：特定数据长度下填充算法会出现异常，而常规测试数据恰好避开了这个场景。经过半天的交互调试，最终彻底解决了这个隐藏极深的问题。
- cc 它是研发神器不假，但是如果你只局限于研发，你实在太小看它了，但凡你要干偷懒提效的活，你都应该第一时间想到它。
- 用 AI 编码还有一个好处，只要逻辑没问题，语法错误率极低，避免了团队因为良莠不齐，代码质量下降；还能有效避免某些杠精找茬（都是 AI 写的~）。
2.2. 缺点
- cc 在处理简单、直观的任务时，有时反而显得 “过度设计” 或效率不高。
- cc 目前尚未解决长记忆问题，也受限于算力，无法深入到复杂项目的每个细节。关键字不够准确时，便难以精准解决问题，有时在改一个问题时，发现另一个问题，它不一定会帮你修改或提醒你。
- 大部分 AI 工具都有奴性（例如豆包），不同程度上讨好使用者，cc 也不能免俗。即便使用者输入的思路不够准确，它也可能会一条路走到黑，直到你自己发现这条路是错的，再给它正确的引导。
- AI 工具是把双刃剑。有的朋友还会问：使用了 cc 是不是自己完全不用熟悉代码了？不是！目前最好的 AI 工具面对复杂交互的业务逻辑，往往会顾此失彼。有的朋友已经重度依赖 AI 工具了，甚至一行代码都不需要手写。一旦脱离工具，他们会对项目代码非常陌生。遇到紧急问题而 AI 又解决不了时，往往会无从下手。所以你不能做甩手掌柜，即便你不写，也得 review 它交付的结果。
尽管它还有不少缺点，它依然比古法手搓代码强大得多，仍然是我们工作提效的神兵利器！
3. 使用
3.1. 科学上网
国内须要使用梯子科学上网，才能确保 cc 不受地域限制，而且这样才能更好地使用海外先进大模型。
最好固定一个地区的代理，否则你将会很快收到账号被 封禁 的消息。
3.2. 安装
cc 有多种安装方式：终端安装过程十分简洁，而通过 VSCode 安装 cc 的插件扩展交互体验更好。
1
2
# 官方一键安装脚本
sudo curl -fsSL https://claude.AI/install.sh | bash
3.3. 常用命令
cc 提供了丰富的内置命令，掌握它们能显著提升使用效率。最常用的是 init 和 compact。
3.3.1. 项目初始化与探索
1
2
3
4
5
# 初始化项目，让 cc 了解当前工作目录的结构
/init
# 详细探索项目架构，分析关键文件
/init --detailed
/init 命令会让 cc 扫描当前目录，建立项目上下文。对于大型项目，建议先使用此命令让 AI 助手了解整体架构：
- 在开始复杂任务前先运行
/init - 对于大型项目，可先运行
/init --detailed获取详细分析 - 定期运行
/init更新项目上下文，特别是项目结构发生变化时
3.3.2. 上下文管理
会话上下文很容易超出限制，这个问题相信不少人都遇到过。此时若想在当前会话继续处理，就需要压缩上下文或重新开始。
1
2
# 压缩当前会话的上下文，节省 token 使用
/compact
4. 交互模式
先问后写，这是使用的基本原则，当然学会使用各种 skills 工具，也会让你事半功倍。
4.1. Plan 模式：先规划后实施
对于复杂任务，直接让 cc 开始编码往往效率不高。
事实上，它并没有想象中那么智能，无法直接同步你大脑中的想法。你提供的信息越细致、越精确，它才能越准确地理解并解决你的问题。
正确的做法是先进入 Plan 模式，与 cc 充分探讨，详细规划实现方案，确保它准确理解需求，并给出可行的方案。
乍一看，程序员倒有点像产品经理。
不要指望 AI 能帮你考虑完所有的逻辑，往往它在执行过程中会根据实际输出完善一些没发现的问题和逻辑。
4.2. Edit 模式：精准执行修改
通过 Plan 模式确定方案后，即可切换到 Edit 模式，让 cc 具体实施修改。
Edit 模式是 cc 的默认工作模式：每次修改文件前，它都会展示改动的 diff，等你确认后才动手。你可以逐条审查——同意就放行，不满意就当场打回，并告诉它哪里不对。整个过程就像给 AI 做 code review，改动尽在掌控之中。
这种 “走一步、看一步” 的节奏看似繁琐，其实好处不少：
- 每个改动都过你的眼，问题能第一时间发现，不至于跑偏太远才回头。
- 顺便能看清 cc 的解题思路，看它如何拆解问题、修改代码，这本身就是一种学习。
- 发现方向不对可以立即纠偏，及时止损，避免浪费 token。
实践中有两个小技巧：
- 把大任务拆成小步骤，一步一确认，比一次性丢个大需求让它埋头猛改要稳妥得多。
- 确认改动时别无脑按 “yes”，重点看它有没有 “顺手” 改了不该碰的文件——前面提过，cc 有时会自作主张。
当然，如果嫌麻烦跳过 Plan 模式直接执行也未尝不可 —— 前提是需求足够明确。否则，不仅可能浪费 token 和时间，还容易事倍功半，得不偿失。
如果通过 cc 解决生产环境问题，最好使用这种方式，而且为了保证安全，得盯着它的会话实时修改输出内容，发现操作不正确可以马上停止。
4.3. Auto 模式：放手让它干
默认情况下，cc 每次修改文件、执行命令前都会停下来向你确认，安全是安全，但频繁按确认键难免让人烦躁。切换到 Auto（auto-accept）模式后，cc 会自动接受编辑，一口气把活干完，无须你逐条放行。
Auto 模式适合方案已经明确、风险可控的场景：例如批量重命名、格式化调整、按既定方案铺开实现等机械性工作，效率提升立竿见影。
但省心不等于放心。cc 拿到 “免检通行证” 后，一旦跑偏就会一路狂奔，等你回过神来，可能已经改了一堆不该改的文件。所以：
- 重要项目先提交 git，留好后路，改砸了随时回滚。
- 任务跑完别急着收工，diff 一定要亲自 review。
- 涉及删除文件、数据库操作等危险动作，老老实实用回默认模式。
一句话总结三种模式的使用节奏：Plan 模式想清楚，Edit 模式盯着改，Auto 模式放手干 —— 信任逐级放开，风险心中有数。
现在 Anthropic Opus-4.8 模型出来后（体验版），感觉它实在太专业了，我开始嫌 Plan 模式麻烦了，因为暂时没有 token 焦虑，经常放手让它干。
5. 大模型
cc 负责处理与本地环境的交互（读文件、运行命令、管理会话），但所有核心的智力活动——理解复杂需求、分析代码逻辑、规划多步修改、生成高质量代码——完全由背后的大模型完成。
1
2
3
用户输入 → Claude Code（IDE插件/CLI工具） → API调用 → 大模型（Anthropic/DeepSeek等）
↑ ↓
└──────────────── 返回结果 ←──────────────────────────┘
-
模型强：能解决复杂的架构重构、跨文件疑难 Bug。
-
模型弱：可能连简单的代码生成都会出错，甚至无法理解指令。
所以接入顶尖模型（如 opus-4.8）和普通模型时，它的 “智商” 表现天差地别。
一分钱一分货，有条件的朋友，建议优先选用 cc 官方大模型 —— Opus 4.8（或 Fable）。订阅 Max 套餐（5 倍额度，约 $100/月），基本可以满足日常研发需求，不会陷入 token 焦虑。
当然，如果你对成本比较敏感，且问题本身不复杂，或者不愿意付费上班便宜 Boss，也可以考虑国内性价比更高的模型，按需交替使用即可。
老实说，Anthropic 对中国用户并不友好，各种限制层出不穷。而 DeepSeek V4 发布后，搭配 cc 使用，效果看起来好像也挺不错～
- Opus - 4.8 模型。
- Claude code 支持 DeepSeek V4 pro 模型，配置：
1
2
3
4
5
6
7
8
9
10
11
12
13
{
"claudeCode.environmentVariables": [
{
"name": "ANTHROPIC_BASE_URL",
"value": "https://api.deepseek.com/anthropic"
},
{
"name": "ANTHROPIC_AUTH_TOKEN",
"value": "sk-test-key"
}
],
"claudeCode.selectedModel": "deepseek-v4-pro",
}
6. skills
skill 本质是一份「规范文档」，告诉 cc 按约定的方式做事。不用自己手写，跟 cc 说清楚需求，让它生成并保存到项目的 .claude/skills 目录即可，后续复用。
例如让 cc 帮忙 commit：第一次先让它梳理标准的提交规范并写成 skill，之后每次让它提交都会自动照此执行，整理出来的提交信息往往比自己手搓规范得不要不要的。
这只是举例，编码过程中需要什么约束，都可以让它沉淀成 skill。
- skill
- 规范后的提交效果
7. token
做大事最重要的三件事：钱！钱！钱！token 对于我们来说就是钱。
用 /usage 命令可查看用量概览，重点关注占比高的部分：
- 长上下文最耗 token：不要在一个会话里堆积多个不相关问题，及时用
/compact压缩历史，切换话题用/clear清空。 - 按需选模型：不同模型能力和收费差异大，简单任务用轻量模型，复杂问题再上顶级模型，不要一律用最贵的。
学习如何节省 token 是必须掌握的技能，但这是一个漫长过程，熟能生巧；虽然 token 很重要，在避免大头部分的损耗前提下，不要陷入 token 焦虑，应该怎么舒服怎么来。
