1. 为什么我要给 AI 编程助手做一套中文命令包

用 AI 编程助手写代码这件事，我从它刚能补全函数的时候就开始了。一路用下来，最大的感受不是模型不够聪明，而是沟通成本高得离谱。你脑子里想的是"帮我把这个模块的边界条件补全，顺便把异常处理统一一下"，手上敲出来的却是一段又长又啰嗦的提示词，等它回你一大段代码，你还得逐行核对它有没有理解偏。来来回回几次，写代码的节奏全被打断了。

后来我注意到一个现象：这些 AI 编程工具其实都支持一种叫"自定义命令"或者"斜杠命令"的机制。你可以把一段固定的、反复要用的提示词，封装成一个短命令，比如输入/review就自动触发一套代码审查流程。这个机制本来是给英文用户设计的，命令名、参数说明、触发词全是英文。但问题是，我日常思考用的是中文，我描述需求、判断代码好坏、跟同事讨论方案，脑子里跑的都是中文。每次还要先把中文需求"翻译"成英文提示词，再喂给工具，这个中间层特别消耗精力。

于是我就想，能不能干脆做一套纯中文的命令包，把我在日常开发里最高频的十来个操作，全部封装成中文命令。比如/补全、/审查、/重构、/写测试、/解释、/优化、/查错、/文档、/提交、/拆解。这样我只要敲两个中文字，AI 就知道我要干什么，而且提示词里已经内置了我多年积累的"怎么问才问得准"的经验。

这套东西做出来之后，我的开发流确实变了。以前是"想需求 → 组织英文提示词 → 等结果 → 反复调整"，现在是"想需求 → 敲中文命令 → 拿结果"。中间那层翻译和措辞的负担被彻底拿掉了。这篇文章我就把这套中文命令包的设计思路、每个命令背后的提示词工程、以及实际用下来踩过的坑，完整地拆给你看。不管你是刚接触 AI 编程的新手，还是已经用了一阵子但觉得效率卡在瓶颈的老手，这套思路都能直接抄去改。

2. 中文命令包的整体设计与选型考量

2.1 为什么是"命令包"而不是"提示词模板"

很多人做 AI 编程提效，第一反应是搞一个提示词模板文档，用的时候复制粘贴。我一开始也这么干，但很快就放弃了。原因有三个。

第一，复制粘贴有摩擦。你正在编辑器里写代码，手不离键盘，这时候要去另一个文档里找模板、选中、复制、切回来、粘贴、再改参数，这一套动作下来至少十几秒，而且打断了心流。命令包是直接在对话框里敲两个字符就能触发的，摩擦几乎为零。

第二，模板容易过期。你把提示词存在文档里，改了一版又一版，最后自己都分不清哪个是最新的。命令包是文件形式存在的，每个命令一个文件，改完即生效，版本清晰。

第三，模板没法带参数。好的提示词往往需要根据上下文变化，比如"审查这段代码，重点看并发安全"。命令包支持参数传递，你可以/审查 并发安全，把关注点作为参数传进去，提示词会自动拼接。模板做不到这一点，你只能手动改。

所以选"命令包"这个形态，本质上是为了降低触发成本和支持参数化。这两点决定了它能不能真正融入日常流，而不是变成一个"偶尔想起来才用"的摆设。

2.2 十个命令是怎么选出来的

我没有一上来就设计十个命令，而是先观察了自己两周的开发行为，把"我反复让 AI 做的事"列了个清单，然后按频率排序，取前十个。这个清单大概是这样的：

这十个命令覆盖了从"读代码"到"写代码"到"改代码"到"交付代码"的完整链路。你会发现它们不是随便凑的，而是沿着一条真实的开发流水线排布的。早上来先/解释一段昨天没看懂的代码，然后/补全新功能，写完/审查一遍，/写测试补覆盖，/重构清理结构，/优化处理性能瓶颈，/文档补注释，最后/提交生成规范的提交信息。如果任务太大，先用/拆解分步。这条链路走下来，基本就是一个完整的开发循环。

2.3 命令命名为什么用中文而不是拼音或英文缩写

这一点我想重点说一下，因为很多人会纠结。我的结论很明确：用中文，不要用拼音，也不要用英文缩写。

