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 + Prettier，2 空格缩进，单引号 路径别名：@/ 映射到 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 和 role，token 无效时抛出错误"提示词模板：
[项目上下文] ... 请实现以下函数： 需求：{{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 "把主按钮的背景色改成品牌蓝 #1890ff，hover 时加深 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 生成的测试跑不起来
这是补测试命令的高频问题。原因通常有几类：
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 找不到模块 | 路径别名没配置 | 在测试配置里加 alias |
| mock 不生效 | mock 路径写错 | 检查 mock 的路径是否跟实际导入一致 |
| 断言失败 | 预期值不对 | 检查被测函数的实际行为 |
| 超时 | 有真实网络请求 | 确保所有外部依赖都被 mock |
| 类型错误 | 测试文件类型定义缺失 | 安装对应的类型包 |
我踩过最坑的一次是 mock 一个默认导出的模块，AI 生成的 mock 写法不对，跑了一直报错。后来在提示词里加了一条"mock 默认导出时使用 vi.mock 的工厂函数形式"，就再没出过这个问题。
7.4 上下文信息过多导致 AI 抓不住重点
如果你把整个项目的文件都传给 AI，它反而会迷失。我试过一次传了 20 个文件让它找逻辑，结果它把每个文件都分析了一遍，输出了一大堆无关内容。
解决办法是分层过滤：
- 第一层：用关键词搜索缩小范围，从几百个文件缩到 10 个以内
- 第二层：按文件路径相关度排序，优先选路径里包含关键词的文件
- 第三层：如果还是太多，只传每个文件的前 50 行，或者只传函数签名
这样逐层过滤后，传给 AI 的信息量控制在合理范围内，它的分析就精准多了。
7.5 不同项目之间配置冲突
如果你同时在多个项目里用这套工作流，可能会遇到配置冲突。比如 A 项目用 Vitest，B 项目用 Jest，但全局配置里写死了 Vitest。
我的做法是项目级配置优先。在每个项目根目录放一个.ai-workflow.yaml，定义这个项目的特定配置。全局配置只放默认值，项目配置会覆盖全局配置。
# 项目级配置示例 project: type: react-ts test_framework: vitest style_solution: tailwind commit_convention: conventional这样切换项目时，工作流会自动读取对应的配置，不会串。
实操心得：建议把项目级配置加入版本控制，这样团队成员共享同一套配置，输出质量更一致。全局配置则因人而异，不用共享。
8. 扩展与定制：打造你自己的命令集
这套工作流包最大的价值不是那 10 个命令本身，而是它提供了一套可扩展的框架。你可以根据自己的需求，添加新的命令。
添加一个新命令只需要三步：
第一步，在命令注册表里加一条记录，定义命令名称、提示词模板路径、需要的上下文类型。
第二步，写提示词模板。可以参考现有模板的结构，替换成你的需求。
第三步，测试。先用几个实际场景跑一遍，看输出质量。不满意就调模板，直到稳定。
我后来自己加了几个命令，比如写文档（为模块生成 README）、查依赖（分析某个依赖被哪些文件使用）、优化性能（针对性能瓶颈给出优化建议）。每个命令的添加时间不超过 30 分钟。
如果你用的是团队协作场景，建议把命令集和配置一起纳入版本控制，新人入职时直接拉下来就能用。我们团队现在新人的 AI 辅助开发上手时间从原来的一周缩短到两天，主要就是靠这套标准化的命令集。
最后分享一个我个人的使用习惯：我每天早上开始工作前，会先跑一遍画结构命令，看看当前项目的模块关系有没有变化。这个习惯帮我及时发现了几次意外的循环依赖，都是在合并分支后引入的。花两分钟跑一下，比事后调试省事多了。
