20年软件开发团队转型VibeCoding的Claude Code 使用手册

内容分享5小时前发布裴黑地

0 0 0

全能 AI 聚合平台免费

一站式接入主流 AI 大模型，支持对话 · 生图 · 生视频，即开即用

ChatGPT Claude Gemini Grok DeepSeek 通义千问 Ollama

AI对话 AI生图 AI视频

免费使用 →

Claude Code 使用手册

面向技术团队

上手、协作、安全与交付规范

使用定位

Claude Code（简称 CC）不是普通问答工具，而是可以读写本地文件、执行终端命令、制定计划并持续推进任务的编程 Agent。团队使用时，必须把它纳入 Git、权限、上下文、验收和安全规范中。

一、核心认识：CC到底是什么

Claude Code（简称 CC）最初定位为终端运行的编程 Agent。它不是只回答问题，而是围绕目标自主制定计划、调用工具、修改文件、执行命令，并根据结果继续推进，直到任务完成。

维度	传统AI助手	Claude Code（CC）	对开发团队的意义
交互方式	一问一答	计划 + 行动 + 反馈循环	可以承担完整开发任务，而不是只给提议
执行环境	一般在沙盒或网页内	本地文件系统 + 终端命令	能直接读代码、改代码、跑命令、看日志
能力核心	生成文本或代码片段	Agent循环 + 工具调用 + Harness工程	同等模型下实际工程能力明显提升
风险点	主要是答案不准	可能真实修改文件或执行命令	必须用权限、Git、审查和验收管住
适用场景	咨询、解释、生成	开发、调试、重构、文档、数据处理	适合纳入团队研发流程

1.1 Agent循环机制

·接收用户提示词、项目上下文和工具说明。

·大模型判断下一步动作：读文件、写代码、执行命令、总结结果或继续提问。

·调用工具并拿到返回结果，例如终端输出、文件内容、测试结果。

·根据结果继续决策，形成“目标—动作—反馈—修正”的闭环。

团队理解重点

不要把 CC 当“代码生成器”，而要当“会使用本地工具的研发助理”。它能提高效率，但也会放大不规范操作的风险。

1.2 主要适用范围

类型	可做事项	提议成熟度
新功能开发	根据任务卡生成后端接口、前端页面、数据库脚本、测试用例	中高
Bug修复	阅读日志、定位代码、提出修复方案、改代码、跑验证	中
代码审查	发现重复逻辑、潜在空指针、安全风险、性能问题	中
文档生成	接口文档、部署说明、验收清单、变更说明	低
数据分析	读取CSV/日志/报表，生成统计结论与图表脚本	中
知识工作	财务、法律、招投标、方案材料的结构化处理	低到中

二、团队使用原则：先管住，再放开

一句话原则

CC可以很强，但不能裸奔。每个项目都必须先建立“Git存档、权限模式、计划确认、验收命令、上下文清理”五件套。

2.1 十条硬规则

1. 禁止在未提交Git的脏工作区中让CC大规模修改代码。

2. 新功能、重构、批量替换必须先让CC输出计划，再确认执行。

3. 涉及数据库结构、生产配置、依赖升级、部署脚本、权限策略的修改，必须人工复核。

4. 禁止在生产服务器、生产数据库、真实客户数据目录中使用高风险自动确认模式。

5. 禁止把密钥、Token、客户隐私数据、未脱敏数据库直接贴给CC。

6. 每次任务必须要求CC给出：变更范围、验证命令、影响评估、回滚方案。

7. 每个项目必须维护项目级CLAUDE.md，固化编码规范、启动命令和禁区。

8. 上下文超过较高占比、回答变慢或质量下降时，必须compact或clear。

9. CC完成后，开发人员依旧是第一责任人，必须读diff、跑测试、看页面。

10. 不要追求一次性全自动完成复杂系统，应该拆成任务卡、分阶段验收。

2.2 推荐工作模式

场景	推荐模式	是否允许自动编辑	是否需要人工确认
阅读/解释代码	默认模式	否	否
小Bug修复	默认模式	可允许	关键文件修改前确认
新模块开发	计划模式	确认计划后允许	必须确认计划和diff
大范围重构	计划模式 + Git分支	谨慎允许	必须逐步验收
依赖安装/系统命令	默认模式	否	必须确认
生产环境操作	人工执行为主	不允许	必须多人复核

三、安装、模型与权限配置

3.1 安装与验证

附件中提到可通过命令行安装，也可以让IDE里的Agent辅助安装。团队内部提议统一出一份环境初始化脚本，避免每个人安装方式不同。

