用了大半年 Claude Code，我总结了 12 个真正改变工作流的配置技巧

进击的尘埃
4 阅读8分钟

用了大半年 Claude Code，我总结了 12 个真正改变工作流的配置技巧

你一定经历过这样的场景：

# 你兴冲冲地装好了 Claude Code
npm install -g @anthropic-ai/claude-code

# 然后对着终端敲下第一句话
claude "帮我重构这个项目"

# 接下来的 10 分钟，你看着它一顿操作猛如虎
# 改了 47 个文件，删了你精心设计的抽象层
# 把 TypeScript 类型全干成了 any
# 还顺手给你升了三个大版本的依赖

改完之后你 git diff 一看，心态直接崩了。不是 Claude 不行，是你没告诉它"规矩"。

这篇文章不聊 Claude 有多智能、AGI 离我们有多近这些虚的。我只聊一件事：怎么配置 Claude Code，让它真正变成你的生产力工具，而不是一个需要你反复擦屁股的代码生成器（实际上没那么简单）。

基础配置：CLAUDE.md 才是灵魂

CLAUDE.md 是 Claude Code 的记忆文件——这个等下再说，放在项目根目录，它会在每次对话开始时被自动加载。这是你跟 Claude 建立"工作契约"的地方。

一个真正有用的 CLAUDE.md

# 项目概述

这是一个 B2B SaaS 的前端项目，技术栈：React 18 + TypeScript 5.3 + Vite 5 + TanStack Query v5。
状态管理用 Zustand，UI 组件库是内部封装的 @acme/ui（基于 Radix）。
后端 API 是 RESTful 风格，统一走 /api/v2 前缀，鉴权用 JWT + Refresh Token。

# 代码规范

- 组件文件用 PascalCase，工具函数用 camelCase
- 禁止使用 default export，全部用 named export
- 禁止使用 enum，用 as const 对象替代
- CSS 方案是 CSS Modules + PostCSS，不要引入 Tailwind 或 styled-components
- 类型定义统一放在同目录的 types.ts 中，不要用 interface，统一用 type

# 目录结构

src/
  features/       -- 按业务模块划分，每个模块包含 components/hooks/api/types
  shared/         -- 跨模块复用的工具、组件、hooks
  app/            -- 路由配置、全局 Provider、入口文件

# 绝对不要做的事

- 不要修改 src/shared/legacy/ 下的任何文件，这是历史遗留代码，正在逐步迁移
- 不要动 package.json 的依赖版本
- 不要创建新的全局状态 store，需要的话先跟我确认
- 不要使用 any 类型，实在推断不出来用 unknown + 类型守卫

看到区别了吗？好的 CLAUDE.md 要具体到能直接指导编码决策的程度。哦不，准确说是_INLINE_CODE_5__ 要具体到能直接指导编码决策的程度。"用 TypeScript"是废话，"禁止使用 enum，用 as const 替代"才是有效指令。

CLAUDE.md 的层级机制

这个很多人不知道——CLAUDE.md 支持多级放置：

项目根目录/CLAUDE.md          -- 全局生效
项目根目录/src/CLAUDE.md      -- 仅在操作 src 目录下文件时生效
项目根目录/tests/CLAUDE.md    -- 仅在操作 tests 目录下文件时生效
~/.claude/CLAUDE.md           -- 你所有项目都生效的个人偏好

我的实际用法是：根目录放项目级规范，src/features/ 下每个业务模块放一个，写清楚这个模块的业务上下文。比如：

# features/billing 模块

负责计费相关功能。核心概念：
- Plan: 套餐方案（free/pro/enterprise）
- Subscription: 用户的订阅实例，关联 Plan
- Invoice: 账单，由 Subscription 周期性生成

注意事项：
- 金额统一用"分"作为单位（integer），展示时再转换
- 所有金额计算必须用 Decimal.js，禁止浮点运算
- 退款逻辑非常复杂，修改前必须先读 src/features/billing/REFUND_LOGIC.md

环境区分：开发、CI、Code Review 三套配置

很多团队开始在 CI 流程里集成 Claude Code 做自动 Code Review 或者自动修复 lint 问题。这时候你需要区分环境。

本地开发配置

{
  "permissions": {
    "allow": [
      "Bash(npm test*)",
      "Bash(npm run dev*)",
      "Bash(npx tsc*)"
    ]
  },
  "model": "claude-sonnet-4-6"
}

CI 自动 Review 配置

# .github/workflows/claude-review.yml
- name: Claude Code Review
  run: |
    claude --print \
      --model claude-sonnet-4-6 \
      --permission-mode bypass \
      --max-turns 3 \
      "Review the changes in this PR. Focus on:
       1. Type safety issues
       2. Missing error handling at API boundaries
       3. Performance anti-patterns (unnecessary re-renders, missing memo)
       Do NOT suggest style changes, the linter handles that."
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

CI 环境里有几个关键点：

  • 用 --print 模式，输出结果但不进入交互
  • 用 --max-turns 限制它的操作轮次，避免跑飞
  • Prompt 里明确告诉它不要做什么，比如不要管代码风格，那是 ESLint 的活

深度分析配置

