动手写 TokSync 之前，我花了两天做可行性分析。起因很简单：我同时在几台电脑上用好几种 AI 编程工具，想知道一个月到底用了多少 token、大概花了多少钱，却没有一个地方能把这些数字汇到一起。
两个参照
我主要看了两个开源项目。Tokscale 擅长本机采集：从各种工具的日志里读出 token 和成本，归一化，再做成好看的个人主页和 README 徽章。OpenSync 擅长多设备同步：把不同机器上的会话聚合起来，可以搜索、导出评测数据。
两者互补得很明显，所以最直接的念头是把它们拼起来。分析下来我没有这么做：不直接 fork，也不硬合并两边的前后端，而是新开一个 monorepo、新的数据契约，先把 collector-core → sync-agent → api → web 这几层边界设计清楚，再按最小范围一层层实现。两个项目都只当作参照——采集和归一化看 Tokscale，同步和聚合看 OpenSync。
最大的风险不在技术
写到隐私那一节，我改变了产品的重心。AI 编程会话里可能有源代码、密钥片段、客户数据、内部路径，甚至商业计划。一个默认把这些东西同步到服务器上的工具，再好用也让人不敢装。
于是第一版的默认策略变成了这样：
- 只同步用量指标，不同步消息正文、工具参数和工具输出；
- 会话内容同步作为以后的功能，开启时要逐台设备确认；
- 在本机做脱敏：密钥模式、路径匿名化、文件片段裁剪；
- 服务端可以按设备、按来源、按日期删除数据；
- API key 和设备令牌只存哈希，泄漏时可以单独撤销一台设备。
代价也要写进产品文案：只同步指标，就做不了全文搜索和评测导出。我觉得这个代价值得——先让人放心地装上，再谈更多功能。
先跑通本地闭环
5 月 16 日，仓库开始落地：pnpm 加 Turbo 的 monorepo，一个 Node 写的命令行 agent，Hono 做 API，Next.js 做网页，外加 worker 的健康检查和几个共享包。存储先用本地文件，不急着上 Postgres，用它跑通了第一版闭环：设备登录、用示例数据演练同步、正式同步、重复同步时跳过、仪表盘、公开主页、README 徽章，以及撤销和删除设备。
现在回头看，这份分析里最重要的一句话，是「默认不上报完整会话内容」。后来 TokSync 的很多设计，都是从这一句长出来的。