最近如果关注 AI，几乎绕不开“龙虾”这个词。

大家一边惊叹“AI 操作系统”终于来了，一边到处晒自己的工作流、晒自己的 Agent、晒自己又让 AI 干成了什么事。我上个月其实也猛玩过一阵，各种工具轮着试，各种模型来回切，短短一段时间，光 Tokens 就烧掉大几百块钱。

刚开始也很兴奋，觉得这东西真是新时代要来了，但玩到后面，人反而逐渐冷静下来。

不是说这些东西不好用，恰恰相反，正因为它们太好用了，不由得让我惊出一身冷汗。设想一下，如果未来一个聊天群里 500 个人，真正日常发言的可能是 499 个个人 Ai BOT；一个短视频网站上，你连续刷几百条，看到的全是 AI 自己批量制造出来的垃圾内容；一个公众号、论坛、网站站点上，密密麻麻都是 AI 自动拼装出来的图文信息。

换句话说，我们未来很可能会生活在一个充满 AI 垃圾信息的环境里。

而这种环境越往前发展，我越觉得一定会有“逆 AI”的潮流出现，一定会有人重新强调“这是人写的”“这是人画的”“这是人拍的”，就像今天有人强调有机蔬菜、家庭农场那样。

对 AI 的一个底线判断

最近两年写过很多关于 Ai 的文章，就不讨论 Ai 实体机器人的大规模应用，光是在 IT 互联网应用层面，也是越来越觉得，AI 应用至少应该有一个最低底线。

我认为，对于普通人能直接看懂、感受的东西，比如文章、图像、视频、音乐、人与人之间的表达，尽可能还是要把这些领域还给真人来做。不是说 AI 完全不能碰，而是不能把这些东西理所当然地交给 AI 批量生产。

因为这些内容本来就是真实世界的一部分，它们的价值不只是“数据信息”，还包括表达者本身的情感。你今天看一篇文章，其实也不只是在看结论本身，而是在设身处地想着，这篇文章我到底在看什么，对我有什么用，如果我遇到这种事情怎么办，所有事情的终点终会落在现实世界。

但对于另外一类东西，我反而没有这么强的保守心理。

比如二进制代码、各种机器语言、编程语言，或者说信息革命以来各国程序员们为了让机器运行，搞出的无数中间层语言。严格说来，这些东西本来就不是给普通人看的，而是给机器用的。既然如此，如果 AI 在这些领域里直接发挥作用，未尝不是一件好事。

最近 VideCoding 的两个项目

也正是在这种心态下，这段时间我借助 OpenCode，连续做完了两个开源项目，一个是 Pocket-Hugo，后一个是 Pocket-Hugo-Theme。都是围绕 Hugo 这个全世界最快的网站构建框架来的，前者用于编辑发布，后者是一套网站模板。 。

严格说来，这两个项目其实算是一体的，因为我在开发 Pocket-Hugo 时，为它添加了独特的页面编辑功能，而这个功能，必须通过调整 Hugo 主题来实现。既然如此，我干脆就自己做个主题，而不是在别人主题的基础上去进行二次开发了。

也正是如此，我在做 PocketHugo 的时候，就已经预想了后面主题要怎么做，很多东西都可以复用，比如按钮、信息层级、卡片节奏、配色等等，都是直接挪到第二个项目，大大减轻了开发难度。

过程中，这一边写 PocketHugo，做出一点顺手的 UI 或交互，另一边 pocket-hugo-theme 就可以顺手复用；那边主题里想到一个更好的卡片布局、多语言切换或者移动端展示方式，这边工具里又能反过来吸收。整个过程其实就是一边研究、一边学习、一边 VibeCoding。

而在这个过程中，我自己反而成了最大的受益者。因为很多以前只是模模糊糊知道“可以这么写”的东西，这次在反复来回折腾里，被真正逼成了理解。无论是 Next.js、Go 语言，还是前端 CSS、Hugo 的各种模板机制，我都比以前有了更具体、更踏实的认识。

也正因为有了这三个前提，后面做 pocket-hugo-theme 这件事，在我这里就不只是“再做一个主题”那么简单了。

为什么还要再做一个主题

