《Day 02：安裝與第一個 Panel，認識這個後台入口容器》 結尾留下一句話，容器蓋好了，裡面還是空的，明天要放進第一件真正有內容的東西，商品管理介面。今天要做的正是這件事。

開場，容器裡該放進第一件東西了

今天的任務範圍很明確，只做一件事，為商品模組建立第一個 Resource，走完列表、建立、編輯、檢視四個預設頁面。訂單、客戶這些其他模組今天都不會出現，商品跟其他模組之間的關聯也還不會處理，今天的商品 Resource 只專注在商品本身的欄位上。

從商品開始不是隨意的順序安排。商品是整個示範情境裡最基礎、不依賴其他模組就能獨立存在的資料，一張訂單如果沒有商品可選就沒有意義，庫存要有商品當作追蹤對象才成立，報表則要等其他模組都累積出資料才有東西可看。商品幾乎不欠任何人，卻被其他模組欠著，這讓它成為整個系列動手做的最自然起點。

建立 Model 與 Migration，Resource 蓋在既有的地基上

在打開終端機建立 Resource 之前，先確認一件更基本的事，商品這個 Eloquent Model 跟對應的資料表存在嗎。如果你是照著系列一路做下來，這一步可能還沒做過，先用平常熟悉的方式建立：

php artisan make:model Product -m

這裡先不展開完整的欄位型別選擇，那個細節留給明天。但方向感還是需要有，商品資料表至少會需要名稱、分類、價格、庫存數量、上架狀態這幾個欄位，這是任何一套商品管理介面都繞不開的基本盤，先在 Migration 裡把這幾個欄位的雛形寫出來，欄位型別選得粗略一點沒關係，跑過 php artisan migrate 讓資料表真正存在即可。

為什麼要先確認這一步，而不是直接跳去下指令生成 Resource。這裡呼應 《Day 01：為什麼是 Filament，跟手刻後台與其他套件比起來差在哪》 已經定案的定位，Filament 深度綁定 Laravel 既有的 Eloquent Model，而不是另外發明一套獨立的資料層。Resource 不會憑空生出一張資料表，它做的事情是讀取一個已經存在的 Model，把這個 Model 的欄位包裝成可以操作的介面。延續 Day 1 用過的比喻，Eloquent Model 跟 Migration 是地基，Resource 是蓋在這塊地基上的建築骨架，地基沒打好，骨架無處可蓋。所以今天動手的第一步，永遠是先確認商品的 Model 跟 Migration 已經備妥，接下來才輪到 Resource 登場。

一個指令，生成四個頁面

地基確認之後，正式進入今天的主戲。打開終端機，下這道指令：

php artisan make:filament-resource Product --view

指令帶了 --view 這個選項，這件事值得說明一下。Filament 的這道指令預設只會生成列表、建立、編輯三種頁面，檢視頁面需要額外加上 --view 才會一併產生。今天的目標是走完完整的四頁，所以指令一次帶齊這個選項，讓四個頁面一起生成，不用之後再補一次指令。

指令執行完，Product 這個 Model 名稱會被拿去推導出整組檔案的命名與位置，app/Filament/Resources 底下會出現一個 Products 資料夾，裡面有負責整體定義的 ProductResource.php，還有一個 Pages 子資料夾，裡面放著四個各自獨立的頁面類別，分別對應列表、建立、編輯、檢視。你不需要背下這份目錄結構的每一個細節，但值得花一分鐘打開來看一眼，親眼確認這四個頁面類別是真實存在的檔案，而不是某種隱藏在框架深處、看不到摸不著的魔法。

這裡正式把今天的核心錨點定下來，Resource 指的是對應一個 Eloquent Model 的完整 CRUD 管理介面骨架，含列表、建立、編輯、檢視四種預設頁面。這個定義從今天開始固定下來，後面提到 Resource 都是指這件事。

四個頁面分別對應什麼操作，逐一拆開來看：

