一句話總結

一日到貨而已，能有多難？

本月亮點

• 想提供一日到貨的運送選項，沒想到困難重重。
• 參加了 Handmade Seattle 大會。
• 試玩了 Zig 語言和一個開源 AI 聊天機器人。

目標成績單

每個月月初，我都會訂下想完成的目標。以下是這個月的達成狀況：

盡快將生產轉移到代工廠

• 結果：已完成轉移。
• 評分：A

代工廠現在生產的 TinyPilot 裝置，品質已與我們自行組裝時相當。代工廠現在會直接將裝置運送到我們的第三方物流（3PL）倉庫，因此 TinyPilot 也不再一定需要自己的辦公室了。

進行五通客戶訪談

• 結果：聯繫了三位客戶，但一通訪談都沒完成
• 評分：F

這次是我忘了把這件事排到優先順位。我因為參加研討會和假期出遊，幾乎損失了整整兩週，加上客服團隊當時的人力也比平常吃緊。我本該更積極地跟團隊追蹤、把這件事優先處理好，畢竟為了公司的長期永續經營，我們必須持續在這方面投入。

清空 TinyPilot 辦公室的所有舊庫存與備用零件

• 結果：決定先暫停這項計畫
• 評分：N/A

後來發現房東對於我們何時搬離其實很寬鬆，所以關閉辦公室的急迫性沒有我想的那麼高。而且要把辦公室清乾淨又不直接把東西全丟進垃圾桶，比我想的還要困難。我們有數十種品項，每件價值約 1 到 50 美元，但每種通常只有少少幾個。

舉例來說，我們有三塊二手的 Arduino Uno 開發板，每塊零售價 28 美元。我們或許能在 eBay 上把三塊一起賣個 30 美元，但從上架到出貨整個流程大概要花兩個小時。算下來付給員工的工時成本，反而比賣板子賺的還多。

我現在的新計畫是，等到快要搬離時再公告一個時間，讓大家直接來把想要的東西免費拿走。

TinyPilot 數據一覽

利潤看起來很嚇人，但只是因為轉移到代工廠後，我的支出變得比較「爆發性」。10 月我沒有任何原物料的帳單，但 11 月卻有 5.7 萬美元的原物料費用。我其實應該開始把它們列為銷貨成本，但目前我只是單純呈現現金流的增減。

8 萬至 10 萬美元是 TinyPilot 正常的營收區間，我們目前仍穩穩落在這個範圍內。我本來或許會想把握黑色星期五／網購星期一的機會，但因為正值生產轉移，庫存偏低，所以沒有足夠的存貨可以降價促銷。

一日到貨，能有多難？

在 TinyPilot 的大部分時間裡，我們都沒有提供隔夜或一日到貨的運送服務。

當我們自行出貨時，辦公室一週有六天都有人處理訂單，但每天只有一個人值班。我之所以沒提供一日到貨，是因為我知道總會遇到有人生病或休假的情況，到時就無法做到一天內出貨。

改由第三方物流倉庫（3PL）負責出貨後，人力吃緊的問題就消失了。3PL 的人力備援比我們充足得多，所以無論如何，訂單應該都能在一個工作天內寄出。

轉移到 3PL 後，我們終於能夠提供一日到貨的選項了！

複雜的運送系統架構

改用 3PL 之後，管理運送選項的邏輯變得複雜許多。過去我們向 TinyPilot 客戶呈現運送選項的方式是這樣的：

1. 我先在 Shopify 上選好要開放給客戶的運送選項。
2. 客戶在結帳時選擇一種運送方式。
3. 我們再透過 Shopify 購買對應的郵資。

在這套系統下，Shopify 從頭到尾掌控整個流程，而且做得很好。

我們的 3PL 使用一套（不太好用的）倉儲管理系統 ShipStation。這個工具會與我們的 Shopify 商店串接，所以現在的架構變成這樣：

1. ShipStation 提供 3PL 一份它支援的運送選項清單。
2. 3PL 從這份清單中挑選它想提供給客戶（也就是 TinyPilot）的運送選項。
3. Shopify 向 ShipStation 查詢，看 ShipStation 和 3PL 雙方共同認可了哪些運送選項。
4. 我再從 Shopify 中挑選要開放給客戶的運送選項。
5. 結帳時，ShipStation 會不透明地猜測哪些選項對客戶「最好」，並把運送選項縮減到只剩兩、三個。
6. 客戶在結帳時選擇一種運送方式。
7. 3PL 再透過 ShipStation 或其他供應商購買對應的郵資。

牽涉這麼多方，出錯的環節多不勝數，也充滿了互相推卸責任的空間。

我試著啟用一日到貨，卻發現設定從 3PL 經過 ShipStation 再到 Shopify，最後傳到我這裡時，已經沒有任何一日到貨的選項了。

