告别“修复 bug”：让别人一眼看懂你的 Commit

你有没有遇到过这种场景：

PR 已经发了、代码也改完了，唯一的问题是 commit message 呃......真的不好读。

比如团队里最常见、也最让人抓狂的写法（说重一点：狗屎一样的 commit）：

fix: 修复了已知问题
fix: 修复bug
perf: 优化页面
style: 更新样式
chore: 更新了部分逻辑

它们的问题不是"写错了"，而是几乎没有信息密度：读起来像一句句屁话。

对写的人来说可能"看一眼就知道发生了什么"。但对没参与实现的人来说，只会变成一句更大的问号：到底解决了什么问题？影响哪里？为什么要改？

commit 到底缺了什么信息？

很多 commit 的"可读性"不足，并不是因为你不够努力，而是因为你在写的时候更像是在描述代码变更，而不是在传达意图。

更现实的原因通常是这两个：

没有 commit 规范：大家只记得"前面写个 fix/feat"，后面随手糊一句话就算交差
去想 commit 很浪费时间：写 message 变成临门一脚的脑力活，越赶越随便，最后就只剩"修复 bug / 优化页面 / 更新样式"

非技术读者（或未来的自己）通常需要的是：

这次改动的目的是什么
它让系统/用户发生了什么变化（影响）
变更的边界大概在哪里（scope 的作用）

workpilot 想解决的，就是把这件事从"靠脑子写"变成"基于 diff 自动生成"。

workpilot 做了什么（为什么你会喜欢它）

workpilot 是一个 AI CLI，会读取你本地 Git 历史与代码 diff，并生成可直接分享的内容。

在"生成 commit message"这个场景里，你只需要：

运行 wp commit
查看 AI 生成的 message
交互确认后再提交（你不想提交也可以只生成不提交）

它的输出遵循常见的规范 commit message 结构，让 summary 更像"给人看的结论"，而不是"给机器的操作记录"。

你会得到的 commit message 长什么样？

wp commit 的推荐输出格式是：

text 复制代码

<type>[scope]: <summary>

<optional body>

其中：

summary：一句话说明改动目的（不罗列文件、不描述实现细节），通常控制在 72 字符以内
body（可选）：最多 3 行，用来补充关键背景或影响
type 常用值：feat / fix / refactor / perf / docs / test / build / ci / style / chore

最短上手：3 行命令让 commit 变"可读"

在你的项目里：

bash 复制代码

wp commit

它会根据你当前仓库的 diff 生成 commit message，并引导你确认是否执行 git add -A以及是否git commit。

如果你只想先看效果，不急着提交：

bash 复制代码

wp commit --no-commit

常用模式：按你的节奏来

只用暂存区（你已精确 git add 的内容）

bash 复制代码

wp commit --staged

只用未暂存变更（仅生成，不提交）

bash 复制代码

wp commit --work

只生成并打印（不执行提交）

bash 复制代码

wp commit --no-commit

生成后同时复制到剪贴板（适合你改一改再粘贴）

bash 复制代码

wp commit copy
wp commit --no-commit copy

对比示例：同样是"修复"，表达方式差很多

写法 1：信息不足，别人看不懂

text 复制代码

fix: 修复了已知问题

问题是：它没有告诉人"目的是什么"和"影响哪里"。

写法 2：用目的 + 影响讲清楚

text 复制代码

fix(ui): 修复列表异常展示，减少用户操作中断

这类写法的核心变化是：

scope 标明主要影响模块（例如 ui）
summary 讲清"解决什么 + 带来什么改善"
不罗列文件、不展开实现细节

为什么这会提升协作效率？

当 commit message 变得可读，你会同时获得三件事：

复盘更快：回看历史不需要再"猜你当时改了啥"
同步更顺：站会/评审/跨团队协作时，汇报更容易对齐
未来更省事：哪怕过几个月，你也能用 commit 结论快速定位变更影响

对开发者来说，这不是"好看"，是减少沟通成本。

30 秒试用建议（不需要任何额外准备）

在你有变更的仓库里先跑一次：

bash 复制代码

wp commit --no-commit

看 AI 生成的 summary 是否符合你的预期表达
如果满意，再用：

bash 复制代码

wp commit

（交互确认后再提交）

安装与获取帮助

安装：

bash 复制代码

npm i -g workpilot

帮助：

bash 复制代码

wp --help

最后一句：把"改了什么"变成"为什么改"

commit message 的价值不在于记录代码动作，而在于传递改动意图。

如果你也不想再写那种别人看完只会"嗯？"的 commit------从今天开始试试 wp commit。