Helper CTO 系列文章 22｜從 AI 原型到正式產品：要補的不是功能，是可維護性

「東西做出來了，客戶試用也說不錯，接下來要正式上線，我還要補什麼功能？」用 AI 工具做出原型的老闆，十個有九個先問這句。答案常讓人意外：先不要補功能。原型壞了可以重新生成，正式產品上面有真實客戶的訂單，壞一次就是真的損失。你不是功能做得不夠多，而是缺一個「有人能長期負責它」的底。可維護性拆開來是四件事，這篇講怎麼補。

原型跟產品，目標不一樣

原型的目標是驗證想法，怎麼做出來都行；正式產品要在你不看著的時候也正常運作。目標換了，評價標準跟著換：

• 原型問「能不能跑」，產品要問「壞了誰會先知道」。
• 原型問「多快做得出來」，產品要問「半年後還改不改得動」。
• 原型問「我看不看得懂」，產品要問「換一個人接不接得起來」。
• 原型問「做得出來嗎」，產品要問「能不能安心放著不管」。

拿原型的做法一路加功能，功能越多越沒人敢動，最後只剩 AI 對話紀錄看得懂。能 demo 不等於能上線那篇列的五件事，背後就是同一件事。

可維護性是什麼：四件事

白話講就是：這個系統能不能被人長期照顧。四件事都可以拿來問自己：

四件事都做到，系統就從「只有做的人懂」變成「任何合格的人都能接」。

為什麼先補這個，不是先加功能

功能是加在系統上的，底不穩，加越多越危險。更現實的理由是：可維護性越晚補越貴。

• 功能少的時候補結構、補測試，動到的範圍小、風險低。
• 功能堆了一年再補，每動一個地方都要顧到十個地方。
• 拖到沒人敢動的階段，補的成本會逼近整個重做一次。
• 底沒補就一直加功能，等於替未來的自己挖洞。

AI 一直改壞同一個地方那篇講的，就是這筆債欠到後期的樣子。

補的順序

四件事不必一次做完，順序照「出事的代價」排：

1. 先備份：資料庫與上傳的檔案每天備份，而且放在另一個地方。
2. 再讓它能重來：寫下架設步驟，實際照著做一次確認架得起來。
3. 接著讓它壞了會叫：網站活著嗎、有沒有報錯、主機資源夠不夠。
4. 然後補測試：從會賠錢的那條路徑開始——結帳、登入、表單送出。
5. 最後整理程式碼：清掉 AI 順手生出來、從來沒人用的東西。

原則是：先讓它「壞了有救」，再讓它「不容易壞」，最後才是「好改」。這跟Vibe Coding 與真正系統架構的落差那篇的結論一樣——差距在功能底下。

補完之後，誰來顧

補到「可以被照顧的狀態」，還是要有人照顧。你需要的不是一個全職的人，是一個機制：

• 備份有人定期確認真的還原得了，不是只看到跑成功的紀錄。
• 監控叫了有人看得懂，而且知道下一步該做什麼。
• 安全更新有人定期做，不是等出事了才想到。
• 小地方想改有人直接做，不必每一件都重談一次。
• 主機或服務出問題，有人在 1 個工作日內回應處理。

這就是我們說的「接手」：不重做你的東西，是把它整理到可維護，然後持續顧著。

恩梯科技接手 AI 原型時的四個承諾

• 先把產品整理到可維護，再談要不要加功能，不急著勸你重做。
• 健檢只需要看得到程式碼，不需要正式環境的帳號密碼。
• 基本維護 NT$6,000 起／月，按月請款，想停隨時可以停。
• 接手、維護、改善、繼續開發，同一組人從頭顧到尾。

原型驗證想法，產品長期營運——中間那一步，有人陪你走比較省。

從原型走到正式產品，缺的通常不是功能，是有人長期負責。恩梯科技以 Helper CTO 的角色接手並維護這樣的系統——像公司的技術負責人，只是不在你的編制裡。第一步是 60 分鐘的系統健檢：讓我們看得到程式碼就好，不需要正式環境的帳號密碼，3～5 個工作天內你會拿到一頁看得懂的報告，告訴你四件事現在各補到哪。如果你的原型已經有真實客戶在用、你卻不確定它撐不撐得住，我們先幫你量一次：Helper CTO：系統維運方案。