當時應該還沒有「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"
}

這樣就正常了

在Nginx的環境裡面，定時檢視error.log是很重要的事情，這次小編就遇到了這問題。在 /var/log底下的php7.0-fpm.log裡面可以發現下列的錯誤。

定期查看php7.0-fpm.log

WARNING: [pool www] server reached pm.max_children setting (*), consider raising it

在處理php時，是Nginx直接調用php-fpm，如果請求量過高然後又沒有給php-fpm足夠的配置，就會有資源耗盡的可能，一旦找不到php-fpm，就會出現502的錯誤畫面。

這時候需要調整php的www.conf，如果是php7.0，位置會在 /etc/php/7.0/fpm/poo.ld/www.conf，而需要調整的部分如下，

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
pm.max_requests

計算要調整的數量，則是需要依據Server上的記憶體進行調配。可以先查看每一個php-fpm使用的記憶體數量，可以用下列方式來查看。

ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x<=NF ; x++ ) { printf("%s ",$x) } print "" }' | grep php-fpm

會跑出每一個php-fpm所需要的記憶體

33.88 Mb php-fpm: pool www
33.83 Mb php-fpm: pool www
33.57 Mb php-fpm: pool www
33.52 Mb php-fpm: pool www
33.28 Mb php-fpm: pool www
32.34 Mb php-fpm: pool www
32.32 Mb php-fpm: pool www
31.88 Mb php-fpm: pool www
31.86 Mb php-fpm: pool www
31.78 Mb php-fpm: pool www
31.38 Mb php-fpm: pool www
30.35 Mb php-fpm: pool www
28.11 Mb php-fpm: pool www
26.17 Mb php-fpm: pool www
24.29 Mb php-fpm: pool www
24.02 Mb php-fpm: pool www
5.90 Mb php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
0.34 Mb grep –color=auto php-fpm

這樣推算平均大概在30MB左右，如果Server的記憶體是4G來看，扣掉系統運作的部分，假設是3G來計算pm.max_children = 3072MB / 30MB = 102，所以每一個參數都要自己進行調整測試才可以找出符合自己Server的數量，別忘記，調整完畢之後記得要重啟服務。

sudo service php7.0-fpm restart

參考來源：https://myshell.co.uk/blog/2012/07/adjusting-child-processes-for-php-fpm-nginx/

本文同步發表在WordPress工具書

前台登入

在前面Part 2有使用到前台上圖的外掛，這款WP User Frontend有Login的功能，可以調整登入的介面，強制使用者登入完畢之後回到特定頁面，下圖如設定的部分，可以在後台的[User Frontend] > [Settings]找到。

設定完成之後將 [wpuf-login] 填入分頁即可，如下顯示

透過外掛的功能快速達到前台登入的功能，不過如果覺得登入介面不夠華麗，不夠漂亮，可以透過CSS來進行美化。或者使用另一款ProfilePress Lite外掛來達到前台搭入的效果，一樣先從官網的外掛進行下載安裝並且啟用，啟用完畢之後在左側選單會出現ProfilePress的功能清單。裡面有兩的部分，第一個部分是Login Form而另一個部分是Registration Form。

進入Login Form之後可以看到如下的畫面，已經有建立好三種登入樣式，可以快速使用。

接下來將上面隨便一個ShortCode貼入登入的頁面即可，每個登入介面都經過設計，可以直接使用喔！

前台註冊

註冊的填入的表單也是一樣，如下所顯示，將註冊表單的ShortCode填入註冊的頁面即可，這樣就大功告成。

以WordPress為基礎來架設社群的服務基本上都是沒有問題，而是取決要用哪一種方式來達成。艾德覺得市場上的變化很快，用WordPress以最快的速度將服務推出來到市場試水溫更為重要。

以WordPress實作imgur.com的系列文章，講解得很快，有不懂的地方可以發問，也請多多指教！

• 以WordPress實作imgur.com網站為例 (Part 5 – 前台登入)
• 以WordPress實作imgur.com網站為例 (Part 4 – 圖片管理及選單權限)
• 以WordPress實作imgur.com網站為例 (Part 3 – 圖片網址)
• 以WordPress實作imgur.com網站為例 (Part 2 – 前台上圖)
• 以WordPress實作imgur.com網站為例 (Part 1 – 淺談架構)

若對於WordPress有興趣的可以與我聯繫。

edl2000(小老鼠)gmail達康

W4 Post List外掛使用

首先，要建立個人資料的頁面，也就是顯示已經登入的使用者，可以查看自己上傳過的圖片。本次要使用的外掛是W4 Post List，這外掛是免費的，可以在WordPress官方的Plugin找到，一樣先下載進行外掛安裝並且啟用外掛。啟用之後可以在左側選單找到

點選Add New之後開始新增列表。這邊要注意的是，目前是使用Divi內建的Post Type，所以選擇第一個Post的部分，Preset選擇Post with Thumbnail，也就是有使用縮圖做顯示。

再來切換到List Type下方的Posts，因為使用內建的Post Type，所以就要選擇對應的名稱，請將Projects打勾。Post Status為文章狀態，將Publish(發佈)的打勾，好了之後發佈即可。

接下來再W4 Post List的列表頁上面可以取得ShortCode

複製ShortCode的內容，然後點選左側的[頁面] > [新增頁面]，再內容的部分填入剛剛複製的ShortCode。

如此一來就完成囉！前台的頁面您可以透過CSS定義樣式即可。

接下來要處理主選單的部分，這裡講到的權限是有登入的情況下可以看到我的圖片，也就是剛剛透過W4 Post List做的頁面。基本上那一個頁面已經有判斷是否有登入狀態了，所以未登入的情況下點進去是顯示全部的圖片，有登入的情況下則是顯示自己的圖片。不過在選單上我們還做些處理，接下來將使用if Menu這套外掛來進行設定。

if Menu外掛使用

介紹一下這款外掛，外掛名稱看起來大概就知道這功能是甚麼，if 在程式裡面都是做判斷用的，menu就是要顯示的選單(廢話 XD)。一樣到WordPress的官網外掛區進行下載，再進行外掛安裝並且啟用外掛。

外掛啟用之後在外觀裡面可以找到設定，這邊設定是調整管理者是否要看到隱藏的選項。打勾，那麼管理者就會在前台看的到隱藏項目，不打勾則無法看到，就只是測試用而已。

接下來就是主要的部份，直接到[外觀] > [選單 ]，下方用imgnow.cc的做展示設定。

可以看到我的圖片這個選單，有一個Change menu item visibility，也就是改變選單項目的可見度，點選之後可以有不同的條件搭配。

第一個下拉選單有Show 跟 Hide

第二個下拉選單有很多，可以參考畫面顯示。

這邊設定Show > User is logged in，也就是只有在登入狀況下才會顯示這個選項。

好了存檔即可，接下來測試看看前台畫面，上方為登入情況下顯示，下方為未登入的時候顯示。

這樣就完成了查詢使用者上傳圖片的功能以及選單判斷登入顯示！

Part 5: 以WordPress實作imgur.com網站為例 (Part 5 – 前台登入)