你有没有过这种经历代码写完了、测试也过了准备 git commit 的时候手指悬在键盘上半天下不去憋了半天只想出一句“修改代码”。提交信息这件事日常开发里看着不起眼可真等到版本回溯、代码评审、自动生成 changelog 的时候它的重要性立刻就会冒出来。我最近索性把 AI 变成了自己的“代码秘书”每次 Git 提交前让 AI 自动分析暂存区里改了什么生成规范且有重点的提交信息我再快速核对一遍确认即可。这套方案在真实项目里跑了不少次稳定可靠。我今天把完整方案拆开讲透包括思路、可直接复制的脚本以及过程中踩过的坑特别适合提交频繁、想把提交历史做规范的开发者参考。1. 整体方案设计AI 是怎么当上“代码秘书”的1.1 提交信息看似小事踩坑成本可不低写提交信息这件事很多开发者的态度是“反正代码都在仓库里写不写清楚无所谓”。但真到了协作场景提交信息几乎是代码仓库的“日记”信息量到底够不够直接影响后续所有人排查问题的效率。我说几个特别具体的场景代码评审的时候reviewer 第一眼看的不是 diff 全文而是提交信息。信息写得模糊review 双方要多花好几轮来回确认改动意图。git bisect 定位回归问题时提交信息写得清楚能直接把嫌疑范围缩到一两个 commit写不清楚只能挨个 checkout 试。很多生成 changelog 的工具比如 standard-version、release-please都是靠解析提交信息里的 type/scope 来归类版本变更的信息不规范生成结果就是一团乱麻。git blame 查某行代码来源时提交信息就是“责任人”的自我介绍。那句“更新代码”和那句“修复跨时区订单倒计时计算错误”排查效率完全是两个量级。所以提交信息不是给 git 看的是给人看的。更准确地说是给三个月后的自己和其他同事看的。但人写这东西确实容易崩。刚改完一堆代码脑子里信息量爆棚落笔时往往只写出一句“改代码”。状态切换频繁的时候上一件事还没调干净就切到下一件事提交时根本想不起自己改了什么。最要命的是那种牵扯十几个文件的功能改动自己都不一定能一两句话讲清全貌。AI 恰恰擅长干这种“不嫌烦、不健忘、合稿快”的活。它能把多个文件的差异放在一起总结还能按模板输出统一格式。但必须认清一个边界AI 读得到 diff看不到你没写进代码里的“动机”。所以它的角色是“秘书”不是“老板”——替你起草帮你把关最终定稿还是要人来拍板。这个边界我特别想强调。很多人一开始用 AI 写提交信息会走极端要么觉得 AI 写得太水直接弃用要么全盘照收把 AI 一本正经编出来的“修复了某个问题”提交进仓库。后面要讲的方案会把“人工确认”这个步骤固化在工作流里这正是规避这两个极端的关键。1.2 两条技术路线我选的是“先秘书后签字”围绕“让 AI 写提交信息”这个目标目前业界常见的做法是两种。第一条路线是 Git Hook 自动注入。在.git/hooks/prepare-commit-msg里写脚本每当用户执行git commit时自动把 AI 生成的信息填充到提交信息编辑器里。优点是自动化程度高凡是走git commit都能被覆盖到。缺点也很明显每次提交都要先调用一次大模型接口几十秒的耗时在交互式提交流程里非常尴尬而且一旦 API 超时或报错提交流程直接被卡住用户还一时搞不清问题出在哪。第二条路线是自定义 Git 命令也是我最终采用的方案。把生成提交信息的过程封装成一个命令比如git ai-commit由用户主动触发。脚本先检查暂存区有没有改动再把 diff 发给 AI收到结果后打开编辑器让你确认、修改最后执行 commit。我之前也试过 hook 方案但在线上真实场景里被网络波动整得挺闹心。退回“主动命令 人工确认”之后体验反而稳了不少网络挂了我只是少用一条美化命令不影响正常提交AI 写得不对我在编辑器里顺手改掉再提交。这就像真正的秘书你叫她来帮忙她自然给你准备稿子但你不叫她也绝不影响你正常干活。顺带说一句Git 自身的别名机制天然支持这种“自定义子命令”的玩法。把脚本命名为git-ai-commit并放入 PATHGit 就会自动识别成git ai-commit。这种方式比配置别名更干净命令行为和原生 git 子命令几乎一致。1.3 工具选型模型、脚本语言与 Git 环境模型选择上如果你的项目代码允许出内网直接用云端模型接口最省事如果团队对数据安全比较敏感或者公司要求代码 diff 不允许出内网就上本地模型比如基于 Ollama 跑 Qwen2.5-Coder 或 Llama 系列的小参数模型。两者在接口调用方式上高度相似——不少本地模型服务提供了 OpenAI 兼容的/v1/chat/completions接口所以同一份脚本通过环境变量切换地址就能复用。脚本语言我用 Python。原因很简单尽管 Bash 也能完成任务但要处理 JSON 转义、多行字符串和编码问题时代码很快变得难以维护。Python 在绝大多数开发机上是标配装上 requests 库就能在 80 行内把整个流程串起来。如果你机器上实在不方便装 Python用 Bash curl jq 也不是不行只是后续迭代成本会高一些。Git 版本没有什么硬性要求只要会用git diff --cached、git commit --file就行。现在的 Git 2.x 默认都满足这些条件。Windows 用户需要额外留意控制台代码页和文件编码否则中文提交信息容易乱码这一点后面会专门展开。2. 核心细节拆解Prompt、Diff 与 API 参数怎么调很多人以为把 diff 丢给 AI 就能得到高质量提交信息试了之后发现生成结果是“正确的废话”。问题出在几个核心环节上我一个个拆开讲。2.1 提交信息格式给 AI 定好“文风模板”我的提交信息格式完全沿用 Conventional Commits 规范。这个规范在开源社区和各大公司里已经非常主流没必要自己发明一套。核心格式是type(scope): subject body footertype 是提交类型常见取值为 feat新功能、fix修复、docs文档、style样式/格式、refactor重构、perf性能、test测试、chore维护琐事。scope 是受影响的模块名说明改动落在哪个区域。subject 是一句话主题简洁扼要。body 是正文解释背景、原因和影响。footer 通常放破坏性变更说明或关联 issue 编号。AI 模型并不天然知道你项目要什么格式但只要在 prompt 里把规范讲清楚再给一两个贴合场景的例子输出就会非常稳定。我一开始没给模板让它“自由发挥”结果它给我输出过 Markdown 列表、JSON 结构甚至带表情符号的标题看着花哨实际没法用。后来把模板和约束写死进 prompt提交信息才真正规范化。2.2 Prompt 的写法把“秘书”的要求一次说清楚这是整套方案最核心的部分我直接把当前稳定运行的 prompt 模板放出来你是一名资深软件工程师请根据下面的 Git 差分内容写一条符合 Conventional Commits 规范的提交信息。 要求 1. 第一行格式为type(scope): subject 其中 type 可选值feat, fix, docs, style, refactor, perf, test, chore scope 为本次涉及的主要模块名没有则省略 2. subject 用一句话简洁说明“做了什么”不要超过 50 个中文字符 3. 空一行后用 body 说明“为什么改动”和“影响范围”两三句即可 4. 如果包含破坏性变更在末尾加 BREAKING CHANGE 说明 5. 使用中文编写提交信息 6. 只输出提交信息本身不要输出任何解释、引言、Markdown 代码块标记这里面每条要求背后都有对应的坑第 1 行限定 type 枚举值避免模型自创“update/change/improve”这类没营养的前缀。scope 要求写模块名而不是文件路径是因为模型很容易直接把文件名当 scope提交信息看起来像fix(utils/date.ts)不够提炼。第 3 条是让 body 承担解释“为什么”的职责。很多人写提交信息只写“改了什么”忽略了“为什么这么改”但“为什么”才是三个月后排查问题时最有价值的信息。第 5 条是中文团队实测下来最该写的一条。不写的话模型会依据 diff 里注释的语言甚至训练数据里的统计偏好中英混用提交历史风格直接乱套。第 6 条最关键。没有这条限制模型经常输出“好的根据您的 diff我生成了以下提交信息”这类废话甚至用代码块把信息包起来脚本解析时会把无关文字一并提交进去。2.3 Diff 怎么取、怎么传、怎么截断脚本里取暂存区 diff 就两条命令git diff --cached --stat # 先看改了什么文件 git diff --cached # 拿完整 diff核心是--cached参数它表示“只看已经暂存的内容”也就是git add之后、还没 commit 的改动。这样既符合“提交信息描述本次提交内容”的语义也能在生成信息之前提醒用户“你到底暂存了什么”。很多时候用户以为改了三个文件实际上只 add 了一个看到脚本输出的 stat 清单就能立刻意识到问题。另一个关键点是 diff 截断。一次提交如果改动很大特别是前端项目带 lock 文件或自动生成文件时完整 diff 可能超过上万行。把这么多内容直接塞给模型既浪费 token模型又容易抓不住重点。我的策略是保留前 800 行总行数超过阈值就在 prompt 末尾追加一行“以下 diff 已截断请基于提供的内容总结”。这样既能控制成本也避免超大 diff 导致 API 请求超时。文件类型上也要留意二进制文件在 diff 里只会显示Binary files differ对 AI 没有任何价值。如果项目习惯把构建产物提交进仓库建议先在.gitignore里过滤掉否则 AI 秘书会被大量噪音干扰。2.4 API 参数temperature、max_tokens 和超时策略调用模型接口时有几个参数值得认真设置temperature 控制在 0.2 到 0.4 之间。提交信息属于“格式化输出”类任务太高的随机性会让文案忽好忽坏。我最初用 0.7同一段 diff 每次生成的信息措辞差异很大后来降到 0.3稳定多了。max_tokens 设 300 到 500 就够。一次提交信息撑死了也就几十行给太多 token 反而容易出现模型自嗨追加一堆无关内容。timeout 要设置。我默认设 30 秒模型超时就报错退出不拖着提交流程。你可以根据网络情况和模型速度自行调整。retry 逻辑看网络质量。如果经常偶发超时可以给脚本加一层重试比如遇到 500 错误或超时隔 2 秒重试一次最多三次。我这里网络比较稳定就没加重试避免提交流程被拉得过长。还有一个细节API Key 绝对不能硬编码在脚本里。放到环境变量里是最稳妥的做法后面实操部分会给出完整的环境变量清单。2.5 安全边界AI 能碰的代码和不能碰的代码这里必须单独讲。把代码 diff 上传到第三方 AI 接口本质上是把未发布的源代码暴露给外部服务。个人项目无所谓但公司项目一定要先确认数据安全边界。我见过不少团队自己偷偷接外部 API 写提交信息结果被安全审计查出来轻则下架工具重则影响团队评级。这一点真不是危言耸听。对策分三层第一层公司有授权或项目代码可公开直接用成熟的云端模型体验最好。第二层代码不能出内网用本地模型。Ollama 这类工具把部署门槛降得很低跑一个小参数模型写提交信息完全够用。第三层代码不出内网但本地 GPU 资源紧张可以让 AI 只分析文件清单和关键改动节点而不发送完整代码内容。这样既降低泄露风险又给模型留了足够上下文。任何情况下都不建议把 API Key 提交进仓库也不建议在提交信息里粘贴密钥或敏感路径。AI 生成的信息只是辅助最终落到仓库历史里的内容责任始终在你。3. 实操部署从零搭建 AI 提交助手进入实操环节。目标是让你在二十分钟内把“AI 秘书”跑起来从安装 Git 开始一直到提交助手稳定运行。3.1 环境准备Git、Python 与编辑器Git 安装这件事Windows 用户建议直接官网下安装包或者用包管理器 Chocolatey 安装macOS 用户brew install gitDebian/Ubuntu 用户sudo apt install git。装完先查版本git --version如果你是第一次配置 Git记得先设置用户名和邮箱否则提交时会提示 missing identitygit config --global user.name 你的名字 git config --global user.email youexample.comPython 3 环境大多数系统自带。如果没有装的时候注意别污染系统目录。运行脚本前安装 requests 库pip install requests编辑器方面脚本会读取环境变量EDITOR。macOS 上推荐配成 VS Code 的等待退出模式不然编辑器不会正确阻塞命令行export EDITORcode --waitWindows 上同样推荐code --wait或者用 vim、nano 都行。3.2 编写核心脚本git-ai-commit这是整套方案的骨干。我直接把稳定运行过很长一段时间的完整脚本放出来代码不算长但每一步都考虑到了真实工作流里的异常处理#!/usr/bin/env python3 git-ai-commit让 AI 生成 Git 提交信息人工确认后再提交。 import os import subprocess import sys import tempfile try: import requests except ImportError: sys.exit(缺少依赖 requests请先执行pip install requests) API_KEY os.environ.get(AI_API_KEY, ) API_BASE os.environ.get(AI_BASE_URL, https://api.openai.com/v1) MODEL os.environ.get(AI_MODEL, gpt-4o-mini) EDITOR os.environ.get(EDITOR, vim) MAX_DIFF_LINES 800 PROMPT_TEMPLATE 你是一名资深软件工程师请根据下面的 Git 差分内容写一条符合 Conventional Commits 规范的提交信息。 要求 1. 第一行格式为type(scope): subject 其中 type 可选值feat, fix, docs, style, refactor, perf, test, chore scope 为本次涉及的主要模块名没有则省略 2. subject 用一句话简洁说明“做了什么”不要超过 50 个中文字符 3. 空一行后用 body 说明“为什么改动”和“影响范围”两三句即可 4. 如果包含破坏性变更在末尾加 BREAKING CHANGE 说明 5. 使用中文编写提交信息 6. 只输出提交信息本身不要输出任何解释、引言、Markdown 代码块标记 下面是 Git diff可能被截断 {DIFF} def run_git(cmd): return subprocess.run(cmd, capture_outputTrue, textTrue, checkTrue) def main(): try: stat run_git([git, diff, --cached, --stat]).stdout.strip() except subprocess.CalledProcessError as exc: sys.exit(fgit diff --cached 执行失败{exc}) if not stat: sys.exit(暂存区没有内容请先执行 git add 添加要提交的文件。) diff run_git([git, diff, --cached]).stdout diff_lines diff.splitlines() if len(diff_lines) MAX_DIFF_LINES: diff \n.join(diff_lines[:MAX_DIFF_LINES]) diff \n...diff 已截断 if not API_KEY: sys.exit(缺少 AI_API_KEY 环境变量。) prompt PROMPT_TEMPLATE.format(DIFFdiff) payload { model: MODEL, messages: [{role: user, content: prompt}], temperature: 0.3, max_tokens: 500, } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } print(正在让 AI 生成提交信息...) try: resp requests.post( f{API_BASE}/chat/completions, headersheaders, jsonpayload, timeout30, ) resp.raise_for_status() msg resp.json()[choices][0][message][content].strip() except requests.exceptions.Timeout: sys.exit(调用 AI 接口超时请稍后重试或调大 timeout。) except Exception as exc: sys.exit(f调用 AI 接口失败{exc}) if not msg: sys.exit(AI 返回内容为空已取消提交。) # 让用户看到并主动确认/修改 with tempfile.NamedTemporaryFile( w, suffix.txt, deleteFalse, encodingutf-8 ) as fh: fh.write(msg) tmp_path fh.name try: subprocess.run([EDITOR, tmp_path], checkTrue) with open(tmp_path, r, encodingutf-8) as fh: final_msg fh.read().strip() finally: if os.path.exists(tmp_path): os.unlink(tmp_path) if not final_msg: sys.exit(提交信息为空已取消提交。) with tempfile.NamedTemporaryFile( w, suffix.gitmsg, deleteFalse, encodingutf-8 ) as fh: fh.write(final_msg) msgfile fh.name try: run_git([git, commit, --file, msgfile]) finally: if os.path.exists(msgfile): os.unlink(msgfile) if __name__ __main__: main()脚本逻辑按六个步骤走检查暂存区 → 取 diff 并截断 → 组装 prompt 调 AI → 写临时文件让用户确认 → 读回最终信息 → 执行提交。两个细节值得展开说说。第一个是git commit --file。为什么不直接用git commit -m 信息因为提交信息往往包含多行文本直接塞命令行参数容易出现转义问题或超长命令。先把信息写入临时文件再用--file让 Git 读取是最稳的做法。第二个是临时文件的生命周期管理。我用try...finally保证无论用户是否确认提交、脚本是否报错临时文件都会被清理不会在仓库里留下垃圾文件。3.3 注册命令让 git ai-commit 直接用起来脚本写好后保存到某个目录比如~/bin/git-ai-commit然后加上可执行权限并确保这个目录在 PATH 里chmod x ~/bin/git-ai-commit export PATH$HOME/bin:$PATHGit 有一个约定可执行文件如果命名为git-xxx且在 PATH 中就能直接用git xxx调用。因此保存为git-ai-commit后命令就是git ai-commit为了让 PATH 设置永久生效把export PATH$HOME/bin:$PATH写进~/.bashrc或~/.zshrc。Windows 用户如果在 Git Bash 环境下操作同样适用如果习惯 PowerShell就得写一个git-ai-commit.cmd包装脚本或者干脆在 Git Bash 里用。最后配置环境变量。Linux/macOSexport AI_API_KEYsk-your-api-key export AI_BASE_URLhttps://api.openai.com/v1 export AI_MODELgpt-4o-mini export EDITORvimWindows PowerShell$env:AI_API_KEY sk-your-api-key $env:AI_BASE_URL https://api.openai.com/v1 $env:AI_MODEL gpt-4o-mini $env:EDITOR vim如果接的是本地模型只需要改AI_BASE_URL和AI_MODEL脚本主体不用动。3.4 一次完整的实战演示模拟一次真实的提交过程。假设我在改用户登录模块涉及两个文件$ git add auth/login.py auth/tests/test_login.py $ git status # 暂存区有两个文件 $ git ai-commit 正在让 AI 生成提交信息...等几秒编辑器里会出现类似内容fix(auth): 修复登录接口在超时场景下返回错误状态码的问题 - 修复 verify_token 内部超时时未正确设置响应状态码的问题 - 补充对应超时场景的单元测试我通读一遍确认没问题保存退出。脚本随即执行git commit --file提交完成。看一下 git log$ git log -1 --stat fix(auth): 修复登录接口在超时场景下返回错误状态码的问题整个过程一气呵成。我实际用下来最有惊喜感的是重构场景AI 会在 body 里补上“将旧接口迁移到新协议的过渡逻辑保持外部 SDK 兼容”这种我自己都不一定记得写的背景说明这对后续维护帮助很大。如果你不喜欢编辑器交互可以在脚本里加一个--quick参数直接打印信息到终端并询问是否需要微调把确认环节压到最短。我后来一直用编辑器模式因为我可以在临时文件里直接修改保存后一条命令完成最终提交。4. 常见问题与排查技巧实录这部分是真实使用中的问题和排查思路很多在文档里查不到先记下来省得踩坑的时候再抓瞎。4.1 高频问题速查表下面这个表覆盖最常遇到的几类情况先存着遇到问题对着查现象可能原因排查与解决提示“暂存区没有内容”没有先 git add执行 git status 确认暂存状态把改动加入暂存区后重试提示“缺少 AI_API_KEY”环境变量未配置检查 export 是否写入了 shell 配置文件重启终端后再试调用 AI 接口返回 401API Key 错误或过期用 curl 单独测接口重新生成 Key 后再配置调用 AI 接口超时网络不稳定或模型响应慢调大 timeout 参数换更快的模型或接入本地模型提交信息经常丢失空行编辑器保存时处理了末尾换行读取最终文件时用 strip()不影响提交内容中文提交信息乱码Windows 控制台或文件编码问题脚本中显式使用 encodingutf-8控制台执行 chcp 65001编辑器启动不了EDITOR 没配好用绝对路径配置如 export EDITOR/usr/bin/vim生成的提交信息和代码不匹配diff 截断太狠提高 MAX_DIFF_LINES或拆分更小的提交4.2 我实际踩过的三个坑第一个坑是 temperature 调太高。最初我设置成 0.8想着“AI 多点创造性”结果同一个 diff 每次生成的提交信息措辞和类型都不一样。有一次它把修复 bug 的提交写成了feat(...)确实造成过混乱。后来定位到问题把 temperature 降到 0.3输出才稳定。第二个坑是编辑器模式在 Windows 下踩的。项目代码里用中文默认EDITORnotepad临时文件是 UTF-8 编码但旧版 notepad 对 UTF-8 无 BOM 文件识别会乱。后来统一改用 VS Code 的code --wait并把脚本读写都显式指定为 UTF-8才彻底解决。Windows 环境遇到这类问题优先看编码准没错。第三个坑是 API Key 差点被提交进仓库。早期测试时图省事把 Key 写在脚本默认值里结果有一次执行git add .把脚本一起暂存了还好提交前多看了一眼 diff才没酿成大祸。从那以后我把所有密钥都收敛到环境变量里并且养成了提交前用git diff --cached检查暂存内容的习惯。这个习惯救了我很多次强烈建议你也养成。4.3 怎么排查“AI 生成质量不高”的问题如果你的 AI 秘书时不时生成“正确的废话”问题大概率出在 prompt 或输入信息上而不是模型能力。先检查传进 prompt 的 diff 是不是太杂。一次提交涉及多个不相关模块时AI 很难提炼统一主题建议拆分提交让每个提交职责更单一。再检查 diff 里是不是混入了大量测试数据、本地配置或构建产物。这类噪音会稀释 AI 对核心改动的注意力最好在git add阶段就用.gitignore过滤掉无关文件。如果是特别大的重构提交AI 的概括往往偏“流水账”。这种场景我会手动在编辑器里把生成的信息改成类似“重构 xx 模块迁移到新的 xx 架构保持对外行为不变后续可逐步删除旧实现”把意图和背景补上去。如果你发现模型在 body 部分经常编造不存在的改动就把 prompt 里 body 要求改得更保守比如“没有把握的细节不要写宁可少写也不要编造”。这能明显降低幻觉带来的误导。5. 进阶扩展从一个命令到一个开发助理AI 写提交信息只是切入点。实际用顺之后你会发现这套脚本稍加修改就能承担更多任务把“代码秘书”升级成“提交管家”。5.1 接入本地模型代码 diff 不出内网对有数据安全要求的团队强烈推荐把 API 地址切到本地模型。Ollama 是目前最简单的本地模型运行工具一条命令就能把模型拉起ollama run qwen2.5-coder:7b它会默认监听11434端口并提供 OpenAI 兼容接口。你只需要改两个环境变量其他逻辑不用动export AI_BASE_URLhttp://localhost:11434/v1 export AI_MODELqwen2.5-coder:7b实测 7B 参数的模型在普通开发机上生成一条提交信息大概需要 3 到 8 秒虽然不是秒回但考虑到数据全程不出内网这点延迟完全值得。如果团队有 GPU 服务器上 14B 甚至 32B 的模型效果会更好基本能和云端小模型打个平手。我的个人建议是哪怕你自己的开发机能跑得动也优先用本地小模型。原因是提交信息属于高频低难度任务对模型推理能力要求不高但数据又是最敏感的源码能在本地就在本地这是最稳妥的选择。5.2 用 Git Hook 做全自动注入适合团队级规范如果团队想强制所有人使用 AI 提交信息可以在.git/hooks/prepare-commit-msg里挂一个脚本逻辑是检测提交信息文件内容如果内容为空或太短就调用 AI 生成后填入。但这里有个体验上的坑用户执行git commit时 hook 会同步阻塞接口超时 20 秒用户就得干等着。我建议的方案是折中hook 里不直接调 AI而是先检查一个缓存文件比如.git/ai-suggested-msg如果存在就自动填充git ai-commit命令在空闲时把建议信息写入缓存文件。这样用户正常git commit时也能吃到 AI 红利但不会被 API 延迟卡住提交流程。这个进阶方案更适合团队协作作为个人工具用自定义命令就够了。5.3 基于提交信息的二次挖掘Changelog 与 PR 描述提交信息一旦规范后面的自动化红利会接踵而至。Changelog 生成release-please、standard-version 这类工具会按提交信息的 type 自动归类版本变更、生成更新日志。你只要保证提交信息规范发布时几乎零成本拿到 changelog。PR 描述初稿把本次分支相对主干的 commit 信息汇总让 AI 生成一份 PR 描述初稿人工改一改就能提交。比起从零写效率提升不是一点半点。周报与进展汇报把一周的 feat/fix 汇总成流水再让 AI 润色成汇报文字也是顺理成章的事。这些扩展方向的共同点是本质还是“让 AI 基于代码差异做事”。提交信息是这个方向里最轻量、最不容易出错的第一个切入点一旦跑通整套思路可以平移到更多场景。最后聊点实际体会。这套流程我跑了差不多两个月最明显的变化是提交信息不再是我最头疼的收尾工作了。夜班改完需求或者连续修 bug 修到脑子发木的时候以前最容易随便交差现在 AI 先把草稿起好我哪怕只瞄一眼再改几个字提交信息都比我硬想出来的规范得多。你把这个脚本放进自己的项目里先跑一两周把 prompt 逐步调成适合你自己和团队习惯的版本。等哪天你发现提交历史已经变成一本按条目排列的“变更日记”而不是一坨“update xxx”的流水账你就明白这个“代码秘书”确实请得值了。