用拼音的问题是，/buchong和/chonggou这种，你敲的时候要在脑子里做一次"中文→拼音"的转换，而且拼音没有语义，看命令列表的时候反应慢。用英文缩写的问题是，/exp、/ref、/opt这种，你得记住每个缩写对应什么，学习成本高，而且容易和工具自带的英文命令混淆。

用中文的好处是零转换成本。你脑子里想"补全"，手上就敲/补全，中间没有任何映射。而且中文命令自带语义，你打开命令列表扫一眼就知道每个是干嘛的，不需要记忆。实测下来，中文命令的肌肉记忆形成速度比英文快得多，大概用两三天就能盲敲了。

提示：如果你的工具对中文命令名支持不好（比如某些版本对非 ASCII 字符处理有 bug），可以退而求其次用"中文拼音首字母"，比如/bc（补全）、/sc（审查）。但优先还是试中文，大部分现代工具都没问题。

2.4 提示词工程的核心原则

命令包的外壳是命令名，内核是提示词。这十个命令的提示词，我反复打磨了很多轮，总结出四条原则，后面每个命令都会体现。

原则一：角色前置。每个提示词开头都明确 AI 要扮演什么角色。/审查开头是"你是一位严格的代码审查者"，/重构开头是"你是一位注重可读性的重构专家"。角色决定了 AI 的输出风格和关注点，不写角色，AI 就会用那种四平八稳的通用口吻，出来的东西没针对性。

原则二：约束输出格式。不约束格式，AI 就会写一大段散文，你还得自己从里面挑重点。我在每个命令里都规定了输出结构，比如/审查要求按"严重问题 / 建议改进 / 可选优化"三档分类，/写测试要求先列测试用例清单再写代码。格式约束让输出可以直接用，不用二次加工。

原则三：内置领域经验。这是最值钱的部分。比如/审查里我内置了"重点检查空指针、边界条件、并发安全、资源泄漏、错误处理"这几个我踩过坑的点。AI 拿到这个清单，就会逐项检查，而不是泛泛地说"代码看起来不错"。这些经验是命令包的灵魂，也是它比通用提示词强的地方。

原则四：留参数口子。每个命令都支持一个可选参数，用来传递本次的特殊关注点。/审查 并发安全会让 AI 重点看并发，/优化 内存会让 AI 聚焦内存优化。参数让固定命令有了灵活性。

3. 十个中文命令的逐个拆解与实操要点

3.1 /解释：把看不懂的代码讲成人话

/解释是我用得最多的命令，没有之一。接手老项目、看开源库、读同事写的复杂逻辑，全靠它。

提示词的核心结构是这样的：先让 AI 判断这段代码的整体意图，再逐段拆解关键逻辑，最后指出"这段代码里最容易被误解的地方"。第三步是我特意加的，因为很多时候代码本身不难，难的是它为什么这么写。比如一段看起来多余的判空，背后可能是某个历史 bug 的规避。让 AI 主动指出这些"反直觉点"，能帮你快速建立对代码的信任感。

实操的时候有个技巧：不要一次贴几百行。AI 的注意力是有限的，代码太长它会抓不住重点。我的做法是按函数或按逻辑块贴，一次控制在 50 行以内。如果确实要看一个大文件，先用/拆解让它把文件结构理出来，再逐个函数/解释。

注意：/解释的输出里，AI 有时会"脑补"一些代码里没有的意图。看到它说"这里是为了处理 XX 情况"的时候，如果代码里没有对应的注释或测试，最好自己再确认一下。AI 的解释是帮你理解，不是替你判断。

3.2 /补全：从注释或签名生成实现

/补全的用法是：你写好函数签名和一段描述性注释，然后敲/补全，AI 根据签名和注释生成实现。

这个命令的提示词里，我强制要求 AI 做三件事：第一，先复述一遍它理解的函数职责，确认没跑偏；第二，生成实现；第三，列出它做的假设。第三步特别重要。比如你写了个parseConfig(path)，AI 可能会假设"文件不存在时抛异常"，也可能假设"返回空配置"。这两种假设对应完全不同的调用方处理逻辑。让它把假设列出来，你一眼就能看出它有没有理解错。

实操心得：注释写得越具体，补全质量越高。不要写"解析配置"，要写"读取指定路径的配置文件，支持 JSON 和 YAML 两种格式，文件不存在时返回空配置对象，格式错误时抛出带行号的异常"。你给的信息越足，AI 猜的空间越小，出来的代码越接近你要的。

