我最近把自己日常摸鱼用的几个 AI 编程流程，固化成了 10 个中文命令，全部装进了 Claude Code 里。这些命令不是花架子，而是把代码审阅、日志分析、单元测试补全、提交信息生成这些高频动作，封装成了一条条可以直接调用的工作流。这篇文章就把整套工作流包的设计思路、每个命令的实际写法、踩过的坑和最后落地的效果完整拆开，适合那些正在折腾 AI 编程助手、想把手头重复劳动交给工具的朋友。

标题里说“中文命令”，重点不在于把英文翻译成中文，而在于命令的触发词、输出风格、交互逻辑都贴合中文开发者的习惯。比如团队里同事写的注释是中文，要求代码规范描述也是中文，那 AI 审阅代码时，如果让它用中文输出问题清单，大家沟通成本会低很多。Claude Code 对命令的定义方式支持设置命令名和参数，我实测下来，中文命令名在/触发时完全没问题，直接在终端里敲/代码审阅就能唤起。

这套命令一共 10 个，分别是：代码审阅、提交信息生成、重构建议、日志分析、单元测试补全、接口调试、文档生成、依赖梳理、问题修复、项目状态巡检。下面逐个聊。

1. 整体工作流包设计：为什么需要一套“中文命令”

1.1 中文命令不是什么“炫技”，而是降低心智开销

先说个大实话：命令本身不会让 Claude 变聪明，真正起作用的是命令背后那套提示词和上下文管理策略。那为什么非要用中文命令名？我以前用英文命令名，不是不行，但有几个痛点。

第一是遗忘成本。日常用到的命令如果超过 10 个，英文名容易混。比如/code-review和/review-code，看着差不多，敲错就白搭。换成/代码审阅之后，每次调用之前脑子里不需要“中英文互译”这一步，直接敲中文，几乎没有记错的可能。

第二是团队协作。如果团队里有人不习惯英文交互，比如做后端的老同事，你跟他说“你敲一下 /commit-msg 生成提交信息”，他可能需要反应一下；但你说“敲 /提交信息”，他直接就能操作。实测下来，新人上手这套工作流包的时间从小时级降到了分钟级。

第三是输出风格的统一。命令触发后，Claude 会按照构建好的提示词输出结构化内容，比如代码审阅会固定输出“问题清单 + 严重级别 + 修改建议”的表格。用户平时对话可能口语化，但命令输出必须是严格的固定格式。中文命令名和中文输出格式搭配，整条链路风格统一。

1.2 命令筛选：不是所有任务都适合做成命令

把操作变成命令有个前提：这个操作要么是高频重复的，要么是流程固定的，要么是可以通过 AI 输出模板化的内容来减少人工整理时间的。我最初列了一份 25 个候选命令的清单，最后砍到 10 个，筛选标准就三条。

高频：这个动作一周至少会用三次以上。比如“生成提交信息”，每天提交代码必用，适合做成命令。

低思考成本：命令触发后，Claude 自动带上固定的上下文和规则，用户只需要给一个参数（比如“改动范围”），剩下的都交给命令本身。如果某个命令还需要用户长篇大论描述背景，那说明逻辑还没设计好。

输出可模板化：命令的输出要是结构化、可直接复用的。比如日志分析，输出必须包含“异常类型、报错行、可能原因、建议修复方案”几个字段；如果输出只是一段自然语言，不能直接粘贴到工单里，价值就少了半截。

按这三条标准筛下来的 10 个命令，基本覆盖了日常开发的四个阶段：读代码（代码审阅、项目状态巡检、依赖梳理）、写代码（重构建议、问题修复、单元测试补全）、交付（提交信息生成、文档生成、接口调试）、排障（日志分析）。

1.3 整体架构：命令层、规则层、上下文层

这套工作流包的结构其实很简单，分三层：

