看房看少的時候，每一間都記得很清楚；
看房看多之後，真的會全部混在一起。

哪一間採光好？
哪一間廁所格局怪？
哪一間車位不好停？
哪一間開價比較合理？
哪一間其實當下覺得還好，但回家後越想越可以？

一開始我也是用 Excel 整理，但實際看房時很容易懶得補資料，久了之後就變成：

「這間是哪一間？」
「我們上次說缺點很多的是哪一戶？」
「這間有車位嗎？」
「管理費多少？」
「它跟上一間差在哪？」

所以後來就做了這款 App：看房筆記。

它不是房仲平台，也不是物件搜尋平台，而是一個很單純的工具：

幫你把看過的房子、租屋物件、心得、評分與比較結果整理起來。

一、建立專案：買房、租屋可以分開整理

很多人看房不一定只看一種需求。

有些人是準備買房，有些人是先看租屋，也有人可能同時幫家人看不同區域的房子。

所以在看房筆記裡，可以先建立不同的專案，例如：

• 林口買房
• 台北租屋
• 家人換屋參考
• 學區宅比較
• 捷運宅清單

每一個專案都可以獨立管理，不會把所有物件混在一起。

這樣做的好處是，當你看久了之後，不會全部塞在同一份清單裡，而是可以依照目的慢慢整理。

二、輸入物件網址，快速建立筆記

看房之前，我們通常會先在各種房屋網站看到物件資訊。

但每個網站的格式不同，資訊也很分散。

看房筆記的設計方式，是讓你可以先貼上物件網址，之後再建立自己的看房資料。

這邊要特別說明一下：

看房筆記不是直接複製房屋網站的資料庫，也不是提供物件搜尋服務。

它比較像是你自己的筆記本。

你看到一間有興趣的房子，就把網址放進來，建立成自己的看房紀錄，後續再補上實際看房心得、評分、優缺點與比較資料。

三、AI 協助整理目前畫面中的資訊

這是我自己覺得最實用的功能之一。

有些物件頁面資訊很多，包含價格、坪數、樓層、格局、車位、管理費等等。

手動一個欄位一個欄位輸入其實很麻煩，所以 App 裡加入了 AI 協助整理的功能。

操作方式很簡單：

1. 開啟物件頁面
2. 按下建立筆記
3. 系統協助整理目前畫面中的資訊
4. 自動帶入看房筆記欄位
5. 使用者再自行確認與修改

這個功能的定位不是「完全取代人工判斷」，而是幫你省下初步整理資料的時間。

畢竟買房、租屋都是重要決策，最後還是建議自己確認資料是否正確。

四、每一間物件都有自己的詳細筆記

建立物件之後，就可以開始補上自己的看房心得。

例如：

• 實際看房日期
• 開價或租金
• 坪數
• 格局
• 樓層
• 車位
• 管理費
• 採光感受
• 噪音狀況
• 周邊環境
• 交通便利性
• 優點
• 缺點
• 備註

這些資料通常不會全部出現在房屋網站上，很多都是實際看房後才知道的。

例如：

「下午去看採光其實不錯」
「樓下車流聲比想像中明顯」
「客廳很舒服，但廚房偏小」
「車位入口不好轉」
「附近生活機能很好，但晚上可能比較吵」

這些才是真正影響你最後判斷的內容。

五、自訂評分，讓感覺變得更容易比較

看房最麻煩的地方是：

有些房子不是明顯好或壞，而是各有優缺點。

例如 A 物件交通很好，但價格偏高。
B 物件價格漂亮，但採光普通。
C 物件格局方正，但離捷運比較遠。

如果只靠印象，很容易被當下情緒影響。

所以看房筆記加入了評分機制，可以依照自己的感受幫每一間物件打分數。

評分不是要做出絕對標準，而是幫助自己回頭看的時候，能更快回想：

「當時我們為什麼覺得這間不錯？」
「這間分數高，是因為價格好，還是環境好？」
「這間雖然照片漂亮，但實際看完評分不高。」

當看過的物件越多，評分就越有參考價值。

六、比較表：把多間物件放在一起看

買房或租屋很少是只看一間就決定。

通常會看好幾間，然後開始陷入選擇困難。

這時候比較表就很重要。

看房筆記可以把不同物件放在一起比較，像是：

• 價格
• 坪數
• 單價
• 管理費
• 格局
• 車位
• 評分
• 備註

原本分散在不同頁面的資料，整理成比較表之後，差異就會變得比較清楚。

有時候你會發現：

「原本覺得 A 比較貴，但其實坪數也比較大。」
「B 看起來便宜，但管理費加上去不一定划算。」
「C 分數沒有最高，但整體最平均。」

這也是我自己做這個 App 最主要的原因之一。

因為看房最後不是只看單一條件，而是要把價格、地點、格局、生活機能、實際感受全部放在一起比較。

右上角也有匯出PDF功能，可以選擇直式或者是橫式的版型。PDF可以印出來或者分享給親友進行比較。

這邊是從電腦上看匯出的PDF，真的是清楚方便。

七、房貸試算：初步估算每月負擔

買房時，總價只是第一步。

真正要面對的是：

每個月要繳多少？

所以 App 裡也加入了房貸試算功能，可以輸入房屋總價、頭期款、貸款年限、利率等資訊，快速估算每月還款金額。

這個功能很適合在看房時先做初步判斷。

例如看到一間物件覺得不錯，就可以馬上算一下：

「如果買這間，每個月大概要負擔多少？」
「頭期款需要準備多少？」
「利率變動後會不會壓力太大？」

當然，正式貸款條件還是要以銀行核貸結果為準，但初步估算可以幫助自己不要只看總價，而是更實際地評估現金流。

八、資料儲存在手機端，自己保留自己的看房紀錄

看房筆記的設計方向，是讓使用者整理自己的看房資料。

目前資料主要儲存在使用者自己的手機端。

這樣的設計有幾個好處：

第一，資料是自己的筆記，不是公開平台。
第二，不需要把每一次看房紀錄都變成雲端資料。
第三，使用上比較單純，打開 App 就能整理。

不過也因為資料儲存在手機端，所以如果移除 App 或更換手機，就要注意資料備份與保存問題。

未來如果有更多使用需求，也會再評估加入匯出、備份或同步功能。

九、適合哪些人使用？

我覺得看房筆記比較適合這幾種人：

正在買房、看房看很多間的人。
正在租屋，需要比較多個物件的人。
夫妻或家人一起討論房子的家庭。
想把物件優缺點整理起來的人。
看房後常常忘記細節的人。
不想再用 Excel 手動整理的人。

尤其是看房超過五間之後，你會很明顯感覺到：

只靠記憶真的不夠。

照片、價格、格局、優缺點、當天感受，如果沒有記下來，很快就會混在一起。

十、未來想加入的功能

目前看房筆記還在持續調整中，後續我自己也希望加入更多實用功能。

例如：

• 資料備份與轉移
• 多個裝置同步看房專案
• 或者即時問房仲

結語：看房不只是看喜不喜歡，而是要能回頭比較

以前我看房時，常常覺得只要當下記得就好。

但實際看多了之後才發現，人的記憶真的很不可靠。

尤其買房這種金額很大的決定，不能只靠當下感覺。

看房筆記的目的，就是希望把每一次看房都整理起來，讓自己之後可以回頭看、慢慢比較，而不是看完就忘。

它不是要幫你決定哪一間房子最好，而是幫你把資訊整理好，讓你做決定時更清楚。

對我來說，這也是用 AI 和 App 解決自己生活問題的一次實驗。

從自己真的遇到的需求出發，做出一個自己也會用的工具。

下載與使用

目前看房筆記會持續更新功能，如果你也正在買房、租屋，或是常常看完房子就忘記細節，可以試試看這款 App。

App 名稱：看房筆記

下載連結：

Google Play：https://play.google.com/store/apps/details?id=com.abcb.homeviewing.notes

App Store：https://apps.apple.com/us/app/id6780499050

這款 App 的起點不是市場分析，也不是一開始就想做成商品。

它其實很單純，就是來自我自己的需求。

最近這段時間，因為實際有看房、比較房子、整理物件資訊的需求，我才發現這件事情比想像中麻煩很多。

從開始看房到整理資料，前前後後大概看了快十五間房子，每一次整理資料

都是很煩躁。

一開始只是用 Excel 或筆記慢慢整理，但看得越多，資料越容易混在一起。

每一間房子都有不同的價格、坪數、格局、樓層、管理費、車位、地點、採光、噪音、屋況與優缺點。

如果只是看一兩間還好，但當物件數量變多之後，光是回想「那一間到底是哪一間」，就已經開始有點混亂。

