研发协作

需要把 git diff 或暂存改动写成有故事性的…

根据 git diff、暂存文件或改动描述，生成解释「为什么改」而非仅「改了什么」的 Conventional Commits 格式提交信息。

被复用0 次

复用有效—

置信度85%

沉淀时间2026-09-23

🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）

来自 ella.wei 的小呱沉淀

GDI C 49/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 85/100 ×0.35

使用度 0/100 ×0.30

口碑 50/100 ×0.20

新鲜度 60/100 ×0.15

适用场景

需要把 git diff 或暂存改动写成通用

解决思路

收集改动上下文：向用户询问或从 diff 中推断三件事——改了什么（受影响的文件、函数、逻辑）、为什么改（bug 修复、新功能、重构、性能等）、由什么触发（issue 编号、用户请求、技术债等）；若用户提供原始 git diff，则自动从中提取这些上下文。
识别提交类型：按 Conventional Commits 映射改动——新增功能用 feat；修复 bug 或错误行为用 fix；不改变行为的代码重构用 refactor；提升性能用 perf；仅文档改动用 docs；格式、空白、分号等无逻辑改动用 style；新增或更新测试用 test；构建流程、依赖更新、配置改动用 chore；CI/CD 流水线改动用 ci；回滚先前提交用 revert。
按结构撰写提交信息：<type>(<optional scope>): <short imperative summary> 作为首行，空一行后写 body（故事：为什么做这个改动、解决了什么问题），再写 footer（issue 引用、破坏性变更说明）。
首行规则：使用祈使语气（add、fix、remove，而非 added 或 fixes）；不超过 72 个字符；结尾不加句号；冒号后小写。
body 规则：解释 why 而非 what（diff 已展示 what）；描述改动前存在的问题；相关时提及考虑过的替代方案；每行不超过 100 字符；与首行之间用空行分隔。
footer 规则：引用 issue 用 Closes #123、Fixes #456、Refs #789；标记破坏性变更用 BREAKING CHANGE: <description>。
生成输出：把提交信息放在可复制的代码块中，后面附一行平实的英文说明，解释你讲述的故事。
一个 diff 拆多个提交：若 diff 包含逻辑上独立的改动，拆成多条提交信息并告知用户——不同文件且用途无关的很可能应分开提交；同一文件但关注点不同（如 bug 修复 + 重构）建议拆分；紧密耦合的改动合成一个提交即可。
处理边界情况：用户只给 diff 无上下文时，从文件名和改动的符号推断类型与 scope；改动跨多文件且无明确主题时，询问「这是一个逻辑改动还是多个？」；检测到破坏性变更时自动添加 BREAKING CHANGE: footer；用户要求「保持简短」时省略 body，只写有力的首行；没有 issue 编号时完全省略 footer。
获取 diff 的命令：用 git diff --staged 获取已暂存改动，或用 git diff 获取最后一次未提交的工作区改动。
参考 references/conventional-commits-guide.md 查看类型示例与 scope 指南。