一句话总结

刷写 microSD 卡竟然如此之难

亮点

• TinyPilot 迎来了有史以来营收第二高的月份。
• TinyPilot 向第三方代工厂转移生产的工作已接近完成。
• 我似乎已经踏入了机械键盘的“深坑”。

目标评分

每个月初，我都会定下当月想要完成的目标。以下是本月的完成情况：

尽快将生产转移至代工厂

• 结果：第一批货出了点小问题，但转移应该很快就能完成。
• 评分：B

我们已经收到了代工厂生产的第一批量产设备，并计划在 11 月发给客户。

我原本希望这批货完美无缺，可以直接宣告转移完成。可惜组装过程中出现了一个小错误，我们不得不在办公室自行修复，因此还没能实现从工厂到仓库再到客户的顺畅流转。

精简 TinyPilot 软件发布流程中的人工环节

• 结果：我们取消了一项原本只能由我来完成的手动发布任务。
• 评分：A

我一直在想办法自动化、简化 TinyPilot 的软件发布流程，尤其希望把自己从日常流程的关键路径中解放出来。10 月份，我们在这两方面都取得了进展：当有新版本的 TinyPilot Pro 发布时，TinyPilot 官网的更新流程实现了自动化。

过去，我发布新版本后，还要手动更新官网上的下载链接。现在，官网已与我们的更新服务同步，能够自动发现新版本。

制定更严格的 TinyPilot Pro 授权执行方案

• 结果：尚未在方案上取得进展。
• 评分：F

10 月份开发团队的可用时间比我预期的要少，因此我们最终未能在授权执行方案上取得进展。

TinyPilot 数据一览

这是 TinyPilot 历史上业绩第二好的一个月，而我完全不知道原因。数据分析中看不出任何异常，我也没有注意到新的评测或提及。我们在 2022 年 10 月也曾迎来强劲销量，所以这可能只是季节性因素。

我原本预计数据会略有下滑，因为我一直专注于生产转移，没有在营销上投入。很高兴看到我们能靠惯性维持，但我也已在 2023 年最后几个月开始重新加大对增长的投入。

与新代工厂一起解决 microSD 刷写问题

不翼而飞的存储卡

TinyPilot 设备使用一种叫做 microSD 的小存储卡来保存数据。就在代工厂要寄出第一批 TinyPilot 样机前几天，他们发现我寄去的参考样机里插着 microSD 卡，于是问我：是否需要 microSD 卡？

原来，代工厂的物料清单（BOM）里根本没有包含 microSD 卡，而我也一直没发现少了这一项。

好在购买和刷写 microSD 卡是个快速而简单的过程。我们本来就有一家供应商，能生产印有 TinyPilot 标志的 microSD 卡。我们让代工厂与这家供应商对接，并向代工厂说明了如何将 TinyPilot 的系统刷入 microSD 卡。

我和代工厂商量后认为，没必要因为 microSD 卡而推迟寄送样机。我们决定让他们先寄出不含 microSD 卡的设备，一两周后再补寄存储卡。

结果第一批样机问题太多，我完全把 microSD 的事忘了，代工厂也就一直没有寄来。

核验 microSD 是否正确刷写

到了 10 月中旬，代工厂表示他们已经修复了我提出的所有样机问题。他们准备寄来一小批试产设备，这批应该是完整成品，可以直接发给客户了。

我们仍计划对第一批货进行额外的质检，以确保它们符合我们内部的标准，其中一项就是检查代工厂是否正确刷写了 microSD 卡。

直到这批货预定到达的前两天，我才突然想到——我该怎么检查代工厂是否把 microSD 刷对了？我想确保卡上每一个字节都准确无误。

验证 microSD 并非易事，于是我请 TinyPilot 的技术支持团队写一个快速的 shell 脚本，将代工厂的 microSD 与我们的“黄金”镜像进行逐字节对比，并报告任何差异。他们及时在测试前完成了脚本。

第一批货到后，我插上一张 microSD，运行了完整性检查脚本，结果显示完全匹配。太好了！

我们又做了功能测试，一切都按预期工作。我非常开心。这意味着代工厂这批货完全做对了，我们可以宣告向第三方代工厂的过渡大功告成了。

就在我准备关闭最后一台测试用的 TinyPilot 时，我注意到一件事：视频设置并不是 TinyPilot 出厂时的默认值，看起来好像有人在我之前用过这台设备。

我关掉正在测试的设备，重新运行了 microSD 检查脚本。这一次，脚本理应报告有改动，因为我在测试中改了不少设置。然而，脚本却显示我的 microSD 与黄金镜像完全一致。

糟了。

尽管这个脚本在支持工程师的电脑上运行正常，但在我的测试环境中，它总是返回假阳性结果。