於是我開始想：

既然這是自己真的會遇到的問題，能不能把它整理成一款 App？

從自己的痛點開始

看房這件事，表面上只是去現場看看房子。

但實際上，真正困難的是後續整理與比較。

看完一間房子之後，當下可能覺得印象很深。

但如果同一天看了三間、五間，甚至連續幾週都在看不同物件，很多細節很快就會忘記。

例如：

• 哪一間採光比較好？
• 哪一間格局比較方正？
• 哪一間有明顯噪音？
• 哪一間管理費比較高？
• 哪一間有車位？
• 哪一間附近生活機能比較好？
• 哪一間其實有漏水疑慮？
• 哪一間價格看起來合理，但總價壓力比較大？

這些資訊如果沒有在當下整理，之後要靠記憶回想，其實很不可靠。

尤其是買房或租屋都不是小事。

如果只是靠感覺，很容易被某個優點吸引，卻忽略一些實際居住後才會放大的問題。

原本用 Excel 整理，但不夠順手

一開始，我是用比較傳統的方式整理資料。

例如把物件連結貼到 Excel，然後手動輸入價格、坪數、地址、樓層、車位、管理費與備註。

這種方式不是不能用，但有幾個問題。

第一，輸入資料很花時間。

每看到一個物件，都要重新打開表格，複製欄位，慢慢補資料。

第二，手機上操作不方便。

很多時候是在手機上看到物件，或是在外面看房時臨時想補充筆記，但 Excel 在手機上操作起來並不直覺。

第三，照片、網址與備註不容易整合。

看房時常常會拍照，也會有一些現場才知道的感受，例如「窗外視野不錯」、「路邊車流聲明顯」、「公設看起來普通」、「格局比照片看起來小」。

這些資訊如果沒有整理在同一個地方，後面比較時就會很麻煩。

所以我開始覺得，與其一直用 Excel 將就，不如直接做一款符合自己流程的 App。

把需求轉成 App

看房筆記的核心想法很簡單：

讓使用者可以把看房過程中的物件資料、照片、評分與備註整理在一起，方便之後比較。

一開始我設定的方向不是要做成房仲平台，也不是要取代 591、永慶、信義或其他房屋網站。

它比較像是個人的看房整理工具。

也就是說，使用者還是可以在原本習慣的平台找房子，但看到有興趣的物件後，可以把資料整理進自己的筆記裡。

這樣一來，看房就不只是「看過就算了」，而是可以慢慢累積成自己的決策資料。

我希望它解決的問題

這款 App 最想解決的，不是找房，而是整理與比較。

所以我一開始規劃的重點包括：

• 建立買屋或租屋專案
• 新增不同物件
• 記錄物件基本資料
• 保存物件網址
• 加入現場看房筆記
• 記錄照片與觀察重點
• 設定評分
• 標記優點與缺點
• 加入風險標籤
• 整理公設清單
• 進行物件比較

這些功能看起來都不算特別炫技。

但對真的正在看房的人來說，這些反而是最實用的。

因為最後會影響決策的，往往不是單一資訊，而是許多細節加總起來的結果。

AI 協助整理資料的想法

這個專案比較特別的地方，是我也嘗試加入 AI 協助整理資料。

原本的想法是，使用者輸入物件網址後，可以透過 WebView 開啟頁面，擷取畫面中的文字，再讓 AI 協助整理成結構化欄位。

例如從頁面中整理出：

• 開價
• 坪數
• 格局
• 樓層
• 管理費
• 車位資訊
• 物件類型
• 地址或區域
• 買屋或租屋模式

這樣可以減少使用者手動輸入資料的時間。

不過這個功能也讓我重新思考一件事情：

AI 可以協助整理資訊，但不能亂猜資料。

尤其是房屋資訊牽涉到金額、坪數、管理費與屋況，如果 AI 自己補資料或判斷錯誤，反而會造成使用者誤解。

所以在設計這個功能時，我會要求 AI 盡量保守。

如果無法確認，就應該顯示空值或標記為低信心，而不是自己編一個看起來合理的答案。

看房資料不是越自動越好

做這個 App 的過程中，我也慢慢發現，看房筆記不適合完全自動化。

有些資料可以由 AI 協助整理，例如價格、坪數或格局。

但有些感受一定要靠自己記錄。

例如：

• 走進去的第一印象
• 房子的氣味
• 窗外噪音
• 鄰居與公共空間感受
• 採光是否舒服
• 格局動線是否順手
• 家人是否喜歡
• 自己有沒有想住在這裡的感覺

這些東西，AI 沒有辦法替你感受。

所以看房筆記的定位，不是讓 AI 幫你決定要不要買。

而是讓 AI 幫你減少整理資料的時間，讓你把更多注意力放在實際判斷上。

從買屋延伸到租屋

一開始我主要是從買房需求出發。

但後來想想，其實租屋也有類似問題。

租屋看起來決策成本比較低，但實際上也有很多需要比較的地方。

例如：

• 租金
• 押金
• 管理費
• 水電費計算方式
• 是否可開伙
• 是否可養寵物
• 是否有電梯
• 是否有對外窗
• 家具家電狀況
• 通勤時間
• 房東溝通感受

如果只是靠記憶比較，其實一樣很容易混亂。

所以後來我把看房筆記的方向調整成同時支援買屋與租屋。

使用者可以依照自己的需求建立不同專案，而不是只限制在買房。

Vibe Coding 在這個專案中的角色

這款 App 很適合使用 Vibe Coding 開發。

原因是它的需求來自真實使用情境，而且流程可以拆得很清楚。

例如：

1. 建立專案
2. 新增物件
3. 輸入物件網址
4. 建立筆記
5. 補充看房紀錄
6. 加入評分與標籤
7. 進行比較

每一個功能都可以拆成獨立階段慢慢完成。

這對 AI 協助開發來說很重要。

如果一次只做一個清楚的小功能，AI 的產出品質通常會穩定很多。

但如果一開始就要求它「幫我做一款完整的看房 App」，結果通常會變得很混亂。

這個專案也有合規問題要注意

看房筆記雖然不像網路電台那樣直接牽涉到串流授權，但仍然有自己的合規風險。

尤其是如果 App 會讀取房屋網站頁面、擷取文字、透過 AI 整理資訊，就必須注意資料來源與使用方式。

我不希望這款 App 變成大量抓取別人網站資料的工具。

所以它的定位應該是使用者個人整理筆記，而不是建立另一個房屋資料平台。

換句話說，這款 App 應該協助使用者整理自己正在看的物件，而不是替代原本的房屋網站。

這也是我後來在文案上會比較謹慎的地方。

與其說「自動抓取房屋資訊」，不如說「AI 協助整理目前畫面中的資訊，幫你快速建立看房筆記」。

這樣比較符合產品實際用途，也比較不容易讓人誤解成資料搬運或爬蟲服務。

資料儲存在使用者手機端

這款 App 另一個我很在意的地方，是資料儲存方式。

看房紀錄其實帶有不少個人決策資訊。

例如你正在考慮哪些區域、預算範圍、喜歡什麼類型的房子、看過哪些物件，以及對每一間的評價。

這些不一定是高度機密資料，但仍然屬於比較私人的使用紀錄。

因此，看房筆記的設計方向，是讓資料主要儲存在使用者自己的手機端。

使用者移除 App 後，資料也會跟著移除。

這樣雖然少了一些雲端同步的方便性，但對第一版來說，可以讓產品更單純，也比較符合個人筆記工具的定位。

從自己的需求做產品，比較容易知道重點在哪裡

用 Vibe Coding 做過幾款 App 之後，我越來越覺得，如果產品需求來自自己的生活，會比較容易做出第一版。

因為你自己就是使用者。

你會知道哪些功能是真的需要，哪些功能只是看起來很厲害。

你也會知道哪些操作流程很卡，哪些欄位其實沒有人想填。

看房筆記就是這樣的專案。

它不一定是最炫的 App，但它解決的是一個我自己真的遇到的問題。

這讓我在開發時更容易判斷功能優先順序。

結語

看房筆記對我來說，是一個很典型的 Vibe Coding 案例。

它不是從一個完整商業計畫開始，而是從生活中實際遇到的麻煩開始。

先是發現 Excel 整理不夠順手，接著思考能不能把流程 App 化，再透過 AI 協助規劃、拆解與開發。

AI 在這個過程中扮演的角色，不是替我決定產品方向。

而是幫我把已經想清楚的需求，更快轉成可以測試的產品。

這也是我目前對 Vibe Coding 最深的感受之一。

AI 可以加快開發速度，但真正有價值的產品，通常還是來自真實需求。

