我用Claude Code写了30天代码，总结了这10条血泪教训
上周三凌晨两点，我的CI pipeline炸了。
不是那种"跑一下就好了"的小问题——是17个test case集体挂掉，而本地跑得好好的。我盯着那个红色的failed看了大概10秒钟，然后打开终端敲了一行命令：
claude "17个测试在CI上全挂了但本地正常，帮我看看GitHub Actions日志找到根因"
然后我就去泡咖啡了。等我回来，它已经：读了workflow配置文件，发现是CI环境的Node版本和本地不一致，改了.nvmrc，提交了修复，还顺手把CI配置加了Node版本校验。
push，green。
那一刻我突然意识到——这玩意跟我之前用的所有AI编程助手都不一样。
先说说Claude Code到底是个啥
Claude Code是Anthropic出品的命令行AI编程工具。你不需要打开IDE，不需要拖拽窗口，就在终端里跑。它能读你的整个代码仓库，改文件，跑命令，甚至帮你发PR。
安装就一行：
# macOS / Linux
curl -fsSL https://claude.ai/install.sh | bash
# 或者用npm
npm install -g @anthropic-ai/claude-code
# Windows (PowerShell)
irm https://claude.ai/install.ps1 | iex
装完之后cd到你的项目目录，敲claude，就进去了。
说真的，一开始我是拒绝的。一个命令行的AI编程工具？我Cursor用得好好的，为什么要换？但后来发生了一件事改变了我的想法——
我接手了一个8000多行的Python legacy项目。没有文档，原作者已经离职，变量名是那种tmp1、tmp2、data_final_v3_real的风格。Cursor的补全在这种项目面前基本废了，因为它看不到全局。而Claude Code直接扫描了整个项目，花了大概40秒理解了调用链，然后告诉我："这个data_final_v3_real其实是用户行为日志的聚合结果，上游在etl/pipeline.py的第247行"。
那一刻我服了。
教训1：CLAUDE.md不是可选的，是必需的
我第一周完全没用CLAUDE.md。结果就是——每次新对话，Claude都要重新理解项目结构，反复问一样的问题。浪费了大量token和时间。
CLAUDE.md就是Claude Code的"项目记忆"。你把项目约定、技术栈、代码规范写在里面，它每次启动都会自动读取。
后来我学乖了，花了一个下午整理出了这么一个模板：
# 项目：xxx
## 技术栈
- 后端：Python 3.11 + FastAPI + SQLAlchemy
- 前端：React 18 + TypeScript + TanStack Query
- 数据库：PostgreSQL 15
## 开发命令
- 启动后端：`cd backend && poetry run uvicorn main:app --reload`
- 启动前端：`cd frontend && npm run dev`
- 跑测试：`pytest tests/ -xvs`
- lint：`ruff check .`
## 代码规范
- 用ruff做linting和formatting
- 所有API endpoint必须有类型标注
- commit message用Conventional Commits格式
## 已知坑
- 本地PostgreSQL要用15版本，14的JSONB查询行为不同
- 不要动`legacy/`目录下的代码，那是有专人维护的
核心原则：不要写大段文档，写Claude容易犯错的点。 一个好的CLAUDE.md不是面面俱到的手册，而是一份"避坑指南"。
有个细节很多人忽略了——CLAUDE.md要控制在200行以内，大约2000个token。太长了反而会让Claude的注意力被稀释，什么都看等于什么都不看。
教训2：Plan Mode是你的好朋友（但我一开始不知道）
Claude Code有两种模式：正常模式和Plan Mode（按Shift+Tab切换）。
我头两周压根不知道有Plan Mode这回事。每次上来就让它改代码，改完发现方向错了，回退，重新来。浪费了不知道多少时间。
后来我在Reddit上看到一个哥们说"complex task without plan mode is like driving blindfolded"，我才开始用。
Plan Mode的核心思路是：先让Claude思考，不要急着动手。
实际操作：
- 进Plan Mode
- 告诉它："我要给用户系统加一个邮箱验证功能，先别写代码，给我讲讲你的实现思路"
- 它会分析现有代码，提出2-3个方案，列优缺点
- 你选一个方案，它再细化
- 退出Plan Mode，让它执行
这个过程看起来多了一步，但实际上能避免70%的返工。尤其当你在一个不熟悉的项目里工作时，让Claude先"逛逛"代码库再做决定，效果完全不一样。
对了，你可以用"think"、"think hard"、"think harder"来控制它的思考深度。遇到复杂的架构决策，来一个"think harder about this"，你会发现它的分析质量明显上了一个台阶。
教训3：Context窗口不是无限的，学会/clear
Claude Code有200K token的上下文窗口。听起来很大对吧？
我之前做了一个重构任务，从上午10点一直聊到下午3点。到后面Claude开始"精神错乱"——忘记之前的约定，改了刚改过的代码，甚至开始建议我删掉它两小时前刚写的函数。
原因很简单：上下文被撑爆了。
200K token听起来多，但一个中等项目光文件内容就能吃掉一半。再加上对话历史，很容易就满了。
解决方案很暴力但很有效：
- 当你感觉Claude开始"忘事"了，或者你看到context usage超过60%，直接
/clear - 但清之前，让它先把当前进度写到一个markdown文件里（比如
PROGRESS.md） - clear之后，开新会话，让它先读
PROGRESS.md再继续
有人说用/compact也行。但我的经验是——/compact的压缩质量不稳定，有时候会丢关键信息。直接/clear + 文档化是最靠谱的做法。
教训4：模型选择——不要所有活都用Opus
Claude Code支持多个模型：
| 模型 | 输入价格/MTok | 输出价格/MTok | 适合场景 |
|---|---|---|---|
| Haiku | $1 | $5 | 快速探索、简单任务 |
| Sonnet | $3 | $15 | 日常编码（默认） |
| Opus | $5 | $25 | 架构设计、疑难杂症 |
默认用Sonnet，性价比最优。但很多人（包括我）一开始图省事全程Opus——直到账单来了。
我现在的工作流：
- Sonnet：写业务代码、修bug、加测试、重构（日常80%的工作）
- Opus：架构决策、跨模块重构、调试诡异bug、性能优化
- Haiku：快速问答、文件查找、简单格式化
切换模型用/model opus或/model sonnet，随时可以换。
一个省钱技巧：先用Sonnet跑，跑不通了再切Opus。很多时候Sonnet已经够用了，你不需要为简单的CRUD操作付Opus的价格。
教训5：别把Claude当打字员，把它当架构师
很多人的用法是："帮我写一个xxx函数"。这其实浪费了Claude Code最大的优势——它能看到你整个项目。
更好的用法是给上下文、给目标，让它自己决定怎么做：
❌ 帮我写一个分页查询的函数
✅ 用户列表页面需要分页功能，前端已经用TanStack Query了，
后端用的是FastAPI + SQLAlchemy。你看看现有的代码风格，
用一致的方式加上分页，记得加测试。
第二种写法为什么更好？因为Claude会：
- 看你现有的API风格（REST还是RPC-like）
- 看你用的ORM写法
- 看你测试是怎么组织的
- 然后用和项目一致的方式来实现
出来的代码不需要你大改就能merge。第一种写法？它给你生成一个完美但不沾地气的"教科书分页"，你得手动改半小时。
教训6：Hooks——用好了是神器，用不好是灾难
Hooks是Claude Code的自动化钩子，可以在特定事件（比如文件修改后、命令执行前）触发自定义脚本。
比如你可以配置：每次Claude改完TypeScript文件，自动跑一遍ruff check。
// .claude/settings.json
{
"hooks": {
"afterFileEdit": [
{
"pattern": "*.ts",
"command": "npx tsc --noEmit $FILE"
}
]
}
}
听起来很美好对吧？但这里有个坑——如果hook本身执行慢或者输出量大，它会疯狂消耗token。 我之前配了一个自动格式化hook，它在一次会话里跑了3轮，吃了160K token。是的，光hook就吃了80%的上下文。
建议： hook只做轻量级检查（类型检查、lint），不要放格式化和构建命令。格式化在commit前手动跑一遍就行。
教训7：MCP让Claude Code如虎添翼
MCP（Model Context Protocol）是让Claude Code连接外部工具的协议。通过MCP服务器，Claude可以操作数据库、访问Jira、读Slack消息、甚至打开浏览器做UI测试。
我最常用的几个MCP服务器：
# 用claude命令一键配置
claude mcp add playwright -- npx @anthropic-ai/claude-code-mcp-adapter @anthropic-ai/mcp-playwright
claude mcp add github -- npx @anthropic-ai/claude-code-mcp-adapter @anthropic-ai/mcp-github
加了Playwright MCP之后，Claude可以直接打开浏览器，点点看你的UI有没有问题。这个在写前端的时候太香了——以前写完前端代码要自己切过去看效果，现在直接跟Claude说"帮我看看按钮对齐了没"，它自己打开浏览器检查。
教训8：Git工作流——让Claude帮你commit，但别让它自己push
claude "把我刚才改的认证模块提交一下，用Conventional Commits格式"
Claude Code特别擅长写commit message——因为它能看到完整的diff，理解每一处改动的原因。比你手动写git commit -m "fix bug"强一万倍。
但是！不要让它自动push。
我曾经让它自动push了代码，结果它把一个带console.log的debug代码推到了main分支。虽然很快回退了，但那次事故让我明白——push这个动作必须经过人的确认。
安全配置：
// .claude/settings.json
{
"permissions": {
"allow": ["Read", "Write", "Bash"],
"deny": ["git push"]
}
}
教训9：Headless模式——CI/CD的好搭档
Claude Code不只能交互式使用，它还支持headless模式，可以直接嵌入你的自动化流程：
# 分析日志
tail -200 app.log | claude -p "有异常吗？有的话给我发Slack"
# PR review
git diff main --name-only | claude -p "review这些文件的改动，重点看安全问题"
# 自动翻译
claude -p "把新增的文案翻译成法语，然后提一个PR"
我在团队里搭了一个GitHub Actions workflow：每次提PR自动触发Claude Code做代码review。虽然不能完全替代人工review，但它能先帮你过一遍，揪出明显的问题（硬编码密钥、未处理的异常、SQL注入风险之类的），节省了大量review时间。
教训10：它不是万能的——知道什么时候该自己写
用了30天，我最深的感触是：Claude Code很强，但它不是银弹。
它擅长的：
- 大规模代码重构（扫全仓库级别的）
- 理解和解释legacy代码
- 写测试（尤其TDD流程下）
- 排查诡异bug（它有耐心一个文件一个文件地翻）
- 生成commit message和PR描述
它不擅长的：
- 需要产品直觉的UI/UX设计
- 涉及业务领域知识的决策（它不了解你们公司的业务逻辑）
- 超长上下文后的连贯性（超过200K就开始"失忆"）
- 对性能极度敏感的底层优化（它倾向于写"正确"的代码而非"快"的代码）
说到底，Claude Code是一个放大器——它放大你的工程能力，但不能替代你的工程判断。用得好，10倍效率提升不是吹的；用得不好，它会让你花更多时间在修它写的代码上。
实用命令速查表
用了一个月，我把最常用的命令整理出来了：
| 命令 | 用途 |
|---|---|
claude | 启动交互式会话 |
claude -p "问题" | 单次提问模式 |
Shift+Tab | 切换Plan Mode |
/model opus | 切换模型 |
/clear | 清空上下文 |
/cost | 查看当前会话花费 |
/compact | 压缩上下文（慎用） |
@文件名 | 引用特定文件 |
# 内容 | 添加到持久记忆 |
Esc Esc | 回退上一次修改 |
价格方案一览
如果你准备入手，这里是最新的价格（2026年4月）：
| 方案 | 价格 | 说明 |
|---|---|---|
| Pro | $20/月 | 适合个人开发者，有使用时长限制 |
| Max 5x | $100/月 | 5倍用量，适合重度用户 |
| Max 20x | $200/月 | 20倍用量，适合全天候使用 |
| API | 按token计费 | 适合自动化和CI/CD场景 |
| Team | $30-45/人/月 | 团队版，有管理后台 |
Pro方案对大多数个人开发者够用了。但如果你像我一样每天6小时以上泡在Claude Code里，Max 5x会更安心——Pro的限额在下午三四点就会用完。
写了这么多，其实就一句话：Claude Code改变了我的编码方式，但它改变不了编码的本质——你还是得知道你在做什么。
工具再强，脑子不能偷懒。
对了，你们在实际使用中有什么心得？评论区聊聊，我挺想知道别人是怎么搭配工作流的——我现在还在探索最优解。
