企业官网建设流程全解析

最近我的 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、规范与 .cursorrules

2.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表示修 bug，refactor表示重构但不改变行为，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 hook，commitlint 负责检查提交信息是否符合规范。

这套组合和智能 commit 并不冲突。AI 生成的 message 照样要走 commitlint 校验，如果格式不合规，提交会被拦截下来，你拿报错回给 Cursor，让它按规则重写就行。每次被拦截一次，你其实就多了一个对齐规则的机会。等到 AI 对.cursorrules和 commitlint 的 config 文件已经很熟悉，这种拦截会越来越少。

需要留意的是，commitlint 默认规则集中在type-enum、subject-case这些字段上，默认可能要求 subject 全英文或特定格式，这跟中文提交描述有冲突。你需要在 commitlint config 里明确允许中文，并关闭大小写校验，不然你会被一堆“subject 必须小写”的报错烦死。

4. 用了一个月之后踩的坑和排查实录

4.1 高频问题与解决办法速查表

下面这张表是我在实际使用中整理出来的问题清单，每个都踩过或者亲眼见过，解决办法都已经验证过。

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 的那几十秒，而是逼着我去重新审视一次我到底改了什么、应该怎么表达改动的边界。这个习惯一旦形成，提交历史会变成团队里最被低估的资产。