Showdev：AI 辅助的技能，将凌乱的更改批量整理为 Conventional Commits

Source: Dev.to

Hi DEV community 👋

我想分享一个我一直在玩的小项目：conventional-commit-batcher。
这是我第一次在 AI 工具的帮助下构建的“skill”。在几位程序员朋友在真实的进行中分支上尝试后，发现它对把混乱、混合的改动整理成更清晰的提交历史非常有用，于是我决定开源它。

TL;DR

• 先制定计划 – 根据意图生成提交计划
• 分批提交 – 通常配合 git add -p 使用
• 验证提交信息 – 强制遵循 Conventional Commits

它要解决什么问题？

当工作树中混杂了重构、修复、文档和杂项时，尤其是对初级开发者来说，很容易出现：

• 一个巨大的 “misc” 提交
• 含糊的提交信息

导致历史难以审查、回滚或 git bisect。
我想要一种能够引导我形成更易审查、可追溯的历史的工具——而不是把它变成繁琐的仪式。

它的功能（一句话概括）

先计划后分批提交 + 提交信息验证 – 帮助你把混合的差异组织成逻辑清晰、可审查的 Conventional Commits，并在提交前验证信息。

工作原理（高层概述）

先制定计划

生成一个 提交计划，按意图（如重构、修复、文档）对改动进行分组。

分批暂存

一次只暂存一批改动（通常使用 git add -p），而不是“一键全加”。

信息验证

使用可执行的验证器强制 Conventional Commits 格式。

安全门槛

如果出现风险迹象（冲突标记、敏感字符串等），提前中止。

示例：按意图划分的提交计划

1) refactor(auth): simplify token parsing
   changes: src/auth/*

2) fix(api): handle empty response safely
   changes: src/api/*

3) docs: update setup notes
   changes: docs/*

仓库 / 快速尝试

Repository:

如果你使用 Vercel skills 生态系统，可以尝试：

npx skills add cnkang/conventional-commit-batcher

不想使用代理工具？仍然可以在仓库中使用验证器和 commit‑msg 钩子示例。

一个小的前后对比示例

之前（典型的混乱分支）

• update stuff
• fixes
• wip

之后（相同工作，历史更清晰）

• refactor(auth): simplify token parsing
• fix(api): handle empty response safely
• docs: update setup notes

可以想象，这样审查、回滚或 bisect 会容易得多。

小小请求：试用并分享反馈

如果你能在“混乱分支”上试用，我非常期待你的想法：

• 按意图分批：它真的能把混合改动拆分成逻辑提交吗？如果不能，哪些类型的改动最难分离（测试 + 重构、格式化 + 业务逻辑、锁文件…）？
• 团队约定：你们遵循哪些规则（type/scope、标题长度、issue 引用、breaking changes）？
• 对初级开发者友好的护栏：哪些检查感觉有帮助，哪些又显得过于严格？
• 多语言提交信息：你会用非英文写提交吗？如果会，你更倾向于 type(scope) 用英文 + 本地化的 subject/body，还是全部本地化的提交信息（验证器该如何适配）？

感谢阅读 🙇

如果你尝试过并且有收获（或遇到问题），非常期待听到你的反馈——无论结果如何。