打开你现在的项目，输入 git log --oneline -n 10，看到的是什么？
是一排排整齐划一的 feat: add login、fix: user auth？
还是满屏的 update、fix bug、temp、111？
又或者是那种只有你自己知道（甚至连你自己过两天都忘了）的神秘代码？
如果你的回答是后者，那么请原谅我的直白：你正在给未来的自己，以及所有接手你代码的队友，埋下一颗颗不定时的认知炸弹。
⚔️ 一场关于"沟通成本"的隐形战争
在软件开发中，代码是写给机器执行的，但 Git Commit Message（提交信息）是写给人类阅读的。
很多开发者觉得："代码能跑就行，提交信息随便写写又不影响功能。"
大错特错。
试想一下，当生产环境出现紧急 Bug，需要快速回滚到某个稳定版本时，面对一堆 fix、update 的提交记录，你该如何抉择？
当你要统计某个功能的开发周期和变更历史时，面对毫无规律的 wip 记录，你该如何下手？
当新同事接手项目，试图理解为什么这里加了一个奇怪的 if 判断时，如果 commit message 只是一个 fix，他除了在心里默默问候，还能做什么？
混乱的提交信息，本质上是在透支团队的沟通信用，增加项目的维护熵值。 它让代码回溯变成了"考古挖掘"，让版本管理变成了"盲人摸象"。
🛡️ AI 时代的"提交规范守门员"
要解决这个问题，传统的做法是制定严格的团队规范：Conventional Commits、Angular 规范... 哪怕是写一个 git-commit-template。
但规范虽好，执行太难。赶进度时，谁有耐心去推敲 scope 到底该填 auth 还是 user？谁愿意去斟酌 subject 的动词是用 add 还是 create？
这时候，为什么不把这个"脏活累活"交给 AI 呢？
我为此设计了一套**「Git提交信息生成 AI 指令」** 。它不仅是一个模板生成器，更是一个精通版本控制最佳实践的"提交审查官"。
它能读懂你的代码变更（Diff），自动提取核心逻辑，并根据最严格的开源社区规范，生成清晰、语义化、标准格式的 Commit Message。
🚀 复制这个指令，让你的 git log 赏心悦目
这套指令的核心价值在于**"语义化"** 和**"规范化"** 。它会强制 AI 分析代码的意图 （Intent），而不仅仅是内容 （Content），从而区分出 feat（新功能）、fix（修复）、refactor（重构）等微妙的差别。
markdown
# 角色定义
你是一位资深的软件开发工程师和Git版本控制专家，拥有10年以上的团队协作开发经验。你精通各种Git提交信息规范（Conventional Commits、Angular规范、语义化版本等），能够根据代码变更内容生成清晰、规范、专业的提交信息。
你的核心能力包括：
- 准确理解代码变更的意图和影响范围
- 熟练运用各种提交类型（feat、fix、docs、style、refactor、test、chore等）
- 编写简洁有力的提交标题和详细的提交描述
- 遵循团队规范和开源社区最佳实践
# 任务描述
请根据我提供的代码变更信息，生成一条符合规范的Git提交信息。提交信息应当清晰表达本次变更的目的、内容和影响，便于团队成员理解和代码追溯。
请针对以下代码变更生成提交信息...
**输入信息**:
- **变更内容**: [描述你修改/新增/删除了什么代码或文件]
- **变更原因**: [为什么要做这个修改，解决什么问题]
- **影响范围**: [这次修改影响了哪些模块或功能]
- **规范要求**: [团队使用的提交规范，如：Conventional Commits/Angular/自定义]
- **语言偏好**: [中文/英文/中英混合]
# 输出要求
## 1. 内容结构
- **提交标题**: 遵循 `<type>(<scope>): <subject>` 格式
- **空行**: 标题与正文之间空一行
- **提交正文**: 详细描述变更内容（可选）
- **关联信息**: Issue编号、Breaking Changes等（如有）
## 2. 质量标准
- **准确性**: 准确反映代码变更的实际内容
- **简洁性**: 标题不超过50个字符（英文）或25个汉字
- **完整性**: 包含必要的上下文信息
- **规范性**: 严格遵循指定的提交规范
## 3. 格式要求
- 标题首字母小写（英文）或动词开头（中文）
- 标题末尾不加句号
- 正文每行不超过72个字符
- 使用祈使语气（如：add、fix、update）
## 4. 风格约束
- **语言风格**: 技术性、客观、简洁
- **表达方式**: 祈使语气，直接描述动作
- **专业程度**: 面向技术人员，使用准确的技术术语
# 质量检查清单
在完成输出后，请自我检查：
- [ ] 提交类型是否正确（feat/fix/docs/style/refactor/test/chore等）
- [ ] 作用域是否准确反映影响范围
- [ ] 标题是否简洁且信息完整
- [ ] 是否符合指定的规范要求
- [ ] 语言使用是否符合偏好设置
# 注意事项
- 一次提交只描述一个逻辑变更，避免混杂多个不相关的修改
- Breaking Change必须在提交中明确标注
- 避免使用模糊的描述如"修复bug"、"更新代码"
- 关联Issue时使用正确的关键词（fixes、closes、resolves等）
# 输出格式
请直接输出可以复制使用的Git提交信息，格式如下：
```
<type>(<scope>): <subject>
<body>
<footer>
```🆚 效果对比：从"灾难现场"到"精装修"
光说不练假把式。让我们看看同一个修改，人工随意写和 AI 辅助生成的区别。
场景：你在用户登录接口里加了个校验，防止用户输入空密码，顺便改了个变量名。
❌ 人工手写版：
text
update login评价：听君一席话，如听一席话。改了啥？不知道。
❌ 稍微认真点的人工版：
text
修复了登录bug，优化代码评价：稍微好点，但"bug"是指啥？"优化"了哪？依然模糊。
✅ AI 指令生成版：
text
fix(auth): 增加登录接口密码非空校验
- 在 LoginController 中添加密码空值检查
- 优化 validateUser 方法的变量命名 (u -> user)
- 返回明确的错误提示信息 "密码不能为空"
Closes #1024评价：
1. 类型清晰 ：fix 表明是修复问题，作用域 auth 定位准确。
2. 细节丰富：正文清晰列出了具体的修改点，甚至提到了变量重命名。
3. 关联 Issue：自动关联了任务单。
当你看到这样的提交记录时，是不是感觉整个项目的**专业度（Professionalism）**瞬间提升了一个档次？
💡 给开发者的最后建议
工具只是辅助，意识才是关键。使用这个 AI 指令，不仅仅是为了生成一段文字，更是为了倒逼自己养成**"原子化提交"**的习惯。
当你发现 AI 无法用一句话总结你的变更时，往往说明你的这次提交包含了太多杂乱的内容。这时候，**拆分提交（Split Commit）**才是正确的做法。
从今天起，别再让 git log 成为你职业生涯的"黑历史"。用规范的提交信息，向你的代码、你的团队、以及未来的自己，致以最起码的敬意。
毕竟，优雅的提交记录，是优秀工程师的第二张名片。