docevilock git-commit-template
提交说明的书写规范与模板。不负责提交流程（版本、固件、changelog 同步等），只定义 commit message 怎么写。
标题（Subject）
标题使用 Conventional Commits 格式，英文小写 type，可追加 scope，中文描述：
<type>[scope]: <中文描述>
Commit Types
| type | 用途 |
|---|---|
feat |
新功能 |
fix |
修复缺陷 |
docs |
文档变更 |
style |
格式/风格（无逻辑变更） |
refactor |
代码重构（无功能/修复变更） |
perf |
性能优化 |
test |
新增/更新测试 |
build |
构建/依赖变更 |
ci |
CI/配置变更 |
chore |
维护/杂项 |
示例：
refactor: 简化编码规范流程并增强编译指令生成feat[agent-browser]: 新增截图对比功能fix: 修复 skills 链接在 Windows 下失效
⚠️ 硬性输出约束
以下规则为强制门禁，违反即错误，不可协商：
逐行输出
版本、时间、修改者、更改点、以及更改点下的一级子项（修改原因/修改依据/修改方法/修改影响）必须各自独占一行。
禁止将多个顶级字段拼接为单行，例如：
n# 错误 — 禁止以下输出格式 版本：N/A 时间：26.07.16 修改者：Yangyp 更改点：gbk_prepare改为stamp增量扫描，gbk_encode用C重写 n
正确格式：每个字段独占一行，子项缩进换行。
篇幅上限
| 字段 | 上限 |
|---|---|
| 修改原因 | ≤ 1 行 |
| 修改依据 | ≤ 1 行 |
| 修改方法 | ≤ 2 行 |
| 修改影响 | ≤ 1 行 |
这是硬性字数/行数约束，不是建议。超出上限即为格式错误。
正文模板
主题行可使用 Conventional Commits 简写（如 feat: xxx、fix: xxx），但正文必须包含以下字段（格式优先参考仓库既有提交历史）：
版本：<artifact-or-release-version，无版本号则填 N/A>
时间：<date>
修改者：<git config user.name>
更改点：
1）修改原因：
1. <why-1>
2. <why-2>
2）修改依据：
1. <basis-1>
2. <basis-2>
3）修改方法：
1. <how-1>
2. <how-2>
4）修改影响：
1. <impact-1>
2. <impact-2>
若仓库已有自己的模板，按仓库模板。
字段说明
| 字段 | 来源 | 说明 |
|---|---|---|
| type[scope] | 标题 | Conventional Commits 格式 |
| 版本 | 版本源文件或发布版本号；若无版本号，填 N/A |
不把长版本信息塞进标题；禁止在没有版本号时尝试查找或推导版本号 |
| 时间 | 当前日期 | 格式沿用仓库历史；若无固定格式，使用 YYYY.MM.DD |
| 修改者 | git config user.name |
除非仓库另有要求 |
| 修改原因 | 本次改动要解决什么问题 | 从用户/产品/业务角度说明，≤ 1 行 |
| 修改依据 | 基于什么理由做这个修改 | 需求、bug、设计文档等，≤ 1 行 |
| 修改方法 | 关键实现手段摘要 | 只写方法摘要，不展开实现细节，≤ 2 行 |
| 修改影响 | 对用户/系统/兼容性的影响 | 只写关键结果，不写过细技术影响，≤ 1 行 |
写作风格
- 标题：
type[scope]: 中文描述，聚焦提交目的，简练清晰。 - 正文：只描述本次真实业务、代码、文档、兼容性和影响变化。不要写提交流程、是否递进版本、是否归档固件、后续应该做什么等流程话术。
- 默认禁止一整段说明式写法：在
修改原因/修改依据/修改方法/修改影响后直接跟一大句完整说明而不分点（除非仓库历史模板明确要求单段写法）。 - 同一一级字段下最多 3 条子点：先压缩语言，再检查是否还能继续合并同类项。能写成一条摘要时，不拆成多条细节。
- 同一一级字段下存在两个及以上独立主题时：拆成
1.2.3.子点，不要把多个主题塞进一个长句、分号串联句或并列从句里。 - "修改方法" 默认不写过细实现细节：不写具体函数级处理步骤、内部状态机细节、输入输出字节级变化、调试日志点布置、具体兼容分支和兜底路径。
- "修改影响" 默认不写过细技术影响：不写某种旧报文/旧字段/旧格式会被拒绝、某个中间态如何切换、内部 session/payload 如何分段推进、过细的协议兼容边界。
- 不要把"已按默认流程检查/同步固件和 README/changelog"写成变更点或原因；默认流程是否执行记录在任务汇报中即可。
正反示例
修改方法
推荐（短句概括，最多 3 点）：
3）修改方法：
1. 收口提交正文模板
2. 增加最多 3 点约束
3. 补充正反示例
不推荐（长句串联、函数级细节）：
3）修改方法：收口提交正文模板并增加最多 3 点约束，同时补充正反示例以
避免提交时继续输出整段长句。修改了 validate_template() 函数内部的状态机
处理，增加了字段级校验和回退逻辑。
修改影响
推荐（用户/业务视角）：
4）修改影响：
1. 提交模板统一为四字段结构
2. 不再接受整段式提交说明
不推荐（过细技术影响）：
4）修改影响：
1. 旧的单段提交格式会被拒绝
2. 内部 session 状态切换逻辑不变
3. 兼容旧版本 review 工具
常见错误
- 在 commit message 里写"按默认流程检查/同步固件和 README"造成提交说明噪音。
- 在 commit message 或版本履历里写"不修改版本宏""不归档固件产物""后续需要更新固件"等流程说明。
- 标题塞入过长版本字符串。
- 多个独立影响面挤在一条长句里，导致兼容性、策略和行为混在一起。
- 一级字段下分出 5-8 条碎点，没有先压缩语言、合并同类项。
- 正文与版本头、README/changelog、归档产物不一致。
- 在没有版本号时尝试查找或推导版本号（如搜索 VERSION 宏、package.json 等），应直接填
N/A。 - 将版本、时间、修改者、更改点等所有字段拼接在一行输出（如
版本：N/A 日期：26.07.16 修改者：Yangyp 更改点：...），必须每个顶级字段和一级子项独占一行。 - 修改原因/依据/影响超过 1 行，或修改方法超过 2 行，未按硬性篇幅上限压缩。