起因#

正如很多站长都会遇到的那样，如果你通过 PR 来处理友链申请，尤其是在完全没有自动化的情况下，大概率会遇到下面这种场面：

数量多其实还不是最麻烦的，真正麻烦的是：

以及各种格式问题。

是的，我甚至都没有设计什么复杂格式，但很多人提交友链时，连 JSON 都写不明白。上图是忘了引号，下图则连 .json 后缀都没写对。

很长一段时间里，这些小问题我都是手动帮忙修的，毕竟看起来都不算大事。

但问题在于：当你正在打游戏，或者正忙着处理别的事情时，突然弹出一个友链 PR，你到底是现在处理，还是留到之后集中处理？无论怎么选，都挺打断节奏。

所以我就在想：有没有办法把这件事尽可能自动化掉？

正式开始#

我们能不能用 GitHub Action 来自动化这件事？

思路是这样的：让用户在提交友链时额外填写一个回链字段，然后由 GitHub Action 实际检测是否存在回链。这样不仅能确认对方确实添加了你的友链，也能顺便完成一次所有权验证。

我们可以先把整个流程拆开来想一遍。

GitHub Action 本来就是用来处理这类自动化任务的，这不正好符合我们的需求吗？甚至还可以顺手做一些更高级的事情，比如所有权验证，某种程度上和站长平台验证域名的思路很像。

于是，整体流程草图很快就出来了。

接下来再把这份思路交给 AI 帮忙整理实现。

最终你就得到了

没关系，前期看起来乱一点很正常，毕竟 GitHub Action 这类流程很多时候只能在真实环境里慢慢调试。

最终我们就会得到…

看起来是不是很简单？其实并没有。现在看到的这套流程虽然表面上还算清晰，但也是反复梳理和修改之后，才勉强打磨到“基本能用”的状态。

下面再说一些非常容易踩坑的地方。

首先，这整套架构虽然最终看起来还算清晰，但实际逻辑并不简单。要是一次就能跑通，那已经算运气很好了；一旦中间某一步出问题，排查起来会相当痛苦。

所以在多次调整架构之后，我最终决定直接使用 GitHub 的标签系统来跟踪进度并锚定规则。

每一步都给 PR 打上明确的标签，就像这样：

这样做的好处是，不仅在外部一眼就能看出某个 PR 卡在哪一步，也能让你在不额外写复杂日志的情况下，大致判断问题出在哪里。

接下来是所有权验证。这个环节其实必须做好错误处理，因为它往往无法一次性顺利跑到底。借助 GitHub 标签，我们可以控制某些步骤是否跳过，从而避免验证文件被重复要求，或者每次都随机生成一个新的文件。

只要打上 所有权验证进行中 这个标签，Action 就会去寻找之前已经创建好的验证文件，而不是重新生成一个新的。

到这里看起来还只是基本功，但后面还有一个更关键的问题。

我发现，只要是从外部仓库拉进来的 PR，Action 就没法直接通过 GITHUB_TOKEN 去合并它。不过这个问题也不算麻烦，额外创建一个自己的个人访问令牌（PAT），再把它绑定到 Action 中即可。

至此，这套自动化流程终于能比较顺畅地跑起来了。