上一集我說，Claude Chat 出策略、Claude Code 執行、我夾在中間做判斷——這套雙 AI 工作流是我四個月來的核心紀律。
這一集要進入第一個我們用這套工作流做出來的重大架構決策——把核心邏輯搬到 Cloud Run。
但這個決策有一個過程：我心裡一直有個模糊的想法「要保護自己的東西」，但具體要保護什麼、怎麼保護——這些是 2 月初跟 Claude Chat 一輪一輪討論，才慢慢明確下來的。
一開始，核心計算就放在 App 裡
算分明最初的版本，核心的分帳計算是完整放在 App 裡的。
所有計算、所有邊界處理，全部在 App 內部跑完。
這在當時很合理。
我自己一個人在用、還沒上市、沒有競爭壓力。
核心計算跟介面寫在一起最簡單，要改隨時改，要測隨時測，根本沒有「該不該放這裡」的問題。
我那時候滿腦子想的是：功能要齊、零頭要算得對、120 間房的真實情境要能跑得起來。
架構保護？智慧財產？這些詞還沒進入我的雷達。
2 月初：威脅的樣子，是聊出來的
轉折點發生在 2 月初。
那時候我開始認真規劃上市這件事——要走 SaaS 模式、要設付費機制、要送進 Google Play 和 App Store 審核。
準備上架的清單越拉越長，但越拉我心裡越涼——我知道有什麼不對勁，但說不上來。
我跟 Claude Chat 一輪一輪討論。
從「上架要準備什麼」聊到「上架之後會發生什麼」，再聊到「上架之後我的程式碼會跑到哪裡去」——就是在這個過程中，我心裡那個模糊的「要保護自己的東西」，第一次有了具體的形狀：
「我把 App 上架，等於我把整個 APK 公開放在 Google Play 上讓人下載。任何人下載我的 APK，都可以反編譯它。反編譯之後⋯⋯我的核心邏輯不就在反編譯工具下面裸奔？」
Chat 確認了我的擔心是真的：Android APK 反編譯工具是公開的、人人可用的，邏輯流程在反編譯之後依然清晰可讀，只是變數名稱會變成 a1b2c3 之類的代號。
對一般 App 來說這沒什麼大不了，但對我這個「整個產品護城河就建立在這套邏輯本身」的工具來說，這等同於把核心競爭力公開。
這個結論不是 Chat 主動告訴我的，也不是我自己一個人想出來的——是我跟它一輪一輪聊出來的。
模糊的想法，被對話磨成了具體的問題。
這就是我覺得「多反思、多研究」這件事對非寫程式背景的人特別重要的原因。
AI 不會主動告訴你你沒問的事——但只要你願意持續跟它討論、把問題往各個方向推、把模糊的擔心一個一個說出來，答案會慢慢浮出來。
為什麼這個核心計算值得這樣保護
可能有人會問：「你的核心計算真有那麼值得保護嗎？」
「要保護自己的東西」這件事，我心裡其實一直擱著。
我做這個工具不只是要解自己的問題，也想著未來要拿出去——既然要拿出去，總是要保護自己的東西不被人家拿走。
但保護什麼、怎麼保護——這些問題我一直沒有具體的答案。
答案是這樣明確下來的——
2 月初跟 Chat 討論：威脅長什麼樣子（APK 反編譯），把問題具體化。
2/12 落實技術手段：把核心搬到 Cloud Run、用 API 封裝、別人反編譯 APK 也看不到邏輯。
2 月底升級到法律手段：技術保護只是把門關上，真正的保護是讓「就算門被撬開，別人也不能拿來用」。那才是申請專利。
於是我在 2026 年 3 月 20 日送了專利申請
從 2 月初的模糊想法，到 3 月底的具體行動——中間每一步都是跟 AI 來回討論磨出來的，不是哪一刻突然想通的。
當你手上有一個正在走法律保護流程的技術資產，你不應該把它放在一個可以被反編譯的 APK 裡。
不是只問 Claude，我多問了幾個 AI
這個決策對我太重要，我不敢只聽一個 AI 的意見。
我把問題拋給了 ChatGPT、Gemini，問同一件事：「我有一套核心運算、準備上架雙平台，要怎麼保護它？」
得到的答案三個方向相當一致：
1. 程式碼混淆——用 ProGuard 之類的工具讓反編譯的結果難讀
2. 訂閱閘門——邏輯還是在 App 裡，但用付費驗證去鎖
3. 核心搬後端——邏輯完全不放 App，App 只是介面、計算丟到雲端做
不同 AI 的措辭、優先順序、技術細節有小差異，但**「最徹底的保護是搬到後端」這個結論是一致的**。
這個多 AI 交叉驗證的過程對我這個非寫程式背景的人特別重要——單一 AI 我會懷疑「會不會它有偏見」，三個 AI 給同樣方向我才敢拍板。
我選了最徹底的方案
我選了最徹底的——把核心搬到 Google Cloud Run。
理由是：這個機會只有一次。
一旦上架之後，任何回頭改架構都會痛十倍。
與其用混淆這種「攔得了一時、攔不了專業」的方式拖延，不如趁還沒上市、用戶為零、沒有歷史包袱的時候，把架構直接做到對的位置。
那是 2 月 12 日。我跟 Chat 把整個遷移計畫梳理出規格書，丟給 Claude Code 執行。
Code 把核心運算從 App 抽出來，搬到雲端的 Cloud Run 服務，App 那邊原本的位置被換成一個空殼——告訴後人「真的核心運算不在這裡了，去雲端找」。
從那一天起，任何人拿到我的 APK 反編譯，能看到的最多就是「App 會打 API 給 Cloud Run」這件事。
API 後面跑什麼，他永遠摸不到。
三個額外的代價，我都接受
老實說，這個決定有三個代價：
第一，使用者沒網路就不能算。對代管業大部分時間沒問題（在家算、在辦公室算），偶爾會卡到（在房客家現場想當場算給他看）。
第二，每次計算都會產生雲端費用。
這直接影響後來的定價策略——但這是值得的，沒有護城河的產品根本不該定價。
第三，開發複雜度從「一邊改」變成「兩邊改」。
App 端的介面改了，Cloud Run 端的計算也要跟著調整，兩邊的版本還要對齊。
但這三個代價我都接受。因為一旦邏輯回到 APK 裡，這個產品就再也沒有護城河了。
下一集：方向相反的另一個架構決策
這集講的是「為了保護自己的演算法，我把核心搬到雲端」。
但我做的另一個架構決策方向相反——「為了保護使用者，我選擇不把使用者的東西搬到雲端」。
這次的教訓很簡單：模糊的想法不會自己變成行動，要靠對話一輪一輪磨清楚。
下一集：架構不只是技術選擇，是價值觀選擇。
