那些做壞的專案教我的事

我以前很容易把「有想法」誤會成「可以做」。

現在比較不一樣。不是比較成熟，是被專案打過幾次之後，至少會先問一句：這東西真的有資料嗎？真的有人需要嗎？我真的做得完嗎？

這篇先把幾個做過、做完、做壞、放棄，或是沒有走到最後的東西整理起來。不是履歷，不是戰績表，比較像專案屍檢報告。

我想整理的不是「我做過哪些 App」，而是這些專案各自打醒了我什麼。

Tap2Go 讓我知道完成一個小東西本身就是能力。HawkGuard 讓我知道市場上已經有人跑很遠時，不能只靠熱血硬追。DriveWorth 讓我知道資料不是最後再補的裝飾。LinkPet 則讓我知道，比賽型專案不是兩個人各做一半就好，而是要把問題、分工、文件和決策同步清楚。

它們有些完成了，有些放棄了，有些還沒真正落地。

但它們都留下同一個提醒：專案不是從寫 code 開始，而是從你能不能清楚回答「為什麼要做、靠什麼做、做到哪裡算完成」開始。

Tap2Go：完成本身就是一個技能

Tap2Go 是我早期練習 Flutter 時做的小作品，也是我人生第一個自己做出來、可以安裝到手機裡的 App。

它沒有什麼驚天動地的題目，也不是要改變世界。它比較像暑假把自己丟進 Flutter、Dart、UI、頁面切換和 App 打包流程裡，硬練一輪。

這個專案最有價值的地方不是技術很難，而是它有收尾。

那時候我從 C 轉到 Dart 和 Flutter，第一次比較具體碰到 widget tree、class、object、state、頁面同步、元件拆分這些概念。現在回頭看，Tap2Go 的程式碼一定還有很多可以改，但它讓我跨過一個很重要的門檻：從「看教學」變成「真的做出一個可以操作的 App」。

我也第一次完整走過 Android APK Release。當 App 真的被包成可以安裝的檔案，再跑進手機裡時，感覺跟在模擬器上看到畫面完全不一樣。

那時候我才理解，做 App 不只是把畫面寫出來而已。它還包含環境安裝、專案結構、互動回饋、狀態變化、資源管理和發布流程。

很多 side project 死掉不是因為技術不會，是因為做到一半就覺得不夠酷、不夠完整、不夠像正式產品。Tap2Go 讓我學到一件比較樸素的事：小專案如果能完成，它就不是白做。

它不是成熟產品，但它完成了自己的學習任務。

這點其實很重要。因為早期學習時，如果每個專案都只做到一半，就很難真正理解「一個東西從開始到收尾」中間到底有哪些細節。

Tap2Go 教我的不是怎麼做一個偉大的產品，而是怎麼把一個小練習做完。

這個技能比我原本想像的更重要。

HawkGuard：市場不會等我慢慢想

HawkGuard，也就是鷹眼守護，是我做過的一個反詐騙 App 原型。

一開始會想做，是因為詐騙真的太常見。可疑簡訊、陌生電話、假投資廣告、奇怪網址、社群私訊，全部都有可能藏著風險。

我當時想做的不是單純來電辨識，而是更廣一點的防詐工具。使用者可以輸入文字、網址、電話號碼，甚至圖片，讓系統先給一個初步風險提示。也希望加入社群回報功能，讓可疑內容可以被大家一起維護。

功能聽起來很合理：關鍵字偵測、警示提醒、案例資料庫、分析紀錄、登入、論壇、儀表板。

但後來問題也很快浮出來。

Whoscall 這類成熟產品已經走在前面，而且不是只多一點功能而已。它們累積的是資料、使用場景、品牌信任、回報機制和長期維運能力。

這讓我學到另一件事：不是每個有意義的問題，都適合我現在用 side project 的規模去打。

市場判斷如果太晚做，最後就會變成「我做了一個比較小、資料比較少、使用者比較不信任的版本」。這句話寫出來很刺耳，但很有用。

更麻煩的是，防詐騙產品跟 DriveWorth 一樣，也是一個資料門檻很高的題目。

可疑內容要怎麼判斷真假？使用者回報要怎麼驗證？過期資料要怎麼處理？不同型態的詐騙要怎麼分類？系統如果誤判，要怎麼避免讓使用者產生錯誤安全感？

這些都不是做幾個頁面就能解決的問題。