• 命令层：定义10个命令，每个命令有自己的触发词和参数说明。
• 规则层：存放在项目根目录下的CLAUDE.md规则文件里。这里存的是“全局约束”，比如代码风格偏好、禁止修改的文件范围、输出语言要求等。命令本身不需要重复写这些规则，因为 Claude Code 在每次会话中会先读取规则文件。
• 上下文层：命令的提示词里只写“本次动作要做什么”，具体代码结构、文件路径、项目背景都通过 Claude Code 的自己读文件能力实时获取。不把项目代码塞进命令里，命令保持轻量、通用。

这层设计的好处是：命令是通用的，规则是项目的。比如/代码审阅命令可以在任何项目里用，但不同项目里它读到的规则不同，输出建议会有差异 —— 项目 A 要求 TypeScript 严格模式，项目 B 要求兼容旧浏览器，规则文件不同，审阅侧重点自然不同。

2. 命令清单逐个拆解：每个命令怎么设计、怎么写

这 10 个命令，我从设计意图、触发形式、核心逻辑三个角度来拆。每个命令附一段简化版的写法示例，帮助大家理解命令背后到底做什么。

2.1/代码审阅：最常用的一个命令

核心逻辑很简单：让 Claude 先读取你指定的代码文件，然后按照规则文件里的代码规范做一次静态审阅。这个命令要做的，不是“重新检查一遍代码是否有语法错误”，而是关注“可读性、潜在 bug、边界处理、性能隐患、一致性”这几个维度。

/code review 请审阅文件: $FILE

实际的命令里我会指定一个参数$FILE，用户可以传单文件，也可以传一个目录。命令的核心不是让 AI 泛泛而谈，而是要求输出格式固定：

• 问题清单（按严重级别排序：阻断 / 重要 / 建议）
• 每个问题关联的代码引用（行号 + 代码片段）
• 建议修复方案
• 风险最高的 3 个点

为什么这样设计？因为审阅完代码，最终还是要人来修改。如果 AI 只是说“这个函数太长了，建议拆分”，没有给出具体行号，开发者还得自己翻代码，并没有节省时间。强制固定输出格式之后，拿到结果可以直接对照处理，工作效率提升明显。

2.2/提交信息：给 Git 提交写规范信息

这个命令服务的是“规范提交”，让每次提交信息符合团队约定，比如<type>(<scope>): <subject>格式。以往我写提交信息总是随手敲一句“修复了 bug”，过一个月自己都看不懂。现在用命令触发后，它会自动对比暂存区的改动内容，生成符合规范的提交信息。

/commit 生成提交信息，类型遵循 conventional-changelog 规范

命令里不用传任何参数。Claude Code 会自己执行git diff查看暂存区改动，然后自动生成信息。生成完我可以复制或直接采用，支持中文和英文两种输出。实测下来，生成的信息在语义粒度上比我自己写的更准确，因为它会根据改动内容自动判断是feat还是fix还是refactor。

补充一点：使用这个命令的前提是git add已经执行，否则它看不到改动内容。我一开始经常忘记先暂存，后来干脆把提示词里加了“如果暂存区无改动，则提示用户先执行 git add”。

2.3/重构建议：在动大刀之前先问 AI 一声

重构风险高，容易把好端端的代码改崩。这个命令的工作方式是：先把目标代码读进来，分析结构、圈复杂度、潜在扩展点，然后输出一份“重构方案”。方案里包含：当前架构的劣势分析、推荐的目标结构、分几步走、每一步的验证方式。

实际产出是一张表格：

为什么单独做一个命令而不是直接对话？因为直接对话时总会忘掉一些维度。命令规定必须先分析“圈复杂度”，必须先评估“改动影响面”，这样不会漏项。

2.4/日志分析：异常排查时最快的入口

很多项目日志格式不统一，服务一多，日志文件混在一起。这个命令的价值在于：把“人肉翻日志、找异常关键字、猜原因”的过程交给 AI。

/日志分析 日志文件: $LOG_PATH 时间范围: $TIME_RANGE

命令内置了解析逻辑：先按时间线排序，过滤掉无意义的心跳日志，识别错误级别日志之间的关联关系，最后输出“异常事件 + 关联日志 + 可能原因 + 排查建议”。有一个很实用的细节：它会在分析前先统计日志级别的分布，如果某个时间段 ERROR 比例突然飙升，它会刻意标注出拐点。