如果這個需求剛好是自己正在面對的問題，那就更適合拿來做成第一版。

因為你不只是開發者，也是第一個使用者。

看房筆記：Googoe Play下載 | AppStore下載

兔耳絲網路電台，就是其中一個很特別的案例。

這個 App 從技術角度來看，其實並不是做不出來。

相反地，在 AI 協助之下，從功能規劃、畫面設計、串流播放、收藏電台、最近播放、搜尋分類，到 Google Play 與 App Store 的上架素材，整個開發流程都算是相當順利。

但最後我還是選擇沒有正式上架。

原因不是技術問題，而是：

m3u8 直播串流的授權問題。

一開始只是想做一款簡單的網路電台 App

兔耳絲網路電台最初的想法很單純。

我希望做一款可以快速收聽網路電台的 App，讓使用者可以依照地區、分類或名稱找到想聽的電台。

功能大致包含：

• 電台列表
• 搜尋功能
• 分類瀏覽
• 收藏電台
• 最近播放
• 推薦電台
• 迷你播放器
• 睡眠計時
• 主題色與顯示模式

這類 App 在功能上並不算複雜，重點主要在資料整理、播放穩定度與操作體驗。

透過 AI 協助，很快就能規劃出 App 架構，也能逐步完成 Flutter 端的播放功能與 UI。

如果單純從「能不能做出來」來看，答案是可以。

但問題是，App 能做出來，不代表可以放心上架。

Vibe Coding 很快，但法律問題不會因為 AI 而消失

使用 AI 開發時，很容易產生一種錯覺：

只要 AI 能幫我做出功能，這個產品就離上架不遠了。

但兔耳絲網路電台讓我發現，真正麻煩的地方不一定在程式碼。

網路電台 App 最大的問題，是直播串流來源。

很多電台都可以在網站上收聽，也可能可以透過瀏覽器或技術方式找到 m3u8 串流網址。

但是，能在網站上播放，不代表第三方 App 就可以直接拿來使用。

這中間牽涉到很多問題：

• 直播串流是否允許第三方 App 使用？
• 電台是否授權其他平台轉播？
• App 是否會造成使用者誤以為與電台官方合作？
• 電台 Logo、名稱與節目資訊是否可以使用？
• App 是否涉及內容重製、公開傳輸或再利用？
• 如果 App 內有廣告或商業用途，授權條件是否不同？

這些問題，不是 AI 幫忙寫完播放器就能解決的。

甚至可以說，AI 把技術門檻降低之後，反而讓這些法律與授權問題變得更重要。

技術上可行，不等於法律上可行

這是我在這個專案中最大的體會。

過去開發 App 時，我比較常思考的是：

• 功能能不能做？
• 畫面好不好用？
• App 會不會閃退？
• Google Play 或 App Store 能不能通過審核？

但兔耳絲網路電台讓我多了一個更前面的問題：

這個內容，我到底有沒有權利使用？

在 AI 時代，開發速度變快，取得資料與整理資料也變容易。

以前可能需要花很多時間研究的功能，現在透過 AI 幾天內就能完成初版。

但也因為如此，開發者更容易在沒有完全理解授權邊界的情況下，把產品做出來。

尤其是牽涉到音樂、廣播、影片、圖片、文章、新聞、地圖資料或第三方資料來源時，都不能只看「技術上能不能抓到」。

更重要的是：

對方是否允許你這樣使用？

App Store 審核只是第一關，不是法律保證

很多人可能會想，如果 App 能通過 Google Play 或 App Store 審核，是不是就代表沒有問題？

我認為不能這樣理解。

平台審核可以擋下一部分明顯違規或高風險的 App，但平台審核不等於法律授權。

就算 App 上架成功，也不代表內容來源一定沒有版權問題。

如果未來權利人提出異議，仍然可能面臨下架、警告、帳號風險，甚至法律責任。

所以對我來說，與其抱著僥倖心態先上架再說，不如在授權沒有釐清前，先不要正式推出。

這也是兔耳絲網路電台最後沒有上架的主要原因。

AI 時代，版權問題會更常發生

AI 讓個人開發者的能力被放大。

以前需要多人團隊才能完成的事情，現在一個人搭配 AI，也許就能做出原型，甚至完成可上架的產品。

這是一件很令人興奮的事。

但同時，也代表開發者更容易接觸到原本需要專業判斷的問題。

例如：

• 使用公開網站資料是否可以？
• 使用對方網站圖片是否可以？
• 使用串流網址是否可以？
• 使用他人商標或 Logo 是否可以？
• AI 產生的圖片能不能商用？
• AI 生成內容是否可能太接近既有作品？
• 整理第三方資料後提供給使用者，是否涉及資料再利用？

這些問題在以前就存在。

只是過去技術門檻比較高，很多人還沒做到產品階段，就已經卡在開發過程。

現在 AI 把開發速度推快之後，法律、授權與內容來源反而會更早浮現。

也因此，我覺得未來使用 Vibe Coding 開發產品時，不能只問 AI：

「這個功能怎麼做？」

還要多問自己：

「這個功能使用到的資料、內容或服務，我有沒有權利使用？」

開發者不能只相信 AI 的回答

在開發過程中，也可以問 AI 法律或版權相關問題。

但我認為，這只能當作初步參考，不能當成最終答案。

因為 AI 可能會根據一般情況給出看似合理的說法，但實際法律問題往往取決於：

• 所在地區法律
• 平台規範
• 權利人的授權條款
• 實際使用方式
• 是否營利
• 是否造成混淆
• 是否涉及內容再傳播

尤其是授權問題，最終還是要回到權利人或官方條款。

如果條款沒有寫清楚，或使用方式可能超出一般網站瀏覽範圍，就應該更加保守。

AI 可以協助整理問題、撰寫授權信、分析風險，但不能替開發者承擔法律責任。

真正要負責的人，還是開發者自己。

兔耳絲網路電台帶給我的提醒

這個專案雖然最後沒有正式上架，但它不是一個失敗的專案。

相反地，它讓我更清楚理解一件事：

Vibe Coding 的限制，不只在程式能力，也在產品能不能被合法使用。

技術可以快速完成，但授權需要時間確認。

功能可以靠 AI 生成，但責任不能交給 AI 承擔。

App 可以被做出來，但不代表它就適合公開上架。

這也是我後來在其他專案中會更加注意的地方。

例如使用圖片、第三方資料、網站內容、AI 生成素材、地圖資訊或任何外部來源時，都會先想一層：

這個東西是不是我可以使用的？

以後如果要重啟這個專案

如果未來要重新啟動兔耳絲網路電台，我認為比較安全的方向會是先處理授權。

可能的方式包括：

• 向電台官方申請串流授權
• 只收錄明確允許第三方使用的電台來源
• 改成導向官方網站收聽，而不是在 App 內直接播放
• 避免使用未授權 Logo 與節目資訊
• 建立清楚的資料來源與下架聯絡機制
• 在 App 內標示非官方 App，避免使用者混淆

這些做法不一定能完全解決所有問題，但至少可以讓產品方向更穩健。

對個人開發者來說，做得出來很重要，但能不能長期安全地運作更重要。

結語

兔耳絲網路電台讓我學到一個很現實的課題。

AI 讓開發速度變快，讓一個人可以完成更多過去很難完成的作品。

但也因為開發變快了，我們更不能忽略產品背後的法律與版權問題。

在 Vibe Coding 的過程中，最容易被看到的是速度。

幾天完成原型、幾週完成 App、快速產出圖片與上架素材，這些都很有成就感。

但真正能不能把產品公開推出，不只取決於程式碼。

還取決於內容來源、授權條件、平台規範，以及開發者是否願意在法律風險前停下來。

這次我選擇不上架兔耳絲網路電台。

不是因為做不出來，而是因為我還沒有足夠把握，確認所有直播串流都有可以被第三方 App 使用的授權基礎。

對我來說，這也是 Vibe Coding 很重要的一課：

AI 可以幫你把產品做出來，但不能替你確認產品是否真的可以合法上線。

當時應該還沒有「Vibe Coding」這個說法，但實際上的做法已經很接近：先用文字說明需求，讓 AI 協助規劃與撰寫程式，再由自己進行測試、驗收與修正。

過去一年多，我在 Web 前後端開發上已經大量採用這種模式。

到了去年九月，我開始嘗試把相同的方法用在 Flutter App 開發。

半年過去，陸續完成了幾款工具 App、休閒遊戲、網站與後端服務，也曾經挑戰過超出自己能力範圍的遊戲專案。

有些作品大約一週就能完成並上架，也有專案投入兩個月後，最後還是選擇暫停。