如果只是单纯找个主题用，其实 Hugo 官方主题站里已经有很多选择。像我之前长期使用的 Hugo-theme-stack ，后来换的 bear-cub 等，都是非常好的主题。

但我真正想要的，不只是“能用”，而是“正好适合”。

如果看过我那个魔改版 Hugo-theme-stack 以及 bear-cub 的朋友就知道，我一直是钟情于“图文捆绑”这种模式，也就是微信公众号这种默认展示模式。但很遗憾，因为 Hugo 的用户大部分都是 Geek，大部分网站内容也都是跟 Coding 有关，所以一般来说，配不配图对他们压根没影响。甚至网上还有很多 Small Web 项目，一个个在拼自己的网站到底能极限压缩到多小，100KB 都已经排不上号，最小的好像才几 KB。

另一个重要的问题是，我一直想寻求一个手机上发布文章的稳定方案，这一点我在前一篇关于 Pocket Hugo 上线的文章已经讲到，这里就不再赘述。虽然我也很喜欢 IDE 工具，但挡不住，手机上用 IDE 实在是太痛苦了，特别是 iPhone 上默认输入法与网页输入框里边那些“反人类”的交互，相信但凡在 iPhone 的 Github APP 上复制过、修改过代码的都知道有多难受。

所以，最终，这次我想做的，就是一款封面图更突出、卡片感更强、同时又适合长期个人写作的图文式主题。

我是如何开发这款主题的

Hugo 主题的开发，讲起来其实挺容易。起码，在我混迹 Hugo 论坛的这几年，看到一堆北欧、北美五六十岁“老头们”每次都是用几行代码搞定一个页面模板。

但真正下手后却发现，这玩意也不是那么容易。因为我首先需要它能在我自己的网站上运行起来。

于是我几乎是把原来 Hugo-theme-stack 和 bear-cub 用过的各种组件，一个个全部先搬过来测试。

过程中也不知道经历了多少次 Hugo server 构建失败，最后一点一点才把模板搭建起来。

但也正是这个过程，让我后续开发受了不少苦头，因为前边这个过程，本质上是建立在它只服务我一个人的前提之上。各种元素都被我写死了，甚至一些页面结构和图片习惯，也都是完全围着我自己的写作方式转的。对个人来说，这种写法问题不大，反正怎么顺手怎么来，可一旦要把它拿出来开源，问题就立刻暴露了。

比如网站头部各种元素，这些东西以前在我网站里都是写死的；又比如各种组件、图片效果和各种功能，这些以前也都是“我自己知道就行”。但真要开源，就得一项一项改成配置，让别人也能看懂、也能用。

这里边最麻烦的其实不是写模板，而是反复判断什么应该保留成主题性格，什么又必须开放给用户自己设。

同时，为了发到 Hugo 主题站，还得尽量把多语言、注释、bundle、封面图、演示站这些东西都做出来。后面我又补了一堆示例文章和页面。做到这一步，我才更明显地感觉到，做自己的网站和做开源主题完全不是一回事。前者内容是目的，主题只是载体，后者内容反而成了说明书。

而且在这个过程中，Pocket Hugo 其实也一直在反过来逼着这个主题成长。因为我原本在开发 Pocket Hugo 时就是完全按照个人需求来的，如果别人恰好有相同需求就可以用我的方案。但后来，为了上线开源，我也不得不从头修改。过程中，还有人提 issue 说想要一个仅在本地运行的无需 Github 鉴权的版本，又多耗费了我几个小时。

最后，我几乎是把这个主题但凡能自定义的地方，都添加成了具体配置项。而这个过程，对我个人而言，几乎是重塑了对 Hugo 的认识，就像在不断逼问自己，为什么要这么设置，为什么不能那样设置，到底什么样的设定才是更好，更符合实际使用需求。

当然，我现在当然不敢这个主题已经有多成熟。一个主题这种东西，本来就是边用边改，边写边长的。但至少到今天，我已经可以很确定地说，我做这件事不是为了再往网上多堆一份 AI 时代的模板垃圾，而是想给 Hugo 这个老派、笨拙、却依然很可靠的世界，再添一块真正能被人长期使用的砖。