最近我的 git 提交流程发生了不小的变化。以前写完代码顺手敲一句“fix bug”“update code”“改了一堆东西”就推了等过了两周回来看历史记录完全想不起来当时改了啥。后来我开始试着让 Cursor 的 AI 帮我生成 commit message再进一步让它帮我做完整的智能 commit分析 diff、按逻辑拆提交、生成符合团队规范的提交信息、执行提交。用了一段时间之后我发现这套流程本身就是一个值得分享的工作流。这篇文章就从我的实际使用经验出发讲清楚智能 commit 的思路、配置、Prompt 写法、实操步骤和踩过的坑给同样在用 Cursor、想改善提交质量但一直没动手的开发者一个参考。1. 为什么要把 commit 这件事交给 AI 来做1.1 我见过最敷衍的提交消息长什么样Git 提交消息这件事很多人觉得是形式主义。我见过最夸张的是同一个人同一个分支上连续十条提交全是“update”中间偶尔穿插一条“啊这里错了”。到了要写版本发布说明或者回滚代码的时候你就得把 diff 一坨一坨翻出来一行一行比对才能知道那次提交到底动了什么。这种效率损耗在一个人单干的项目里还能接受一旦交给团队后续接手的人基本是在考古。还有一类情况是 message 写得很长但全是空话。比如“修复了页面上的一个问题优化了加载逻辑调整了一些样式”看似写了一大段实际上没有一条能让人快速定位修改点。真正有价值的提交信息应该像一个小标题一看就知道这个提交在哪个模块做了什么类型的变更。这件事说起来简单坚持做下来却很难因为人在写完代码后的第一反应是赶紧提交、赶紧切到下一个任务根本不想花时间组织语言。1.2 Cursor 在这里面到底强在哪让 AI 来写 commit message 并不是新鲜事很多命令行工具也能做到但 Cursor 有一个天然的场景优势它就在你的编辑器里能看到当前的代码变更能直接操作终端。这意味着它可以不依赖“你把代码贴给它”这种笨办法而是自己去看git diff自己去理解这次改动的意图。我在实际使用中的感受是Cursor 的 AI 对代码变更的感知比我想象得更细。它不只会看到“这些文件被修改了”还能在一个文件内部区分出哪些改动是重构、哪些是新增逻辑、哪些又是修 bug。这个能力是智能 commit 的核心基础。普通的提交信息生成工具基本只能做“把文件名和改动行数拼成一段话”而 Cursor 能做到“读懂改动意图再生成描述”两者体验差别非常大。更关键的是Cursor 可以在对话里调用终端命令也就是后面要讲的 Agent 模式。这就让整个链路从“AI 生成一段文字、我自己复制粘贴执行”进化成了“AI 自己看状态、自己提出提交计划、在执行前等我的确认”。这种闭环体验是目前其他 AI 编程工具里比较少见的。1.3 我给自己定的三条原则在把一个环节交给 AI 之前我习惯先明确边界。智能 commit 这套流程我刚上手的时候吃过小亏后来给自己定了几条原则一直用到现在。第一条是“AI 提议人来确认”。无论 AI 分析得看起来多准确我永远不会让它跳过确认直接提交。哪怕它在 Agent 模式里已经准备好了完整的git commit命令我也要亲眼看到它将 add 哪些文件、提交信息写的是什么再放行。第二条是“只提交本逻辑内的改动不做全家桶”。一次提交尽量只解决一件事。AI 很容易把所有改动塞进一个提交里我必须让它先给出拆分计划再按计划逐个执行。第三条是“绝不自动 push”。就算 commit 是 AI 做的push 这个动作我一定自己来。因为 push 是不可逆的上游操作一旦推到远端历史就进入了公共区域再想改就很麻烦。把 push 留给自己相当于把质量控制和安全控制握在手里。2. 让 Cursor 懂规矩diff、规范与 .cursorrules2.1 先补两个 Git 基础概念status 与 diff如果你平时只用git add、git commit、git push这三板斧后面看智能 commit 的用法可能会有点吃力。这里花几分钟补一下基础。git status用来查看当前工作区有多少个文件被修改、有多少新文件没被跟踪、当前在哪个分支。它是 AI 分析改动范围的第一手信息。git diff用来查看具体的代码改动内容默认显示的是还没提交的改动也就是工作区和暂存区之间的差异。这两个命令组合起来就构成了智能 commit 的信息源。Cursor 的 AI 在执行终端命令时会先跑git status拿到文件清单再跑git diff或者git diff --stat拿到每个文件改了多少行、改了什么代码。只有在拿到这些信息之后它生成的提交信息才不是凭空猜的。所以如果你在团队里想让别人也可以用你这个工作流至少要让他们懂得这两个命令的作用。另外还有一个值得提的命令是git diff --staged它查看的是已经git add但还没提交的内容。如果你想先用git add确立提交范围再让 AI 只针对暂存区生成信息这个命令会更准确。我习惯让 AI 先看工作区的完整差异再让它自己区分需要提交的部分这样更符合实际工作流的节奏。2.2 Conventional Commits团队规范的通用语言智能 commit 生成出来的信息如果不规定格式就只是“一段长得像话的中文描述”含金量不高。我建议直接绑上 Conventional Commits 这个规范。这本质上是一套提交信息命名约定核心格式是type(scope): subject。type 表示变更类型scope 表示影响范围subject 是一句话描述。我自己常用的 type 就那几个feat表示新增功能fix表示修 bugrefactor表示重构但不改变行为style表示格式调整perf表示性能优化test表示测试相关docs表示文档变更chore表示构建工具或杂项build表示构建系统相关ci表示持续集成配置变更。别贪多挑几个高频的记熟就够了剩下的交给 AI。这套规范最大的价值不是让每个信息看起来工整而是让提交历史具备了机器可读性。基于这个格式可以用工具自动生成 changelog可以快速筛选出某个版本里所有新增功能也可以让git bisect的定位效率更高。我特别看重这个“可自动处理”的属性因为人力维持的规范总会松动代码层面的约定才靠得住。2.3 用 .cursorrules 把偏好写进项目Cursor 支持项目级别的规则文件放在项目根目录文件名必须是.cursorrules。这个文件里的内容会被作为项目上下文的一部分在每次对话时生效。我在这里干的是一件事把团队的提交偏好写进去。下面是我在一个项目里实际用过的.cursorrules文件内容你可以直接参考。# 提交风格约束 - 提交信息使用 Conventional Commits 格式类型限 feat/fix/docs/style/refactor/perf/test/chore/build/ci/revert - 描述使用中文subject 控制在 50 字以内动词开头 - 禁止提交 node_modules、构建产物、.env 文件 - 生成 commit message 前必须先查看 git status 和 git diff - 当一次改动了多个逻辑模块时主动拆分提交不合并 - 不要执行 git push我建议把规则写成分号分隔的简洁命令式不要用大段的散文描述。AI 对短句的遵循率明显高于作文式的规则。特别需要注意“不要执行 git push”这句一定要写在里面因为 Agent 模式下的 AI 调用终端命令时默认会尝试完成任务如果没有约束它可能真的会把 push 一起做了。这个文件还有一个额外好处它进了版本控制之后整个团队都能共享同一套提交习惯。新来的同事只要打开项目Cursor 就会自动读到规则他的提交风格会被不自觉地矫正过来比自己人肉背诵规范靠谱得多。2.4 一份可以直接抄的提交 Prompt 模板规则文件是“软约束”真正决定每次生成质量的是对话里给 AI 的 Prompt。我建议把需求说得具体一点别只丢一句“帮我写个 commit”。下面是我经过多次调整之后固定下来的模板用在不开启 Agent、只让 AI 生成建议内容的场景里。请分析当前项目的 git 改改动 1. 先执行 git status 和 git diff --stat 查看变更概览 2. 再挑选关键文件的 diff 内容读取理解改动意图 3. 按 Conventional Commits 格式生成提交信息 4. 描述用中文subject 不超过 50 字动词开头说明“做了什么” 5. 如果本次改动包含多个逻辑独立的变更分条列出不要合并成一条 6. 只输出建议内容不要执行 git commit 或任何修改操作这里“只输出建议内容”是很关键的一句。它把 AI 限制在了安全范围内。我在早期使用中经常遇到 AI 自作主张直接执行提交命令的情况后来加了这句话并且把它固定写在模板末尾基本就没再出过乱子。你可以在团队内部把这段模板存成通用的片段大家统一使用成本非常低。3. 实操三种把 Cursor 智能 commit 跑起来的方式3.1 动手前先花两分钟检查这几样正式进入操作之前我建议你花两分钟做一个快速自检能省很多后面的麻烦主要是以下几点看一眼.gitignore是否完整特别是node_modules、.env、编译产物这类文件。AI 执行git add .的时候如果.gitignore配得不好它很容易把不该提交的东西带进去。再看一下当前工作区是否有大量无关改动。如果你改一个需求的过程中顺手格式化了整份文件AI 在分析 diff 时会分不清哪些是核心改动、哪些是噪声提交信息也会跟着失真。最后确认.cursorrules文件存在并且内容是你想要的。没有这个文件的话AI 的发挥会比较随机。这个检查环节不是形式主义。我试过一次在.gitignore漏了dist目录的情况下让 AI 自动提交结果它把构建产物全加进去了提交信息写的是“生成最新构建文件”。这种提交一多仓库直接变成垃圾场。所以准备好地基再开工永远是对的。3.2 方式一Chat 生成、人来执行第一个方式最保守也最容易上手。在 Cursor 的 Chat 面板里直接发上面那段模板AI 会读取项目上下文、生成提交信息的建议内容。你要做的就是把它的输出复制到终端自己执行git add和git commit。这个方式对 AI 的模式没有要求普通对话模式就够用。它适合你只是想让 AI 帮忙想一句“人话”而不是真的编辑终端命令的场景也适合你不想让 AI 拿到操作权限的情况。用下来我最喜欢它的一点是AI 输出的内容会被完整保留在对话记录里如果它偶尔生成了一段特别好的提交信息你还可以直接摘出来用到别的地方比如 PR 描述。让我提醒一下就算在这个模式下我也见过 AI 生成的信息里出现“优化了性能”“提升用户体验”这类空泛的话。遇到这种情况直接让它重写要求它基于具体的代码变更来写不要写任何 diff 里看不出来的结论。3.3 方式二Agent 全流程自动提交要在 Cursor 里做到真正的“智能 commit”还是得开 Agent 模式。开启之后AI 可以在你的授权下执行终端命令包括git status、git diff、git add、git commit这一整套动作。我的推荐流程是分四步走每一步都睁大眼睛看。第一步输入“请先执行 git status看看当前工作区有哪些改动用中文简短汇报”。让 AI 先把变更清单列出来它会返回哪些文件是修改、哪些是新文件、当前在哪个分支。第二步输入“再看一下 git diff --stat然后读取核心文件的 diff理解改动意图”。这一步是为了让 AI 不只看文件名而是真正读到代码内容理解改了什么逻辑。第三步把前面那份模板发过去要求“按模板生成提交计划不要执行命令”。AI 会输出几条建议的提交信息可能还会附上它计划添加的文件列表。这个列表是你最后的机会如果它想加的文件不对直接指出或者要求它只选择哪些文件。第四步确认无误后说“按照第一条提交计划执行使用 git add [指定文件]然后 git commit -m 提交信息”。AI 会逐条执行命令终端里会输出实际执行结果。你在旁边看着核心文件被加入暂存区后才放行。这四步看起来有点繁冗实际熟练了也就两分钟。但每一步都有明确的信息确认节点安全性比让 AI 一把梭高很多。经过这个过程生成的提交信息基本是你可以直接放到 PR 里的水平。3.4 方式三多逻辑变更的拆分提交第三种方式解决的问题是“一次改动里混了多个逻辑”。举个例子你在同一个分支里修了一个 bug又顺手把某个大函数拆成了两个小函数还加了一个新的测试用例。这三个阶段其实是三个逻辑原则上应该拆成三个提交。可传统流程里很多人直接git add -A一把提交历史记录里就出现一条信息写着“修复问题和重构函数”未来想单独回溯 bug 修复就难了。在 Cursor 里你可以在 Prompt 里明确要求它“先拆分提交计划”。给我经常用的表述是请根据本次 diff 的逻辑划分提交每个提交只包含一个逻辑主题先输出提交计划包括每个提交包含的文件和 message我确认之后再逐个执行。AI 返回的计划通常会长成这样提交一修 bug相关文件是 A 和 B提交二做重构相关文件是 A 和 C提交三新增测试相关文件是 D。注意同一个文件可能出现在多个提交里因为 AI 是按逻辑圈不是按文件圈的。如果你的工具不能支持同一文件分 hunk 提交这一步可能需要你手动干预把某些文件的改动先暂存后再让 AI 处理剩余部分。这种情况处理起来有些麻烦但至少 AI 已经把拆分建议给你了你只需要执行偏移部分。3.5 和 commitlint、Husky 配合起来更稳AI 生成的提交信息再有道理也得有校验机制兜底否则规范和实际执行之间会逐渐脱节。我在项目里接入了 commitlint 加 Husky 的组合。Husky 负责在 pre-commit 或 commit-msg 阶段挂 git hookcommitlint 负责检查提交信息是否符合规范。这套组合和智能 commit 并不冲突。AI 生成的 message 照样要走 commitlint 校验如果格式不合规提交会被拦截下来你拿报错回给 Cursor让它按规则重写就行。每次被拦截一次你其实就多了一个对齐规则的机会。等到 AI 对.cursorrules和 commitlint 的 config 文件已经很熟悉这种拦截会越来越少。需要留意的是commitlint 默认规则集中在type-enum、subject-case这些字段上默认可能要求 subject 全英文或特定格式这跟中文提交描述有冲突。你需要在 commitlint config 里明确允许中文并关闭大小写校验不然你会被一堆“subject 必须小写”的报错烦死。4. 用了一个月之后踩的坑和排查实录4.1 高频问题与解决办法速查表下面这张表是我在实际使用中整理出来的问题清单每个都踩过或者亲眼见过解决办法都已经验证过。问题可能原因解决办法AI 把 dist、node_modules、.env 加进了提交.gitignore 不完整或 Agent 执行了 git add .完善 .gitignore在 Prompt 里明确“只 add 指定的关键文件”提交信息写成长篇大论像一篇文章Prompt 里没限制长度AI 默认喜欢展开描述增加“subject 不超过 50 字不要写 body”的限制提交信息中英文混杂读起来很怪没有在规则里指定语言AI 可能受代码注释语言影响在 .cursorrules 和 Prompt 里都注明“使用中文描述”提交之后才发现漏了一个文件AI 只看了一部分 diff或者文件没被 git status 显示先让 AI 跑 git status 并明确列出“所有待提交文件”确认后执行一个提交里混了新增、修复、重构三件事没有明确要求拆分逻辑用拆分提交那个 Prompt先让 AI 输出计划再执行AI 生成的信息里出现“优化性能”等空话AI 根据代码表象脑补了 diff 里没有的结论要求它“只描述代码实际改变了什么不做价值判断”AI 执行 git push 了权限未收敛在 .cursorrules 固定写“不要执行 git push”提交后自己 push提交失败提示已存在同名 message 或文件冲突分支切换、stash 操作等因素让 AI 先 git status 和 git log --oneline -5看清当前状态再决定4.2 几条用一个月才换来的心得第一永远让 AI 先输出计划再执行。这是我在一次实际使用中损失最小但教训最大的一次。当时我在一个分支上做性能调优改到了不耐烦的程度就一股脑让 Agent“提交所有改动”。结果它把我一个临时调试用的本地日志输出文件也一起提交了。虽然用git reset --soft HEAD~1可以救回来但整个过程既狼狈又浪费时间。从那以后“先计划后执行”成了我的硬性规则。第二生成的提交信息里凡是让你感觉“不太确定”的表述大概率是 AI 脑补的。有一次它写了一句“重构了订单模块的状态管理”我点开 diff 发现其实只是给一个函数加了两个默认参数这算什么重构呢AI 倾向于把事情说得更有分量。你需要做的是只保留对代码实际变化的安全描述把虚词删掉。第三不要把智能 commit 当成一个“省掉思考”的黑盒而是当成一个“帮你想清楚改动逻辑”的白板。每次 AI 生成的拆分计划出来我会问自己我真的想先做这个提交吗这个提交放在历史里别人能看懂吗这个过程本身就是一次 code review。5. 从智能 commit 延伸出去的能力5.1 让 AI 从“写提交”到“写 PR 描述”一旦你习惯了让 AI 基于 diff 生成描述延伸能力几乎是水到渠成的。我现在打开 PR 之前会先让 Cursor 基于当前分支相对主分支的提交记录生成一份 PR 描述草稿包括这次改动的背景、关键实现、测试情况和可能影响的范围。因为提交信息是结构化、规范化的AI 梳理这些提交时准确性比直接从一坨乱码状的 message 里猜要高得多。如果提交历史里混着“update”“修复乱七八糟”这种垃圾信息AI 再聪明也很难写出靠谱的 PR 描述。反过来只要提交历史是干净的、语义化的PR 描述就只是把这些信息重新组织一遍而已。这也是为什么我坚持用 Conventional Commits 的原因之一它在为下游所有环节提供高信噪比的“原料”。5.2 把智能 commit 的规则同步给 CI 校验规则的稳定性最终要靠机器校验来守住。在前面讲到的 commitlint 之外我还建议把 Husky 配置也放进仓库的版本控制里让每个开发者拉下代码之后就自动生效。这样即使有人不用 Cursor他的提交信息也会被同样的规则约束。这个思路和侧重点在于把“人遵守规范”变成“流程强制规范”智能 commit 负责降低写规范信息的门槛CI 负责守住底线。我见过一些团队在推进提交规范时起过争执原因无非是“写规范信息太费事”。智能 commit 恰恰解决了这个最大的阻力让 AI 帮你组织语言、帮你拆分逻辑整个过程中人的精力只花在判断“对不对”上而不是从零开始思考“怎么写”。当提交信息变得好写之后规范本身就不再是负担。5.3 最后再安利一个小习惯我强烈建议你把提交模板做成 Cursor 的自定义 snippet 或者一段保存好的 Chat 常用文本保证每次发起对话都是同一套格式。别看这只是一个习惯它会让你的提交风格高度稳定AI 也不会因为不同措辞而跑偏。如果你之前一直觉得 git 提交历史只是个记录不影响代码质量那你可以试着做一个实验花一天时间把每一次提交都说清楚“为什么”和“做了什么”再用智能 commit 把这件事自动化。几天之后你再回头看历史你会第一次发现原来提交信息写清楚的感觉这么好。我现在已经基本不自己手敲 commit message 了但每一步我都会盯着看一遍。它最大的价值并不是省下写 message 的那几十秒而是逼着我去重新审视一次我到底改了什么、应该怎么表达改动的边界。这个习惯一旦形成提交历史会变成团队里最被低估的资产。