這篇文章不是要討論 AI 能不能取代工程師，而是單純記錄我實際使用 Vibe Coding 開發 App 半年之後，對這種開發方式的理解。

從一款類似 2048 的小遊戲開始

我第一款使用 Flutter 製作的遊戲，是一款玩法類似 2048 的休閒遊戲。

由於規則不算複雜，主要就是處理方塊移動、數值合併、分數計算與基本畫面呈現。

在 AI 協助之下，從建立專案、完成主要功能、調整畫面，到最後上架 Google Play，大約花了一週左右。

這次經驗讓我產生了一個有點危險的錯覺：

既然簡單的遊戲可以完成，那麼複雜一點的遊戲，應該也只是多花一點時間而已吧？

後來證明，事情完全沒有這麼簡單。

剛走出新手村，就直接挑戰魔王

接下來，我開始規劃一款單機大富翁玩法的生存遊戲。

玩家可以擲骰子、在地圖上移動、觸發事件，也能加入多人聊天等功能。

一開始看起來，只要把每個功能拆開，逐步交給 AI 開發，似乎就有機會完成。

但真正開始製作後，我才發現遊戲開發和一般工具 App 完全不同。

除了功能本身，還需要處理：

• 遊戲狀態管理
• 角色移動與地圖系統
• 畫面更新與動畫
• 事件觸發邏輯
• 操作手感
• 效能與裝置適配
• 遊戲 UI
• 美術資源
• 整體遊戲節奏

Unity、Cocos Creator 或其他遊戲框架，也各自有一套需要理解的觀念。

後來我嘗試使用 Flutter 搭配 Flame 繼續製作，每天晚上花時間調整功能、修正錯誤與重新規劃。

大約持續兩個月之後，我決定先把專案停下來。

這次經驗讓我理解一件很重要的事：

AI 可以協助你寫程式，但不會自動補上你缺少的領域經驗。

如果連自己都還不清楚遊戲架構應該怎麼設計、哪些功能應該優先處理，AI 只會更快地幫你製造出一堆需要重構的程式碼。

自己重新造輪子，真的很可怕。

後來改成先做小型 App

遊戲專案暫停之後，我重新調整了開發方向。

與其一開始就挑戰龐大的系統，不如先從需求清楚、功能單純的小工具開始。

這些 App 不一定很複雜，但每一款都可以讓我熟悉不同問題：

• Flutter 的畫面與狀態管理
• Android 與 iOS 的差異
• 多語系處理
• 內購與廣告
• 通知提醒
• 資料儲存
• API 串接
• Google Play 與 App Store 上架流程

我也逐漸建立出比較適合自己的開發方式。

我現在使用的 Vibe Coding 流程

目前我不太會直接叫 AI「幫我做一款 App」。

比較常用的方式是把專案拆成幾個階段。

第一步：先確認 App 要解決什麼問題

我會先整理最基本的需求：

• 這款 App 是給誰使用？
• 它要解決什麼問題？
• 最重要的功能是什麼？
• 哪些功能可以晚一點再做？
• 第一個版本做到什麼程度就可以上架？

這個階段很重要。

因為如果自己沒有想清楚，AI 也只會根據模糊的描述，做出一個看起來功能很多，但實際上很難使用的版本。

第二步：先整理文件，再開始寫程式

確定方向後，我會先使用 ChatGPT 整理功能文件與開發順序。

接著再把文件交給 GitHub Copilot 或其他程式工具，讓 AI 先理解專案背景，再逐步進行開發。

比起每次臨時輸入一句指令，先準備一份相對完整的需求文件，通常會穩定很多。

第三步：拆成小功能，逐步完成

我不會一次要求 AI 完成整個專案。

通常會拆成：

1. 建立基礎專案架構
2. 完成主要畫面
3. 加入核心功能
4. 處理資料儲存
5. 加入次要功能
6. 進行錯誤修正
7. 準備上架

一次處理一個階段，比較容易知道問題出在哪裡。

如果一次改太多東西，最後很容易連 AI 自己都不知道是哪個步驟造成錯誤。

第四步：每個階段都自己測試

這是我目前最重視的部分。

AI 很常會告訴你：

「功能已經完成。」

但實際測試之後，可能會發現：

• 正常流程可以使用，但特殊情境會出錯
• 畫面看起來正常，但資料沒有正確儲存
• Android 可以執行，但 iOS 出現問題
• 舊資料升級後無法讀取
• 按鈕可以點擊，但操作流程不符合直覺

所以，即使 AI 已經寫完程式，我還是會自己逐一測試。

簡單來說，就是因為我信不過 AI。XD

目前使用的 AI 工具

ChatGPT 付費版

ChatGPT 主要用來處理前期規劃、需求討論、文件整理、問題分析，以及圖片素材。

我也會使用它製作 App 內的圖片，以及 Google Play、App Store 上架時需要的視覺素材。

VS Code + GitHub Copilot 付費版

實際撰寫程式時，我主要使用 VS Code 搭配 GitHub Copilot。

一開始使用每月 20 美元的方案，後來升級到每月 39 美元的方案。

通常會先讓 Copilot 讀取文件與現有程式碼，再透過多輪對話逐步完成各項功能。

Gemini 付費版

Gemini 主要作為備用工具。

當 ChatGPT 的回答不夠理想，或是希望比較不同模型的處理方式時，我會改用 Gemini 測試。

另外，有些圖片素材也會使用 Gemini 產出。

Codex 桌面版

今年四月開始，我也加入 Codex 桌面版作為開發工具。

目前部分規劃、程式修改與問題排查，會直接交給 Codex 處理。

Claude 桌面版

今年三月曾經試用 Claude 桌面版。

整體品質不錯，但額度消耗速度比較快，因此目前沒有作為主要工具。

近半年完成了哪些作品？

近半年製作的作品，大多使用 Flutter 開發，並以支援 Android 與 iOS 雙平台為目標。

目前包含：

Clockwise：世界時鐘與會議時間

支援中文、英文、日文與韓文。

除了世界時鐘，也可以自訂時鐘顯示方式、調整時鐘速度，並比較多個地區的時間，方便安排跨時區會議。

MeetWhen

將跨時區會議安排功能獨立出來，製作成更單純的工具 App。

中國象棋

支援中文與英文。

目前包含電腦對戰、雙人對弈、暗棋，以及不同難易度的殘局挑戰。

吸血鬼怕怕

這是最早完成的類 2048 休閒遊戲，也是我開始使用 Flutter 製作 App 的起點。

兔耳絲日常工具屋

支援中文、英文與日文，包含網站版與 App 版。

裡面收錄許多生活中可能會用到的小工具，例如今天吃什麼、誰去倒垃圾、今天誰洗碗、今天穿什麼，以及一些簡單的日常抽選功能。

網站版採用 Next.js，App 版則採用 Flutter。

雖然兩邊的功能類似，但因為技術架構不同，仍然需要分別重新實作。

CycleNote：喝水與提醒紀錄

支援中文、英文與日文。

這款 App 主要用來記錄喝水、定期事項，以及生活用品的更換與到期提醒。

Rootrees：家族樹與族譜紀錄

Rootrees 是目前規模較完整的一款 App。

它不只是手機 App，還包含後端 API、雲端資料同步與行銷網站。

這個專案也讓我遇到不少問題，尤其是家族關係、樹狀圖排列與 PDF 匯出。

由於先前已經另外寫過一篇完整的開發紀錄，這裡就不再重複介紹。

有興趣可以參考：

Rootrees：我把家裡的舊族譜，做成一款家族樹 App

ABCB Studio

ABCB Studio 是目前用來整理與介紹這些作品的網站：

https://abcbstudio.cc/

網站一開始使用 WordPress 製作，後來重新規劃成 Next.js 版本，並部署在 Vercel。

從重新規劃到可以正常運作，大約花了半天時間。

這類需求清楚、架構相對單純的網站，也是 Vibe Coding 很適合發揮的場景。

多語系與雙平台，比想像中花時間

完成 App 的主要功能之後，才會發現還有很多細節需要處理。

例如多語系。

一款 App 支援中文、英文與日文，不只是把文字丟給 AI 翻譯就結束。

還需要確認：

• 翻譯是否符合當地常用說法
• 不同語言的文字長度是否影響排版
• 按鈕與畫面是否會超出範圍
• App Store 與 Google Play 的介紹文案是否自然

雙平台也有類似問題。

Flutter 可以讓 Android 與 iOS 共用大量程式碼，但不代表完成 Android 版本後，iOS 就能直接上架。

實際上，兩個平台的權限、登入方式、通知、內購、廣告與審核規範，都有不同的細節。

功能做完，只是第一步。

真正要讓 App 順利上架，還是需要逐項處理。

