把說不清楚的問題
做成現場能用的工具

01　醫療現場

電話為什麼一直響

2018 年，我們開始和高雄市立大同醫院健康管理中心合作。那時候很多健檢預約還是靠電話，光是接電話、確認時間、處理來回修改，就需要三個人輪著做。

坦白說，這不是做一張線上表單就會消失的問題。民眾選了日期，後面還有排程、報到、報告和追蹤；只要其中一段沒有接起來，工作就會換個地方繼續卡住。電話只是最先被大家聽見的地方。

後來，我們把預約流程搬到線上。根據 2026 年《看雜誌》的採訪資料，現在大約八成預約由民眾自己完成，電話值機從三個人減為一個人。電話沒有消失，而是留給真的需要人工協助的人。這件事沒有什麼很炫的技術，只是原本每天都很麻煩的事情，終於被好好做完了。^P01

「無聊，但要做到位。」

我會這麼在意「工作不能只靠一個人撐住」，不是進了醫院才開始。要說清楚這件事，得先回到我的第一份工作。

02　工作的起點

不能只靠一個人記得

我的第一份工作是在旗立資訊擔任責任編輯，編撰國、高中計算機概論教科書。^E14

那時候，業務會把老師對教材的意見帶回來。有時是某一段寫得不清楚，有時是書上的說法和老師原本的理解不一樣。主管很保護編輯，希望大家專心把書寫好，所以這些第一線問題大多由她接住。

後來我發現，她幾乎沒有辦法真的休假。只要業務帶回一個沒有人處理過的問題，編輯部最後還是得打電話找她。公司明明有這麼多人，少了一個人，事情卻像停住一樣。我一直覺得這很奇怪。

所以後來只要電話到了我這裡，就算我不知道、也沒有碰過，我還是會先去翻資料，把老師真正問的是什麼弄清楚，再想辦法整理答案。至少主管休假時，不需要因為每一件事都回來救火。

當時我未必想得這麼完整。我只知道，如果一件工作永遠要找同一個人救火，那就還沒有真的被團隊接住。離開出版社後，我加入網絡行動科技（NETivism），開始用工程師的身份面對同一個命題。

03　走向開源

不需要很厲害才開始

我對開源的認識，其實不是從什麼大道理開始，而是大學打工時的一段狼狽經歷。

那時我是個連 Linux 都不懂的菜鳥，英文也很差。主管要我架伺服器，我把英文手冊印出來，一個指令一個指令照著敲；只要系統反應不對，就只能格式化重灌再來一次。但正是因為 Linux 和伺服器軟體全都是開源的，讓一個窮學生只要願意花時間，就能拿到跟全世界工程師一樣的工具。我在家架起 FTP 和 BBS，第一次在技術裡找到自信。

離開出版社後，我加入網絡行動科技（NETivism）擔任專案經理與工程師。^E10在南部長大的我，原本習慣了傳統「當師傅要留一手（偷囥步）」的防備心理；但這間公司卻大方對外宣稱用開源架站，還出錢出力推廣社群、拉更多人加入。

跟著做了幾年，我才徹底想通：開放底層的磚塊，給出去的是「信任」與「標準」；客戶真正需要買的，是幫他們把大樓蓋得穩固的架構能力。那幾年我在 COSCUP、ICOS、DrupalCamp 發表了大量演講。開源對我來說就是這樣一個舞台：你不需要很厲害才開始，而是先站上去、動手做，社群的友善會陪你變厲害。

04　教室裡的實驗

孩子畫的角色，能不能自己動起來

後來我到雲科大進修。在雲科讀書期間，我順道去雲林古坑的水碓國小，當了一、兩個學期的創客社團課老師。

那是一間偏鄉小學，全校加起來不到五十個人。我和校內老師黃任暘合作，帶中高年級的孩子做一件事：用 Scratch 寫程式、用手繪角色、用 3D 列印做出實體模型，最後把這些全部放進一個手機 App 裡。

