Astromer 的開發實作：從設計系統到內容編輯器的產品化路徑

如果只把 Astromer 看成一套 UI 元件庫，很容易低估它的角色。對我來說，Astromer 真正要解決的不是「再做一批按鈕、表單、Dialog」，而是把設計 token、互動模式、內容區塊與前端落地方式整理成一條可以持續演進的產品線。這也是我另外設定 `astromer.hedula.dev` 網域的原因：它不是單一 demo，而是 Astromer 對外被理解、驗證與持續整理的入口。

Astromer 的開發起點，不是先畫出一套漂亮元件，而是先界定哪些東西應該穩定、哪些東西應該留給產品自行決定。穩定的部分包括 token、基本互動元件、版型與內容區塊的 schema；變動的部分則是品牌語氣、內容策略、權限流程、資料來源與每個產品自己的 UI 排布。這樣切分之後，Astromer 才不會變成一個過度耦合、只能服務單一網站的前端專案。

在實作層面，Astromer 採取的是「系統先於頁面」的做法。也就是先建立可重複使用的基礎能力，再讓頁面去組合，而不是每做一頁就手工拚一次版。這個順序很重要，因為一旦內容平台、行銷網站、產品後台都要共用同一套設計語言時，真正的成本不是第一個頁面做出來有多快，而是第三個、第五個、第二十個畫面是否還能維持一致。

我目前把 Astromer 放在三個層次來開發。第一層是 design tokens，負責顏色、間距、字體、圓角、陰影等基礎節奏，讓不同專案可以共享視覺規則。第二層是互動與版型能力，像是 section、stack、rich text、media、dialog 這些能被多個畫面重複使用的結構。第三層才是產品 block，也就是真正帶有業務語意的內容模組，例如文章標題、相關連結、CTA、媒體說明，或是未來更細的資料展示區塊。

這種分層的另一個好處，是讓編輯器與前端渲染可以共享同一份契約。當內容編輯器儲存的是結構化的 PageDocument，而不是隨意拼接的 HTML，公開頁、預覽頁與後續的 AI 工作流就能建立在同一個資料模型上。Astromer 在這裡不只是視覺層，它也是內容模型可以被穩定渲染的基礎。這對內容平台尤其重要，因為真正難維護的通常不是一篇文章，而是「每一篇文章都必須在不同頁面、不同流程、不同裝置下可預期地呈現」。

技術選擇上，我傾向讓 Astromer 站在現代瀏覽器能力之上，而不是先用大量框架封裝把問題藏起來。像是 Popover API、Anchor Positioning、beforeinput、Clipboard API 這些能力，已經讓很多過去必須靠大型客製邏輯處理的互動，可以更接近平台原生做法。這不是為了追求新技術，而是因為只要底層能力越接近平台，元件的可解釋性、可維護性與可測試性通常就越高。

當然，Astromer 也不是把所有事情都包進自己。產品真正困難的部分，往往不在按鈕怎麼長，而在資料權限、發布流程、快取策略、媒體管線、社群發佈與跨站隔離。這些我會刻意留在外層產品架構處理，讓 Astromer 維持清楚邊界。換句話說，Astromer 負責「怎麼穩定地表現內容與互動」，但不假裝自己同時負責所有產品後端決策。

目前 `astromer.hedula.dev` 的價值，也正是在這個邊界上。它可以作為對外說明 Astromer 的窗口，讓設計系統、元件能力、內容區塊與實作方向有一個獨立入口；同時又不必把每個實際使用它的產品專案綁死在同一套敘事上。這樣一來，Astromer 既能保有產品化的清晰度，也能繼續在不同 consumer 專案裡被驗證。

如果要用一句話總結 Astromer 的開發方向，我會說：它不是為了展示元件而存在，而是為了讓設計系統、內容模型與產品實作之間的交界變得更穩定。當這件事成立之後，無論是內容網站、Studio、互動流程，或未來接入更多 AI 與協作能力，整體系統都會有一個更可靠的前端基礎。