# 常用验证方式

claude –version

# 进入项目目录后启动

cd /path/to/project

claude

3.2 模型与计费配置

方式	说明	团队提议
订阅模式	使用Claude Pro/Max/Team等订阅	适合个人高频研发、培训与探索
API模式	通过Anthropic控制台或第三方平台计费	适合团队统一网关、统一审计、统一成本控制
国产/多模型切换	通过CC Switch等方式管理模型切换	适合成本敏感或内网/国产化项目，但要做效果验证

3.3 权限模式

模式	含义	适用场景	风险
计划模式（Plan Mode）	先输出执行计划，用户确认后再执行	新功能、重构、复杂Bug	较低
默认模式	自主判断风险操作，关键修改需确认	日常开发、解释代码、局部修改	中
自动编辑模式（Accept Edits）	自动执行文件修改，系统命令仍需确认	小范围、可回滚、测试充分的任务	中高
高风险跳过确认	尽量减少或跳过确认	仅限沙盒/演示/一次性实验	高，不提议默认使用

内部要求

团队默认从“计划模式/默认模式”开始。只有在已提交Git、任务边界清楚、验证命令明确时，才允许短时间使用自动编辑模式。

四、日常开发标准流程

4.1 标准流程总览

阶段	开发人员动作	让CC做什么	产出物
1. 准备	切分任务卡，确认分支，git status干净	读取项目结构、启动命令、相关模块	任务理解与影响范围
2. 计划	描述目标、约束、验收口径	输出实施计划、涉及文件、风险点	计划清单
3. 执行	确认计划后允许修改	编码、生成脚本、调整配置、补文档	代码diff
4. 验证	要求给出并执行验证命令	跑单测、构建、lint、接口或页面检查	验证结果
5. 复核	人工看diff、跑关键路径、补充测试	总结变更、风险、回滚方式	提交说明
6. 提交	git commit并推送	生成commit message或PR说明	可审查提交

4.2 每次任务的最小提示词结构

请先不要改代码，先阅读项目并输出计划。

任务目标：……

业务背景：……

涉及模块：……

必须遵守：……

禁止事项：……

验收标准：……

请输出：

1. 你理解的目标

2. 需要查看的文件

3. 实施步骤

4. 风险点

5. 验证命令

确认后再开始修改。

4.3 精准上下文输入技巧

·用 @filename 或 @目录精准引用相关文件，不要只说“看一下项目”。

·UI类任务可拖拽图片作为参考，让CC对照布局、配色、交互细节。

·复杂任务先让CC列出“还需要哪些信息”，再补充，不要一次塞入大量无关内容。

·对已知错误要直接贴日志、堆栈、接口返回、复现步骤。

·对不希望修改的目录，明确写入“禁止修改”。

五、项目记忆与团队规范：CLAUDE.md

附件中提到的 Cloud MD / cloud.md，提议团队统一理解并落地为 CLAUDE.md。它是让CC理解项目规则、团队习惯和局部约束的关键文件。

5.1 三级结构

层级	位置	用途	维护人
全局级	~/.claude/CLAUDE.md	个人习惯：中文输出、常用工具、个人偏好	个人
项目级	./CLAUDE.md	团队共享规范：架构、启动命令、代码规范、禁区	项目负责人/技术负责人
目录级	子目录/CLAUDE.md	局部规则：某模块特殊约束、生成代码规则	模块负责人

5.2 项目级CLAUDE.md提议模板

# 项目名称

本项目是……

## 技术栈

– 后端：……

– 前端：……

– 数据库：……

## 启动与验证命令

– 后端启动：……

– 前端启动：……

– 单元测试：……

– 构建检查：……

## 编码规范

– 统一使用……

– 禁止直接修改……

– 新增接口必须同步更新……

## 数据库规则

– 禁止直接删除字段

– 结构调整必须提供迁移脚本和回滚脚本

## 安全规则

– 禁止提交密钥、Token、客户数据

– 涉及权限、登录、支付、生产配置必须人工确认

## 交付要求

每次任务完成后输出：变更文件、验证命令、风险点、回滚方式。

5.3 编写原则

·简洁聚焦：只写会长期影响项目执行的规则，不要堆砌大段说明。

·随项目演进逐步补充：把踩过的坑、固定命令、禁止事项沉淀进去。

·优先写“可执行规则”：列如必须运行哪些命令、哪些文件不能改。

·定期清理过期内容，避免CC被旧规则误导。

