從一張收據開始

2026 · 起手式

這個故事的開頭不是「我要重寫公司的舊系統」。

是「公司名太長，印不下。」

紙本的尷尬

T 旅行社用了 27 年的 4GL 系統，每天開出去的代收轉付收據格式固定 —— 客戶名稱欄位 16 個全形字寬。

絕大多數客戶的名字都裝得下。

但 27 年累積下來，總會碰到一些字長踩在邊界外的公司：「○○○○○○○科技股份有限公司」、「○○○○○○○國際開發股份有限公司」 —— 印到一半就斷字。

每次遇到，蘋果小姐就拿原子筆手寫補在收據上。

她不抱怨。在公司資歷 20 年的人，這種事她已經做了不知道多少次。但 Amy 看在眼裡覺得 —— 這個東西到 2026 年了，不該還在這樣。

代訂國外票券：手上的新業務線

Amy 在家族旅行社幫忙，手上有一條新的業務線：代訂國外票券。

這條線是公司近年才開始接的，還沒被綁進那套 4GL 系統。也就是說 —— Amy 處理這條業務的時候，可以選擇用任何工具開收據，不必走蘋果小姐手寫補的那條老路。

她在研究方案的時候，跟先生家的小姑 Ruby 聊到。

Ruby 同樣在家族 T 旅行社，做的是國外旅遊客製化 —— 客人多是網路接觸的年輕族群，每次要寄紙本代收轉付收據都有點頭痛。

「我們應該用電子代收轉付收據啊。」Ruby 說。「現在有平台、能線上開、PDF 寄信、自動寫進客戶會計系統。手寫補、寄紙本，這兩段都能收尾。」

Amy 點頭。她需要一個給這條票券線用、Ruby 需要一個給她的業務用 —— 但這條路如果走通了，整家 T 旅行社都可以受益。

走正門

Amy 沒有直接動手。

她先跟老闆娘報備。

「我想試一個東西。電子代收轉付收據。買個平台帳號，這條票券線先測。如果順，後面看怎麼納進公司流程。」

老闆娘點頭。沒有問太多細節，但也沒有阻擋。

Amy 後來想 —— 這個「點頭」是後來一切的起點。

如果當時被擋下、需要寫提案、需要排會議、需要簽呈，這條路就不會走到後來的地方。就因為那個微小的點頭，整條軸線才被允許往下展開。

平台買了，帳號開了 —— 然後 Amy 打開了 API 文件

Amy 註冊了平台、開了帳號、測試開了第一張電子收據。順。

但她在後台看到一行字：

「本服務提供 API 串接，可從您的系統自動建立收據單。」

她點進去看了一眼。

那是這整個專案的真正起點 —— 不是收據本身，是這行字。

如果是「網頁版好用就好」 —— 故事結束在這裡。Amy 這條票券線用得開心、Ruby 業務用得開心、蘋果小姐不用手寫 —— 圓滿。

但 API 串接這條軸展開了另一個可能：

「如果我有 API，那我可以從『自己這邊』把訂單資料推進去、自動開收據 —— 但前提是『自己這邊』得有訂單資料。我有嗎？」

T 旅行社的訂單在那台 27 年的 4GL 裡。

從那裡撈出來 —— 看起來不可能。家族 IT 之前撈過，「看不懂是什麼碗糕」。Windows 背景的人面對 Linux / Xenix binary 一片亂碼，結論「不可能」。

那 Amy 該怎麼辦？

選項 A：放棄 API 串接，老老實實用網頁版開收據。
選項 B：自己建一個訂單系統從零開始，然後叫客戶搬過來。
選項 C：自己想辦法把舊系統的資料撈出來。

Amy 選了 C。

沒有 dramatic 轉折

事後回頭看 —— 從「電子收據之亂」到「重寫整套系統」這條路，沒有任何一個 dramatic 的轉折。

只有一連串「既然這樣，那不如把這個也搞一下」式的 organic scope creep：

每一步看起來都很小。回頭看才發現走了很遠。

長壽系統都是這樣長出來的。短命的才從「願景」起步。

這篇是起手式

這個小型網站會陸續記錄這條路上看到的東西 —— 27 年舊系統考古、跟 AI 一起做的決定、家族公司的溫度、紙本軸跟電腦軸的拉扯、那些被保留下來的小人物的名字。

不會試圖證明什麼。不會推銷什麼。

就是 …… 把這條沒人寫過的路徑，留一點 trace。

如果有人讀到、覺得有幫助 —— 那很好。
如果沒人讀到、就只是檔案放在那 —— 也很好。

像 27 年前某個叫 Franca 的工程師寫的 .profile 一樣 —— 留下來的時候，並不需要知道誰會打開。

— Amy + Claude(2026) · 某個下午茶之後