我把 10 个中文命令装进了 Claude Code：AI 编程工作流包实战
装好 Claude Code 之后的前几天，我一直在做同一件事：把同样的话翻来覆去地用英文敲进去，然后眼睁睁看着上下文被无关内容冲散，输出质量越来越飘。明明 AI 编程工具已经把“命令”这个概念做出来了，我却还在靠手打 prompt 过日子，这感觉像是买了一台自动挡的车，结果天天挂空挡推着走。后来我花了两天时间，把高频动作全部固化成 10 个中文命令，塞进工作流包，整个用法就彻底变了：输入从“解释一下xxx文件的功能和主要流程并给出修改建议”变成一句/理依赖，结果稳定、格式统一、上下文干净。这篇文章就是把这套工作流包的完整做笔记分享出来，包括命令怎么来的、每个命令处理什么场景、底层是怎么组织的，以及我踩过的那些坑。
1. 为什么非要“命令化”：AI 编程工具最大浪费是重复提问
先从根源说起。Claude Code 本身能力不弱，但很多人用起来都觉得“玄学”：同一个问题，描述详细点就靠谱，描述随便点就胡说；上午用得顺手，下午换个新任务又开始犯傻。我当时的困扰不在模型本身，而在交互方式。
1.1 手打 Prompt 的三个隐藏成本
第一是遗忘成本。接手一个不熟悉的中大型代码库时，我需要反复让 AI“先读一下目录结构”“看下这个入口文件”“梳理一下数据流”。每次都花几百 token 重复铺背景，输出还不一定稳。第二是格式成本。让 AI 写提交信息、做代码审查、出技术方案，每次它给我的格式都不太一样，我还要再整理一遍，比我自己写还慢。第三是切换成本。当任务需要连续操作（先看架构、再定位 bug、再改代码），中间一旦换话题，前面的上下文就被挤掉了，AI 就开始“失忆”。
这三点凑一起，本质上说明一件事：Claude Code 的交互对象不是一个“会聊天的模型”，而是一个可以承接固定流程的执行器。问题的解法不是把 prompt 写得更长，而是把流程本身固定下来。
1.2 命令系统在工作流里的真实定位
Claude Code 的 slash command（斜杠命令）不是简单的“prompt 模板调用宏”，它在设计上更接近 IDE 里的 Code Snippet 和任务编排器的结合体。每一个命令对应一个独立的任务单元：你输入/看架构，它先按既定流程扫描目录、读关键文件、输出结构化报告；你输入/救命，它带着当前项目上下文去定位报错、给出修复步骤。
这就是工作流包的雏形：把“人想做的事”翻译成“模型按固定节奏执行的动作序列”。命令本身不炫技，但胜在把不确定性挡在了门外。我后面所有优化，都基于这个思路展开。
2. 先把地基打好：自定义命令在 Claude Code 里的组织方式
做命令之前，得先弄清楚 Claude Code 把命令放在哪儿、怎么加载。网上关于“Claude Code 安装教程”的帖子一抓一大把，但真正讲到自定义命令目录结构的很少。这块直接决定了后面的 10 个命令能不能稳定生效。
2.1 命令目录的两级体系与加载顺序
Claude Code 支持两类命令配置：
- 用户级命令：放在
~/.claude/commands/下，对当前账号的所有项目生效，适合放通用型命令。macOS 和 Linux 用户一般直接建目录即可，Windows 下如果通过 WSL 使用，路径在 WSL 的 home 目录里，不是 Windows 的原生目录。 - 项目级命令：放在项目根目录的
.claude/commands/下，只对当前代码库生效。由于 Claude Code 会优先加载项目级命令，遇到同名命令时会以项目内的为准。适合把某套业务特有的流程、术语、规范固化在仓库里，团队协作时直接跟着仓库走。
我实际的做法是双层都建。用户级放通用动作（提交信息、代码审查、bug 定位），项目级放业务相关动作（需求拆分、影响面分析、方案设计）。这样既能在任何项目里复用基础能力，又能保证每个项目的专属流程不污染其他仓库。
2.2 命令文件的长相和解析规则
每个命令本质上是一个 Markdown 文件，文件名去掉.md后缀就是命令名。文件分为两个区域：
- YAML frontmatter：用
---包裹的元信息区，支持description（命令描述，触发时会展示）、allowed-tools（允许调用哪些工具，如 Read、Edit、Bash 等）、argument-hint（参数提示）。 - 正文区：写在 frontmatter 下面的所有内容都会被当作系统提示的一部分，注入到模型上下文里。
这里的重点是：description字段一定要写清楚“这个命令什么时候用”，因为 Claude Code 在执行时会根据描述判断是否适合当前场景。我的做法是每个描述都带明确触发条件，比如“当用户想要快速了解代码库整体结构、模块划分、核心数据流时使用”，避免模型在无关场景下强行套用命令。
2.3 为什么命令文件比单独改 CLAUDE.md 更稳
有人可能问：这些内容直接写在项目的CLAUDE.md里不也行吗？还真不一样。CLAUDE.md是全局背景知识，会注入到每一次对话里；命令则是按需加载，只在触发时生效。把高频动作全塞进CLAUDE.md，会让每次请求都背上几百 token 的包袱，而且所有任务共享一套指令，容易互相干扰。命令的“按需触发”特性，天然避免了这个问题。这也是我把 10 个中文命令单独做成工作流包而不是一股脑堆进项目说明的原因。
3. 10 个中文命令逐条拆解：从设计动机到实际内容
下面进入正题。我给这 10 个命令分了三条主线：高频基础动作、进阶分析动作、项目治理动作。每个命令我都会说明触发场景、核心指令内容和我在实际使用中总结的关键点。命令正文本身不追求长篇大论，但每一条都要求能独立完成任务。
3.1 高频基础动作组：最日常的四个命令
第一组是/看架构。设计动机很简单：每次开新项目、接手前同事留下的工程，都要让 AI 先跑一遍结构梳理。过去我会手写“请先看下这个项目的目录结构，标注主要模块，说明技术栈”，效果时好时坏。命令化之后，我在正文区固化了几个必须完成的动作：先列根目录文件，再识别入口文件和配置文件，然后找路由层/服务层/数据层的边界，最后输出一张项目概览表。这张表包含：模块名、职责、关键文件路径、依赖的技术。实测中这命令最大的价值不是省了打字，而是固定了输出结构——我不需要再让 AI 把“先看这个再看那个”的流程重新理解一遍。
第二组是/救命。这是我自己踩坑最多的地方。过去遇到报错，我习惯把报错信息复制给 AI，它常常回复得模棱两可。后来我把/救命的流程设计成三步走：先提取报错堆栈中的核心关键字和位置，再定位到对应文件并读取上下文，最后按“可能原因 → 核实方法 → 修复建议 → 验证步骤”四段式输出。特别关键的是：命令里明确要求 AI 不要直接给结论，而是先做复核——很多报错看起来是 A 文件的问题，实际根源在 B 文件的参数类型。此外，我还给这个命令加了一个小约束：如果找不到报错位置，必须明确说“未能定位”，而不是给一个通用答案。
第三组是/过测试。这个命令的触发场景是“改完代码想跑一遍相关测试确认没搞坏”。在正文区我写了：先尝试识别项目的测试框架和测试命令（package.json 里的 scripts、pytest.ini、Makefile 等），然后以最小代价跑“只和本次改动相关的测试”，遇到失败项先抓失败原因，再给出修复建议和修复后的验证命令。这里有个重要设计：我不允许它一上来就全量跑测试——中大型项目全量测试耗时很长，而且失败信息淹没在几百行输出里，根本看不出重点。命令按“相关测试优先”执行，效率高得多。
第四组是/写提交。写提交信息这事，很多人都觉得让 AI 写不靠谱，其实难点不在生成，在于让它“按你的规范生成”。我在命令里约定了提交信息的格式： ( ): ，type 限定为 feat/fix/refactor/docs/style/test/chore 几种，subject 用中文短语，不超过 50 字。命令执行的逻辑是：先读git diff --staged，判断变更属于哪类 type，再提取核心变更点生成 subject，最后在 body 里列出关键改动点。用了这个命令之后，我的提交记录整齐了非常多，团队 review 时能一眼看出意图。
3.2 进阶分析动作组：把“慢思考”固化成流程
基础命令解决的是“立刻能用”的问题，进阶命令解决的是“想得更深”的问题。我单独做了 3 个分析类命令，专门处理代码库里比较费脑的场景。
第一个是/理依赖。当模块间耦合严重、不知道改动某个函数会不会引发连锁爆炸时，这个命令的价值就体现出来了。它的执行步骤是：先定位“被分析的入口符号”（函数、类、接口），再用代码搜索能力找出所有引用它的位置，接着把“直接调用 → 间接调用 → 依赖关系总结 → 修改风险提示”分四层输出。这里面的核心技巧是：限制分析深度。我让 AI 只分析两层间接调用，再深就得靠人了，因为模型在超长调用链上的可靠性会明显下降。输出格式里我会要求给出一张“影响面清单”，每条都带调用位置的文件和行号。这套逻辑跑下来，改动代码前的安全感强了很多。
第二个是/改需求。产品一句话需求，代码一堆排查，这是日常工作中最频繁的麻烦事。我把这个命令的设计目标定成“先出方案，再动手写代码”。执行流程是：读需求描述 → 在当前代码库中定位所有涉及改动的地方 → 输出影响面清单 → 给出修改方案（每个改动点配一句改法和理由）→ 等用户确认后才开始改。为了确保 AI 不“抢跑”，我在命令正文里写死了这句话：“在给出完整修改方案之前，绝对不要直接修改任何文件。”这一步非常重要，否则命令就会变成“乱改代码生成器”，改完还要人收拾。
第三个是/审查代码。这个命令应对的场景是“改动不大，但想让人/AI 看出潜在问题”。我把它设计成走“问题清单”而不是“工作总结”：不夸代码，只挑毛病。输出格式是：按严重程度（高/中/低）列出问题，每条包含问题位置、问题描述、风险点、修复建议。命令的正文区我特意注明了审查维度：边界值、空值处理、资源释放、异常捕获、性能隐患、安全隐患、命名与可读性。实践下来，这个命令对发现空指针风险、死循环隐患、重复代码这类问题非常有效，尤其是深夜赶工写完自己看不下去的时候。
3.3 项目治理动作组：让 AI 沉淀团队资产
最后这组命令，是很多人忽略的用途——用 AI 编程工具做项目治理和知识沉淀，而不仅仅是写代码。
第一个是/写周报。触发场景是每个周五下午，我都不想从 git 记录和聊天记录里翻自己这周干了啥。命令会执行这些动作：先读取最近一周的git log和git diff --stat，再结合当前分支的 PR/MR 描述（如果有），按“需求/功能、Bug 修复、重构/优化、其他”四类生成周报草稿。为了让 AI 输出接地气，我特别在命令里加了约束：“不要使用夸张的形容词，用项目业务语言描述，说明影响范围。”生成之后我会手动调整一下语气，但整体框架已经省了 80% 的工夫。
第二个是/会议纪要。我们小组每周都有技术评审会，会上聊了很多设计取舍，但没人记完整，过两周就忘了。这个命令我设计成“结构化记录模板”：要求 AI 按“议题、结论、待办、责任人、截止时间”输出 Markdown 表格。使用时直接把讨论内容粘贴进来，或者附上对话上下文，AI 就能自动整理。命令的关键设计是：必须区分“已确认结论”和“待讨论事项”，避免模型把猜测写进结论。
第三个是/写方案。遇到稍大一点的技术改造，需要一份技术方案文档。我要求 AI 按这几节输出：背景与现状、方案对比（至少两个候选方案并分析优缺点）、选定方案、详细实施步骤、风险清单与对策、验证方案。这个命令的调教重点是：必须做“多方案对比”，否则 AI 通常会吊死在自己第一个想到的方案里。在命令正文里我写了一句“请从一个有经验的架构师视角出发，分析至少两个不同方向，然后给出推荐”。用下来后，输出质量远超我直接问“这个需求怎么实现”。
4. 让命令们协同起来：一套组合拳跑完真实开发流程
单条命令做好只是第一步，命令之间的协同配合才是工作流包真正的价值。如果我非要手打一大段话才能让 AI 完成“了解项目 → 定位问题 → 修改代码 → 提交信息”这一整条链路，那命令的存在意义就打了折扣。实际操作中，我往往是把 2~3 个命令串起来用。
4.1 接到新任务的“三步开场白”
面对一个没接触过的模块，我现在不会直接让 AI 改代码。我的固定开场白是：先/看架构拿到项目概览，然后/理依赖定位目标模块的上下游，最后才让 AI 处理具体需求。这个流程里其实藏着两个原因：第一，模型对“不知道背景”的任务容易答非所问，喂了概览之后，后续回答的准确性明显提升；第二，这两条命令输出的结构化结果同时也是接下来对话的“上下文锚点”，后续 AI 就不会再跑偏了。
4.2 改完代码后的“收尾三连”
代码改完之后，我不会直接结束。先把改动过的文件简单复述一下，随后跑一遍/过测试看有没有破坏别人功能，再跑/审查代码挑潜在问题，最后用/写提交生成提交信息。这套组合在个人项目和团队项目里都能用，尤其是多人协作时，提交信息规范了，review 效率高很多，测试也能避免“我以为没影响，结果炸了”的尴尬。
4.3 把常用流程沉淀为“自定义复合命令”
组合用得顺手之后，就会出现一个新需求：能不能把“三步开场白 + 收尾三连”直接做成一个更大的复合命令？Claude Code 允许命令里Bash工具执行指定脚本，不过我的做法更简单：在命令正文里用文字串联。也就是让/开工这条命令自动先输出项目概览，再让用户指定目标模块，然后再输出依赖分析，最后等待用户给出具体需求。它的收益不是省了四五行字，而是让 AI 的执行顺序变得可预测、可复现。对我这种容易分心的人，这种“流程压舱石”特别重要。
5. 实测踩坑记录：这些细节比命令正文更值钱
光拆解命令还不够。把这套工作流包真正跑起来的过程中，我踩了不少坑。有些问题在官方文档里根本不会写，有些则是“遇上了才懂为什么”。我把最关键的几个翻出来说清楚，能帮你少走一半弯路。
5.1 命令描述写不好，等于没做命令
最早我写的命令描述特别随意，比如/看架构的 description 就写了句“看下架构”。结果 Claude Code 在执行时经常不识别，或者自动认为这个命令和当前任务不匹配，转向普通对话。后来我改成触发条件式描述：“当用户需要快速了解代码库整体结构、模块划分、核心入口、数据流方向时使用。适合新项目启动、接手旧代码、梳理系统全貌。”效果立刻不一样。核心原因在于：Claude Code 会根据描述判断命令的适用范围，描述里的场景词越多，它匹配触发条件的准确率越高。
5.2 输出格式不加约束，命令会“自由发挥”
第二个坑是格式约束不到位。最初/救命命令只要求“解释报错原因并给出修复建议”，结果 AI 有时输出一大段文章，有时只给三行结论，有时直接改代码，完全不看我的其他指令。我的修复方法是：在命令正文末尾加“这是你的输出模板，请严格按模板执行”，然后把四段式结构写死。模型对明确模板的遵循度远高于自然语言描述，这是实测下来很稳的一个技巧。
5.3 Windows/WSL 环境下路径问题的处理
国内很多用户在 Windows 下通过 WSL 安装和使用 Claude Code。命令配置文件放在 WSL 的 home 目录里没问题，但如果你操作的项目在/mnt/c/...这种跨盘路径下，Read/Edit工具在处理中文路径或者含空格的目录时偶尔会抽风。我踩过一次：命令文件里的路径写成了 Windows 风格的反斜杠，结果工具死活读不到。正确做法是：命令文件内部尽量使用相对路径，或者使用 WSL 内的绝对路径，并避免在路径里带空格。另外，如果遇到auto-update failed: no write permission to npm prefix这类权限报错，多半是 npm 全局目录的权限问题，把 npm prefix 指到用户目录下即可解决。
5.4 要不要接 DeepSeek 等其他模型
标题相关热词里反复出现“Claude Code 接入 DeepSeek”的讨论，我也专门试过。Claude Code 本身支持通过环境变量指定 API 地址和模型名，不登录官方账号也能用其他模型跑起来。但这里有个实际问题：命令系统依赖的是模型的工具调用能力，如果你的命令里大量使用了Read、Edit、Bash这些内置工具，那么所选模型必须支持类似的功能协商。我测试了部分开源模型，日常问答没问题，但执行复杂命令（尤其要多次读取文件、修改代码）时的稳定性差距还是存在的。我的建议是：如果你打算完整复刻这套工作流包，优先用官方支持的模型跑命令逻辑；如果想省钱用第三方模型，先从基础命令组开始试，分析类和治理类命令的稳定性要求比较高。
5.5 命令多了以后，别让上下文互相“打架”
当我一开始把 10 个命令全丢进工作流包时，遇到过一个问题：AI 在处理某个任务时，会“借鉴”其他命令的逻辑。比如我在/写方案里定义了严格的多方案对比格式，结果/救命输出时也带了方案对比，把修复建议搞得很啰嗦。后来我才意识到，自定义命令是独立的系统提示，它们彼此之间没有隔离认知错位。解决方法是给每条命令加一句“你正在执行 [命令名]，不要使用其他命令的流程和格式”。这句话简单，但能有效防止命令之间的上下文串味。
6. 工作流包的调整方法与进阶思路
写完这 10 个命令只是开始，这套工作流包真正有价值的时刻，是它被持续打磨到与你自己的开发习惯完全贴合的时候。这里分享我迭代命令包的几个方法，以及接下来我打算继续扩展的方向。
6.1 每次翻车都是一次调优机会
我现在有个习惯：只要 AI 用某条命令给出让我不满意的结果，我不会直接重问，而是先看命令正文哪里写得不够细。比如/改需求早期有个问题：AI 读完需求后会直接给方案，但不标注“每个方案点的风险”。后来我在命令里加了一行“每个改动点必须附带风险等级（无风险/低风险/中风险/高风险）”，输出质量立刻提了一个档次。这背后的原则是：命令文件不是写完就完的静态文档，而是随着使用不断收紧的“行为规范”。
6.2 让命令吸收团队的业务语言
如果是团队使用，我强烈建议把业务术语直接写进命令。比如我们团队内部管“用户下单后优惠计算”叫“价格快照”，普通模型根本不知道这个词。我把这类术语表和约束写进了项目级命令/改需求的末尾，AI 在处理相关改动时就能自动使用团队熟悉的表达方式。这对新同学尤其友好，等于把团队潜规则直接固化进了工具里。
6.3 下一步：把命令用到更多场景
目前我觉得值得继续做的是两个方向：一是做更多的“复合命令”，把几个基础命令的串联固化成一个大流程，减少多步切换成本；二是给命令加上“验证清单”，比如/过测试跑完失败项后，强制 AI 列出“重新运行该测试的命令”，方便我直接复制执行。这些都是在实际使用中冒出来的想法，每加一个，这套工作流包就更贴合真实需求一点。
最后再分享一点个人体会：这套东西不复杂，就是一个 Markdown 文件加一个命名习惯，但它把我和 AI 编程工具的配合方式从“每次重新下车问路”变成了“上车设个目的地就行”。10 个命令能不能直接用，完全取决于你对自己的工作流能不能看得足够清楚。我自己用下来的真实感受是：命令越具体，AI 越可信；工作流越固定，结果越可预期。希望你也能从这套思路里找到适合自己的那组命令。
