10个中文命令装进Claude Code：打造高效AI编程工作流

1. 为什么我要折腾这套中文命令工作流用 Claude Code 做开发的人大概率都经历过这样一个阶段刚开始觉得终端里直接对话写代码很爽用了两周之后发现每次都要重复输入一大段提示词比如帮我 review 这个文件重点看边界条件和错误处理、把这段代码重构成函数式风格保持原有测试通过、生成这个模块的单元测试覆盖率达到 80% 以上。这些话每次都要打一遍打多了就烦烦了就想偷懒偷懒就直接扔一句帮我看看结果 AI 给你的反馈质量断崖式下跌。我自己的情况更极端一点。我日常在 Claude Code、Codex CLI 和几个不同的项目之间来回切换每个项目的技术栈、代码规范、测试框架都不一样。前端项目用 React Vitest后端用 Go testify脚本工具用 Python pytest。如果每次都要手动描述上下文一天下来光打字就消耗掉大量精力。更麻烦的是团队里其他人用同样的工具但每个人给的提示词风格不同导致 AI 输出的代码质量参差不齐review 的时候经常要返工。所以我就想能不能把那些高频的、重复的、有固定套路的操作封装成一套简短的命令用中文触发一键执行。这样不仅我自己用得爽团队里其他人也能直接复用保证输出质量的下限。这就是10 个中文命令装进 Claude Code这个项目的由来。这套东西本质上是一个轻量级工作流封装层。它不改变 Claude Code 本身的任何核心逻辑而是在它之上加了一层命令映射你输入一个简短的中文指令它自动展开成一段结构化的、经过调优的提示词再附带必要的上下文信息比如当前文件路径、项目类型、测试命令等最后把结果交给 Claude Code 执行。整个过程对你来说就是敲几个字的事但背后跑的是一套标准化的流程。适合谁来参考三类人。第一类是个体开发者想让 AI 编程助手更听话、更稳定第二类是技术团队负责人想统一团队的 AI 辅助开发规范第三类是对 CLI 工具链感兴趣、喜欢折腾效率工具的人。不管你用的是 Claude Code 还是 Codex CLI这套思路都可以迁移过去核心逻辑是通用的。接下来我会把这 10 个命令逐个拆开讲包括每个命令解决什么问题、背后的提示词怎么设计、参数怎么传、有哪些坑我踩过。同时也会讲清楚整个工作流包的架构设计以及怎么根据自己的需求去扩展。文章会比较长但都是实操干货建议收藏后慢慢看。2. 工作流包的整体架构与设计思路2.1 为什么选择命令映射而不是插件系统Claude Code 本身支持自定义命令和 hooks但它的扩展机制有一定的学习成本而且不同版本之间 API 可能有变化。我一开始也考虑过写一个完整的插件但后来放弃了原因有三个。第一插件系统的耦合度太高。一旦 Claude Code 升级改了接口插件可能直接挂掉维护成本不划算。而命令映射层是松耦合的它本质上就是一组 shell 脚本或者配置文件即使 Claude Code 换了版本只要它还支持基本的命令行调用这套东西就能继续用。第二命令映射的调试成本极低。你输入一个中文命令它展开成什么提示词你可以直接打印出来看。哪里不对改一行配置就行。插件系统往往需要跑测试、看日志、断点调试对于这种轻量级需求来说太重了。第三跨工具迁移方便。我今天用 Claude Code明天可能换成 Codex CLI后天可能试试别的。命令映射层的核心是提示词模板和上下文采集逻辑这部分跟具体工具无关。我只需要写一个适配层把展开后的提示词传给不同的 CLI 工具就行。所以最终架构是这样的一个命令注册表用 YAML 或 JSON 存一个上下文采集器自动获取当前项目信息一个提示词模板引擎把命令和上下文拼装成最终提示词再加一个执行适配层调用 Claude Code 或其他 CLI。整个东西加起来不到 500 行代码但覆盖了我日常 80% 的高频操作。2.2 10 个命令的分类与职责划分这 10 个命令不是随便选的而是根据我自己的开发流程梳理出来的。我把它们分成四类代码理解类看代码、找逻辑、画结构。这三个命令解决的是读懂现有代码的问题。你接手一个新项目或者回到三个月前自己写的代码第一件事就是理解它。这三个命令分别对应不同粒度的理解需求。代码生成类写函数、补测试、改样式。这三个是最高频的操作。写新功能、补测试覆盖、调整 UI 样式基本上占了日常开发的一半以上时间。代码质量类查问题、重构。这两个针对的是代码 review 和优化阶段。查问题侧重找 bug 和边界情况重构侧重改善代码结构和可读性。工程辅助类写提交、查文档。这两个是辅助性的但用好了能省不少时间。写提交信息看起来简单但要写出清晰、规范、有信息量的 commit message其实很费脑子。查文档则是快速定位某个 API 或配置项的用法。每个命令背后都有一套精心设计的提示词模板。这些模板不是随便写的而是经过反复调优确保 AI 输出的质量稳定。下面我会逐个拆解。2.3 上下文自动采集的实现方式光有提示词模板还不够AI 需要知道当前项目的上下文才能给出准确的回答。比如你让它补测试它得知道这个项目用什么测试框架、测试文件放在哪里、命名规范是什么。这些信息如果每次都手动输入那这套工作流就失去意义了。我的做法是写一个上下文采集脚本在命令执行前自动运行。它做以下几件事读取当前目录下的package.json、go.mod、requirements.txt等文件判断项目类型和依赖查找测试配置文件如vitest.config.ts、jest.config.js、pytest.ini确定测试框架读取.editorconfig、.eslintrc、.prettierrc等了解代码风格规范获取当前 git 分支名和最近一次提交信息判断当前工作状态如果是前端项目读取tsconfig.json了解路径别名配置这些信息会被整理成一段简短的上下文描述附加在提示词前面。比如[项目上下文] 类型React TypeScript 前端项目 测试框架Vitest 代码规范ESLint Prettier2 空格缩进单引号 路径别名/ 映射到 src/ 当前分支feature/user-profile这段上下文大概 100 到 200 字但能让 AI 的输出质量提升一个档次。实测下来加了上下文之后生成的测试代码直接能跑的比例从 60% 左右提升到 85% 以上。注意上下文采集要控制信息量不要把所有配置都塞进去。只采集跟当前命令相关的信息。比如改样式命令就不需要知道测试框架是什么。2.4 提示词模板的设计原则提示词模板的设计有几个核心原则这些是我踩了很多坑之后总结出来的。原则一角色设定要具体。不要写你是一个程序员而要写你是一个有 10 年经验的 React 开发者熟悉 Vitest 测试框架和 Testing Library 的最佳实践。角色越具体AI 的输出越专业。原则二输出格式要明确。如果你不指定格式AI 可能给你一段解释加一段代码也可能只给代码。我的做法是在模板里明确要求只输出代码不要解释或者先输出修改后的完整代码再用一句话说明改动点。原则三约束条件要写清楚。比如不要引入新的依赖、保持现有的函数签名不变、测试用例要覆盖空值、边界值和异常情况。这些约束能避免 AI 自作主张。原则四给示例比给描述更有效。与其说按照项目现有风格写测试不如直接附上一个现有测试文件的片段作为参考。AI 模仿能力很强给个例子它就能学得像模像样。原则五留出人工确认的环节。对于重构、删除这类有风险的操作模板里要明确要求 AI 先输出方案等确认后再执行。不要让它直接改文件。这五个原则贯穿了所有 10 个命令的设计。下面逐个命令拆解的时候你会看到它们的具体应用。3. 代码理解类命令的实操拆解3.1看代码快速理解一个文件的职责这个命令是我用得最频繁的。场景很简单你打开一个陌生的文件或者回到很久没看的代码想快速知道它在干什么。命令用法看代码 src/services/user-service.ts背后的提示词模板大致是这样的[项目上下文] ... 请分析以下文件用中文回答 1. 这个文件的核心职责是什么一句话概括 2. 它导出了哪些函数/类/常量各自的用途 3. 它依赖了哪些外部模块这些依赖分别用来做什么 4. 有没有明显的代码坏味道或潜在问题 要求 - 每个函数用一句话说明不要展开讲实现细节 - 如果文件超过 300 行只分析主要的导出项 - 用列表形式输出不要写大段文字 文件内容 {{file_content}}这个模板的关键在于限制输出粒度。如果你不限制AI 会把每个函数的实现细节都讲一遍输出一大堆你根本不想看的东西。我要求每个函数用一句话说明这样输出就很紧凑一眼能扫完。实测下来一个 200 行的文件输出大概 15 到 20 行30 秒内能读完。比自己逐行看快太多了。实操心得如果文件特别大超过 500 行建议先用找逻辑命令定位到具体函数再用看代码看细节。不要一上来就让 AI 分析整个大文件它容易抓不住重点。3.2找逻辑定位特定功能的实现位置这个命令解决的是我知道有个功能但不知道它在哪实现的这个问题。命令用法找逻辑 用户登录后的 token 刷新逻辑提示词模板[项目上下文] ... 在以下代码库中查找与{{query}}相关的实现代码。 要求 1. 列出所有相关的文件和函数按相关度排序 2. 对每个位置用一句话说明它跟查询的关系 3. 如果找到核心实现附上关键代码片段不超过 20 行 4. 如果找不到明确的实现说明可能的原因 代码库结构 {{project_structure}} 相关文件内容 {{relevant_files}}这个命令的难点在于如何确定相关文件。我的做法是先用关键词在项目里做一次全文搜索用grep或ripgrep把命中的文件路径和匹配行提取出来再把这些文件的内容一起传给 AI。这样 AI 不需要扫描整个项目只需要在候选文件里做判断。这里有个技巧搜索关键词的时候不要只用查询词本身还要用它的同义词和相关词。比如查token 刷新除了搜 token 和 refresh还要搜 renew、expire、auth 等。我一般会准备一个同义词映射表常见的技术词汇都有对应。注意如果项目很大全文搜索可能命中几百个文件。这时候要限制传给 AI 的文件数量一般不超过 10 个。优先选那些文件名或路径跟查询相关的。3.3画结构生成模块依赖关系图这个命令输出的是文字版的架构图用缩进和箭头表示模块之间的依赖关系。命令用法画结构 src/modules输出示例user 模块 ├── 依赖 auth 模块获取当前用户信息 ├── 依赖 api 模块调用后端接口 └── 被 profile 模块依赖提供用户数据 auth 模块 ├── 依赖 storage 模块存取 token └── 无外部模块依赖提示词模板[项目上下文] ... 分析以下目录结构生成模块依赖关系图。 要求 1. 用树形结构表示缩进表示层级 2. 每个模块标注它的依赖和被依赖关系 3. 如果存在循环依赖用 [循环] 标记出来 4. 不要分析模块内部的实现细节 目录结构 {{directory_tree}} 各模块的导入语句 {{import_statements}}这个命令的核心是提取导入语句。我用一个脚本扫描目录下所有文件的 import/require 语句提取出模块之间的引用关系再让 AI 整理成可读的树形结构。循环依赖的检测是重点。AI 在分析导入关系时能发现 A 导入 B、B 导入 C、C 又导入 A 这种情况。虽然 TypeScript 编译器也能检测循环依赖但 AI 的输出更直观而且能给出解决建议。实操心得这个命令特别适合在重构前使用。你先画一遍结构看清楚模块之间的关系再决定怎么拆分或合并。我试过在一个 50 多个模块的项目里用这个命令发现了好几处隐藏的循环依赖都是之前没注意到的。4. 代码生成类命令的实操拆解4.1写函数按规范生成新函数这是最常用的生成类命令。你描述需求它生成符合项目规范的函数代码。命令用法写函数 解析 JWT token返回 payload 中的 userId 和 roletoken 无效时抛出错误提示词模板[项目上下文] ... 请实现以下函数 需求{{requirement}} 要求 1. 使用 TypeScript严格类型不要用 any 2. 遵循项目的代码风格2 空格缩进单引号尾随逗号 3. 包含完整的错误处理 4. 添加 JSDoc 注释说明参数和返回值 5. 只输出函数代码不要写使用示例 6. 如果需要引入依赖先说明需要什么依赖 参考现有代码风格 {{style_reference}}这里的关键是参考现有代码风格。我会自动从项目里找一个风格良好的文件截取一段作为参考附上。AI 看到实际代码后生成的代码风格会非常接近几乎不需要手动调整。错误处理是另一个重点。如果你不明确要求AI 可能只写 happy path异常情况直接忽略。我要求包含完整的错误处理并且在需求描述里明确说明异常情况比如token 无效时抛出错误这样生成的代码才健壮。注意生成函数后不要直接复制粘贴就用。先看一遍逻辑确认边界条件处理正确。我遇到过 AI 生成的 JWT 解析函数没有验证签名的情况这种安全问题必须人工把关。4.2补测试为现有代码生成单元测试这个命令帮我省了最多时间。以前写测试要手动构造 mock、写断言、跑覆盖率现在一句话搞定。命令用法补测试 src/utils/format-date.ts提示词模板[项目上下文] ... 为以下文件生成单元测试。 要求 1. 使用 {{test_framework}} 测试框架 2. 覆盖以下场景正常情况、边界值、异常输入 3. mock 外部依赖不要发真实网络请求 4. 测试文件放在 {{test_file_path}} 5. 测试描述用中文简洁明了 6. 只输出测试代码 参考现有测试风格 {{test_style_reference}} 被测文件内容 {{file_content}}这个模板有几个细节值得说。测试框架自动识别上下文采集器会检测项目用的是 Vitest、Jest 还是其他框架自动填入{{test_framework}}。测试文件路径也根据项目约定自动生成比如src/utils/format-date.ts对应src/utils/format-date.test.ts。参考现有测试风格跟写函数一样我会附上一个现有测试文件的片段。这样生成的测试在命名、断言风格、mock 方式上都跟项目保持一致。覆盖场景的明确要求我明确要求覆盖正常情况、边界值、异常输入三类。如果不写这条AI 可能只测正常情况。边界值包括空字符串、null、undefined、极大值、极小值等。异常输入包括类型错误、格式错误等。实测下来生成的测试直接能跑的比例在 85% 左右。剩下 15% 通常是 mock 配置需要微调或者某些边界情况的预期值需要修正。即使这样也比从零写测试快太多了。实操心得生成测试后先跑一遍看覆盖率报告。如果某些分支没覆盖到再针对性地让 AI 补充。不要指望一次生成就 100% 覆盖迭代两三轮是正常的。4.3改样式调整 UI 组件样式这个命令主要针对前端项目用来修改组件的 CSS 或样式相关代码。命令用法改样式 src/components/Button.tsx 把主按钮的背景色改成品牌蓝 #1890ffhover 时加深 10%提示词模板[项目上下文] ... 修改以下组件的样式。 修改需求{{requirement}} 要求 1. 保持组件的 props 接口不变 2. 使用项目现有的样式方案{{style_solution}} 3. 不要修改组件的逻辑代码 4. 如果需要新增样式变量在文件顶部定义 5. 输出修改后的完整文件 组件代码 {{component_code}}这里的关键是样式方案识别。项目可能用 CSS Modules、styled-components、Tailwind CSS 或者普通 CSS。上下文采集器会检测项目用的方案填入{{style_solution}}。这样 AI 生成的样式代码就跟项目一致不会出现混用的情况。不要修改组件的逻辑代码这条约束也很重要。有时候 AI 会顺手重构一下组件逻辑虽然可能是好意但会增加 review 成本。明确限制后它就只动样式部分。注意涉及颜色、间距这类视觉调整最好附上设计稿的截图或者具体的数值。光说好看一点AI 是没法执行的。我一般会要求需求描述里包含具体的色值、像素值或相对比例。5. 代码质量类命令的实操拆解5.1查问题代码 review 与潜在 bug 排查这个命令相当于请了一个不知疲倦的 code reviewer。你给它一个文件或一段 diff它帮你找问题。命令用法查问题 src/services/payment.ts或者针对 git diff查问题 --diff提示词模板[项目上下文] ... 请 review 以下代码找出潜在问题。 重点检查 1. 边界条件处理空值、越界、类型错误 2. 错误处理是否完整 3. 是否有资源泄漏未关闭的连接、未清理的定时器 4. 并发安全问题 5. 性能隐患不必要的循环、重复计算 6. 安全隐患注入、越权、敏感信息泄露 输出格式 - 按严重程度排序高/中/低 - 每个问题说明位置、问题描述、建议修复方式 - 如果某类问题不存在不用列出 代码内容 {{code_content}}这个模板的核心是检查清单。如果你只说帮我 review 代码AI 的检查是随机的可能这次看边界条件下次看性能不稳定。给出明确的检查清单后每次 review 都覆盖这些维度质量就稳定了。严重程度排序也很重要。AI 有时候会把一个命名不规范的问题跟一个空指针异常并列这显然不合理。要求按严重程度排序后你能快速定位到真正需要修的问题。实操心得--diff模式特别适合在提交前跑一遍。它只 review 你这次改动的部分不会翻出历史遗留问题。我一般在git add之后、git commit之前跑一次能拦下不少低级错误。5.2重构改善代码结构而不改变行为重构是最需要谨慎的操作。我的原则是AI 出方案人工确认后再执行。命令用法重构 src/utils/data-processor.ts 这个文件太长了拆分成多个小文件提示词模板[项目上下文] ... 请对以下代码提出重构方案。 重构目标{{goal}} 要求 1. 先输出重构方案说明要拆分成哪些部分、每个部分的职责 2. 说明重构后对外接口是否变化 3. 列出可能的风险点 4. 不要直接输出重构后的代码等我确认方案后再生成 代码内容 {{code_content}}注意最后一条不要直接输出重构后的代码。这是故意的。重构涉及结构调整如果 AI 直接改你可能看不过来容易引入 bug。先看方案确认思路对了再让它生成代码这样可控性高很多。方案确认后我会用第二个命令重构执行来生成实际代码。这个命令会附上确认后的方案要求 AI 严格按照方案执行不要自由发挥。注意重构后一定要跑测试。如果测试覆盖不足先补测试再重构。我踩过一次坑重构一个没有测试的工具函数结果改出了一个边界 bug上线后才发现。6. 工程辅助类命令与工作流集成6.1写提交生成规范的 commit message这个命令看起来简单但用好了能省不少事。命令用法写提交它会自动读取当前 staged 的改动生成 commit message。提示词模板[项目上下文] ... 根据以下 git diff生成一条 commit message。 要求 1. 遵循 Conventional Commits 规范feat/fix/refactor/docs/test/chore 2. 第一行不超过 50 个字符用中文 3. 如果有必要空一行后写详细说明 4. 只输出 commit message不要其他内容 Git diff {{git_diff}}Conventional Commits 规范是我团队统一采用的。好处是 commit history 清晰而且可以自动生成 changelog。AI 判断类型feat 还是 fix的准确率挺高的偶尔需要手动调整。实操心得如果一次改动包含多个不相关的修改建议拆成多个 commit。写提交命令对单一目的的改动效果最好。混合改动它也能生成但 message 会比较笼统。6.2查文档快速定位 API 用法这个命令严格来说不是操作代码而是查询知识。你问一个 API 的用法它给你答案。命令用法查文档 Vitest 的 vi.mock 怎么 mock 一个模块的部分导出提示词模板[项目上下文] ... 回答以下技术问题 问题{{question}} 要求 1. 直接给出答案不要铺垫 2. 附上可运行的代码示例 3. 如果项目里已经有类似用法引用项目中的实际代码 4. 说明常见的坑和注意事项 项目相关代码 {{relevant_code}}这个命令的价值在于结合项目实际。普通的文档查询工具给你的是通用答案而查文档会先搜索项目里有没有类似用法如果有就引用实际代码。这样答案更贴合你的项目环境。6.3 与 Claude Code 和 Codex CLI 的集成方式这套工作流包本身不绑定特定的 CLI 工具。它的执行适配层支持多种后端。对于 Claude Code我用的方式是通过它的非交互模式调用。具体来说把展开后的提示词通过管道传给它或者写到一个临时文件里让它读取。Claude Code 的命令行参数支持指定提示词文件这样就能实现自动化。对于 Codex CLI集成方式类似。Codex CLI 支持通过标准输入接收提示词所以适配层只需要把提示词写到标准输入就行。适配层的核心是一个配置文件定义不同后端的调用方式backends: claude-code: command: claude args: [--prompt-file, {prompt_file}] input_mode: file codex-cli: command: codex args: [] input_mode: stdin这样切换后端只需要改配置不用改代码。我平时主要用 Claude Code偶尔用 Codex CLI 做对比测试切换很顺畅。注意不同 CLI 工具对提示词长度有限制。如果展开后的提示词太长比如附带了大量代码可能需要截断或分段。我的做法是控制单次传入的代码量一般不超过 500 行。7. 常见问题与排查技巧实录7.1 命令展开后提示词为空或乱码这是最常见的问题通常是因为上下文采集脚本执行失败导致模板变量没有被替换。排查步骤先单独运行上下文采集脚本看输出是否正常检查当前目录是否是项目根目录采集脚本依赖根目录的配置文件检查模板文件编码确保是 UTF-8如果用了 shell 变量替换注意转义问题我遇到过一次是因为项目根目录没有package.json采集脚本判断不出项目类型直接报错退出。后来加了个兜底逻辑检测不到项目类型时用默认配置就不会中断了。7.2 AI 输出格式不符合预期有时候你要求只输出代码AI 还是加了一段解释。这通常是因为提示词里的约束不够强或者跟上下文里的其他指令冲突。解决办法把格式要求放在提示词的最后AI 对末尾的指令更敏感用更强的措辞比如严禁输出任何解释性文字如果还是不行在输出后加一个后处理步骤自动提取代码块我一般会在适配层加一个简单的后处理如果输出包含 markdown 代码块就只提取代码块内容。这样即使 AI 多说了几句最终结果也是干净的。7.3 生成的测试跑不起来这是补测试命令的高频问题。原因通常有几类问题现象可能原因解决办法找不到模块路径别名没配置在测试配置里加 aliasmock 不生效mock 路径写错检查 mock 的路径是否跟实际导入一致断言失败预期值不对检查被测函数的实际行为超时有真实网络请求确保所有外部依赖都被 mock类型错误测试文件类型定义缺失安装对应的类型包我踩过最坑的一次是 mock 一个默认导出的模块AI 生成的 mock 写法不对跑了一直报错。后来在提示词里加了一条mock 默认导出时使用 vi.mock 的工厂函数形式就再没出过这个问题。7.4 上下文信息过多导致 AI 抓不住重点如果你把整个项目的文件都传给 AI它反而会迷失。我试过一次传了 20 个文件让它找逻辑结果它把每个文件都分析了一遍输出了一大堆无关内容。解决办法是分层过滤第一层用关键词搜索缩小范围从几百个文件缩到 10 个以内第二层按文件路径相关度排序优先选路径里包含关键词的文件第三层如果还是太多只传每个文件的前 50 行或者只传函数签名这样逐层过滤后传给 AI 的信息量控制在合理范围内它的分析就精准多了。7.5 不同项目之间配置冲突如果你同时在多个项目里用这套工作流可能会遇到配置冲突。比如 A 项目用 VitestB 项目用 Jest但全局配置里写死了 Vitest。我的做法是项目级配置优先。在每个项目根目录放一个.ai-workflow.yaml定义这个项目的特定配置。全局配置只放默认值项目配置会覆盖全局配置。# 项目级配置示例 project: type: react-ts test_framework: vitest style_solution: tailwind commit_convention: conventional这样切换项目时工作流会自动读取对应的配置不会串。实操心得建议把项目级配置加入版本控制这样团队成员共享同一套配置输出质量更一致。全局配置则因人而异不用共享。8. 扩展与定制打造你自己的命令集这套工作流包最大的价值不是那 10 个命令本身而是它提供了一套可扩展的框架。你可以根据自己的需求添加新的命令。添加一个新命令只需要三步第一步在命令注册表里加一条记录定义命令名称、提示词模板路径、需要的上下文类型。第二步写提示词模板。可以参考现有模板的结构替换成你的需求。第三步测试。先用几个实际场景跑一遍看输出质量。不满意就调模板直到稳定。我后来自己加了几个命令比如写文档为模块生成 README、查依赖分析某个依赖被哪些文件使用、优化性能针对性能瓶颈给出优化建议。每个命令的添加时间不超过 30 分钟。如果你用的是团队协作场景建议把命令集和配置一起纳入版本控制新人入职时直接拉下来就能用。我们团队现在新人的 AI 辅助开发上手时间从原来的一周缩短到两天主要就是靠这套标准化的命令集。最后分享一个我个人的使用习惯我每天早上开始工作前会先跑一遍画结构命令看看当前项目的模块关系有没有变化。这个习惯帮我及时发现了几次意外的循环依赖都是在合并分支后引入的。花两分钟跑一下比事后调试省事多了。