Poise 已經有一個能工作的 light-marmite：它可以讀取 Markdown、生成文章與彙整頁，並把純靜態成品交給 Cloudflare。既然功能已經能用，為什麼還要研究另一個生成器 Bamboo？

原因不是為了追逐新工具，而是要確認目前的設計是否走在正確方向。當一個專案刻意把 JavaScript、圖片、資料庫與執行時服務全部拿掉之後，生成器本身就成了最重要的核心。它必須夠小，也必須讓未來的維護者看得懂。

先問清楚真正要替換的是什麼

最初的問題看起來很直接：能不能用 Bamboo 取代 light-marmite，同時維持既有的寫作、Skill 與部署方式？

研究後，我們把問題拆成三層：

  1. 作者仍然只需要撰寫 Markdown，並用白話要求 AI 建立草稿或發布文章。
  2. GitHub Actions 仍然負責驗證、建置與部署，不改變 Cloudflare 的公開網址。
  3. 只有最底層的網站生成器可以替換，公開網站的零 JavaScript、零內容圖片與零第三方請求規格不能退讓。

這個拆解很重要。使用者真正依賴的不是某個生成器名稱，而是一條穩定的發布流程。只要輸入格式、輸出結構與部署命令保持一致，底層實作就能獨立演進。

從 Bamboo 借走架構，而不是套件

Bamboo 最值得參考的地方，是把工作分成清楚的階段：先讀取內容，再建立可排序、可連結的站點模型，最後渲染成檔案。這比讓解析 Markdown、組合導覽與寫入 HTML 全部纏在同一個流程裡，更容易理解與測試。

這個分層也正好符合 Poise 的需求：

  • 內容層負責 frontmatter、文章日期、序號、標籤與純文字政策。
  • 模型層負責排序、分頁、前後篇、反向連結與內部連結檢查。
  • 輸出層負責 HTML、RSS、sitemap、CSS 與 favicon.ico。

然而，直接採用 Bamboo 也代表使用者必須取得另一個第三方程式，專案則要追蹤版本、安裝方式、設定格式與上游輸出變化。即使公開網站仍然很輕，建置鏈也不再完全屬於 Poise。

決策標準比功能數量重要

這次評估沒有用「誰支援的功能比較多」決定勝負。Poise 需要的功能範圍早已被刻意限制：文章、靜態頁、標籤、彙整、RSS、sitemap、分頁、導覽與內部連結。搜尋、圖片處理、主題市集與外掛系統反而會擴大不必要的邊界。

最後採用的標準很簡單：

問題Poise 的答案
使用者是否需要另外安裝工具？不需要
建置是否能在只有 Python 3 的環境執行？可以
生成器是否能和網站規格一起版控？可以
公開輸出是否仍只有允許的靜態檔案？必須
原本的 Skill、建置與部署方式是否改變？不改變

因此，結論不是「選 Bamboo」或「保留原狀」，而是第三條路：保留 Bamboo 啟發的分層方式，重新寫成 Poise 自己擁有的單檔 Python 生成器。

從工具名稱回到產品名稱

這個決定也讓 light-marmite 這個過渡名稱完成了任務。它曾經清楚表達「更小的 Marmite」，但新核心已不再是任何第三方工具的縮小版。它只服務 Poise 的內容模型、安全規格與發布流程，因此最誠實的名稱就是 poise。

這次研究最後帶來的不是更多依賴，而是更清楚的邊界：可以學習成熟專案的結構，卻不必連同整套工具鏈一起搬進來。對 Poise 而言，輕量不只是訪客下載得少，也包括作者不必安裝、維護者不必猜測、部署環境不必臨時取得任何東西。