從作品集到工作室官網：用途改變後，資訊架構也要改變

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

如果網站的主要工作從「展示做過什麼」變成「讓人理解正在做什麼、怎麼做，以及能不能一起做」，原本以作品為中心的導覽就不夠了。增加幾張卡片不會自動變成工作室官網；要先重新回答每個頁面替誰解決什麼問題。

這篇使用目前的頁面、路由與內容契約，整理這次資訊架構調整。主要判斷是：用途改變時，應先改頁面責任與入口順序，再補視覺和元件。作品仍然保留，但不再讓它承擔全部說明工作。

從單一展示入口改成多種閱讀入口

原本的作品集主要回答「做過哪些作品」。現在的網站還要回答幾個不同問題：這個網站在做什麼、有哪些實作方法、目前正在做哪個產品、合作可以從哪裡開始，以及作者的背景和完整作品在哪裡。

目前的路由分工如下：

路由	主要回答的問題	目前責任
/	這個網站現在要做什麼？	工作室定位、筆記入口、單一產品、合作方向與關於／聯絡入口
/notes	有哪些可以閱讀的方法與紀錄？	正式發布文章列表、分類資訊與沒有文章時的空狀態
/notes/[slug]	某一個主題的完整內容是什麼？	單篇文章、摘要、日期、標籤、正文與延伸閱讀
/products/daily-order	目前正在做的產品是什麼？	日序的定位、狀態、功能方向與產品入口
/services	如果想一起做，可以從哪裡談？	合作方向、可討論的問題與聯絡入口
/about	誰在做，以及累積了什麼？	真實背景、工作方式、經歷與實作入口
/about/work	實際做過哪些網站、系統與視覺作品？	作品集合與網站／系統、內容／視覺兩種內容切換

這份分工不是把每個名詞都做成一頁，而是讓一個問題有一個主要入口。作品可以在 /about/work 內被查看，產品則有自己的介紹頁；兩者都不必再負責解釋整個工作室的定位。

首頁不再只把人送到作品

目前首頁的閱讀順序已經不是先鋪滿作品卡片。它先用一句定位和簡短說明交代網站在做什麼，接著依序放入筆記、單一產品、合作方向，以及關於和聯絡。

這個順序有一個實際效果：讀者可以先理解「這裡提供什麼」，再決定要閱讀方法、查看正在打磨的產品、了解合作方式，或回頭看完整背景。首頁因此比較像分流頁，而不是作品牆的縮圖版。

首頁的筆記區也只取該語言最新最多三篇正式文章，並提供完整列表入口。沒有正式文章時，頁面顯示可讀的空狀態，不複製同一篇文章來填滿版面。這個規則看起來很小，卻直接限制了資訊架構不能靠假內容維持「看起來完整」。

同樣的取捨也出現在產品區。現在只有一個已確認名稱與入口的產品，所以導覽直接指向產品詳頁，沒有先做一個沒有第二個產品可列的 /products 總覽。

筆記是方法紀錄，不是作品卡片的延伸

作品卡片適合快速回答「這是什麼、可以去哪裡看」；筆記要處理的問題不同。它需要交代決策、做法、限制和驗證範圍，讓讀者理解一個結果怎麼形成，而不是只看到最後的畫面。

因此 /notes 和 /notes/[slug] 被當成獨立內容入口。列表只讀取已發布、日期已到的文章；單篇頁則負責正文、文章目錄、標籤、日期和延伸閱讀。草稿與未完成翻譯不會被當成正式文章連結，這讓「正在整理」和「可以公開閱讀」保持不同狀態。

這個區分也避免把作品頁寫成萬用說明頁。作品頁保留實際做過的範圍；需要解釋架構判斷、內容流程或驗證界線時，再交給筆記處理。兩種頁面都可以談實作，但讀者進入時期待的資訊深度不一樣。

作品沒有消失，只是不再是唯一答案

目前主導覽把筆記、產品、合作和關於放在主要位置，作品不再是唯一的第一層入口。這不代表作品被刪掉：/about 仍然提供通往實作與作品的入口，/about/work 保留完整作品內容；舊的 /work 也保留為可讀的相容網址，並指向新的 canonical 路由。

這裡有兩個不同的責任：

• 主導覽決定現在希望讀者先理解什麼。
• 相容路由負責讓既有連結仍然找得到原本的內容。

把兩者混在一起，常會得到一個看似「什麼都有」的導覽，卻沒有清楚的閱讀順序。保留舊網址不等於要讓舊資訊架構繼續佔據首頁和主導覽。