3.3 /审查：像资深工程师一样挑刺

/审查是我认为最能体现"命令包价值"的一个。因为代码审查这件事，新手和老手的差距不在"能不能看出问题"，而在"知道该看哪些地方"。老手脑子里有一张检查清单，新手没有。/审查就是把这张清单固化下来。

我的提示词里内置的检查清单包括：空值和边界条件、并发与竞态、资源释放（文件句柄、连接、锁）、错误处理是否吞异常、输入校验、日志是否泄露敏感信息、命名是否误导、是否有重复逻辑可以抽取。AI 会按这个清单逐项过，输出分三档：严重问题（必须改，可能导致 bug 或安全问题）、建议改进（改了更好，不改也能跑）、可选优化（风格层面）。

这里有个反直觉的经验：不要让 AI 一次审查太多代码。我试过贴一个 300 行的文件让它审，结果它只挑了表面问题，深层的逻辑漏洞全漏了。后来我改成按函数审，每个函数单独/审查，问题检出率明显提升。原因是 AI 的"审查注意力"也是有限的，代码越长，它越倾向于走马观花。

3.4 /写测试：先列用例再写代码

/写测试的提示词结构是：先分析被测函数的输入空间和边界，列出测试用例清单（正常路径、边界值、异常路径、并发场景），然后逐个用例写测试代码。

为什么先列清单？因为测试的质量取决于用例设计，而不是代码写法。很多人让 AI 写测试，AI 直接给一堆assert，看着挺多，但全是正常路径，边界和异常一个没覆盖。先让它列清单，你就能看出它有没有想到边界情况。如果清单不全，你可以补充"还要测空输入和超大输入"，再让它写代码。

实操技巧：写完之后，让 AI 自己跑一遍"变异测试"的思路——"如果我把被测函数里的某个条件反过来，你的哪个测试会失败？"如果它答不上来，说明那个条件没被覆盖到。这个方法能快速找出测试的盲区。

3.5 /重构：在保持行为不变的前提下改善结构

/重构的提示词里，我加了一条硬约束：重构后的代码必须保持外部行为完全不变。AI 会先说明它打算怎么改（提取函数、消除重复、简化条件、替换魔法数字等），改完之后列出"行为不变性说明"，逐条解释为什么改完还是原来的行为。

这条约束很关键。不加的话，AI 经常借着"重构"的名义偷偷改逻辑，比如把>=改成>，把异常改成返回默认值。这些改动在重构里是绝对不允许的，因为它们改变了行为。有了"行为不变性说明"，你就能快速核对它有没有越界。

提示：重构前一定要有测试覆盖。没有测试的重构就是赌博。如果这段代码没测试，先/写测试补上，再/重构。这个顺序不能反。

3.6 /查错：从报错信息反推根因

/查错的输入是报错信息加相关代码。提示词要求 AI 做四步：第一，翻译报错信息的字面含义；第二，列出可能导致这个报错的三种原因，按可能性排序；第三，针对最可能的原因给出验证方法；第四，给出修复方案。

第三步"验证方法"是精髓。很多人拿到报错，直接让 AI 给修复代码，结果改了半天发现根因在别处。让 AI 先给验证方法，你花一分钟验证一下，确认根因再改，能省下大量瞎改的时间。比如它说"最可能是空指针，你在这行加个打印看看对象是不是 null"，你验证一下，是就改，不是就换下一个原因。

3.7 /优化：先测量再优化

/优化的提示词里，我强制要求 AI 先问一句"你测量过瓶颈在哪里吗"。如果我没提供性能数据，它会拒绝直接优化，而是建议我先加埋点测量。这个设计是刻意的，因为没有测量的优化都是瞎猜。我见过太多人凭感觉优化，把一段根本不热的代码改得面目全非，真正的瓶颈还在那儿。

如果你提供了性能数据（比如"这个函数占了 60% 的 CPU 时间"），AI 就会针对性地给优化方案，并且每个方案都标注"预期收益"和"引入的复杂度"。你可以根据收益/复杂度比来决定做哪个。

3.8 /文档：生成能看懂的注释

