削减繁琐工作：自动化重复的开发任务

Source: Dev.to

自动化版本标签工作流

我维护着少量需要定期修补的开源工具。随着我对编码代理的使用越来越熟练，我终于解决了两个我让它们拖了太久的小烦恼。

第一个是让编码代理生成一个 GitHub Workflow，用来在我创建新次要版本时推进一个主要版本标签（例如 v1）。主要版本跟踪是 GitHub Actions 中常见的做法，使用者希望减少对工作流文件的更新次数。

以前，这需要额外的几条命令来把主要版本映射到最新发布的提交。虽然这并不是“移山”，但我拖了太久才去自动化它。我把想要的内容描述给 Claude Code，工作流在第一次使用时就成功运行了。

在 Dependabot PR 上自动重建 Dist

我经常遇到的另一种情况是：Dependabot 更新了一个库，而 dist 文件夹中的转译后 JavaScript 与源码不再匹配。PR 工作流会捕获到这种不匹配，这意味着我必须：

1. 检出该分支。
2. 重新构建项目。
3. 推送更新后的 dist 文件夹。

在过去的一年里，我容忍了 5–10 次执行这套命令的过程。

我没有使用工作流，而是通过一个代理技能来解决。技能现在已经成为一种开放标准，为代理提供了可扩展的方式来自动化常见任务。与其手动运行一系列命令，我只需对我的编码代理说：

rebuild dist on PR 123

经验教训

这两个例子都有一个共同特征：它们本质上是确定性的。工作流每次运行的方式都相同，而技能则为代理提供了明确的步骤，而不是让它从头推理 Dependabot PR。

编码代理之所以强大，是因为它们可以即兴发挥，但对于已经知道正确顺序的任务，将该顺序编码进去更快、更便宜，也更可预测。

这些小的迭代改进会累计起来。这正是我看到编码代理提供真正价值的地方——不是通过一次提示生成完整的应用程序，而是通过一点一点消除围绕工作产生的摩擦。当这些改进不断堆叠时，我在维护上的时间会减少，更多时间可以投入到工具本身。我很好奇当团队开始将这些模式串联起来时，这种复合效应在大规模下会如何表现。