六、上下文管理与会话治理

附件指出，当上下文饱和时，CC可能出现响应变慢、输出质量下降、有效上下文利用率下降等问题。开发人员必须主动治理上下文，而不是无限追加对话。

问题表现	可能缘由	处理方式
回答变慢、开始绕圈	上下文过长或目标混乱	执行 /compact 或重新开会话
忘记前面约束	关键规则没有写入CLAUDE.md	把稳定规则沉淀到项目记忆
开始修改无关文件	任务边界不清	重新声明目标、禁止目录、涉及文件
输出质量下降	上下文噪声太多	用 /clear 开新会话，重新输入最小上下文

6.1 常用命令

命令	作用	使用时机
/context	查看上下文占用情况	任务较长、响应变慢时
/compact	精简对话历史，保留关键信息	一个任务做了较久但还要继续
/clear	清空上下文，开始新会话	任务切换、方向混乱、上下文污染
/memory	编辑或管理记忆	需要固化/修正项目规则时
/model	切换模型配置	不同任务需要不同模型时

6.2 会话切分提议

·一个会话只做一个明确任务，不要把多个需求混在一起。

·大任务拆成“调研—方案—编码—验证—文档”多个会话。

·每个阶段结束要求CC输出阶段总结，作为下一阶段输入。

·核心项目规则进入CLAUDE.md，临时讨论不要长期留在上下文里。

七、Git、回滚与风险控制

附件中强调，/rewind 或双击ESC可以回滚AI编辑内容，但无法撤回终端命令造成的影响，例如安装依赖、数据库变更等。因此，团队真正可靠的“后悔药”必须是Git。

7.1 开发前必须做

git status

# 确保当前工作区干净，或先提交/暂存已有改动

git checkout -b feature/xxx

# 为CC任务创建独立分支

7.2 让CC参与Git，但不要完全取代人

动作	可让CC做	必须人工做
查看diff	解释变更影响、发现异常文件	亲自阅读关键业务代码
提交说明	生成commit message和PR说明	确认描述准确
回滚提议	指出回滚文件、命令、注意事项	执行高风险回滚前确认备份
冲突处理	给出解决方案	复杂冲突必须人工复核

7.3 回滚方式选择

方式	适合场景	局限
双击ESC / /rewind	刚刚完成的AI文件修改	无法撤回终端命令或外部系统影响
git checkout — file	回退某个文件	需要知道文件路径
git reset / revert	回退一次或多次提交	多人协作时要谨慎
数据库回滚脚本	结构或数据变更	必须提前准备，不能事后临时猜

八、高级能力：Skills、MCP、Sub-Agent、Hooks

附件将高级扩展能力概括为：通过Skills增加领域能力，通过MCP和CLI连接外部工具，通过Sub-Agent并行处理任务，通过Hooks实现自动化触发。团队落地时，不提议一上来全用，应按价值逐步引入。

能力	作用	适用场景	落地提议
Skills	为CC增加特定领域能力或固定流程	代码审查、生成测试、项目脚手架、文档模板	把公司标准流程固化为Skill
MCP	把外部系统、数据库、知识库、浏览器等接入CC	PMS、NAS、接口平台、代码仓库、知识库	先做只读，再做可写，必须有权限边界
CLI工具	通过终端调用已有脚本和工具	构建、测试、部署、日志分析	优先沉淀为scripts目录
Sub-Agent	让多个子任务并行分析	竞品分析、模块审查、多方案评估	输出必须合并和人工判断
Hooks	在特定节点自动触发动作	提交前lint、测试完成提示、代码扫描	从低风险检查类Hook开始

8.1 推荐引入顺序

1. 先统一CLAUDE.md和项目脚本，解决“每个人用法不同”的问题。

2. 再沉淀常用提示词模板和任务卡模板，解决“不会提需求”的问题。

3. 再引入Hooks做提交前检查，解决“忘记跑测试”的问题。

4. 再接入只读型MCP，例如知识库、接口文档、PMS任务查询。

5. 最后才思考可写型MCP、自动化部署、跨系统操作。

九、典型任务SOP与提示词模板

9.1 Bug修复SOP

步骤	提示词要点	交付要求
复现	我遇到如下报错/日志/复现步骤，请先判断可能缘由	缘由假设列表
定位	请只读代码，找出最可能相关文件，不要修改	相关文件和调用链
计划	给出最小修改方案和验证命令	修复计划
修改	按方案修复，避免扩大改动范围	代码diff
验证	运行测试/构建/复现检查	验证结果和剩余风险

