Co-authored by Claude Opus 4.8

This blog is summarized via my personal notes on the Transformer architecture, which is the backbone of Large Language Models (LLMs) like Claude and GPT. It provides a detailed walkthrough of the entire process, from tokenization to generating a probability distribution over the vocabulary, highlighting key components such as Q/K/V computation, attention mechanisms, and the differences between encoder-decoder and decoder-only models.

Everything here is general, public knowledge (see the Elastic overview linked at the end). There is no private or proprietary code involved. Because the original notes leaned heavily on diagrams, every figure below is redrawn as an ASCII flow so the post stays self-contained.

Lessons learned from a recent project that heavily leverages Vibe Coding

Co-authored by Claude Opus 4.7

最近几个月在做一个常驻在桌面端的守护进程：它对外扮演一个”被远程控制”的入口，远端的 bot、本机的 desktop、本机的 TUI 可以同时连进来，驱动同一台机器上跑着的 coding agent —— 不管这个 agent 是 claude code、codex、还是内部代号 hx 的 agent CLI。同一个 session 任务，A 端发起、B 端跟看、C 端续问，消息通过这个进程在多端之间保持同步与统一；机器在 NAT 后侧也好、断线重连也好，这层”对所有端表现一致”的抽象不破。

Co-authored by Claude Sonnet 4.6

Videos, audio, and images in a client app are usually hosted on a CDN (OSS / S3). For auth and hot-link protection, the backend hands out signed, time-limited URLs — a plain GET after expiry returns 403. The tricky part is that the client has no control over when a URL is consumed: a user might tap a thumbnail right away, or scroll back to an old message a week later and only then start playback.

To handle this we introduced a resourceUrlExchange endpoint that swaps an “original URL” for “a signed URL that’s valid right now” before downloading or playing. But if every playback or render calls the endpoint, a list view easily fires dozens of concurrent requests, blocking first paint and burning bandwidth. This post walks through the five layers we built around that problem, and how they compose into a nearly transparent caching pipeline.

The snippets below happen to use a Flutter idiom, but the design itself is platform-agnostic — the same layering maps cleanly onto iOS, Android, Web, or RN clients; only the package names change.

Co-authored by Claude Opus 4.7

LLM 时代有个很诱人的玩法：让模型直接说出 UI 应该长什么样，端上拿到一份描述就把界面拼出来。比起预先把每个页面写死，这种「server 推一份意图，client 渲一份界面」的形态对 AI 类业务太顺手了 —— 模型每讲一句话，界面跟着变一次，不用再发版。

Flutter 官方有一份 genui 在做这件事，但它的运行时跟它假设的服务端协议捏在一起卖。一旦你的服务端不是它那个形状 —— 不走 JSON-RPC、消息体判别 key 不一样、事件回传走另一条通道 —— 那份运行时就用不上了。

所以我把它的”形状”抽出来，写成了一个纯端侧的 SDR（Server-Driven Rendering）运行时：只对四类消息负责，剩下的怎么传、怎么发，全甩给宿主。这篇按「核心思路 → 调用路径（三个场景）→ 数据规约 → 取舍」走一遍。

Most “Figma to code” tools are vertical: pick a stack (usually React or Flutter), hard-code the mapping, ship a plugin. They work — until your codebase isn’t React or Flutter, or until your team’s component library, naming conventions, and design tokens don’t match the canned ones.

Over the past few months I built a different shape of the same tool: a stack-agnostic agent that treats the target framework as an injection point, paired with a desktop client that uses the agent itself as its backend. This post walks through both halves — the agent skill design and how it adapts to arbitrary stacks (Section 1), and the desktop UI that streams lifecycle events back from the agent and never opens a single REST endpoint of its own (Section 2).

Continue the discussion on gesture system in Flutter framework. Talking about Pointer/Gesture and HitTest.

Recently I developed a pure flutter application which related to AI virtual figure interaction. During the development process, I was impressed by the performance and flexibility of the Flutter framework. The plugins are mature and easy to use, and process is smooth (the overall core features are implemented within 2 months). This experience motivated me to explore the Flutter framework more deeply, especially the code under flutter/lib/src.