1. 为什么我要给 AI 编程助手做一套中文命令包用 AI 编程助手写代码这件事我从它刚能补全函数的时候就开始了。一路用下来最大的感受不是模型不够聪明而是沟通成本高得离谱。你脑子里想的是帮我把这个模块的边界条件补全顺便把异常处理统一一下手上敲出来的却是一段又长又啰嗦的提示词等它回你一大段代码你还得逐行核对它有没有理解偏。来来回回几次写代码的节奏全被打断了。后来我注意到一个现象这些 AI 编程工具其实都支持一种叫自定义命令或者斜杠命令的机制。你可以把一段固定的、反复要用的提示词封装成一个短命令比如输入/review就自动触发一套代码审查流程。这个机制本来是给英文用户设计的命令名、参数说明、触发词全是英文。但问题是我日常思考用的是中文我描述需求、判断代码好坏、跟同事讨论方案脑子里跑的都是中文。每次还要先把中文需求翻译成英文提示词再喂给工具这个中间层特别消耗精力。于是我就想能不能干脆做一套纯中文的命令包把我在日常开发里最高频的十来个操作全部封装成中文命令。比如/补全、/审查、/重构、/写测试、/解释、/优化、/查错、/文档、/提交、/拆解。这样我只要敲两个中文字AI 就知道我要干什么而且提示词里已经内置了我多年积累的怎么问才问得准的经验。这套东西做出来之后我的开发流确实变了。以前是想需求 → 组织英文提示词 → 等结果 → 反复调整现在是想需求 → 敲中文命令 → 拿结果。中间那层翻译和措辞的负担被彻底拿掉了。这篇文章我就把这套中文命令包的设计思路、每个命令背后的提示词工程、以及实际用下来踩过的坑完整地拆给你看。不管你是刚接触 AI 编程的新手还是已经用了一阵子但觉得效率卡在瓶颈的老手这套思路都能直接抄去改。2. 中文命令包的整体设计与选型考量2.1 为什么是命令包而不是提示词模板很多人做 AI 编程提效第一反应是搞一个提示词模板文档用的时候复制粘贴。我一开始也这么干但很快就放弃了。原因有三个。第一复制粘贴有摩擦。你正在编辑器里写代码手不离键盘这时候要去另一个文档里找模板、选中、复制、切回来、粘贴、再改参数这一套动作下来至少十几秒而且打断了心流。命令包是直接在对话框里敲两个字符就能触发的摩擦几乎为零。第二模板容易过期。你把提示词存在文档里改了一版又一版最后自己都分不清哪个是最新的。命令包是文件形式存在的每个命令一个文件改完即生效版本清晰。第三模板没法带参数。好的提示词往往需要根据上下文变化比如审查这段代码重点看并发安全。命令包支持参数传递你可以/审查 并发安全把关注点作为参数传进去提示词会自动拼接。模板做不到这一点你只能手动改。所以选命令包这个形态本质上是为了降低触发成本和支持参数化。这两点决定了它能不能真正融入日常流而不是变成一个偶尔想起来才用的摆设。2.2 十个命令是怎么选出来的我没有一上来就设计十个命令而是先观察了自己两周的开发行为把我反复让 AI 做的事列了个清单然后按频率排序取前十个。这个清单大概是这样的高频操作出现频率是否封装让 AI 解释一段看不懂的代码极高是/解释让 AI 补全或生成函数极高是/补全让 AI 审查代码找问题高是/审查让 AI 写单元测试高是/写测试让 AI 重构一段烂代码高是/重构让 AI 排查报错高是/查错让 AI 优化性能中是/优化让 AI 生成注释和文档中是/文档让 AI 生成提交信息中是/提交让 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 编程的效率瓶颈往往不在模型能力而在你和模型之间的接口设计。命令包就是这个接口。接口设计得好同样的模型能多干一倍的活设计得差再强的模型也使不上劲。中文命令包的意义就是把这个接口从英文思维切换到中文思维让沟通成本降到最低。你可以从最简单的/解释和/补全开始用顺手了再逐步加慢慢长成一套属于自己的工作流。