Shelf 这个功能复用了我之前的一个小项目。

我一直有在 Notion 里记录生活轨迹的习惯，主要是书和电影。早些时候，为了把 Notion 里的数据库改造得更好看，也更符合自己的使用习惯，我用 AI 帮忙写了一套网页信息抓取功能。后端主要由 Cloudflare Worker 处理抓取和写入。因为浏览器 extension 需要上架和审核，为了更轻量，前端触发方式最后做成了一个 bookmarklet。

再往后，我把授权部分拆成了 Notion OAuth。这样其他人如果复制了我的 Notion 模板，也可以一步步 set up，接入自己的 Notion workspace。这本来是一个独立的小工具。但在改进个人站时，我也想把这部分信息展示出来，而且最好能复用现有的东西。于是我在 Notion 数据库里多加了一个字段，用来选择某条记录是否 publish 到网站上，再通过 Worker 触发同步。

前端部分，尤其是效果和审美的实现，主要是靠 Claude 和 Gemini 一起讨论出来的。我发现 Codex 在这类视觉想象和风格探索上还欠缺许多，但它在把明确的方案落地成代码时很可靠。

6 月 7 号的这次更新，是在书籍和电影页面里加入了一个 Gesture Mode。此前我没有真正接触过视觉识别相关的东西，做这个的过程中才知道，浏览器里已经有很多成熟、免费的手部识别和 landmark detection 库可以使用，比如 MediaPipe Hands。这个功能本身只是一个小实验，但它让我很具体地意识到，在很近的未来，人与电子信息的日常交互未必还要被鼠标和键盘这套模式牢牢限制住。

Hoot 🦉

Hoot 的产生，最开始是因为我想在这个个人站里更显性地引入 AI。尽管在写作流程里，其实已经有 AI 生成 metadata 的环节，但那更像是后台流程的一部分，并不是访客可以直接感知到的东西。

创造大概有两种方式。一种是先有问题，然后寻找解决问题的工具。这个工具可以是现有的，也可以是从无到有生出来的。另一种方式是先有工具，然后再考虑它可以解决什么问题。后一种方式里的问题通常没有那么迫切，否则大概早就会采取第一种方式了。

在这里，我是先有了 AI 这个工具，才很自然地开始想：它能做什么？大语言模型的特性是能“说人话”，而现在的检索、索引和工具调用能力，又让它有机会说一些有依据的人话。于是便有了 Hoot：一个可以回答我公开信息的 assistant。

AI 还有调用工具的能力，所以它也很自然地改进了 contact 功能。以前传统博客通常是在 Contact 页面放一个 email 地址，或者触发邮件客户端。而 Hoot 可以在相关对话里触发 workflow，把信息发送到我的 Telegram bot。额外的，我也可以知道联系者在发起联系前问过哪些问题，从而理解这个联系发生的上下文。

English version

Shelf

The Shelf feature reuses a small project I had built earlier.

I have long had the habit of recording traces of my life in Notion, mostly books and films. Earlier, in order to make my Notion database look better and fit my own usage habits more closely, I asked AI to help me build a web information scraping workflow. The backend is mainly handled by Cloudflare Workers, which fetch information and write it into Notion. Because publishing and reviewing a browser extension would add extra friction, I made the front-end trigger a lightweight bookmarklet instead.

Later, I separated the authorization flow into Notion OAuth. This means that if someone copies my Notion template, they can set it up step by step and connect it to their own Notion workspace. Originally, this was an independent tool. But while improving my personal site, I also wanted to show part of this information here, ideally by reusing what already existed. So I added another field in the Notion database to decide whether a record should be published to the website, then used a Worker to trigger the sync.

The front-end part, especially the interaction and visual direction, came mostly from discussions with Claude and Gemini. I find that Codex is still weaker at this kind of visual imagination and style exploration, but it is reliable when the plan is already clear and needs to be turned into code.

The June 7 update added Gesture Mode to the books and films pages. Before this, I had not really worked with computer vision. During the process, I learned that there are already mature and free hand-tracking and landmark detection libraries available in the browser, such as MediaPipe Hands. The feature itself is only a small experiment, but it made me feel very concretely that in the near future, everyday interaction with digital information may not need to remain so tightly bound to the familiar mouse-and-keyboard model.

Hoot 🦉

Hoot began with a simple desire: I wanted to introduce AI into this personal site in a more visible way. AI was already part of my writing workflow, especially in generating metadata, but that was more of a background process. It was not something visitors could directly experience.