我踩过的坑是：日志文件太大时，直接把整个文件灌给 Claude 会超过上下文窗口，处理速度也很慢。现在的做法是命令里内置一条“先做采样，优先抽取 ERROR、WARN 级别以及时间相邻的上下文日志”，避免上下文爆炸。

2.5/单测补全：把测试覆盖率补上

编写单元测试是个精细活，也是很多人拖延的重灾区。这个命令的目标不是 AI 顺手把所有测试都写了，而是“参照已有测试风格，补全缺失场景”。命令会先读取被测文件、已有测试文件、覆盖率报告，然后找出没覆盖的分支，生成补充测试用例。

如果有覆盖率报告，命令会读报告；如果没有，会让 Claude 自己分析代码分支。它的输出是完整的测试代码块，可直接粘贴到测试文件里。命令里会设置一条偏执的规则：“生成的测试用例至少包含正常输入、边界输入、异常输入三类。”

注意一个细节：AI 生成的单测，不能无脑相信。有一个常见问题：为了通过覆盖率检测，AI 会生成一些看似覆盖了分支、但实际只是空转的测试用例。所以命令的提示词里专门有一条：“不允许为了覆盖率而生成无断言的测试。”加上这一条之后，测试质量明显提升。

2.6/接口调试：快速生成请求示例、定位联调问题

处理接口联调问题时，最烦的是翻文档找参数名、构造请求体、确认鉴权方式。这个命令会读取接口定义文件（OpenAPI / Swagger / 后端路由代码），然后按用户指定的场景生成请求示例，或者对返回结果做疑难点分析。

触发方式如：

/接口调试 接口路径: /user/info 场景: 查询用户详情

输出包含：请求方法、请求头、请求体示例、鉴权方式说明、可能遇到的错误码及含义。这个命令对于前后端联调很有用，尤其是后端接口文档更新不及时的时候，直接从代码里读取路由定义，省得来回问人要文档。

2.7/文档生成：把散落的注释变成可用文档

文档任务在工程里往往优先级很低，但一旦接手维护旧项目，没有文档就会被坑惨。这个命令会根据代码里的注释、函数签名和模块导出，生成一份结构清晰的文档草稿。

它生成的内容包括：模块概览、函数签名、参数说明、返回值、使用示例、注意事项。命令会要求“先读取项目已有文档的写作风格，再按同样风格生成”，避免产出的文档和团队已有的风格不统一。

2.8/依赖梳理：搞清楚项目依赖之间的关系

依赖关系混乱是旧项目的常见问题。package.json里几十个依赖，哪些是直接依赖、哪些是间接依赖、哪些版本冲突，人肉排查很痛苦。这个命令会读取依赖清单并分析目录结构，输出一张依赖关系表和潜在风险点。

输出格式为：

| 依赖名 | 当前版本 | 最新版本 | 直引/间接 | 风险说明 | 建议操作 |

生成的建议可以包括“升级到某个版本后需要回归验证哪些模块”，这个信息对排期很有价值。

2.9/问题修复：拿到报错直接修

严格来说这不是一个自动修改器，而是一个“诊断工具”。它接收报错信息或异常堆栈，再结合相关代码上下文，输出“根因分析 + 修复建议 + 修改后的代码”。

与/代码审阅的区别是：代码审阅面对的是整个文件尽量发现潜在问题，问题修复是拿着明确报错去定位根因。命令会要求 Claude 先解释报错产生的链路，再动手改代码，避免“只改了表面症状、没有消除根因”。

每次使用这个命令，我都会让它先输出“根因是否确认”这个字段。如果它没有足够信息确认根因，它会要求补信息，而不是强行给修复方案。这个约束很关键，防止 AI 在一知半解时瞎改代码。

2.10/状态巡检：摸清项目全貌的第一站

接手新项目（或者刚打开一个几周没碰的旧项目）时，内心最迷茫的是“这项目现在什么状态”。项目状态巡检这个命令，就是把项目关键信息一次性拉出来：

