用少量示例说明做法

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你要把改动说明转成统一的提交摘要，已有实际行为，但读者对 type 和 scope 的写法理解不同。教学输入是“缓存查询拒绝空 key”；项目约定 bug 修复使用 fix，缓存模块的 scope 为 cache。示例演示格式，不给新任务提供事实。

具体做法

选少量能展示关键差别的输入→输出对，并说明它们体现的规则。这里用一个新增行为和一个修复行为说明 type，用不同模块说明 scope，再用缺少行为的反例说明何时不能生成。

随后提供真正要处理的输入，要求只迁移格式和判断方式，不复制示例中的模块或功能。输入缺关键信息时列出缺口。

反例

把“缓存查询拒绝空 key”写成提交摘要。写得像一个好的身份认证提交，例如增加 token 刷新。

改进写法

按以下项目约定生成提交摘要：新增功能用 feat，修复错误用 fix；scope 使用实际模块名。示例：增加 token 刷新 → feat(auth): add token refresh；拒绝空邮箱 → fix(validation): reject empty email。反例“改进东西”缺少行为与模块，应先询问缺失信息。
实际输入：缓存查询拒绝空 key。这是 bug 修复，模块为 cache。输出一行摘要，只复用示例格式，不复制它们的功能事实。

为什么这样改

反例只提到一个好例子的主题，无法说明哪些部分应该迁移。改进版本让输入、输出和规则一起出现，读者可以看见 type、scope 与行为的对应关系，也知道资料不足时不能照搬一个完整示例。

如何验证

教学任务的示意输出为 fix(cache): reject empty key。检查 type 是否来自“bug 修复”，scope 是否来自 cache，行为是否保留“拒绝空 key”，是否没有混入 token 或邮箱。

再把输入换成“改进东西”：合格结果应指出缺少行为和模块，而不是随机套用示例。这个检查验证例子能否说明规则，不证明真实模型的成功率。

适用边界

示例会占用上下文，也可能引导模型过度模仿。优先选择覆盖实际差异的例子；复杂格式还需显式约束或验证器。来源展示了输入→输出格式和被拒绝的理解；本篇 type/scope 约定属于教学项目，不是所有仓库的通用规则。