HawkGuard 教我的不是「不要做防詐騙」，而是：當一個題目高度依賴資料、信任和即時性時，我必須先想清楚自己的切入點。

如果我要做，就不能只是做一個小版 Whoscall。

我需要回答更尖銳的問題：

• 我到底補了現有產品哪個空缺？
• 我的資料來源跟更新機制是什麼？
• 使用者為什麼願意相信我的判斷？
• 這個功能適合一個人做，還是需要團隊與資料合作？

沒有回答這些問題前，功能列再多都只是讓專案看起來很熱鬧。

DriveWorth：我低估了資料

DriveWorth，也就是駕值觀，原本想做的是買車前的養車成本評估工具。

我自己的背景有汽車修護乙級和丙級，所以這個題目一開始對我來說很自然。很多人買車時只看車價，但真正壓力通常在買下去之後：保養、稅金、保險、油錢、耗材、輪胎、大保養、突發維修。

我想做的不是單純記帳，而是一個購車前的決策工具。使用者輸入車款、年份、里程、油耗、保險、稅金、預期持有年限後，系統可以估算未來 3 到 5 年的總擁有成本，甚至提醒哪些里程點可能會遇到比較大的保養支出。

想法本身不是沒有價值。問題是，我太早把注意力放在 App、API、畫面跟架構，太晚面對真正麻煩的地方：資料。

資料從哪裡來？品質穩不穩？不同車款、年份、保養項目、零件價格、工資行情、稅金級距、保險條件能不能對齊？沒有足夠資料時，是不是只能靠一堆假設硬撐？

這些問題沒有先處理，後面寫再多 code 都像在漂亮地修補一個不穩的地基。

尤其 DriveWorth 這種會影響金錢決策的工具，不能只算出一個看起來很精準的數字。它必須讓使用者知道每個估算背後的假設，也要提供可信、可調整、能幫助判斷的成本範圍。

這才是它真正難的地方。

所以 DriveWorth 後來停下來了。不是因為這個題目完全不能做，而是我當時還沒有把資料來源、資料結構、估算模型和可信度問題想清楚。

DriveWorth 教我的結論很直接：資料密集的題目，不是 UI 做出來就算有進度。

如果資料是產品的底層，那我就不能把它當成最後再補的東西。

下一次碰到這種題目，我應該先做的不是畫漂亮畫面，而是先問：

• 最小可用資料集是什麼？
• 哪些資料可以人工整理？
• 哪些資料需要長期維護？
• 使用者為什麼要相信這個結果？
• 如果估算錯了，會造成什麼風險？

這些問題聽起來不像寫程式，但它們就是產品能不能成立的核心。

LinkPet：比賽教我的團隊合作

LinkPet 是我們為 2026 行動應用創新賽準備的 AR AI 陪伴 App。

它的想法是做一個可以陪伴使用者的 AI 虛擬角色。不是單純把聊天機器人套上可愛外皮，而是希望透過 2D 互動、AR 空間呈現、語音對話和本機記憶，讓角色比較像日常生活裡可以自然出現的陪伴夥伴。

這個專案最後沒有通過初審，也沒有走到完整開發階段。

但它跟前面幾個專案不太一樣。Tap2Go 是個人練習，DriveWorth 和 HawkGuard 比較像我自己從產品想法一路撞到資料與市場問題。LinkPet 則讓我第一次更完整碰到比賽型專案和團隊合作的限制。

比賽專案不是只要題目有趣就夠了，也不是兩個人把工作切開，各自埋頭做完就好。

它需要讓評審在很短時間內理解：

• 使用者問題是什麼？
• 為什麼這個方案適合解決？
• 核心體驗到底長什麼樣？
• 技術風險在哪裡？
• 團隊有沒有能力把想法整理成可執行的成果？

我們當時想了很多功能：2D / AR 雙模式、語音與文字互動、個人化設定、持續記憶、觸碰與餵食、本機資料管理。

這些方向不是錯，但功能一多，團隊之間就更需要有共同理解。

如果我腦中想的是陪伴感，隊友想的是技術展示，文件寫的是比賽亮點，最後做出來的東西就很容易散掉。不是大家不努力，而是沒有把「我們到底要做什麼」同步到同一個版本。

所以 LinkPet 最重要的收穫，其實是團隊合作。

一個人做專案時，很多事情可以靠腦袋裡的默契撐過去。想到哪裡改哪裡，命名亂一點也只有自己痛苦。

但多人合作不一樣。