Vibe Coding 最重要的能力，不只是下 Prompt

使用 AI 開發一段時間後，我認為最重要的能力不是背誦多少 Prompt，也不是一次輸入多完整的指令。

真正重要的是：

• 能不能把需求拆解清楚
• 能不能判斷 AI 的解法是否合理
• 能不能發現目前的架構已經開始失控
• 能不能知道哪些功能應該先做
• 能不能在錯誤方向投入太多時間之前，及時停下來

有時候，AI 產出的程式可以正常執行，但架構並不好。

有時候，問題並不是程式碼寫錯，而是一開始的產品設計就不合理。

也有些時候，最好的選擇不是繼續叫 AI 修改，而是回到前一步，重新思考需求。

目前的上架狀況

目前 Google Play 上仍有七款 App：

Google Play 開發者頁面

iOS 設備是在今年五月取得，目前已經有五款 App 上架：

App Store 開發者頁面

另外還有 App 正在送審，其他作品也會陸續處理 iOS 上架準備。

結語

回頭看這半年的開發過程，Vibe Coding 最大的價值，不是讓開發變成一件完全不用思考的事情。

它真正改變的，是驗證想法的成本。

以前想到一個 App，可能會因為時間、人力或技術問題，最後只停留在想法階段。

現在則可以先快速做出第一個版本，實際測試，再決定值不值得繼續投入。

但 AI 寫程式的速度越快，越需要知道自己要往哪裡走。

否則，很可能只是用更快的速度，製造更多需要修正的程式碼。

AI 可以幫忙寫程式。

但產品方向、需求拆解、測試驗收與最後的判斷，仍然需要自己負責。

不是功能做不出來，也不是技術卡住。

而是突然不知道下一個要做什麼。

前面幾個專案都有比較明確的原因。

CycleNote 是因為我常常忘記喝水、吃藥，也需要記錄一些定期更換的生活用品。

Rootrees 是因為家裡有早期留下來的族譜資料，想要做一個方便整理與匯出的家族樹 App。

中國象棋則是想嘗試切入休閒遊戲，從規則比較完整、容易理解的棋類遊戲開始。

但當這些專案陸續完成之後，我反而有一小段時間失去了目標。

加上白天工作已經長時間坐在電腦前面，回家之後偶爾也會想放鬆一下。打打遊戲、看看劇，其實也不錯。

於是，我決定先不要想得太複雜。

如果暫時沒有一個很大的產品題目，那就先做一些日常生活中可能會用到的小工具。

兔耳絲工具屋就是這樣開始的。

一開始其實只是網站版本

兔耳絲工具屋最早不是 App，而是一個網站：

https://rabbitears.cc/

我想做一個簡單的生活小工具集合，讓使用者不需要登入，也不需要花時間研究操作方式，打開之後就可以直接使用。

有些工具只是幫忙做一個小決定，有些則是提供一點生活中的小樂趣。

它不是一個要解決重大問題的平台，也不是功能非常複雜的系統。

比較像是一個隨手可以打開的生活工具箱。

為什麼叫做兔耳絲工具屋？

一開始，我就不想讓它看起來像一個冷冰冰的工具網站。

很多工具類產品會使用比較正式的名稱與介面，但這個專案本來就不是為了工作效率，而是希望讓生活多一點輕鬆感。

因此，我幫它設計了一個兔耳角色。

當你不知道今天要吃什麼、想抽一個幸運數字，或只是需要有人幫忙做個決定時，就可以打開兔耳絲工具屋，看看兔耳絲會給你什麼答案。

這個角色也逐漸成為整個工具屋的核心。

工具本身可以持續增加，但整體風格仍然維持可愛、簡單，而且不需要學習成本。

工具屋裡面有哪些功能？

兔耳絲工具屋目前收錄的功能，主要都來自一些生活中常見的小問題。

例如：

• 今天吃什麼
• 飲料喝什麼
• 幫我決定
• 每日語錄
• 心情占卜
• 是或否
• 幸運物
• 幸運數字與幸運顏色
• 記分板
• 家事分配
• 今日穿搭
• 出遊點子

有些功能偏實用，有些比較偏娛樂。

但共同點都是：不需要複雜設定，打開之後幾秒內就可以得到結果。

「今天吃什麼」可能是最常見的生活難題

其中最實用的功能之一，就是「今天吃什麼」。

很多時候不是完全沒有想法，而是選項太多，最後反而不知道要吃什麼。

尤其到了中午或晚上，大家討論了半天，常常還是會回到同一句話：

「都可以。」

這時候，與其繼續陷入選擇困難，不如直接交給工具隨機決定。

使用者可以依照用餐時段與料理風格，快速抽出一個建議。

它不一定會給出最完美的答案，但至少可以讓你少花一點時間糾結。

有些工具的作用，是讓生活多一點趣味

除了比較實用的功能之外，工具屋裡也有一些比較輕鬆的內容。

例如每日語錄、心情占卜、幸運數字、幸運顏色與今日穿搭。

這些功能不需要太認真看待。

有時候只是早上打開手機，隨手抽一個結果，替一天增加一點小小的儀式感。

我覺得生活工具不一定都要提升效率。

偶爾讓人覺得有趣、可愛，或提供一個小小的驚喜，也是一種價值。

某一天，我突然覺得它也應該有 App

網站版本完成之後，原本我沒有立刻打算做成 App。

畢竟這些功能透過瀏覽器就可以使用。

但某一天，我突然覺得：既然這些都是生活中偶爾會打開的小工具，那它其實很適合直接放在手機裡。

網站需要先打開瀏覽器、輸入網址或找到書籤。

App 則只要點一下圖示就能開啟。

這個差距看起來不大，但對於這種使用頻率不固定、每次只操作幾秒鐘的小工具來說，開啟速度與方便性很重要。

於是，我又把兔耳絲工具屋做成了 App 版本。

網站和 App 並不是完全相同的產品

把網站轉成 App，不代表只要把原本的畫面直接搬進去就完成了。

手機使用者的操作方式不同，畫面空間也比較有限。

因此，App 版本需要重新調整介面，讓每個功能更容易找到，按鈕更適合手機操作，整體畫面也要保持簡單。

另外，網站可以透過連結快速分享，但 App 則更適合日常重複使用。

兩者的功能方向相似，但使用情境不完全一樣。

網站適合第一次接觸與快速體驗，App 則比較像是放在手機裡的一個小工具箱。

這是一個可以慢慢增加內容的專案

和其他專案相比，兔耳絲工具屋沒有一開始就設定非常明確的終點。

它比較像是一個可以持續擴充的容器。

只要想到一個有趣、簡單，而且適合快速使用的小工具，就可以考慮加入。

不需要每次都做一個全新的 App，也不需要為了一個小功能重新建立完整產品。

這種開發方式也讓整個過程比較輕鬆。

有些點子未必適合成為大型專案，但放進工具屋裡，反而剛剛好。

不是每一個作品，都需要有很大的野心

兔耳絲工具屋可能不是我功能最複雜的作品。

它沒有龐大的資料結構，也沒有非常困難的技術挑戰。

但它讓我重新思考了一件事。

做產品不一定每次都要解決很大的問題，也不一定要先想出一個完整的商業模式。

有時候，只是做一個自己覺得有趣、使用者也可能會喜歡的小東西，就已經足夠。

尤其是在 AI 協助開發的過程中，很多過去可能覺得不值得花時間製作的小工具，現在都更有機會被實現。

當開發成本下降之後，產品不一定只能追求功能更多、更複雜。

也可以更輕、更快，甚至更有趣。

支援多語系，比想像中更花時間

兔耳絲工具屋的網站與 App 版本，目前都支援繁體中文、英文與日文。

一開始，我原本以為多語系主要就是把畫面上的文字翻譯完成。

但真正開始處理之後，才發現事情沒有那麼簡單。

每新增一個工具，不只是要把功能做出來，還要重新整理所有會顯示給使用者看的內容。

按鈕文字、標題、說明、抽選結果、提示訊息，甚至一些比較輕鬆的語句，都需要分別處理三種語言。

這也代表，原本只要完成一次的內容，加入多語系之後，往往需要多花一倍以上的時間確認。

而且，翻譯完成不代表真的適合使用。

現在 AI 翻譯已經很方便，可以快速產出英文與日文版本。

但我其實很難百分之百確定，翻譯結果是不是符合當地使用者平常會使用的說法。

尤其兔耳絲工具屋裡面有不少比較生活化、比較輕鬆，甚至帶一點可愛語氣的內容。

這些文字如果只是逐字翻譯，文法可能沒有問題，但讀起來還是可能有點生硬。

