
你會讓同一個工程師自己寫、自己測、自己 review 再自己上線嗎?
Anthropic 的新文章讓我更確定,AI agent 也需要分工。很多人類團隊踩過的坑,AI 會重新踩一次。
The Serial Founder Roots
QuantumSmile
這段對我來說是很早期、也很硬的一次 deep-tech 練習。先蹲現場,再逆向工程資料協定,最後做出 IoT bridge,讓原本靠手抄的數據進到 dashboard。
Role
Founder / Medical IoT Systems
Client
洗腎中心與醫療現場
Industry
Medical IoT / Clinical Workflow / HealthTech
Outcome
把原本靠人工抄寫的機台數據,拉進準即時監控與半自動化作業流程。
Case Study Summary
>QuantumSmile 展現的是我如何從設備協定、即時資料到醫療情境,建立完整的醫療 IoT 系統視角。
>這個案例對硬體整合、醫療資料流與高信任場景特別有參考價值。
>它說明我不是只做 Web 產品,也能深入設備、通訊與即時監測層。
這個案例適合誰看
>醫療 IoT、設備整合與即時監測決策者
>想看硬體協定如何接回軟體產品的人
>需要在高信任場景做資料整合的人
核心成果
>逆向工程醫療設備協定並接回即時監測系統
>建立設備資料、軟體介面與場域需求之間的連結
>累積醫療場景下硬體與系統整合經驗
關鍵限制
>設備協定不透明時,整合成本會非常高
>醫療資料流對穩定性與可信度要求極高
>現場導入需要同時理解設備與操作流程
可複製方法
>先解通訊與資料層,再設計上層產品體驗
>在高信任場景裡,可靠性優先於功能炫技
>把現場流程理解納入系統設計,而不是只看規格
FAQ
現場蹲點
3 months
資料流量等級
1,000+/sec
單位護理負荷
4-8 beds
先講結論:這個題目最難的,不是大家不知道資料重要,而是洗腎機資料根本讀不出來。
台灣洗腎中心長期面對一個很現實的問題:不同品牌的洗腎機不一樣,資料也沒有被統一整合。護理人員同時照顧四到八床病人,還要每十五分鐘手抄一次關鍵數據,工作壓力很高。
所以真正的問題不是「醫療資料很重要」這種抽象命題,而是現場根本沒有一套可行的方法,能把機台資料穩定讀出來,再整理成可用的流程。
我那時候的做法很直覺:先蹲現場,不先畫架構圖。
三個月裡,我在洗腎中心理解護理節奏、機台差異和工作壓力,然後才反過來定義產品應該長什麼樣子。
核心解法其實也很硬,就是逆向工程洗腎機的資料傳輸方式,做出一個能跟機台對接的 IoT bridge。
資料層一打通,後面的事情才開始有可能:高頻機台數據可以進 dashboard,監控、告警和半自動化作業也才有機會成立。
這個題目真的難的地方是,沒有現成文件可以抄,也沒有標準接口可以直接接。
我得先理解多種品牌機台,再自己把資料傳輸邏輯拆開來看。這個過程其實很土,也很花時間,但沒有這一步,後面的產品都是空的。
等資料終於能穩定讀出來之後,系統每秒可以接收到大量數據,才真正撐得起即時監控這個方向。
接下來我做的事情就比較像把技術往產品推:把資料變成 dashboard,讓醫療現場不再只靠人工抄寫和分散判斷。整體作業也因此從純手工流程,開始走向有系統支援的半自動化狀態。
QuantumSmile 這段經歷對我來說,重要的不只是技術難度高,而是它真的把醫療現場一個很痛的問題,拉成了可操作的系統。
如果要用一句話講,這是一段很典型的 deep-tech founder 經驗:現場理解、技術突破和產品化判斷,一個都不能少。
這個案子讓我非常確定,醫療場域的信任不是靠簡報建立的,而是靠你願不願意真的蹲進現場,把最難的那層資料問題解開。
沒有現場理解,再好的技術都很容易變成空中樓閣。
另一個很深的體會是,deep-tech 的技術突破只是起點。要讓它變成可持續的事業,合作結構、商業邊界和組織對齊同樣重要。技術可以打開門,但能不能走下去,最後還是看整個系統。
Contact
把原本靠人工抄寫的機台數據,拉進準即時監控與半自動化作業流程。
Related Writing

Anthropic 的新文章讓我更確定,AI agent 也需要分工。很多人類團隊踩過的坑,AI 會重新踩一次。

我把 LINE 做成控制 AI 的遙控器。你在外面傳一句話,電腦上的 AI 就去做事,結果再傳回來。