面向对象：日常写代码、带团队或做工程实践的开发者和技术同学，希望把 Claude Code 真正融进工作流，而不是偶尔玩一玩。

围绕一件事展开：怎么把 Claude Code 变成你稳定、可控、可复用的「协作伙伴」，而不是一时爽、一会儿就开始瞎编的「工具人」。我们会从官方没怎么讲清楚的实战细节入手，一步步拆开：会话怎么开、项目怎么组织、提示词怎么给、工具和 Agent 怎么搭、最后怎么沉淀成自己的技能体系。

---

一、先说结论：Claude Code 的「正确打开方式」

如果只看一个结论，那就是：把 Claude Code 当「协作开发同事」来设计，而不是当「万能代码生成器」来祈祷。

围绕这个思路，整套实践大致分成七个方面：

• 用 Plan 模式，让 Claude 先想清楚再写
• 用根目录 CLAUDE.md 设「防呆规则」，防止会话失控
• 用「分级加载」整理代码库，让它理解项目结构
• 提示词只抓三件事：目的、上下文、怎么测
• 主动让它用 MCP 查资料，而不是等它自己悟
• 用多个 Agent 分工和互相挑错，提升质量
• 把高频工作流固化成自定义 Skill，少重复讲废话

后面我们按这个顺序展开，每一节都尽量结合平时真会遇到的场景来讲。

---

二、Plan 模式：先把活说清楚，再写代码

2.1 Plan 模式是什么？

Claude Code 里有个很关键但容易被忽略的能力：Plan 模式（Shift + Tab）。简单说，它会先跟你对齐目标、拆任务，而不是直接开始写代码。

默认大家容易这样用：

「帮我写个 xxx 功能，前端 React，后端是 Spring Boot……」
Claude：一顿输出，写了一屏又一屏。

结果往往是：

• 业务边界不清楚，你发现写出来的和你想的差一截
• 中途需求补充了几次，前后风格和设计都不统一
• 返工成本极高，改来改去不如自己写

Plan 模式就是强制它：先别写，先想清楚。

2.2 怎么实际使用 Plan 模式？

一个推荐的最小套路是这样的：

1. 先给「目标+边界」

   • 我要做什么（例如「新增一个订单列表页，可筛选、分页、导出 Excel」）
   • 暂时不做什么（例如「暂时不支持多租户、也不对接权限系统」）

2. 明确要它怎么问你

   • 「你先把需要确认的问题列出来，一次性问完」
   • 「不要自己脑补业务设定，有疑问必须问」

3. 要求它输出结构化 Plan

   • 整体方案
   • 任务拆解（分成几大块，每块有哪些子任务）
   • 每块大概会涉及哪些文件、接口或模块

一个简单示例提示：

「接下来你只做一件事：帮我整理开发计划，不要写任何代码。
先列出你需要确认的问题，然后给出分步骤的开发方案，按模块划分任务。等我逐条确认后，再进入写代码阶段。」

你可以理解为：Plan 模式就是帮你「先写一份用人能看懂的需求+设计文档」，只不过这份文档是你和 Claude 共同磨出来的。

2.3 为什么这一步能大幅减少返工？

原因很简单：大部分返工不是因为「写错」，而是因为「一开始没讲清楚」。Plan 模式等于在会话刚开始时，给你一个「停下来对齐」的机会：

• 发现他理解错的地方，当场纠正，不让问题在代码里发酵
• 边界说清楚，避免一路加需求、一路改架构
• 计划写出后，你可以拿给同事或产品一起看，相当于一份轻量设计文档

尤其是大任务（比如重构一个模块、搭一套管理后台），强烈值得要求 Claude 把 Plan 持久化成文档，放在项目仓库或知识库里，以后新开会话直接引用。

---

三、根目录 CLAUDE.md：给 AI 立几条硬规矩

3.1 CLAUDE.md 是干嘛的？

