拓冰网站定制 
先说个真实场景。你坐在终端前想用 Claude Code 帮忙把一段烂代码理一理结果又开始敲那段复制了无数次的英文提示词please review the code, focus on potential bugs, suggest improvements… 敲完还得担心它理解偏了输出一堆正确的废话。更麻烦的是团队里的同事第一次打开 Claude Code 根本不知道能干嘛你口头教完他还是一脸懵。我花了两个晚上把平时最高频的 10 类操作全部做成了中文 slash 命令打包成一个工作流包直接丢进.claude/commands/目录。现在输入/需求分析、/代码审查、/提交信息后面跟上你的具体要求剩下的提示词细节全部由命令文件补全。这套方案既不依赖外部插件也不改 Claude Code 本体纯靠它自带的命令机制实现零维护成本。这篇就把这套工作流的完整设计思路、10 个命令的原始配置、安装步骤、以及我实际踩过的坑全部摊开讲一遍。准备照着做的朋友你只需要已经装好 Claude Code CLI能用终端打开交互界面剩下的一切跟着配置就行。没装过的先花两分钟装好再回来看这篇。1. 为什么我把日常操作全部做成 slash command1.1 重复提示词的账单比你想的更贵很多人觉得自己写 prompt 很灵活没必要做成命令。我一开始也这么想直到有一次给同一个项目连续改了三次接口设计每次都要重新把上下文、约束条件、输出格式打一遍。打完发现真正花在思考上的时间没多少时间全耗在把需求翻译成 AI 能理解的结构化描述上了。这其实是重复提示词的隐性成本第一每次写 prompt 的一致性问题今天强调代码风格明天忘了提输出质量就像开盲盒第二长提示词本身就有噪音AI 读着一堆临时拼凑的句子很容易抓错重点第三团队协作成本被放大了。像我带过的新人第一次用 Claude Code 时的典型反应是知道它能写代码但哪里敢把关键任务交给它根本不知道从哪句话开始。把这些高频动作固化成 slash command 之后等于把怎么写好这次 prompt这个问题提前用结构化模板解决了。你在终端里敲一个短命令加几个参数AI 拿到的是经过反复调优的完整指令效果自然比临场发挥稳定得多。1.2 slash command 到底是什么Claude Code 原生支持一个非常朴素的扩展机制在.claude/commands/目录下放一批 markdown 文件文件名去掉.md后缀就是命令名。命令文件顶部用 YAML 写 metadata 描述命令用途正文就是真正会发给模型的提示词内容。项目下或用户目录下 └── .claude └── commands ├── 需求分析.md ├── 架构设计.md ├── 代码审查.md └── ...这个机制最爽的地方是它不要求你掌握任何新语言。会写 markdown、会写中文提示词你就能做命令。配合$ARGUMENTS这个占位符用户在执行/命令名 参数时输入的内容会被原样嵌入命令正文从而实现了短命令 长模板的组合。我之所以选中文文件名而不是review、refactor这种英文名直接原因是这套工作流的使用者以中文为母语中文名字在命令面板里一眼就能看懂。严格来说这也算某种模型无关的工程优化你换的是提示词工程层的封装和背后使用哪个模型没有关系。1.3 中文命名不是偷懒而是降低使用门槛有人会觉得中文文件名不够极客但我实测下来对普通使用者来说中文的识别速度远超英文缩写。终端输入时你只需要打出/需求Claude Code 会自动补全成/需求分析基本不增加输入成本。更重要的是它降低了第一次使用的心理门槛。团队里不懂 AI 的同事看到命令列表看到的是需求分析、代码审查、数据库设计、提交信息这些他本来就要做的事自然明白该点哪个。这种设计跟产品的空状态引导思路一样工具的高级感不重要能让人愿意用起来才重要。2. 十个命令的设计与实现下面把这 10 个命令逐个拆开。每个命令我都会给出可直接落地的 markdown 文件内容然后解释设计意图和我的实测体验。你自己用的时候不用一字不差照抄重点吃透每个命令里结构性约束的部分。2.1 /需求分析 —— 把模糊想法变成可执行需求这个命令专门处理一类高频场景你脑子里只有个模糊方向比如用户模块要做个权限升级但要落成开发任务还差得远。--- description: 把零散想法整理成可执行的需求文档 argument-hint: 简要描述你想要的场景或功能 --- 请扮演资深产品负责人和系统分析师的综合角色帮我把下面这个模糊想法 拆解成可直接进入研发的软件需求。 用户描述 / 原始想法的核心是 $ARGUMENTS 请按以下结构输出 1. 需求背景与业务价值一句话说清楚为什么要做。 2. 功能范围列表用 MoSCoW 优先级标注Must/Should/Could/Wont。 3. 用户流程或典型场景至少给出 3 个具体场景。 4. 边界和例外情况列出至少 5 种异常或边界输入。 5. 验收标准用当...时系统应该...的句式描述覆盖主路径和边界路径。 6. 待确认问题列出开发前必须由业务方回答的 3-5 个问题。 如果我的描述里有歧义先主动提出你的理解再按这个框架输出。这个命令的价值在于它强制 AI 一次性把业务想法翻译成研发输入。以前我给 AI 一句话需求它可能直接甩出一段代码有了这个模板它会先做结构化拆解我再决定哪些做、哪些不做。实测最有用的是第 6 条待确认问题它经常能问出我自己都没考虑到的业务细节。2.2 /架构设计 —— 给技术选型加约束架构设计这个活AI 最容易犯的毛病是给一个看似合理但完全不符合项目现状的方案。所以我故意在命令里加了先读项目再说话的约束。--- description: 生成技术方案对比选型并给出落地建议 argument-hint: 描述要设计的模块或要解决的问题 --- 你现在是一位资深架构师先读一下当前项目根目录里的 README、package.json、 pyproject.toml 等描述文件再结合我下面提到的问题来做设计。 待设计的问题是 $ARGUMENTS 输出要求 1. 先给出 2-3 种候选方案每种方案要写清楚实现思路、优势和代价。 2. 对比表按复杂度、性能、可维护性、团队上手成本四个维度打分。 3. 基于当前项目现状给出明确推荐并说明哪些约束条件影响了你的选择。 4. 给出分阶段落地步骤第一阶段的改动面必须控制在最小范围。 5. 指出你推荐方案的潜在风险点以及回滚方案。 注意不要凭空引入当前项目未使用的技术栈如必须引入需给出理由。我实测下来的感受是先读项目描述文件这条约束是灵魂。加了之后AI 给出的方案会贴着项目的实际技术栈说而不是泛泛而谈。还有一点命令里要求明确说明哪些约束条件影响了选择这能让它把决策依据讲清楚而不是只给结论。2.3 /代码审查 —— 当结对评审用代码审查是使用频率最高的命令之一。我没有让它检查所有问题而是引导它按严重程度分级并且每条建议必须给出可操作修改避免空话套话。--- description: 审查当前改动或指定文件输出分级评审意见 argument-hint: 可指定文件名、文件范围或留空让 AI 自行分析 --- 请以资深代码评审者的角色审查代码。 审查范围$ARGUMENTS如果为空则根据当前 git diff 自动识别变更文件 重点检查维度 1. 正确性并发问题、边界条件、资源泄漏、错误处理缺失。 2. 安全注入风险、敏感信息泄漏、越权访问。 3. 可维护性命名、重复代码、模块耦合、可测试性。 4. 性能不必要的循环、N1 查询、大对象引用。 输出格式 - 必须按 P0 / P1 / P2 三个级别分类问题。 - P0 是会导致线上故障或严重安全风险的问题必须给出修复示例 - P1 是潜在缺陷或明显设计问题需要给出改进建议 - P2 是风格和可读性层面的建议简写即可。 - 所有输出使用中文修复示例用代码块给出。 - 如果审查结果没有问题也请你明确说清楚哪些隐患你检查过确认没有遗漏。我以前直接用一句话让 AI 审查代码它经常把风格问题当成大问题讲半天真正的并发隐患反而漏掉。这个命令把检查维度固定下来以后输出结构就变得稳定了处理修 bug 的流程也会顺很多。2.4 /调试修复 —— 禁止猜答案先复述问题调试这个场景最忌讳的是 AI 还没看明白问题就开始改代码。我用命令强行规定它的工作顺序先复述、再定位、后修复最后必须验证。--- description: 根据报错或异常行为定位并修复缺陷 argument-hint: 粘贴报错信息或描述异常表现 --- 你现在是 Debug 专家。在给出任何结论之前严格遵守以下流程 第 1 步必须执行用自己的话复述问题包括它出现的场景、输入、 期望行为和实际行为如果信息不足先索要缺失信息。 第 2 步基于代码库提出至少 3 个可能导致该问题的假设按可能性排序。 第 3 步针对排名最高的假设给出最小验证方案加日志、写单测 或构造最小复现不要直接改生产代码。 第 4 步确认根因后再给出修复代码。修复必须最小化改动。 第 5 步给出验证方法应该运行什么测试、观察什么日志输出 才能确认问题真正解决。 问题是 $ARGUMENTS这个命令救过我一次。之前有个偶发超时问题AI 上来就改了一行超时配置结果当然是没解决。后来用这个命令它老老实实分析了三个假设最后定位到是连接池耗尽而不是超时时间不够。强制先复述问题的好处是很多bug其实在第一遍复述时你自己就发现是理解偏差了。2.5 /重构优化 —— 小步重构避免大爆炸重构的常见悲剧是 AI 大刀阔斧改一堆文件最后测试全挂你还不知道是哪里改崩的。这个命令的核心约束是保持行为不变、单次只做一个小重构。--- description: 对指定代码进行小步重构保持行为不变 argument-hint: 指定文件、函数或一段代码并说明重构目标 --- 请对以下代码进行小步重构严格遵守行为保持原则。 重构目标$ARGUMENTS 约束条件 1. 单次重构只允许做一类操作提取函数、消除重复、重命名、 简化条件表达式或调整模块结构不要混着来。 2. 任何一步重构都不允许改变现有功能的外部行为包括边界条件。 3. 重构前先说明当前代码的主要坏味道重构后逐项说明 你做了什么以及为什么这样不影响行为。 4. 如果重构涉及多个步骤请一步一步列清楚不要一次性给出 一个巨大的改动 diff。 5. 最后给出如何验证应运行哪些现有测试或补什么测试来兜底。我通常会在重构前先让 AI 生成一轮/测试生成把关键行为用测试锁住再跑重构命令。这种顺序操作之后大改动的心理压力小很多因为每一步都有测试兜底。实测重构命令给出的分步方案比一次性 diff 的可读性好太多代码评审时也容易过。2.6 /测试生成 —— 按语义补全单测写单测是自己最不想干、但 AI 最擅长的活。这个命令的重点不是凑覆盖率而是要求测试围绕业务语义和边界值来写。--- description: 为指定函数或模块生成单元测试 argument-hint: 指定函数或文件可补充测试重点 --- 请为以下目标生成单元测试 目标$ARGUMENTS 要求 1. 先分析这个函数/模块的输入域和业务规则列出至少 5 个 有测试价值的场景正常路径、边界值、非法输入、异常分支。 2. 测试用例名称使用中文描述意图例如当金额为负数时应该抛错。 3. 使用项目已有的测试框架不要引入新的测试依赖。 4. 生成的测试必须能跑得通不能因为 mock 方式错误而失败。 5. 额外说明哪些场景你故意不测以及为什么例如成本过高、收益低。这个命令设计上最妙的是第 2 条强制中文用例名。以前 AI 生成的测试叫 test_user_login_with_valid_credentials看半天不知道测的啥现在一眼就看到登录成功后应返回 token。项目里的测试文件逐渐变成了一份能读的业务文档这点让我极其受用。2.7 /数据库设计 —— 从业务描述到表结构数据库设计这个场景AI 的输出往往缺索引、缺外键、缺迁移脚本纯产出两张建表 SQL 完事。我做的命令把完整交付物拆成了固定结构。--- description: 根据业务描述输出表结构设计、索引与迁移脚本 argument-hint: 描述业务实体和关系例如用户、订单、商品等 --- 请基于以下业务描述进行数据库设计 业务描述$ARGUMENTS 输出要求 1. 实体识别列出核心实体和实体间关系一对一/一对多/多对多。 2. 每张表给出字段清单包含字段名、类型、约束、默认值、注释。 3. 索引设计给出每个索引的字段和设计理由特别是查询频率高的字段。 4. 核心表需要说明软删除、创建时间、更新时间等通用字段的约定。 5. 输出可直接执行的 DDL 迁移脚本并说明回滚脚本。 6. 指出这个设计可能存在的性能瓶颈或数据增长风险点。设计意图很简单数据库设计不是建表而是数据建模和长期演进规划。有了这个模板AI 至少会把索引和外键想一遍而不是只把字段罗列出来。迁移脚本我是强烈要求必须有的否则本地改着玩还行一上协作流程就乱。2.8 /提交信息 —— 终结绞尽脑汁写 commit message这可能是最没有技术含量、但每天用得最多的命令。它不需要 AI 读什么上下文只要读 git diff 就够了。--- description: 根据 git diff 自动生成规范的 commit message argument-hint: 可补充提交说明例如 bugfix、新功能、重构等 --- 请先执行 git diff --staged如果没有暂存内容再看 git diff然后根据改动 生成一份符合 Conventional Commits 规范的提交信息。 补充说明$ARGUMENTS 要求 1. type 属于 feat / fix / refactor / docs / test / chore / perf 之一。 2. 提交信息开头用一句中文概括不要用英文祈使句。 3. 正文列出关键改动点按重要程度排序每点一句话。 4. 如果检测到可能 breaking change必须在正文里单独标记。 5. 只要最终一条提交信息不要提供多个候选版本。实际用的时候我的流程是git add .之后直接输入/提交信息它读出 diff 生成一条信息我检查没问题就提交。这个命令帮我解决的最大问题是提交粒度以前我经常一个 commit 塞一堆不相关改动现在 AI 会按改动类型组织正文变相逼着我自己把提交拆干净。2.9 /更新日志 —— 按版本聚合变更整理 CHANGELOG 是发版前最让人头痛的杂活。这个命令基于git tag和日志来聚合版本变更省去翻 commit 的时间。--- description: 根据 git 历史生成或更新 CHANGELOG argument-hint: 可指定版本范围例如 v1.0.0..v1.1.0 --- 请执行 git tag 和 git log 查看提交历史然后生成一份更新日志。 版本范围$ARGUMENTS留空则取最近的 tag 到当前 HEAD 输出格式 1. 按版本号倒序排列标题格式 ## [版本号] - 日期。 2. 每个版本下分为新功能、修复、重构、文档、依赖更新几个小节。 3. 把同一语义的提交合并成一条不要逐条复制 commit message。 4. 对行为有破坏性变化的条目必须放在最前面并用感叹句式强调。 5. 输出纯文本不含解释性开头。 如果项目还没有 tag则基于最近 30 条 commit 归纳并在开头注明 此日志基于最近 N 条提交生成建议尽快补充版本标签。我不掩饰地说这个命令生成的日志不是完美的因为 commit 信息本身质量参差。但它好在能一口气把几个版本的变更都归纳完我再手动微调比从零整理快一个量级。还有个小技巧配合上一节的/提交信息命令产出规范 commit再跑更新日志时质量会明显上一个台阶。2.10 /环境准备 —— 新项目起步自动搭建最后一个命令是开箱即用的初始化流程。它针对的是进入一个新项目AI 不知道从哪看起的尴尬期。--- description: 初始化新会话识别技术栈并梳理运行方式 argument-hint: 可补充项目背景、队友想实现的短期目标 --- 当你进入一个新项目时请先做一次环境勘察再规划后续动作。 背景补充$ARGUMENTS 执行步骤 1. 列出项目根目录结构识别语言、框架、包管理器、配置文件。 2. 尝试从 README、Makefile、package.json、docker-compose.yml 等 文件里总结出如何安装依赖、如何启动、如何跑测试。 3. 把关键命令整理成清单开发启动命令、构建命令、测试命令、代码规范命令。 4. 如果我给了短期目标基于以上勘察结果给出一份 3-5 步执行计划。 5. 如果项目有缺失文档指出哪些环节没有说明需要我去补。 输出保持简洁不要用套话。进入新项目时第一件事往往是读一堆文档无从头。这个命令把我的项目勘察手册固化下来新会话第一次对话就省去大量上下文的重复铺垫。它也是我拿来验证命令包是否被正确加载的常用命令因为输出里直接出现项目目录结构一眼就能判断 AI 有没有拿到完整上下文。3. 工作流包的安装与配置实操3.1 命令包目录结构我建议你在自己的配置管理仓库里单独建一个claude-workflow-zh文件夹结构保持和 Claude Code 的加载规则一致方便整体同步claude-workflow-zh └── commands ├── 需求分析.md ├── 架构设计.md ├── 代码审查.md ├── 调试修复.md ├── 重构优化.md ├── 测试生成.md ├── 数据库设计.md ├── 提交信息.md ├── 更新日志.md └── 环境准备.md这样做的理由有两条。一是 Claude Code 原生的加载路径只认commands目录文件名即命令名所以目录结构必须严格保持二是单独建仓可以纳入版本管理后续自己改了哪个命令git diff一清二楚团队之间同步也只需要git pull。3.2 两种安装范围与具体步骤Claude Code 支持两个级别的命令目录项目级别和用户级别。项目级别放在当前项目根目录的.claude/commands/下只对这个项目生效适合跟着团队仓库走用户级别放在用户主目录的~/.claude/commands/下全局生效。Windows 下用户目录通常是C:\Users\你的用户名\.claude\commands\。这里有个容易踩的坑如果你把命令放进项目级目录要确保这个目录被打进 Git 仓库别人 clone 下来才能用。如果只想自己用全局用户级是更省事的选择任何项目打开 Claude Code 都能调用。安装时可以直接复制文件也可以用一条命令完成# 全局安装macOS / Linux mkdir -p ~/.claude/commands cp -r claude-workflow-zh/commands/* ~/.claude/commands/ # Windows PowerShell New-Item -ItemType Directory -Force -Path $HOME\.claude\commands Copy-Item -Path claude-workflow-zh\commands\* -Destination $HOME\.claude\commands\ -Recurse复制完之后重新进入 Claude Code 会话输入/应该能在命令列表里看到这 10 个中文命令。如果没看到大概率是编码或者目录层级问题我下面第四节会专门讲排查方法。3.3 参数使用与命名规范$ARGUMENTS的机制很简单命令文件正文里写了$ARGUMENTS你在执行命令时输入的后续所有文本都会被原样替换进去。比如输入/需求分析 做一个会员积分回馈功能那这段会员积分回馈功能就会替换掉文件里的$ARGUMENTS占位符。但如果需要传多个参数比如/测试生成 登录接口 要覆盖并发场景AI 拿到的是整句登录接口 要覆盖并发场景它需要自己从中拆分意图。我的经验是在命令正文里明确写好格式要求比如如果描述中包含多个关注点请分别拆解比在两个占位符之间做解析靠谱得多。Claude Code 的命令机制没有真正意义上的位置参数所有输入都汇集成一个字符串所以你必须在模板里教会 AI 如何拆解这句话。命名规范上我建议文件名遵循动词 对象的格式需求分析、数据库设计、提交信息读起来是完整的指令。避免只用一个名词比如单纯叫测试AI 不知道你要生成测试还是运行测试。另外就算用中文名也最好在 frontmatter 的 description 里写清边界这样命令面板的提示足够明确不会让人猜。4. 踩坑实录中文命令的血泪排查4.1 中文文件名带来的兼容性问题最无语的坑是编码问题。在 Windows 上用记事本保存.md文件默认很可能是 UTF-8 with BOM。这个 BOM 字符会悄悄出现在 YAML frontmatter 的---之前Claude Code 解析 frontmatter 时直接失败命令就不出现在面板上。表面现象是文件放对了目录格式也对但命令就是加载不出来。解决办法很简单用 VS Code 或任何支持编码选择的编辑器重新保存为 UTF-8 without BOM。macOS 和 Linux 下一般没这个问题但保险起见我建议所有命令文件统一用 VS Code 维护顺手可以装个 markdownlint 之类插件帮你看 frontmatter 格式。另一个坑是终端输入法的问题。有些输入法在终端里输/之后会触发中英文切换导致命令名输入不完整甚至被吞字符。我的规避方案是多敲几个字符让补全生效比如直接输/需求分析时如果输入法捣乱可以先切英文输入法打/xuqi或/需求让 Cluade Code 自动补全。这里不用强求英文文件名因为补全逻辑是按前缀匹配的。4.2 命令不生效的 5 类原因我整理了一个最具性价比的排查清单按出现频率排序现象最可能原因处理办法输入/看不到中文命令文件不在commands目录核对路径直接ls ~/.claude/commands/能看到命令但执行报 YAML 错误frontmatter 格式错误或存在 BOM用 VS Code 另存为 UTF-8 without BOM命令能执行但完全没有按模板约束文件正文被截断或缩进混乱检查 YAML 分隔线是否在文件最顶部不要有空行改完模板后行为还是旧的会话缓存了旧命令重开 Claude Code 会话不要相信即时刷新别人电脑上不生效项目级目录未纳入 Git确认.claude/commands已git add并推送这里面最容易忽略的是重开会话。Claude Code 对命令文件的加载时机不是每次输入都扫描的至少我实测下来修改完文件经常需要新开会话才生效。为了不白等我改完模板后的固定动作是CtrlC退出当前会话再重进一次。4.3 参数传递的边界$ARGUMENTS看着好用但它的边界很隐蔽。假如你输入的参数里包含换行或者包含特殊字符如引号、花括号Claude Code 不会替你转义会原样替换进正文。这在大多数场景下问题不大但有一种情况会出岔子你想让 AI 执行的命令里本身包含$ARGUMENTS字样或反引号就可能被误解析。我的经验是把$ARGUMENTS当作一个整块待分析文本来用而不是当结构化编程语言的参数。如果你需要让 AI 接收多组信息比如同时传目标文件和测试重点不要指望命令框架帮你区分直接在命令正文里写清楚格式示例比如请解析以下输入格式为文件路径测试重点。 输入内容 $ARGUMENTS 解析后分别处理路径部分用于定位被测代码重点部分用于设计用例。这样哪怕用户输入得随意一点AI 也会按你定义的语义去拆分。还有一个常见的坑用户执行命令时只在后面加了半句没说完的话$ARGUMENTS不可能自动帮你补充完整。所以我的命令模板里都会显式要求如果信息不足先索要缺失信息不要凭空假设这句话能防止 AI 拿着残句硬编。5. 从个人命令到团队工作流包5.1 复用与版本管理既然是工作流包最核心的价值应该是可复用。我的做法是把整个claude-workflow-zh仓库当作团队内部的基础设施来管命令文件的变更一律走 PR review和代码评审一个待遇。这样做的原因很简单命令文件本质上是团队的提示词资产里面沉淀的是大家对好的需求分析长什么样代码审查该关注什么的共同认知。版本管理上我建议每个命令文件正文末尾加一段注释形式的版本信息比如!-- v2.1加入边界条件清单v2.0调整输出为分级结构 --这种注释不影响 AI 的指令内容但你在排查为什么行为和上周不一样时能直接定位到版本改动。特别是团队里有人提了能不能让它多给一条建议之类的需求改完标注版本后续不会出现混乱。5.2 自定义你自己的命令模板这 10 个命令不是终点关键是掌握设计模式。我总结的三个要点是定结构、给边界、要验证。定结构就是模板必须把输出组织成固定的小节AI 的自由发挥被限制在这些小节里给边界就是明确告诉它什么东西不要做、什么情况先提问要验证则是所有涉及改代码的命令末尾必须写清怎么证明你改对了。你完全可以按自己的岗位改造出另一批命令。比如运营同事可以做一个/活动复盘命令让 AI 按目标、数据、归因、下一步四个板块输出做数据的朋友可以做一个/SQL优化命令固定要求先看执行计划再给出索引建议。本质都是一样的把一个反复执行的判断过程固化成稳定的提示词结构。5.3 与编辑器、桌面端点配合的杂项最后说几个实际使用中的杂项技巧。在 VS Code 里使用 Claude Code 插件时命令包的加载逻辑和终端版一致所以配置完目录结构后编辑器里同样能直接用。装桌面版的话用户级路径下的命令也是通用的不需要单独维护两套。还有一条关于本地模型服务的经验如果你配置了兼容 Anthropic 协议的服务端点来跑 Claude Code这套命令包依然能正常工作因为命令的本质只是提示词文本解析和加载发生在客户端。切换不同模型供应商时工作流命令本身不需要改动只需要保证你切换的服务支持足够的上下文长度否则长模板的命令容易被截断。我个人在实际使用中最大的体会是命令包这种玩法真正的门槛不在技术而在你愿不愿意花一个晚上把自己的重复劳动提炼成模板。一旦提炼出来后面每一次复用都是纯收益。最后送上一个实用小技巧不要一口气做 10 个命令先把你最近一周用 Claude Code 做过的 5 件重复的事写下来从最烦的那件开始做成命令用一周再迭代第二版。工具不是越多越酷贴手才是真的。 用中文Slash Command固化Claude Code高频操作：10个命令工作流设计
先说个真实场景。你坐在终端前想用 Claude Code 帮忙把一段烂代码理一理结果又开始敲那段复制了无数次的英文提示词please review the code, focus on potential bugs, suggest improvements… 敲完还得担心它理解偏了输出一堆正确的废话。更麻烦的是团队里的同事第一次打开 Claude Code 根本不知道能干嘛你口头教完他还是一脸懵。我花了两个晚上把平时最高频的 10 类操作全部做成了中文 slash 命令打包成一个工作流包直接丢进.claude/commands/目录。现在输入/需求分析、/代码审查、/提交信息后面跟上你的具体要求剩下的提示词细节全部由命令文件补全。这套方案既不依赖外部插件也不改 Claude Code 本体纯靠它自带的命令机制实现零维护成本。这篇就把这套工作流的完整设计思路、10 个命令的原始配置、安装步骤、以及我实际踩过的坑全部摊开讲一遍。准备照着做的朋友你只需要已经装好 Claude Code CLI能用终端打开交互界面剩下的一切跟着配置就行。没装过的先花两分钟装好再回来看这篇。1. 为什么我把日常操作全部做成 slash command1.1 重复提示词的账单比你想的更贵很多人觉得自己写 prompt 很灵活没必要做成命令。我一开始也这么想直到有一次给同一个项目连续改了三次接口设计每次都要重新把上下文、约束条件、输出格式打一遍。打完发现真正花在思考上的时间没多少时间全耗在把需求翻译成 AI 能理解的结构化描述上了。这其实是重复提示词的隐性成本第一每次写 prompt 的一致性问题今天强调代码风格明天忘了提输出质量就像开盲盒第二长提示词本身就有噪音AI 读着一堆临时拼凑的句子很容易抓错重点第三团队协作成本被放大了。像我带过的新人第一次用 Claude Code 时的典型反应是知道它能写代码但哪里敢把关键任务交给它根本不知道从哪句话开始。把这些高频动作固化成 slash command 之后等于把怎么写好这次 prompt这个问题提前用结构化模板解决了。你在终端里敲一个短命令加几个参数AI 拿到的是经过反复调优的完整指令效果自然比临场发挥稳定得多。1.2 slash command 到底是什么Claude Code 原生支持一个非常朴素的扩展机制在.claude/commands/目录下放一批 markdown 文件文件名去掉.md后缀就是命令名。命令文件顶部用 YAML 写 metadata 描述命令用途正文就是真正会发给模型的提示词内容。项目下或用户目录下 └── .claude └── commands ├── 需求分析.md ├── 架构设计.md ├── 代码审查.md └── ...这个机制最爽的地方是它不要求你掌握任何新语言。会写 markdown、会写中文提示词你就能做命令。配合$ARGUMENTS这个占位符用户在执行/命令名 参数时输入的内容会被原样嵌入命令正文从而实现了短命令 长模板的组合。我之所以选中文文件名而不是review、refactor这种英文名直接原因是这套工作流的使用者以中文为母语中文名字在命令面板里一眼就能看懂。严格来说这也算某种模型无关的工程优化你换的是提示词工程层的封装和背后使用哪个模型没有关系。1.3 中文命名不是偷懒而是降低使用门槛有人会觉得中文文件名不够极客但我实测下来对普通使用者来说中文的识别速度远超英文缩写。终端输入时你只需要打出/需求Claude Code 会自动补全成/需求分析基本不增加输入成本。更重要的是它降低了第一次使用的心理门槛。团队里不懂 AI 的同事看到命令列表看到的是需求分析、代码审查、数据库设计、提交信息这些他本来就要做的事自然明白该点哪个。这种设计跟产品的空状态引导思路一样工具的高级感不重要能让人愿意用起来才重要。2. 十个命令的设计与实现下面把这 10 个命令逐个拆开。每个命令我都会给出可直接落地的 markdown 文件内容然后解释设计意图和我的实测体验。你自己用的时候不用一字不差照抄重点吃透每个命令里结构性约束的部分。2.1 /需求分析 —— 把模糊想法变成可执行需求这个命令专门处理一类高频场景你脑子里只有个模糊方向比如用户模块要做个权限升级但要落成开发任务还差得远。--- description: 把零散想法整理成可执行的需求文档 argument-hint: 简要描述你想要的场景或功能 --- 请扮演资深产品负责人和系统分析师的综合角色帮我把下面这个模糊想法 拆解成可直接进入研发的软件需求。 用户描述 / 原始想法的核心是 $ARGUMENTS 请按以下结构输出 1. 需求背景与业务价值一句话说清楚为什么要做。 2. 功能范围列表用 MoSCoW 优先级标注Must/Should/Could/Wont。 3. 用户流程或典型场景至少给出 3 个具体场景。 4. 边界和例外情况列出至少 5 种异常或边界输入。 5. 验收标准用当...时系统应该...的句式描述覆盖主路径和边界路径。 6. 待确认问题列出开发前必须由业务方回答的 3-5 个问题。 如果我的描述里有歧义先主动提出你的理解再按这个框架输出。这个命令的价值在于它强制 AI 一次性把业务想法翻译成研发输入。以前我给 AI 一句话需求它可能直接甩出一段代码有了这个模板它会先做结构化拆解我再决定哪些做、哪些不做。实测最有用的是第 6 条待确认问题它经常能问出我自己都没考虑到的业务细节。2.2 /架构设计 —— 给技术选型加约束架构设计这个活AI 最容易犯的毛病是给一个看似合理但完全不符合项目现状的方案。所以我故意在命令里加了先读项目再说话的约束。--- description: 生成技术方案对比选型并给出落地建议 argument-hint: 描述要设计的模块或要解决的问题 --- 你现在是一位资深架构师先读一下当前项目根目录里的 README、package.json、 pyproject.toml 等描述文件再结合我下面提到的问题来做设计。 待设计的问题是 $ARGUMENTS 输出要求 1. 先给出 2-3 种候选方案每种方案要写清楚实现思路、优势和代价。 2. 对比表按复杂度、性能、可维护性、团队上手成本四个维度打分。 3. 基于当前项目现状给出明确推荐并说明哪些约束条件影响了你的选择。 4. 给出分阶段落地步骤第一阶段的改动面必须控制在最小范围。 5. 指出你推荐方案的潜在风险点以及回滚方案。 注意不要凭空引入当前项目未使用的技术栈如必须引入需给出理由。我实测下来的感受是先读项目描述文件这条约束是灵魂。加了之后AI 给出的方案会贴着项目的实际技术栈说而不是泛泛而谈。还有一点命令里要求明确说明哪些约束条件影响了选择这能让它把决策依据讲清楚而不是只给结论。2.3 /代码审查 —— 当结对评审用代码审查是使用频率最高的命令之一。我没有让它检查所有问题而是引导它按严重程度分级并且每条建议必须给出可操作修改避免空话套话。--- description: 审查当前改动或指定文件输出分级评审意见 argument-hint: 可指定文件名、文件范围或留空让 AI 自行分析 --- 请以资深代码评审者的角色审查代码。 审查范围$ARGUMENTS如果为空则根据当前 git diff 自动识别变更文件 重点检查维度 1. 正确性并发问题、边界条件、资源泄漏、错误处理缺失。 2. 安全注入风险、敏感信息泄漏、越权访问。 3. 可维护性命名、重复代码、模块耦合、可测试性。 4. 性能不必要的循环、N1 查询、大对象引用。 输出格式 - 必须按 P0 / P1 / P2 三个级别分类问题。 - P0 是会导致线上故障或严重安全风险的问题必须给出修复示例 - P1 是潜在缺陷或明显设计问题需要给出改进建议 - P2 是风格和可读性层面的建议简写即可。 - 所有输出使用中文修复示例用代码块给出。 - 如果审查结果没有问题也请你明确说清楚哪些隐患你检查过确认没有遗漏。我以前直接用一句话让 AI 审查代码它经常把风格问题当成大问题讲半天真正的并发隐患反而漏掉。这个命令把检查维度固定下来以后输出结构就变得稳定了处理修 bug 的流程也会顺很多。2.4 /调试修复 —— 禁止猜答案先复述问题调试这个场景最忌讳的是 AI 还没看明白问题就开始改代码。我用命令强行规定它的工作顺序先复述、再定位、后修复最后必须验证。--- description: 根据报错或异常行为定位并修复缺陷 argument-hint: 粘贴报错信息或描述异常表现 --- 你现在是 Debug 专家。在给出任何结论之前严格遵守以下流程 第 1 步必须执行用自己的话复述问题包括它出现的场景、输入、 期望行为和实际行为如果信息不足先索要缺失信息。 第 2 步基于代码库提出至少 3 个可能导致该问题的假设按可能性排序。 第 3 步针对排名最高的假设给出最小验证方案加日志、写单测 或构造最小复现不要直接改生产代码。 第 4 步确认根因后再给出修复代码。修复必须最小化改动。 第 5 步给出验证方法应该运行什么测试、观察什么日志输出 才能确认问题真正解决。 问题是 $ARGUMENTS这个命令救过我一次。之前有个偶发超时问题AI 上来就改了一行超时配置结果当然是没解决。后来用这个命令它老老实实分析了三个假设最后定位到是连接池耗尽而不是超时时间不够。强制先复述问题的好处是很多bug其实在第一遍复述时你自己就发现是理解偏差了。2.5 /重构优化 —— 小步重构避免大爆炸重构的常见悲剧是 AI 大刀阔斧改一堆文件最后测试全挂你还不知道是哪里改崩的。这个命令的核心约束是保持行为不变、单次只做一个小重构。--- description: 对指定代码进行小步重构保持行为不变 argument-hint: 指定文件、函数或一段代码并说明重构目标 --- 请对以下代码进行小步重构严格遵守行为保持原则。 重构目标$ARGUMENTS 约束条件 1. 单次重构只允许做一类操作提取函数、消除重复、重命名、 简化条件表达式或调整模块结构不要混着来。 2. 任何一步重构都不允许改变现有功能的外部行为包括边界条件。 3. 重构前先说明当前代码的主要坏味道重构后逐项说明 你做了什么以及为什么这样不影响行为。 4. 如果重构涉及多个步骤请一步一步列清楚不要一次性给出 一个巨大的改动 diff。 5. 最后给出如何验证应运行哪些现有测试或补什么测试来兜底。我通常会在重构前先让 AI 生成一轮/测试生成把关键行为用测试锁住再跑重构命令。这种顺序操作之后大改动的心理压力小很多因为每一步都有测试兜底。实测重构命令给出的分步方案比一次性 diff 的可读性好太多代码评审时也容易过。2.6 /测试生成 —— 按语义补全单测写单测是自己最不想干、但 AI 最擅长的活。这个命令的重点不是凑覆盖率而是要求测试围绕业务语义和边界值来写。--- description: 为指定函数或模块生成单元测试 argument-hint: 指定函数或文件可补充测试重点 --- 请为以下目标生成单元测试 目标$ARGUMENTS 要求 1. 先分析这个函数/模块的输入域和业务规则列出至少 5 个 有测试价值的场景正常路径、边界值、非法输入、异常分支。 2. 测试用例名称使用中文描述意图例如当金额为负数时应该抛错。 3. 使用项目已有的测试框架不要引入新的测试依赖。 4. 生成的测试必须能跑得通不能因为 mock 方式错误而失败。 5. 额外说明哪些场景你故意不测以及为什么例如成本过高、收益低。这个命令设计上最妙的是第 2 条强制中文用例名。以前 AI 生成的测试叫 test_user_login_with_valid_credentials看半天不知道测的啥现在一眼就看到登录成功后应返回 token。项目里的测试文件逐渐变成了一份能读的业务文档这点让我极其受用。2.7 /数据库设计 —— 从业务描述到表结构数据库设计这个场景AI 的输出往往缺索引、缺外键、缺迁移脚本纯产出两张建表 SQL 完事。我做的命令把完整交付物拆成了固定结构。--- description: 根据业务描述输出表结构设计、索引与迁移脚本 argument-hint: 描述业务实体和关系例如用户、订单、商品等 --- 请基于以下业务描述进行数据库设计 业务描述$ARGUMENTS 输出要求 1. 实体识别列出核心实体和实体间关系一对一/一对多/多对多。 2. 每张表给出字段清单包含字段名、类型、约束、默认值、注释。 3. 索引设计给出每个索引的字段和设计理由特别是查询频率高的字段。 4. 核心表需要说明软删除、创建时间、更新时间等通用字段的约定。 5. 输出可直接执行的 DDL 迁移脚本并说明回滚脚本。 6. 指出这个设计可能存在的性能瓶颈或数据增长风险点。设计意图很简单数据库设计不是建表而是数据建模和长期演进规划。有了这个模板AI 至少会把索引和外键想一遍而不是只把字段罗列出来。迁移脚本我是强烈要求必须有的否则本地改着玩还行一上协作流程就乱。2.8 /提交信息 —— 终结绞尽脑汁写 commit message这可能是最没有技术含量、但每天用得最多的命令。它不需要 AI 读什么上下文只要读 git diff 就够了。--- description: 根据 git diff 自动生成规范的 commit message argument-hint: 可补充提交说明例如 bugfix、新功能、重构等 --- 请先执行 git diff --staged如果没有暂存内容再看 git diff然后根据改动 生成一份符合 Conventional Commits 规范的提交信息。 补充说明$ARGUMENTS 要求 1. type 属于 feat / fix / refactor / docs / test / chore / perf 之一。 2. 提交信息开头用一句中文概括不要用英文祈使句。 3. 正文列出关键改动点按重要程度排序每点一句话。 4. 如果检测到可能 breaking change必须在正文里单独标记。 5. 只要最终一条提交信息不要提供多个候选版本。实际用的时候我的流程是git add .之后直接输入/提交信息它读出 diff 生成一条信息我检查没问题就提交。这个命令帮我解决的最大问题是提交粒度以前我经常一个 commit 塞一堆不相关改动现在 AI 会按改动类型组织正文变相逼着我自己把提交拆干净。2.9 /更新日志 —— 按版本聚合变更整理 CHANGELOG 是发版前最让人头痛的杂活。这个命令基于git tag和日志来聚合版本变更省去翻 commit 的时间。--- description: 根据 git 历史生成或更新 CHANGELOG argument-hint: 可指定版本范围例如 v1.0.0..v1.1.0 --- 请执行 git tag 和 git log 查看提交历史然后生成一份更新日志。 版本范围$ARGUMENTS留空则取最近的 tag 到当前 HEAD 输出格式 1. 按版本号倒序排列标题格式 ## [版本号] - 日期。 2. 每个版本下分为新功能、修复、重构、文档、依赖更新几个小节。 3. 把同一语义的提交合并成一条不要逐条复制 commit message。 4. 对行为有破坏性变化的条目必须放在最前面并用感叹句式强调。 5. 输出纯文本不含解释性开头。 如果项目还没有 tag则基于最近 30 条 commit 归纳并在开头注明 此日志基于最近 N 条提交生成建议尽快补充版本标签。我不掩饰地说这个命令生成的日志不是完美的因为 commit 信息本身质量参差。但它好在能一口气把几个版本的变更都归纳完我再手动微调比从零整理快一个量级。还有个小技巧配合上一节的/提交信息命令产出规范 commit再跑更新日志时质量会明显上一个台阶。2.10 /环境准备 —— 新项目起步自动搭建最后一个命令是开箱即用的初始化流程。它针对的是进入一个新项目AI 不知道从哪看起的尴尬期。--- description: 初始化新会话识别技术栈并梳理运行方式 argument-hint: 可补充项目背景、队友想实现的短期目标 --- 当你进入一个新项目时请先做一次环境勘察再规划后续动作。 背景补充$ARGUMENTS 执行步骤 1. 列出项目根目录结构识别语言、框架、包管理器、配置文件。 2. 尝试从 README、Makefile、package.json、docker-compose.yml 等 文件里总结出如何安装依赖、如何启动、如何跑测试。 3. 把关键命令整理成清单开发启动命令、构建命令、测试命令、代码规范命令。 4. 如果我给了短期目标基于以上勘察结果给出一份 3-5 步执行计划。 5. 如果项目有缺失文档指出哪些环节没有说明需要我去补。 输出保持简洁不要用套话。进入新项目时第一件事往往是读一堆文档无从头。这个命令把我的项目勘察手册固化下来新会话第一次对话就省去大量上下文的重复铺垫。它也是我拿来验证命令包是否被正确加载的常用命令因为输出里直接出现项目目录结构一眼就能判断 AI 有没有拿到完整上下文。3. 工作流包的安装与配置实操3.1 命令包目录结构我建议你在自己的配置管理仓库里单独建一个claude-workflow-zh文件夹结构保持和 Claude Code 的加载规则一致方便整体同步claude-workflow-zh └── commands ├── 需求分析.md ├── 架构设计.md ├── 代码审查.md ├── 调试修复.md ├── 重构优化.md ├── 测试生成.md ├── 数据库设计.md ├── 提交信息.md ├── 更新日志.md └── 环境准备.md这样做的理由有两条。一是 Claude Code 原生的加载路径只认commands目录文件名即命令名所以目录结构必须严格保持二是单独建仓可以纳入版本管理后续自己改了哪个命令git diff一清二楚团队之间同步也只需要git pull。3.2 两种安装范围与具体步骤Claude Code 支持两个级别的命令目录项目级别和用户级别。项目级别放在当前项目根目录的.claude/commands/下只对这个项目生效适合跟着团队仓库走用户级别放在用户主目录的~/.claude/commands/下全局生效。Windows 下用户目录通常是C:\Users\你的用户名\.claude\commands\。这里有个容易踩的坑如果你把命令放进项目级目录要确保这个目录被打进 Git 仓库别人 clone 下来才能用。如果只想自己用全局用户级是更省事的选择任何项目打开 Claude Code 都能调用。安装时可以直接复制文件也可以用一条命令完成# 全局安装macOS / Linux mkdir -p ~/.claude/commands cp -r claude-workflow-zh/commands/* ~/.claude/commands/ # Windows PowerShell New-Item -ItemType Directory -Force -Path $HOME\.claude\commands Copy-Item -Path claude-workflow-zh\commands\* -Destination $HOME\.claude\commands\ -Recurse复制完之后重新进入 Claude Code 会话输入/应该能在命令列表里看到这 10 个中文命令。如果没看到大概率是编码或者目录层级问题我下面第四节会专门讲排查方法。3.3 参数使用与命名规范$ARGUMENTS的机制很简单命令文件正文里写了$ARGUMENTS你在执行命令时输入的后续所有文本都会被原样替换进去。比如输入/需求分析 做一个会员积分回馈功能那这段会员积分回馈功能就会替换掉文件里的$ARGUMENTS占位符。但如果需要传多个参数比如/测试生成 登录接口 要覆盖并发场景AI 拿到的是整句登录接口 要覆盖并发场景它需要自己从中拆分意图。我的经验是在命令正文里明确写好格式要求比如如果描述中包含多个关注点请分别拆解比在两个占位符之间做解析靠谱得多。Claude Code 的命令机制没有真正意义上的位置参数所有输入都汇集成一个字符串所以你必须在模板里教会 AI 如何拆解这句话。命名规范上我建议文件名遵循动词 对象的格式需求分析、数据库设计、提交信息读起来是完整的指令。避免只用一个名词比如单纯叫测试AI 不知道你要生成测试还是运行测试。另外就算用中文名也最好在 frontmatter 的 description 里写清边界这样命令面板的提示足够明确不会让人猜。4. 踩坑实录中文命令的血泪排查4.1 中文文件名带来的兼容性问题最无语的坑是编码问题。在 Windows 上用记事本保存.md文件默认很可能是 UTF-8 with BOM。这个 BOM 字符会悄悄出现在 YAML frontmatter 的---之前Claude Code 解析 frontmatter 时直接失败命令就不出现在面板上。表面现象是文件放对了目录格式也对但命令就是加载不出来。解决办法很简单用 VS Code 或任何支持编码选择的编辑器重新保存为 UTF-8 without BOM。macOS 和 Linux 下一般没这个问题但保险起见我建议所有命令文件统一用 VS Code 维护顺手可以装个 markdownlint 之类插件帮你看 frontmatter 格式。另一个坑是终端输入法的问题。有些输入法在终端里输/之后会触发中英文切换导致命令名输入不完整甚至被吞字符。我的规避方案是多敲几个字符让补全生效比如直接输/需求分析时如果输入法捣乱可以先切英文输入法打/xuqi或/需求让 Cluade Code 自动补全。这里不用强求英文文件名因为补全逻辑是按前缀匹配的。4.2 命令不生效的 5 类原因我整理了一个最具性价比的排查清单按出现频率排序现象最可能原因处理办法输入/看不到中文命令文件不在commands目录核对路径直接ls ~/.claude/commands/能看到命令但执行报 YAML 错误frontmatter 格式错误或存在 BOM用 VS Code 另存为 UTF-8 without BOM命令能执行但完全没有按模板约束文件正文被截断或缩进混乱检查 YAML 分隔线是否在文件最顶部不要有空行改完模板后行为还是旧的会话缓存了旧命令重开 Claude Code 会话不要相信即时刷新别人电脑上不生效项目级目录未纳入 Git确认.claude/commands已git add并推送这里面最容易忽略的是重开会话。Claude Code 对命令文件的加载时机不是每次输入都扫描的至少我实测下来修改完文件经常需要新开会话才生效。为了不白等我改完模板后的固定动作是CtrlC退出当前会话再重进一次。4.3 参数传递的边界$ARGUMENTS看着好用但它的边界很隐蔽。假如你输入的参数里包含换行或者包含特殊字符如引号、花括号Claude Code 不会替你转义会原样替换进正文。这在大多数场景下问题不大但有一种情况会出岔子你想让 AI 执行的命令里本身包含$ARGUMENTS字样或反引号就可能被误解析。我的经验是把$ARGUMENTS当作一个整块待分析文本来用而不是当结构化编程语言的参数。如果你需要让 AI 接收多组信息比如同时传目标文件和测试重点不要指望命令框架帮你区分直接在命令正文里写清楚格式示例比如请解析以下输入格式为文件路径测试重点。 输入内容 $ARGUMENTS 解析后分别处理路径部分用于定位被测代码重点部分用于设计用例。这样哪怕用户输入得随意一点AI 也会按你定义的语义去拆分。还有一个常见的坑用户执行命令时只在后面加了半句没说完的话$ARGUMENTS不可能自动帮你补充完整。所以我的命令模板里都会显式要求如果信息不足先索要缺失信息不要凭空假设这句话能防止 AI 拿着残句硬编。5. 从个人命令到团队工作流包5.1 复用与版本管理既然是工作流包最核心的价值应该是可复用。我的做法是把整个claude-workflow-zh仓库当作团队内部的基础设施来管命令文件的变更一律走 PR review和代码评审一个待遇。这样做的原因很简单命令文件本质上是团队的提示词资产里面沉淀的是大家对好的需求分析长什么样代码审查该关注什么的共同认知。版本管理上我建议每个命令文件正文末尾加一段注释形式的版本信息比如!-- v2.1加入边界条件清单v2.0调整输出为分级结构 --这种注释不影响 AI 的指令内容但你在排查为什么行为和上周不一样时能直接定位到版本改动。特别是团队里有人提了能不能让它多给一条建议之类的需求改完标注版本后续不会出现混乱。5.2 自定义你自己的命令模板这 10 个命令不是终点关键是掌握设计模式。我总结的三个要点是定结构、给边界、要验证。定结构就是模板必须把输出组织成固定的小节AI 的自由发挥被限制在这些小节里给边界就是明确告诉它什么东西不要做、什么情况先提问要验证则是所有涉及改代码的命令末尾必须写清怎么证明你改对了。你完全可以按自己的岗位改造出另一批命令。比如运营同事可以做一个/活动复盘命令让 AI 按目标、数据、归因、下一步四个板块输出做数据的朋友可以做一个/SQL优化命令固定要求先看执行计划再给出索引建议。本质都是一样的把一个反复执行的判断过程固化成稳定的提示词结构。5.3 与编辑器、桌面端点配合的杂项最后说几个实际使用中的杂项技巧。在 VS Code 里使用 Claude Code 插件时命令包的加载逻辑和终端版一致所以配置完目录结构后编辑器里同样能直接用。装桌面版的话用户级路径下的命令也是通用的不需要单独维护两套。还有一条关于本地模型服务的经验如果你配置了兼容 Anthropic 协议的服务端点来跑 Claude Code这套命令包依然能正常工作因为命令的本质只是提示词文本解析和加载发生在客户端。切换不同模型供应商时工作流命令本身不需要改动只需要保证你切换的服务支持足够的上下文长度否则长模板的命令容易被截断。我个人在实际使用中最大的体会是命令包这种玩法真正的门槛不在技术而在你愿不愿意花一个晚上把自己的重复劳动提炼成模板。一旦提炼出来后面每一次复用都是纯收益。最后送上一个实用小技巧不要一口气做 10 个命令先把你最近一周用 Claude Code 做过的 5 件重复的事写下来从最烦的那件开始做成命令用一周再迭代第二版。工具不是越多越酷贴手才是真的。