「以前一個前端工程師很難獨立完成 App + Backend + DB + Landing Page。現在，我做到了。」
身為一個寫了多年 Angular 的前端工程師，我從沒想過有一天能獨立完成一款手機 App——從 UI 到後端、從資料庫到雲端部署，以及 Landing Page，全部自己搞定。
開發時程：約 2 個月（業餘時間）
這篇文章記錄了我從 2025 年底開始，如何用 Vibe Coding 模式與 AI 協作，從零打造了「書櫃日記」這款漫畫收藏管理 App 的完整歷程，以及我對 AI 時代工程師角色的反思。
緣起：收藏狂的痛點與前端的野心
這幾年開始沉迷於收藏紙本漫畫，收著收著就遇到了一個問題：家裡藏書越來越多，根本記不住哪些買過、哪些還缺。
市面上的 App 不支援「系列進度追蹤」（我收了海賊王 1~85 集，還缺哪幾本？），也沒辦法區分「愛藏版」、「新裝版」。我想要的很簡單：掃條碼、自動抓資料、然後告訴我還差哪幾本。
同時，身為工程師，我一直有個「想做 App」的念頭。看著 React Native、Flutter 逐漸成熟，我幾度想跳進去，但每次都被環境設定、學習新語言與原生生態系勸退。
直到 2024 年，AI 工具成熟。我嘗試了 Vibe Coding——不再一個人造輪子，而是與 AI 結對開發，讓我專注在**「我想要什麼」，而 AI 負責「怎麼實現」**。這個模式讓我終於跨出舒適圈，完成了這個產品。
產品概覽：不只是一個 App
「書櫃日記」不只是一個手機 App，它是一個 End-to-End 的完整系統：
| 模組 | 技術棧 | 說明 |
|---|---|---|
| App | React Native + Expo | 核心功能，目前提供 APK 下載，支援條碼掃描 (Vision Camera / MLKit)、離線管理 |
| Local DB | SQLite (expo-sqlite) | 離線優先架構，資料儲存於手機端 |
| 雲端 API | Cloudflare Workers + Hono | Serverless 後端，處理資料同步 |
| ISBN 資料庫 | Cloudflare D1 + R2 | 公共書籍資料庫，儲存使用者掃描的 ISBN 資訊 |
| 圖片 CDN | Cloudflare Workers | 封面圖自動 WebP 壓縮與快取，減少 85% 體積 |
| 爬蟲代理 | Google Apps Script | 整合多個外部 ISBN API，解決 CORS 問題 |
| Landing Page | Vite + React + Tailwind v4 | 產品官網 |
架構設計：前端思維的延伸
1. 為什麼選 React Native + Expo？
身為前端，我對 React 生態非常熟悉。React Native 讓我能用熟悉的 JSX 與 Hooks 開發 App，而 Expo 更是神器——它把原生配置都封裝好了，尤其是 Expo Router，讓我可以用類似 Next.js 的檔案路由方式組織畫面，幾乎沒有學習曲線。
2. 為什麼選 Local-First (SQLite)?
漫畫店裡的訊號通常不好。我希望使用者可以在完全離線的情況下掃描書籍、管理收藏，等到有網路時再同步。SQLite 作為手機端的資料庫，輕量且極快。
3. 為什麼選 Cloudflare D1 + Workers？
我不想管 Server。Cloudflare 的 Serverless 生態讓我可以用極低成本運行後端。D1 本身基於 SQLite，這讓我的 Local DB 與 Cloud DB 共用幾乎相同的 Schema，大幅降低維護複雜度。
核心功能開發：AI 協作的真實體驗
1. 三層級資料結構：系列 → 作品 → 集數
漫畫收藏最麻煩的是「層級」。一般的書籍 API 把每本書視為獨立資料，但漫畫是「一套」的。我需要：
- L1 系列 (Series)：例如「小學館少年漫畫」。
- L2 作品 (Work)：例如「名偵探柯南」。
- L3 集數 (Volume)：例如「第 1 集」。
我向 AI 描述這個需求，它快速生成了 SQLite Schema、TypeScript Type 定義，以及計算進度條的 Hook。我只需要專注在「進度條顏色該怎麼變化」這種體驗層面的決策。
2. ISBN 掃描與眾人協作
這是 App 的靈魂功能。但現實是沒有一個 API 能完美涵蓋所有繁體中文書籍。
於是我設計了一個架構：
- GAS 中繼層：依序查詢 Google Books, Open Library 等來源，清洗資料。
- 公共資料庫回饋：當使用者掃描並新增一本書，這筆資料會同步到我的 D1 公共資料庫。
- 後人乘涼：後續使用者掃描同一本書時，直接從 D1 秒速抓取，不用再等外部 API。
3. 解鎖「第一次」的成就
對前端仔來說，這次開發解鎖了很多生涯第一次：
- 第一次設計正規化資料庫 Schema
- 第一次寫後端 API (Hono)
- 第一次處理圖片壓縮與 CDN
- 第一次打包 Android APK 並公開下載
踩坑實錄：AI 無法一步到位的地方
Vibe Coding 並非萬能。AI 給的方案有時是通用的，但在特定場景下會失效，這時就需要工程師的 Debug 能力。
1. 跨平台軟體鍵盤遮擋
在 React Native 開發中，軟體鍵盤彈出時遮住輸入框是經典痛點，而且 iOS 與 Android 的行為完全不同。
AI 建議的 KeyboardAvoidingView 雖然是標準解法，但經常在特定情境下失效。
- Android：需要調整
AndroidManifest.xml中的windowSoftInputMode設定才能生效。 - iOS：需要精確計算
behavior="padding"的 offset。
這讓我學到：AI 給的通用解法，通常無法完美處理跨平台的 Edge Case，還是得針對不同平台調校。
2. D1 同步的時間戳記地獄
有一段時間，同步到 D1 的 createdAt 欄位總是 NULL。追蹤後發現，SQLite 的時間是字串，而我在同步邏輯中沒有正確處理時區與 ISO 格式轉換。這類全鏈路的資料流問題，AI 很難一開始就預見，需要人工排查。
3. TailwindCSS v4 的新語法
Landing Page 開發時，剛好遇上 Tailwind v4 發布。AI 的資料庫還停留在 v3，即使我貼了文件給它，它有時還是會寫出舊的 bg-gradient-to-r。v4 其實改成了 bg-linear-to-r，且不再需要 tailwind.config.js。這花了我不少時間手動修正。
學到的事：跨界開發的真實體悟
1. 架構設計比寫 Code 更重要
以前做前端，通常是接 API、畫畫面，較少參與資料庫設計。這次自己設計 DB Schema，才深刻體會到「資料結構決定應用程式的命運」。一開始命名不精確（IP、SeriesGroup 混用），導致後續重構花了好幾倍的時間。先想好名詞定義、畫好 ER 圖，比急著寫 Code 重要太多。
2. AI 能帶你入門，但不能帶你精通
AI 最大的價值是「降低門檻」。以前看到 React Native 文件就頭暈，現在可以直接問 AI 怎麼開始。但當遇到效能瓶頸、記憶體洩漏或特定平台的 Bug 時，還是得靠工程師的基本功去查文件、看 Source Code。AI 是加速器，不是自動駕駛。
3. 完成比完美重要
作為工程師，我們很容易陷入「還不夠完美」的焦慮，想把功能修到 100 分才發布。但這次為了趕 v1.0 上線，我學會了做出取捨。iOS 版本還在等待開發者帳號審核，Android 上架也需要測試門檻，但我選擇先打包 APK 直接提供下載。雖然不是最正規的發布方式，但這能讓想要用的人立刻就能用。先讓產品上線（無論形式為何）與真實世界碰撞，比死守在開發環境裡重要。
UI/UX 的堅持：溫暖書房美學
我不希望 App 看起來像冷冰冰的資料庫工具。我告訴 AI：「我要一種『溫暖書房』的感覺，有木頭質感、柔和燈光。」
我們定義了一套設計系統：
- 主色調：陶土橘 (#C67B5C)、森林綠 (#5C8C6B)。
- 質感：暖棕色漸層搭配 Noise 紋理，以及半透明的玻璃擬態卡片。
為了 Landing Page 的效能，我還將 Demo 影片用 ffmpeg 轉為 WebM 格式，體積從 34MB 降到 5.7MB，減少了 83%。
結語：AI 時代工程師的新價值
回顧這段歷程，我最大的收穫是重新思考了工程師的角色。
在 AI 之前，我需要花大量時間查語法、寫 Boilerplate。在 AI 之後，我可以：
- 用自然語言描述需求，快速產出原型。
- 用技術判斷力 Review 程式碼，挑出架構與安全問題。
- 把時間花在架構設計、產品決策、使用者體驗這些高價值的事情上。
AI 不是取代工程師，而是放大工程師的產能。
體驗書櫃日記
如果你也是漫畫愛好者，歡迎下載試用！
- 前往官網 (Landing Page)：查看完整功能介紹與下載 APK。
- 技術交流：如果你對 React Native、Cloudflare 或 AI 協作開發有任何疑問，歡迎交流想法。