用 vibe coding 做了一个本地优先的 X/Twitter 书签管理插件，聊聊过程

起因其实很朴素：我自己的 X/Twitter 书签和点赞越攒越多，书签有一万多条，点赞有三万多条（以前把点赞当书签用）。

但真正想找某条内容时，原生列表基本只能一直往下翻。记得作者还好，不记得作者、只记得正文里某个词，几乎就只能放弃。

另一个让我有点不踏实的地方是，这些“收藏”实际上仍然完全依赖平台：账号状态、帖子删除、产品界面调整，都会影响之后还能不能找到。于是我想做一个很个人化的工具：把已经收藏过的内容沉淀到本地，能搜索、整理，也能自己备份。

最后做成了 Twitter Mark ，一个基于 WXT + React + TypeScript + Dexie 的浏览器扩展。

书签截图：

点赞截图：

它现在主要做几件事：

• 读取当前浏览器里已经登录的 X 会话，只读同步书签和点赞；


• 数据保存在本地 IndexedDB ，不要求再注册一个云端账号；


• 可以按正文、作者、语言、媒体类型和时间筛选，也可以自己打标签；


• 支持增量/全量同步、后台同步、暂停后继续，以及 JSON 导入导出；


• 同步过程不会替你发帖、点赞、关注，也不会取消书签。

实现中最麻烦的其实不是 UI ，而是“如何保证同步不会把已有数据搞坏”。x.com 的网页 GraphQL 并不是稳定的公开 API ，Query ID 、返回结构和限流都有可能变。所以我给自己定了几个硬约束：解析异常不能当成空列表，远端某次没返回的数据不能自动从本地删除；每一页数据写入后才推进 cursor ；中断、限流或浏览器退出后要能从 checkpoint 继续。

关于 vibe coding

这个项目大部分代码是用 vibe coding 的方式完成的，但实际过程并不是一句“帮我做个插件”然后等结果。

我先把产品边界写清楚，尤其是“本地优先、只读、已有数据优先”这几个不能破坏的原则；再把系统拆成 X 网页请求、同步引擎、存储层、任务调度和资料库 UI 几块。每次只让模型处理一个范围比较小、可以验证的改动，然后马上跑类型检查和测试，再用真实账号做小批量验证。

模型在搭页面、补类型、写重复性代码上确实很快，但在分页状态、失败恢复和数据一致性上，还是很容易给出“看起来能跑”的实现。比较有效的做法是先写清楚不变量，再让它根据这些约束补测试，而不是只看 happy path 。比如：cursor 什么时候可以提交、重复同步是否幂等、解析失败会不会误删本地数据、切换账号时任务会不会串数据，这些都需要人主动盯着。

我目前最大的体会是：vibe coding 很适合把一个人脑子里的小工具快速做出来，但前提是人要负责定义问题、控制范围和验收。模型可以加速实现，却不会自动替你做出正确的产品取舍。

项目现在已经能日常使用，但同步依赖 X 的网页接口，未来接口变化时仍可能需要跟着维护。我也还在继续打磨搜索、同步稳定性和跨浏览器体验。

如果你也有大量 X 书签/点赞，想听听大家平时是怎么整理的，以及对“本地资料库”这种做法最在意什么。

项目主页： https://twittermark.com

Chrome 商店： https://chromewebstore.google.com/detail/twitter-mark/phoiffgkjjfnjfljnjgmpobmanghlaga