GitHub Copilot Slash Commands 实战：让常用 AI 操作更稳定

前言我刚开始用 Copilot Chat 时基本都是直接打一整句自然语言。比如解释这段代码、帮我修复这个错误、给这个函数写测试、优化一下这个方法。这样当然能用但问题也明显同样一类任务每次都要重新组织提示词。尤其是在代码审查、补测试、修报错这些高频场景里提示词写得不够具体Copilot 的回答就容易发散。Slash Commands 解决的就是这个问题。它把一些常见开发任务做成了斜杠命令比如/explain、/fix、/tests、/doc。输入/后Copilot Chat 会显示当前环境可用的命令。不同 IDE、不同上下文、不同扩展下能看到的命令会有差异所以最稳的办法不是背一张固定命令表而是在当前 Chat 输入框里输入/看可用项。我更愿意把 Slash Commands 看成“任务意图快捷入口”。它不会替代清晰的问题描述也不会自动理解所有项目规则。它的价值在于把常见动作变得更短、更明确再配合#上下文引用、workspace这类上下文能力让 Copilot 更容易把回答落到当前代码里。一、Slash Commands 适合处理高频小任务Slash Commands 的用法很简单在 Copilot Chat 输入框里输入/再选择对应命令。它本质上是预设任务入口帮你少写一大段提示词。常见命令可以分成几类。代码理解用/explain。当你打开一个陌生文件或者接手一段别人写的逻辑时它适合快速解释当前代码在做什么。代码修复用/fix。当编辑器里已经有报错、类型错误或明显问题时选中相关代码再执行/fix比单纯问“这段代码怎么改”更聚焦。测试生成用/tests。它适合围绕现有代码生成测试尤其是已经有函数、类或模块时。需要注意的是/tests更适合给已有代码补测试。如果你在做 TDD还没有代码实现直接用自然语言描述测试目标会更合适。文档注释可以用/doc。它适合给函数、类或模块生成注释尤其是公共 API、工具函数和复杂业务方法。性能或可维护性问题可以尝试/optimize或/simplify。这两个命令并不是所有环境都一样可用输入/时能看到就用看不到就直接用自然语言描述你的优化目标。这里有个使用习惯很重要命令只负责说明任务类型真正的质量还取决于上下文。比如只写/fixCopilot 会根据当前文件和选中内容尝试修复但它未必知道你希望保持 API 兼容、不能改数据库结构、不能引入新依赖。更稳的写法是/fix 只修复当前 TypeScript 类型错误不要改变函数签名不要新增依赖。Slash Commands 不需要写得很长但最好补上边界条件。尤其是修复类和优化类命令少加一句限制结果可能完全不同。二、/explain 不只是解释代码还适合接手旧项目/explain是我最常用的命令之一。接手一个旧项目时真正费时间的地方通常不是某一行语法而是搞清楚一段逻辑为什么这么写。这个函数处理了哪些边界为什么失败时返回默认值这里有没有隐含的业务规则这些信息在代码里经常没有注释。比如有这样一个函数functionparseUserPreferences(jsonString){constdefaults{theme:light,language:en,notifications:true};try{constparsedJSON.parse(jsonString);return{...defaults,...parsed};}catch(e){returndefaults;}}如果只是问/explainCopilot 大概率会解释这个函数如何解析 JSON、如何合并默认配置、为什么使用try...catch。但在真实项目里我更建议继续补充问题/explain 重点解释这个函数的容错策略以及哪些输入可能导致结果不符合预期。这样回答会更贴近开发判断。比如它可能指出如果 jsonString 是无效 JSON会直接返回默认配置。 如果 parsed 里传入 theme: null最终结果会覆盖默认 theme。 如果 parsed 里包含额外字段这个函数不会过滤。这些才是维护代码时真正有价值的信息。很多旧代码表面上能运行但隐含着“允许额外字段”“失败时静默降级”“默认值可被 null 覆盖”这类行为。/explain的价值不只是翻译代码而是帮你更快找到这些行为边界。它也适合代码审查前的预热。先选中关键函数跑一遍/explain再问“这里有没有副作用”“这里是否可能破坏兼容性”比直接从整个 PR 开始看更省力。三、/fix 和 /tests 要配合约束使用/fix很方便但我不建议把它当成自动修复按钮随便点。它适合处理范围明确的问题比如类型错误、空值判断遗漏、异步调用没等待、明显的语法问题。遇到跨模块 Bug、业务状态错误、并发问题时只靠/fix通常不够需要先让 Copilot 分析调用链和上下文。比如下面这个函数defcalculate_average(numbers):totalsum(numbers)returntotal/len(numbers)如果空列表进来会出现除零错误。选中这段代码后使用/fix 处理空列表输入保持返回值仍然是数字。得到的修复会更可控defcalculate_average(numbers):ifnotnumbers:return0totalsum(numbers)returntotal/len(numbers)如果不写“保持返回值仍然是数字”Copilot 可能会选择抛异常、返回None或者改成其他错误处理方式。它们不一定错但可能和当前项目约定冲突。/tests也一样。它能给已有函数生成测试但最好告诉它测试框架、覆盖重点和命名风格。比如这个函数defvalidate_email(email:str)-bool:ifnotemailornotinemail:returnFalselocal,domainemail.split(,1)ifnotlocalornotdomain:returnFalseif.notindomain:returnFalsereturnTrue可以这样写/tests 使用 pytest为 validate_email 生成测试。重点覆盖空字符串、None、缺少 、缺少域名、缺少本地部分、正常邮箱和带子域名邮箱。生成结果一般会比只写/tests更接近预期importpytestfromyour_moduleimportvalidate_emaildeftest_valid_email():assertvalidate_email(userexample.com)isTruedeftest_valid_email_with_subdomain():assertvalidate_email(usermail.example.com)isTruedeftest_empty_string():assertvalidate_email()isFalsedeftest_none_input():assertvalidate_email(None)isFalsedeftest_missing_at_symbol():assertvalidate_email(userexample.com)isFalsedeftest_missing_local_part():assertvalidate_email(example.com)isFalsedeftest_missing_domain():assertvalidate_email(user)isFalsedeftest_missing_dot_in_domain():assertvalidate_email(userexample)isFalse这段测试还有一个细节原函数类型标注是email: str但测试里传了None。如果项目严格使用类型检查这个用例可能需要调整。也就是说Copilot 生成的测试要审查不能直接当成最终答案。它可以帮你补测试框架和覆盖思路但边界条件是否符合项目设计仍然要自己判断。四、命令要和上下文引用一起用Slash Commands 单独使用适合当前选中代码很明确的场景。只要任务跨文件就要补上下文。VS Code 里可以用#明确引用文件、文件夹、符号、代码库、终端输出和工具结果。常见写法包括#file、#selection、#codebase、#terminalSelection。当前文件、当前选中内容、可见错误、Git 状态也会作为隐式上下文的一部分参与对话但复杂问题最好显式引用。比如你要解释当前选中的函数/explain #selection你要让 Copilot 从整个工作区找认证逻辑workspace 这个项目的登录态是在哪里维护的你知道问题涉及整个代码库但不知道相关文件在哪里可以写#codebase 找出订单状态从 pending 变成 paid 的完整调用链。你要让它结合终端错误输出修复问题可以先选中终端里的报错再写/fix #terminalSelection 结合当前项目结构分析这个测试失败原因。这里要注意不同 IDE 的上下文能力不完全一样。VS Code 支持#引用文件、文件夹、符号、代码库和终端输出也支持workspace、terminal、vscode这类参与者。Visual Studio、JetBrains、Xcode 里可用的命令和引用方式会有差异。实际使用时以当前输入框弹出的候选项为准。(Visual Studio Code)我现在的习惯是小代码块用#selection跨文件问题用#codebase项目结构问题用workspace终端错误用#terminalSelection或terminal。这样比单纯靠 Copilot 猜上下文稳定很多。五、把项目规则写进自定义指令Slash Commands 能告诉 Copilot 这次要做什么但项目规则要靠自定义指令长期保存。比如团队要求 React 组件必须用函数式组件API 请求统一用fetch禁止使用any所有外部输入必须做 Zod 校验。如果每次都在提示词里重复这些规则很快就会烦。更好的做法是放到.github/copilot-instructions.md。一个简单示例# Project rules - This project uses React 18 and TypeScript. - Use functional components and React Hooks. - Use fetch for API requests. Do not introduce axios. - Avoid any. Use specific types or unknown with type narrowing. - Validate external input with Zod. - Keep API response shapes backward compatible. - Do not modify database migration files unless explicitly requested.如果不同文件需要不同规则可以继续拆成.github/instructions/*.instructions.md用applyTo指定适用范围。VS Code 会把仓库级指令和匹配到的文件级指令加入上下文。适合把 React、测试、API、数据库、GitHub Actions 这类规则分开维护。(Visual Studio Code)例如测试文件可以单独写--- applyTo: **/*.test.ts,**/*.spec.ts --- - Use Vitest syntax. - Prefer explicit assertions over snapshot tests. - Cover success path, failure path, and boundary input. - Do not mock the module under test itself.这样再使用/tests时Copilot 更容易生成符合项目风格的测试。这里不要把自定义指令写成“写优雅代码”“遵循最佳实践”。这类话太宽实际效果有限。更有用的是项目里不容易从语法推断出来的规则比如“不要改 migration 文件”“API 响应字段必须兼容旧客户端”“后台任务日志必须包含 traceId”。总结Slash Commands 的价值不是让 Copilot 变得更神而是让常见操作更稳定。/explain适合理解旧代码和复杂逻辑。真正有价值的用法是让它解释设计意图、边界行为和潜在风险而不是只翻译每一行代码。/fix适合处理范围明确的问题。使用时最好补充约束例如不改函数签名、不引入新依赖、不改变返回结构。越是业务代码越要限制修改范围。/tests适合给已有代码补测试。它能快速生成测试骨架和常见边界用例但测试是否符合类型约束、业务预期和项目习惯仍然要人工审查。#上下文引用和参与者能显著提升回答质量。选中代码就用#selection跨文件问题用#codebase项目结构问题用workspace终端问题用terminal。项目规则要放进自定义指令。Slash Commands 解决单次任务意图自定义指令解决长期项目约束。两者配合起来Copilot 的输出才会更贴近真实项目。我的建议是先把最常用的三个场景跑顺解释旧代码、修复当前错误、给关键函数补测试。等这三个流程稳定后再加入#codebase、workspace和.github/copilot-instructions.md。这样不会一下子把 Copilot 用得太复杂也能慢慢形成自己的 AI 编码工作流。