用途：规范 Git commit message 的写法，让提交信息成为一次变更的事实记录，说明变更为何发生，而不是重复 diff 已经展示的内容。
结构：提交信息由 [scope] subject、body、trailers 三部分组成。subject 用祈使语气只陈述事实，目标 50 字符、硬上限 72 字符；body 写原因、权衡与可重复的验证步骤；trailers 放引用、作者等结构化元数据。
作用域：可选，形如 [parser]、[core/auth]、[web/api]，从文件路径而非文件内容推导，取公共父目录或最重要的组件；同一组件只允许一种拼写，否则会破坏基于 scope 的过滤。路径中的版本目录（如 v2）在某版本仍存活时可省略，双版本并存时保留以区分。
正文：解释变更必要的原因；修复类说明缺陷为何存在，特性类给出使用场景，重构类给出动机，破坏性变更给出迁移路径。正文每行硬性折行 72 字符，trailers 除外。长度取决于理由数量而非 diff 大小；多个行为变更用 - 列表每行一项，不写成走查。需通过两个测试：把段落放进仓库文档是否仍真实有用；以及它是否对应某项应保留的理由，否则删除。
破坏性变更：正文以大写 BREAKING: 开头，简短说明破坏内容，后续段落解释原因与迁移路径；多步迁移用 Migration: 行下的编号列表。
Trailers：采用 git-trailer 格式，键用 Title-Case，值单行，多值可逗号分隔或重复该 trailer，例如 Task:、Fixes:、Refs:、Closes:、See:、Reviewed-By:、Co-Authored-By:。
改写提交（amend）：改写会重写历史，最终信息必须描述该提交引入的完整变更，而非相对原提交的差异；不要写“也更新了测试”“修复上一版的边界情况”“响应评审意见”这类迭代表述。应读取暂存区完整 diff，重新写一条描述整体变更的信息。
限制与禁忌：使用 ASCII 符号，避免破折号、箭头、项目符号、花引号、emoji 与装饰性 Unicode；避免“This commit”“I”“we”“now”“previously”等表述；不把旧行为作为对比；不写宣传性形容词与填充词；不记录测试数、lint/类型检查/构建/CI 状态等会话产物；不添加 AI 署名、AI 共同作者 trailer、AI 生成 emoji 或指向 AI 工具与站点的链接。除项目约定必需外不使用 emoji。