• 列表頁，對應瀏覽所有商品的表格畫面，打開商品這個選單項目，看到的就是這一頁，每一列是一筆商品資料。
• 建立頁，對應新增一筆商品的表單，列表頁右上角會有一個新增按鈕，點下去就是進到這一頁。
• 編輯頁，對應修改既有商品的表單，在列表頁的某一列上點擊，會直接帶著這筆商品的既有資料進到編輯表單。
• 檢視頁，對應唯讀顯示單筆商品完整資訊的畫面，適合只是想確認某筆商品目前狀態、不打算動手修改的情境。

這四頁不是各自獨立的孤島，彼此之間是有串接關係的，列表頁是整個 Resource 的入口，其他三頁都是從列表頁出發才會走到的目的地，走完編輯或建立之後，也會自動導回列表頁，讓你確認剛才的操作反映在資料上了沒有。

做完這一步，還有一件事今天不需要動手，就是回到 AdminPanelProvider.php 手動註冊這個新建立的 Resource。這正是 Day 2 已經提醒過的自動掃描機制在發揮作用，因為 ProductResource 這個類別被放進 discoverResources 指定的資料夾裡，Panel 啟動時就會自動把它掃描進來，不需要回頭補上任何一行註冊程式碼。重新整理 admin Panel 的頁面，側邊選單會自動多出商品這個項目，這正是自動掃描機制第一次讓你有感的時刻。

對照手刻後台，五分鐘省下的究竟是什麼

指令跑完，頁面也看得到了，這時候適合回頭驗證一件事， Day 1 講過的開發速度優勢，今天親手操作有沒有真的感受到。

如果今天沒有 Filament，要手刻出一套一模一樣的商品 CRUD 介面，具體要完成的工作項目其實不少。四個頁面對應的操作，各自需要一個 Controller 方法去處理，列表要寫分頁與排序邏輯，建立跟編輯都要設計對應的 Blade 表單樣板，還要手動寫驗證規則檔擋住不合法的輸入，新增成功或驗證失敗之後的提示訊息也要自己處理，這些工作項目加起來，隨便都是好幾個檔案、好幾百行程式碼的份量。

今天一個指令生成的骨架，已經內建了這些機制的預設實作。列表頁本來就有分頁功能，表單本身就串接著驗證流程，操作完成後的提示訊息也是內建行為，不需要另外寫一行程式碼。這個落差不是文字上的形容詞能完全傳達的，實際跑過一次今天的指令，跟看著 Day 1 那段論述紙上談兵，感受完全不同，這正是 Day 1 提出、當時只能靠文字說服的「開發速度」優勢，第一次在你自己的專案裡被驗證出來。

但這裡要誠實補一句，不要被「五分鐘」這三個字沖昏頭。今天生成的介面樣式非常粗略，表單欄位大概只是最基本的文字輸入框，稱不上是真正貼近商品管理需求的介面，客製化彈性這個優勢，今天完全還沒有展現出來。今天只驗證了開發速度這一半，彈性的一半留給後續天數逐步加深。

階段一收尾，陽春後台正式誕生

今天是階段一「動機與地基」的最後一天，適合停下來回顧一下這三天走過的路徑。Day 1 把「為什麼是 Filament」從一句直覺推薦拆成具體的決策依據，也定案了寵物用品批發商這個示範情境。Day 2 完成安裝，看懂 Panel 這個容器概念，打開瀏覽器看到一個能登入但空無一物的後台。今天讓這個容器第一次裝進真正能操作的東西，商品管理介面。

現在登入 admin Panel，能看到第一次真實存在的商品列表，可以新增一筆商品、點進去編輯、切換到檢視畫面確認資料，一個陽春但真實可操作的後台正式誕生了。這三天累積下來的成果，不再只是安裝紀錄跟設定檔，而是一個你可以親手操作、螢幕上有東西可以點的介面。

但這個陽春也要老實承認。今天生成的表單欄位還是最基本的預設樣式，商品實際需要的欄位其實遠不止於此，分類要用什麼方式選擇，上架狀態要用什麼元件呈現，規格描述這種長文字內容又該怎麼處理，這些欄位背後都牽涉到不同的欄位型別選擇，今天的介面離真正貼近商品管理的實際需求還有一段距離。

這些欄位型別的講究，從文字輸入到日期選擇器，會是明天要處理的內容。階段一的地基打完了，接下來要開始往這個骨架裡填進真正有血有肉的細節。