• 框架、语言版本、构建工具
• 目录结构概览
• 技术栈亮点与风险点（比如依赖了过时库）
• 全部 TODO / FIXME 位置摘录
• 当前分支状态、未提交改动数量

实际体验下来，这个命令是“开局”命令。每次开始干活前跑一次，比盯着 README 发愁强。它会自动跳到 README、配置文件、入口文件等关键位置读信息，不用用户一点点翻。

3. 工作流包的实现与落地：怎么把命令变成可复用的工具

3.1 命令目录结构与配置方法

Claude Code 的命令目录配置，本质上就是把每个命令写成一个带有函数式声明的配置文件。我实际用的目录结构大概是这样：

.claude/ ├── commands/ │ ├── 代码审阅.md │ ├── 提交信息.md │ ├── 重构建议.md │ ├── 日志分析.md │ ├── 单测补全.md │ ├── 接口调试.md │ ├── 文档生成.md │ ├── 依赖梳理.md │ ├── 问题修复.md │ └── 状态巡检.md └── CLAUDE.md

每个.md文件就是一个命令定义。文件开头写了触发命令名、参数说明、简短描述，后面跟着命令真正执行的提示词。

以/提交信息为例，配置文件核心结构如下：

--- name: 提交信息 description: 对比 git 暂存区改动，按规范生成提交信息 参数: 无 --- 按 Conventions 生成一条 git commit message。 先执行 `git diff --cached` 查看暂存区改动，分析改动文件和内容。 要求： 1. 提交信息格式 `<type>(<scope>): <subject>` 2. 如果包含破坏性变更，在正文中说明 BREAKING CHANGE 3. 简要描述为什么做这个改动，而不是仅描述改了什么 4. 主体内容使用中文，type 使用英文标准词汇 5. 最多提供 3 条候选信息，并给出简短的选择理由

CLAUDE.md文件放的是项目级偏好，比如这个团队的风格规范、禁止触碰的文件、测试要求。每个命令在执行过程中会自动感知这个文件里的规则。

3.2 参数设计：怎么让命令“好用、不容易用错”

参数设计是一门分寸感很强的学问。参数太少，命令灵活度不够；参数太多，使用门槛升高。我录过 10 个命令里，有 7 个不需要任何参数，剩下 3 个最多 2 个参数。

为什么偏好在“少参数”方向？因为命令区别于脚本的本质在于：它应该有“智能默认值”。比如/日志分析，如果不传时间范围，就默认分析最近一小时的日志；如果传时间范围，就按传的来。Claude Code 在解析命令时能理解自然语言参数，你可以说“最近 2 小时”，也可以说“2025-12-01 当天”。对 AI 来说这没有区别，但对人来说，输入的自然语言比你记忆一套标志位语法要好得多。

参数尽量用$变量表示，并在命令描述里写清楚参数格式：

--- name: 代码审阅 description: 审阅指定文件的代码质量 参数: $FILE 目标文件或目录 ---

此外我强烈建议每个命令的描述里带上“使用前提”，比如“/日志分析 需要在项目目录下执行”“/提交信息 需要先 git add”。这些描述会展示在命令列表里，能显著减少用错的概率。

3.3 规则文件：命令效果差异最大的因素

很多人的命令效果不稳定，最根本的原因是全局规则文件写得太粗糙。CLAUDE.md里我放了以下六块内容：

• 项目语言和框架基础信息（只有 Claude 知道项目用 Vue 还是 React、用 Python 还是 Java，才能给对建议）
• 代码风格偏好（分号要不要、缩进两个还是四个、组件命名用 PascalCase 还是 kebab-case）
• 禁止自动修改的文件清单（比如 lock 文件、dist 目录、自动生成的 SDK 代码，AI 看不懂这些文件千万别动）
• 测试约定（测试文件放哪、命令怎么跑）
• 文档语言（默认输出中文，除非用户明确要求英文）
• 常见坑（比如某些第三方库的已知问题，AI 检查代码时遇到相关模式要特别关注）