可以把根目录的 CLAUDE.md 当成「团队工作手册」，里面写的是：你希望这个 AI 员工在这个项目里，遵守哪些铁律。

几个很实用的例子，我们拆开看。

3.2 「称呼规则」：用来检测上下文过载

有一个很有意思的约定：

• 强制它在对话里称呼你为「Boss」
• 如果有一轮突然不这么叫了，很可能是上下文被截断或挤满，之前的约定丢失了

这其实是一个非常简单但好用的「健康监控」：

• 一旦发现它开始不按规矩说话，你就知道：会话该重开了
• 搭配类似 /new 这种命令，能快速切一个干净的上下文

这比你盯着 token 数字有用得多，因为你能第一时间感知「它已经不记得刚才你们说过什么了」。

3.3 「自由意志约束」：禁止它自己拍脑袋

这里的核心要求是：

• 设计之前必须给你至少两个可选方案
• 不允许自己决定「哪种更好」，而是不停问：
  • 「你更倾向哪种？成本和收益分别是…」

这对架构决策特别重要：

• 很多时候你需要权衡「简单 vs 可扩展」，AI 不知道你团队的实际情况
• 如果它直接拍板，很快就引发风格混乱、技术债增加

让它先列方案，再讨论，可以保证关键决策掌握在你手里。

3.4 「拒绝冗余兼容」：不乱加 if，代码更干净

另一条很接地气的约束是：

除非我明确要求，不要「为了健壮性」给我加一堆 if 分支。

很多模型有个习惯：

• 害怕出错，就疯狂包 try-catch、疯狂 if 判空
• 对简单场景写成「防导弹级」代码，看着很安全，其实可读性极差

在 CLAUDE.md 里直接说明：

• 只对我们已有明确需求的情况做兼容
• 其他场景宁可先不处理，有真实需求再说

你会发现，代码简洁度会好很多。

3.5 「状态监控」：上下文超过 50% 就要警惕

监控上下文占用，并关闭自动上下文压缩。

原因是：

• 上下文接近一半时，模型开始变「糊涂」：
  • 记不住之前的细节
  • 回答变含糊、摇摆
• 自动压缩有时会把关键信息「模糊处理」掉，你还以为它记着

更稳妥的做法是：

• 适时把阶段性结论沉淀到文档（例如 README、设计文档）
• 新开会话时，把这份文档当冷启动上下文喂给它，而不是指望它记着长长的聊天记录

---

四、Vibe Coding：「分级加载」代码库

4.1 问题：AI 要么看太少，要么看太多

在实际项目里，我们经常碰到两种极端：

• 只贴一小段代码，它看不出上下文，乱猜意图
• 把整个项目文件夹扔给它，它上下文爆炸，抓不到重点

所谓「Vibe Coding 自分形（分级加载）」就是用 Claude Code 的懒加载能力，让它按层级、按模块去理解代码，而不是一股脑全塞进去。

4.2 每个业务模块配一份 CLAUDE.md

做法很简单：

• 每个业务模块（比如 user/、order/、billing/）下面都放一份自己的 CLAUDE.md，里面写：
  • 这个模块是干什么的
  • 和其他模块的关系
  • 关键约束（比如「这里所有金额都以分为单位」）
  • 重要文件列表和作用

好处是：

• 当 Claude 只加载 order/ 相关文件时，它会优先看这个目录下的说明
• 它能在「正确的上下文」里理解你给的代码，不会拿用户模块的习惯套到订单模块上

4.3 每个源码文件加三行头注释

建议：在每个源码文件头部加三行注释：

• INPUT：它依赖哪些东西（比如依赖哪些接口、哪些配置）
• OUTPUT：它提供哪些能力或数据
• POS：它在整体系统中的位置（例如「这是订单服务的聚合根」「这是前端订单列表页」）

这三行看似简单，但对 Claude 来说非常重要：

