AI Commander 的定位
AI Commander 並不是單一頁面的主體功能,而是掛在後台共用 layout 上的全站漂浮對話框。它的角色比較像一層全域 AI 助手,讓使用者在任意工作流程中,都能隨時提出問題、要求分析,或進一步觸發待確認操作。
這種設計和把 AI 侷限在某一頁不同。它更適合多模組來回切換的後台情境,因為使用者不需要先跳到特定頁面,才能開始與系統互動。
這頁以接近文件的方式整理系統能力。左側為模組目錄,右側則以章節形式說明各分類的定位、主要功能與實際可用範圍。
作為全後台共用的漂浮式 AI 助手入口,支援跨頁面提問、分析、操作確認與歷史對話延續。
AI Commander 並不是單一頁面的主體功能,而是掛在後台共用 layout 上的全站漂浮對話框。它的角色比較像一層全域 AI 助手,讓使用者在任意工作流程中,都能隨時提出問題、要求分析,或進一步觸發待確認操作。
這種設計和把 AI 侷限在某一頁不同。它更適合多模組來回切換的後台情境,因為使用者不需要先跳到特定頁面,才能開始與系統互動。
Commander 掛在後台共用 layout 中,因此除了 /admin/station 指揮站頁本身會隱藏外,其餘大多數後台頁面都可以直接呼叫。這讓它在使用上更接近系統層級工具,而不是某個模組內的附屬功能。
在介面上,它以右下角固定顯示的浮動按鈕存在,讓使用者不論正在看訂單、商品、分析或 CRM,都能快速開啟對話視窗。
最直接的使用方式,是從右下角 Commander 漂浮按鈕開啟視窗。這種設計適合臨時提問、即時查詢或在工作途中要求系統協助分析。
另一種更進階的方式,是由其他頁面帶入指定內容後開啟。特別是在分析報告頁中,可以附帶報告內容與時間區間作為對話上下文,讓使用者不必重述背景就能直接延續問題。
Commander 採用獨立漂浮視窗,而不是整頁式介面,因此在工作流程中干擾較小。使用者可以依照當下需求展開視窗深入對話,也可以先最小化暫時保留工作狀態。
在互動模式上,系統也區分聊天模式與歷史紀錄模式。前者偏向當下對話與操作,後者則偏向回看過去內容與延續既有脈絡,這使它不只是一次性聊天框,而是可累積上下文的工作介面。
在對話層面,Commander 允許使用者直接輸入自然語言,不論是查詢營運資料、要求分析某段報告,或提出操作需求,都可以透過同一個介面發送。這讓它在使用上更像通用型 AI 助手,而不是固定格式的表單工具。
訊息區同時會顯示使用者輸入與 Commander 回覆,且回覆支援 Markdown 格式,意味著系統不只輸出簡單文字,也能呈現較有結構的說明內容。發送過程中則會顯示思考或載入狀態,讓使用者清楚知道系統正在處理請求。
Commander 的一個重要能力,是不必每次從零開始對話。當使用者從分析報告或其他分析區塊進入對話時,系統可以把報告內容一併掛載進來,讓提問建立在既有資料之上。
介面中也會顯示目前掛載的報告類型與時間區間,讓使用者清楚知道 AI 正在參考哪些背景資訊。如果上下文不再需要,也可以直接移除,避免後續回覆被不相關內容影響。
Commander 不把每次對話視為一次性互動,而是提供完整的歷史紀錄能力。使用者可以在歷史列表中查看對話標題、最後一則訊息摘要與最後更新日期,快速判斷哪一段紀錄值得回來接續。
若需要重新延續某個分析脈絡,也能直接載入舊對話繼續聊天,而不是重新開始。系統同時支援刪除單筆對話、清除全部歷史與開啟新對話,讓紀錄維護保持彈性。
Commander 的角色不只停留在回答問題,也可以在回覆中附帶待確認操作。這表示它除了分析與說明,也開始承接部分可執行工作,但仍保留使用者確認這個關鍵步驟。
在介面上,使用者可以看到待執行動作名稱與參數內容,再決定要確認執行或取消。執行後也會顯示完成或取消的狀態標籤,讓整個流程更接近可追蹤的工作確認,而不是黑盒式自動操作。
Commander 的價值,很大一部分來自它不是孤立存在。它可以從分析報告頁帶入報告上下文提問,也能從 AI insight 或 analytics 類區塊直接呼叫,讓使用者在閱讀分析內容時,立刻延伸後續問題。
此外,它也能與 /admin/station 的任務與事件流同步。當操作執行完成後,還可觸發任務列表刷新,讓 AI 對話、指揮站與其他模組之間形成連續性的工作關係。
作為管理中心首頁,集中呈現每日營運、流量、待處理事項與快捷入口。
Dashboard 是管理中心的總覽頁,設計目的不是取代各個專門模組,而是讓使用者一進入後台,就能先快速掌握今天的營運狀況、目前需要優先處理的工作,以及接下來應該前往哪個頁面。它更像是一個每日巡檢與工作分流的起點。
在營運總覽區,使用者可以直接看到今日營收、本月累計營收、今日訂單數與轉換率,作為快速掌握生意狀況的基礎資訊。這些數據搭配營收圖表呈現,能幫助管理者在短時間內理解近期銷售走勢,而不需要先進入更完整的分析頁面。
介面中也預留了 7 天與 30 天的切換樣式,表示這個區塊已朝不同觀察區間的使用情境做設計。不過以目前功能狀態來看,實際顯示的仍以近 7 日資料為主。
除了銷售數據,Dashboard 也會集中呈現站內流量的基礎資訊,讓使用者能快速判斷今天的流量表現是否有明顯波動。這一區目前包含今日訪客數、與昨日相比的變化,以及主要流量來源,例如 Meta、Google 與 Direct。
這樣的設計適合做第一層判讀。當訪客數提升但轉換率下降時,管理者就能進一步檢查流量品質、活動頁內容,或商品承接表現是否出現落差,而不是只停留在數字表面。
頁面中也保留了 Google Analytics 快捷按鈕,方便未來串接更完整的流量分析流程。
待處理訂單區的作用,是把營運與客服最常需要優先關注的訂單狀態集中顯示。使用者可以直接看到待處理訂單、待出貨訂單、退款/退貨中訂單,以及異常訂單的數量,快速掌握目前工作壓力主要集中在哪個流程。
這種呈現方式不只是統計展示,也有實際的分流價值。當某一類訂單數量明顯增加時,團隊可以更快判斷今天應優先處理出貨、退款,或異常訂單排查。
各狀態卡片也可直接跳轉到對應的訂單篩選頁,縮短從總覽頁切換到實際處理頁面的時間。
除了固定數據與統計欄位,Dashboard 也提供 AI 營運提醒區塊。系統會根據站內營運數據整理出重點事件,並以事件標題與摘要說明的方式呈現,幫助使用者更快注意到異常、變化或需要追蹤的事項。
這類功能的價值,在於先替使用者做第一輪資訊整理。對於同時管理訂單、庫存、會員與行銷的團隊來說,AI 提醒能降低在多個模組間來回查找的成本,讓人更容易先看到真正值得關注的問題。
若事件與特定模組有關,也可直接跳轉到相關頁面進一步查核。
Dashboard 不只是資訊首頁,也承擔了工作入口的角色。當使用者完成初步巡檢後,通常下一步就是新增商品、查看訂單、建立活動或檢查會員資料,因此頁面也整合了一組快捷操作,減少重複切換選單的時間。
這一區的定位很明確,就是把常用任務集中在同一個地方,讓 Dashboard 從單純的資訊總覽,延伸成每日工作的轉接中心。
將 AI 任務建議、待處理事件與站務簡報集中為專門的指揮視角。
AI 指揮站台的定位,比 Dashboard 更聚焦在事件判讀與處理方向。它不是單純把指標再重複一次,而是把 AI 生成的摘要、建議與優先事件集中成一個比較偏指揮視角的工作畫面。
對於同時管理多個模組的營運團隊來說,這個頁面更適合用來安排今天先處理哪些問題、哪些事件需要追查,以及哪些任務可以延後,不同於一般分析頁偏重看數字,也不同於功能頁偏重逐筆操作。
站台總覽會把今天值得先注意的營運資訊收斂成較高層的摘要內容,讓管理者在很短的時間內掌握目前站務重點。這類設計適合每日開工、週會前巡檢,或需要快速了解整體狀況時使用。
相較於單一模組數據,這一區更強調整理後的結論與優先順序,目的是降低使用者自行比對多頁資訊的負擔。
站台中的 AI 指揮功能,會把待處理事件與建議行動整合在一起,讓使用者不只是看到異常,而是能接著判斷該往哪個模組深入處理。這種設計比較貼近日常營運決策,而不是單純的訊息通知。
當事件涉及訂單、庫存、行銷或分析時,使用者也能透過站台提供的入口回到對應頁面進一步查核,因此它更像工作流程的中控視角。
指揮介面的重點在於把多來源的事件整理成容易瀏覽的結構,包含任務卡片、狀態、事件分類與優先排序。這讓使用者在資訊量較大時,也能較快知道哪些問題需要先看、哪些可以稍後處理。
對中小型團隊來說,這種整理方式有助於降低資訊分散的問題,尤其適合需要兼顧營運、行銷與客服的管理者。
從營收、轉換、廣告、流量到 AI 報告整合成完整的商業分析工作台。
數據分析看板是較完整的經營分析入口,用來承接 Dashboard 的總覽資訊,進一步把營收、訂單、客單價與轉換等核心指標整理成更適合分析的視角。
如果說 Dashboard 偏向每日巡檢,那數據分析看板更適合用來觀察趨勢、理解銷售結構,或在活動檔期與成長策略上做更完整的判讀。
在核心指標層,頁面提供較常用的商業基礎指標,方便管理者快速比較不同期間的營運表現。這些指標屬於最常被拿來做營運復盤與短期成效判斷的數據,因此放在分析看板的核心位置是合理的。
區間切換的設計也讓這個頁面可以同時支援短期波動觀察與較長週期回顧,不需要來回切換不同報表。
分析看板不只停留在整體營收曲線,而是進一步把銷售結構拆成幾個比較有決策意義的區塊,例如熱銷商品排行、客單價分布與商品組合關聯分析。這些資訊有助於理解哪些品項在帶動營收,哪些組合可能具備交叉銷售價值。
Cohort 留存分析則讓頁面不只看單次交易,而是開始延伸到會員或顧客的回購與留存觀察,讓分析範圍從營收結果往經營品質推進一步。
報告管理中心承接分析看板中的 AI 分析內容,讓使用者可以用列表方式管理不同報告。這種設計適合需要長期累積分析紀錄、回看舊報告,或在不同主題間切換的情境。
列表中會顯示標題、類型、建立時間與摘要,讓使用者在不進入全文前,也能先快速判斷這份報告是否與目前要追查的問題相關。
Meta 廣告解讀頁面提供的是比較偏投放管理的分析視角。它把廣告花費、轉換數、ROAS、CPC 與 CTR 等常用指標集中呈現,讓團隊能在同一頁面快速掌握近期投放表現。
進一步拆到 Campaign、Ad Set 與 Ad 層級後,也更方便理解成效差異來自哪一層,適合作為廣告優化與活動回顧的入口。
Google Analytics 頁面補足了流量分析的深度,適合用來承接 Dashboard 中較簡化的流量摘要。當使用者需要從站內營運往流量來源、裝置分布與頁面表現延伸時,這一頁就會比總覽型資訊更適合。
這樣的分工很清楚:Dashboard 幫你先看有沒有異常,GA 分析頁則幫你深入理解異常可能發生在哪裡。
整合營收、交易、退款、發票與財務指標,讓帳務流程與分析都更清楚。
帳務概覽的角色,是把財務面最需要先掌握的資訊集中成一個管理入口,讓使用者先了解近期營收與退款狀況,再視需要深入交易或發票處理頁面。
對品牌營運方來說,這一頁的價值在於把生意數字與帳務處理放在同一個上下文中,而不是讓財務資訊零散地分佈在多個功能頁。
財務總覽會先把關鍵數字集中呈現,包括營收相關 KPI、近 30 日趨勢、退款走勢與淨營收,讓管理者在查看財務時不只看到收入,也能一併理解退款對整體表現的影響。
同時保留稅務設定入口,也代表這一區不只是報表,更是通往後續財務設定與處理流程的入口。
交易與退款頁面偏向實務處理與資料查詢。當使用者需要查某一筆付款、退款進度,或匯出資料進一步整理時,這一頁會比總覽更直接。
列表中同時保留狀態、金額、時間與訂單連結,也讓帳務追查不必脫離訂單上下文,適合營運、財務或客服交叉查核時使用。
電子發票頁面承接交易後的正式憑證流程,讓發票管理不只是資料留存,也能直接對應到日常開立、作廢與折讓等操作。這對需要合規處理發票流程的品牌來說,是非常實務的一塊。
頁面也保留了跳轉對應訂單的能力,因此在處理發票時,不會失去與訂單原始情境的連結。
把訂單、出貨批次、物流與運費規則收斂成完整的履約管理流程。
訂單管理是日常履約流程的核心頁面,主要承接接單後的實際處理工作。相較於 Dashboard 偏向總覽,這裡更偏向逐筆查詢、篩選、狀態調整與批次作業。
對多訂單量的商家來說,這一頁的價值不只在於看清單,而在於能否有效率地把待處理訂單分流到不同工作階段。
訂單列表會顯示最常被拿來做排查與處理的基本欄位,因此客服、營運與倉儲都能以這頁作為共同工作入口。使用者也可透過訂單編號、顧客、Email、付款狀態、訂單狀態與日期快速縮小範圍。
這種多條件篩選設計,對於大量訂單下的日常作業尤其重要,因為它直接決定查找效率與分工速度。
當訂單量提高時,單筆處理很快會變得低效率,因此頁面提供勾選、批次更新與批次匯出等能力,讓團隊可以以流程為單位處理訂單,而不是逐筆重複操作。
單筆訂單詳細頁則補足了查核與例外處理的需求,讓使用者能在同一頁看到付款資訊、配送資訊、收件資料、商品明細與活動紀錄,並進行退款或物流更新等後續處理。
批次出貨的設計目的是讓出貨流程從單筆作業轉成可管理的批次節奏。當品牌每日有固定出貨量時,這種做法更容易安排揀貨、打包與交寄流程,也比較符合實際倉務作業方式。
頁面不只顯示批次編號、狀態與訂單數量,也支援從可分配訂單建立新批次,讓出貨流程可以從訂單列表延伸到更有結構的批次管理。
運費規則設定處理的是訂單成立前的配送邏輯與費率結構。它的價值不在於單筆物流查詢,而是讓商家可以依不同物流商、配送區域與計費條件,建立更貼近營運實際的配送規則。
當品牌同時使用 PayUni、ECPay 或自訂物流時,這一頁能提供較完整的管理框架,避免物流設定散落在不同地方。
聚焦商品本身的經營維護,包含商品資料、庫存、分類與評論等與商品結構直接相關的管理工作。
商品管理是整個內容營運的核心區塊,因為它不只管理商品是否上架,也同時承接價格、規格、媒體、分類與 SEO 等資料。對品牌方來說,這通常是使用頻率最高的管理頁之一。
從清單到編輯頁的設計,也可以看出它不是單純的商品名單,而是一個完整的商品資料維護流程。
列表頁提供商品圖片、名稱、商品 ID、分類、價格、總庫存與狀態等欄位,讓使用者先快速掌握目前商品盤點狀況。搜尋、排序與狀態篩選則讓商品數量成長後,仍能保持查找效率。
批次上架、設為缺貨、設為草稿與批次匯出等操作,也讓頁面不只適合單筆編輯,而能支援更有節奏的商品維護流程。
商品編輯頁承接了較完整的商品資料維護需求。除了基本名稱與價格,也支援不同語言內容、富文字描述、規格庫存、媒體順序、多幣別價格與 SEO 設定,功能範圍明顯超出簡單商品表單。
其中 AI 翻譯、AI 描述優化與分類建議等能力,則讓這個頁面不只是資料填寫工具,也逐步提供內容生產上的協助。
庫存管理頁面把商品與規格層級的庫存資訊分開整理,讓使用者能更清楚掌握哪個商品、哪個 SKU 正在接近低庫存或已售罄。這對有多規格商品的品牌特別重要。
可直接修改庫存與查看異動紀錄,也代表這個頁面不只是報表,而是具備實際營運維護能力的工作頁。
分類管理的價值,在於讓商品架構不只是前台導覽用途,也能支援後台搜尋、維護與內容治理。當商品數量增加時,分類的清晰度會直接影響營運效率與使用者瀏覽體驗。
支援拖曳排序、多語言與 SEO 設定,也讓分類不只是內部欄位,而是前後台都需要顧及的內容資產。
評論管理頁面讓品牌能以後台方式處理顧客回饋,而不是只在商品頁被動顯示。這對有經營口碑與顧客關係需求的品牌來說,是很實用的內容營運能力。
保留商品頁與訂單頁的關聯,也讓評論不只是內容,而能回到交易與客服上下文理解。
集中維護品牌對外呈現的內容資產,包含媒體、靜態頁面與部落格等前台內容。
媒體庫中心的作用,是把原本容易散落在商品、Banner、文章中的資源整理成共用媒體庫。這對需要重複使用素材的團隊來說,可以大幅降低資源管理成本。
除了上傳與刪除,也加入了詳情側欄、公開連結與 Alt Text 維護,因此這個頁面不只是檔案倉庫,也開始承擔資產治理功能。
頁面管理讓品牌能在商品與部落格之外,維護更多靜態內容頁,例如品牌介紹、活動頁、政策頁等。這代表系統不只重視交易頁,也把前台內容頁納入日常管理範圍。
Preview、Code 與 AI 生成整頁 HTML 的設計,也顯示這個頁面同時照顧到視覺預覽與內容生產兩種需求。
部落格管理提供的是內容行銷層面的經營能力,讓品牌能持續產出文章,而不必依賴外部 CMS。這對需要兼顧 SEO、品牌教育與內容導流的站點很重要。
文章編輯、分類管理、SEO 設定與 AI 文章助手整合在一起,也讓內容生產流程更完整,不只是單一篇文章的編輯器。
讓會員、標籤、購買歷程、VIP 與點數規則成為可持續經營的 CRM 底盤。
客戶列表是 CRM 的基礎入口,用來集中查看顧客身份、聯絡資訊、消費表現與互動狀態。它的價值在於讓客戶資料不只是一筆帳號資料,而能被整理成可經營的顧客輪廓。
當品牌開始重視再行銷、會員經營與分群操作時,這類集中式的客戶清單就會變得很重要。
客戶列表頁除了基本聯絡資訊,也會顯示消費總額、訂單數量與最後互動或購買日期,讓使用者可以很快判斷客戶價值與近期活躍程度。
搭配已註冊會員、訪客下單、遺棄購物車、VIP 等級與潛在客戶等標籤後,這些資料就能進一步支援更細緻的分群與溝通。
CRM 不只是看客戶清單,更重要的是能否快速找到特定客戶群並進一步操作。支援搜尋、類型篩選與名單匯出後,這一頁就能直接服務行銷與營運用途。
客戶詳細頁則補上單一顧客的購買歷史、可用點數與標籤維護,讓客戶管理從清單延伸到個體層級。
VIP 等級設定處理的是會員制度的結構面。當品牌要建立不同層級的權益與回購誘因時,這一頁能提供等級名稱、門檻與優惠的集中設定。
這讓會員制度不只是前台標示,而是後台可持續調整的經營策略。
點數設定的重點,在於把會員回饋機制轉成可調整的規則,而不是寫死在系統裡。無論是註冊贈點、評論贈點或消費換點比例,都會直接影響回購體驗與會員感知。
因此,這一頁不只是系統設定頁,也屬於 CRM 策略的一部分。
從折扣活動、首頁曝光到 EDM 與 SEO,集中管理成長與轉換所需的推進工具。
行銷中心處理的是成長與轉換相關的後台能力,包括折扣、活動、首頁曝光素材、EDM 與 SEO 設定。這些功能雖然分屬不同操作面向,但共同目標都是提升流量利用效率與轉單表現。
因此這一類頁面更適合從活動管理與內容曝光角度來理解,而不只是單一工具清單。
優惠代碼是最基礎也最常用的促購工具,頁面集中顯示折扣類型、折扣值、門檻、效期與使用次數,讓團隊能有效管理活動生命週期。
支援搜尋、建立、編輯與刪除後,這個頁面足以承接日常檔期與臨時促銷的運作需求。
促銷活動並不只是一種玩法,因此系統把不同類型的折扣與回饋分開管理。這種做法有助於商家依目的選擇合適機制,例如用限時優惠刺激短期轉換,用免運活動改善結帳阻力,用贈品與首購優惠提升新客體驗。
從後台結構來看,這一組功能已經不只是單一 coupon 工具,而是一套較完整的促銷活動管理框架。
行銷活動不只發生在折扣規則裡,也會直接反映在前台曝光版位上。首頁幻燈片與 Header Banner 的管理能力,讓品牌可以更有系統地安排檔期主視覺與活動訊息。
因為支援排序、多語言與媒體選圖,這些頁面已經具備一定程度的前台內容治理能力,而不是單純更換圖片。
EDM 行銷頁面補足了站內活動之外的主動觸達能力。從活動統計、開信率、點擊率到內容建立與發送,這一組功能讓品牌能在後台內部完成基本 Email 活動操作。
AI 生成郵件內容的加入,也使這個頁面不只偏向發送工具,而開始延伸到內容草稿產出的協助。
SEO 設定屬於比較偏站台層級的內容治理功能。它不只影響單一頁面,而是會對整站搜尋可見度產生長期影響,因此放在行銷中心中是合理的。
加入 AI 建議標題與描述後,也讓 SEO 維護不只是技術欄位設定,而能更貼近內容營運工作。
串接客服工單、FAQ 與 AI 客服設定,讓售前售後支援有一致的操作流程。
客服中心把顧客問題處理、知識整理與 AI 客服設定集中在同一個分類中,讓售前與售後支援不必散落在不同模組。這對需要跨客服、訂單與會員資料協作的團隊來說尤其重要。
從頁面組成來看,這一類功能的設計方向是讓客服回應流程更可追蹤,也更容易標準化。
客服工單頁面承接的是具體的問題處理流程,讓團隊可以用列表與單一工單視角管理顧客詢問,而不是只靠外部信箱或零散訊息。
因為頁面中會顯示顧客背景資料與關聯訂單,所以處理客服問題時,可以更快回到實際交易情境,減少查資料的時間。
FAQ 管理是客服知識整理的基礎。當常見問題能在後台被系統化維護,就更容易讓顧客自助解答,也能作為客服與 AI 回應時的知識來源。
支援排序與發佈狀態,也表示這一頁不只是資料表,而是前台知識內容的一部分。
客服功能設定處理的是回應機制與服務規則,而不只是訊息內容本身。從 AI 可讀取的知識來源到客服人格 Prompt,這些設定都會直接影響顧客接收到的回覆品質。
把這些設定集中在一頁,也有助於後續維護 AI 客服與真人客服間的分工方式。
集中處理品牌視覺、支付物流、多語言、權限與第三方整合等商店級設定。
系統設定處理的是整個站台運作的基礎層,包括品牌視覺、支付物流、通知、多語言、認證與團隊權限等。這些項目未必每天都修改,但會長期影響商店的運作方式。
因此這一類頁面的設計目標,通常不是高頻操作,而是讓關鍵設定可以集中維護、避免分散。
一般設定頁負責的是最基本的品牌與聯絡資訊,雖然內容看似簡單,但會直接影響前台識別與外部連結呈現,因此仍是商店初始化與品牌維護的重要頁面。
支援媒體庫選圖與拖放上傳,也讓這一頁更貼近實務操作,不需要反覆在其他模組間切換。
品牌視覺編輯提供的是站台外觀層級的控制能力。對需要維持品牌一致性的商家來說,能在後台統一調整色彩、字體與資產,比在各頁零碎修改更有效率。
預覽與重置設計也讓這個頁面更適合做視覺微調,而不只是靜態設定表單。
這一頁屬於商店營運的關鍵基礎設定,因為它會直接影響結帳、出貨與發票流程是否能正常運作。從 Merchant ID 到測試模式與付款方式,都是偏實務而必要的設定欄位。
把支付、物流與稅務放在同一個設定頁,也符合實際結帳流程彼此連動的特性。
這組設定共同處理的是站台運作規則。通知開關影響系統如何發送訊息,多語言設定影響不同語系的站台呈現,而認證設定則影響會員登入與註冊流程。
其中 UI translation key 管理與 AI 翻譯能力,也讓多語言維護不只是技術設定,而能真正支援後續營運。
這一組功能處理的是營運治理層面。退換貨政策屬於對外規則,第三方整合影響系統與外部服務的連動,而團隊權限管理則處理內部人員的操作範圍。
放在同一分類下,可以讓使用者從較高層的管理角度維護整個商店,而不只是修改單一功能頁。