GitHub Copilot Commit Message 生成与自定义配置优化指南

前言

提交信息这件事，几乎每个开发者都知道重要，但也几乎每个团队都碰到过同样的问题。有人写得太短，只留下一句 update。有人写得太散，标题和正文都抓不住重点。还有一些团队明明已经约定了 Conventional Commits、工单号、语言风格和 scope 规则，最后真正落到提交历史里，还是越来越乱。

Copilot 把这件事往前推了一步。现在它已经可以根据你选中的改动生成提交标题和描述，但真正决定结果好不好用的，不是按钮本身，而是上下文和规则有没有提前准备好。尤其是团队一旦有固定格式、固定语言、固定工单规范，默认生成结果通常是不够的。

不要把 Copilot 的提交信息生成功能当成随机写一句摘要的工具，而要把它当成一个可以被约束、被校正、被纳入团队规范的自动化入口。这样它才会真正帮你省时间，而不是再制造一层新的返工。

一、先搞清楚它到底在做什么

Copilot 生成提交信息的基本逻辑并不复杂。它会读取你已经选中准备提交的改动，然后根据这些变更内容生成一个标题和描述。这个过程不是根据整个仓库历史去推理，也不是根据某个复杂训练专门微调出来的模型去写，而是基于当前改动内容做一次摘要型生成。

这里有两个现实边界最好先看清。

第一，它的结果高度依赖你这次提交的改动是否足够聚焦。一个提交里如果混进了功能开发、重构、文档调整和测试修复，Copilot 再聪明，最后也只能给你一个平均值式的总结。第二，它默认更擅长生成英文摘要。在 GitHub.com 和 GitHub Desktop 的这项功能里，当前明示支持的提交信息语言是英文。也就是说，如果团队本身要求中文提交历史，不能指望默认状态下直接稳定满足。

这也是为什么，真正有效的优化路径不是一味追求更强的模型，而是先把提交范围收窄，再把规则前移。提交越清楚，生成结果越准。规则越明确，输出越稳定。

二、真正值得用起来的是提交信息专用 instructions

现在在 VS Code 里，Copilot 已经支持专门针对提交信息生成配置自定义 instructions。对应的设置项是 github.copilot.chat.commitMessageGeneration.instructions。它目前仍被标记为 Experimental，但已经能正常接受两种形式的规则输入，一种是直接写在设置里的 text，另一种是引用一个 Markdown 文件的 file 路径。

这一步非常关键。因为它意味着你不需要再把所有提交规范都寄希望于通用的聊天指令，也不需要每次生成提交信息时重新解释团队约定。你可以把提交信息规则单独抽出来，只在这一个场景下生效。

一个更稳的做法，是直接在工作区里放一份 Markdown 规则文件，比如：

# 提交信息规则

- 使用 Conventional Commits
- 标题尽量控制在 50 个字符以内
- 如果需要正文，正文每行尽量控制在 72 个字符以内
- 优先概括本次改动的目的，不要机械罗列文件名
- 如果变更涉及工单，补上工单号
- 不要使用模糊表达，例如 update、fix bug、modify code

然后在 settings.json 里这样关联：

{
  "github.copilot.chat.commitMessageGeneration.instructions": [
    {
      "file": ".vscode/commit-instructions.md"
    }
  ]
}

这里有一个很重要的现实点。与其纠结某个固定文件名是不是唯一标准，不如直接抓住已经明确支持的能力边界，也就是这个设置项本身支持 file 和 text 两种输入形式。这样写的好处是更稳定，也更容易在团队里复制。

三、团队如果要中文提交信息是把格式和语气一起约束住

很多团队在内部协作里，确实更希望提交历史是中文。这件事可以做，但不能只写一句 请使用中文。真正更稳的做法，是连同格式、语气和保留哪些英文结构一起写进去。

原因很简单。提交信息不是普通聊天输出，它通常还会被 CI、发布工具、日志系统或者团队约定一起消费。Conventional Commits 里的 feat、fix、docs 这类前缀，本身最好保留英文，因为这部分往往承担着自动解析的职责。真正可以本地化的，主要是 subject 和正文说明。

更实用的规则写法可以像这样：

# 中文提交信息规则

- 提交信息主体使用简体中文
- 保留 Conventional Commits 英文类型前缀
- 推荐格式为 <type>(<scope>): <subject>
- subject 用中文简洁描述本次改动，不要写成口语
- 如果需要正文，说明为什么要改，以及影响范围
- 避免使用 修一下、改点东西、优化若干 这类模糊表达