举一个具体例子。某次在一个发版前的仓库里跑/代码审阅，Claude 一直报错说某个第三方依赖的代码有问题。但实际上那是构建工具自动生成的、不能手改的文件。后来我在规则里加了“/src/libs/目录下所有文件为自动生成文件，发现问题时标记为‘不可修改，需上游修复’”，这个问题就消失了。规则文件不是摆设，它是命令效果的放大器。

3.4 配置进团队仓库和个人全局配置的区别

这套命令包有两个层级：个人全局配置和项目级配置。个人全局配置适合那些与项目无关的通用命令，比如“提交信息”“文档生成”。项目级配置适合绑定当前项目上下文的内容，比如“数据库表结构”“目录风格”。

我实际使用时分得很清楚：与业务强相关的内容（API 路由、数据模型）放项目级CLAUDE.md；通用 AI 交互偏好、通用命令定义放个人配置。原因是项目级配置要跟着仓库走，方便团队成员共享。通用命令挪到个人配置后，无论在哪个项目里都能唤起，不用每个仓库粘一份。

3.5 版本管理与团队分享

命令包本身也是一个代码库，值得用 Git 管理。我会把命令包单独建一个配置仓库（.dotfiles 仓库管理模式），改完命令后提交一条feat: 增加接口调试命令。团队其他成员可以直接 pull 下来放入自己的配置目录；如果项目需要，也可以把这套命令目录拷贝到项目根目录的.claude/下，分享给参与这个项目的所有人。

一份配置能不能在团队推广，很大程度取决于“命令文档是否清晰”。我给每个命令都写了使用说明，包括：

• 这个命令解决什么问题
• 在什么场景下用
• 执行的先后顺序是什么（比如先 /状态巡检 再 /代码审阅）
• 常见误用方式

命令文档写在每个命令的description字段和配套 README 里。好的命令包，应该让队友拿到手之后不用再问你“这个命令怎么用来着”。

4. 真实场景中的完整工作流串联：从接手项目到提交上线

光有命令清单还不够，真正顺手的是把它们按场景串成工作流。我拿最近处理的一个遗留系统为例，完整走一遍这套流程。

4.1 开局：项目状态巡检

活还没开始干，先跑/状态巡检。输出里能看到这个项目是一个内部的报表系统，后端用了 Python 加一个老版本 ORM，前端是 Vue 2。依赖里有几个已停止维护的包。目录结构里有一个scripts/report_generate.py看起来像是核心模块，还有 47 个 TODO 待办。分支上挂着十几处未提交改动，看起来是上一个同事改到一半的状态。

看完成巡检结果，我对项目的“健康状况”就有底了。这种一眼扫过去完全摸不着北的旧项目，先巡检再动手，能少走很多弯路。

4.2 动手改需求前：先看代码再重构

这次需求是“报表导出增加 CSV 格式”。我先用/代码审阅 scripts/report_generate.py过一遍核心文件。审阅结果指出两个问题：一是数据量大的时候内存占用会翻倍，因为没有用生成器逐个写入；二是异常处理覆盖不足，数据库查询出错时会直接抛给前端。

对于我这种刚接触这个项目的人来说，这种及时的提醒非常关键，不用等代码跑到线上出问题才后悔。看完审阅结果，我继续用/重构建议设计“如何接入 CSV 导出且不影响现有 Excel 导出逻辑”。重构建议给出的方案是：抽象一个ReportExporter基类，分别实现 Excel 和 CSV 两个子类，调用处按格式参数切换。按这个结构改完后，改动面最小，风险也可控。

4.3 写完代码后：单测补全、接口调试、文档生成

功能写完，跑一遍/单测补全。它读了report_generate.py的现有测试文件，识别到测试覆盖了 Excel 导出路径，但 CSV 导出路径完全没测。于是生成了 CSV 导出的测试用例，包含正常数据导出、空数据导出、字段映射缺失三种场景。我补充提交后，覆盖率从 61% 提升到 78%。

