一个技术人的知行笔记
这个系列写到这里，该聊点未来的事情了。
前三篇文章分别是：FreeInk 的全栈解析、硬件路线与软件路线的对比、各个项目的技术栈全景。这一篇我不打算再拉清单了——我想聊聊我看到的几个信号，以及它们可能会怎么改变我们读书这件事。
先说一个暴论：今天的电子书阅读器，在上手体验上，还没有超越十年前初代 Kindle Paperwhite 的水平。 无论是开源还是商业，市面上的阅读器本质上还是在做同一件事——把电子墨水屏换成分辨率更高的、加了前光、调了刷新率——但你在阅读器上能做的事情，和 2012 年没有本质区别。
翻页。标注。查词典。调字体。
就这些。
但这几年出现了一些有意思的信号，让我觉得这个局面可能快要被打破了。
前两篇文章聊了 FreeInk 的全栈设计和开源阅读器的硬件/软件路线之争。今天换个角度，从技术栈切入，看看这些项目的开发者们分别选择了什么工具来造轮子。
作为一个写了十几年代码的人，我有个习惯：看到一个开源项目，第一反应不是「这玩意儿能干啥」，而是「它怎么写的」。技术栈的选择往往暴露了一个项目的核心哲学——你选什么语言、什么框架、什么构建工具，背后都藏着你在乎什么、不在乎什么。
这篇就带你在开源阅读器的技术栈里走一圈。
上一篇文章聊了 FreeInk，一个从 SDK 到硬件全栈开源的电子墨水屏阅读器生态项目。文章发出去后，有朋友问我一个很直接的问题：
「FreeInk 和 unobox 不是竞品吗？你们做 unobox，为什么还要写文章推荐 FreeInk？」
这个问题聊开来，其实指向的是整个开源阅读器世界的一个基础分野。
你有没有经历过这样的场景？
项目会上，你和产品经理因为一个功能优先级吵了起来。你刚说完“这个需求技术上至少需要两周”，对方立刻回怼：“两周？竞品早就上线了，你们研发效率不行。” 会议室瞬间安静，你感觉脸上火辣辣的，心跳加速，血往上涌……
这时候，你心里有两个声音：一个说“必须当场怼回去，让他知道尊重人”；另一个说“算了，忍忍，别把关系搞僵”。
你到底该怎么做？
答案是：都不对。
当场爆发，你会把技术问题升级成人格冲突，后续合作直接崩盘；当场隐忍，你把情绪压进肚子里，三天后还觉得恶心——更糟的是，那个产品经理压根不知道你生气了，下次还敢。
真正的职场高手，会用一条铁律来应对：冲突管理的“黄金24小时”原则。
你经历过这种场景吗？需求评审会，产品经理刚说完方案，开发组长直接拍桌子：“这需求根本做不了，你们懂技术吗？”产品经理脸一黑：“客户就要这个，你做不了你去找客户说。”项目经理坐中间，手心冒汗，两边都不敢得罪，只能打圆场：“大家冷静一下，我们再想想办法……”结果会开完了，问题没解决，团队关系还崩了。
这不是冲突，是火并。冲突是良性的，火并是毁灭的。
很多项目经理怕冲突，一听到不同声音就紧张，觉得“团队和谐最重要”。但你仔细想想：一个从来没人争论的团队，真的是好团队吗？不，那是僵尸团队。所有人都在心里憋着，当面你好我好，背后互相甩锅。项目反而死在暗处。
真正健康的团队，不是没有冲突，而是能吵出结果。
为什么你带的团队总有人“带不动”？因为你在用同一把尺子量所有人。
带项目最怕什么？不是进度延迟，不是需求变更，而是你手下三个人，三种状态。
新人像只刚出壳的雏鸟，你怕他摔死；熟手像个准时上下班的公务员，不犯错也不上进；核心成员像个被掏空的陀螺，你再转就散架了。你用什么方法管他们？是不是开会时讲一遍要求，群里统一发一遍提醒，然后发现——新人没听懂，熟手嫌你啰嗦，核心成员在替你补位？
别这么干了。差异化管理的本质，不是“区别对待”，而是“对的人用对的方法”。
上周逛 Hacker News，一条 421 分的帖子直接把我拽住了。
FreeInk，一个号称要做「开源电子书阅读器全栈开放生态」的项目。站点干净利落，没有花哨的营销文案，开门见山：我们正在构建从软件、固件到硬件的每一层——全部开源，任何人拿去用、去改、去自己造。
看到这句话我脑子里冒出的第一个念头是：终于有人这么干了。