例如「今天吃什麼」、「幫我決定」或一些抽選結果，在不同語言裡，最自然的表達方式未必完全相同。

有些句子在中文裡看起來很可愛，翻成英文或日文之後，可能會變得太正式，或失去原本的語氣。

這也是多語系產品很現實的一個問題。

AI 可以協助加快翻譯速度，但它不一定能完全取代當地語感。

如果希望產品不只是「看得懂」，而是真的讓不同語言的使用者覺得自然，後續還是需要持續調整。

對一個人開發的專案來說，多語系會明顯增加維護成本，但如果希望讓更多人可以直接使用，這又是一個值得投入的方向。

App 版本不是把網站直接包起來

兔耳絲工具屋的網站版本採用 Next.js 開發，App 版本則是使用 Flutter。

兩邊使用的是不同技術架構，也不是同一套程式碼。

因此，把網站做成 App，並不是將原本的網頁直接包進手機裡，也不是把畫面複製過去就完成。

很多功能都必須重新實作。

例如轉盤抽獎功能，在網站版本裡，需要依照瀏覽器環境處理畫面顯示、動畫效果與使用者操作。

到了 Flutter App 裡，則需要使用不同的方式重新製作轉盤、動畫與互動邏輯。

畫面看起來可能很接近，但背後其實是兩套不同的實作。

除了轉盤之外，按鈕操作、畫面切換、版面配置與手機尺寸適配，也都需要重新調整。

這也是我在開發 App 版本之後更明顯感受到的事情：

網站與 App 可以共用產品概念，但不一定能直接共用程式碼。

如果只是把網站硬塞進 App 裡，開發速度可能比較快，但操作體驗通常也會比較像網頁。

我希望 App 版本仍然有比較適合手機的操作方式，因此最後還是選擇用 Flutter 重新製作。

當不知道下一個要做什麼時，就先做點好玩的

兔耳絲工具屋的誕生，其實沒有什麼非常偉大的故事。

單純就是在完成幾個專案之後，我突然不知道下一個要做什麼。

既然如此，那就先做一個生活小工具集合。

從網站開始，後來再延伸成 App。

它可能會慢慢增加更多功能，也可能會隨著新的想法持續調整。

但這也正是這個專案有趣的地方。

它沒有太多限制。

只要生活中又出現一個讓人猶豫、想抽籤，或需要一點靈感的小問題，兔耳絲工具屋就還有繼續擴充的空間。

想要體驗一下這款多樣性的工具，可以從雙平台下載或者從網站直接使用。

雙平台下載：AppStore | Google Play | 兔耳絲工具屋網站

這個想法不是突然出現的，而是來自一個很實際的需求：我手上有家裡族譜的電子檔。

其中很多資料，是早期手寫族譜拍照後留下來的數位檔案。雖然資料有被保存下來，但閱讀、整理與分享都不算方便。

以前我曾經嘗試用 Photoshop 重新整理。

但家族成員一多，整張圖就會變得非常龐大。畫面需要不斷往左右延伸，修改關係也很麻煩。如果想輸出成紙本，還會遇到尺寸與排版問題。

這個想法一直放在心裡，只是遲遲沒有真正開始執行。

直到今年四月，我才正式把需求拿出來，開始和 ChatGPT 討論：能不能做一款可以在手機和平板上建立家族資料，並且匯出 PDF 的家族樹 App？

這就是 Rootrees 的起點。

我真正需要的，不只是一張家族樹圖片

一開始看起來，需求似乎很簡單。

只要讓使用者可以新增家族成員、設定彼此關係，然後產生家族樹狀圖就好了。

但仔細思考之後，就會發現真正需要的功能比想像中更多。

家族資料不只是姓名而已，還可能包含：

• 出生日期與離世日期
• 性別
• 照片
• 備註與生平資料
• 配偶關係
• 父母與子女關係
• 不同世代之間的排列方式

除了在 App 裡查看，我也希望資料可以匯出。

而且 PDF 不能只有一種形式。

有些時候，需要的是方便閱讀與保存的文字版本；有些時候，則需要可以一眼看出家族關係的樹狀版本。

因此，Rootrees 的 PDF 匯出功能分成兩種方向：

• 家族成員資料的文字版 PDF
• 呈現世代與親屬關係的家族樹狀 PDF

這兩種格式用途不同，也各自有不同的排版挑戰。

從規劃到上架，大約花了一個月

Rootrees 的開發時程大致如下：

• 四月第一週：開始整理需求與規劃產品方向
• 4 月 7 日：正式建立專案並進入開發
• 4 月底：完成主要功能與測試
• 5 月 7 日：上架 Google Play，正式對外開放下載

從開始建立專案到正式上架，大約是一個月。

如果只看時間，可能會覺得開發速度很快。

但這一個月並不是單純把功能列出來，然後交給 AI 自動完成。實際過程中，仍然需要不斷確認需求、測試功能、修正資料關係，並且處理許多原本沒有預想到的問題。

Rootrees 不只是一個 App

Rootrees 比較特別的地方，是它不是單一專案，而是由三個部分組成。

A. Web：行銷網站

Rootrees 有一個獨立的官方網站：

https://rootrees.app/

網站主要用來介紹產品功能、提供下載資訊，以及放置隱私權政策等相關內容。

目前網站使用 Vercel 架設。

B. Backend：後端服務

後端主要負責提供 API 給 App 使用，採用Digitalocean做為後端服務商。

使用者建立的家族成員資料、人物關係與相關內容，都需要透過後端進行儲存與同步。

這也表示 Rootrees 不只是一款單機工具，而是一個需要處理資料結構、帳號與雲端同步的完整服務。

C. App：雙平台應用程式

Rootrees 支援中文與英文，也同時支援 Android 與 iOS。

使用者可以在手機或平板上建立家族資料、整理人物關係、查看家族樹，並且匯出 PDF 檔案。

整體開發順序是：

Backend → App → Web

我先把後端資料結構與 API 建立起來，再進入 App 功能開發。等主要流程完成後，才補上行銷網站。

最大的挑戰，是需求和 AI 理解之間的落差

Rootrees 是我目前在 Vibe Coding 過程中，遇到最多問題的一個專案。

最大的挑戰不是單純的「程式能不能寫出來」，而是：

我腦中想要的功能，和 AI 理解到的功能，常常會有落差。

有些功能用文字描述看起來很清楚，但實際做出來後，才會發現彼此理解的畫面完全不同。

尤其是畫面流程、資料結構、人物關係與 PDF 輸出格式，不能只用一句話簡單帶過。

很多時候，必須搭配範例、使用情境，甚至像分鏡一樣，把每一個步驟說清楚，AI 才比較有機會理解真正的需求。

「PDF 顯示錯了」不是一個足夠清楚的需求

家族樹狀 PDF 是整個專案裡比較複雜的功能之一。

在 App 裡顯示的家族樹，和匯出成 PDF 後的結果，並不是完全相同的事情。

App 畫面可以讓使用者縮放、拖曳，也可以依照螢幕大小即時調整。

但 PDF 是固定尺寸的文件。

當家族成員數量增加，或某一代的兄弟姊妹、配偶與子女比較多時，就可能出現排列擁擠、節點重疊或頁面過大的問題。

遇到這種情況，不能只對 AI 說：

「PDF 顯示錯了，請幫我修正。」

因為問題可能來自很多不同地方：

• 家族成員的資料排序
• 父母、配偶與子女的關係判斷
• 不同世代的層級位置
• 兄弟姊妹之間的排列方式
• 配偶節點是否占用額外空間
• 樹狀圖節點之間的間距
• PDF 頁面尺寸與輸出方向
• 內容超出頁面時如何縮放

必須先把問題拆開，確認可能出錯的環節，再針對不同方案和 AI 討論。

有時候需要調整節點位置，有時候需要修改資料排序，有時候則必須重新思考 PDF 的輸出方式。

通常不會只靠一次對話就得到最適合的答案，而是需要經過多輪測試與修正。

表達需求，本身就是 Vibe Coding 的重要能力

開發 Rootrees 之後，我更明顯感受到一件事：

使用 AI 寫程式，並不代表只要會下指令就夠了。

真正重要的是，能不能把需求說清楚。

如果自己也沒有想清楚流程、資料關係與使用情境，AI 很容易做出一個「表面上可以執行」，但實際上不符合需求的版本。

尤其是比較複雜的產品，不能只用一句話要求 AI 完成整套功能。

比較有效的方式是：

• 先拆分功能
• 說明使用情境
• 提供具體範例
• 指出目前畫面與預期結果的差異
• 分析可能出錯的位置
• 設計幾種不同解法
• 逐步測試與修正

AI 可以協助產生程式碼，也可以協助討論方案。

