Mockup 可以提供方向，但不能直接當成產品規格

本文記錄改版時的頁面與合作方向；網站後續已有調整，目前僅承接平面設計、UI/UX 與前端開發委託，依確認範圍報價，詳見合作頁。

一張 mockup 可以很快讓人看出頁面的氣氛、資訊層級和大致閱讀順序。工作室改版的參考圖也做了這件事：首頁、手機首頁、筆記列表、文章內頁、產品介紹和合作方向，都先用畫面把可能的結構放在一起。

但圖裡同時出現的標題、日期、卡片、產品畫面和服務項目，不會因此自動變成真的內容或功能。這些圖是 AI 生成的方向稿，不是量測用設計稿、產品截圖、正式文章或功能證明。主要判斷是：mockup 應該拿來對齊視覺方向，不應該替代內容資料、產品功能和互動行為的實作契約。

Mockup 先回答「畫面要怎麼看」

mockup 很適合先處理視覺問題，例如：

• 哪一段是首屏，哪一段是後續閱讀入口。
• 標題、說明、按鈕、卡片和圖片之間，誰應該先被注意到。
• 桌面版可以並排的內容，到了手機是否要改成上下閱讀。
• 筆記、產品、合作和關於是否被看成不同的內容區塊。
• 整個頁面想維持什麼氣氛，以及哪些區域需要留白。

這些資訊很有價值，因為實作者可以先討論「要不要朝這個方向走」，不用一開始就把每個 CSS 數值定死。

但 mockup 不能單獨回答另一組問題：

• 圖上的文章標題是否真的存在，日期是否真的可以公開。
• 圖上的按鈕要連到哪個 URL，還是其實只是一個視覺位置。
• 產品畫面裡顯示的欄位是否已經實作，服務項目是否真的能交付。
• 一張介面圖是正式產品截圖、靜態示意，還是單純用來表達構圖。
• 頁面在鍵盤操作、停用 JavaScript、窄螢幕、放大文字或載入失敗時會怎麼表現。

如果把這兩組問題混在一起，圖片就會悄悄替產品做決定：看起來像有日期，就被當成已發布；看起來像有功能，就被當成已完成；看起來像有聯絡表單，就被當成真的可以送出。

一張圖裡常常混著四種訊息

讀 mockup 時，我會先把可見內容分成四層，而不是把每個細節都抄進程式。

圖上看到的訊息	可以拿來討論什麼	還需要補什麼才能實作
區塊與排列	頁面層級、閱讀順序、桌面與手機的分組方式	真實 DOM 順序、RWD 規則、區塊是否真的存在
範例文字	內容長度、標題層級、卡片密度	正式文案、來源、語言版本和發布狀態
介面畫面	視覺焦點、產品與網站之間的比例	真實資產或明確標示的示意、alt、尺寸和錯誤狀態
功能暗示	可能需要哪些入口或互動	路由、元素語意、資料來源、狀態、鍵盤與無 JavaScript 行為

例如，筆記列表的 mockup 裡可以放很多看起來完整的卡片和分類標籤。它可以幫忙討論卡片應不應該有主題標籤、摘要和閱讀入口，卻不能證明那些文章已經寫好，更不能決定網站要為了填滿格子而新增假文章。

同樣地，產品 mockup 裡的儀表板畫面可以說明產品區需要一個比較大的視覺焦點，但不能從幾個帳戶欄位推導出完整的資料模型，也不能把示意圖裡的每個小圖示都當成已承諾的功能。

把視覺方向翻成實作契約

比較可靠的做法，是每一個想保留的畫面元素都回答「它在產品裡負責什麼」：

視覺元素	目前頁面的實作問題	可用的證據
首頁筆記卡片	要讀哪些文章、排序怎麼定、沒有文章時怎麼呈現	HomePage.astro 使用 getPublishedNotes(lang)，最多取三篇；沒有可發布文章時顯示空狀態
筆記列表與分類	分類是不是實際存在的內容契約，點擊後要去哪裡	NotesPage.astro 從可發布文章建立列表；分類、featured、分頁和文章連結都由目前資料與路由決定
文章頁目錄	目錄是否跟正文同步，手機版如何閱讀	ArticleLayout.astro 從實際渲染出的 heading 建立目錄，手機版另有 Drawer 和無 JavaScript 的 fallback
產品畫面	是正式 screenshot、程式產生的示意，還是尚未取得的素材	ZeniDashboardPreview 是元件輸出的靜態介面預覽；它能傳達構圖，不足以證明某個真實資料狀態
合作方向列	哪些是目前可公開的合作範圍，哪些仍只是探索方向	servicesCopy 目前列出合作方向與討論起點，也明確寫出 AI 導入顧問仍是未來方向
手機版並排區塊	縮小後的內容順序、換行、溢出和操作方式	同一套主要 DOM、以內容容納為依據的 RWD 規則，以及實際窄螢幕和鍵盤檢查

這個轉換步驟會讓 mockup 從「照著畫面切」變成「先確認每個區塊的責任」。有些元素會進入正式資料，有些會變成 CSS 或局部腳本的行為，有些則應該直接刪掉，因為它只是生成圖為了讓畫面看起來完整而補上的細節。

介面示意不是產品截圖

在這次改版裡，至少有三種容易被混叫成「畫面」的東西。

方向稿