• 它不再是盯着几百行代码「猜」用途，而是先看你给的标签
• 搜索代码时，能更快找到正确文件，而不是翻半天

举个例子：

// INPUT: 依赖 /api/orders, userStore, route query
// OUTPUT: 展示订单列表，支持筛选、分页、导出
// POS: 订单域的主列表页，用于运营查看订单概况

有了这些注释，你以后只要说「帮我改订单列表页，让导出时多一个 xxx 字段」，它更容易定位到正确的文件，而且知道这块改动对整体有什么影响。

---

五、提示词三原则：别说术语，把话说明白就行

5.1 不需要「魔法咒语」

提示词不需要搞成玄学，只要把三件事讲清楚：你要干什么，有哪些参考，它该如何验证。

这三件事分别对应：

1. 清晰目的

   • 功能点：你到底要实现什么
   • 页面元素：需要有哪些按钮、输入框、表格列等

2. 参考上下文

   • 接口文档地址
   • 现有页面或组件路径

3. 测试方法

   • 用哪个浏览器
   • 需要覆盖哪些操作步骤

5.2 一个更贴近日常的示例

例如，你可以这样说：

「我要在订单列表页加一个导出按钮，点击后导出当前筛选条件下的订单。
参考接口：GET /api/orders/export，文档在 docs/api/orders.md。
前端框架是 Vue3 + Element Plus，现有列表组件是 src/pages/order/OrderList.vue。
你改完后，请说明如何在 Chrome 里验证，包括：

• 哪里能看到这个按钮
• 点击后应出现什么反馈
• 异常时如何提示用户。」

这段话完全不用任何玄乎的术语，但信息量对 Claude 来说已经足够。

---

六、MCP：不要等它「想起来用工具」

6.1 MCP 是什么角色？

简单理解，MCP（Model Context Protocol）是一套「让模型主动去调用外部工具和数据源」的机制。

• 不要指望 Claude 自己想起来用 MCP
• 你要像带新人一样，明确告诉它「去查哪儿」

6.2 主动命令它用 MCP

举一个指令例子：「Use Context7」——你可以理解为明确指定它：

• 去某个配置好的知识源（比如内部文档、Wiki、API 文档）里查
• 把相关内容拉进当前上下文，再开始分析或编码

这有两个好处：

• 避免它凭记忆瞎编接口字段、业务规则
• 让它在需要精确信息时，优先查「权威来源」而不是自己瞎猜

6.3 「本地优先」的考量

能用本地工具解决的，就别全推给云端 MCP。

原因包括：

• MCP 越多，占用的上下文和心智负担越大
• 延迟和稳定性也受网络影响
• 有些信息（比如当前项目代码）本地就能直接读取，没必要绕一圈

比较合理的设计是：

• 把「稳定、通用、更新不太频繁」的知识（比如 API 文档、设计说明）放到 MCP
• 把「强依赖当前项目结构」的东西交给本地插件或直接读文件

---

七、Agent 高级玩法：用多个「小助手」互相挑错

7.1 为什么需要多个 Agent？

在开发实践里，「一个会话干所有事」很容易弄成垃圾场：

• 它既要写代码、又要查文档、还要做 code review、顺便帮你改改测试
• 上下文混在一起，很难保持清晰的角色边界

用子 Agent（SubAgent）和对抗式 Agent。可以理解为给 Claude 分几个「小号」，每个只干一件事

7.2 SubAgent：专门用来查和搜

SubAgent 的典型用法：

• 专门负责搜索代码、查资料
• 有独立的上下文，不会把一堆搜索结果塞进你的主开发会话

比如：

• 主会话是「实现功能」
• 子 Agent A：只查项目里相关代码
• 子 Agent B：只查知识库或外部文档

这样你的主会话就不会被一堆「搜索过程」的噪音污染。

7.3 对抗式纠错：CodeReview Agent + Test Agent

另一个好玩但很有用的玩法是「对抗式纠错」：

