鷹眼守護 HawkGuard：一個反詐騙 App 早期嘗試

鷹眼守護是我以前做過的一個反詐騙 App 概念。

它最後沒有變成完整產品，但回頭看，這個專案其實滿重要。它讓我第一次比較具體地意識到：一個 App 不只是畫面做出來、功能串起來就好，真正麻煩的東西通常藏在資料、判斷邏輯和使用情境裡。

專案起點：詐騙不只來自電話

一開始會想做鷹眼守護，是因為那陣子真的太常看到各種詐騙案例。

可疑簡訊、陌生電話、假投資廣告、奇怪的網址，甚至是社群平台上的貼文或私訊，都有可能藏著詐騙風險。

當時我有注意到 Whoscall 這類工具。它在電話辨識上已經做得很成熟，也確實解決了很多陌生來電的問題。

但我那時候開始想一件事：

如果詐騙不只是從電話來，那其他地方怎麼辦？

所以我想做的不是單純的來電辨識 App，而是一個可以協助使用者檢查更多可疑內容的反詐騙工具。

核心概念：多一層判斷依據

鷹眼守護的核心概念很直接：使用者可以輸入文字、網址、電話號碼，甚至是圖片，讓系統先幫忙做初步判斷。

遇到一個看起來怪怪的訊息或連結時，使用者不用完全靠直覺猜，而是可以先透過工具得到一個風險提示。

這個提示不一定要取代人的判斷，但至少可以多一層參考。

除了單次分析之外，我當時也希望加入社群回報功能。因為詐騙資訊很依賴即時性，如果有人遇到可疑內容，可以回報出來，其他人就有機會更早看到、避開類似風險。

這也是我覺得這個專案最有意思的地方：它不只是單人使用的工具，而是有機會變成一個大家一起維護的反詐騙防護網。

功能規劃與技術方向

功能規劃上，鷹眼守護大概包含幾個主要模組：

• 詐騙內容分析
• 分析紀錄保存
• 使用者登入
• 社群論壇
• 首頁儀表板
• 個人設定

技術上，這個專案使用 Flutter 開發，目標是同時支援 iOS 和 Android。

架構上我也有嘗試用比較模組化的方式整理，讓分析、登入、論壇、設定等功能可以分開維護。這對當時的我來說不只是寫畫面，而是在練習怎麼把一個 App 拆成比較清楚的功能邊界。

資料與即時同步的部分，原本規劃使用 Supabase。後續也預留了接 FastAPI 後端的空間，想像中未來可以進一步整合文字分析、OCR、網址檢測，甚至是機器學習模型。

現在回頭看，這些技術方向不算錯，但問題是我當時太快跳到「可以接哪些技術」，太慢面對「這些判斷到底要靠什麼資料」。

為什麼後來沒有繼續做下去？

這個專案後來沒有繼續深入做下去。

其中一個原因是，Whoscall 也開始往更多反詐騙功能發展。原本我想補足的方向，市場上也逐漸有人開始做了。

這不代表不能做，但代表我需要更清楚回答一個問題：

我的版本到底差在哪裡？

如果只是做一個比較小、資料比較少、使用者比較不信任的版本，那它很難真的解決問題。

另一個原因是，當時我對資料的重要性還沒有那麼深的體會。功能想了很多，畫面也可以規劃，但真正要讓它變成可靠的產品，其實沒有想像中簡單。

後來在做 DriveWorth 的時候，我才更明顯感受到一件事：資料真的很珍貴。

後來才理解：資料才是真正的門檻

如果一個系統想要做 AI 分析、風險判斷或預測功能，最難的往往不是把畫面做出來，也不是把幾個功能頁面串起來。

真正困難的是背後要有足夠可靠、乾淨，而且能持續累積的資料。

回頭看鷹眼守護，我才發現它真正的挑戰不是 App 本身，而是詐騙案例資料要怎麼收集、分類、驗證和更新。

這裡面每一件事都不簡單：

• 可疑內容要怎麼判斷真假？
• 使用者回報的資料要怎麼驗證？
• 過期的詐騙資訊要怎麼處理？
• 不同型態的詐騙案例要怎麼分類？
• 系統給出風險提示時，要怎麼避免誤判？

如果沒有穩定的資料來源，系統就很難做出可信的判斷。資料品質不好，就算介面做得再漂亮，分析結果也不一定有價值。

專案反思：App 不是只有 UI

鷹眼守護讓我重新理解「做 App」這件事。

以前可能會覺得，只要會寫 UI、會做頁面、會把按鈕和資料串起來，好像什麼 App 都能做出來。

但真的開始規劃一個產品後才發現，App 不是只有畫面。

背後還有很多商業邏輯、資料來源、使用情境、風險判斷規則，以及使用者到底為什麼需要它。

這些東西如果沒有想清楚，功能再多也可能只是堆在一起。看起來很完整，但實際上不一定能解決真正的問題。

結語：沒有完成，但不是沒有價值

鷹眼守護最後雖然沒有完成到完整產品階段，但它對我來說不是完全失敗的專案。

它更像是一個早期嘗試，讓我開始知道：一個應用不只是功能多就夠了，而是要真的理解它要解決什麼問題、資料從哪裡來、判斷依據是否可信，還有它有沒有辦法長期運作。

也因為這個經驗，後來我在做 DriveWorth 的時候，才會更重視資料結構、資料來源和預測模型。

某種程度上，鷹眼守護算是我後來開始重視資料驅動應用的伏筆。