然后再配合一组例子，让 Copilot 更容易抓住你们真正想要的风格：

示例：
feat(auth): 增加短信登录校验流程
fix(order): 修复订单超时后状态未回滚的问题
docs(api): 补充用户中心接口返回字段说明
refactor(user): 拆分用户资料更新逻辑并收敛重复校验

这种写法的好处是，它不是只告诉模型语言偏好，而是把结构、语气、模糊词禁用范围一起写清楚。这样生成结果会稳很多。

不过这里也要把边界说清楚。大改动、混合提交、跨很多文件的提交，本来就更容易让模型丢重点。语言规则写得再细，也不等于它在任何场景下都能完美遵守。所以真正想要稳定，还是要先把提交本身切小、切清楚。

四、团队用 Conventional Commits

很多文章一提 Conventional Commits，写法都差不多，列一张类型表，然后结束。这样当然不能算错，但还不够。因为真正的难点从来不是团队不知道有哪些类型，而是不知道什么时候用哪个、scope 要不要写、工单号放哪、正文应该写到什么粒度。

所以更有效的做法，不是只列 feat、fix、docs 这些类型，而是把团队自己的判定规则一起写进去。比如：

# Conventional Commits 使用规则

- feat 只用于真正新增可感知功能
- fix 只用于修复缺陷，不用于重构
- refactor 用于重构，不应暗含新功能或修复
- docs 只用于文档变更
- chore 用于构建、脚本、依赖和其他维护项
- 如果改动集中在单一模块，必须写 scope
- 如果分支名中带工单号，标题中应带上工单号

如果你们团队的分支规范本身已经包含工单号，比如 feature/DEV-1234-user-auth 这种形式，那规则里还可以继续要求生成结果尽量包含工单号。只是这里要注意一个边界，提交信息生成能不能自动稳定识别分支名，取决于你所在环境、插件状态和当前上下文是否能把这些信息喂给模型。所以更稳妥的表达方式，不是说它一定能自动提取，而是明确告诉它，若上下文里已有工单号，应优先写进标题。这样更符合实际，也更不容易让团队形成错误预期。

五、真正影响生成质量的是提交本身

这件事反而最容易被忽略。很多人会一直调 instructions，结果越调越复杂，但效果还是不稳定。问题根本不在规则不够细，而在提交本身就不适合被一句话概括。

如果一个提交同时改了 API、改了数据库迁移、补了测试、修了文档，再加一点顺手重构，那不管是人还是 Copilot，最后都很难写出一条真正干净的提交信息。它最多只能生成一个折中的概括，而这个概括通常不够好。

所以，比起继续堆规则，更有价值的习惯其实有两个。

第一个是小步提交。把同一类改动放在同一个提交里。第二个是先暂存你真的打算一起提交的那部分内容，再触发生成。因为它本来就是基于你当前选中的改动做总结，选得越杂，生成就越散。

你可以把这件事理解得更直接一点。Copilot 不是在替你整理混乱，它只是帮你总结已经相对清晰的改动。如果提交本身没整理好，它也救不了。

六、实战里最稳的策略是分层配置

如果团队真的想把这套能力长期用起来，我更建议按三层思路来配。

第一层是仓库级规则，用 .github/copilot-instructions.md 承载那些长期稳定的团队规范，比如是否使用 Conventional Commits、是否要求工单号、整体语言偏好、是否必须写正文。GitHub 和 VS Code 现在都已经支持把这类仓库级自定义指令自动加入 Copilot 请求里。

第二层是提交信息专用规则，用 github.copilot.chat.commitMessageGeneration.instructions 单独配置。这样提交信息有自己的格式约束，不会和普通聊天、代码生成规则混在一起。

第三层是团队 review 习惯。再好的规则都不可能一次性覆盖所有情况，所以最终还是要保留人工确认。Copilot 给出的提交信息，本质上应该被看成草稿，而不是最终版本。GitHub 在相关说明里也明确强调，这个能力是辅助，不是替代，用户仍然需要审阅和修改结果。

这三层叠起来，效果会比试图靠一个超长 instruction 文件解决所有问题要稳得多。

总结

GitHub Copilot 的提交信息生成能力，真正的价值不在于自动写一句摘要，而在于它可以被纳入团队自己的提交规范体系里。只要规则足够清楚，提交本身足够干净，再把仓库级规则、提交信息专用 instructions 和人工 review 这三层配合起来，它就不再是随机生成一条英文描述，而会慢慢变成你们团队协作流程里的稳定部件。