• 一个 Agent 只负责 code review：
  • 看风格、复杂度、潜在 bug
• 另一个 Agent 只负责测试设计：
  • 写测试用例、设计边界场景

你可以一条指令把它俩都拉上来，然后要求它们互相挑错：

• Test Agent 根据 review 结果补充测试
• CodeReview Agent 根据测试发现的问题调整建议

这种「内部 PK」，很多时候能暴露你自己都没想到的坑。

---

八、Custom Skills：把高频套路固定下来

8.1 为什么要做 Skill？

如果你每天都在用 Claude Code 工作，很快会发现：

• 自己对它说的话，80% 都是重复的套路
  • 比如「先帮我看一下这段代码有啥问题」
  • 「按之前风格帮我扩展一个接口」

Custom Skills 的意义，就是把这些高频工作流固化成可复用的「任务模板」。以后只要一句话，就能触发一整套流程。

8.2 一个典型 Skill 的结构

一个成熟的 Skill 通常包含：

• 触发方式：你说什么话，代表要启动这个 Skill
• 输入约定：它需要你提供哪些信息（代码片段、文件路径、接口文档等）
• 内部步骤：
  • 先检查什么
  • 再做什么修改
  • 最后如何给出结果（比如顺带产出一份变更说明）

例如你可以定义一个「安全审查 Skill」：

• 触发语：
  • 「用安全审查流程过一遍这段接口代码」
• 内部流程：
  • 检查 SQL 注入、XSS、鉴权是否缺失
  • 给出修改建议
  • 生成一份简要审查报告

长期来看，Skill 是你把个人经验和团队最佳实践，沉淀到工具里的方式，而不是只存在于「老员工脑子里」。

---

九、实践

9.1 第一步：搭好基础约束

• 在项目根目录加上 CLAUDE.md：

  • 写清称呼规则（如「必须叫我 Boss」）
  • 写清「自由意志约束」（不得自行拍板重要设计）
  • 写清「冗余兼容」策略（不乱加 if）
  • 写清上下文健康规则（比如超过 50% 就建议新开会话）

• 在团队里达成共识：

  • 所有人在这个仓库里，都按这套规则和 Claude 互动

9.2 第二步：整理模块和文件结构

• 给每个核心业务模块都加一份 CLAUDE.md：

  • 模块职责
  • 对外接口
  • 和其他模块的关系

• 给关键源码文件头部加那三行注释：INPUT / OUTPUT / POS

这是最费时间的一步，但也是最值得投资的部分。

9.3 第三步：改造你的「提问方式」

• 把所有「口头需求」都改成三段式：
  • 我要实现什么
  • 参考什么（接口、页面、文档）
  • 怎么测

你可以考虑写一个简单的「提示词模板」，贴在团队 Wiki 里，让大家照这个格式问。

9.4 第四步：接入 MCP 和 Agent

• 挑一两类「信息稳定、变更不太频繁」的文档优先接入 MCP，比如：

  • API 文档
  • 领域模型说明

• 搭建 1~2 个辅助 Agent：

  • Search Agent：只负责查代码与文档
  • Review Agent：只负责做 code review

先从简单场景开始，不要一上来做太复杂的编排。

9.5 第五步：从「常用套路」里提炼 Skills

• 观察 1~2 周你和团队最常用的几类对话
• 挑 2~3 个最有价值的场景先做 Skill：
  • 比如「新接口开发流程」、「新页面开发流程」、「常规 bug 分析流程」

后面再逐步扩充，不要追求一步到位。

---

十、最后的几句实话

• Claude Code 真正的价值，不在于「它能写多少行代码」，而在于你能不能把它稳定地融到日常开发节奏里，让它变成团队的一部分。
• Plan 模式、CLAUDE.md、防呆规则、分级加载、MCP、Agent、Skill，本质上都是在做一件事：把不确定性收紧，让 AI 在「你设计好的轨道」里发挥能力。