但產品設計、需求拆解與結果判斷，仍然需要自己負責。

從家裡的舊族譜，變成可以持續使用的工具

Rootrees 最初只是來自一個很單純的問題：

家裡留下來的族譜資料，有沒有更方便的整理方式？

從早期手寫資料的照片，到 Photoshop 裡龐大的族譜圖片，再到可以在手機與平板上建立資料、整理關係、匯出 PDF 的 App，整個過程其實就是把一個生活中的需求，逐步轉換成產品。

目前 Rootrees 已經支援中文與英文，並且陸續上架 Android 與 iOS 平台。

它還有很多可以持續改善的地方，但對我來說，這個專案已經不只是一次技術練習。

它也是目前最能代表我使用 AI 協助開發產品的一次經驗。

AI 的確讓一個人可以更快完成過去需要多人合作的工作。

但越深入做下去，就越會發現：真正決定產品品質的，仍然是你有沒有辦法把問題想清楚。

如果想要試試這個族譜App，歡迎下載。雙平台下載：AppStore | Google Play

不過，我也一直想嘗試另一個方向：休閒遊戲。

相比功能型 App，遊戲有不同的挑戰。除了功能可以正常運作，還要考慮玩家會不會願意持續使用、操作是否直覺，以及同一套規則可以延伸出哪些玩法。

最後，我選擇從中國象棋開始。

為什麼選擇中國象棋？

中國象棋是一款大家相對熟悉的棋類遊戲。

它的規則完整，也已經累積了長時間的玩法基礎。對第一次嘗試開發休閒遊戲的人來說，比起從零開始設計一套新的遊戲規則，中國象棋是一個比較容易切入的題目。

我不需要先花大量時間解釋遊戲世界觀、角色技能或複雜的戰鬥機制，而是可以先把重點放在遊戲流程、棋盤操作、畫面呈現與不同模式的設計。

但真正開始製作之後，我也慢慢發現：規則簡單，不代表開發過程沒有細節。

不只是和電腦下棋

一開始，我不希望這款 App 只有單一玩法。

有些玩家想要自己練習，有些人則是希望兩個人直接拿著同一台手機或平板對戰。也有人平常比較常玩暗棋，不一定想下完整的中國象棋。

因此，目前 App 內包含幾種不同模式：

• 電腦對戰
• 雙人象棋對戰
• 暗棋電腦對戰
• 雙人暗棋對戰

對我來說，這也是開發休閒遊戲很有趣的地方。

同一套棋子與棋盤，可以透過不同規則與操作方式，延伸出不一樣的遊戲體驗。

雙人對戰時，棋子方向也會影響體驗

如果只是自己對著手機下棋，所有棋子朝向同一個方向並沒有太大問題。

但雙人對戰就不一樣了。

當兩位玩家坐在手機或平板的兩側時，如果棋子的文字全部朝向同一邊，其中一位玩家就必須倒著看自己的棋子。

這不會影響規則，卻會讓遊戲體驗變得不自然。

因此，在雙人象棋模式中，我讓紅方與黑方的棋子依照各自角度翻轉。兩位玩家坐在對面時，都可以清楚看到自己的棋子，不需要一直轉動手機。

這是一個看起來很小的功能，但實際使用時差異很明顯。

很多 App 的細節，並不是功能能不能執行，而是使用者操作起來是否順手。

暗棋模式加入橫向畫面

暗棋的棋盤和完整象棋不同，棋子排列方式也不一樣。

如果在手機直向模式下顯示，棋盤寬度受到限制，棋子可能會縮得太小。雖然仍然可以操作，但閱讀與點擊都比較不方便。

因此，暗棋模式可以切換成橫向畫面。

橫向顯示之後，棋盤可以使用更完整的螢幕空間，棋子不需要過度縮小，操作起來也更舒服。

這也是我在開發過程中逐漸注意到的事情：手機畫面空間有限，不能只是把桌上遊戲直接縮小塞進螢幕，而是要依照實際使用方式重新調整介面。

後續加入殘局挑戰

完成基本對戰功能之後，我開始思考：除了完整對局之外，還能不能提供更適合短時間遊玩的內容？

因此，後來的版本加入了殘局挑戰。

殘局的特色是局面已經進行到某個階段，玩家不需要從第一步開始慢慢下，而是直接面對一個特定情境，嘗試找出破解方式。

對玩家來說，殘局很適合利用零碎時間挑戰。即使只有幾分鐘，也可以開啟一個局面思考看看。

目前加入的殘局棋譜，主要整理自採用 MIT 授權的開源資源。

開源授權讓我可以在遵守授權條件的前提下，將這些棋譜整合進 App，再依照手機操作方式重新設計呈現流程。

挑戰過的殘局，可以隨時重新挑戰

在最新一次改版中，我又補上了殘局挑戰紀錄功能。

只要玩家進入某個殘局挑戰，系統就會自動留下紀錄。

這項功能不是等到成功破解之後才記錄，而是只要曾經進入挑戰，就可以在紀錄中找到它。

玩家之後可以隨時回頭重新挑戰，不需要再次從完整清單中慢慢尋找。

這對殘局玩法來說很重要，因為有些題目未必第一次就能解開。有時候隔一段時間再回來思考，反而會有不同的想法。

從象棋開始嘗試休閒遊戲

中國象棋 App 對我來說，是一次切入休閒遊戲開發的嘗試。

它不像大型 RPG 需要大量角色、美術與劇情內容，也不像完全原創的遊戲需要先驗證整套規則是否好玩。

但即使是一款大家熟悉的棋類遊戲，實際做起來仍然有不少值得思考的地方：

• 不同玩家需要哪些遊戲模式？
• 雙人共用同一台裝置時，棋子應該如何顯示？
• 直向與橫向畫面如何調整？
• 除了完整對局之外，還能加入哪些短時間玩法？
• 玩家如何快速回到曾經挑戰過的內容？

這些功能不一定很華麗，但每一個調整，都是讓遊戲更容易使用的一小步。

對我來說，開發 App 最有趣的地方，也正是在這裡。

一開始可能只是一個簡單的想法，但隨著自己實際使用、持續測試與更新，產品會逐漸長出更多細節。

雙平台下載：AppStore | Google Play

有時候忙著處理事情，一回過神才發現整個下午幾乎沒有喝水。需要固定吃的藥，也可能因為正在開會、寫程式，或只是單純分心，不小心就錯過時間。

除了每天重複發生的事情，生活中還有很多不會立刻造成問題，卻很容易被忽略的小事。

例如牙刷多久該換一次、濾芯什麼時候要更換、某些用品是不是已經用了太久，甚至一些每隔幾週或幾個月才需要處理一次的事情。

這些事情單獨看都不大，但累積起來，就很容易漏東漏西。

CycleNote 就是從這些日常問題開始的。

我需要的不是待辦清單，而是更簡單的提醒工具

市面上已經有很多行事曆、待辦清單與提醒 App，但我真正需要的功能其實沒有那麼複雜。

我不是想要管理大型專案，也不是要建立一套完整的時間管理系統。我只是希望有一個簡單的地方，可以記錄：

• 今天喝了多少水
• 藥是不是已經吃過了
• 某件事情上次是什麼時候完成的
• 下一次大概什麼時候需要再次提醒

很多生活習慣並不是「做完一次就結束」，而是需要持續循環。

喝水每天都要記得，藥可能一天要吃一次或數次，某些生活用品則是隔一段時間就需要更換。

因此，我想做的不是一張會愈來愈長的待辦清單，而是一個可以協助記錄生活週期的小工具。

為什麼叫做 CycleNote？

CycleNote 這個名稱來自兩個概念：Cycle 與 Note。

Cycle 代表生活中不斷重複的週期，Note 則代表簡單記錄。

我們每天的生活，其實充滿了各種循環：

• 每天固定要做的事情
• 每週需要整理或補充的用品
• 每月需要處理的生活事項
• 每隔一段時間需要更換的物品

有些事情很重要，卻不值得為它建立一套複雜流程。只要在適當的時間提醒一下，就已經很有幫助。

最先想到的功能：喝水與吃藥提醒

對我來說，第一個最實際的需求就是喝水。

整天坐在電腦前面工作，很容易進入專注狀態。有時候不是完全沒有喝水，而是喝得太少，直到晚上才發現今天幾乎沒怎麼補充水分。

另一個需求則是吃藥提醒。

手機鬧鐘當然也可以做到提醒，但一般鬧鐘只能告訴你時間到了。它不一定能讓你清楚知道，這次到底有沒有完成，或今天還剩下哪些紀錄。

我希望 CycleNote 不只是跳出通知，而是讓使用者可以快速確認與留下紀錄。

