Claude Code 实战 5 招：从「问答机」到「生产引擎」

工具的价值不在工具本身，在你怎么打磨它。

这篇文章想帮你解决一个问题

你已经在用 Claude Code 了。但每次开会话还是：「这个表怎么改」「帮我写个接口」。问一句答一句，像在用搜索引擎。

它本来可以记住你的项目规矩、写完代码自动跑 lint、还能在你提交前自检多租户漏洞。你没让它做，是因为没人告诉过你怎么让它做。

这篇文章给你 5 个升级动作。看完照着配，下周的 Claude Code 就不一样了。

一、你是不是也是「表面型」选手？

我去年用了大半年才意识到，自己一直在「打字员模式」：

• 每次开新会话，重复解释一遍项目架构
• 让它写完代码，自己手动跑 lint、跑测试
• 改多个模块时，它一头钻进去乱改，回头要回滚
• 多租户接口写完，忘了加 tenant_id 过滤，上线才发现

你看，工具一直在那。但我用得像 ChatGPT。直到把下面这 5 招配上，效率才真正翻倍。

工具的天花板不是模型有多聪明，是你愿意花多少时间教它。

二、五个升级动作

招式 1：CLAUDE.md 五层金字塔 —— 让它记住你的规矩

最大的浪费：每次新会话都重新解释项目。

解药：把规矩写进 CLAUDE.md，让它自动加载。但 CLAUDE.md 不是只有一个文件 —— 它有五层，作用域从广到窄。

每一层放什么：

三条铁律：

• 每个文件 ≤ 200 行（超了模型遵守度断崖式下降）
• 具体规则 > 模糊建议（"返回 ISO8601 时间戳" 比 "用合理时间格式" 好十倍）
• 用 Markdown 标题分组，方便它扫

我自己的全局 CLAUDE.md 前阵子从 91 行瘦身到 30 行 —— 每次启动省 600 token，遵守度反而更高。

招式 2：Hook 自动化 —— 解放你的手

你有没有这种习惯：让 Claude 改完代码，然后自己跑 pytest、跑 ruff、自己提交？

这步不该你做。Hook 就是干这个的。

5 类 Hook 时机：

最先该配的一个：编辑 Python 文件后自动跑 ruff。

写一个 ~/.claude/hooks/lint-on-edit.sh：

#!/bin/bash
input=$(cat)
file_path=$(echo "$input" | jq -r '.tool_input.file_path // empty')
[[ "$file_path" != *.py ]] && exit 0
[[ ! -f "$file_path" ]] && exit 0

# 优先找项目 venv 的 ruff，找不到再用系统的
dir="$(dirname "$file_path")"
ruff_bin=""
while [[ "$dir" != "/" ]]; do
  [[ -x "$dir/.venv/bin/ruff" ]] && ruff_bin="$dir/.venv/bin/ruff" && break
  dir="$(dirname "$dir")"
done
[[ -z "$ruff_bin" ]] && command -v ruff >/dev/null && ruff_bin="ruff"
[[ -z "$ruff_bin" ]] && exit 0

"$ruff_bin" check --fix "$file_path" >&2 || true

然后在 ~/.claude/settings.json 里加：

"hooks": {
  "PostToolUse": [
    {
      "matcher": "Edit|Write|MultiEdit",
      "hooks": [
        {
          "type": "command",
          "command": "/Users/你/.claude/hooks/lint-on-edit.sh"
        }
      ]
    }
  ]
}

配完之后，每次 Claude 改 .py 文件，自动 lint 一遍。你不用记，它也不会忘。

Hook 的本质不是装插件，是让工具自己照顾自己。

招式 3：三段式工作流 —— 别让它一上来就写

这是最反直觉的一招：最快的方式不是让它直接写，而是先让它「想」。

第一段：Plan Mode（只读分析）

按 Shift + Tab 两次切到 Plan Mode。这模式它只能读、不能写。你扔需求给它：

「实现多租户产品管理模块：列表（分页+搜索+租户隔离）、详情、新建、编辑、软删除。涉及 P 端 + T 端。分析需求 + 数据库设计 + 接口 + 前端，列出决策点。」

它会读 HLD、扫现有 product 模块、出方案、列出"这里要选 A 还是 B"。不写一行代码。

你审完方案、拍板、改细节。

第二段：Auto-accept（按方案实施）

切到 Auto-accept，一句话：「按方案实施，后端先」。它一气呵成：

• Alembic 迁移
• controller.py（CRUD）
• service.py（业务逻辑 + tenant_id 过滤）
• dao.py（数据库层）
• 跑 pytest 验证
• 自动 lint（招式 2 那个 hook）
• 提交 commit

第三段：自动审查

/review            # 代码审查 + 测试报告
/security-review   # 多租户 / 权限 / SQL 注入检查