There are roughly two ways to create things. One starts with a problem, then looks for a tool to solve it. The tool can already exist, or it can be built from scratch. The other starts with a tool, then asks what problems it might solve. Problems in the second category are usually less urgent; otherwise, they would probably have already triggered the first path.

Here, I had AI as a tool first, and it was natural to start asking: what can it do? The defining quality of large language models is that they can speak in human language. With today’s retrieval, indexing, and tool-calling capabilities, they can also speak with some grounding. That became Hoot: an assistant that can answer questions about my public information.

AI can also call tools, so it naturally improved the contact flow as well. A traditional blog usually puts an email address on the Contact page, or opens an email client. Hoot can trigger a workflow during a relevant conversation and send the message to my Telegram bot. As an extra benefit, I can also see what questions the person asked before contacting me, which gives me more context for why the contact happened.

5 月 11 号的这次更新，进一步把一些写作流程自动化了。

之前用 Hugo 写作，需要先在 terminal 里跑命令生成新的 Markdown 文件；写完后，还要再回到 terminal 里构建并推送。整个流程分散在多个地方。如果我想在文中引用图片，还需要把图片特别放到某个目录下。对一个原本应该顺畅的写作过程来说，这些摩擦都太明显了。

最开始我想象中的理想状态，是能直接在自己的网站上写作并发布。但和 AI 讨论几轮后，我意识到这件事的工程量其实很大：自己写编辑器的体验大概率不如现成工具，还需要考虑认证、存储、后端和部署成本。于是平衡之后，我选择把本来就很习惯的 Obsidian 融合进来。现在从创建新 post，到插入图片，再到最后 git push，都可以尽量在同一个写作窗口里完成。

这样的事情还有很多。想要实现什么，总是有成本的。一个现实的理想主义者必须不断做这样的考量和决策，才能让一个不那么糟的东西真正成型。前段时间看《巴拉巴西成功定律》，里面提到 Q 因子，可以简单理解为一个人把想法转化为成果的能力。若再细究，我觉得它也包含一种“妥协并推动”的能力。这里的妥协并不是降低标准，而是为了推动一个实体的产生。它远比一个单纯好的 idea 更重要。

Voice to inbox - capture ideas anytime

写作的另一个摩擦，是表达冲动的收集。很多想要表达的东西，并不是产生于正襟危坐在电脑前、准备开始写作的那一刻，而是发生在更早之前，更随机的场合。

考虑到场景和成本，我最后确定使用 iPhone 自带的 Shortcuts 和转录能力。转录效果没有那么理想，但在当前阶段已经够用。后续如何触发自动写入，在和 AI 讨论时出现过几版方案。

最初，在 Claude 和 ChatGPT 的一致确认下，我继续尝试使用 Telegram bot 来接收转录信息，并进一步通过 Cloudflare Worker 写入本地 Obsidian 的 inbox 文件。但实际测试后发现，这条链路并不成立。更准确地说，Telegram Bot API 本身可以接收消息，也可以发送消息；真正的问题是，运行在 Cloudflare 上的 Worker 没有办法直接写入我 Mac 本地的 Obsidian vault，除非我另外暴露一个本地服务、使用同步目录，或引入额外的中转层。也就是说，Telegram 可以作为消息入口，但它并不能神奇地绕过本地文件系统的边界。

实践中的失败也纠正了 AI 一开始给出的幻觉。确认“此路不通”之后，我们换了另一个方案：使用 iCloud 做中转。这个方案最开始被我否决，是因为我以为它会带来额外成本，而我并不想为了这件小事再花钱买 iCloud。后来经 AI 解释，这类文本数据量非常小，免费空间远远够用，而且它本来就在 Apple 生态内，和 Shortcuts 的连接也更自然。

这次经历很好地说明了如何应对 AI 的幻觉问题：要么依靠人类原本就有的相关知识，提前意识到方案行不通；要么就靠实践出真知。而现实中，绝大多数情况都是后者。

English version

Writing workflow with Obsidian

The update on May 11 further automated parts of my writing workflow.

Previously, writing with Hugo meant running a command in the terminal to create a new Markdown file. After writing, I had to return to the terminal to build and push the site. The whole process was split across several places. If I wanted to reference images in a post, I also had to put them into a specific folder. For something that should feel like writing, there was too much friction.

At first, my ideal state was to write and publish directly on my own website. But after a few rounds of discussion with AI, I realized that the engineering cost would be quite high. A self-built editor would probably be worse than existing tools, and I would also need to think about authentication, storage, backend logic, and deployment costs. So I chose a more balanced path: integrating Obsidian, a tool I already use comfortably. Now, creating a new post, inserting images, and finally running git push can all happen as much as possible within the same writing window.

