Claude Code 本地工作流快速上手

用户791816245302
10 阅读11分钟

这份文档给第一次接触 Claude Code 本地工作流的同事使用，目标是让你在 10 到 15 分钟内完成安装、模型切换和首次上手。

1. Claude Code是什么

Claude Code 本地工作流，可以理解为一个运行在你电脑上的 AI 助手，主要通过两种入口工作：

  • VS Code 插件：适合在编辑器里边看代码边协作

  • CLI：适合开发同事直接在项目目录里进行操作

它的核心价值不是“聊天”，而是直接参与工作流，例如：

  • 阅读项目代码并解释逻辑

  • 根据需求修改代码

  • 生成测试点、测试脚本、接口调用示例

  • 协助整理 PRD、技术方案、操作文档

  • 通过 skill 调用特定能力，完成更专业的任务

2. 适合谁用

开发同事常见用法：

  • 读代码，快速理解陌生模块

  • 定位 bug，生成修复建议

  • 改小功能，补注释和文档

  • 写 SQL、脚本、接口示例

测试同事常见用法：

  • 根据需求生成测试点

  • 生成接口测试脚本

  • 生成回归测试 checklist

  • 帮助分析报错日志

产品经理或其他岗位常见用法：

  • 梳理需求说明

  • 优化 PRD 结构和表达

  • 生成会议纪要、操作手册

  • 把口头流程整理成标准文档

3. 安装方式

3.1 VS Code 插件安装

如果你平时主要在 VS Code 里工作，推荐优先使用插件方式。

适合以下场景：

  • 想在编辑器里直接和 Claude Code 协作

  • 一边看代码一边提问、修改

  • 不想频繁切出终端

典型安装方式：

  1. 打开 VS Code
  2. 进入扩展市场
  3. 搜索 Claude Code
  4. 安装对应插件
  5. 按插件提示完成登录或接入本地工作流

安装完成后，通常可以在 VS Code 侧边栏、命令面板或聊天面板中使用 Claude Code。

推荐用法：

  1. 先在 VS Code 中打开本地项目
  2. 确认插件已经连接成功
  3. 先让它阅读当前仓库，再开始具体任务

插件方式的优势：

  • 直接结合当前打开的项目和文件工作

  • 看代码、改代码、问问题在一个界面里完成

  • 对开发同事最顺手

3.2 CLI 安装

CLI 是开发同事的主力入口，通常在终端中使用。

安装方式

npm install -g @anthropic-ai/claude-code

claude --version

典型使用方式：

  1. 打开终端
  2. 进入项目目录
  3. 启动 Claude Code
  4. 直接在当前代码仓库中提问或下达任务

示例：

cd your-project
claude

3.3 环境要求

建议具备以下基础环境：

  • 可以正常打开终端

  • 已安装 Git

  • 开发场景下，能够进入本地项目目录

  • 已准备好可用模型渠道，尤其是国内模型接入方式

4. 首次配置

4.1 先理解模型配置

Claude Code 本地工作流本身是一个工作界面，真正回答问题的是背后接入的模型。
如果你计划使用国内模型，重点不是“登录官方账号”，而是把本地工作流切换到你们可用的模型源。

常见思路：

  • 使用团队提供的模型配置

  • 使用兼容 Anthropic 格式的国内模型平台

  • 根据个人体验来配置不同模型

4.2 cc switch 是做什么的

cc switch 可以理解为“切换当前使用的工作配置或模型配置”。

它通常用于：

  • 在不同模型之间切换

  • 在不同 provider 之间切换

  • 在不同团队配置之间切换

你可以把它理解为：

“平时不用每次手动改配置文件，直接切换到一套现成配置。”

示例思路：

cc switch

执行后，通常会让你选择：

  • 当前使用哪个模型

  • 当前走哪个渠道

  • 当前使用哪套默认配置

如果你们团队已经预置了多个选项，日常最常用的动作就是：

  • 写代码前切到高质量模型

  • 普通问答切到便宜模型

  • 需要稳定输出文档时切到更擅长中文的模型

4.3 如何配置国内模型

这一部分以“思路”为主，具体参数以你们团队的配置方式为准。

通常你需要准备：

  • API Base URL

  • API Key

  • 模型名称

  • 默认模型或别名

