在一次紧急的线上故障回滚会议中，面对屏幕上清一色的 fix bug、update code 和 111 提交记录，整个开发团队陷入了令人窒息的沉默。
这不仅是代码规范的缺失，更是一场典型的"上下文丢失"灾难。当代码变更失去了与之匹配的意图说明，每一次回溯都变成了大海捞针，每一位接手维护的同事都在被迫进行高难度的"代码考古"。
在阿里云开发者社区的技术实践中，我们发现优秀的提交信息（Commit Message）是代码库中信噪比最高的部分。它不只是给机器看的记录，更是工程师之间跨越时空的对话。然而，要求每一位开发者都能瞬间写出符合 Conventional Commits 规范的完美描述，既不现实也耗费精力。
这正是大模型（LLM）最擅长的领域。
我构建了一套"Git提交信息标准化AI指令"，它能将杂乱的代码变更描述瞬间转化为架构级的版本记录。它不是简单的翻译，而是对你的代码变更进行了一次"语义清洗"和"规范重构"。
🛠️ 核心AI指令：代码库的"守门员"
请将以下指令保存到你的 Prompt 库中，推荐使用 通义千问 (Qwen)、DeepSeek 或 Kimi 等国产大模型执行，它们对中文技术术语的理解尤为精准。
# 角色定义
你是一位资深的软件开发工程师和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接管提交信息？
很多开发者认为写好 Log 是"由于行政命令被迫执行的枯燥任务"。但实际上，这套AI指令解决的是开发流程中的三个隐形耗损：
1. 消除"认知阻断"
当你刚写完复杂的逻辑，大脑还停留在代码细节中。此刻让你切换思维去概括"我到底做了什么"，是一次高成本的上下文切换。
AI的价值：你只需扔给它碎片的变更点（"改了登录逻辑，加了手机号验证"），它能自动帮你组织成结构化的语言。你负责提供原料，AI负责烹饪。
2. 统一"技术方言"
同一个 fix，有人叫"修复"，有人叫"修补"，有人叫"解决"。团队协作中，这种不一致会导致搜索和过滤的困难。
AI的价值：指令强制约束了 feat、fix、refactor 等标准类型，确保了整个代码仓库的语义一致性。无论新人还是老手，提交记录都像出自一人之手。
3. 提升"追溯精度"
如果你只写了 fix login，两周后没人知道修了什么。
AI的价值：指令会引导AI生成 <body> 部分，详细列出"具体改动点"。这种颗粒度的提升，让 Code Review 时的理解成本直线下降。
🚀 实战演练：从"流水账"到"版本史诗"
假设你在阿里云函数计算（FC）项目中优化了一个图片处理功能，不仅修复了内存溢出，还顺手改了下格式。
原始输入（你随手写的）：
"改了下图片处理，之前老是用量超标报错，现在限制了大小，顺便把缩进调整了一下。"
投喂给AI后的输出：
perf(image-process): 优化图片处理内存占用并规范代码格式
- 增加图片大小预检查逻辑，限制最大处理尺寸为5MB
- 引入流式处理替代一次性加载，降低内存峰值
- 统一调整 image-utils 模块的代码缩进和换行格式
Closes #1024
看，原本混在一起的逻辑被清晰地拆解了。perf 类型准确指出了这是一次性能优化，正文部分条理清晰地记录了技术手段。
📝 落地建议
不要试图强迫团队成员背诵《Angular提交规范》。工具的问题，就用工具解决。
建议将这条指令配置在团队共享的 Prompt Library 中。在执行 git commit 前，花10秒钟与AI对话，换来的是整个项目全生命周期的维护红利。
记住，代码是写给机器跑的，但 Commit Message 是写给未来的自己和队友看的。 别让今天的随意，成为明天的技术债务。