为什么这套有效？因为人脑和模型一样：一边想一边写，质量最差。先想清楚再下手，能省一倍返工时间。

招式 4：多租户陷阱卡 —— SaaS 开发者必读

这一招专门给做多租户 SaaS 的同行。多租户隔离是 SaaS 最容易出大事的地方。

最常见的坑长这样：

# ❌ 坏：忘记 tenant_id 过滤（数据泄露！）
@router.get("/products")
async def list_products(db: AsyncSession):
    return db.query(Product).all()

# ✅ 好
@router.get("/products")
async def list_products(
    db: AsyncSession,
    current_user: User = Depends(get_current_user)
):
    return db.query(Product).filter(
        Product.tenant_id == current_user.tenant_id
    ).all()

只要少了那一句 filter(tenant_id == ...)，整个租户的数据就泄给所有人。

怎么让 Claude 永远不会忘？ 在 ./CLAUDE.md 里写死一段检查清单：

## 多租户安全检查（每个新 API 必过）

- [ ] 所有 SELECT 都有 WHERE tenant_id = ?
- [ ] 所有 UPDATE / DELETE 都有 WHERE tenant_id = ?
- [ ] JWT 中 tenant_id 不可绕过 / 伪造
- [ ] 禁止跨租户 JOIN
- [ ] 接口响应不暴露其他租户字段

写完它每次写 API 都会自检。比你自己 review 还稳定 —— 人会累，它不会。

进阶玩法：把这段做成 multi-tenant-check skill，写完 PR 前一句 /multi-tenant-check 自动跑全套检查。

招式 5：提效黑科技 —— 小招式大解放

最后给你三个「装上就回不去」的小技巧。

第 1 个：模糊需求自动拆解

接到这种话：「优化产品合规审核流程」—— 脑子里一团浆糊，不知道从哪写起？让它拆：

/claude-mem:make-plan

"分解 '优化产品合规审核流程' 为具体任务清单。"

# 输出：
# 第一阶段：数据库迁移
# 第二阶段：后端 API
# 第三阶段：前端页面
# 第四阶段：端到端测试

/claude-mem:do   # 按阶段顺序执行

它把模糊需求切成 4 阶段、十几个具体任务。你不用想，它替你想。

第 2 个：后端接口 → 前端类型自动同步

后端 API 改了，前端 TypeScript 类型怎么办？以前手抄，现在写个 skill：

/frontend-types

# 读后端 controller，自动生成 packages/shared/src/types/api.ts

接口改了，类型自动跟着改。少一道手抄，少一处对不上的坑。

第 3 个：并行开发多端

要在 P 端、T 端、C 端同时改一个组件？以前开三个窗口轮流改。现在：

/batch

"修改 DataTable.vue：
- P 端：行级权限控制
- T 端：租户数据权限
- C 端：导出 CSV
3 个并行 agent 处理"

它自动开三个 worktree、并行做、做完合并。三件事的时间压缩到一件事。

三、维护清单：让你的工具不退化

工具配完不维护，半年就退化成摆设。我自己执行这套：

每周一次（10 分钟）

每次大功能完成（5 分钟）

/review            # 代码审查 + 测试
/security-review   # 多租户 + 权限 + SQL 注入
git log --oneline  # 检查提交信息清晰度

每月一次（30 分钟）

• 整理 CLAUDE.md（删过时规则、合并相似条目）
• 清 .claude/rules/（合并冗余）
• 更新 CLAUDE.local.md（补新测试数据）

不维护的工具，跟没工具一样。

四、🚨 五条红线

写得再多不如记住这五条不能踩的：

1. CLAUDE.md 写太长 —— 超 200 行，模型遵守度断崖式下降
2. Skill 写太长 —— 单文件超 300 行，每次加载浪费 context
3. 滥用 subagent —— 小于 1K token 的任务别 fork，反而更慢
4. MCP 装太多 —— 常用 3-4 个就够，启动加载 20+ 是灾难
5. 跨项目共享忘配 —— claude --add-dir ~/rules 别忘了

踩过几个，心里有数。

写在最后

我用了大半年 Claude Code 才搞明白一件事：

它真正的价值，80% 来自 CLAUDE.md + Hooks + Skills 三件套，20% 才来自模型本身。

换句话说 —— 模型再聪明，你不教它项目规矩、不让它自动跑测试、不让它会议前先想，效果也就那样。

工具的潜力一直在那。差的不是你会不会用，是你愿不愿意花一个下午把它配明白。

下次再开新会话之前，先打开 ~/.claude/CLAUDE.md，从写下第一条规矩开始。

明天的你，会感谢今天的你。 ☕

作者：张少楠
最后更新：2026-05-28
适用范围：单人 / 小团队 SaaS 开发（FastAPI / Vue3 / monorepo）