常见流程是：

  1. 准备国内模型平台的密钥
  2. 写入本地配置
  3. 通过 cc switch 或配置文件设为默认模型
  4. 启动后做一次简单验证

建议团队统一命名，例如：

  • fast：速度优先，适合普通问答

  • dev：代码能力优先

  • doc：中文文档能力优先

这样同事更容易理解切换逻辑。

4.4 如何判断模型是否配置成功

启动后先做两个最简单的验证：

  1. 让它回答一个普通问题
  2. 让它读取当前目录并总结内容

例如：

  • “请总结一下当前目录里有哪些文件”

  • “请用中文解释这个项目是做什么的”

如果能稳定返回结果，说明配置基本可用。

5. 日常使用

5.1 从 VS Code 开始

如果你平时本来就在 VS Code 里开发，插件方式通常是最自然的入口。

常见流程：

  1. 用 VS Code 打开项目目录
  2. 打开 Claude Code 插件面板
  3. 先让它解释当前项目，再逐步下达任务

推荐的第一句：

  • “先阅读当前仓库，不要修改代码，告诉我项目结构、启动方式和核心模块。”

适合在 VS Code 插件里做的事情：

  • 阅读当前文件或当前模块

  • 让它解释报错和代码逻辑

  • 针对局部需求做小步修改

  • 生成注释、文档、测试样例

5.2 从 CLI 开始

CLI 更适合在项目目录里直接工作。

常见流程：

cd your-project
claude

进入后，你可以直接说：

  • “先阅读这个项目，告诉我主要模块和启动方式”

  • “帮我定位登录接口超时可能的原因”

  • “根据这个需求修改代码，并说明改动点”

CLI 的优势在于：

  • 它知道你当前在哪个项目里

  • 它能结合代码、目录和文件上下文工作

  • 对开发和测试更高效

5.3 日常高频任务

推荐把任务拆小，不要一上来就说“帮我重构整个项目”。

更好的方式是分步：

  1. 先读
  2. 再分析
  3. 再改
  4. 最后验证

例如：

  • 第一步：“先阅读订单模块，说明核心流程”

  • 第二步：“找出最可能导致重复下单的逻辑点”

  • 第三步：“只修改这个问题，不要动其他逻辑”

  • 第四步：“给出需要我手动验证的点”

5.4 非开发岗位怎么用

虽然 Claude Code 的主场景是 CLI，但非开发岗位同样可以使用，只是更适合处理文档和说明类任务，而不是直接修改本地项目。

适合的任务：

  • 整理需求文档

  • 输出会议纪要

  • 梳理流程说明

  • 生成测试点和回归 checklist

推荐方式：

  1. 先准备好需求、日志、接口文档或说明材料
  2. 在会话里明确自己的角色和目标
  3. 让它先整理结构，再细化内容

例如：

  • “我是产品经理，请把下面的需求整理成 PRD 草稿，分为背景、目标、流程、边界情况。”

  • “我是测试工程师，请根据这段需求输出测试点、异常场景和回归关注项。”

6. 按岗位使用示例

6.1 开发同事

场景 1：快速读代码

cd your-project
/init

可以这样问：

  • “先阅读这个仓库，不要修改代码，告诉我项目结构、启动方式和核心模块。”

场景 2：修 bug

可以这样问：

  • “这个接口返回 500，请根据报错日志和相关代码，分析最可能原因，并给出最小修改方案。”

场景 3：补文档

可以这样问：

  • “根据当前代码实现，帮我整理订单同步流程说明，面向新同事阅读。”

6.2 测试同事

场景 1：生成测试点

  • “根据这段需求，输出功能测试点、异常测试点和回归关注点。”

场景 2：生成接口脚本

  • “根据这个接口文档，帮我生成 curl 示例和 Postman 可参考的请求参数说明。”

场景 3：分析日志

  • “这是失败日志，请先解释报错，再列出建议排查顺序。”

6.3 产品经理

场景 1：整理需求

  • “把下面这段口语化需求整理成结构化 PRD，要求表述清晰，保留待确认项。”

场景 2：梳理流程

  • “根据下面的业务描述，帮我整理用户流程、系统处理流程和异常分支。”

场景 3：输出沟通材料

  • “帮我把这段需求说明改成适合发给研发和测试的版本，强调输入、输出和边界。”

7. Skill 是什么