这个项目前端调接口的方式我不熟。直接用/接口调试 接口路径: /api/report/export 场景: 导出CSV，它会自动读取路由定义，把请求方法、参数、返回结构列出来。前后端联调时，省去了抱着接口文档反复翻找的流程。

文档目前基本空白。跑完/文档生成，它按照代码里的注释生成了report_generate.py的模块文档，包括导出流程、参数说明、异常类型汇总。一并提交到仓库里，后面的同事接手就轻松多了。

4.4 提交与排障：提交信息、日志分析、问题修复

功能联调完毕，执行git add后调用/提交信息，生成的候选信息：

feat(report): 增加 CSV 导出支持 - 抽象 ReportExporter 基类，新增 CsvExporter 实现 - 调整导出接口以支持 format 参数 - 补充 CSV 导出路径的单元测试

我选了这版，理由很充分：它概括了重构背景，也说明了技术方案，后续回溯 git history 时能知道这次改动背后的意图。

上线后监控发现一个报错。我导出日志跑/日志分析，它识别到 CSV 导出接口在空数据时抛出的类型错误，定位到是因为fields为空时 CSV 表头构造逻辑走了错误分支。拿到这个定位结果，直接用/问题修复提供修复方案：将表头构造逻辑提前判空，空数据时直接返回空文件。修复后重新跑单测，全部通过。

4.5 工作流串联的总结感言

这一整条链路，从接手项目到交付功能，以前我至少要折腾一整天；这套命令包稳定情况下一个上午就能完成。不是每次命令输出都完美，但可以快速确定“哪一步有问题”，而不是反复手工操作去猜。

版本规划上也更清晰。用完了测试、审阅、生成文档、生成提交信息，再回看git log，这条线比以往规整太多。

5. 常见问题与排查技巧：命令包用着用着出问题怎么办

任何工具用久了都会遇到问题。命令包也一样。我把自己用这 10 个命令过程中遇到的典型问题和排查思路整理成速查表。

5.1 命令没有按预期执行

如果某个命令完全不触发，或触发了但行为不对，首先检查命令配置文件名与name字段是否一致。命令名里不要有空格（可以用中文，但不要用“代码 审阅”这种带空格的写法），也不要包含会被解析出歧义的符号。

然后检查工作目录是否正确。很多命令内部会调动git、读取文件，如果当前目录不是项目根目录（而是子目录），相对路径就可能会出问题。一个快速验证方法是：在项目根目录下重新执行。

5.2 上下文太长，响应变慢且效果下降

命令本身加上项目文件内容，叠加起来容易超过模型上下文窗口或可用冗余。我遇到最多的是/日志分析和/代码审阅。

解决思路是“先缩小再分析”。在命令配置里强制增加一步：“先读取文件大小；如果超过阈值，优先提取代码中的关键函数/关键目录作为分析对象，避免一次性读入整个大文件。”或者在日志分析场景，先按时间过滤、按日志级别过滤，再判断是否读入。

5.3 中文输出格式混乱

命令要求输出成表格，但 AI 偶尔会输出成一大段文字。这种情况基本是因为用户在原场景中追加的其他指令干扰了命令的说明。有一个相对稳定的小技巧：在命令提示词里把“必须输出表格”这样的要求重复两遍，并明确“不要在其他解释性文字中夹杂表格数据”。在关键位置强调一遍，输出稳定性会明显变好。

5.4 命令被“串场”污染

这是比较隐蔽的问题。一个命令执行完之后，后续继续对话，新命令会“沿用”前面的语义。比如先跑了/提交信息，再跑/日志分析，AI 可能误将日志内容视为“最近的代码提交内容”。

解决方法是命令文件里开头加一句“忽略与本次命令无关的对话上下文”。这样能有效阻断串场。另外，建议在执行下一个命令前按 Esc 或清理一下会话上下文。

5.5 生成的代码不可靠，甚至直接编译失败

AI 生成的代码偶尔引用不存在的 API 或写错变量名，这无法完全避免。我的处理经验是：要求命令输出后自动执行“自检”。

