很多人第一次打开 Claude Code第一反应是这不就是另一个 AI 编程助手吗能写代码能解释代码能生成文档能跑命令。看起来和 Cursor、Copilot、Windsurf 没有太大区别。但真正用上一段时间后会发现它的重点不在“多补几行代码”。Claude Code 更有意思的地方是把 AI 放进了终端工作流里。你可以让它读项目、看文件、跑测试、分析报错、查看 diff、整理提交信息甚至通过 CLAUDE.md 记住项目规则。它不是停留在聊天框里回答问题而是开始参与一条完整的工程链路。这也是 Claude Code 最近被很多开发者重新讨论的原因。AI 编程正在从“会不会写代码”转向“能不能进入真实项目流程”。这篇文章我们就从工程实践角度聊聊Claude Code 到底该怎么用为什么很多人用了一圈还觉得浅以及测试开发工程师能从里面看到什么机会。目录Claude Code 和普通代码助手差在哪为什么说它不是简单的“代码补全工具”快速上手先跑通基础环境三个小实验理解它的工作方式11 个真正影响效率的核心技巧CLAUDE.md让 AI 理解你的项目.claudeignore别让上下文变成垃圾桶权限配置让 AI 能干活但不能乱来测试开发视角Claude Code 最值得用在哪些场景真正的门槛不是安装而是工程化使用习惯一、Claude Code 和普通代码助手差在哪过去我们用 AI 编程工具更多是在编辑器里完成局部动作。写一个函数。 解释一段代码。 补全几行逻辑。 根据注释生成代码。 帮忙看一个报错。这类能力当然有价值但它们大多还停留在“局部辅助”。真正复杂的工程开发不是只写代码。一个真实任务往往要经历理解需求 阅读项目结构 找到相关文件 判断技术栈 修改代码 运行测试 分析报错 继续修复 查看 diff 整理提交信息 沉淀文档。Claude Code 的价值就在于它不是只停留在“生成代码”这一步而是能参与这条链路。它运行在终端里可以围绕项目文件、命令执行、测试结果、Git 变更和项目配置持续协作。换句话说它更像是一个终端里的 AI 工程搭档。如果只把它当成“会写代码的聊天窗口”很容易用浅。它真正的价值是进入工程流程。二、为什么说它不是简单的代码补全工具普通代码补全工具解决的是“当前这一段代码怎么写”。Claude Code 更接近解决这个项目该怎么改 这个测试为什么失败 这次 diff 改了什么 这个模块缺哪些测试 这个任务应该怎么拆 这个项目规则怎么让 AI 记住。举个例子。你可以直接让它做一个完整任务帮我给用户登录模块补充单元测试运行测试如果失败就分析原因并修复。这句话背后其实包含多个动作找到登录模块相关代码判断项目使用什么测试框架生成测试文件覆盖正常登录、异常账号、密码错误、空参数等场景执行测试命令根据失败日志修复测试或代码再次运行验证这已经不是单点代码生成而是一个小型工程闭环。测试开发工程师应该特别关注这一点。因为测试工作本来就不是只写脚本而是围绕需求、风险、数据、执行、结果、回归形成闭环。Claude Code 对测试开发最大的启发不是“AI 能写自动化脚本了”。而是AI 开始具备参与测试工程流程的能力。三、快速上手先把基础环境跑通Claude Code 基于 Node.js 构建安装前需要确认本地 Node.js 版本不低于 18。常规安装方式如下npm install -g anthropic-ai/claude-code claude --version进入项目目录后启动cd /path/to/your/project claude首次启动时一般会经历几个步骤登录 Anthropic 账户 选择使用计划 确认服务条款 可选配置 API 密钥。对于国内用户来说可能会遇到网络访问或 API 配置问题。如果使用兼容 Anthropic API 格式的服务一般需要配置 API 地址和密钥。这里不建议一开始就手工复制一堆命令乱配。更稳妥的方式是让已有 AI Agent 帮你检查环境比如安装 claude code cli并检查 Node.js 版本是否兼容。或者帮我配置 Claude Code 的 API 地址和密钥并验证是否能正常启动。这样可以避免很多基础环境问题。真正要关注的不是“能不能装上”而是装好之后怎么进入项目流程。四、三个小实验先理解它的工作方式很多人刚装好 Claude Code就直接打开公司项目让它改业务代码。这其实不太稳。工具没熟悉权限没配置上下文没建立Git 状态也不干净很容易出现“改了一堆但不敢用”的情况。建议先做三个小实验。实验 1先看它怎么理解问题可以输入你好你是谁再试一个技术问题什么是闭包太长不看版本。再试一个对比问题JavaScript 和 TypeScript 有什么区别这一步不是为了学习这些知识而是观察它的回答结构。好的工程协作不只是答案正确还要表达清楚。Claude Code 的回答通常会先给核心判断再展开细节。这种结构适合快速获取信息也适合后续让它帮你写文档、整理方案、生成复盘。实验 2让它生成一份 Markdown 文档可以输入帮我写一份 Git 常用命令的 Markdown 文档。 要求包含命令、说明、示例。它一般会按照场景组织内容初始化仓库 日常提交 分支管理 远程协作 冲突处理 回滚操作。这个实验可以验证它的结构化输出能力。对测试开发来说这类能力很实用。测试方案、接口测试说明、自动化框架文档、缺陷复盘、上线检查清单都可以先让它生成初稿再由人来审核和补充。实验 3让它写一个可运行的小程序比如输入用 Python 写一个贪吃蛇游戏。 要求 1. 使用 pygame 库 2. 有分数显示 3. 按 ESC 退出 写完后帮我运行它。这个实验能看到 Claude Code 的完整链路这一步非常关键。因为你会发现它不是只会“输出一段代码”。它可以创建文件、执行命令、读取报错、继续修复。这才是 Claude Code 和普通聊天式编程助手的明显区别。五、11 个真正影响效率的核心技巧Claude Code 上手不难真正拉开差距的是下面这些用法。1. 双击 Esc别让错误对话继续滚下去AI 协作最常见的问题不是它不会回答而是它开始沿着错误方向回答。你说错了一个条件。 它理解错了一个需求。 你发现刚才的问题问得不准确。 它已经开始往不该改的方向走。这时候不要硬聊。Claude Code 里可以用 Esc 快速回退按一次 Esc清除当前输入 按两次 Esc回退上一轮对话 按三次 Esc清空对话历史但这里有一个重要细节Esc 回退的是对话状态不是代码文件。如果 Claude Code 已经修改了文件Esc 不会自动撤销文件变更。所以在正式项目里大改之前最好先保证 Git 状态干净。比如git status git add . git commit -m chore: save current work before claude session或者至少git stash push -m before claude sessionAI 可以大胆用但回滚手段必须提前准备好。2. 引用文件让 AI 看准确的上下文很多人会这样问帮我看看登录模块有没有问题。这个问题太模糊。更好的方式是src/services/auth.ts tests/login.test.ts 帮我分析登录逻辑和现有测试覆盖情况。引用文件的好处是让 AI 明确读取哪些文件 减少无关上下文 降低误判概率 节省 Token 让回答更贴近项目实际。比如测试开发场景可以这样用openapi.yaml 请基于接口定义设计接口测试用例覆盖正常场景、参数缺失、非法参数、权限异常和幂等性问题。或者tests/e2e/login.spec.ts 这个 Playwright 用例最近不稳定请分析可能原因并优化等待策略。当你给的上下文越精准它越容易输出可用结果。3. ! 执行命令把测试和构建纳入对话Claude Code 支持直接执行终端命令!npm test!git status!npm run build这意味着你可以让它参与测试闭环!npm test 测试失败了请分析失败原因并判断是业务代码问题还是测试代码问题。这个能力对测试开发非常重要。因为测试工程的核心不是写完脚本而是跑起来、看结果、定位问题、修复问题、再次验证。过去这条链路需要人在多个窗口之间切换。Claude Code 可以把它收进一个终端工作流。4. /plan复杂任务先拆不要直接让它开写很多人用 Claude Code 翻车都是因为一上来就让它直接改。比如帮我实现用户认证功能。这个需求太大。更好的做法是先进入规划模式/plan 我想添加用户认证功能请帮我制定实施计划。它会先分析项目结构然后拆出阶段用户表设计 注册接口 登录接口 Token 或 Session 机制 权限中间件 前端登录页 异常处理 单元测试 集成测试。这一步非常重要。因为复杂任务真正难的不是写代码而是边界拆分。没有计划就让 AI 改代码本质上是在让它替你做架构判断。这很危险。正确方式应该是先让 AI 给方案 人来判断方案是否合理 再让 AI 分阶段执行 每完成一阶段就检查 diff 和测试结果。5. /init生成项目说明书 CLAUDE.md/init是 Claude Code 里非常关键的命令。它会扫描项目结构读取配置文件分析技术栈和常用命令然后生成一份CLAUDE.md。这个文件可以理解为 Claude Code 的项目记忆。最小可用版本大概长这样# 项目名称 ## 技术栈 - 前端React 18 TypeScript - 构建工具Vite - 测试框架Vitest Playwright - 样式方案Tailwind CSS ## 常用命令 bash npm run dev npm run test npm run build npm run lint代码规范组件使用函数组件API 请求统一走 request 封装提交信息遵循 Conventional Commits测试文件统一放在 tests 目录有了这个文件Claude Code 每次进入项目时就能知道 项目用什么技术栈 怎么启动 怎么测试 代码风格是什么 哪些目录放什么内容 团队约定是什么。 没有 CLAUDE.md 的项目AI 每次都像新来的同事。 有了 CLAUDE.mdAI 至少知道项目的基本规矩。 --- ## 6. /compact长对话一定要压缩上下文 很多人用 AI 工具时会遇到一个现象 刚开始回答挺准聊着聊着就开始跑偏。 这不一定是模型突然变差了很可能是上下文变脏了。 长对话会积累大量内容 已经废弃的方案 中间尝试过的错误 不再需要的文件 临时讨论的问题 旧的需求表述。 这些信息都会占用 Token也会影响判断。 可以用 bash /compact它会把当前对话压缩成摘要只保留关键决策和当前状态。建议在这些场景使用连续聊了 5 到 6 轮之后 完成一个阶段准备进入下一个阶段之前 感觉它开始遗忘重点时 上下文使用率明显变高时。AI 协作不是上下文越多越好。真正高效的上下文应该是干净、准确、可复用。7. /diff让 AI 解释变更而不是盲目提交写代码只是第一步。工程里更重要的是知道改了哪些文件 为什么这么改 有没有引入风险 测试是否覆盖 提交信息是否清楚。可以用/diff然后继续问请基于当前 diff 总结这次变更指出潜在风险并生成一个 Conventional Commit message。推荐的 Git 工作流是/diff 请总结当前变更并生成提交信息。 !git add -A !git commit -m feat: xxx不要让 AI 在你没看 diff 的情况下直接提交。这就像让一个新同事不经过 Code Review 直接合并代码。AI 可以帮你提高效率但不能替你承担工程责任。8. Shift Tab自动接受修改但别一上来就开Claude Code 默认在修改文件前会询问确认。这是好事。学习阶段建议保留默认模式因为你需要知道它到底要改什么。熟悉之后可以用Shift Tab开启自动接受模式减少反复确认。但开启自动接受前最好满足几个条件当前 Git 状态是干净的 你清楚它要修改哪些文件 任务范围比较明确 不是在改部署、权限、支付、生产配置等敏感逻辑。否则自动接受很容易变成自动翻车。9. Ctrl C方向错了就及时刹车当 Claude Code 正在执行长任务或者你发现它理解错了不要等它全部做完。直接Ctrl C停止当前操作。它和 Esc 的区别是Ctrl C停止正在执行的操作 双击 Esc回退上一轮对话状态一个是刹车一个是回退。用 AI 编程一定要有打断意识。很多问题不是 AI 一开始就不可控而是人发现方向不对后没有及时停下来。10. /context看清 Token 到底花在哪当你觉得 Claude Code 响应慢、成本高、回答变乱可以用/context它会显示当前上下文使用情况。重点看几个信息Token 使用率 引用了多少文件 哪些文件占用最多上下文 是否读入了无关目录。如果发现 node_modules、构建产物、日志文件、大型资源文件进入上下文那就说明.claudeignore需要调整。Token 不只是成本问题也是质量问题。上下文越脏AI 越容易抓错重点。11. /resume多任务切换时保留上下文当你在多个任务之间来回切换可以用/resume它可以帮助你回到之前的会话状态。比如你刚才在修登录 bug中间临时问了一个算法问题之后想回到原来的修复任务就可以用/resume。对于长周期任务来说这个命令可以减少重复解释上下文的成本。但如果会话已经很长建议先/compact再继续后续任务。六、CLAUDE.md决定 AI 能不能真正理解项目如果一个项目没有 CLAUDE.mdClaude Code 对项目的理解主要依赖临时读取文件和你的描述。这就很容易出现几个问题每次都要解释技术栈 每次都要告诉它测试命令 每次都要说明代码规范 每次都要提醒它目录结构 多人协作时规则不统一。一个好的 CLAUDE.md至少应该包含这些内容# 项目名称 ## 项目概述 一句话说明项目做什么服务什么用户核心业务是什么。 ## 技术栈 - 前端框架 - 后端框架 - 数据库 - 测试框架 - 构建工具 - 部署方式 ## 项目结构 说明 src、tests、components、services、api 等目录的用途。 ## 常用命令 - 启动开发环境 - 运行测试 - 类型检查 - 代码格式化 - 生产构建 ## 编码规范 - 命名规则 - 组件写法 - API 封装方式 - 错误处理方式 - 日志规范 ## 测试规范 - 单元测试放哪里 - E2E 测试怎么跑 - 哪些模块必须补测试 - Bug 修复是否需要回归测试 ## 常见坑 - 哪些文件不要改 - 哪些接口有历史兼容问题 - 哪些配置涉及生产环境这份文件不是给老板看的也不是给客户看的。它是写给 AI 的项目说明书。越清楚Claude Code 越不容易乱来。七、.claudeignore别让上下文变成垃圾桶Claude Code 能读取项目上下文但不是所有文件都应该让它读。很多项目 Token 消耗异常高不是因为任务复杂而是因为上下文里混进了大量没用内容。建议.claudeignore至少包含node_modules/ dist/ build/ .next/ coverage/ *.log .env .env.local .vscode/ .idea/ *.png *.jpg *.jpeg *.gif *.mp4这些文件的问题很明显依赖目录太大 构建产物没有必要 日志文件噪音多 环境变量可能包含敏感信息 图片视频对多数代码任务没帮助。合理配置.claudeignore通常能带来三个变化响应更快 Token 消耗更低 回答更聚焦。很多人只关注提示词怎么写却忽略了上下文治理。但在真实工程里上下文治理比提示词更重要。八、权限配置让 AI 能干活但不能乱来Claude Code 可以执行命令、修改文件所以权限配置不能忽视。权限通常分成三类{ permissions: { allow: [], ask: [], deny: [] } }可以这样理解allow安全操作自动允许 ask有风险操作执行前确认 deny危险操作直接禁止。例如{ permissions: { allow: [ Bash(git status), Bash(git diff:*), Bash(npm test:*), Bash(npm run lint:*), Edit(src/**/*.{ts,tsx}), Edit(tests/**/*.test.ts) ], ask: [ Bash(git commit:*), Bash(git push:*), Bash(npm install:*), Bash(npm run build), Edit(package.json), Edit(tsconfig.json) ], deny: [ Bash(rm -rf:*), Bash(sudo:*), Bash(curl * | sh), Bash(wget * | sh), Read(.env) ] } }这个配置背后的原则很简单只读操作可以放宽 测试和 lint 可以放宽 提交、推送、安装依赖要确认 危险命令和敏感文件要禁止。AI 工具越强越要有边界。不是不信任 AI而是不应该让任何工具绕过工程安全底线。九、测试开发视角Claude Code 最值得用在哪些场景对测试开发工程师来说Claude Code 不是只用来写业务代码的。它更适合放到测试工程链路里。1. 辅助生成自动化测试用例比如src/services/order.ts 请为订单创建逻辑生成单元测试重点覆盖边界值、异常输入、状态流转和重复提交。它可以根据代码逻辑反推测试场景。但注意AI 生成的用例不能直接当最终结果。测试人员要重点审核是否覆盖核心业务风险 断言是否有意义 边界条件是否完整 异常路径是否真实存在 测试数据是否可维护。AI 适合补充思路不适合替你做最终质量判断。2. 分析失败用例可以这样用!npm test 测试失败了请分析失败原因判断是业务逻辑问题、测试断言问题还是环境问题。这类场景非常适合 Claude Code。因为它可以结合测试输出、源码和测试文件一起分析。传统流程里你可能需要复制日志、打开文件、搜索调用链、重新跑命令。Claude Code 能把这些动作合在一个会话里。3. 生成接口自动化脚本如果项目里有 OpenAPI、Swagger 或接口文档可以这样问openapi.yaml 请基于这个接口文档生成 Pytest Requests 的接口测试脚本。 要求覆盖正常场景、参数缺失、非法参数、权限异常和幂等性问题。它可以快速生成接口测试初稿。再由测试人员补充业务前置数据 鉴权逻辑 环境变量 数据清理 接口依赖关系 断言策略。这样比从零手写脚本效率高很多。4. 优化 UI 自动化稳定性UI 自动化最常见的问题不是写不出来而是不稳定。比如 Playwright 用例偶现失败可以让 Claude Code 分析tests/e2e/login.spec.ts 这个 Playwright 用例最近经常失败请分析可能的不稳定原因并优化等待策略。它可能会从这些角度给出建议定位器是否稳定 是否依赖固定 sleep 页面跳转是否等待完成 接口返回是否有异步延迟 测试数据是否相互污染 断言是否过早执行。这类问题非常贴近测试开发日常。5. 重构测试框架目录当测试代码越写越多目录结构往往会变乱。可以让 Claude Code 先做分析tests/ 请分析当前测试目录结构给出一套更适合维护的分层方案。它可以从这些维度整理单元测试 接口测试 E2E 测试 测试数据 公共 fixture 页面对象模型 断言工具 测试报告。这对测试框架治理很有帮助。6. 生成缺陷复盘和回归建议Bug 修完之后不要只停留在代码修复。可以基于 diff 生成复盘/diff 请基于这次 bug 修复生成一份缺陷复盘文档。 包括问题现象、根因分析、影响范围、修复方案和回归测试建议。这类能力非常适合团队沉淀知识库。尤其是测试团队很多经验如果不沉淀就会一直停留在个人脑子里。Claude Code 可以帮助把一次修复变成可复用的团队资产。十、一个更适合测试开发的 Claude Code 工作流如果从测试开发角度使用 Claude Code我更建议采用下面这条流程这里面AI 不是替代测试工程师。AI 负责提高产出速度。人负责判断质量。哪些场景必须测 哪些风险不能漏 哪些断言才有业务意义 哪些失败属于环境问题 哪些缺陷值得复盘 哪些自动化脚本需要长期维护。这些仍然是测试开发工程师的核心价值。十一、Claude Code 用不好往往不是工具问题很多人用 Claude Code 用得浅不是因为工具不行而是使用方式还停留在问答模式。常见问题有几个。1. 需求太模糊比如帮我优化一下代码。这类问题很难得到高质量结果。更好的写法是src/components/UserList.tsx 请从渲染性能、状态管理、重复逻辑和可测试性四个角度审查这个组件并给出可执行的修改方案。2. 不给上下文如果不告诉它项目结构、相关文件、测试命令、业务规则它只能泛泛而谈。AI 不是神它需要上下文。但上下文不是越多越好而是越准确越好。3. 不看 diff让 Claude Code 改完代码之后一定要看 diff。不看 diff就相当于让一个刚接触项目的人直接提交代码。这是工程风险不是工具问题。4. 不配置 .claudeignore把 node_modules、构建产物、日志、临时文件都丢进上下文只会让 AI 越来越糊涂。很多回答不准根源不是模型能力而是上下文太脏。5. 没有 Git 保护AI 改代码之前至少要知道怎么回滚。建议养成习惯git status确认当前分支状态。大改之前先提交或 stash。这是使用任何 AI 编程工具的底线。十二、最后AI 编程的门槛正在变Claude Code 的出现说明 AI 编程正在发生一个变化。过去大家关心的是AI 能不能写代码 AI 能不能补全函数 AI 能不能解释报错 AI 能不能生成脚本。现在更应该关心的是AI 能不能理解项目 能不能遵守团队规范 能不能参与测试闭环 能不能看懂 diff 能不能管理上下文 能不能在权限边界内执行任务 能不能把开发、测试、提交、复盘串起来。这才是 Claude Code 值得学习的地方。它不是让工程能力变得不重要。恰恰相反它会放大工程能力的差距。懂项目结构的人能写出更好的 CLAUDE.md。 懂测试策略的人能判断 AI 生成的用例是否有效。 懂 Git 工作流的人敢让 AI 参与真实项目。 懂上下文治理的人能控制成本和质量。 懂权限边界的人能让 AI 高效但不失控。未来的差距不会只体现在“谁会用 AI 写代码”。更大的差距会体现在谁能把 AI 放进自己的工程流程里形成稳定、可控、可复用的生产力。Claude Code 最强的地方也许不是写代码本身。而是它让我们重新思考一个开发者、一个测试开发工程师应该如何把 AI 纳入真实的工程协作流程。
Claude Code 用了两周后，我发现它最强的不是写代码
很多人第一次打开 Claude Code第一反应是这不就是另一个 AI 编程助手吗能写代码能解释代码能生成文档能跑命令。看起来和 Cursor、Copilot、Windsurf 没有太大区别。但真正用上一段时间后会发现它的重点不在“多补几行代码”。Claude Code 更有意思的地方是把 AI 放进了终端工作流里。你可以让它读项目、看文件、跑测试、分析报错、查看 diff、整理提交信息甚至通过 CLAUDE.md 记住项目规则。它不是停留在聊天框里回答问题而是开始参与一条完整的工程链路。这也是 Claude Code 最近被很多开发者重新讨论的原因。AI 编程正在从“会不会写代码”转向“能不能进入真实项目流程”。这篇文章我们就从工程实践角度聊聊Claude Code 到底该怎么用为什么很多人用了一圈还觉得浅以及测试开发工程师能从里面看到什么机会。目录Claude Code 和普通代码助手差在哪为什么说它不是简单的“代码补全工具”快速上手先跑通基础环境三个小实验理解它的工作方式11 个真正影响效率的核心技巧CLAUDE.md让 AI 理解你的项目.claudeignore别让上下文变成垃圾桶权限配置让 AI 能干活但不能乱来测试开发视角Claude Code 最值得用在哪些场景真正的门槛不是安装而是工程化使用习惯一、Claude Code 和普通代码助手差在哪过去我们用 AI 编程工具更多是在编辑器里完成局部动作。写一个函数。 解释一段代码。 补全几行逻辑。 根据注释生成代码。 帮忙看一个报错。这类能力当然有价值但它们大多还停留在“局部辅助”。真正复杂的工程开发不是只写代码。一个真实任务往往要经历理解需求 阅读项目结构 找到相关文件 判断技术栈 修改代码 运行测试 分析报错 继续修复 查看 diff 整理提交信息 沉淀文档。Claude Code 的价值就在于它不是只停留在“生成代码”这一步而是能参与这条链路。它运行在终端里可以围绕项目文件、命令执行、测试结果、Git 变更和项目配置持续协作。换句话说它更像是一个终端里的 AI 工程搭档。如果只把它当成“会写代码的聊天窗口”很容易用浅。它真正的价值是进入工程流程。二、为什么说它不是简单的代码补全工具普通代码补全工具解决的是“当前这一段代码怎么写”。Claude Code 更接近解决这个项目该怎么改 这个测试为什么失败 这次 diff 改了什么 这个模块缺哪些测试 这个任务应该怎么拆 这个项目规则怎么让 AI 记住。举个例子。你可以直接让它做一个完整任务帮我给用户登录模块补充单元测试运行测试如果失败就分析原因并修复。这句话背后其实包含多个动作找到登录模块相关代码判断项目使用什么测试框架生成测试文件覆盖正常登录、异常账号、密码错误、空参数等场景执行测试命令根据失败日志修复测试或代码再次运行验证这已经不是单点代码生成而是一个小型工程闭环。测试开发工程师应该特别关注这一点。因为测试工作本来就不是只写脚本而是围绕需求、风险、数据、执行、结果、回归形成闭环。Claude Code 对测试开发最大的启发不是“AI 能写自动化脚本了”。而是AI 开始具备参与测试工程流程的能力。三、快速上手先把基础环境跑通Claude Code 基于 Node.js 构建安装前需要确认本地 Node.js 版本不低于 18。常规安装方式如下npm install -g anthropic-ai/claude-code claude --version进入项目目录后启动cd /path/to/your/project claude首次启动时一般会经历几个步骤登录 Anthropic 账户 选择使用计划 确认服务条款 可选配置 API 密钥。对于国内用户来说可能会遇到网络访问或 API 配置问题。如果使用兼容 Anthropic API 格式的服务一般需要配置 API 地址和密钥。这里不建议一开始就手工复制一堆命令乱配。更稳妥的方式是让已有 AI Agent 帮你检查环境比如安装 claude code cli并检查 Node.js 版本是否兼容。或者帮我配置 Claude Code 的 API 地址和密钥并验证是否能正常启动。这样可以避免很多基础环境问题。真正要关注的不是“能不能装上”而是装好之后怎么进入项目流程。四、三个小实验先理解它的工作方式很多人刚装好 Claude Code就直接打开公司项目让它改业务代码。这其实不太稳。工具没熟悉权限没配置上下文没建立Git 状态也不干净很容易出现“改了一堆但不敢用”的情况。建议先做三个小实验。实验 1先看它怎么理解问题可以输入你好你是谁再试一个技术问题什么是闭包太长不看版本。再试一个对比问题JavaScript 和 TypeScript 有什么区别这一步不是为了学习这些知识而是观察它的回答结构。好的工程协作不只是答案正确还要表达清楚。Claude Code 的回答通常会先给核心判断再展开细节。这种结构适合快速获取信息也适合后续让它帮你写文档、整理方案、生成复盘。实验 2让它生成一份 Markdown 文档可以输入帮我写一份 Git 常用命令的 Markdown 文档。 要求包含命令、说明、示例。它一般会按照场景组织内容初始化仓库 日常提交 分支管理 远程协作 冲突处理 回滚操作。这个实验可以验证它的结构化输出能力。对测试开发来说这类能力很实用。测试方案、接口测试说明、自动化框架文档、缺陷复盘、上线检查清单都可以先让它生成初稿再由人来审核和补充。实验 3让它写一个可运行的小程序比如输入用 Python 写一个贪吃蛇游戏。 要求 1. 使用 pygame 库 2. 有分数显示 3. 按 ESC 退出 写完后帮我运行它。这个实验能看到 Claude Code 的完整链路这一步非常关键。因为你会发现它不是只会“输出一段代码”。它可以创建文件、执行命令、读取报错、继续修复。这才是 Claude Code 和普通聊天式编程助手的明显区别。五、11 个真正影响效率的核心技巧Claude Code 上手不难真正拉开差距的是下面这些用法。1. 双击 Esc别让错误对话继续滚下去AI 协作最常见的问题不是它不会回答而是它开始沿着错误方向回答。你说错了一个条件。 它理解错了一个需求。 你发现刚才的问题问得不准确。 它已经开始往不该改的方向走。这时候不要硬聊。Claude Code 里可以用 Esc 快速回退按一次 Esc清除当前输入 按两次 Esc回退上一轮对话 按三次 Esc清空对话历史但这里有一个重要细节Esc 回退的是对话状态不是代码文件。如果 Claude Code 已经修改了文件Esc 不会自动撤销文件变更。所以在正式项目里大改之前最好先保证 Git 状态干净。比如git status git add . git commit -m chore: save current work before claude session或者至少git stash push -m before claude sessionAI 可以大胆用但回滚手段必须提前准备好。2. 引用文件让 AI 看准确的上下文很多人会这样问帮我看看登录模块有没有问题。这个问题太模糊。更好的方式是src/services/auth.ts tests/login.test.ts 帮我分析登录逻辑和现有测试覆盖情况。引用文件的好处是让 AI 明确读取哪些文件 减少无关上下文 降低误判概率 节省 Token 让回答更贴近项目实际。比如测试开发场景可以这样用openapi.yaml 请基于接口定义设计接口测试用例覆盖正常场景、参数缺失、非法参数、权限异常和幂等性问题。或者tests/e2e/login.spec.ts 这个 Playwright 用例最近不稳定请分析可能原因并优化等待策略。当你给的上下文越精准它越容易输出可用结果。3. ! 执行命令把测试和构建纳入对话Claude Code 支持直接执行终端命令!npm test!git status!npm run build这意味着你可以让它参与测试闭环!npm test 测试失败了请分析失败原因并判断是业务代码问题还是测试代码问题。这个能力对测试开发非常重要。因为测试工程的核心不是写完脚本而是跑起来、看结果、定位问题、修复问题、再次验证。过去这条链路需要人在多个窗口之间切换。Claude Code 可以把它收进一个终端工作流。4. /plan复杂任务先拆不要直接让它开写很多人用 Claude Code 翻车都是因为一上来就让它直接改。比如帮我实现用户认证功能。这个需求太大。更好的做法是先进入规划模式/plan 我想添加用户认证功能请帮我制定实施计划。它会先分析项目结构然后拆出阶段用户表设计 注册接口 登录接口 Token 或 Session 机制 权限中间件 前端登录页 异常处理 单元测试 集成测试。这一步非常重要。因为复杂任务真正难的不是写代码而是边界拆分。没有计划就让 AI 改代码本质上是在让它替你做架构判断。这很危险。正确方式应该是先让 AI 给方案 人来判断方案是否合理 再让 AI 分阶段执行 每完成一阶段就检查 diff 和测试结果。5. /init生成项目说明书 CLAUDE.md/init是 Claude Code 里非常关键的命令。它会扫描项目结构读取配置文件分析技术栈和常用命令然后生成一份CLAUDE.md。这个文件可以理解为 Claude Code 的项目记忆。最小可用版本大概长这样# 项目名称 ## 技术栈 - 前端React 18 TypeScript - 构建工具Vite - 测试框架Vitest Playwright - 样式方案Tailwind CSS ## 常用命令 bash npm run dev npm run test npm run build npm run lint代码规范组件使用函数组件API 请求统一走 request 封装提交信息遵循 Conventional Commits测试文件统一放在 tests 目录有了这个文件Claude Code 每次进入项目时就能知道 项目用什么技术栈 怎么启动 怎么测试 代码风格是什么 哪些目录放什么内容 团队约定是什么。 没有 CLAUDE.md 的项目AI 每次都像新来的同事。 有了 CLAUDE.mdAI 至少知道项目的基本规矩。 --- ## 6. /compact长对话一定要压缩上下文 很多人用 AI 工具时会遇到一个现象 刚开始回答挺准聊着聊着就开始跑偏。 这不一定是模型突然变差了很可能是上下文变脏了。 长对话会积累大量内容 已经废弃的方案 中间尝试过的错误 不再需要的文件 临时讨论的问题 旧的需求表述。 这些信息都会占用 Token也会影响判断。 可以用 bash /compact它会把当前对话压缩成摘要只保留关键决策和当前状态。建议在这些场景使用连续聊了 5 到 6 轮之后 完成一个阶段准备进入下一个阶段之前 感觉它开始遗忘重点时 上下文使用率明显变高时。AI 协作不是上下文越多越好。真正高效的上下文应该是干净、准确、可复用。7. /diff让 AI 解释变更而不是盲目提交写代码只是第一步。工程里更重要的是知道改了哪些文件 为什么这么改 有没有引入风险 测试是否覆盖 提交信息是否清楚。可以用/diff然后继续问请基于当前 diff 总结这次变更指出潜在风险并生成一个 Conventional Commit message。推荐的 Git 工作流是/diff 请总结当前变更并生成提交信息。 !git add -A !git commit -m feat: xxx不要让 AI 在你没看 diff 的情况下直接提交。这就像让一个新同事不经过 Code Review 直接合并代码。AI 可以帮你提高效率但不能替你承担工程责任。8. Shift Tab自动接受修改但别一上来就开Claude Code 默认在修改文件前会询问确认。这是好事。学习阶段建议保留默认模式因为你需要知道它到底要改什么。熟悉之后可以用Shift Tab开启自动接受模式减少反复确认。但开启自动接受前最好满足几个条件当前 Git 状态是干净的 你清楚它要修改哪些文件 任务范围比较明确 不是在改部署、权限、支付、生产配置等敏感逻辑。否则自动接受很容易变成自动翻车。9. Ctrl C方向错了就及时刹车当 Claude Code 正在执行长任务或者你发现它理解错了不要等它全部做完。直接Ctrl C停止当前操作。它和 Esc 的区别是Ctrl C停止正在执行的操作 双击 Esc回退上一轮对话状态一个是刹车一个是回退。用 AI 编程一定要有打断意识。很多问题不是 AI 一开始就不可控而是人发现方向不对后没有及时停下来。10. /context看清 Token 到底花在哪当你觉得 Claude Code 响应慢、成本高、回答变乱可以用/context它会显示当前上下文使用情况。重点看几个信息Token 使用率 引用了多少文件 哪些文件占用最多上下文 是否读入了无关目录。如果发现 node_modules、构建产物、日志文件、大型资源文件进入上下文那就说明.claudeignore需要调整。Token 不只是成本问题也是质量问题。上下文越脏AI 越容易抓错重点。11. /resume多任务切换时保留上下文当你在多个任务之间来回切换可以用/resume它可以帮助你回到之前的会话状态。比如你刚才在修登录 bug中间临时问了一个算法问题之后想回到原来的修复任务就可以用/resume。对于长周期任务来说这个命令可以减少重复解释上下文的成本。但如果会话已经很长建议先/compact再继续后续任务。六、CLAUDE.md决定 AI 能不能真正理解项目如果一个项目没有 CLAUDE.mdClaude Code 对项目的理解主要依赖临时读取文件和你的描述。这就很容易出现几个问题每次都要解释技术栈 每次都要告诉它测试命令 每次都要说明代码规范 每次都要提醒它目录结构 多人协作时规则不统一。一个好的 CLAUDE.md至少应该包含这些内容# 项目名称 ## 项目概述 一句话说明项目做什么服务什么用户核心业务是什么。 ## 技术栈 - 前端框架 - 后端框架 - 数据库 - 测试框架 - 构建工具 - 部署方式 ## 项目结构 说明 src、tests、components、services、api 等目录的用途。 ## 常用命令 - 启动开发环境 - 运行测试 - 类型检查 - 代码格式化 - 生产构建 ## 编码规范 - 命名规则 - 组件写法 - API 封装方式 - 错误处理方式 - 日志规范 ## 测试规范 - 单元测试放哪里 - E2E 测试怎么跑 - 哪些模块必须补测试 - Bug 修复是否需要回归测试 ## 常见坑 - 哪些文件不要改 - 哪些接口有历史兼容问题 - 哪些配置涉及生产环境这份文件不是给老板看的也不是给客户看的。它是写给 AI 的项目说明书。越清楚Claude Code 越不容易乱来。七、.claudeignore别让上下文变成垃圾桶Claude Code 能读取项目上下文但不是所有文件都应该让它读。很多项目 Token 消耗异常高不是因为任务复杂而是因为上下文里混进了大量没用内容。建议.claudeignore至少包含node_modules/ dist/ build/ .next/ coverage/ *.log .env .env.local .vscode/ .idea/ *.png *.jpg *.jpeg *.gif *.mp4这些文件的问题很明显依赖目录太大 构建产物没有必要 日志文件噪音多 环境变量可能包含敏感信息 图片视频对多数代码任务没帮助。合理配置.claudeignore通常能带来三个变化响应更快 Token 消耗更低 回答更聚焦。很多人只关注提示词怎么写却忽略了上下文治理。但在真实工程里上下文治理比提示词更重要。八、权限配置让 AI 能干活但不能乱来Claude Code 可以执行命令、修改文件所以权限配置不能忽视。权限通常分成三类{ permissions: { allow: [], ask: [], deny: [] } }可以这样理解allow安全操作自动允许 ask有风险操作执行前确认 deny危险操作直接禁止。例如{ permissions: { allow: [ Bash(git status), Bash(git diff:*), Bash(npm test:*), Bash(npm run lint:*), Edit(src/**/*.{ts,tsx}), Edit(tests/**/*.test.ts) ], ask: [ Bash(git commit:*), Bash(git push:*), Bash(npm install:*), Bash(npm run build), Edit(package.json), Edit(tsconfig.json) ], deny: [ Bash(rm -rf:*), Bash(sudo:*), Bash(curl * | sh), Bash(wget * | sh), Read(.env) ] } }这个配置背后的原则很简单只读操作可以放宽 测试和 lint 可以放宽 提交、推送、安装依赖要确认 危险命令和敏感文件要禁止。AI 工具越强越要有边界。不是不信任 AI而是不应该让任何工具绕过工程安全底线。九、测试开发视角Claude Code 最值得用在哪些场景对测试开发工程师来说Claude Code 不是只用来写业务代码的。它更适合放到测试工程链路里。1. 辅助生成自动化测试用例比如src/services/order.ts 请为订单创建逻辑生成单元测试重点覆盖边界值、异常输入、状态流转和重复提交。它可以根据代码逻辑反推测试场景。但注意AI 生成的用例不能直接当最终结果。测试人员要重点审核是否覆盖核心业务风险 断言是否有意义 边界条件是否完整 异常路径是否真实存在 测试数据是否可维护。AI 适合补充思路不适合替你做最终质量判断。2. 分析失败用例可以这样用!npm test 测试失败了请分析失败原因判断是业务逻辑问题、测试断言问题还是环境问题。这类场景非常适合 Claude Code。因为它可以结合测试输出、源码和测试文件一起分析。传统流程里你可能需要复制日志、打开文件、搜索调用链、重新跑命令。Claude Code 能把这些动作合在一个会话里。3. 生成接口自动化脚本如果项目里有 OpenAPI、Swagger 或接口文档可以这样问openapi.yaml 请基于这个接口文档生成 Pytest Requests 的接口测试脚本。 要求覆盖正常场景、参数缺失、非法参数、权限异常和幂等性问题。它可以快速生成接口测试初稿。再由测试人员补充业务前置数据 鉴权逻辑 环境变量 数据清理 接口依赖关系 断言策略。这样比从零手写脚本效率高很多。4. 优化 UI 自动化稳定性UI 自动化最常见的问题不是写不出来而是不稳定。比如 Playwright 用例偶现失败可以让 Claude Code 分析tests/e2e/login.spec.ts 这个 Playwright 用例最近经常失败请分析可能的不稳定原因并优化等待策略。它可能会从这些角度给出建议定位器是否稳定 是否依赖固定 sleep 页面跳转是否等待完成 接口返回是否有异步延迟 测试数据是否相互污染 断言是否过早执行。这类问题非常贴近测试开发日常。5. 重构测试框架目录当测试代码越写越多目录结构往往会变乱。可以让 Claude Code 先做分析tests/ 请分析当前测试目录结构给出一套更适合维护的分层方案。它可以从这些维度整理单元测试 接口测试 E2E 测试 测试数据 公共 fixture 页面对象模型 断言工具 测试报告。这对测试框架治理很有帮助。6. 生成缺陷复盘和回归建议Bug 修完之后不要只停留在代码修复。可以基于 diff 生成复盘/diff 请基于这次 bug 修复生成一份缺陷复盘文档。 包括问题现象、根因分析、影响范围、修复方案和回归测试建议。这类能力非常适合团队沉淀知识库。尤其是测试团队很多经验如果不沉淀就会一直停留在个人脑子里。Claude Code 可以帮助把一次修复变成可复用的团队资产。十、一个更适合测试开发的 Claude Code 工作流如果从测试开发角度使用 Claude Code我更建议采用下面这条流程这里面AI 不是替代测试工程师。AI 负责提高产出速度。人负责判断质量。哪些场景必须测 哪些风险不能漏 哪些断言才有业务意义 哪些失败属于环境问题 哪些缺陷值得复盘 哪些自动化脚本需要长期维护。这些仍然是测试开发工程师的核心价值。十一、Claude Code 用不好往往不是工具问题很多人用 Claude Code 用得浅不是因为工具不行而是使用方式还停留在问答模式。常见问题有几个。1. 需求太模糊比如帮我优化一下代码。这类问题很难得到高质量结果。更好的写法是src/components/UserList.tsx 请从渲染性能、状态管理、重复逻辑和可测试性四个角度审查这个组件并给出可执行的修改方案。2. 不给上下文如果不告诉它项目结构、相关文件、测试命令、业务规则它只能泛泛而谈。AI 不是神它需要上下文。但上下文不是越多越好而是越准确越好。3. 不看 diff让 Claude Code 改完代码之后一定要看 diff。不看 diff就相当于让一个刚接触项目的人直接提交代码。这是工程风险不是工具问题。4. 不配置 .claudeignore把 node_modules、构建产物、日志、临时文件都丢进上下文只会让 AI 越来越糊涂。很多回答不准根源不是模型能力而是上下文太脏。5. 没有 Git 保护AI 改代码之前至少要知道怎么回滚。建议养成习惯git status确认当前分支状态。大改之前先提交或 stash。这是使用任何 AI 编程工具的底线。十二、最后AI 编程的门槛正在变Claude Code 的出现说明 AI 编程正在发生一个变化。过去大家关心的是AI 能不能写代码 AI 能不能补全函数 AI 能不能解释报错 AI 能不能生成脚本。现在更应该关心的是AI 能不能理解项目 能不能遵守团队规范 能不能参与测试闭环 能不能看懂 diff 能不能管理上下文 能不能在权限边界内执行任务 能不能把开发、测试、提交、复盘串起来。这才是 Claude Code 值得学习的地方。它不是让工程能力变得不重要。恰恰相反它会放大工程能力的差距。懂项目结构的人能写出更好的 CLAUDE.md。 懂测试策略的人能判断 AI 生成的用例是否有效。 懂 Git 工作流的人敢让 AI 参与真实项目。 懂上下文治理的人能控制成本和质量。 懂权限边界的人能让 AI 高效但不失控。未来的差距不会只体现在“谁会用 AI 写代码”。更大的差距会体现在谁能把 AI 放进自己的工程流程里形成稳定、可控、可复用的生产力。Claude Code 最强的地方也许不是写代码本身。而是它让我们重新思考一个开发者、一个测试开发工程师应该如何把 AI 纳入真实的工程协作流程。
