不知道大家和我是不是有同样的感觉刚开始用Claude Code的时候真挺别扭甚至有点抵触已经习惯了 Cursor、IDEA 里的侧边栏、文件树、diff 面板再回到终端里跟 AI 协作真心不顺手。后来用多了反而觉得 CLI 这层很适合长任务。它能在本地跑也能搬到远程机器、临时环境、CI/CD 里跑同一套命令、权限和验证方式可以复用不用为了 GUI 再改一遍步骤。现在我用 Claude Code直接先把目录、目标和验收方式说清楚让它自己去读代码、跑命令最后我再看 diff 和测试结果。麻烦也在这里。CLAUDE.md写太满、权限放太宽、上下文塞爆、Sub-Agent 拆错边界都会让它越跑越偏。下面这些内容基本来自我这一年多的使用记录偏实战不追求把官方文档重新讲一遍。PSClaude Code 迭代非常快本文按 2026 年 6 月前后的官方文档和个人使用经验整理。命令、权限模式、插件、Auto Mode、Sub-Agent 和 Worktree 行为可能受版本、平台、账号套餐、provider 和安装渠道影响。实际使用前最好先看claude --version、claude --help、/help和官方文档。比如/run、/verify需要 v2.1.145/code-review支持 effort 等级、--comment和--fix/simplify当前更适合理解成 cleanup-only review不是完整的 correctness bug review。CLAUDE.md非常重要CLAUDE.md最好别写成第二份 README。它更像是写给 Claude Code 的项目备忘录哪些规则代码里看不出来、哪些命令经常被它猜错、哪些目录不要碰、改完某类代码必须跑哪条测试。我的项目文件里通常只留这些东西Claude 容易猜错的规则、代码里读不出来的约定、团队必须遵守的规范以及技术栈版本、常用命令、架构取舍、项目坑点。官方文档建议每份CLAUDE.md目标控制在 200 行以内。文件太长会消耗更多上下文也可能降低规则遵守度。内容继续膨胀时再拆到带paths的.claude/rules/低频参考内容放进 Skills。Claude Code 官方文档对 CLAUDE.md 的建议我判断一条规则该不该留会问一句这行删掉后Claude 会不会更容易犯错如果会就保留如果不会直接删掉。放在哪里CLAUDE.md可以放在多个位置。官方的加载顺序大致从全局到局部别只盯着项目根目录那一份CLAUDE.md 层级与优先级最外层是组织级文件通常给 IT 或 DevOps 统一下发规范。macOS 路径是/Library/Application Support/ClaudeCode/CLAUDE.mdLinux/WSL 是/etc/claude-code/CLAUDE.mdWindows 是C:\Program Files\ClaudeCode\CLAUDE.md。这类规则一般不是个人项目里要动的东西。再往下是用户级~/.claude/CLAUDE.md适合放自己的通用偏好。项目级文件放在./CLAUDE.md或./.claude/CLAUDE.md应该提交到 Git让团队都看到。本地级./CLAUDE.local.md只留个人配置记得加进.gitignore。子目录里的CLAUDE.md不会一开局就全塞进上下文Claude 访问到对应目录时才按需加载。这些文件会一起进入上下文后加载的文件不会把前面的内容整块覆盖掉。只是越靠近当前项目、作用范围越具体的规则会排在更后面Claude 通常也更容易采纳。比如用户级规则写“统一用空格缩进”项目级规则写“这个仓库使用 Tab”那在这个项目里Claude 通常会优先按项目规则来。官方文档里的加载顺序也是从组织级、用户级一直到项目级和本地级。我的习惯是把项目级CLAUDE.md提交到 Git只写团队共同遵守的规则。只和自己有关的偏好比如某个项目里想让提交信息用中文放进CLAUDE.local.md再加到.gitignore。项目规模大时可以拆开my-project/ ├── CLAUDE.md ├── backend/ │ └── CLAUDE.md ├── frontend/ │ └── CLAUDE.md └── .claude/ ├── rules/ ├── skills/ └── agents/根目录放全局约定子目录放局部规则。Claude 读取到某个子目录文件时会按需加载对应目录下的说明。这个机制对 monorepo 很友好后端、前端、管理台不用挤在一份文件里。path引用也别误会。它不会凭空省上下文被引用的内容最终还是会进来只是维护起来更清楚。某些规则只对特定目录生效时优先考虑.claude/rules/这类按路径加载的规则别继续往根目录文件里塞。初始化和维护新项目可以先运行/initClaude 会读仓库生成一份初始CLAUDE.md。这份文件只能当草稿别直接提交。它可能猜错 build 命令也可能把 README 里已经写清楚的内容又抄一遍。维护时最容易失控的是越写越多。Claude 偶尔犯一次错先别急着加规则。等同类问题出现两三次、你也能用一句明确指令挡住它再写进去。反过来代码里一眼能读出来的事实、模型本来就会做的事、已经过时的历史约定都应该删掉。规则太多时最该看的几句会被冲淡。如果 Claude 明明读到了规则却没照做先看规则写得是否太软。“尽量保持测试完整”就很虚“修改 Service 后必须运行对应单测并贴出命令和结果”更好执行。同一条规则在多个会话里反复失效再去检查文件太长或者规则放错了位置。我会把规则分成两类团队级、长期有效、必须共享的要求写进CLAUDE.md个人偏好、阶段性调试经验、临时提醒交给 Auto Memory 或本地配置。CLAUDE.md最好来自真实错误也要定期删掉失效内容。写完规则后也别默认它已经生效。可以用/memory看当前会话到底加载了哪些CLAUDE.md、CLAUDE.local.md和 rules 文件如果某个文件不在列表里Claude 这轮就看不到。复杂项目里用了带paths的.claude/rules/还可以用InstructionsLoadedHook 记录规则文件什么时候被加载、为什么被加载别等出了问题才发现某条规则根本没进上下文。权限管理要重视分层授权Claude Code 默认会对敏感操作弹确认比如写文件、执行 Bash、调用 MCP 工具。刚开始会觉得麻烦但在你还不熟悉它的执行习惯时先保留确认更安全。我一般先只放开那些看了也不会出事、跑了也不会破坏现场的命令。比如git diff、git status、rg这类只读命令可以少拦一点mvn test、pnpm test、npm run lint这类固定验证命令也可以按项目情况放行。反过来rm -rf、git push --force、修改.git/这类操作默认不要放。.env、secrets/、生成产物、证书目录和各种 dump 文件也尽量用 deny 规则先挡住。权限可以通过/permissions配也可以写进.claude/settings.json{ permissions: { allow: [Bash(git status*), Bash(git diff*), Bash(rg *)], deny: [ Read(./.env), Read(./.env.*), Read(./secrets/**), Bash(rm -rf *) ] } }规则会被 Claude Code 的执行层处理。也就是说就算 prompt 里写了“请一定不要读.env”那仍然只是建议deny 规则才会拦住对应操作。Auto Mode 的分类器也会参考你在对话里写下的边界但这不是硬保证。不能丢的边界最好写进permissions.deny或者用 Hook 在工具调用前拦住。长会话压缩以后聊天里临时说过的限制也可能被压掉。Auto Mode如果频繁确认已经影响节奏可以考虑 Auto Mode。当前官方文档里CLI 会通过ShiftTab切换权限模式当账号、模型、provider 和组织设置都满足要求时auto才会出现在模式循环里。Team / Enterprise 环境下管理员还可能把它打开或锁掉。它的原理是用一个单独的分类器判断操作风险低风险操作自动放行下载并执行陌生代码、向外部端点发送敏感内容、生产部署、强推、直接 push 到main这类动作会被阻断或转人工确认。不过 Auto Mode 不提供安全沙箱也不保证不会误判。它解决的是“少点确认”不负责隔离文件系统、网络和凭据。高风险任务还是要靠容器、临时账号、最小权限、deny 规则、Hooks 和人工 Review。想默认进入 Auto Mode也别把defaultMode: auto写到项目级.claude/settings.json或.claude/settings.local.json里。v2.1.142 会忽略这些来源里的auto设置避免仓库自己给自己打开 Auto Mode。应该放到用户级~/.claude/settings.json或组织 managed settings。Bedrock、Vertex AI、Microsoft Foundry 这类 provider 还可能需要额外设置CLAUDE_CODE_ENABLE_AUTO_MODE1。启动参数也不要写死。不同版本、安装渠道和 provider 对 permission mode 的支持可能不同脚本里最好先用claude --help或官方文档确认当前可用值。交互使用时我更倾向于在会话里用ShiftTab切换模式而不是把高权限模式写进脚本。--dangerously-skip-permissions我不建议在日常项目里用。除非你已经把文件系统、网络、凭据都隔离好了否则一次误操作就可能改到不该改的文件或者读到不该读的凭据。安全边界生产凭据、数据库密码、云厂商长期 token不要直接暴露给 Claude生产环境也别让它直接碰除非这件事本来就有审批和审计。Git 这边也要收紧。不要允许它默认 push 到main更不要让强推远端分支变成一个随手能执行的动作。来源不明的远程脚本尤其是curl | bash这种写法最好只在隔离环境里试。文件读取范围同样要管住。.env、secrets/、证书目录、SSH key、数据库 dump、生产日志这些都不该默认进 Claude 的可读范围。不只是.env。像~/.aws/、~/.gcp/、~/.kube/、~/.ssh/、Mavensettings.xml、npm token、生产日志和数据库 dump都不应该随便暴露给 Claude。真要让它看日志也尽量先脱敏、截取和限定范围。真的需要自动化高权限任务时放进容器、临时凭据、最小权限账号里跑。这样即使命令执行错了影响范围也更可控。MCP、Skills、Sub-Agent 和插件怎么分Claude Code 周边东西很多刚接触时确实容易混在一起。我自己的分法大概是这样机制解决什么问题适合放什么不适合放什么CLAUDE.md每次会话都要知道的背景构建命令、目录约定、团队规则多步骤任务流程Rules按路径加载局部规则前端规则、后端规则、安全规则全项目都要看的核心约定Skills可复用任务步骤TDD、Code Review、写文章、前端实现永久背景知识MCP连接外部系统GitHub、Sentry、Notion、Figma、数据库本地普通文件规则Sub-Agent隔离支线任务上下文代码搜索、专项审查、并行研究边界很小的一次性修改Hooks固定执行动作禁止危险命令、编辑后格式化、结束前测试仅供参考的建议插件打包分发一组扩展Skills、MCP、Hooks、脚本的组合没审查过的第三方权限包比如“每次编辑后必须跑 formatter”写进CLAUDE.md只能提醒 Claude 记得写成 Hook 才能在文件改完后触发。再比如“修 GitHub Issue 的步骤”放进CLAUDE.md会污染所有会话做成 Skill 更合适。Code Intelligence让 Claude 少靠全文搜索硬读项目能用 Code Intelligence 的话尽量配上。它相当于给 Claude 接了一套语言服务器看类型错误、找符号定义、查引用关系不必每次都靠rg搜一大片文件。拿 Java 或 TypeScript 项目来说Claude 想知道某个类在哪里定义、被谁调用不一定非得先搜关键词再挨个打开文件确认。借助 LSP它可以直接跳到定义、查看引用改完代码后还能马上发现类型错误。它不能替代全文搜索但能少读很多无关文件。项目一大上下文会干净不少Claude 也不容易被一堆候选文件带偏。Claude Code 官方也建议类型化语言安装 Code Intelligence 插件因为一次符号跳转往往能省掉一次搜索加多文件读取。不过Code Intelligence 插件不是“装上就完事”。它还需要本机有对应的 language server binary比如 Java 对应jdtlsTypeScript 对应typescript-language-server。如果/plugin的 Errors 页里出现Executable not found in $PATH通常就是这个依赖没装好。MCP让 Claude 接上真实世界MCPModel Context Protocol模型上下文协议管连接外部系统。外部系统提供一个 MCP ServerClaude Code 这类客户端连上来后就能看到并调用里面的工具。MCP 图解这是 Claude Code 接外部工具的主要方式。查数据库、读 Sentry 报错、访问浏览器、拉 Notion 文档、取 Figma 设计稿都属于这一类。添加远程 MCP 服务器的命令大概长这样claude mcp add --transport http notion https://mcp.notion.com/mcp \ --header Authorization: Bearer your-token这里的your-token只是示意。真实项目里尽量别直接把 token 写进 shell history。团队项目里能共享的 MCP 配置可以放到.mcp.json再提交到仓库。比如某个项目统一要接 Notion、Sentry、内部文档系统就把 server 名称、URL、transport 这些公共配置沉淀下来。带 token、密钥、数据库连接串的配置不要提交到.mcp.json。更稳的做法是放用户级配置、本地环境变量、密钥管理系统或者使用对应 MCP server 支持的 OAuth 流程。MCP Server 要克制。工具越多Claude 越容易选错也越难审计。平时可以用/mcp看当前连接状态启用或禁用 server成本和用量拆分更适合看/usage它会展示 skill、subagent、plugin、MCP server 等维度的使用情况。不常用的 server 先断开。Skills把重复动作存下来规则文件和 Skill 不要混着用。规则文件放长期约束比如技术栈版本、启动命令、目录结构、错误码格式、哪些文件不能碰。Skill 放任务步骤比如代码审查、写测试、改前端页面、网页调研、写技术文章。这些任务每次走法都差不多不必在聊天里反复提醒。小 G 之前写过两篇相关的文章Agent Skills 是什么和 Prompt、MCP 到底差在哪[1] 和AI 编程必备 Skills 推荐[2]。Skill 就是一份按需加载的任务说明。某类任务怎么做、有哪些约束、要检查哪些点、踩过哪些坑都写进SKILL.md。它和CLAUDE.md的一个区别在于加载时机。Claude 默认只看到 Skill 的名称和描述用来判断是否该调用调用这个 Skill 时SKILL.md正文和相关资源才会进入上下文。用户级 Skill 放在~/.claude/skills/项目级 Skill 放在.claude/skills/。还有一个版本变化要注意Claude Code 里 custom commands 已经合并进 Skills。.claude/commands/deploy.md和.claude/skills/deploy/SKILL.md都能创建/deploy这类命令旧的.claude/commands/还能用新内容更推荐按 Skill 组织。Agent 执行链路重复性很强的步骤都可以沉淀成 Skill。写功能前固定走 TDD先写失败测试再实现代码审查时固定检查安全、事务、性能和边界条件写技术文章时固定核对事实来源、引用、标题层级和 AI 味。这比每次在 prompt 里补一长串提醒稳定得多。官方对 Skill 的定义也接近这个意思一组可复用的指令、脚本和资源让 Claude 按固定步骤处理某类任务。现成 Skill 也可以用比如 Superpowers 把 TDD、Code Review、Spec-Driven、Git Worktree、子 Agent 协作这些步骤封装好了。我在 AI 编程必备 Skills 推荐TDD、代码审查与网页自动化实战 这篇文章中有详细推荐。第三方 Skill 不要拿来就跑。SKILL.md本身就是指令里面如果带了危险命令、奇怪脚本、过宽权限Agent 可能会照着做。装之前至少看一眼正文、scripts/和references/确认它没有越权操作。插件先看官方 marketplace不想自己从零配 Skills、MCP、Hooks可以先去 Claude Code 的官方插件市场claude-plugins-official[3] 翻一翻。安装也很直接/plugin install nameclaude-plugins-official插件省的是组装时间。一个插件里可能已经打包好了 Skill、MCP Server、Hooks 和一些辅助脚本装完 Claude 就多了一套现成工作流。但插件最终还是会在你本地跑有些还会碰文件系统、浏览器、GitHub、数据库或第三方服务。装之前至少看一眼说明、权限和源码来源不用了就卸掉减少不必要的工具入口。具体安装和发现方式可以看官方的Discover plugins[4] 文档。Sub-Agent让主会话保持干净Sub-Agent 我用得比较多。Claude Code Sub-Agent让主对话保持干净排查复杂问题时Claude 经常要读几十个文件、搜一堆代码、跑几条命令。主会话很快被日志、搜索结果和文件内容塞满后面再继续写代码就容易飘。这种支线任务可以丢给 Sub-Agent。它有自己的上下文可以单独读代码、查日志、分析问题结束后只把结论汇报回主会话。Claude Code 内置的 subagent 里我最常见到的是 Explore、Plan 和 general-purpose。这些内置 subagent 都继承父会话权限但会叠加各自的工具限制子代理模型工具/权限用途ExploreHaiku偏快速低延迟只读无 Write / Edit文件发现、代码搜索、代码库探索Plan继承主对话模型只读无 Write / EditPlan Mode 下的代码库研究general-purpose继承主对话模型继承主会话可用工具仍受权限约束复杂研究、多步骤操作、代码修改Explore 和 Plan 更偏只读研究不负责直接改代码。官方文档里还有个细节Explore 和 Plan 会跳过CLAUDE.md文件和父会话的 git status所以更适合快速做代码搜索和上下文收集其他内置 subagent 和自定义 subagent 会加载这些内容。general-purpose 边界更宽可能会探索、执行命令、修改代码。用它之前最好明确哪些目录可读、哪些文件不能改、是否允许写入、最终只需要结论还是要直接动手实现。真要做强约束不能只靠提示词要配合 subagent 的tools/disallowedTools、权限模式、permissions.deny或 Hooks。你也可以创建自己的 subagent。项目级配置放在.claude/agents/给团队共享用户级配置放在~/.claude/agents/自己跨项目复用。每个 subagent 都可以配置系统提示词、工具权限、模型以及触发条件。我比较常用的场景是让 subagent 跑测试套件只把失败用例和错误信息带回来或者让不同 subagent 分别研究认证、数据库、API 模块最后把结论合并到主会话。更复杂的任务也可以先让 code-reviewer subagent 找性能问题再让 optimizer subagent 尝试修复。任务太小、边界不清、代码还在剧烈变化时不一定要拆 subagent。主会话保留目标、决策和验收subagent 只处理局部、明确、能汇报结果的专项任务。后续用到 Agent teams 时可以把它看成多会话协作的玩法。Sub-Agent 用来隔离支线任务Agent teams 用来让多个独立会话围绕共享任务协作。刚上手不用急先把 Worktree、小步提交和验证节奏跑顺。一个自定义安全审查子代理可以这么写--- name: security-reviewer description: Reviews Java and Spring Boot code for security risks. tools: Read, Grep, Glob, Bash model: opus --- Review the target diff for: - SQL injection and unsafe dynamic queries. - Authentication and authorization bypass. - Secrets or credentials committed to code. - Unsafe deserialization or command execution. Return concrete file and line references. Do not rewrite code unless explicitly asked.实际项目里subagent 的 tools 尽量收窄。如果只做代码审查通常不需要Edit/Write。同时设置tools和disallowedTools时disallowedTools会先应用同一个工具同时出现在两边最后会被移除。Hooks处理必须执行的规则Hooks 很容易被忽略但真实项目里很有用。它能在 Claude Code 的生命周期节点上执行动作比如工具调用前、文件编辑后、会话结束前、上下文压缩前后。举个例子假设 Claude Code 准备执行rm -rf /tmp/buildPreToolUseHook 会先拿到这次 Bash 调用判断它是否危险命中规则后返回denyClaude Code 会取消这次工具调用并把拒绝原因反馈给 Claude。下面这张图来自 Claude Code 官方 Hooks 文档展示的就是这条链路。Claude Code PreToolUse Hook我会把几类动作交给 Hook编辑后自动格式化会话结束前跑测试禁止改migrations/或.github/workflows/拦截curl | bash、rm -rf、向外部端点发送敏感内容或者在 Sub-Agent 启动时注入额外上下文。需要固定执行的动作适合放进 Hook只作为背景参考的内容再写进CLAUDE.md。如果写的是 HTTP Hook还要注意一个坑不能靠返回 4xx / 5xx 阻断工具调用。HTTP Hook 的非 2xx、连接失败和超时都会被当成非阻塞错误执行会继续。要拦住工具调用需要返回 2xx并在 JSON 里写decision: block或者在hookSpecificOutput里写permissionDecision: deny。最常用的工作流探索、计划、执行、验证复杂任务别一上来就让 Claude 写代码。先让它读仓库暂时不要修改文件进入 plan mode。先阅读 src/auth 和相关测试搞清楚登录态刷新链路。 不要写代码只汇报当前链路、相关文件和可能的修改点。读完以后再让它给计划我要修复用户 session 超时后刷新 token 失败的问题。 基于刚才的阅读列出要改的文件、测试策略和风险点。你确认计划后再执行按这个计划实现。优先补一个能复现问题的测试再改实现。 完成后运行相关测试把命令和结果贴出来。这个节奏前面会慢一点但后面省返工。尤其是你不熟悉代码库或者改动跨多个模块时先让 Claude 把调用链、风险点和测试策略说清楚后面少很多“改完才发现方向错了”的尴尬。小改动可以跳过计划。比如改一个文案、加一条日志、补一个一眼能看出来的空指针判断直接让它做就行。过度规划也会浪费上下文。TDD 测试驱动开发AI 写代码最麻烦的地方在于它很会写“看起来合理”的代码。TDD 能先把预期行为钉住再让实现往测试上靠。提示词不用绕先不要改实现。为 TokenRefreshService 写一个失败测试 覆盖 session 已过期但 refresh token 仍有效的场景。 测试失败后再修改实现直到测试通过。如果测试没有先失败过就很难确认后面的实现到底修到了哪个问题。否则它可能直接改一堆代码然后告诉你“已修复”。让 Claude 自己验证Anthropic 官方最佳实践里有一句我很认同给 Claude 一个能运行的检查。测试、build、lint、截图对比、脚本输出都可以。比如别只说写一个邮箱校验函数。写成下面这样会少很多猜测写一个邮箱校验函数。测试用例 - hellogmail.com 应该通过 - hello 应该失败 - domain.com 应该失败 - ab.co 应该通过 写完后运行测试把命令和结果贴出来。验收标准越具体Claude 越不容易停在“看起来完成了”。如果任务会跑很久可以再加一句“最多尝试 3 轮仍失败就停下来汇报阻塞点”避免它在错误方向上消耗太多 Token。代码库问答接手陌生项目时我会先把 Claude Code 当临时向导用。别急着让它改文件先问调用链用户登录的完整链路是什么从 HTTP 请求进来到 session 写入为止 列出相关类和方法不要修改文件。或者这个项目里订单状态机在哪里定义每个状态之间怎么流转 如果有隐式约束也一起指出来。但它总结出来的内容仍然要抽查。跨服务调用、配置开关、历史兼容逻辑这几类地方最容易被它说得很顺实际漏掉一条分支。Bug 修复需要提供错误信息修 Bug 时最怕只丢一句登录有 bug帮我修一下。这基本是在让 Claude 猜。把原始材料贴上去会稳很多下面是线上报错日志、复现步骤和相关请求参数。 请先定位可能原因不要马上改代码。 找到根因后补一个能复现的测试再修复。日志、堆栈、Slack 讨论、Docker 输出、失败测试结果都比你转述“好像是缓存问题”更有用。转述越多Claude 越容易被你的猜测带偏。多实例和 Worktree不要让一个 Claude 做所有事。互相独立的任务可以拆到不同会话里并行跑。Claude Code 支持用 Git Worktree 隔离不同会话claude --worktree feature-auth claude --worktree bugfix-payment--worktree是 Claude Code 官方支持的参数会在仓库下创建隔离 worktree 并启动会话默认目录在.claude/worktrees/name/分支名通常是worktree-name。如果你想完全自己控制目录和分支也可以先用 Git 原生命令创建git worktree add ../project-auth -b feature-auth cd ../project-auth claude每个 Worktree 有独立目录和分支。一个会话改认证模块另一个会话修支付 bug文件不会互相踩。官方桌面应用也会为新会话自动创建 Worktree这个方向和 CLI 是一致的。Claude Code Git Worktree如果你已经有多个后台会话可以用claude agentsAgent View 会把后台 session 放在一个界面里看哪些在运行、哪些需要你确认、哪些已经完成。多会话用久了以后比开一排终端窗口清爽很多。这里有个容易踩的点后台会话在动手改文件前会自动把自己挪进.claude/worktrees/下的独立 worktree避免几个会话踩同一份工作区。但如果项目带大量生成产物或者 pre-commit hook 很挑路径反复隔离反而成了负担。这种情况可以在.claude/settings.json里把worktree.bgIsolation设成none需要 v2.1.143让后台会话直接改工作区。代价也摆在那儿并发会话有概率互相踩按项目情况权衡。如果你用了.worktreeinclude把.env、.env.local、config/secrets.json这类 gitignore 文件复制到新 worktree一定要确认里面只是本地开发凭据不是生产凭据。Worktree 隔离的是文件改动不等于隔离密钥风险。Commit 和 PR 别一次塞太大不要让 Claude 一次性提交一大坨改动。我倾向于把它拆成小步提交。一个 commit 只做一件事提交前让 Claude 给出 diff 摘要、验证命令和剩余风险自己再过一遍git diff --stat和重点文件的git diff。Claude 写 commit message 和 PR 描述很快但最后别只看它的总结。它说“只改了认证逻辑”不如你自己看一眼 diff 可信。PR 描述写清三件事就够了改了什么、怎么测的、还有哪些地方没完全兜住。常用命令命令不用背真用的时候打/翻一下就行。我平时按两类记。第一类是基础命令。/help看当前环境到底有哪些命令/diff看 Claude 改了哪些文件、哪些行长任务变慢、变飘时先看/context上下文太满再用/compact权限相关看/permissions记忆和规则加载情况看/memoryMCP 连接看/mcp用量拆分看/usage。第二类是 bundled skills / workflow 相关命令。/code-review用来扫当前改动里的 correctness bug、边界条件和潜在风险可以指定 effort比如/code-review high加--comment可以把发现发成 GitHub PR 行内评论加--fix会把 review findings 应用到工作区。/simplify当前更适合当成 cleanup-only review用来处理复用、简化、效率这类清理项并自动应用修复。它不是完整的 bug-hunting review。老版本里/simplify和/code-review --fix的关系变过如果你看到的命令行为和本文不一致优先看当前/help和官方 commands 文档。/batch用在边界清晰的多模块大改上会把需求拆成多个工作单元开后台 Worker 在隔离 worktree 里并行干。/loop可以定时跑任务也可以围绕一个目标反复执行、验证、修正跑之前最好写清停止条件比如最多尝试 5 次。/run用来把应用启动起来看改动是否生效/verify更轻主要做 build 和运行验证快速确认有没有编译或运行时问题。这些命令和 bundled skills 迭代很快不同版本、平台和套餐看到的列表可能不一样。写文章可以介绍经验真到自己机器上用还是先看/help和官方 commands 文档。某个版本里的行为不一定长期保持不变。/compact还有一个容易忽略的点压缩之后有些规则不会立刻回到上下文里。根目录的CLAUDE.md会重新注入但子目录里的嵌套规则不一定马上回来。长任务压缩后最好让 Claude 先复述一遍当前目标、已改文件、剩余风险和下一步验证命令再继续往下跑。命令细节我在Claude Code 核心命令详解simplify、code-review、loop、batch、run、verify[5] 这篇里展开写过这里就不重复铺太长了。提示词怎么写英文和中文各用在合适位置编程任务里英文通常稳一些。我不会把这件事上升成“中文不行”只是代码、库名、错误信息、API 文档本来就大量使用英文。像modal、debounce、retry policy、transaction boundary这类词硬翻成中文反而容易变味。但业务背景、产品规则、中文文案当然还是中文更准。我的习惯是代码动作、技术约束和术语尽量用英文业务语义、验收标准和中文文案用中文讲清楚。限制范围还要小心一句话“调查一下这个项目”。Claude 会很认真地到处搜文件读着读着上下文就被填满了。可以这样写只调查 src/payment 和 src/order 目录。 目标是确认订单支付成功后库存扣减在哪里触发。 不要修改文件只列出调用链和相关类。范围、目标、禁止动作写清楚后它搜索文件和修改代码的范围会收窄很多。给金标准范例让 Claude 按项目风格写代码别只说“参考最佳实践”。这个范围太宽它很容易写出一套看起来不错、但和你项目完全不搭的东西。给它一份现有样板效果通常更好阅读 UserController.java、UserService.java 和 UserDTO.java。 参考它们的分层方式、构造器注入、ResultT 返回格式和异常处理。 为订单查询补一个 OrderController不要引入新的返回结构。项目里的既有风格往往比外面那套“最佳实践”更有约束力。尤其是老项目分层、返回结构、异常处理、日志格式很多都带着历史包袱和团队习惯。让 Claude 先读样板再让它照着补输出会更贴近当前仓库。前端别只说“做得好看”如果让 Claude 写前端别只说“现代、简洁、高级”。这类词太空最后很容易得到一套熟悉的组合Inter 字体、紫色渐变、大圆角卡片、满屏营销页味道。后台系统尤其容易翻车本来是给运营同学高频使用的页面结果做成了产品官网。我一般会写得更硬一点使用现有 Ant Design 组件不新增 UI 库。 页面是后台运营工具信息密度优先不要营销页风格。 主色沿用项目 CSS 变量不要新增紫色渐变背景。 参考 src/pages/UserList.tsx 的筛选区和表格布局。设计规范也可以做成 Skill让 Claude 每次写前端前先读项目视觉约束。先把不该出现的套路挡住。后台工具就按后台工具来信息密度、可扫描性、操作反馈比“氛围感”重要得多。常见失败模式我自己踩得最多的是会话太杂。一个会话里同时聊需求、排错、重构、发版Claude 很快就开始带着前一个话题的惯性做下一个任务。切任务时直接/clear必要时写一份HANDOFF.md不要硬撑着同一个上下文继续聊。第二种是纠正死循环。同一处错误纠正 3 次还不对就别继续在原上下文里磨了。停下来重新写起始 prompt把目标、证据和禁止动作说清楚。CLAUDE.md膨胀也很常见。规则很多Claude 反而不遵守这时不要继续加规则先删掉代码里能读出来的内容只保留真实犯错后总结出的约束。还有一种是无边界调查。让 Claude “看一下这个项目”它可能一次读几百个文件上下文很快耗尽。限定目录、目标和禁止动作或者交给 Sub-Agent。测试全绿也不代表行为正确。让 Claude 展示证据对比 main 和 feature 分支该看日志就看日志该跑手工验证就跑手工验证。权限过宽最危险。为了省确认直接 bypass后面排查误操作会很麻烦。allow/deny、Auto Mode、容器隔离、临时凭据尽量按风险分层配置。总结一开始很容易只盯着“让它多写点代码”。用久了会发现影响结果的反而是那些很普通的工程习惯CLAUDE.md写清项目规矩复杂任务先 plan改动后必须 verify长调查丢给 Sub-Agent多任务用 Worktree 隔离权限别一次放太开。实际项目里可以先从一个目录、一个模块、一条可验证的任务链开始让 Claude 在小范围内稳定完成任务再逐步增加任务复杂度。