/文档生成的不是那种"函数名复读机"式的注释（比如// 获取用户配getUser()），而是解释"为什么"的注释。提示词要求 AI 说明：这个函数解决什么问题、有什么非显而易见的约束、调用时要注意什么、有没有副作用。

我特别要求它不要注释那些一眼就能看懂的代码。注释是稀缺资源，满屏注释等于没注释。只注释那些"看代码看不出来"的信息，比如"这里必须用 <= 因为边界是闭区间"、"这个锁的顺序不能反否则会死锁"。

3.9 /提交：生成规范的提交信息

/提交会读取当前的改动，生成符合约定式提交（Conventional Commits）格式的信息，比如feat: 增加配置解析的 YAML 支持。提示词要求它区分改动类型（feat/fix/refactor/test/docs/chore），并且正文里说明"为什么改"而不只是"改了什么"。

实操技巧：如果一次改动包含多个不相关的修改，/提交会建议你拆成多个提交。这个建议很有价值，因为一个提交只做一件事，回滚和 review 都方便。

3.10 /拆解：把大任务切成可执行的小步

/拆解的输入是一个模糊的大需求，比如"给项目加个用户认证"。提示词要求 AI 输出一个分步骤的计划，每步都是"可独立验证"的——做完这步，你能明确知道它对不对。并且标注每步的依赖关系和预估复杂度。

这个命令的价值在于把"不知道从哪下手"变成"照着清单做"。大任务最怕的就是一团乱麻，拆解之后每一步都清晰了，执行起来心理负担小很多。

4. 命令包的落地实现与配置细节

4.1 命令文件的目录结构

大部分支持自定义命令的 AI 编程工具，都是从一个约定目录读取命令文件的。常见的结构是这样：

项目根目录/ .ai-commands/ # 命令目录（具体名字看工具约定） explain.md # /解释 complete.md # /补全 review.md # /审查 test.md # /写测试 refactor.md # /重构 debug.md # /查错 optimize.md # /优化 document.md # /文档 commit.md # /提交 breakdown.md # /拆解

每个.md文件就是一个命令。文件内容分两部分：头部是元信息（命令名、描述、参数说明），下面是提示词正文。不同工具的元信息格式不一样，有的是 YAML front matter，有的是特定注释语法，你需要查一下自己工具的文档。但提示词正文部分是通用的，换工具也能用。

4.2 一个完整命令文件的写法

拿/审查举例，一个完整的命令文件大概长这样：

--- name: 审查 description: 对代码进行严格审查，按严重程度分类输出问题 argument: 可选，本次审查的重点关注方向 --- 你是一位严格的代码审查者，有十年以上一线开发经验。 请审查以下代码，重点关注：空值和边界条件、并发与竞态、 资源释放、错误处理、输入校验、日志安全、命名准确性、重复逻辑。 如果用户指定了关注方向（$ARGUMENT），请优先深入检查该方向。 输出格式： 1. 严重问题：必须修改，可能导致 bug 或安全问题 2. 建议改进：改了更好，不改也能运行 3. 可选优化：风格和可读性层面 每个问题请给出：问题位置、问题说明、修改建议。 不要泛泛而谈，每个结论都要有代码依据。 待审查代码： $SELECTION

这里的$ARGUMENT是参数占位符，$SELECTION是当前选中的代码占位符。不同工具的占位符语法不同，但思路是一样的：把用户输入和上下文注入到提示词里。

4.3 参数传递的实操细节

参数传递看起来简单，实际用起来有几个坑。

第一个坑是参数为空时的处理。如果用户敲/审查不带参数，$ARGUMENT就是空字符串，提示词里那句"如果用户指定了关注方向"就会变成"如果用户指定了关注方向（）"，读起来很怪。解决办法是在提示词里写清楚"如果参数为空则忽略此条"，或者用工具的条件语法处理。

第二个坑是参数里的空格。/审查 并发 安全和/审查 并发安全在有些工具里解析结果不一样。前者可能被当成两个参数，后者是一个。我的建议是参数尽量用连字符或下划线连接，比如/审查 并发-安全，避免歧义。

第三个坑是参数注入提示词的位置。参数放在提示词开头还是结尾，效果不一样。我实测下来，放在"关注方向"这种明确的位置效果最好，放在最后容易被 AI 忽略。

4.4 跨工具迁移的注意事项

这套命令包我先后在几个不同的 AI 编程工具上用过，迁移的时候有几个点要注意。