Bug修复提示词模板：

请先不要修改代码。

错误现象：……

复现步骤：……

日志/堆栈：……

期望结果：……

请你先完成：

1. 判断可能缘由，按概率排序

2. 列出需要查看的文件

3. 输出最小修复方案

4. 给出验证命令

我确认后再开始修改。

9.2 新功能开发SOP

步骤	开发人员要提供	CC应输出
需求澄清	业务目标、输入输出、权限、边界	需求理解和疑问
设计	现有模块、数据表、接口规范	接口设计、表结构、页面结构、影响范围
编码	任务拆分和禁区	后端/前端/脚本/测试代码
验收	验收标准和关键路径	验证步骤、测试结果、说明文档

新功能提示词模板：

请基于现有项目实现一个新功能：……

业务规则：

– ……

技术约束：

– 遵守CLAUDE.md

– 不修改……目录

– 数据库变更必须提供迁移脚本和回滚脚本

请先输出设计方案，包括：

1. 涉及文件

2. 数据结构

3. 接口设计

4. 前端页面/组件

5. 验证步骤

确认后再编码。

9.3 代码审查SOP

请对当前分支相对main的diff做代码审查。

重点检查：

1. 业务逻辑是否偏离需求

2. 权限和数据安全风险

3. 空指针/异常处理/边界条件

4. SQL性能和事务一致性

5. 前端交互和接口字段一致性

6. 是否缺少测试和文档

请按“严重/一般/提议”分级输出，不要直接修改代码。

十、团队落地制度

10.1 团队分级目标

等级	能力要求	通过标准
L1 会用	能安装、启动、提问、让CC解释代码	能独立完成代码阅读和文档生成
L2 能控	会用计划模式、Git、/compact、/rewind	能安全完成小Bug修复
L3 能交付	会写任务卡、拆需求、让CC完成新功能	能交付经过验证的中小需求
L4 能治理	会维护CLAUDE.md、脚本、Hooks、团队模板	能把项目经验沉淀为团队规范
L5 能编排	会使用Sub-Agent、MCP、Skills做复杂任务	能主导AI辅助研发流程优化

10.2 项目落地检查表

检查项	是否完成
项目根目录是否有CLAUDE.md	□
是否明确启动、测试、构建、lint命令	□
是否明确禁止修改目录和高风险文件	□
是否建立任务卡模板	□
是否要求每次任务输出变更说明、验证结果、回滚方案	□
是否要求大任务必须先计划后执行	□
是否有Git分支和提交规范	□
是否有敏感数据和密钥处理规范	□
是否有团队共享的优秀提示词库	□

10.3 管理提议

·不要只统计“用了多少次CC”，要统计“节省多少工时、减少多少缺陷、沉淀多少规范”。

·每个项目每周复盘一次：哪些提示词有效、哪些规则要写进CLAUDE.md、哪些风险要加入禁区。

·鼓励开发人员提交“AI协作案例”：问题、提示词、过程、效果、可复用模板。

·把优秀实践沉淀为项目级模板、公司级Skill和内部培训案例。

附录A：常用命令速查表

命令/操作	用途	注意事项
claude –version	验证安装是否成功	首次安装后执行
claude	进入CC交互	提议在项目根目录执行
/model	切换模型配置	不同模型效果和成本不同
/context	查看上下文占用	长任务中定期查看
/compact	压缩上下文	保留关键内容继续任务
/clear	清空上下文	切换任务或上下文污染时使用
/memory	管理记忆	修正错误记忆或补充稳定规则
/rewind 或双击ESC	回滚AI编辑	不能撤回终端命令影响
@filename	引用具体文件	提高定位精度
拖拽图片	多模态输入	适合UI参考和截图分析
Shift+Tab	权限模式切换	不同版本可能略有差异，以本地为准

附录B：新人一周上手训练清单

天数	训练目标	任务
第1天	安装与基础使用	完成安装、启动、解释一个已有模块
第2天	文件引用与代码阅读	使用@file分析一个接口调用链
第3天	Git与回滚	在独立分支让CC修复一个小Bug，并完成回滚演练
第4天	CLAUDE.md	为一个项目补充启动命令、编码规范和禁区
第5天	新功能小闭环	按任务卡完成一个小功能：计划、编码、验证、提交说明
第6天	代码审查	让CC审查一次diff并人工判断问题有效性
第7天	复盘沉淀	提交一份可复用提示词和一个项目规则改善提议