所谓自检，就是让 Claude 检查自己生成的代码：先看引用的函数和变量是否在上下文中定义，再看语法是否完整，最后对照导入表的模块名。这一步放在输出的最后，能在很大程度上减少低级错误。测试类和接口调试这类命令的效果会稳很多。

5.6 不同项目之间命令行为不一致

如果同一命令在不同项目里效果差异巨大，十有八九是规则文件差异导致的。项目 A 的CLAUDE.md里写了“工程文件在 src 目录下，自动生成的代码不要动”，项目 B 没有这些规则，AI 自然只能根据默认经验来响应。

建议每个项目都在根目录放一个CLAUDE.md，把项目独有的上下文写清楚。哪怕只写三行，也比没有强。

6. 一些踩坑后的心得：怎么把命令包做得更好用

6.1 命令要“小步快跑”，不要追求一步到位

一开始我设计命令时，总想把所有规则一次性塞进一句话里。结果效果反而不好。比如/代码审阅最初要求“同时检查代码质量、性能、安全、可维护性、设计模式，并生成重构建议”。输出内容太多，反而没有重点，几乎不能用。

后来我把所有命令的输出都强制收敛成“最多三个重点”：最严重的问题必须先列出来，其余问题用一句话汇总。这样做之后，输出质量明显提升，人也更容易消化结果。

6.2 把“不要做什么”写进命令里

提示词里如果少于 10% 是“不要做什么”，命令大概率会在某些边界上跑偏。

给几个实际例子：

• “不要在回答中修改用户的代码，如果修改则给出完整 diff。”
• “不要将自动生成的文件列为问题，除非是改造方案。”
• “不要假设测试环境已经配置了数据库连接，需要在建议中给出 mock 方案。”
• “不要使用超出项目 dependencies 的库，除非给出理由且用户确认过。”

增加了一层“否定约束”，让命令的安全边界变得清晰。AI 不容易“自由发挥”。

6.3 测试命令本身：迭代命令包也需要回归

每次修改命令的提示词，最好都用同一份样例数据回归一遍。我给 10 个命令各准备了一个测试样例文件，放在配置仓库里。修改某个命令后，对照样例重新跑一次，看输出格式是否规范、关键要求是否被遵守。这样做能有效防止改坏原有功能。

6.4 不要过度自动化

这一点可能有些反直觉，但我真心提醒：不是所有事情都适合交给 AI 自动执行。比如自动重构代码、自动批量调整文件，只要命令一开，改动范围很难预期，风险极大。我的所有命令默认都是“生成建议供用户确认”，只有用户明确说“执行”之后，AI 才会动手修改文件。我宁可人肉确认一遍，也不半夜被线上事故吵醒。

7. 后续可以怎么扩展这套工作流包

这套命令包目前运行得比较顺手，我还在持续扩展。目前已经在尝试的方向有两个。

一个是结合 CI 流程。计划把/代码审阅和/单测补全的执行结果以评论形式回写到 Pull Request 上。这样不只本地开发时用命令，团队在 code review 环节也能借助 AI 覆盖常见问题。

另一个是给不同技术栈定制预置命令。现在命令包是通用版，在不同框架下细节有差异。考虑按“前端 Vue 项目命令包”“Python 服务命令包”“Java 后端命令包”拆分不同版本，配合对应的规则文件，开箱即用性会更好。

如果这篇文章看下来的读者也想自己搭一套，我的建议是：不要照搬我的 10 个命令，先拿一周时间记录自己日常操作哪些动作重复度最高，挑出 3 个做成命令，用熟了再逐步扩充。命令包的价值不在于数量，而在于每个命令都能真正帮你省下时间。我自己试错了两三轮才找到合适的结构，你如果在折腾过程中碰到奇怪问题，大概率是规则文件和参数设计的问题，对照前面第 5 节逐条排查一下，基本都能解决。

我个人用下来的最大感受，就是“中文命令”这一层设计，让这套东西在团队里的接受度变得异常高。如果你也想快速验证自己的 AI 编程工作流，不妨从第一个命令开始，挑一个你每天都要重复做的动作，花十分钟做成命令，很快就能尝到甜头。