拉取请求描述模板

模板类别概述

一份好的拉取请求描述，是快速而有把握的评审与缓慢往返之间的分别——然而开发者在每个 PR 上都写同样的支架（摘要、动机、测试说明、清单），并常在赶工时省略它。结构在各 PR 之间相同；变的只是具体信息。文本扩展工具会保存经过验证的描述框架，让一个简短触发词插入完整模板，于是你把时间花在解释实际改动上，而非重建标题。Lightning Assist 会把它们插入 GitHub、GitLab 或 Bitbucket——任何你键入描述的地方——配有摘要、为什么和测试计划的占位符。与只在一个项目内生效的仓库原生 PR 模板不同，同一个片段在你接触的每个仓库与工具中都有效。

何时使用这些模板

凡清晰描述能加快评审的每个 PR——也就是几乎所有：功能开发、缺陷修复、重构，乃至琐碎改动——都可使用拉取请求描述模板。结构（做什么、为什么、如何、如何测试）保持不变；变的只是具体信息。将其标准化能让评审更快更彻底，捕获那个一旦合并便消失的"为什么"，并在团队中无论谁开 PR 都保持质量一致。文本扩展工具版本相较仓库原生 PR 模板有一个优势：同一套库在你使用的每个仓库、组织与 Git 主机中都有效，因此你的描述质量不取决于每个项目是否配置妥当。

此类别中的示例模板

• 标准 PR 描述：改了什么、为什么，以及评审者如何验证。
• 缺陷修复 PR：根因、修复，以及证明它的回归测试。
• 小型/琐碎 PR：一个轻量变体，仍然说明意图与风险。

实践中的示例模板

## What
[#One-line summary of the change#]

## Why
[#Motivation / linked issue: #123#]

## How
[#Brief description of the approach#]

## How to test
- [#step 1#]
- [#step 2#]

## Checklist
- [ ] Tests added/updated
- [ ] Docs updated if needed

## Bug
[#Link to issue#] — [#what was broken#]

## Root cause
[#The underlying cause#]

## Fix
[#What this change does#]

## Regression test
[#The test that now covers this case#]

## Summary
[#One-line description of the trivial change#]

**Risk:** [#none / low — e.g. copy-only, no logic change#]
**Testing:** [#how verified, or "n/a"#]

如何开始

把你的标准 PR 描述写一次，做成 ;prdesc 上的片段，并为摘要、关联问题和测试计划加上占位符。再加一个缺陷修复变体（;prbug）和一个轻量变体（;prsmall）。键入触发词，它会在你打字时就地展开——无需热键（或使用 Hotkey Mode）——在 GitHub、GitLab 或 Bitbucket 中。只填具体信息；结构在每个 PR 上复用。把它与你的提交信息片段搭配，让整个改动得到一致记录；并在点击创建前用 AI Enhance 把仓促的描述收紧为清晰的文字。

专业提示

• 始终连同关联问题写出"为什么"——这是评审者最需要、也是在赶工时最常被丢弃的部分。
• 保留一个明确的"如何测试"小节；正是它把缓慢的评审变成快速而有把握的批准。
• 对琐碎 PR 使用轻量变体，让小改动既保持快速，又绝不带着空白描述框到来。
• 与仓库原生 PR 模板不同，文本扩展工具的片段在每个仓库与 Git 主机中都有效，因此质量不取决于逐项目的配置。