用 Trae、Claude Code、Cline 这类 AI 编程工具时，经常会遇到一个小问题：让它生成 Git 提交信息，它不是只给一句 commit message，而是顺手写一大段解释、改动摘要、注意事项，甚至还给你列清单。
如果是在聊天里看一眼还好；如果是在 git_message 场景里，这种输出就很烦。我们真正需要的只是类似下面这种一句话：
docs: 精简Trae提交信息规则问题不在于 AI 不懂你的意思，而是你的规则还不够“可判定”。只写“简单一点”“短一点”“一句话总结”通常不够，因为模型会把它当成风格建议，而不是硬性输出协议。
把要求写成硬性规则
可以把 Trae 的 git message 规则改成这样：
---
alwaysApply: true
scene: git_message
---
只输出一行中文 git commit message。
硬性要求：
- 不超过 50 个中文字符
- 不换行
- 不解释
- 不列清单
- 不写正文
- 不包含句号
- 格式：类型: 动作 + 对象 + 结果
类型只能选：
docs, feat, fix, refactor, chore, test, style
示例：
docs: 精简Claude Code权限配置说明
fix: 修复Windows路径权限匹配问题
refactor: 调整WordPress发布审计结构
输出前自检：如果超过 50 字，必须压缩到 50 字以内。这里最关键的不是示例，而是这些否定规则：
- 不解释
- 不列清单
- 不写正文
- 不换行
AI 很容易把“生成提交信息”理解成“帮你分析一下这次改动并给一个建议”。所以要明确告诉它：只要 commit message 本身，其他任何文字都不要出现。
加一句失败条件
如果 Trae 还是喜欢多写，可以在规则末尾再加一句：
除 commit message 本身外，输出任何额外文字都视为失败。这句话很有用。它把“别啰嗦”从语气要求变成了判定条件。模型会更倾向于压缩输出，而不是礼貌性地补充解释。
提问方式也要配合
规则写好了，平时让它生成提交信息时也不要问得太开放。
不太推荐：
总结本次改动并生成提交信息。这种问法会诱导它先总结，再给 commit message。
更推荐：
只生成 commit message，不要解释。或者：
按 git_message 规则输出一行提交信息。规则和提示词要朝同一个方向用力。规则说“只输出一行”，提示词就不要再说“总结一下改动”。
类型不用太多
commit message 的类型也不要放太多。常用这些就够了：
docs, feat, fix, refactor, chore, test, style类型越多，AI 越容易犹豫，最后又开始解释为什么选这个类型。对日常个人项目来说，能稳定生成清晰短句，比类型体系特别完整更重要。
50 字限制要写清楚
“不要超过 50 个字符”最好写成硬性要求，而不是建议：
不超过 50 个中文字符如果你经常写中文 commit message，这个长度基本够用。太长的提交信息往往不是信息更多，而是动作、对象、结果没有压缩好。
例如：
docs: 更新WordPress发布流程说明比下面这种更适合提交历史：
docs: 更新WordPress发布流程相关文档并补充特色图和SEO校验说明后者不是不能用，只是日常看 git log --oneline 时会显得拥挤。
一份我会直接用的版本
最终可以直接放这份：
---
alwaysApply: true
scene: git_message
---
只输出一行中文 git commit message。
硬性要求：
- 不超过 50 个中文字符
- 不换行
- 不解释
- 不列清单
- 不写正文
- 不包含句号
- 格式：类型: 动作 + 对象 + 结果
类型只能选：
docs, feat, fix, refactor, chore, test, style
示例：
docs: 精简Trae提交信息规则
fix: 修复Windows路径权限匹配问题
refactor: 调整WordPress发布审计结构
输出前自检：如果超过 50 字，必须压缩到 50 字以内。
除 commit message 本身外，输出任何额外文字都视为失败。小结
想让 Trae 的提交信息变短，不要只写“简短一点”。要把输出格式、长度、禁止项、失败条件都写清楚。
一句话版本就是：**把 commit message 规则写成硬约束，而不是风格建议。**
这样它才更容易稳定输出：
docs: 精简Trae提交信息规则而不是又来一大段“本次提交主要包括以下内容”。
