不知哪年哪月上网冲浪的时候，Rabi来到了犬's Blog，当时就喜欢上了这个主题。
到了Rabi建立博客的时候，找到了这个主题的仓库。但是xb2016/kratos-pjax是怎么说的呢——
此项目基于 Kratos V2，当前已不再维护，请使用 Kratos V4 原项目 以获得支持与最佳体验
坏耶，放到现在的WordPress版本不知道还能不能用，那Rabi来看看seatonjiang/kratos吧。
最后一个版本v4.3.3发布于2025-11-17，看上去搭配最新的WordPress 6.9.4应该不会有太大问题，那么就试试吧。
安装完毕，仔细思考，发现问题：
文章类型怎么只有标准，Rabi心心念念的动态去哪了？！
不好，原来发布动态也是kratos-pjax加进去的功能。要寄了吗？
于是Rabi想到了：让Coding Agent来办这件事。
Rabi知道WordPress有一个东西叫做“子主题”，也就是能够在不修改原始主题的情况下，叠加上自定义的修改。无论主题还是子主题，都是以独立文件夹的形式存在的，并且代码修改也是即时生效的，因此只要将子主题的文件夹作为Agent的工作区打开，让Agent创建代码，Rabi打开网站随时刷新检查效果，就能快速得到代码的效果反馈。
同时Rabi决定利用Linux的权限机制来给Agent划定一个硬边界，不给它任何搞坏东西的机会。Rabi所采用的办法是为Agent创建一个单独的agent用户，将agent用户加入www-data组，使其能够读取WordPress的路径，这其中就包含了所有的主题文件夹，但agent用户能够修改的，就只有属于agent用户自己的子主题文件夹，其他的只能看，不能摸。
到这里该给子主题想个名字了，略加思索，那就叫做Kratos4Radio吧。
这里的4既是指基于V4版本，也是for的意思。又是双关冷笑话吗，哈哈。
Coding Agent选择Codex CLI，因为网站服务器本来就在国外，所以不需要过多折腾就可以直接安装使用。
第一步就先把发布动态这个功能做出来。预想到刚开始大概率会翻车，Rabi在提示词里出了个主意：每完成一个功能，执行curl https://rabi.fm，如果返回了500 Internal Server Error，就立刻回滚修改。
不出所料确实翻车了。然而此前Rabi打开了FastCGI缓存，结果网站即使实际上500了，缓存依然会生效并给出200响应，导致Agent没能正确判断主题有没有崩。于是急急忙忙的关掉缓存功能，然后清空工作区重新开始。
这次Agent能知道自己搞砸了，但是似乎陷入了无尽的思索，迟迟没有给出修复。Rabi一想，这应该是信息不够导致的，于是指示Agent去读取nginx的error.log来获取底层的PHP报错信息。但Agent表示权限不够，无法读取/var/log/nginx/error.log。难道要把系统路径也授权给agent用户？不，Rabi想到了一招变通：只要Rabi自己用root执行tail -f /var/log/nginx/error.log | tee /tmp/error.log，实时把/var/log/nginx/error.log的内容转录到权限开放的/tmp/error.log，Agent不就能毫无阻碍地读取了？
这个方法很奏效，有了报错信息的加持，Agent很快就修出了一版正常工作的子主题，为文章增加了“动态”类型。Rabi随即发布了一条用来观察效果的动态：
因为Rabi还没有启动（悲）
好吧，这里没有保存下来第一版动态框的截图。但是讲真，被丑到了。
虽说确实不能指望Coding Agent有什么审美，但是能提需求啊。好在Rabi对CSS也是略通一二，知道元素都叫什么，于是边看调整情况边反馈，不多时就实现出了现在这一版能看得过去的动态框。
紧接着Rabi发现动态出现在了侧边栏的文章聚合中，心想这不对吧。于是又提出新需求让Agent修改侧边栏小工具，从文章列表里排除掉所有动态，但是覆盖原有组件可算不上一招好棋，一下子崩坏3了。好在Rabi马上回过味来，为什么不重新写一个新的小工具呢？于是马上指示Agent撤销改动，写一个新的Kratos4Radio - 文章聚合小工具来实现这一功能，于是这个功能也平稳落地了。
最后把子主题丢到GitHub上方便版本控制，以后想到什么再做什么吧——
文章评论