經過好幾個月的來回溝通，我們把問題鎖定在 ShipStation 上。他們不顯示一日到貨的選項，是因為他們把一日和二日到貨視為「類似」的選項，但二日到貨永遠比較便宜，所以他們就永遠不會呈現一日到貨的選項。

是的，你沒看錯。ShipStation 這家主要業務就是賣郵資幫你寄包裹的公司，竟然無法理解為什麼有人會願意付更多錢選擇一日到貨，而不是比較便宜的二日到貨。

因為 ShipStation 的問題實在太多，我決定改回舊的架構來向客戶呈現運送選項。現在，我們直接透過 Shopify 向客戶顯示運送選項與費率，根本不再向 ShipStation 查詢費率。

把 ShipStation 排除在結帳流程之外的問題在於，3PL 是用 ShipStation 較高的費率購買郵資，但 Shopify 卻是用較低的 Shopify 費率向客戶收取運費。所以，客戶可能只付了 30 美元的隔夜運費，但透過 ShipStation 的實際郵資卻是 100 美元，中間 70 美元的差額就得由 TinyPilot 自行吸收。

儘管如此，這個解法至少讓 TinyPilot 能夠提供我們想要的運送選項，而不會被 ShipStation 傻呼呼地覆蓋掉。而且吸收 70 美元的額外運費，總比完全做不成這筆生意來得好。

選擇一日到貨的客戶，要求高出四倍

大多數時候，3PL 都能在一個工作天內把我們的訂單寄出。偶爾遇到狀況會需要兩個工作天，極少數情況下則需要三天。我們在網站上標示最長需要三個工作天的處理時間，但客戶似乎都不太注意這點。

90% 的情況下，選擇一般陸運或二日到貨的客戶，就算處理時間多延了一天，也不會多說什麼。

黑色星期五過後的那個星期一，UPS 出現了一個奇怪的問題，他們沒有更新任何已取件訂單的物流追蹤資訊。倉庫信誓旦旦說 UPS 已經把貨都取走了，但 UPS 的追蹤系統卻什麼都沒顯示。

這個 UPS 追蹤異常影響了五位選擇一日到貨的客戶。在 24 小時內，就有兩位寫信來抱怨延遲。也就是說，40% 的一日到貨客戶會抱怨，相比之下，選擇陸運或二日到貨的客戶中，只有約 10% 會注意到延遲。

這點我完全能理解。當我自己用一日到貨下單時，也會急著想收到貨，如果店家拖了好幾天才出貨，我也會很不高興。

這些選擇一日到貨的客戶就像雙面刃。如果他們願意付五倍於一般陸運的費用來求快，他們很可能是會推升 TinyPilot 銷售額的大客戶。但我也發現他們通常要求比較高，會讓客服團隊壓力倍增，因為他們對時效的期待是多數客戶所沒有的。

我的第一場 Handmade 大會

11 月，我在西雅圖參加了第一場 Handmade 大會。這是一個面向底層軟體開發者的獨立研討會。

以下是我從這場大會得到的一些心得。

主流技術架構之外，還有其他選擇

David Foster Wallace 在他著名的 2005 年肯揚學院畢業典禮演講中，用了一個關於魚的笑話開場：

有兩條小魚一起游著，迎面遇到一條年長的魚，老魚對牠們點點頭說：「早啊，孩子們，水怎麼樣啊？」兩條小魚繼續往前游了一會兒，最後其中一條轉頭看向另一條說：「水到底是什麼鬼？」

對我來說，網頁瀏覽器就是水。

我太習慣把軟體想成是使用者最終透過 HTML 和 JavaScript 來互動的東西，以至於幾乎忘了還有其他可能性。已經很久沒有想過，一切都圍繞著一個 90 年代為了呈現靜態文件而創造的技術來設計，其實是件多麼奇怪的事。

但在 Handmade，我遇到的大多數開發者根本不碰網頁瀏覽器，也完全沒在使用我習以為常的那些技術。

我認識了 MobileCode 的創作者，這是一款能在手機和平板上寫程式的 App。我問他用了什麼語言，本來以為他會說 Flutter 或大概是 React Native，結果他回答「C 語言」時，我整個驚呆了。

不僅如此，他還說用 C 語言做行動開發的體驗其實很不錯。他可以直接在 iOS 和 Android 上呼叫原生的繪圖 API，而不需要透過現代框架層層的抽象。

不懈的獨立開發雄心

我一開始會知道 Handmade，就是因為我追蹤 Andreas Kling，他是 SerenityOS 的創作者。他一個人、完全不靠任何第三方函式庫或依賴，就打造出了最初的作業系統，並在 2021 年的 Handmade 上發表了這個專案。

Handmade 也吸引了許多關於 Zig 的演講，這是我關注了一陣子的獨立程式語言。Zig 的創作者 Andrew Kelly 在 2021 年上了 CoRecursive Podcast 談到他想用 Zig 取代世界上所有的 C 語言程式碼。

Adam：當你把 C 語言拉下王座後，世界會變成什麼樣子？