进一步检查 microSD 后发现，代工厂误解了我们的说明。我们本意是让他们用一张测试用的 microSD 做质检，然后在打包发货前换上一张全新的卡。但代工厂并没有做这一步替换，所以发给客户的设备里装的是已被使用过的 microSD 卡。

好在这个错误在我们办公室比较容易纠正。本地团队打开每一台设备的包装，将 microSD 重新刷回干净的初始状态，重新打包后再发往仓库。

长远来看，我们显然不想在办公室里一张张重刷 microSD。向代工厂反馈这个问题后，他们表示确实误解了我们的说明，并已修改流程，确保今后发给客户的每一张 microSD 都是全新刷入我们镜像的。我们会对下一批货再次验证，但我有信心这个问题快要彻底解决了。

本可以如何避免 microSD 的问题？

这次 microSD 的问题，其实是此前一系列疏漏累积的结果：

• 我没有发现代工厂的物料清单里少了 microSD。
• 代工厂从未寄来样品 microSD，而我也忘了跟进。
• 直到流程后期，我才想到要如何验证 microSD。
• 我低估了 microSD 检查脚本应有的严谨程度。

当初审核 BOM 时，我只是凭记忆过了一遍，以为都齐了。其实我本可以把现有产品彻底拆解，逐一清点所有零部件，再与代工厂的 BOM 逐项核对。

这已经是第二次遇到代工厂承诺落空导致的问题了，而我至今仍没有很好的解决办法。总体而言，他们大部分任务都跟进得不错，但如果我不去催，大约有 10% 的事项会被遗忘。我一直在主动追问那些我在等的事项，但这也导致像 microSD 或说明书这类看似不重要的部件很容易被遗漏——它们平时不起眼，却会在发货时卡住整个流程。

我对 microSD 检查脚本的投入也不够。当时觉得这只是一个临时脚本，没必要像对待面向客户的代码那样花时间和精力。但出现假阳性后，我才意识到这个脚本在质检流程中至关重要，一个错误可能代价高昂。因此，我们正按照生产级代码的标准流程来重写这个脚本。

我也不确定该如何端到端地验证代工厂的流程。我们自己生产时，有一套写在 Notion 上的操作说明，团队所有人都照着做。但我们无法与代工厂共享 Notion 工作区，因为他们的工人并非都懂英语。所以我们把英文说明交给代工厂，由他们翻译成越南语，再让工人按越南语版本操作。我无法核实越南语流程是否与英文原文完全一致。

让代工厂提供质检过程的视频很有帮助。视频以不受语言限制的方式展示了他们如何做质检。但要拍下从头到尾的完整流程很难。那段质检视频并没有清楚地显示，用于测试的 microSD 最终被留在了成品里，我也不知道该如何预防这一点。

代工厂曾邀请我去越南参观工厂。我以今年出差太多为由拒绝了，但回过头看，或许那次拜访本可以避免一些代价高昂的错误。我本也可以让本地团队的同事代我去一趟。

搭建客户成功流程

年初时，本地 TinyPilot 团队的工作大约是 20% 客服、80% 组装与履约。今年随着我们将生产和履约外包给外部供应商，这一比例已发生显著变化。到 2024 年初，本地团队在组装和履约上的工作应该会降至 0%。

问题在于，客服工作目前仍只占本地团队每周工时的一半不到，那么多出来的时间该怎么利用？

团队从年初就开始讨论这个问题。最自然的转型方向，似乎是从被动响应支持请求，转为主动联系现有客户。有些公司把这个角色称为“客户成功”。

说来惭愧，我很少主动联系客户。这是一件重要但不紧急的事，总是被我忽略。但如果能教会本地团队来做，就不再受限于我个人的时间精力了。

我们正在试行一套新的客户成功流程，步骤如下：

1. 客服团队调研在 TinyPilot 上花费较多的客户（尤其是复购客户）。
2. 客服团队向客户发送一封人工撰写的邮件，提及客户公司和订单的具体细节（以免显得像群发），并邀请对方通话，聊聊功能需求或痛点。
3. 我们与客户会面，了解他们如何使用 TinyPilot。
4. 我们将客户的反馈整合到产品路线图中。

作为客户，当我收到其他公司的联络时，往往能感觉到明显的功利性。他们会说“我们想帮您更好地了解我们的所有产品”，但实际上只是想让我多买点东西。

我希望 TinyPilot 的客户联络能让人感觉是协作，而非索取或贪婪。我认为这能帮助我们让路线图更贴合客户真正想要的功能，也能让我们发现一些原本不会注意到的新机会。

业余折腾

告别 Ansible，迎来 Nix

过去几年，我一直用 Ansible 来管理开发环境，但它的许多痛点让我越来越难以忍受。过去几个月我一直在尝试用 Nix 来替代 Ansible，现在看来终于完成了。