可以把 skill 理解成“给 AI 加的一套专用能力说明书”。

普通对话适合处理通用任务，skill 更适合处理某类专业任务，例如：

  • 抓取网页正文

  • 识别图片文字

  • 生成图示

  • 查阅指定产品文档

  • 按固定流程完成某类任务

它的作用是：

  • 让 AI 按预设流程办事

  • 降低提示词成本

  • 提高特定任务的稳定性

7.1 什么时候该用 skill

以下情况建议优先考虑 skill：

  • 任务很固定，重复很多次

  • 你希望输出格式稳定

  • 某项工作需要专门工具或专门步骤

  • 普通提问效果不稳定

7.2 怎么触发 skill

不同环境的触发方式可能略有差异，但通常有两类方式：

  • 明确提到 skill 名称

  • 提出明显匹配某个 skill 的任务

例如：

  • “用网页抓取相关 skill 读取这篇文章并总结”

  • “帮我从这个图片里提取文字”

  • “生成一个流程图”

7.3 skill 的典型例子

开发或知识工作中常见的 skill 使用方式：

  • 读取网页并提炼重点

  • 根据说明生成图表或流程图

  • 从图片或 PDF 中提取文本

  • 查询某个平台的官方文档

对同事来说，不需要一开始就记住所有 skill。
先记住一个原则：

“如果某类任务你做了很多次，而且每次都想要更稳定的结果，就值得看看有没有对应 skill。”

8. 推荐使用习惯

以下习惯会直接影响使用效果。

8.1 先让它读，再让它改

不要一上来就让它改很多内容。
先让它解释它读到了什么，再决定是否继续。

推荐说法：

  • “先阅读，不要修改。”

  • “先总结你的理解，再等我确认。”

8.2 一次只做一件大事

不要把多个目标混在一起，例如：

  • 一边排查 bug

  • 一边顺手重构

  • 一边补文档

这样容易失控。
更好的方式是一个会话只推进一个主目标。

8.3 明确限制条件

如果你不说限制条件，AI 默认会“尽量完成任务”，这可能带来额外改动。

常见限制条件：

  • “只分析，不修改”

  • “只改这个文件”

  • “不要改接口定义”

  • “优先最小改动”

  • “输出中文”

8.4 改完一定要验证

AI 不是最终责任人。
它写出来的代码、脚本、文档，都需要你自己确认。

至少要做这些动作：

  • 看改动是否符合目标

  • 看是否误改其他文件

  • 跑一下测试或最小验证

  • 检查输出是否有想当然的内容

9. 常见问题

9.1 为什么有时效果很好，有时一般

常见原因：

  • 背景信息不够

  • 任务范围太大

  • 模型切换了，但你没注意

  • 当前模型不适合该任务

解决方式：

  • 把任务拆小

  • 明确输入和输出

  • 用 cc switch 检查当前模型

  • 对复杂任务换更强模型

9.2 为什么不建议一上来就让它“重构全部”

因为这类任务范围太大，风险太高，容易出现：

  • 改动过多

  • 偏离原目标

  • 引入无关修改

  • 你自己也难以 review

更稳妥的方式是：

  • 先分析现状

  • 只处理一个具体问题

  • 每次小步提交

9.3 非技术同事能不能用

可以。
尤其适合：

  • 整理文档

  • 总结会议纪要

  • 改写说明材料

  • 梳理流程和待确认项

只要把任务说清楚，非技术岗位同样能获得很高价值。

10. 推荐的第一次上手流程

如果你是第一次用，建议按这个顺序：

  1. 安装 CLI
  2. 配置好国内模型
  3. 运行一次 cc switch，确认当前默认模型
  4. 先做一个轻任务，例如总结目录或整理一段文本
  5. 再做一个和自己岗位相关的小任务

例如：

  • 开发：让它解释一个模块

  • 测试：让它生成测试点

  • 产品：让它整理需求描述

11. 给同事的最短建议

如果只记住三句话，记这三句：

  • 先让它读，再让它改

  • 任务拆小，效果更稳

  • 用 cc switch 管理模型切换，用 skill 处理专业任务

如果后续要继续扩展，这份文档可以再补两部分：

  • 团队内部的实际安装和配置截图

  • 你们当前可用的国内模型名单与推荐场景

avatar
文章
阅读
粉丝