日常使用的 Google Docs、Notion 或各类在线文档，底层逻辑高度一致：用户敲下的每一个字符，都被实时同步到中心化服务器的数据库中。Aboard 推出的开源办公套件 Tiny Little Office 却彻底掀翻了这个设定。它包含文字处理、大纲、演示文稿、电子表格、计算器、绘图、图表制作、动画、日历及行程规划等 10 款轻量工具，整个应用不需要登录、不依赖后台数据库，甚至提出链接即文档的极简主张。
这并不是又一个套皮的前端网页。它的核心反常在于：整篇文档的所有内容，直接被压缩编码在网址的 Hash 片段中。
把十万字塞进两千个字符的算盘
在标准 HTTP 规范里，URL 中井号后面的 Hash（Fragment）根本不会发送给 Web 服务器。Tiny Little Office 抓住了这个底层机制：文档格式被组织为特定结构，浏览器前端载入静态脚本后，完全在本地对这一串字符进行解码和渲染。
让浏览器吞下一个完整文档，最大的瓶颈在于浏览器的地址栏和聊天工具对 URL 长度的忍受力。Tiny Little Office 将应用层的目标长度预算死死卡在 2,048 字符以内，一旦超过 2,000 字符，内部的语法检查器就会立即警示，防止被聊天软件强行截断。同时，其解压防御上限被固定在 4 MiB，避免恶意构造的长文本撑爆浏览器内存。
为了在如此狭窄的字符通道里塞进大纲、幻灯片乃至表格，工程实现采用了一套多层压缩策略：
- 系统会在原始 UTF-8、原生 DEFLATE 以及挂载高频词固定字典的 DEFLATE 之间遍历比对。
- 自动挑选体积最小的一组产物，通过 fflate 转化为经过定制修改的 Base64 字母表。
- 只有经过这层绞肉机式的压缩，一段包含标题、排版和数据表格的富文本才能被塞进短短几行字符里。
数据不是存放在云端服务器的记录，而是随身携带的报文。
协作倒退三十年，却找回了信件的秩序
当今协作工具普遍推崇多人实时光标飞舞，但 Tiny Little Office 彻底放弃了 CRDT 或 OT 协同算法。它的协作逻辑退回到了古老的分叉副本模式：你写完一份文档，生成一个包含当前状态的长链接发给同事；对方点开后若做修改，本地会重新计算编码，产生一个完全不同的全新链接回传给你。
这种模式看似原始，却少见地重塑了一种确定性。过去几十年里，工具把文档变成了随时变动的活页纸，协作者永远不知道哪一行正在被谁改写。Tiny Little Office 则更像寄信：每一封信寄出时都是盖棺定论的快照，回信则是一份新的草稿。没有后台服务在中间仲裁版本，双方的交互就是报文的单向传递。
零服务端的自由，与悄悄裂开的隐私缝隙
很多人初见这种纯前端架构，第一反应往往是绝对安全，但事实恰恰相反。
普通长链接虽然绕过了 Tiny Little Office 自己的服务器，却将全文暴露在整个互联网的基础设施眼皮底下。浏览器的访问历史会记录它，企业的邮件过滤网关会扫描它，聊天软件更是会顺着链接爬取内容。
为了让链接好看，套件内建了基于浏览器 AES-256-GCM 的短链接中转。加密密钥保留在短链的 Hash 片段中，密文上限支持到 16,384 个字符。然而短链生命周期最长只有 30 天，一旦过期便永久损毁，完全无法承担归档用途。
- 风险.若为了美观开启社交分享卡片预览，系统会在未经加密的情况下将第一页渲染图、标题及前 200 个字符直接上传保留一个月。追求隐私的用户极易在这里被静默破防。
人类退场之后，它成了大模型的最佳容器
Tiny Little Office 最大的受众，可能根本不是坐在写字楼里码字的人类。
它的核心威力在于完全符合纯文本状态机的设定。该项目在发布的同时开源了规范并提供 llms.txt。以往大语言模型想要交付一个排版工整的 PPT 或电子表格，必须借助复杂的第三方 API、申请配额并维护持久化会话；而面对 Tiny Little Office，大模型只需要在本地执行一遍压缩算法，就能在对话流里直接抛出一个立等可取的文档链接。
无须预热环境，无须建立租户，也没有数据库垃圾需要定期清理。人类在追求功能大而全的道路上不断堆砌数据库与微服务，而当真正需要让自动化代理高频分发临时信息时，这种被现代软件工程视作极客玩具的无状态协议，反而成了阻力最小的通信管道。