我以前也见过 Nix Home Manager，但没明白它的意义。它管理我主目录下的文件？NixOS 难道不是已经管理了整个系统吗？

我之前忽略的关键点是：

• Home Manager 可以在任何 Linux 或 Mac 系统上运行，而不仅限于 NixOS。
• 由于 Home Manager 专为文本文件优化，它管理文本文件的接口比 NixOS 更好。

现在，我不再用 Ansible 管理开发机，而是用 Home Manager 加上针对项目的 Nix flake 来管理一切。我已经一个多月没跑过 Ansible playbook 了。

一个显著的变化是，我现在更频繁地使用和定义常用命令的 bash 别名。过去添加 bash 别名的流程是：在 Ansible playbook 中添加，然后在每台需要该别名的机器上重新运行 playbook。但在我的机器上运行 Ansible playbook 又慢又容易失败，经常导致一半机器有了新别名，另一半却没有。阻力太大，让我很少有动力去添加新别名并养成使用习惯。

有了 Nix，Home Manager 现在统一管理我所有的 bash 别名。如果想添加一个 shell 别名，我只需编辑 ~/.config/home-manager/home.nix，然后运行 home-manger switch 来应用更改（实际上我把它简写成了一个 bash 别名：hs）。整个过程不到一分钟，而且不像 Ansible 那样会因外部因素而失败。

我之前一直想切换到 NixOS，但由于我常用的 Debian 开发环境与 NixOS 差异太大，一直不太顺利。使用 Home Manager 是在完全拥抱 Nix 和保留熟悉的 Debian 工作流之间一个很好的折中。

我也成了痴迷机械键盘的怪人

在 Lex Fridman 对 Python 之父 Guido von Rossum 的访谈中，Lex 大聊了一段他有多喜欢自己的 Kinesis Advantage 2 键盘。

Kinesis 是机械键盘领域颇受欢迎的厂商。他们的键盘独特之处在于按键位于凹陷的键井中，且键盘左右两半相距数英寸。

Lex 对他的 Kinesis 键盘喜爱到坐飞机也要随身携带，宁愿背着一块巨大的键盘，也不愿用笔记本自带的按键。

从 14 岁起，我就一直在用微软人体工学键盘的某个版本。我挺喜欢它，但从未像 Lex 谈论 Kinesis 那样热爱，所以过去几个月我对机械键盘产生了好奇。

我只认识几个人用机械键盘，但一直不理解它的吸引力。他们想在某个领域钻研一下也无可厚非，但我觉得键盘能带来的最大乐趣终究有限，何必折腾？

后来，我产生了好奇，开始阅读更多关于高端键盘的资料。我醒着的大部分时间都在键盘前度过，或许确实应该投资优化一下这份体验。

在看过 Kinesis、Ergodox 和 ZSA 等几个选项后，我最终选择了 Kinesis Advantage 360。

用这把键盘的第一天非常煎熬，我的打字速度只有平时的 5% 左右。那天有大量文书要处理，所以第二天早上之前我都把它搁置了。

第二天稍微好一些，但仍然很吃力。我坚持了下来，现在用它打英文文章已经比以前更快了，但写代码时反而更慢。我还没习惯这把键盘上 [、{ 和 = 这些字符的位置。即使我已经重新映射了按键，仍在努力形成肌肉记忆。

我看过一些评测，有人说习惯 Kinesis 后再换回普通键盘毫无压力，但我的体验并非如此。当我切换到 Surface Pro 6 上那块紧凑的笔记本键盘时，会打出大量错别字。也许最终我能重新适应两者。

这把键盘有 60 天的退货期，但在此时，我已经相当确定会留下这块 Kinesis 了。

收尾

完成了哪些事？

• 我们发出了由代工厂生产的第一批 TinyPilot Voyager 2a 设备。
• 我们消除了 TinyPilot 发布流程中的人工环节。
• 我换成了机械键盘。

经验教训

• 更主动地跟进代工厂的承诺。
  • 这是我之前犯过却没有正确解决的错误。
  • microSD 的问题重演了之前的模式：代工厂承诺做某件事，我默认他们会处理，双方都忘了，最终在后续引发问题。
  • 我需要开始记录他们的承诺，并每周复盘状态，以防他们遗忘。
• 逐项核对物料清单。
  • 几个月前代工厂发来物料清单时，我只是凭印象检查了预期会看到的内容，却漏掉了 microSD。
  • 以后再走 BOM 确认流程时，我会把现有产品拆开，逐一清点所有零部件，再与代工厂的 BOM 核对。

下月目标

• 尽快将生产转移至代工厂。
• 完成五次客户回访通话。
• 清理 TinyPilot 办公室中所有旧库存和备件。