Andrew：喔，那會很美好。世界看起來大致不變，只是你所有的 App 都會稍微好用一點，比較不容易當機，用更少的記憶體，跑得更快……

當教科書想解釋作業系統或嵌入式裝置是如何運作時，大家就會理所當然地用 Zig 作為範例程式碼，因為那就是每個人都在用的東西。

我覺得 Andrew 這種對軟體的雄心與熱情非常酷、非常令人振奮，而這正是我來 Handmade 想尋找的東西。

Handmade 沒有讓我失望，它充分展現了獨立開發的雄心。這場大會推崇「重新發明輪子」的精神。

在軟體界，指責別人「重新發明輪子」通常是種貶低，但在 Handmade，大家卻擁抱這件事。為什麼不重新發明輪子呢？也許你造出來的輪子會比大家現在用的更好。而且光是嘗試重新發明輪子，你就會更了解輪子到底是怎麼運作的。

Cameron Riekes 還是一名大學生，他發表了關於打造 2D 角色扮演遊戲的內容。但接著他又 「順手」從零開始寫了一套自己的 3D 遊戲引擎。

Yasser Arguelles 才二十出頭，正在開發 Tilde，這是一個從零開始打造、想取代 LLVM 的專案。補充一下：LLVM 是一個已經持續開發了 20 年的編譯器後端。在演講中，Yasser 提到他其實沒有編譯器方面的背景，但他在 Handmade 的討論中看到大家最常許願的就是希望有 LLVM 的替代方案，所以他就想：「好啊，那我來做吧。」

我還有幸見到了 Andrew Kelly，他人非常好。這次的對話也終於激勵我 動手試寫了一些 Zig 程式碼。

對大型科技公司的極度不信任

我對這場大會的一個抱怨是，整體氛圍對大型科技公司的批判到了一種我覺得不太理性的程度。

整場大會的論調基本上是：大型科技公司根本就是毒藥。他們做出來的東西全都有 bug、臃腫、不可靠，而且價格過高。

根據講者的說法，更多人沒意識到大型科技公司的缺點，是因為大型科技公司掌控了軟體研討會。他們禁止講者誠實地談論大型科技軟體的問題。我自己也曾在幾場中型研討會上演講，從來沒有人告訴我不能批評大型科技公司，所以這種說法對我來說聽起來不太真實。

我能理解反大型科技公司的觀點。只要可以，我也偏好獨立技術，但我同時認為大型科技公司有很多事情做得很好，而且在推動技術前進上承擔了大部分的重任。我覺得如果只是對其嗤之以鼻，並想當然地認為獨立開發的東西永遠比大型科技公司的產品好，那是個錯誤。

其他會後心得

• Carl Sverre

如果你知道其他會後心得，歡迎告訴我，我會幫你加上連結。

業餘專案

WanderJest

WanderJest 是我幾年前開始做的一個網頁 App，目的是幫大家找到附近的現場喜劇演出。我在 疫情爆發時就先擱置了它，但之後還是斷斷續續地加減玩一下。

WanderJest 最大的挑戰之一，是要取得即將舉行的演出資訊。一場喜劇演出的權威資訊，通常就是像這樣的海報：

表演者通常不想做好海報後，還得把所有資訊再打一次字輸入到別的地方，所以我一直在思考怎麼「免費」從海報中直接取得這些資訊。

我最初的想法是做一個 幫助演出製作人製作海報的工具。我花了幾天時間試做了一下，但第一個我去提案的喜劇演員就沒什麼興趣。這個想法我還沒完全放棄，只是還沒興奮到想繼續迭代。

不過現在 AI 影像辨識越來越進步，我的另一個想法是去搜集演出的海報，然後用開源的 AI 工具把演出資訊擷取出來。

當我讀到 Simon Willison 關於使用 Llamafile 的文章時，我才意識到現在要實驗具備影像理解能力的聊天機器人是多麼容易，於是我就拿海報的問題來試試看。

可惜的是，LLaVA 1.5 在影像辨識上的準確度似乎還不夠高，不足以滿足我的需求。當我給它看一張喜劇演出海報並提問時，它的回答準確度大概只有 70%：

我試著胡亂調整了一下設定，但還是無法改善結果。

儘管如此，看到這個領域的開源方案不斷進步與競爭，還是讓我很興奮。更多細節請見：

• Rough Experiments with Llamafile and LLaVA 1.5

總結

完成了什麼？

• 發布了 TinyPilot Pro 2.6.2
• 參加了 Handmade Seattle 大會
• 解決了與一家關鍵供應商之間的出貨匯出問題

學到的教訓

• 一日到貨會吸引願意花更多錢的客戶，但這些客戶的要求也更高。

下個月的目標

• 完成 TinyPilot 授權驗證的設計工作。
• 建立新裝置每批生產的抽檢流程。
• 處理 TinyPilot 年底的報稅事務。