[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"post-vibe-coding-tool-vs-product":3},{"post":4},{"slug":5,"title":6,"date":7,"description":8,"tags":9,"author":14,"cover":15,"draft":16,"readingTime":17,"cta":18,"body":23,"html":24},"vibe-coding-tool-vs-product","三個 Vibe Coding 翻車現場：工具自己用很順，一開放給別人就出事","2026-10-02T12:00:00.000Z","用 AI 做一個自己用的小工具，現在很輕鬆、也很順手。但真正的難題，是把它變成「給別人用」的服務——這時候並發、資料隔離、資安、權限、備份的問題會一次湧上來。三個虛構但很真實的故事，點出問題，也給解法。",[10,11,12,13],"Vibe Coding","SaaS","系統開發","AI 開發","HiHi Digital","\u002Fblog\u002Ftool-to-product-cover.svg",false,7,{"title":19,"text":20,"label":21,"to":22},"想把自己的小工具，變成能賣的服務？","「自己用順」到「給人用穩」中間那段，正是我做了十年的事——做過各種 SaaS，這些坑都踩過。生產級 SaaS 啟動包，幫你把地基一次打對。","看看 SaaS 啟動包 →","\u002Fstarter-kit","\n先說一件現在很爽的事:用 AI 做一個**自己用的小工具**,真的很輕鬆。\n\n一個下午,你就能 vibe 出一個幫你排班、算報價、生文案的小東西,用起來超順手,你會忍不住覺得:「欸,我是不是可以把它包成服務賣?」\n\n這個念頭很對,但接下來那一步,是很多人沒想到的懸崖:\n\n> **「自己用的工具」和「給別人用的服務」之間,隔著一整個軟體工程學科。**\n\n因為自己用的時候,使用者只有一個——你。你很乖、不會亂輸入、只用自己那支手機、記得所有規則、出錯了就聳聳肩自己修。但一開放給別人,使用者變成很多個,而且他們**不配合、用各種裝置、會手滑、不懷好意、還會同時湧進來**。\n\n![自己用 vs 給別人用,根本是兩件事](\u002Fblog\u002Ftool-to-product-contrast.svg)\n\n下面三個故事是虛構的,但每一個我都看過無數次真實版本。\n\n## 故事一:小雅的預約頁,兩個客人訂到同一個時段\n\n美甲師小雅用 AI 做了一個線上預約頁,自己貼在 IG 限動,客人點進來選時間就好,超方便。朋友看到說「這個好用,也借我用!」於是她興沖沖開放給另外五個美甲師一起用。\n\n一週後災難來了:\n\n- 兩個客人**同時**點了同一個 11:00,系統兩個都收——因為它從沒想過「兩個人同一秒按下去」會怎樣。\n- 五家店的預約資料**全混在一起**,A 店看得到 B 店的客人。\n- 有個客人用舊手機打開,版面整個跑掉,根本按不到送出。\n\n**根本問題**:自己用的時候沒有「並發」、沒有「別人的資料」、只有「你的手機」。給別人用,這三件事全冒出來。\n\n**該怎麼解**:用資料庫交易與鎖,確保同一時段只會成立一筆(race condition 要主動處理,不能靠運氣);做**多租戶資料隔離**,每個帳號只看得到自己的資料;介面要響應式(RWD),顧及各種螢幕尺寸。\n\n## 故事二:阿哲的 AI 文案工具,一公開就收到天價帳單\n\n行銷顧問阿哲 vibe 了一個「輸入主題、自動生一週貼文」的工具,接了 OpenAI 的 API,自己用省下超多時間。他決定包成月費訂閱來賣。\n\n上線第三天,他收到 API 帳單——**三萬多塊美金**。\n\n- 他把 API key **直接寫在前端**,被人從瀏覽器扒走,拿去盜刷。\n- 沒有任何**登入\u002F驗證**,網址一外流,全世界都能免費用他的額度。\n- 沒有**限流**,一支機器人幾秒鐘打了幾萬次。\n- 他甚至不知道**誰用了多少**,因為根本沒做用量計量,更別說計費。\n\n**根本問題**:自己用的時候,你信任你自己、你知道成本、你不會攻擊自己。給別人用,這些假設全部不成立。\n\n**該怎麼解**:金鑰一律放**後端**、用伺服器當代理(前端永遠碰不到 key);加上**身分驗證與授權**;做 **rate limiting** 防濫用;把**用量計量 + 成本上限**做起來,才敢安心開訂閱。這些,正是我在〈[Vibe Coding 的四個隱形成本](\u002Fblog\u002Fvibe-coding-hidden-costs)〉裡說的「資安是 AI 最愛跳過、代價卻最高」的那一塊。\n\n## 故事三:阿姨的庫存表,員工一起用之後資料全亂了\n\n雜貨店老闆阿姨做了一個「Google 試算表 + 一點 AI」的庫存小工具,自己對帳對得很開心。生意變好,她請了兩個員工一起更新。\n\n結果:\n\n- 兩個員工**同時改同一格**,後存的蓋掉前存的,庫存數字對不起來。\n- 有人手滑**刪掉一整欄**,沒有備份、救不回來。\n- 月底要看歷史進貨,才發現資料是**就地覆蓋**的,過去的紀錄根本沒留,也不知道「這筆是誰改的」。\n\n**根本問題**:自己用的時候,規則在你腦子裡、只有你會動它、你記得改過什麼。多人協作,就需要「就算有人犯錯也不會釀災」的機制。\n\n**該怎麼解**:做**權限分級**(誰能看、誰能改、誰能刪);**自動備份與版本紀錄**,手滑也能還原;留**稽核軌跡**(誰、何時、改了什麼);關鍵欄位加**防呆驗證**。給人用的系統,要假設「人一定會犯錯」,然後讓錯誤不致命。\n\n## 看出共通點了嗎?\n\n三個故事的工具,**自己用的時候都 100% 正常**。它們不是「做壞了」,而是**從來沒有為「別人」設計過**。\n\n而「為別人設計」要考慮的事——並發、資料隔離、資安、身分、計量、權限、備份、稽核、各種裝置、各種誤用——沒有一項會在你自己用的時候冒出來。它們全都藏在「開放給第一個外部使用者」的那一刻之後。\n\n這也是為什麼 vibe coding 一個 demo 很快樂,把它變成真正能賣的服務卻那麼痛:**你跨越的不是一條線,是一整個領域。**\n\n## 這正好是我們的優勢\n\n現在「做一個自己用的工具」門檻很低,人人都做得到,這是好事。但「把它變成一個給很多人用、還撐得住的服務」,靠的不是會不會 vibe code,而是**有沒有真的把 SaaS 從 0 養到有人付錢用過**。\n\n這剛好是我做了十年的事。上面這三類坑——並發、多租戶、資安、計費、權限、備份——我做各種 SaaS 的時候全踩過,也知道怎麼**在一開始就把地基打對**,而不是等出事了再回頭拆。\n\n就像我在〈[差最後一哩](\u002Fblog\u002Fsoftware-last-mile)〉裡說的:能做出來只是前面那 10%,讓它在真實世界、對真實的人穩穩運作,才是真正值錢的那段。\n\n## 反過來說,如果你是小店家\n\n這篇講的是「別把自己隨手 vibe 的東西,輕率拿去給別人用」。但有另一種人,我想對你說幾乎相反的話。\n\n如果你是個小店家,每天都在跟一套「不合身」的訂閱管理系統鬥——它的流程跟你店裡實際跑的不一樣、你最需要的那個功能它偏偏沒有、一堆用不到的功能你每月照付——那我要告訴你一件事:\n\n**以前身為工程師,我會勸你別自己做系統,因為太貴、不划算。但現在,AI 把客製開發的成本和時間打了下來,我的建議改口了。** 為了那些現成系統給不了的客製,找對的人用 AI 幫你做一套合身的,現在真的划算了。\n\n關鍵是「找對的人」——不是自己硬 vibe(你已經在上面看過會怎樣),而是找有工程底的人用 AI 做,兼顧「合身」與「地基」。這一塊,我下一篇想好好談。\n\n## 你今天可以帶走的三件事\n\n1. **想清楚「第一個外部使用者」會遇到什麼**——在你按下「開放」之前,先問:如果同時來十個人、有人亂輸入、有人用舊手機、有人想佔便宜,會怎樣?光是把這些列出來,你就領先一大半人。\n2. **金鑰、驗證、限流,是開放前的最低門檻**——只要你的服務會連到付費 API 或存別人的資料,這三件沒做好就上線,等於把帳單和風險交給運氣。\n3. **地基要在一開始打,不要等出事再補**——多租戶、權限、備份這些,事後再加往往要打掉重練。一開始多想那十分鐘,省的是之後整包重做的痛。\n\n如果你手上正好有一個「自己用很順、很想拿出去賣」的工具,卡在不知道怎麼把它變成真的能給人用的服務——那段路,剛好就是我在走的。來聊聊,我幫你把地基一次打對。\n\n> 本文故事均為虛構,用以說明「自用工具」轉為「對外服務」時常見的工程問題;技術解法為實務通則。\n","\u003Cp>先說一件現在很爽的事:用 AI 做一個\u003Cstrong>自己用的小工具\u003C\u002Fstrong>,真的很輕鬆。\u003C\u002Fp>\n\u003Cp>一個下午,你就能 vibe 出一個幫你排班、算報價、生文案的小東西,用起來超順手,你會忍不住覺得:「欸,我是不是可以把它包成服務賣?」\u003C\u002Fp>\n\u003Cp>這個念頭很對,但接下來那一步,是很多人沒想到的懸崖:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>「自己用的工具」和「給別人用的服務」之間,隔著一整個軟體工程學科。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>因為自己用的時候,使用者只有一個——你。你很乖、不會亂輸入、只用自己那支手機、記得所有規則、出錯了就聳聳肩自己修。但一開放給別人,使用者變成很多個,而且他們\u003Cstrong>不配合、用各種裝置、會手滑、不懷好意、還會同時湧進來\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fblog\u002Ftool-to-product-contrast.svg\" alt=\"自己用 vs 給別人用,根本是兩件事\">\u003C\u002Fp>\n\u003Cp>下面三個故事是虛構的,但每一個我都看過無數次真實版本。\u003C\u002Fp>\n\u003Ch2 id=\"%E6%95%85%E4%BA%8B%E4%B8%80%3A%E5%B0%8F%E9%9B%85%E7%9A%84%E9%A0%90%E7%B4%84%E9%A0%81%2C%E5%85%A9%E5%80%8B%E5%AE%A2%E4%BA%BA%E8%A8%82%E5%88%B0%E5%90%8C%E4%B8%80%E5%80%8B%E6%99%82%E6%AE%B5\" tabindex=\"-1\">\u003Ca class=\"header-anchor\" href=\"#%E6%95%85%E4%BA%8B%E4%B8%80%3A%E5%B0%8F%E9%9B%85%E7%9A%84%E9%A0%90%E7%B4%84%E9%A0%81%2C%E5%85%A9%E5%80%8B%E5%AE%A2%E4%BA%BA%E8%A8%82%E5%88%B0%E5%90%8C%E4%B8%80%E5%80%8B%E6%99%82%E6%AE%B5\">故事一:小雅的預約頁,兩個客人訂到同一個時段\u003C\u002Fa>\u003C\u002Fh2>\n\u003Cp>美甲師小雅用 AI 做了一個線上預約頁,自己貼在 IG 限動,客人點進來選時間就好,超方便。朋友看到說「這個好用,也借我用!」於是她興沖沖開放給另外五個美甲師一起用。\u003C\u002Fp>\n\u003Cp>一週後災難來了:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>兩個客人\u003Cstrong>同時\u003C\u002Fstrong>點了同一個 11:00,系統兩個都收——因為它從沒想過「兩個人同一秒按下去」會怎樣。\u003C\u002Fli>\n\u003Cli>五家店的預約資料\u003Cstrong>全混在一起\u003C\u002Fstrong>,A 店看得到 B 店的客人。\u003C\u002Fli>\n\u003Cli>有個客人用舊手機打開,版面整個跑掉,根本按不到送出。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>根本問題\u003C\u002Fstrong>:自己用的時候沒有「並發」、沒有「別人的資料」、只有「你的手機」。給別人用,這三件事全冒出來。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>該怎麼解\u003C\u002Fstrong>:用資料庫交易與鎖,確保同一時段只會成立一筆(race condition 要主動處理,不能靠運氣);做\u003Cstrong>多租戶資料隔離\u003C\u002Fstrong>,每個帳號只看得到自己的資料;介面要響應式(RWD),顧及各種螢幕尺寸。\u003C\u002Fp>\n\u003Ch2 id=\"%E6%95%85%E4%BA%8B%E4%BA%8C%3A%E9%98%BF%E5%93%B2%E7%9A%84-ai-%E6%96%87%E6%A1%88%E5%B7%A5%E5%85%B7%2C%E4%B8%80%E5%85%AC%E9%96%8B%E5%B0%B1%E6%94%B6%E5%88%B0%E5%A4%A9%E5%83%B9%E5%B8%B3%E5%96%AE\" tabindex=\"-1\">\u003Ca class=\"header-anchor\" href=\"#%E6%95%85%E4%BA%8B%E4%BA%8C%3A%E9%98%BF%E5%93%B2%E7%9A%84-ai-%E6%96%87%E6%A1%88%E5%B7%A5%E5%85%B7%2C%E4%B8%80%E5%85%AC%E9%96%8B%E5%B0%B1%E6%94%B6%E5%88%B0%E5%A4%A9%E5%83%B9%E5%B8%B3%E5%96%AE\">故事二:阿哲的 AI 文案工具,一公開就收到天價帳單\u003C\u002Fa>\u003C\u002Fh2>\n\u003Cp>行銷顧問阿哲 vibe 了一個「輸入主題、自動生一週貼文」的工具,接了 OpenAI 的 API,自己用省下超多時間。他決定包成月費訂閱來賣。\u003C\u002Fp>\n\u003Cp>上線第三天,他收到 API 帳單——\u003Cstrong>三萬多塊美金\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cul>\n\u003Cli>他把 API key \u003Cstrong>直接寫在前端\u003C\u002Fstrong>,被人從瀏覽器扒走,拿去盜刷。\u003C\u002Fli>\n\u003Cli>沒有任何\u003Cstrong>登入\u002F驗證\u003C\u002Fstrong>,網址一外流,全世界都能免費用他的額度。\u003C\u002Fli>\n\u003Cli>沒有\u003Cstrong>限流\u003C\u002Fstrong>,一支機器人幾秒鐘打了幾萬次。\u003C\u002Fli>\n\u003Cli>他甚至不知道\u003Cstrong>誰用了多少\u003C\u002Fstrong>,因為根本沒做用量計量,更別說計費。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>根本問題\u003C\u002Fstrong>:自己用的時候,你信任你自己、你知道成本、你不會攻擊自己。給別人用,這些假設全部不成立。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>該怎麼解\u003C\u002Fstrong>:金鑰一律放\u003Cstrong>後端\u003C\u002Fstrong>、用伺服器當代理(前端永遠碰不到 key);加上\u003Cstrong>身分驗證與授權\u003C\u002Fstrong>;做 \u003Cstrong>rate limiting\u003C\u002Fstrong> 防濫用;把\u003Cstrong>用量計量 + 成本上限\u003C\u002Fstrong>做起來,才敢安心開訂閱。這些,正是我在〈\u003Ca href=\"\u002Fblog\u002Fvibe-coding-hidden-costs\">Vibe Coding 的四個隱形成本\u003C\u002Fa>〉裡說的「資安是 AI 最愛跳過、代價卻最高」的那一塊。\u003C\u002Fp>\n\u003Ch2 id=\"%E6%95%85%E4%BA%8B%E4%B8%89%3A%E9%98%BF%E5%A7%A8%E7%9A%84%E5%BA%AB%E5%AD%98%E8%A1%A8%2C%E5%93%A1%E5%B7%A5%E4%B8%80%E8%B5%B7%E7%94%A8%E4%B9%8B%E5%BE%8C%E8%B3%87%E6%96%99%E5%85%A8%E4%BA%82%E4%BA%86\" tabindex=\"-1\">\u003Ca class=\"header-anchor\" href=\"#%E6%95%85%E4%BA%8B%E4%B8%89%3A%E9%98%BF%E5%A7%A8%E7%9A%84%E5%BA%AB%E5%AD%98%E8%A1%A8%2C%E5%93%A1%E5%B7%A5%E4%B8%80%E8%B5%B7%E7%94%A8%E4%B9%8B%E5%BE%8C%E8%B3%87%E6%96%99%E5%85%A8%E4%BA%82%E4%BA%86\">故事三:阿姨的庫存表,員工一起用之後資料全亂了\u003C\u002Fa>\u003C\u002Fh2>\n\u003Cp>雜貨店老闆阿姨做了一個「Google 試算表 + 一點 AI」的庫存小工具,自己對帳對得很開心。生意變好,她請了兩個員工一起更新。\u003C\u002Fp>\n\u003Cp>結果:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>兩個員工\u003Cstrong>同時改同一格\u003C\u002Fstrong>,後存的蓋掉前存的,庫存數字對不起來。\u003C\u002Fli>\n\u003Cli>有人手滑\u003Cstrong>刪掉一整欄\u003C\u002Fstrong>,沒有備份、救不回來。\u003C\u002Fli>\n\u003Cli>月底要看歷史進貨,才發現資料是\u003Cstrong>就地覆蓋\u003C\u002Fstrong>的,過去的紀錄根本沒留,也不知道「這筆是誰改的」。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>根本問題\u003C\u002Fstrong>:自己用的時候,規則在你腦子裡、只有你會動它、你記得改過什麼。多人協作,就需要「就算有人犯錯也不會釀災」的機制。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>該怎麼解\u003C\u002Fstrong>:做\u003Cstrong>權限分級\u003C\u002Fstrong>(誰能看、誰能改、誰能刪);\u003Cstrong>自動備份與版本紀錄\u003C\u002Fstrong>,手滑也能還原;留\u003Cstrong>稽核軌跡\u003C\u002Fstrong>(誰、何時、改了什麼);關鍵欄位加\u003Cstrong>防呆驗證\u003C\u002Fstrong>。給人用的系統,要假設「人一定會犯錯」,然後讓錯誤不致命。\u003C\u002Fp>\n\u003Ch2 id=\"%E7%9C%8B%E5%87%BA%E5%85%B1%E9%80%9A%E9%BB%9E%E4%BA%86%E5%97%8E%3F\" tabindex=\"-1\">\u003Ca class=\"header-anchor\" href=\"#%E7%9C%8B%E5%87%BA%E5%85%B1%E9%80%9A%E9%BB%9E%E4%BA%86%E5%97%8E%3F\">看出共通點了嗎?\u003C\u002Fa>\u003C\u002Fh2>\n\u003Cp>三個故事的工具,\u003Cstrong>自己用的時候都 100% 正常\u003C\u002Fstrong>。它們不是「做壞了」,而是\u003Cstrong>從來沒有為「別人」設計過\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>而「為別人設計」要考慮的事——並發、資料隔離、資安、身分、計量、權限、備份、稽核、各種裝置、各種誤用——沒有一項會在你自己用的時候冒出來。它們全都藏在「開放給第一個外部使用者」的那一刻之後。\u003C\u002Fp>\n\u003Cp>這也是為什麼 vibe coding 一個 demo 很快樂,把它變成真正能賣的服務卻那麼痛:\u003Cstrong>你跨越的不是一條線,是一整個領域。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2 id=\"%E9%80%99%E6%AD%A3%E5%A5%BD%E6%98%AF%E6%88%91%E5%80%91%E7%9A%84%E5%84%AA%E5%8B%A2\" tabindex=\"-1\">\u003Ca class=\"header-anchor\" href=\"#%E9%80%99%E6%AD%A3%E5%A5%BD%E6%98%AF%E6%88%91%E5%80%91%E7%9A%84%E5%84%AA%E5%8B%A2\">這正好是我們的優勢\u003C\u002Fa>\u003C\u002Fh2>\n\u003Cp>現在「做一個自己用的工具」門檻很低,人人都做得到,這是好事。但「把它變成一個給很多人用、還撐得住的服務」,靠的不是會不會 vibe code,而是\u003Cstrong>有沒有真的把 SaaS 從 0 養到有人付錢用過\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>這剛好是我做了十年的事。上面這三類坑——並發、多租戶、資安、計費、權限、備份——我做各種 SaaS 的時候全踩過,也知道怎麼\u003Cstrong>在一開始就把地基打對\u003C\u002Fstrong>,而不是等出事了再回頭拆。\u003C\u002Fp>\n\u003Cp>就像我在〈\u003Ca href=\"\u002Fblog\u002Fsoftware-last-mile\">差最後一哩\u003C\u002Fa>〉裡說的:能做出來只是前面那 10%,讓它在真實世界、對真實的人穩穩運作,才是真正值錢的那段。\u003C\u002Fp>\n\u003Ch2 id=\"%E5%8F%8D%E9%81%8E%E4%BE%86%E8%AA%AA%2C%E5%A6%82%E6%9E%9C%E4%BD%A0%E6%98%AF%E5%B0%8F%E5%BA%97%E5%AE%B6\" tabindex=\"-1\">\u003Ca class=\"header-anchor\" href=\"#%E5%8F%8D%E9%81%8E%E4%BE%86%E8%AA%AA%2C%E5%A6%82%E6%9E%9C%E4%BD%A0%E6%98%AF%E5%B0%8F%E5%BA%97%E5%AE%B6\">反過來說,如果你是小店家\u003C\u002Fa>\u003C\u002Fh2>\n\u003Cp>這篇講的是「別把自己隨手 vibe 的東西,輕率拿去給別人用」。但有另一種人,我想對你說幾乎相反的話。\u003C\u002Fp>\n\u003Cp>如果你是個小店家,每天都在跟一套「不合身」的訂閱管理系統鬥——它的流程跟你店裡實際跑的不一樣、你最需要的那個功能它偏偏沒有、一堆用不到的功能你每月照付——那我要告訴你一件事:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>以前身為工程師,我會勸你別自己做系統,因為太貴、不划算。但現在,AI 把客製開發的成本和時間打了下來,我的建議改口了。\u003C\u002Fstrong> 為了那些現成系統給不了的客製,找對的人用 AI 幫你做一套合身的,現在真的划算了。\u003C\u002Fp>\n\u003Cp>關鍵是「找對的人」——不是自己硬 vibe(你已經在上面看過會怎樣),而是找有工程底的人用 AI 做,兼顧「合身」與「地基」。這一塊,我下一篇想好好談。\u003C\u002Fp>\n\u003Ch2 id=\"%E4%BD%A0%E4%BB%8A%E5%A4%A9%E5%8F%AF%E4%BB%A5%E5%B8%B6%E8%B5%B0%E7%9A%84%E4%B8%89%E4%BB%B6%E4%BA%8B\" tabindex=\"-1\">\u003Ca class=\"header-anchor\" href=\"#%E4%BD%A0%E4%BB%8A%E5%A4%A9%E5%8F%AF%E4%BB%A5%E5%B8%B6%E8%B5%B0%E7%9A%84%E4%B8%89%E4%BB%B6%E4%BA%8B\">你今天可以帶走的三件事\u003C\u002Fa>\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>想清楚「第一個外部使用者」會遇到什麼\u003C\u002Fstrong>——在你按下「開放」之前,先問:如果同時來十個人、有人亂輸入、有人用舊手機、有人想佔便宜,會怎樣?光是把這些列出來,你就領先一大半人。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>金鑰、驗證、限流,是開放前的最低門檻\u003C\u002Fstrong>——只要你的服務會連到付費 API 或存別人的資料,這三件沒做好就上線,等於把帳單和風險交給運氣。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>地基要在一開始打,不要等出事再補\u003C\u002Fstrong>——多租戶、權限、備份這些,事後再加往往要打掉重練。一開始多想那十分鐘,省的是之後整包重做的痛。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>如果你手上正好有一個「自己用很順、很想拿出去賣」的工具,卡在不知道怎麼把它變成真的能給人用的服務——那段路,剛好就是我在走的。來聊聊,我幫你把地基一次打對。\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>本文故事均為虛構,用以說明「自用工具」轉為「對外服務」時常見的工程問題;技術解法為實務通則。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n"]