想法要講清楚，工作要拆分，文件要同步，Git branch 和 merge 要管理，決策也要留下脈絡。這些事情看起來不像功能，但它們就是軟體工程的一部分。

LinkPet 教我的重點是：團隊合作不是兩個人各寫一半，而是要讓彼此知道現在在做什麼、為什麼這樣做，以及下一步要往哪裡走。

這次之後，我也比較理解為什麼專案需要文件、討論紀錄和明確分工。

它們不是形式，也不是只有大公司才需要的流程。對學生比賽專案來說，這些東西反而更重要，因為時間短、方向容易變、大家的理解也不一定一開始就一樣。

如果之後再做一次類似的比賽專案，我會更早做幾件事：

• 先把核心問題和作品定位寫成一頁文件。
• 把功能分成必做、可做、先不做。
• 每次討論後留下決策紀錄。
• 提早確認誰負責企劃、設計、程式、簡報和 Demo。
• 不要假設隊友知道我腦中正在想什麼。

這些聽起來很基本，但 LinkPet 讓我知道，基本的協作如果沒有做好，後面功能想得再漂亮也會變得很難推進。

這幾個專案串起來，其實在講同一件事

把 Tap2Go、HawkGuard、DriveWorth 和 LinkPet 放在一起看，我發現它們不是四個完全分開的故事。

它們比較像是我學做專案時的幾個階段。

Tap2Go 解決的是「我能不能把東西做出來」。HawkGuard 讓我看到「市場和信任不是等我做好才開始存在」。DriveWorth 開始問「這個東西背後的資料撐不撐得住」。LinkPet 則提醒我「一個想法要和別人一起做出來，需要清楚的溝通、分工和協作方式」。

以前我會把技術棧看得很重。

Flutter、FastAPI、Supabase、PostgreSQL、ARKit、AI、Docker，這些都很有吸引力。技術越多，專案看起來越像很厲害。

但現在比較知道，技術棧不是專案的答案。

技術只是你選來解決問題的工具。真正要先想清楚的是：

• 使用者遇到什麼問題？
• 這個問題值不值得解？
• 現有產品已經做到哪裡？
• 我的切入點有沒有差異？
• 需要哪些資料才能讓結果可信？
• 最小可驗證版本是什麼？
• 做到什麼程度就應該收尾或停損？

這些問題如果沒有先處理，後面就很容易變成用更多技術掩蓋更模糊的產品判斷。

下次不要再犯

整理下來，目前最明確的幾條規則是：

• 不要把技術棧當成專案進度。
• 資料來源不清楚的題目，要先停下來。
• 市場上已經有成熟產品時，要先問自己差異在哪。
• 小專案完成，比大專案喊很久更有用。
• 放棄不是問題，不知道自己為什麼放棄才是問題。
• 團隊專案要提早整理文件、分工和決策脈絡。
• 比賽或提案型專案，要先把問題、分工、文件和展示方式對齊。
• 任何會影響使用者現實決策的產品，都不能只靠漂亮畫面和模糊估算。

我也會開始把專案分成幾種不同狀態，而不是全部混在一起看。

有些專案適合完成，例如 Tap2Go，因為它的任務是練習和收尾。

有些專案適合先停下來，例如 DriveWorth，因為資料底層還沒有準備好。

有些專案要重新找切入點，例如 HawkGuard，因為市場和信任門檻太高。

有些專案則要更早建立協作方式，例如 LinkPet，因為團隊不是靠默契就會自然同步。

這樣想以後，放棄就比較不只是「我做失敗了」。

它比較像是專案管理的一部分。

該完成的完成，該停損的停損，該縮小的縮小，該驗證的先驗證。

結語：做壞的專案也要被整理

這個 blog 之後會放更多這類東西。不是只有做成功的，也會放做壞的。

因為成功案例通常很好講，失敗案例比較難看，但比較能救下一個專案。

我現在回頭看這些專案，不會覺得它們只是黑歷史。

Tap2Go 讓我真的開始做 App。HawkGuard 讓我重視市場和信任。DriveWorth 讓我重視資料。LinkPet 讓我重視表達、分工和團隊協作。

它們有些沒有完成，有些方向不夠清楚，有些真的太早開始寫。

但這些撞牆經驗加起來，剛好變成下一次做專案前的檢查表。

如果一個專案最後沒有成功，但它讓我下次少犯一次同樣的錯，那它就不算完全浪費。