There are many more things like this. Everything I want to build comes with a cost. A practical idealist has to keep making these trade-offs and decisions in order to make something real, even if it is imperfect. In The Formula, Barabasi writes about the Q factor, which can be roughly understood as the ability to turn ideas into outcomes. Looking more closely, I think it also includes the ability to compromise and keep pushing. This kind of compromise is not about lowering standards; it is about helping something concrete come into being. That matters far more than simply having a good idea.

Voice to inbox - capture ideas anytime

Another source of friction in writing is capturing the impulse to express something. Many things I want to write do not appear at the moment when I sit properly in front of a computer and decide to start writing. They happen earlier, in more random places.

Given the context and cost, I eventually chose to use iPhone Shortcuts and the built-in transcription capability. The transcription quality is not perfect, but it is good enough for now. The next question was how to trigger the content to be written automatically, and during my discussions with AI, several possible designs came up.

At first, with both Claude and ChatGPT agreeing, I tried to keep using a Telegram bot to receive the transcribed text, then have a Cloudflare Worker write it into the local inbox folder of my Obsidian vault. In practice, that chain did not work. More precisely, the problem is not that the Telegram Bot API can only receive messages and cannot send them. The Bot API can do both. The real issue is that a Worker running on Cloudflare cannot directly write to my local Obsidian vault on my Mac unless I expose a local service, use a synced folder, or introduce another relay layer. Telegram can be a message entry point, but it cannot magically bypass the boundary of the local filesystem.

That failure in practice corrected the hallucination AI gave me at first. Once we confirmed that this route was blocked, we moved to another design: using iCloud as the relay. I initially rejected this option because I thought it would create extra cost, and I did not want to pay for more iCloud storage just for this small workflow. But after AI explained it, the amount of text involved is tiny, the free tier is more than enough, and iCloud already lives inside the Apple ecosystem, which makes it much easier to connect with Shortcuts.

This experience is a good example of how to deal with AI hallucination. Either you rely on relevant knowledge you already have and notice early that a plan will not work, or you let practice reveal the truth. In reality, most cases are solved through the second path.

这个网站之前只是一个简单的 Hugo 静态博客，托管在 GitHub 上。那时还没有 AI 帮忙，只能尽量找别人搭好的 UI 框架，可以改动的地方少得可怜。后来冒出一个念头：让 Codex 帮我把网站大改一遍。于是我把网站迁移到了 Cloudflare。除了前端样式终于可以相对“随心所欲”地调整，也顺手加了几个额外的小功能。

时间过去并不久，但我已经有点记不清最初为什么想做这些东西了。若要细究，可能是因为之前做别的项目时发现 Cloudflare 有很多免费、好用、并且对个人项目非常友好的东西。比如 Cloudflare Workers，它是运行在 Cloudflare 边缘网络上的 serverless 运行时，概念上有点像 AWS Lambda@Edge：不需要自己维护服务器，却可以在离用户更近的地方处理请求。知道了有什么工具，剩下的就变成了关于小小欲望的问题：我到底想要什么？

我希望这里不只是一个能放文字的地方。它应该有真正的功能性，也应该是美的。除此之外，这里除了是我的个人空间，也可以是一个建立 connection 的场所。于是有了下面两个小部分，可以在桌面端首页看到：

Thoughts

最开始的念头是，我想要一个能“发推特”的地方。Blog 偏向于长文，并不是一个能常常更新的地方。更多时候，我的表达欲望只是一句话，需要一个即时的出口。于是产生了这个 Thoughts 块：它连接了我的 Telegram bot，后端由 Cloudflare Workers 实现。

Visitors

这里除了是我的空间，也希望能留下别人的痕迹。后续我可能会进一步加上评论功能，但在那之前，我想先有一个更轻、更好玩的“留爪”功能。

兼顾成本和趣味之后，就有了 Visitors 块。它在首页右侧，访客可以留下姓名和坐标。由于 vibe coding 很多时候只需要告诉 AI 我想要什么，具体技术细节不一定要马上知道，所以很长一段时间里，我其实并不知道这些访客信息到底存到了哪里。直到后来让朋友帮忙测试时，触发了操作过多的 limit，我才开始关注这个问题，问 Codex 它到底把数据存在哪里、limit 又是怎么实现的。由此才知道，它当时使用了 Cloudflare Cache 来保存和读取这类轻量状态，并用缓存键与过期时间做了简单的限流。

严格说，Cloudflare Cache 更适合缓存请求响应，并不是一个真正的数据库。如果这个功能之后变得更正式，应该迁移到 Cloudflare KV、D1 或 Durable Objects 这类更明确的存储方案。但对这个轻量、低成本、带实验性质的小模块来说，Cache 的确暂时够用。