遇到复杂的架构决策或者疑难 bug，切到 Opus：

claude --model claude-opus-4-6 \
  "分析 src/features/billing/hooks/useSubscription.ts 的性能问题。
   这个 hook 在订阅列表页会导致每次筛选都触发全量重渲染。
   给出具体的优化方案，包括代码修改。"

Opus 的推理能力确实强一截，但速度慢、成本高。日常写 CRUD 没必要，遇到真正需要"想一想"的问题再拿出来。

提示词工程：跟 Claude Code 说话是门手艺

配置文件搞定了，日常交互的方式同样重要。同一个需求，不同的描述方式，得到的代码质量能差出两个档次。

别说"帮我写一个组件"

// 你说的
帮我写一个用户列表组件

// Claude 理解的
写一个能展示用户列表的 React 组件（具体怎么写我自由发挥）

// 你应该说的
在 src/features/user/components/ 下创建 UserList 组件：
- 用 TanStack Query 的 useQuery 调用 GET /api/v2/users
- 列表项用 @acme/ui 的 Card 组件
- 支持按 name 和 email 搜索，用 useDeferredValue 做防抖
- 空状态用 @acme/ui 的 EmptyState 组件
- 不需要分页，后端一次返回全量数据（最多 200 条）
- 参考 src/features/billing/components/InvoiceList.tsx 的写法

最后那句"参考 xxx 的写法"是点睛之笔，Claude Code 能直接读取那个文件，学习你项目里已有的模式。让它抄你的代码，比让它从零发挥靠谱得多。

用 /compact 控制上下文

长对话是 Claude Code 质量下降的头号杀手。聊到 20 轮以后，它会开始"忘记"前面的约定，代码风格也会漂移。

# 当你感觉它开始"犯迷糊"的时候
/compact

# 或者主动分阶段工作
# 第一阶段：讨论方案
claude "分析一下目前的路由架构，有哪些可以优化的点"

# 方案确定后开新对话执行
claude "按照以下方案重构路由：[具体方案]"

让 Claude 先读再写

先阅读以下文件，理解现有的错误处理模式：
- src/shared/lib/api-client.ts
- src/shared/hooks/useApiError.ts
- src/features/auth/api/login.ts

然后在 src/features/billing/api/createInvoice.ts 中实现创建账单的 API 调用，
错误处理方式必须与上述文件保持一致。

这个"先读后写"的模式我每天都在用。它解决的核心问题是：让 Claude 用你项目的方言写代码，而不是用它自己的"普通话"。

你可能踩的坑（我已经替你踩过了）

CLAUDE.md 写太长反而有害

我试过写一个 500 行的 CLAUDE.md，把所有能想到的规范都塞进去。结果发现 Claude 反而开始选择性遗忘，有些规则它根本不遵守。经验值：根目录的 CLAUDE.md 控制在 100-150 行以内，更细的规范拆到子目录的 CLAUDE.md 里。Claude Code 只会在操作对应目录时加载子目录的配置，这样既不浪费上下文窗口，又能做到精准约束。

不要让 Claude 做它不擅长的事

Claude Code 写业务代码很强，但有几件事它做得不好：

  • 复杂的正则表达式：它生成的正则经常在边界情况翻车，自己写或用库更靠谱
  • 像素级还原设计稿：它能搭结构，但间距、颜色、动画的微调还是得人来
  • 性能优化的"最后一公里"：它能帮你找到性能卡点，给出方向，但具体的优化参数（虚拟列表的 overscan、防抖的毫秒数）需要你实测调整
  • 涉及项目政治的决策：技术选型、要不要引入新依赖、要不要重构某个模块——这些是人的决策，不要甩给 AI

成本控制不是小事

Claude Code 按 token 计费，一个不小心就烧钱。几个省钱建议：

# 日常开发用 Sonnet，够用且便宜
claude --model claude-sonnet-4-6

# 只在需要深度推理时用 Opus
claude --model claude-opus-4-6

# 用 --max-turns 限制自动操作的轮次
claude --max-turns 10 "修复这个 bug"

根据 Anthropic 官方定价（2025 年数据），Opus 的 token 价格大约是 Sonnet 的 5 倍。如果你团队 5 个人全天用 Opus，一个月的 API 费用可能比一个初级工程师的工资还高。

context 溢出的信号

当你发现 Claude 开始出现以下症状，说明当前对话的上下文已经接近极限了：

  • 开始重复你之前已经否决的方案
  • 忘记了 CLAUDE.md 里写明的规范
  • 生成的代码风格突然变了
  • 回答变得越来越笼统，细节越来越少

这时候不要硬撑，直接开新对话。用一段简洁的背景描述代替之前 30 轮的聊天记录，效果反而更好。

Claude Code 不是魔法，它是一个能力极强但需要明确指令的工具，配置的本质是把你脑子里的"常识"翻译成机器能理解的规则。 你在配置上花的每一分钟，都会在后续的协作中以十倍的效率回报你。那些说"AI 写的代码不能用"的人，大概率是在用 2024 年的方式——裸奔、许愿式提示词、一句话需求——去驾驭 2026 年的工具。工具已经进化了，你的使用方式也该跟上。

avatar
文章
阅读
粉丝