方向稿用來討論整體氣氛、區塊比例和資訊階層。它不保證文字、圖示、日期、圖片或功能與最後版本相同。改版規格也明確把參考圖標成 AI 生成的方向稿，模型自行增加的細節不構成實作要求。

程式產生的介面示意

網站可以用 Astro 元件和 CSS 產生一個靜態介面示意，讓頁面不必依賴一張生成圖。例如合作頁目前的 ServicePreview.astro 會依不同方向產生簡化的面板、文字線和卡片，並標成「介面示意」；這個區塊本身是裝飾性的 aria-hidden 預覽，不是可以操作的服務系統。

首頁與產品頁使用的 ZeniDashboardPreview 也屬於程式組出的展示畫面。它可以協助交代產品區的視覺比例和內容方向，但不應被描述成某次真實帳戶狀態的 screenshot。

真實截圖

真實截圖應該來自實際存在的頁面或產品狀態，而且要另外確認可以公開的內容。它至少要能說清楚截的是哪個版本、哪個路由或狀態，以及圖片裡的資料是否已去識別。若只是靜態示意，就直接標示為「介面示意」，不要用 screenshot 這個詞替它增加不存在的可信度。

這個區分也會影響圖片的工程處理：真正要公開的圖片需要合理的 alt、尺寸、lazy loading 和載入失敗狀態；純裝飾的示意則不應讓輔助技術把它誤讀成一組可操作的資料。

發生衝突時，真實契約優先於圖的氣氛

目前改版規格給出的優先順序是：最新明確回饋先於內容與行為契約，內容與行為契約先於經確認的原圖與文案，而 mockup 氣質排在最後。這不是否定視覺，而是避免一張圖在沒有被討論的情況下取得決策權。

目前的程式可以看到幾個具體例子：

• 筆記卡片不為了配合圖片數量而複製。 首頁只讀取該語言可發布的文章，沒有文章時顯示空狀態；列表頁也只從實際文章建立 featured、一般列表和分頁。mockup 裡的示意卡片不能取代這個資料條件。
• 分類不為了視覺完整而擴充。 圖片裡可以畫出多個分類 chip，但目前內容 schema 和資料只支持已確認的分類。若沒有足夠內容和路由行為，新增分類只是把裝飾誤當成產品功能。
• 產品預覽不自動等於功能清單。 產品頁目前有日序的定位、狀態、說明和兩個已整理的方向；mockup 裡更細的畫面元素不能直接擴張產品範圍。
• 合作方向不自動等於成熟服務。 合作頁有介面與內容設計、網站與 Web 系統、AI 應用探索三個方向，但文案同時保留「AI 導入顧問仍是未來方向」的限制。視覺上有一列服務，不代表每一項都已經有固定方案或保證交付流程。
• 文章目錄不手抄圖片。 文章頁的目錄應該從正文實際 heading 產生，延伸閱讀也應該來自正式文章；mockup 裡畫出的目錄文字和卡片只是版面示意。

因此，遇到圖和程式或內容規則不一致時，不是把程式硬改得更像圖，而是先問：這個差異是尚未完成、尚未決定，還是圖片本來就只是方向稿？答案不同，後續處理也不同。

開工前可以先填這張 mockup 檢查卡

不需要把每張參考圖變成逐像素驗收表，但每個要落地的區塊至少可以先留下六個答案：

視覺意圖：這個區塊想讓讀者先看到什麼？
實作契約：它在頁面裡負責內容、導航、操作還是裝飾？
真實來源：文字、圖片、狀態與連結從哪裡來？
缺少時：沒有文章、圖片、翻譯或產品資料時要怎麼呈現？
不包含：圖中哪些細節不承諾、不公開或暫時不做？
驗證證據：要用 HTML、資料、鍵盤、窄螢幕或人工視覺確認哪一件事？

這張卡和一般的需求整理不完全相同。它特別處理 mockup 最容易造成的誤解：把樣本文字當正式內容，把示意畫面當 screenshot，把畫面上的服務名稱當產品承諾。先把這幾種身份分開，才知道哪些東西值得實作，哪些只需要留在討論階段。

這套方法能證明什麼，不能證明什麼

目前的 Astro 實作和文件可以支持幾個具體判斷：首頁、筆記、文章、產品和合作頁各自有實際元件與內容來源；正式筆記透過發布查詢進入公開頁面；產品與合作區的介面預覽可以由程式產生；文章目錄可以跟實際 heading 維持關係。

這些證據不能延伸成以下結論：

• mockup 已經是精確量測的設計稿。
• 正式頁面已經和圖片逐像素一致。
• 所有圖中出現的產品功能、服務範圍、文章和日期都已經存在。
• 目前的 RWD、閱讀舒適度、動畫節奏或視覺氣氛已經通過所有裝置的人工驗收。
• 這套頁面已經帶來搜尋、流量、合作或商業成果。

工程檢查可以驗證輸出、資料和行為的某些範圍；最後的視覺方向與公開內容，仍要由有決定權的人確認。mockup 最有用的地方，不是替大家提前做完決策，而是讓真正需要決策的地方更早被看見。

紀錄範圍

本文整理的是工作室改版參考圖和目前 Astro 頁面的差異判斷，重點放在視覺方向、實作契約、介面示意、真實截圖與假內容的邊界。本文不是完整的視覺設計教學，也沒有把尚未量測的 RWD、使用者研究、產品功能或服務成果寫成已確認事實。