那個 App 叫《水碓GET!》。我們在校園裡埋了 iBeacon 發射器，孩子走到不同位置，手機就會跳出他們自己設計的精靈——「喇叭飛葉殺手」「魔音公主」「瘋電馬」——名字都是他們取的。抓到的角色會登錄在圖鑑裡。整個概念來自當時正紅的《Pokémon GO》，但裡面每一個角色都是孩子自己畫的。

這短短一兩個學期的實驗，讓我看見一件很觸動的事：孩子不是不想學，是他看不到自己做的東西被誰用了。當他畫的角色真的出現在手機裡、可以被同學抓到，他會追著問「老師我還可以再畫一隻嗎？」

這個「讓孩子畫的角色走進故事」的念頭，成了後來創立 FANSEE 的起點。

06　公開工作

做完，順手留下來

我很早就在 Drupal 社群裡做開源。後來又開始做 RikaiDev。這些專案沒有服從一套整齊的職涯計畫，大多只是工作上一直遇到、等不到別人做，只好自己先做。

yomi 就是一個很直接的例子。會做它，是因為我真的不喜歡一直打開 LINE。原本只想回一則訊息，最後卻在聊天室裡待了半小時。總之，既然這件事一直干擾工作，我就把讀取、搜尋和回覆整理成一個本機工具，讓agent 幫忙處理。

toki、mesen 也差不多。自動時間追蹤不好用，就自己做；網站測試只看程式有沒有錯，卻不知道使用者到底看不看得懂，就做一個從persona 視角找問題的工具。它們有些還在實驗，有些已經放進公開的package registry。至少別人可以直接看程式碼、版本與 issue，自己判斷值不值得用。^O01–O08

我自己不覺得把模型或工具放出來，就等於把優勢送人。開放底層的磚塊，給出去的是信任：別人可以先看、先用，再決定要不要把下一步交給你。真正困難的從來不是公開程式碼，而是長時間把東西做好，讓人相信你會繼續負責。

07　回到現場

信任，是一件一件做出來的

資訊管理談數位轉型時，早就不只是在談技術。新系統會改變人的工作方法，也會讓使用者承擔學習、出錯和轉換的成本。如果他還不相信這個改變對自己有幫助，抗拒才是最合理的反應。

2018 年，我們第一次走進大同醫院健康管理中心。當時大家用電話接預約、拿紙本記錄，工作人員忙到一本預約簿翻得快爛掉。院方想要的其實很直接：能不能先把預約這件事做好？所以我們沒有先談一套宏大的轉型計畫，而是把每天能做多少超音波、電腦斷層和腸胃鏡算清楚，讓民眾在預約當下就知道有沒有成功。

第一件事真的有用，信任才開始發生。後來大約八成預約轉到線上，接電話的人力從二、三位減成一位，客訴下降，健檢中心也第一次能從後端看見設備和服務量能。這些結果比任何簡報都有用：它讓現場知道，換一種工作方法不一定會增加麻煩，也可能真的讓人輕鬆一點。

有了第一層信任，院方才願意再往下走。LINE 聊天機器人、政府系統介接、檢查報告無紙化，一項一項接進來；2023 年，這些累積也讓健管中心取得智慧醫療與 SNQ 認證。大同醫院做出成果後，當時的主任願意把經驗分享出去，小港、岡山、旗津才陸續成為下一段合作。這條路不是業務一次談成的，是前一件事替下一件事作證。

當然，每一次換系統，抗拒還是會重新出現。有時候我們甚至會先做一個比較低階、看起來沒有那麼新穎的版本；如果清潔人員平常只熟悉 LINE，就先把工具放進 LINE，而不是硬逼所有人安裝一個 App。先讓人直覺地用起來，再陪著操作、聽回饋、修正匯錯的資料。使用者先相信系統給的結果，才可能願意推動身邊的人一起使用。

《看雜誌》採訪時，我把這件事說得很簡單：「數位化過程從來不是一蹴可幾的，長期的陪伴很重要。」陪伴不是在旁邊等，而是每一次都去第一線把問題做完，讓客戶一次次確認：我們真的理解他的痛苦，也真的說到做到。

我後來才懂，我們真正累積的不是一套系統，而是人家願意再把下一件事交給我們的信任。