作品內容本身現在分成三個可切換的區塊：網站與系統類作品、內容與視覺類作品，以及獨立標示的 AIGC 角色視覺。前兩者描述的是做過的工作，AIGC 則明確標示為 AI 生成的角色視覺；它們都不直接冒充新的產品案例或完整 AI 專案。這條界線很重要，因為網站用途改變，不代表過去每件作品的背景都能被重新包裝成同一種故事。

產品與合作要有邊界，不能靠空頁補齊

「工作室官網」很容易讓網站看起來應該有產品總覽、服務方案、案例研究和完整聯絡流程。但目前的內容證據沒有支持全部都做出來，因此資訊架構刻意保留幾個空缺。

日序是目前唯一明確的產品入口，頁面也直接標示仍在持續打磨中。這可以讓網站介紹一個真實的產品實作，但不能推導出第二個產品、完整產品線或已經定案的功能範圍。

/services 也不是把合作內容包裝成固定方案。頁面描述的是一個正在形成中的合作方向，從釐清想法、把流程整理成工具，到和 AI 一起做出第一版。它提供討論起點，不保證每個專案都會走同一套流程，也不宣稱已經有成熟的服務產品。

這種不把空缺藏起來的做法，會讓頁面少一些「完整感」，卻比較接近目前能公開證明的狀態。資訊架構不是把預計會有的內容先畫出位置，而是先承認哪些內容真的存在。

多語網址也是資訊架構的一部分

這個網站保留繁中首頁，英文放在 /en，日文放在 /ja。同一組固定頁在不同語言下有對應網址，語言選擇、頁面 lang、metadata 和連結可以使用同一個網址來源判斷。

筆記則更嚴格：只有實際存在且完成的語言文章才產生文章網址。現在英文與日文筆記列表可以顯示誠實的空狀態，但不會因為繁中有文章，就自動生成假的翻譯頁或把讀者送回不相關的首頁。

這不是單純的翻譯規則，而是內容入口的規則。語言切換應該告訴讀者「這個內容在哪個語言存在」；如果內容不存在，空狀態比一個標示成已翻譯、實際卻不是同一篇文章的頁面更清楚。

這套架構解決什麼，沒有證明什麼

目前可以從路由、頁面元件、內容資料與靜態輸出檢查確認：

• 首頁、筆記、產品、合作、關於和作品各自有可辨識的頁面責任。
• /about/work 是主要作品路由，舊 /work 仍保留可讀相容入口。
• 多語固定頁使用對應語言路由；不存在的筆記翻譯不會被文章頁或 sitemap 冒充出來。
• 正式頁面有實際 HTML 內容，文章頁不是只有瀏覽器執行 JavaScript 後才出現的空殼。

這些證據能支持「目前的資訊架構已經被實作並且有工程檢查」，不能支持以下結論：

• 沒有使用者研究或分析資料，所以不能說這個順序一定比舊網站更容易理解。
• 沒有 SEO 排名、流量、轉換或合作結果資料，所以不能宣稱資訊架構帶來商業成效。
• 完整 RWD、動畫節奏與閱讀舒適度仍需要實際的使用者視覺驗收，不能用 build 通過代替。
• 產品和合作文案仍受目前公開範圍限制，不能從頁面示意推導出尚未確認的功能或服務。

下一次整理網站時，我會先檢查這些事

1. 先寫出網站現在要完成的主要任務，不先列想加的頁面。
2. 把讀者會反覆問的問題列出來，為每個問題指定一個主要入口。
3. 讓首頁負責分流，不把所有內容都壓成作品卡片。
4. 只有在內容、功能和公開範圍都成立時，才新增產品、分類或案例頁。
5. 舊網址需要保留時，分開處理相容性與主導覽，不讓歷史路由決定新的閱讀順序。
6. 最後才把頁面責任交給元件、樣式和動畫，並分別檢查輸出、互動與主觀閱讀感受。

對目前這個網站來說，從作品集走向工作室官網，不是多放一個「筆記」連結，也不是把首頁改成更大的作品牆。真正的變化是把定位、方法、產品、合作、背景和作品分成不同責任，並且對尚未存在的內容保留空白。只有這樣，新增頁面才是在補資訊架構，而不是在補版面。

紀錄範圍

本文整理的是目前 repository 中已實作的頁面、路由、內容查詢與工作室網站開發規格。文中把頁面責任和公開邊界寫成讀者可以理解的判斷，沒有把 mockup、規劃中的功能、未完成翻譯、視覺驗收或搜尋成果寫成已完成的產品事實。