3.2 KiB
3.2 KiB
name, description, disable-model-invocation
| name | description | disable-model-invocation |
|---|---|---|
| write-commit-message | 根据 git 变更生成简体中文提交日志，遵循固定格式（首行概括，必要时空行加分点简述）。 当用户要求写提交日志、commit message、提交说明，或在提交前需要整理变更摘要时使用。 | true |
写提交日志
工作流程
- 若尚未掌握变更内容，先并行执行：
git status查看变更文件git diff查看未暂存改动git diff --cached查看已暂存改动（如有）
- 阅读 diff，识别新增功能、重要修改与实际影响，忽略构建产物、IDE 缓存等无关文件
- 按下方格式生成提交日志；用户要求直接提交时，将生成的文本作为 commit message 使用
输出规范（必须严格遵守）
回复中只允许出现提交日志正文，禁止输出任何其他内容，包括但不限于：
- 前言、说明、标题（如「提交日志如下」）
- 对变更的分析或评论
- 提醒拆提交、后续建议等附加说明
- Markdown 格式（代码块、加粗、标题、列表语法以外的装饰等）
目的：用户可一键全选复制，直接用于 git commit -m。
正文格式
- 使用简体中文
- 第一行：一段简短的描述性句子，概括本次更改的核心内容（必填）
- 分点简述：可选。仅当变更多处、第一行无法充分表达、或需要补充关键细节时才添加
- 若使用分点：第二行留空，第三行起用
-（横杠 + 空格）列出 1～2 个要点，每点一两句话 - 若改动单一、第一行已说清楚：只输出第一行，不要空行，不要硬凑分点
- 不要使用加粗或其他强调格式
- 英文类名、方法名、变量名等可直接保留原样（非必要时用描述性文字即可）
- 重点突出新增功能、重要修改和实际影响
两种模板，按实际情况选用：
单行（改动简单、第一行已足够）：
<一句话概括核心变更>
多行（有必要补充细节时）：
<一句话概括核心变更>
- <主要改动 1>
- <主要改动 2>
写作原则
- 第一行说「做了什么、解决什么问题」，避免空泛的「更新代码」「修复 bug」
- 分点是补充说明，不是必填项；第一行能独立表达清楚时，省略分点
- 不要为了凑格式而拆分无意义的细项
- 分点只写对使用者或维护者有意义的变更，不写琐碎重命名、格式化
- 多项无关改动时，在内部自行取舍重点，仍只输出一条提交日志正文，不附加说明
示例
示例 1（改动较多，需要分点）
变更：新增测试台拓扑视图，并修复参数网格刷新问题
正确输出：
新增测试台拓扑可视化视图并修复参数表格刷新异常
- 添加 Topo1～Topo4 四种拓扑布局视图及对应 ViewModel
- 修复切换测试台后参数网格未重新加载的问题
示例 2（改动单一，无需分点）
变更：仅修正一处空指针
正确输出：
修复未选择设备时点击导入导致的崩溃
错误输出（含多余说明或 Markdown，禁止）：
以下是提交日志：
新增测试台...
或：「已根据暂存区生成提交日志，请复制使用：……」