跳到正文
码上手 coding.chengyu.dev

提示词:生成提交信息与 PR 描述

让智能体根据暂存区 diff 和近期提交风格写提交信息,再生成包含背景、改动、测试与风险的 PR 描述,写清楚没验证到的内容,不夸大。

通用Claude CodeGit提交信息Pull Request 更新于 2026-10-25

适用场景

改完代码,要写提交信息和 PR 描述。智能体很会写,但默认产出常有三个毛病:把「做了什么」写成流水账;用「大幅提升」「全面优化」这类夸大的词;声称「已测试」,实际上没有跑过。

这份提示词要求它先学习仓库已有的提交风格,只根据 diff 里的事实描述,并且把「没有验证的部分」明确写出来。

模板

请为我当前的改动生成提交信息,并起草 PR 描述。先不要执行 git commit 或 git push,也不要创建 PR。

准备工作:
1. 运行 git status 和 git diff --staged(如果暂存区为空,用 git diff),读懂全部改动。
2. 运行 git log -n 15 --oneline,学习这个仓库的提交信息风格(语言、前缀、长度),并沿用。
3. 检查有没有混进无关改动、调试代码、密钥或大文件;有的话先告诉我,不要继续。

提交信息要求:
- 第一行不超过 50 个字,概述「改了什么」,不要以句号结尾。
- 需要时空一行,再用 1 到 3 行写「为什么改」和关键取舍,不要复述 diff 的每一行。
- 只写 diff 里能看到的事实;不要使用「优化」「提升」「完善」这类没有信息量的词,
  能写出具体数据或行为变化就写。
- 如果这次改动应该拆成多个提交,告诉我怎么拆,每个提交包含哪些文件。

PR 描述按下面的结构输出:
## 背景
为什么要做这件事,关联的 Issue 或需求【编号或链接】。
## 改动
按模块列出主要改动,每条一句话。
## 如何验证
我实际运行过的命令和结果;没有运行过的,明确写「未验证」,不要写「应该没问题」。
## 风险与回滚
可能受影响的功能、数据或接口;如何回滚。
## 截图或说明(界面改动时)
我会自己补充,你留出位置。

最后列出你不确定的地方,等我确认。

怎么用 / 怎么改

  1. 把模板存成团队共享的提示词,或者做成 Skill:只要把正文放进 SKILL.md,就可以用 /commit-msg 之类的命令随时调用。
  2. 想一步到位时,在末尾改成「我确认后,用 git commit 提交;然后用 gh pr create 创建 PR」。官方文档也说明,你可以直接对 Claude 说「create a pr」让它创建,并在之后让它补充描述里的上下文。
  3. 团队有固定规范(例如约定式提交、必须带 Issue 编号)时,把规范写进项目的 CLAUDE.md,而不是每次粘贴到提示词里。
  4. 把第 2 步换成你们团队的真实例子,让它按例子写,比抽象的格式说明有效。

常见问题或注意事项

  • 和内置的提交行为冲突。 Claude Code 自带了一套提交和 PR 的说明。如果你在 CLAUDE.md 里另立规则,两者可能打架。官方给出的做法是用设置项 includeGitInstructions 去掉内置说明,用 attribution 自定义署名文本。具体取值以设置参考文档为准。
  • 署名行不想要或者必须要。 同样通过 attribution 设置,而不是在提示词里反复叮嘱。
  • 不要让它自动提交。 提交会改变仓库状态。在你确认内容前,保持「只生成、不执行」;需要的话可以在权限规则里对 git push 设为询问。
  • PR 描述需要你补的内容。 动机、业务背景、踩过的坑,智能体看 diff 是看不到的。把它当作草稿,补完再提交。
  • Claude 创建的 PR 会关联会话。 通过 gh pr create 创建后,可以用 claude --from-pr 编号 找回当时的会话,方便后续追问。

参考来源

Esc

输入关键词开始搜索,例如「CLAUDE.md」「MCP」「部署」