为什么高级工程师的 Git Log 像诗，而你的像“案发现场“？
深夜排查 Bug 最怕遇到全是 "fix" 的提交记录。本文分享一套基于 Conventional Commits 规范的 AI 指令，能将杂乱的代码变更自动转化为清晰、标准的 Git 提交信息。拒绝无效沟通，让你的 git log 成为团队协作的利器，提升代码可维护性与个人职业形象。
深夜两点，线上服务突然告警。你顶着黑眼圈打开终端，输入 git blame 试图找出是哪行代码导致了内存泄漏。
屏幕上跳出的提交信息让你眼前一黑：
commit a1b2c3d
Author: xiao_wang
Date: yesterday
Message: fix bug
commit e5f6g7h
Author: xiao_wang
Date: 2 days ago
Message: update
commit i8j9k0l
Author: xiao_wang
Date: 3 days ago
Message: 再次修复那个该死的问题
这一刻，你不是在由衷地感谢同事的辛勤付出，而是在心里默默排练了一百遍"格斗技巧"。
承认吧，Git 提交信息就是程序员的"脸面"。
在开源社区或大厂团队，看一个人的代码水平，往往不需要看代码逻辑，扫一眼他的 git log 就知道了。优秀的提交信息（Commit Message）不仅是开发进度的记录，更是团队协作的异步通信协议。
但现实是，我们总是在赶进度，总是在"写完代码就跑"。为了解决这个**“我知道规范很重要，但我真的懒得写"的千古难题，我训练了一套"Git 提交信息生成 AI 指令”**。
它不只是帮你凑字数，而是能像一位严苛的 Tech Lead 一样，把你的代码变更翻译成符合行业标准的专业文档。
🕵️♂️ 从"代码嫌疑人"到"版本管理大师"
这套指令的核心逻辑，是基于 Conventional Commits（约定式提交） 规范。它能精准识别你的修改是属于 feat（新功能）、fix（修补）、refactor（重构）还是 chore（杂务）。
更重要的是，它能把那一堆杂乱无章的 diff，变成人话。
核心 AI 指令（建议直接存入 Cursor/Obsidian）
# 角色定义
你是一位资深的软件开发工程师和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 的"整容"能力
光说不练假把式。我们拿两个真实的开发场景，看看这套指令是如何化腐朽为神奇的。
场景一：那个"只是改了个小逻辑"的提交
你的输入：
“改了下用户登录，加了个手机号验证，为了安全嘛。是在 auth 模块里改的。”
普通人的提交：
Update login logic
AI 的提交：
feat(auth): 添加用户登录手机号验证功能
- 在登录流程中集成短信验证码校验
- 更新用户安全策略，强制开启双因素认证
- 优化错误提示信息，提升用户体验
增强账户安全性，防止恶意暴力破解
解析：AI 敏锐地识别出这是 feat（新功能），并提取了 “auth” 作为作用域。最妙的是正文部分，它自动补全了上下文逻辑，让这次提交显得有理有据。
场景二：那个"我也不知道改了啥反正跑通了"的提交
你的输入：
“修复了 iOS 上图片传不上去的问题，好像是格式不支持，我加了个转换逻辑。关联 Issue #892。”
普通人的提交：
fix bug或fix ios upload
AI 的提交：
fix(upload): 修复iOS设备HEIC图片上传失败问题
- 添加HEIC格式图片的自动转换中间件
- 在上传前统一将图片转换为JPEG格式
- 增加文件格式检测和友好的错误提示
Closes #892
解析：看到 Closes #892 了吗？这就是自动化与项目管理工具（如 Jira、GitHub Issues）联动的关键。以后你的 PM 问你"那个 Bug 修了吗"，你直接甩这个 commit 链接给他，这就是专业。
🚀 为什么你需要现在就用上它？
- 自动生成 Changelog：如果你的提交信息符合 Conventional Commits 规范，你可以使用
standard-version等工具一键生成漂亮的更新日志（CHANGELOG.md）。告别手动写周报的痛苦。 - 代码审查（Code Review）更顺畅：Reviewer 看到清晰的提交信息，心情会变好，通过率自然就高了。
- 未来的你，会感谢现在的自己：三个月后，当你需要回滚某个功能时，你会庆幸自己写得是
feat(payment): add alipay support而不是update。
💡 极客小贴士
如果你觉得每次都要复制粘贴指令很麻烦，可以将这个 Prompt 配置到你的 AI 辅助工具（如 Cursor 的 Rules、ChatGPT 的 Custom Instructions）中。
或者，试试更硬核的玩法：结合 git hook。写一个 prepare-commit-msg 钩子，让 AI 自动读取你的 git diff 并生成提交信息建议。
别让糟糕的提交信息，掩盖了你优秀代码的光芒。从下一次 git commit 开始，做个"体面"的工程师。
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
8
0- 0
已为社区贡献20条内容
所有评论(0)