占位符语法不同。有的工具用$SELECTION，有的用{{selection}}，有的用@selection。迁移的时候要全局替换。

命令触发方式不同。有的工具在对话框敲/触发，有的用快捷键唤起命令面板。这个影响不大，习惯就好。

上下文注入范围不同。有的工具会自动把当前打开的文件作为上下文，有的只注入你选中的部分。这个要搞清楚，否则会出现"AI 看不到我想要的代码"的情况。

中文支持程度不同。大部分工具对中文命令名支持良好，但个别工具在命令列表展示时会有编码问题。如果遇到，可以给命令加一个英文别名，两个都能触发。

提示：迁移之前，先把命令文件里的工具特定语法抽出来，做成一个"适配层"。比如把占位符统一写成{{SELECTION}}，然后写个小脚本在部署时替换成目标工具的语法。这样换工具只需要改脚本，不用改十个命令文件。

5. 常见问题与排查技巧实录

5.1 命令不触发或触发错误

最常见的问题是敲了命令没反应。排查顺序是这样的：先确认命令文件在正确的目录下，文件名和命令名对得上；再确认文件格式正确，元信息没有语法错误；最后确认工具版本支持自定义命令这个功能。我遇到过好几次是文件放错了目录，工具根本扫不到。

还有一个隐蔽的问题是命令名冲突。如果你自定义了/解释，而工具本身也有个/explain，一般不会冲突。但如果工具本身就有中文命令，就可能撞车。解决办法是给自定义命令加个前缀，比如/x解释。

5.2 AI 输出不符合预期格式

有时候你明明在提示词里规定了输出格式，AI 还是给你写一大段散文。原因通常是格式约束写得太靠后，被前面的内容淹没了。解决办法是把格式约束提到提示词靠前的位置，并且用明确的标记，比如"输出必须严格遵循以下格式，不要添加额外说明"。

另一个原因是格式约束太复杂。如果你规定了五层嵌套的结构，AI 很容易乱。建议格式控制在两层以内，用列表或简单表格。

5.3 中文命令在某些场景下识别不准

极少数情况下，AI 会把中文命令名当成普通文本处理，而不是触发命令。这通常发生在命令名和正文连在一起的时候，比如/解释这段代码中间没空格。解决办法是命令名后面加个空格，/解释 这段代码。

如果问题持续，检查一下工具的输入解析逻辑，看它是不是对中文字符的边界判断有问题。实在不行就换成拼音首字母命令。

5.4 提示词效果随时间衰减

这是个容易被忽略的问题。你精心调好的提示词，用了一段时间后发现效果变差了。原因可能是模型更新了，新版本对提示词的响应方式变了。这时候不要急着大改，先做小范围测试，看是哪个部分失效了，针对性调整。

我的做法是给每个命令文件加一个"版本"和"最后验证日期"的元信息，每隔一两个月重新验证一遍，确保效果稳定。

5.5 常见问题速查表

5.6 几条踩坑换来的经验

第一，命令不要贪多。我一开始设计了二十多个命令，结果自己都记不住，常用的还是那五六个。后来砍到十个，每个都高频使用，反而效率更高。命令包的价值在于"常用"，不在于"全"。

第二，提示词要定期回炉。我每个月会挑一两个命令，看看最近的输出质量，如果发现 AI 开始"偷懒"（输出变短、变泛），就回去加强提示词里的约束。

第三，保留一个"万能"命令。除了这十个专用命令，我还留了一个/问，就是把我输入的内容原样发给 AI，不做任何包装。遇到十个命令都覆盖不了的场景，用/问兜底。

第四，把命令包纳入版本管理。这些命令文件是你的"提示词资产"，值得用 Git 管起来。每次调整都提交，出问题能回滚，也能看到自己的提示词是怎么一步步演化的。

这套中文命令包用下来，最大的感受是：AI 编程的效率瓶颈，往往不在模型能力，而在你和模型之间的"接口设计"。命令包就是这个接口。接口设计得好，同样的模型能多干一倍的活；设计得差，再强的模型也使不上劲。中文命令包的意义，就是把这个接口从"英文思维"切换到"中文思维"，让沟通成本降到最低。你可以从最简单的/解释和/补全开始，用顺手了再逐步加，慢慢长成一套属于自己的工作流。