我花了两天时间把“VSCode Commit AI——智能生成提交信息”这套东西完整跑通了。先说说这玩意儿到底解决什么问题过去每次写完代码最痛苦的不是写逻辑而是站在终端前盯着git diff憋半天想不出来这条commit message该怎么写。尤其是重构完一片代码改了十几个文件最后打出一句“update file”交差——过俩月自己都看不懂当时改了什么。把改动内容交给AI让它基于diff生成规范、清晰的提交信息再把结果回填到VSCode的提交框里这套流程就是VSCode Commit AI的核心价值。这套方案适合所有人被提交信息折磨的独立开发者、想统一团队提交规范的工程负责人、每天在中文和英文提交信息之间反复切换的人甚至完全没接触过AI编程的新手。只需要在VSCode里装个扩展或者在终端跑一个脚本把git diff交给大模型就能拿到一条结构标准、内容明确的commit信息。接下来我从方案选型、核心原理、实操落地和踩坑记录四个维度把这个项目完整拆给你。1. 这个项目到底解决什么问题1.1 天天写commit信息到底烦在哪git commit这件事看起来是个小事但真要较真痛点多得数不过来。第一类是“不知道写什么”。改动一多人脑根本没法瞬间归纳出“这一版到底做了什么”。比如改了一个支付模块顺手优化了日志格式又删了两个废弃接口还调了一下数据库索引这应该怎么写写“fix payment bug”太窄写“update”等于没写写“优化支付模块并清理代码”又觉得不够精确。这一想就是两分钟每天想两三次一个月就浪费掉两个小时。第二类是“写了跟没写一样”。团队里总会有人用“update”、 “fix”、 “modify”这种词凑数等三个月后要git blame回查问题时看到这些提交信息头皮直接发麻——完全不知道那个commit动了哪些文件、为什么这么改。Commit信息本质上是一种开发文档写得越差后面维护的人越痛苦。第三类是“团队规范没法落地”。很多团队都要求commit信息带type前缀比如feat、fix、refactor。但人记性不是保靠的写着写着就忘了或者把“fix”写成“fixed”把“feat”写成“feature”看得人强迫症都要犯了。你要是去逐个提醒比自己做一遍还累。第四类是“中文和英文的切换成本”。有些开发者习惯写中文提交信息但开源项目或国际化团队又要求英文每次都要在脑子里把中文翻译成英文再写出来句式还不一定地道。这些都是每天都会遇到的实在问题并不是矫情。1.2 方案选型为什么我不推荐一上来就自己写聊完痛点很多人第一反应是这事儿不是已经有现成插件了吗是的VSCode插件市场里确实有AI Commit、Commit Message AI这类扩展但它们的短板同样明显。大多数这类扩展都绑定特定云厂商的API你要先去注册账号、拿到API Key才能用有些扩展的生成质量完全取决于厂商选的模型遇到模型理解能力差的时候会给你的点击按钮生成一句“Refactor code structure.”这种看似正确、实际上什么都没说的信息还有些扩展只支持英文输出对中文用户非常不友好。更关键的是你没法自定义prompt模板也就是说你没法告诉模型“我们团队要求用gitmoji”、“subject要用动词开头”、“正文要带上关联的issue编号”——这些需求只有自己动手才能满足。那为什么我不建议所有人在第一步就自己写扩展呢因为如果你只是个人使用对定制需求不强直接用一个现成插件可能10分钟就够了。自己写扩展这件事虽然实际难度没那么高但毕竟要初始化项目、调VSCode API、处理Git输出这对纯前端或者纯后端的开发者来说是一个完全陌生的领域。所以我的建议是先用最简单的方式把流程跑通等你觉得“这里我想改一下”的时候再动手自己写。我下面会把两条路都讲清楚按需选择就行。另外如果你已经装了Claude Code、Kimi这类带自定义slash command的AI编程工具其实连扩展都可以不写直接给AI一个“生成git commit信息”的指令模板让它执行git diff命令并分析输出结果这也是一条可以落地的路。但这样做的问题是生成结果只停留在聊天窗口里你还要手动复制粘贴到提交框离“一键”还有距离。VSCode Commit AI的价值恰恰是把“分析diff - 生成信息 - 回填提交框”这三步在原生的Git面板里闭环串起来。2. AI生成Commit信息的核心原理拆解2.1 一条Commit消息的完整生成链路不管用什么方案实现VSCode Commit AI背后的基本原理都是相通的把diff文本作为上下文交给大模型模型理解修改内容后按指定格式输出commit message。整个链路拆开来看是下面这六步。第一步是获取diff。这里要区分一下是提交暂存区的内容还是工作区的内容。如果你先执行了git add就可以用git diff --cached拿到已经暂存但尚未提交的改动如果没有执行add则要用git diff HEAD拿工作区相对上一个提交的改动。我个人的习惯是先add再生成信息这样提交的内容完全可控而且diff里的内容就是真正要提交的东西避免把不想提交的文件也塞进上下文。获取diff这条命令在扩展里用child_process执行在CLI脚本里用subprocess执行本质上都一样。第二步是预处理。这一步很多人会忽略但它恰恰是最影响生成质量的环节。原始git diff里包含大量噪音二进制文件打出来的内容完全没法读几百个文件的diff放到模型里上下文窗口会被撑爆中文文件名和内容如果编码处理得不对模型拿到的是乱码。所以我会对diff做三件事过滤掉二进制文件按改动文件数决定是否截断只保留每个文件的前后几十行改动把diff按文件路径和改动行数做一个摘要塞到prompt开头让模型快速掌握整体范围。第三步是组装prompt。这是整个生成流程里最核心的一步我单独在下一小节展开讲。第四步是模型推理。模型的选择决定了成本、速度和隐私边界。如果项目代码全都在本地或者公司对代码安全要求很高建议用Ollama跑一个本地模型比如qwen2.5-coder这个量级的模型完全够用而且彻底杜绝代码外泄。如果只是个人项目、对生成质量更看重可以直接调云端API速度更快、理解能力更强但要把diff内容发送到外部服务——这一点一定要提前跟公司安全同事确认清楚。第五步是规则校验。模型输出不一定每次都完美总有时候会给你带个markdown代码块或者多输出一行解释文字。我会用一个正则表达式去校验输出是否符合type(scope): subject这个格式如果不符合就重新生成一次或者退化成从输出里强行提取第一行。这一步看着不起眼但能避免很多“模型明明生成了但格式乱七八糟”的尴尬情况。第六步是回填。如果是VSCode扩展就把生成好的信息写入SCM输入框或者复制到剪贴板再模拟粘贴如果是CLI脚本就直接把信息拼成git commit -m命令执行。到这一步整个流程才算真正闭环。2.2 Prompt模板才是灵魂大模型生成commit信息这事看起来好像是模型的功劳但实际上真正决定质量的是你的prompt模板。同一个diff用“请生成一条commit message”和用一套设计良好的模板去生成结果完全不在一个水平线上。我先把这个项目里一直在用的模板贴出来你可以直接抄你是一名资深工程师负责为代码库生成规范的Git提交信息。 请基于下面的git diff生成符合Conventional Commits规范的提交信息。 type只允许使用以下枚举值之一: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert 输出格式要求: type(scope): subject 如果改动跨多个模块scope取影响最大的模块名。 硬性要求: 1. subject不超过50个字符不要加句号结尾 2. 描述必须精确禁止使用update、modify这种泛泛的动词 3. 不要编造diff里不存在的文件路径或功能 4. 只输出提交信息本身不要加代码块标记不要加解释 5. 全文用中文技术名词保留英文 以下是示例 输入diff包含修改登录接口的验证逻辑 feat(auth): 增加手机号格式校验 输入diff包含删除废弃的导出函数 refactor(exporter): 清理废弃的导出函数 以下是要分析的diff {DIFF}这个模板看起来不长但每个部分都有它的用意。枚举type的作用是约束模型的输出范围让结果严格符合Conventional Commits规范同时避免它自创type比如“improve”。输出格式要求直接把结构写死不给模型自由发挥的空间。硬性规则里的第2条最关键——大模型天生倾向于输出“optimize code”、“update files”这类废话你必须在prompt里明确禁止否则它就会用这种万金油句子糊弄你。示例部分是为了告诉模型“你想要的输出长什么样”这叫few-shot比纯文字规则有效得多。第4条也要特别注意我见过很多模型喜欢把结果包装在markdown的代码块里如果你后面的程序不做清洗提交信息就会变成一行带反引号的垃圾。在实际使用过程中我发现temperature这个参数也需要单独调。生成commit信息本质上是抽取和总结不是创作所以温度要调低一般设在0.2到0.4之间。设太低模型会变得机械设太高就容易发挥过头生成一些“fix: 修复了若干历史遗留问题并优化了用户体验”这种假大空的话。另外模型的选择也会影响最终效果我自己用下来普通闲聊型模型在提取diff改动点时经常抓不住重点建议尽量用代码能力较强的模型无论是本地还是云端都是这个原则。2.3 生成结果的常见质量问题和规避思路把流程跑通之后你会发现AI生成commit信息最大的问题不是“不会生成”而是“生成的太笼统”。我拿同一个diff做过测试用最简单的一句话prompt模型输出的是“优化代码结构修复一些问题”用我设计好的模板同一个模型输出的是“refactor(auth): 抽取token校验逻辑为独立工具函数”。差距就是这么明显。还有一个常见问题是“过度总结”。模型基于diff里的信息会脑补出一些根本不存在的改动意图。比如你只是删了一个未使用的import它可能写“优化依赖管理提升代码可维护性”。这种提交信息看起来漂亮但严格来说是在撒谎。解决方案还是回到prompt上明确要求它只能描述diff里真实出现的改动同时我还会在生成后加一道人工检查步骤这也是我在后面会提到的使用习惯。把这两件事做好了生成质量基本就能稳定在“可直接提交”的水平。3. 实操VSCode Commit AI的三种落地方式3.1 五分钟方案先跑通现成插件再谈定制如果你不想自己写代码直接用现成插件把流程跑通这一步只需要五分钟。打开VSCode在扩展市场里搜索“AI Commit”或者“Commit Message AI”挑一个下载量比较大、维护日期比较近的插件安装就行。装好之后大多数插件会在设置页提供一个API接口配置项你填上自己购买的云端模型API地址和Key然后在git面板里点一个“生成提交信息”的按钮它就会自动帮你把diff分析完写好你确认没问题再点击提交。我对现成插件只有一个忠告配置生成引擎时优先选代码能力强的模型不要选那些过于通用但便宜到离谱的廉价模型。这个场景对模型的理解能力要求很高你给它看的是大段大段的diff代码模型必须能判断哪些改动是核心逻辑、哪些只是格式调整这个能力不是所有模型都具备的。如果一开始生成质量不满意更换配置里的模型再试一次往往比反复调prompt更有效。这种方案的优点在于零开发成本、开箱即用适合个人开发者快速提效。缺点也比较明显插件内部的prompt模板是写死的你没法指定“必须用中文”、“必须带gitmoji”而且核心的diff预处理逻辑也不透明遇到一些大仓库或复杂diff插件可能直接就超时了。如果你只是自用可以长期停留在这一步不用自己折腾。3.2 动手方案写一个最小化的VSCode扩展当你开始觉得现成插件“不够味”想完全按照自己的习惯来定制时就可以动手写一个自己的VSCode扩展了。这个事真没想象中那么复杂我基于这个项目写过一个最小版本核心代码不超200行。下面把关键流程和代码都贴出来你可以直接照着做。先准备环境需要Node.js和VSCode的命令行工具yo code。在空目录里执行npx yo code选择“New Extension”语言选TypeScript项目就初始化好了。之后的核心工作集中在src/extension.ts这个文件。整体逻辑分三块拿diff、调模型、回填提交框。import * as vscode from vscode; import { execSync } from child_process; function getGitDiff(): string { // 获取当前暂存区的改动如果没暂存则取工作区改动 const cmd git diff --cached HEAD; try { return execSync(cmd, { encoding: utf-8, maxBuffer: 20 * 1024 * 1024 }); } catch (e) { // 处理没有暂存内容的情况 return execSync(git diff HEAD, { encoding: utf-8, maxBuffer: 20 * 1024 * 1024 }); } } function buildPrompt(diff: string): { role: string; content: string }[] { const template 你是资深前端工程师...这里放上一节写好的模板; return [ { role: system, content: 你只负责生成git提交信息不回答其他问题。 }, { role: user, content: template.replace({DIFF}, diff.slice(0, 8000)) } ]; } async function callLLM(diff: string): Promisestring { const config vscode.workspace.getConfiguration(commitAi); const apiUrl config.getstring(apiUrl) || http://localhost:11434/v1/chat/completions; const model config.getstring(model) || qwen2.5-coder:7b; const messages buildPrompt(diff); const resp await fetch(apiUrl, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model, messages, temperature: 0.2 }) }); if (!resp.ok) throw new Error(API请求失败: ${resp.status}); const data await resp.json(); return data.choices[0].message.content.trim(); } export function activate(context: vscode.ExtensionContext) { const disposable vscode.commands.registerCommand(commit-ai.generate, async () { try { const diff getGitDiff(); if (!diff.trim()) { vscode.window.showInformationMessage(没有检测到任何改动无法生成提交信息。); return; } const message await callLLM(diff); // 将生成结果写入剪贴板并提示用户手动粘贴到SCM输入框 await vscode.env.clipboard.writeText(message); vscode.commands.executeCommand(workbench.scm.focus); vscode.window.showInformationMessage(commit信息已复制到剪贴板直接粘贴到提交框即可。); } catch (e: any) { vscode.window.showErrorMessage(生成失败: e.message); } }); context.subscriptions.push(disposable); } export function deactivate() {}代码里有一个地方值得重点说往SCM输入框里回填内容其实没有官方API可以直接setValue目前比较稳妥的做法是复制到剪贴板然后聚焦到源代码管理面板让用户手动粘贴。这个操作在自动化和人工确认之间找到了一个平衡点也给了用户检查生成结果的机会不是什么坏事。代码写完后在package.json里配置命令和菜单项{ contributes: { commands: [ { command: commit-ai.generate, title: Commit AI: 生成提交信息 } ], configuration: { title: Commit AI, properties: { commitAi.apiUrl: { type: string, default: http://localhost:11434/v1/chat/completions }, commitAi.model: { type: string, default: qwen2.5-coder:7b } } } }, activationEvents: [onCommand:commit-ai.generate] }配好之后按F5VSCode会打开一个“扩展开发宿主”窗口在里面随便改点代码然后通过命令面板执行“Commit AI: 生成提交信息”就能看到完整效果了。我第一次跑通这个流程的时候说实话挺有成就感的——虽然代码总量很小但它确确实实解决了我的真实痛点。之后你随时可以改prompt模板、加上对特定语言的适配、增加自定义type列表这个工具就变成完全长在你手上了。3.3 轻量方案不想碰扩展开发就用CLI脚本写VSCode扩展对很多人来说还是一个门槛如果你只是想要一个命令行工具每次在终端里跑一条命令来生成commit信息那直接用一个Python脚本就够了。下面是这个项目里配合用的一个简化版CLI脚本依赖requests库调用任何OpenAI兼容的API都能工作。import os import subprocess import sys import requests DIFF_TRUNCATE_LIMIT 8000 PROMPT_TEMPLATE 你是一名资深工程师负责生成Git提交信息。 请基于以下git diff输出一条符合Conventional Commits规范的提交信息。 要求type限定为feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert 格式为type(scope): subjectsubject不超过50字符 必须基于diff真实改动来写禁止编造只输出信息本身不要额外解释。 指定语言中文。 diff内容如下 {DIFF} def get_diff() - str: result subprocess.run( [git, diff, HEAD], capture_outputTrue, textTrue, encodingutf-8, ) if result.returncode ! 0: sys.exit(git diff执行失败请确认当前目录是一个git仓库) return result.stdout def generate_message(diff: str) - str: api_base os.getenv(COMMIT_AI_API_BASE, http://localhost:11434/v1) model os.getenv(COMMIT_AI_MODEL, qwen2.5-coder:7b) api_key os.getenv(COMMIT_AI_API_KEY, ollama) payload { model: model, messages: [ {role: system, content: 你只负责生成git提交信息。}, {role: user, content: PROMPT_TEMPLATE.format(DIFFdiff[:DIFF_TRUNCATE_LIMIT])}, ], temperature: 0.2, } resp requests.post( f{api_base}/chat/completions, headers{Authorization: fBearer {api_key}}, jsonpayload, timeout60, ) resp.raise_for_status() return resp.json()[choices][0][message][content].strip() if __name__ __main__: diff get_diff() if not diff.strip(): sys.exit(当前工作区没有任何改动) msg generate_message(diff) print(生成结果) print(msg) # 如果你想直接提交取消下面两行的注释 # subprocess.run([git, add, .]) # subprocess.run([git, commit, -m, msg])这个脚本的用法也简单把环境变量配好直接python commit_ai.py就能跑。关键在于DIFF_TRUNCATE_LIMIT要在外层做一次截断这是为了防止巨型差异把模型上下文撑爆、白白烧掉token。CLI方案还方便以后扩展别的功能比如生成release notes、按文件分组生成多条commit等都只是在这个脚本基础上改一改的事。3.4 把“为什么不自己写扩展”这个判断再展开一点有些读者会问既然准入门槛不高是不是所有场景都适合自己写我个人的判断标准其实很朴素如果你只在意“能不能生成”去用现成插件如果你在意“生成出来长什么样”就自己写。因为这个项目的核心本质上是prompt工程而prompt是跟个人习惯强绑定的。我喜欢中文、喜欢type用中文注释我同事喜欢gitmoji我另一个朋友要求每条commit都要带上JIRA单号——这些需求没有哪家现成插件能同时满足。自己写本质上是把“工具”变成“你的工具”。4. 踩坑记录与排查技巧实录4.1 我踩过的六个坑第一个坑是git diff里的中文乱码。默认情况下git对中文文件名会做转义显示成\347\224\273这种八进制序列同时如果系统locale不是UTF-8diff里的中文内容也会变成乱码。我第一次跑的时候模型把乱码当成了正常内容生成的提交信息里带着一串奇怪转义符非常尴尬。解决办法是在执行git命令前设置环境变量LANGzh_CN.UTF-8同时执行git config core.quotepath false让中文路径直接显示这样diff内容的质量才算可读。第二个坑是diff太大把上下文直接撑爆。我测试过一个改动特别多的分支diff有十几万行直接请求接口返回上下文长度超限。后来我加了两层防护第一层是按文件数量做截断超过20个文件就只保留修改行数最多的前20个第二层是对单个文件的diff内容做截断每个文件最多保留前后各100行。这两层防护下来基本能把单次请求的token控制在可接受范围同时又不丢失核心改动信息。第三个坑是模型的输出格式漂移。你明明在prompt里写了“只输出一行提交信息”它偶尔还是会给你输出两行或者带个冒号开头、带个代码块。这个问题靠prompt不能完全根除还是得加一层代码校验兜底。我会写一个正则判断输出的第一行是否匹配^[a-z](\(.\))?: .不匹配的时候就再调一次接口二次结果再不行就直接把内容原样抛给用户不做处理了。第四个坑是模型编造不存在的改动。模型在理解diff的时候偶尔会延伸出一些它觉得“合理”但实际上不存在的描述。比如diff里只是修改了一个函数的缩进它生成了“优化了函数的执行逻辑”。这种问题在生成结果里最容易骗过人眼因为看着太顺畅了。后来我在prompt里补充了一条硬性规则“你只能描述diff中出现的具体改动禁止概括性总结和推测”生成的虚词明显变少了但完全保证不了。所以我现在在使用习惯上生成完一定自己扫一眼不直接无脑提交。第五个坑是VSCode API没法直接往SCM输入框写值。这个在3.2里已经提到当时我搜了一圈没看到官方支持最后只能用剪贴板加聚焦的方式绕过。后来我发现还有个思路用commands.executeCommand(workbench.view.scm)聚焦源代码管理视图后直接模拟键盘输入但相比剪贴板方案并没有本质优势反而多了一个模拟按键的依赖。所以最终我留在剪贴板方案。第六个坑是扩展里执行git命令时找不到git。VSCode扩展运行在扩展宿主进程中它的PATH环境变量跟你的普通终端不完全一样有时会出现command not found: git。这个不是git没装而是PATH里没有。解决方法是读git.executable这个设置项或者在调用execSync时显式指定shell: /bin/bash并把git的安装目录加进PATH。这个坑在Mac上尤其常见因为很多人的git是Homebrew装的路径是/opt/homebrew/bin/git。4.2 常见问题速查表上面说的坑比较具体我再把日常使用中最高频遇到的问题整理成一个速查表方便你遇到情况直接照着排查。问题现象可能原因解决办法command not found: git扩展宿主进程PATH不包含git设置VSCode的git.executable路径或在代码中显式指定shell路径username and email must be set before commit本地git仓库未配置用户信息执行git config --global user.name 你的名字和git config --global user.email 你的邮箱生成结果全是英文模型默认用训练语料里的英文输出在prompt里加一条“回复语言中文”的硬性要求生成结果带了markdown代码块模型受到外部对话习惯影响在prompt里禁止markdown并在代码里对输出做清洗生成为空或直接报错工作区没有改动或diff为空检查是否执行过git add确认改动文件存在请求超时或上下文长度超限diff过大超出模型窗口按文件数和单文件行数做截断或换一个上下文更大的模型生成的type不是规范枚举模型自由发挥在prompt里限定type枚举并加正则校验兜底生成信息跟实际改动不符模型过度总结或幻觉明确要求只描述diff出现的具体改动生成后人工快速审核中文乱码或文件路径被转义git的quotepath和系统locale问题执行git config --global core.quotepath false设置LANGzh_CN.UTF-8调用API时提示401API Key错误或未设置检查环境变量COMMIT_AI_API_KEY确认Key有效且账户没有欠费还有一个值得一提的细节是如果你用完git commit --amend发现刚才的提交信息写错了想用AI重新生成一版再修正流程是完全兼容的。因为--amend只是把上一次提交的message换掉并不会影响工作区的diff。我现在的习惯是先正常commit一次review历史的时候觉得信息写得不好再在命令行调用一次CLI脚本生成新信息然后用git commit --amend -m 新信息覆盖上去。这样既享受了AI的效率又给了自己一个兜底的修正手段。5. 进阶玩法与个人经验总结5.1 让提交信息更有质量的几个小技巧用了一段时间之后我总结出几个让commit信息质量再上一个台阶的小技巧这些是正经文档里不会提到的。第一个技巧是同style的diff放到同一个commit里。AI最适合总结的是“单一意图”的改动如果一次提交里混着功能开发、格式调整、依赖升级生成出来的信息就会变得又长又乱。我现在会在git add的时候有意识地按模块分开暂存然后分别生成commit信息这样AI的生成质量和最终log的可读性都会高出很多。理论上讲这只耽误你一两分钟但对三个月后的代码考古帮助巨大。第二个技巧是给prompt加团队规范上下文。如果你在一个团队里每天review的commit信息格式五花八门与其在code review时逐一纠正不如把你们的规范直接写进prompt。比如你们要求“feat后方括号标注模块”或者“每个commit必须带issue编号”这些都可以在模板里变成一个硬性规则。本质上这就是把团队规范从口头传导变成了工具约束效率高得多。第三个技巧是在生成之后再加一轮“改写”调用。格式规范的信息不一定通顺有时模型生成的信息虽然结构没问题但读起来就是很生硬。我试过用一个“优化器”角色对生成结果做二次润色先把第一次生成的信息作为输入再要求模型在不改变type、scope的前提下把subject写得更加精简准确。这不一定会提升每次的信息质量但当你需要提交一条特别重要的commit信息时这轮改写确实能明显改善句子观感。5.2 这个项目还能怎么扩展VSCode Commit AI本身只是起点顺着它往宽度扩展能延伸出不少实用工具。我自己在规划的有这么几个方向。一个是自动生成release notes。提交信息本质上就是项目变更日志的原始素材如果commit信息都能按Conventional Commits规范生成那完全可以写一个脚本从git log里按type筛选出feat和fix自动拼出一份release notes草稿。这比到了发版节点再花半小时回忆要准确得多。另一个方向是把AI生成的commit信息用于自动创建PR描述。很多团队用Gitea、GitLab这类平台创建PR时经常要手动把commit列表复制一遍。如果你已经让AI分析过diff那这个分析结果可以直接扩展成PR描述连“改了哪些模块、影响面在哪、怎么测试”都让模型一并写出来然后通过API自动填到PR模板里。还有一个值得关注的方向是给prompt加“记忆”。比如让模型记住你之前提交信息的风格或者记住这个项目的模块划分再生成新信息时参照历史风格来写。这一步可以通过在prompt里附带一段你之前commit的示例或者用一个RAG方案来实现。不过说实话这件事的边际效用没有前面几个方向高因为大多数Commit信息的风格差异都不大最重要的还是完整和准确。我从最开始抱着试一试的心态跑通这条链路到现在每天都用它辅助提交代码前后也就一周时间。这套东西的代码量不大但收益几乎是立竿见影的。如果你也想试一试我的建议是先别急着写扩展按3.1的方法用一个现成插件把流程跑通感受一下“改完代码不用想提交信息”是什么体验。等哪天你觉得“这里不符合我的习惯”了再回来照着3.2或3.3的代码抄一份改个prompt模板五分钟之后它就完全变成属于你的工具了。