一个技术人的知行笔记
这个系列写到这里，该聊点未来的事情了。
前三篇文章分别是：FreeInk 的全栈解析、硬件路线与软件路线的对比、各个项目的技术栈全景。这一篇我不打算再拉清单了——我想聊聊我看到的几个信号，以及它们可能会怎么改变我们读书这件事。
先说一个暴论：今天的电子书阅读器，在上手体验上，还没有超越十年前初代 Kindle Paperwhite 的水平。 无论是开源还是商业，市面上的阅读器本质上还是在做同一件事——把电子墨水屏换成分辨率更高的、加了前光、调了刷新率——但你在阅读器上能做的事情，和 2012 年没有本质区别。
翻页。标注。查词典。调字体。
就这些。
但这几年出现了一些有意思的信号，让我觉得这个局面可能快要被打破了。
前两篇文章聊了 FreeInk 的全栈设计和开源阅读器的硬件/软件路线之争。今天换个角度，从技术栈切入，看看这些项目的开发者们分别选择了什么工具来造轮子。
作为一个写了十几年代码的人，我有个习惯：看到一个开源项目，第一反应不是「这玩意儿能干啥」，而是「它怎么写的」。技术栈的选择往往暴露了一个项目的核心哲学——你选什么语言、什么框架、什么构建工具，背后都藏着你在乎什么、不在乎什么。
这篇就带你在开源阅读器的技术栈里走一圈。
上一篇文章聊了 FreeInk，一个从 SDK 到硬件全栈开源的电子墨水屏阅读器生态项目。文章发出去后，有朋友问我一个很直接的问题：
「FreeInk 和 unobox 不是竞品吗？你们做 unobox，为什么还要写文章推荐 FreeInk？」
这个问题聊开来，其实指向的是整个开源阅读器世界的一个基础分野。
上周逛 Hacker News，一条 421 分的帖子直接把我拽住了。
FreeInk，一个号称要做「开源电子书阅读器全栈开放生态」的项目。站点干净利落，没有花哨的营销文案，开门见山：我们正在构建从软件、固件到硬件的每一层——全部开源，任何人拿去用、去改、去自己造。
看到这句话我脑子里冒出的第一个念头是：终于有人这么干了。
项目推进不下去，往往不是因为事儿太难，而是因为人“炸”了。
你有没有遇到过这样的情况：评审会上，开发总监拍着桌子说“这个需求根本做不了”，产品经理当场红着眼眶怼回去“之前明明确认过”。会议室安静三秒，项目经理夹在中间，手心冒汗，头脑空白。
我知道你想当“和事佬”，但往往越劝越乱——你刚说“大家都冷静一下”，结果两个人同时转向你：“你评评理！”
这就是典型的情绪矛盾。不是技术争议，不是资源冲突，而是人带着情绪在沟通。这时候，任何逻辑推导、进度压力、流程规范都没用。你得先处理情绪，再处理问题。
你有没有遇到过这种情况：项目进度延迟了，开会追责，A部门说“B部门没给我们输入”，B部门说“C部门的审批卡着”，C部门说“我们标准一直这样，你们不知道吗？”——一圈下来，问题原地转圈，没人认领。
这不是沟通问题。这是利益不匹配、目标不一致、流程模糊三者共同作用的结果。
我见过太多项目经理把精力花在“催”和“求”上，今天请吃饭，明天发红包。有用吗？有用，但治标不治本。真正解决跨部门推诿，你得先看懂：他们为什么可以心安理得地“推”。
上周我和一位项目经理聊天，他抱怨：“每次开会我都认真记录，大家也确认了。可过两周追进度，没人认账了，都说‘当时没说这个’‘我理解的是那个意思’。”
我问：“你的纪要怎么写的？”
他给我看了一份：“讨论了A方案的风险，确认了B功能的上线时间，C需求的优先级待定。”
典型的问题——这不是纪要，这是日记。 日记是记给自己看的，纪要是给所有人签字的承诺书。
这也是很多项目失控的起点：会开了，纪要发了，但没人当回事，因为纪要里没有“谁在什么时候必须交付什么”。