提醒只是第一步，真正有幫助的是減少「我剛剛到底有沒有做？」的疑問。

後來發現，可以記錄的事情比想像中更多

開始設計之後，我才發現生活中有很多事情都符合相同的邏輯。

例如：

• 牙刷定期更換
• 隱形眼鏡盒或生活用品汰換
• 飲水機、空氣清淨機或其他設備的濾芯更換
• 定期清潔與保養
• 需要週期性補充的用品

這些事情通常不會每天出現在腦中，但等到想起來的時候，往往已經拖了一段時間。

如果可以在完成時順手留下紀錄，再讓系統在適當的時間提醒下一次，就能省下不少記憶成本。

我想做的是降低生活中的記憶負擔

我們每天需要記住的事情已經很多了。

工作上的進度、臨時交辦、家庭事項、帳單、約定時間，還有各種零碎的小事，全部都擠在腦中。

CycleNote 的目標不是把生活變成一張需要每天仔細維護的表格，而是把一些容易忘記的事情交給手機。

需要做的時候提醒一下，完成之後記錄一下，就這麼簡單。

對我來說，工具的價值不一定來自功能很多。有時候，能夠確實解決一個每天都會遇到的小麻煩，就已經很實用。

從自己的需求開始做 App

我最近陸續嘗試開發幾款 App，慢慢發現一件事情：最適合開始動手做的題目，通常不是看起來最厲害的點子，而是自己真的會使用的工具。

因為自己就是使用者，所以很清楚哪些步驟太麻煩，哪些功能其實不需要，哪些地方如果多按一次就會懶得記錄。

CycleNote 目前仍然會持續調整。我希望它保持簡單，但也能逐步加入更多實用的週期記錄功能。

它不一定是一款功能最複雜的 App，但它確實來自我每天會遇到的問題。

而這也是我開始做獨立 App 之後，愈來愈喜歡的一件事：生活中遇到一個小麻煩，不一定只能尋找現成工具，有時候也可以試著自己做一個。

雙平台下載連結：AppStore | Google Play

第一篇先從 Clockwise 開始。

Clockwise 是我做的一款萬國時鐘 App，主要是用來解決跨時區看時間、安排會議、確認海外朋友或團隊現在時間的問題。

會想做這款 App，其實原因很簡單：
現在很多事情都不是只跟台灣時間有關。

可能是遠端工作、海外朋友、國際服遊戲活動、國外客服、跨國會議，甚至只是想知道某個城市現在是白天還是晚上。這些事情看起來都不大，但每天一直心算時差，其實還是有點麻煩。

所以 Clockwise 的目標不是做一個很複雜的工具，而是做一個可以快速打開、快速看懂、快速判斷的世界時鐘。

一開始想解決的問題

我自己在設計 Clockwise 時，主要想解決幾個問題。

第一個是不用每次都心算時差。

例如台灣現在是下午，但美國、歐洲、日本、澳洲各地時間不同，如果每次都要自己算，久了真的很煩。

第二個是希望一眼就能看出對方那邊現在適不適合聯絡。

有些世界時鐘 App 只是顯示時間，但我更希望它可以讓人直覺知道：

• 那邊現在是白天還是晚上
• 跟本地時間差幾小時
• 現在是不是大概適合開會或聯絡
• 夏令時間有沒有被正確處理

第三個是畫面要乾淨。

我不想把它做成很重的行事曆，也不想一進去就很多設定。Clockwise 比較像是一個每天可以快速看一下的小工具。

Clockwise 目前的主要功能

Clockwise 目前主要有幾個功能。

多城市時間顯示

使用者可以加入不同城市，然後在首頁一次查看各地目前時間。

這是最基本，但也是最重要的功能。對我來說，世界時鐘最重要的不是功能多，而是資訊要清楚。打開 App 之後，最好可以在幾秒內就知道自己要看的城市現在幾點。

自動處理時區與夏令時間

時區其實不是單純加減幾小時而已，因為有些國家或地區會有夏令時間。

如果 App 沒有正確處理夏令時間，就很容易在安排會議或活動時出錯。

所以 Clockwise 在設計時，就把時區與 DST 這件事當成核心功能之一，而不是單純讓使用者自己手動設定時差。

城市卡片與顯示方式

我希望世界時鐘不要只是冷冰冰的一排數字。

所以 Clockwise 有城市卡片的概念，讓不同城市可以用比較直覺的方式呈現。未來也會持續調整卡片樣式，讓它更適合日常使用。

Best Meeting Time

這是我覺得比較實用的功能。

當你有多個城市或多個時區的人要開會時，最麻煩的就是找一個大家都還算可以接受的時間。

Best Meeting Time 的目的就是幫使用者快速找到比較適合的重疊時段。

它不是要取代大型行事曆工具，而是讓你在規劃跨時區會議時，可以先有一個大概方向。

例如：

• 台灣
• 美國西岸
• 英國
• 日本

這幾個地方要一起開會時，就可以用這個功能快速判斷哪個時間比較合理。

免費版與 Pro 版的設計

Clockwise 有免費版，也有 Pro 版。

免費版主要是讓一般使用者可以先正常使用，不需要一開始就付費。對只需要看少數幾個城市的人來說，免費版其實就夠用了。

Pro 版則是給比較常使用世界時鐘的人，例如：

• 需要加入更多城市
• 經常安排跨時區會議
• 想要更完整的自訂功能
• 不想受到免費版限制

我自己比較不喜歡每個小工具都做成訂閱制，所以 Clockwise 的 Pro 版設計方向是偏一次買斷。對使用者來說比較單純，對我來說也比較符合這款工具的定位。

開發過程的一些想法

Clockwise 是用 Flutter 開發的。

這幾年我自己做 App，大多會優先考慮 Flutter，原因是可以同時支援 iOS 和 Android，對一人開發來說比較實際。

不過世界時鐘看起來簡單，實際上還是有一些細節需要處理。

例如：

• 不同地區的時區資料
• 夏令時間
• 城市搜尋
• 卡片排序
• 本地時間與目標城市時間的比較
• UI 顯示是否夠直覺
• 免費版與 Pro 版的功能切分

這些東西單獨看都不大，但真的做起來就會發現，小工具要做到好用，其實很多地方都要慢慢修。

這款 App 也算是我用 AI 輔助開發流程中的一個實戰案例。

現在我寫 App 時，會大量使用 AI 協助整理需求、拆功能、檢查程式碼、補文案、修錯誤。不過 AI 不是按一下就完成，很多時候還是要自己判斷功能怎麼切、問題在哪裡、使用者會怎麼操作。

所以對我來說，AI 比較像是一個很強的開發助手，但產品方向和最後的判斷還是要自己負責。

適合哪些人使用？

Clockwise 比較適合下面幾種使用者：

• 常常需要看不同國家時間的人
• 有海外朋友或家人的人
• 遠端工作者
• 需要安排跨國會議的人
• 會玩國際服遊戲、需要看活動時間的人
• 常出國或常跟海外窗口聯絡的人

如果你只是偶爾查一次時間，可能用 Google 搜尋就夠了。

但如果你每天都會看幾個固定城市的時間，那 Clockwise 會比較方便。

小結

Clockwise 不是一款很複雜的 App。

它比較像是一個日常小工具，目標是讓跨時區這件事變得簡單一點。

對我來說，這款 App 也是一個練習：如何把一個小痛點做成完整產品，然後真的上架、維護、調整，讓它變成可以被使用者下載和使用的工具。

接下來我也會陸續整理其他 App 的開發紀錄，包含 CycleNote、Rootrees、兔耳絲工具屋，以及我這段時間用 AI 輔助開發 App 的一些心得。

雙平台下載連結：AppStore | Google Play

在Laravel 8 建立專案時直接加上參數

laravel new 專案名稱 --jet

安裝時會詢問要哪種 stack，個人偏好用livewire，接著會詢問是否要teams，獨立開發的選no即可。

安裝完後到專案目錄底下執行

npm install && npm run dev

好了之後記得調整專案下的 .env 檔做資料庫的連線相關設定，記得先建立資料庫。

最後執行

php artisan migrate

完成

接著測試一下專案是否正常 進入 https://localhost/test/public/

一切正常

接著進入登入畫面看看如何， 破破破~~破版了！  =.=|||

接著打開專案下的public/mix-manifest.json

{
    "/js/app.js": "/js/app.js",
    "/css/app.css": "/css/app.css"
}

在 / 前面加上實際專案的路徑

{
    "/js/app.js": "http://localhost/專案名稱/public/js/app.js",
    "/css/app.css": "http://localhost/專案名稱/public/css/app.css"
}

這樣就正常了