另外值得一提的是，最初这个模块并没有这么好玩，只有文字信息，显得有点干巴巴的。好像是朋友的一句话，说文字漂浮的效果像“小魂儿”，于是才有了后来这个更具象的小魂儿。

现在和 Codex 合作做东西时，我最喜欢的部分常常是：如果暂时不考虑技术限制，我能想象出什么？这个过程中，想象力很多时候是模糊的，需要和 ChatGPT、Claude 讨论很多次。一个很惊喜的点是，Claude 在和我确认具体想象时，会主动直接帮我画出来，包括配色方案，也包括这个小魂儿的效果。然后我拿着它生成的 prompt，再继续让 Codex 真的把它实现出来。

English version

Recently, I have been slightly obsessed with using Codex to build all kinds of ideas that suddenly come to mind.

This website used to be a simple Hugo static blog hosted on GitHub. Back then, without AI helping me, I could only rely on UI frameworks built by others, which left very little room for meaningful customization. Later, I had the idea of asking Codex to help me redesign the site, and I migrated it to Cloudflare. Besides making the front-end style much easier to adjust, I also added a few small features.

Not much time has passed, but I already find it a little hard to remember why I decided to build these things in the first place. If I trace it back, it probably started from other projects where I discovered that Cloudflare offers many free, powerful, and personal-project-friendly tools. Cloudflare Workers, for example, is a serverless runtime running on Cloudflare’s edge network. Conceptually, it is somewhat similar to AWS Lambda@Edge: I do not need to maintain my own server, but I can still process requests closer to users. Once I knew what tools were available, the rest became a question of small desires: what exactly did I want?

I wanted this site to be more than a place for text. It should be functional, and it should also be beautiful. Beyond that, while this is my personal space, it can also be a place for connection. That led to the following two small sections, which can be seen on the desktop homepage:

Thoughts

The original idea was simple: I wanted a place where I could “tweet.” A blog is more suited to long-form writing, and it is not something I update constantly. Most of the time, my urge to express something is only a sentence long. It needs an immediate outlet. That is how the Thoughts section came about: it is connected to my Telegram bot, with the backend implemented through Cloudflare Workers.

Visitors

Besides being my own space, I also wanted this site to leave traces of other people. I may add a proper comment feature later, but before that, I wanted something lighter and more playful.

Balancing cost and fun led to the Visitors section. It sits on the right side of the homepage, where visitors can leave their name and location. Since vibe coding often lets me simply tell AI what I want without immediately understanding every technical detail, for quite a while I actually did not know where these visitor records were stored. It was only after I asked friends to test the feature and they triggered a rate limit that I started paying attention. I asked Codex where the data was stored and how the limit was implemented. That was when I learned that it was using Cloudflare Cache to store and retrieve this lightweight state, with cache keys and expiration times providing a simple form of rate limiting.

Strictly speaking, Cloudflare Cache is better suited for caching request responses; it is not a real database. If this feature becomes more formal later, it should probably move to Cloudflare KV, D1, or Durable Objects, which are clearer storage options. But for a lightweight, low-cost, experimental feature like this, Cache is good enough for now.

Another detail worth mentioning is that this module was not very fun at first. It only showed text, which felt dry. Then a friend said the floating text looked like little wandering spirits, and that comment eventually became the more concrete little spirit you see now.

One of my favorite parts of working with Codex is asking myself: if I temporarily ignore technical constraints, what can I imagine? During this process, imagination is often blurry, and I need to discuss the idea with ChatGPT and Claude many times. One surprising thing is that Claude sometimes helps me make the idea visual while confirming it with me, including color palettes and the effect of the little spirit. Then I take the prompt it generates and ask Codex to actually implement it.

No sampling permission. Please do not sue me. 🥲

Please enjoy! 😎

Sampling source

Ascendence from “Who Killed AI?” by Kenny Garrett & Svoy.

Vocal from the Wix ads. You may encounter it already if you use YouTube.

Benjamin Franklin
Leonardo da Vinci
Friedrich Hayek
James Stewart
Novak Djokovic
Herbert A. Simon
Emily Dickinson
Alan Turing
Ada Lovelace
Derek Sivers
Yuan Li
Tsai Ing-wen
孙玲

Like the dark side of the Moon

The scale tilts to the side

Where hearts with heavy desire reside

Countless plays abide by one rule

One soul on fire —

Till it cools

A burning gaze —

Rests upon a nameless bloom

Scorched —

Descending into the tomb