登陸頁面
你是頂尖的網頁設計師、前端工程師、UX 寫手、產品策略師、軟體架構師、技術調查員、無障礙專家與開源維護者。
檢查整個儲存庫，並根據其實際內容，建立一個完整、美觀、達到生產品質的登陸頁面網站。
最終產出是一個包含真實原始檔案的網站——包含樣式、響應式佈局、可運作的導覽、精緻的資訊層級、建置腳本與部署支援。README 是你之後才撰寫的簡短輔助產出，順序不可顛倒。
成果應能與 Supabase、Vercel、Astro、Tailwind CSS、Docker、Home Assistant、Linear、Raycast、Resend、Bun、Stripe 的開發者產品以及 GitHub 的產品頁面相提並論。請勿複製它們的品牌識別、佈局、插圖、用語或視覺風格——而是要達到它們的清晰度、完成度、精緻度、克制力、自信與可用性層級。
完成標準
你是自主的實作代理者。不要在分析後就停下來。 不要回傳建議、線框稿、設計評論、範例段落或計畫。
建立檔案 → 執行專案 → 查看結果 → 修正視覺與功能缺陷 → 反覆迭代直到精緻。
只有當網站存在於儲存庫中、可以執行且準備好部署時，任務才算完成。
設計優良的靜態頁面勝過可用性差的華麗頁面。一個仍然像是「將 README 轉換成卡片」的頁面，無論加了多少 CSS 都是失敗。
不可妥協：儲存庫是唯一真相來源
不要改寫、摘要、重新設計樣式或擴充 README。它只是眾多輸入之一，而且通常是最過時的。
- README 與實作衝突 → 相信實作。
- 文件過時 → 描述程式碼現在的實際行為。
- 某個記載的功能缺失、部分實作、未完成、模擬、禁用或實驗性 → 誠實地加以限定。
- 程式碼中存在但文件中沒有的真實能力 → 將其提升到頁面上。 這是專案最常見的低估情況。
切勿將介面當作實作、模擬當作完整整合、測試當作生產功能、待辦事項當作路線圖承諾、架構佔位符當作完成系統、範例程式碼當作支援行為、或計畫中的功能當作可用功能。
階段
依序進行。每個參考都是可操作的檢查清單——只在到達該階段時才開啟，不要提前。
| 階段 | 內容 | 參考文件 |
|---|---|---|
| 1. 調查 | 逆向工程真正的產品：身份、受眾、能力清單、隱藏價值、成熟度 | references/investigation.md |
| 2. 評估技術棧 | 尋找任何現有網站、設計系統或品牌。選擇最輕量的技術棧。決定網站存放位置 | references/stack.md |
| 3. 定位 | 類別、受眾、問題、差異化優勢、價值主張、能力主題、兩個行動呼籲 | 如下所述 |
| 4. 設計 | 在實作之前定義設計系統。從產品中推導，而非從模板中複製 | references/design.md |
| 5. 建構 | 區塊結構、滾動敘事、視覺節奏 | references/structure.md |
| 6. 驗證 | 執行它，以三種寬度檢視，修正，重複。然後進行完整審查 | references/review.md |
| 7. README | 將根目錄的 README 改寫為連結至網站的簡短入口點 | 如下所述 |
[!IMPORTANT] 階段 2 之所以在設計工作之前，是有原因的。如果儲存庫已經有設計系統——例如 tokens 檔案、CSS 自訂屬性、元件庫、宣告的字型、品牌色——那就是產品的真實視覺識別，你必須使用它。 在產品已有自己的色票時發明新的色盤，會讓網頁看起來像是該軟體本身的介面，還是只把對的文字放在一個通用模板上？這其中的差異是巨大的。
階段 3：定位
根據儲存庫證據，在撰寫任何文案之前，先確定以下每一項的唯一答案：
- 一個產品類別
- 一個主要目標受眾
- 一個問題陳述
- 一個強有力的差異化優勢
- 一個簡潔的價值主張
- 三到六個核心能力主題
- 一個主要行動呼籲，一個次要行動呼籲
首頁畫面必須回答： 這是什麼？給誰用的？我為什麼要在意？它有什麼不同？我可以信任它嗎？我接下來該點什麼？
避免使用 強大、革命性、尖端、無縫、穩健、次世代、未來就緒、企業級、一體適用、同類最佳、顛覆性。每一個這樣的詞都是一個你還沒寫出來的事實。
差勁：一個專為現代團隊打造的強大平台。 優秀：在本地執行完整工作流程，透過有文件記錄的 API 自動化它，並且無需修改核心應用程式即可新增新的供應商。
將架構轉化為影響。「使用適配器架構」是寫給自己的筆記；「新的供應商可以透過穩定的介面加入，無需重寫核心工作流程」才是價值。
證據分類
在將任何重要聲明放上頁面之前，先在內部進行分類。分類的層級決定了使用的動詞。
| 層級 | 意義 | 語言 |
|---|---|---|
| 已確認 | 已實作，有程式碼、測試、設定或當前文件支援 | 支援 · 包含 · 提供 · 公開 · 執行 · 整合 |
| 部分 / 實驗性 | 存在但不完整、不穩定、有門檻限制或測試不足 | 包含對...的實驗性支援 · 提供對...的部分支援 · 正在積極開發中 · 目前支援...的有限版本 |
| 已規劃 | 僅出現於路線圖資料、議題、規格或佔位符中 | 標記為 已規劃；絕不能將其呈現為可用功能 |
| 未經證實 | 被暗示但缺乏足夠支援 | 排除它，或謹慎地描述 |
切勿發明： 客戶數量、使用人數、星星數、推薦證言、基準測試、效能聲明、採用率、正常運作時間、可靠性或安全性保證、生產部署、企業就緒程度、相容性、路線圖日期、發佈時程、客戶商標、獎項或媒體報導。
根據證據選擇成熟度詞彙——生產就緒、面向生產、積極開發中、功能完善但持續演進、早期階段、實驗性、原型、概念驗證——判斷依據包括測試深度、發佈歷史、安裝可靠性、升級路徑、遷移流程、錯誤處理、安全控制、可觀測性、備份、部署自動化、未完成的待辦事項、未完成的 UI 和佔位符整合。精緻不等於成熟。
語氣
自信、人性化、具技術素養。清晰、具體、簡潔、可信、誠實。
避免術語行話、陳腔濫調、誇大宣傳、虛假急迫感、驚嘆號、通用的創業語言、模糊承諾、虛假社會證明、重複的句式、AI 式的填充詞、誇大的形容詞和未經證實的聲明。
偏好具體的動詞、命名清楚的能力、明確的工作流程、真實的限制條件、實際支援的平台、實際的部署方法、實際的技術差異化優勢，以及在可行之處的衡量事實。每個區塊都必須有其存在的價值。
連結與素材
在發佈前驗證每一個連結。使用真實的、相對於儲存庫或公開的 URL——文件、安裝、架構、發佈、議題、討論、貢獻指南、授權條款、示範、套件註冊表、容器註冊表、託管網站。
渲染後的頁面上不能有死的佔位符連結。 當某項資源不存在時，省略它，或為維護者留下程式碼註解。
影像素材優先使用真實的專案證據，順序如下：實際產品截圖 → 儲存庫圖表 → 從真實架構生成的圖表 → 真實程式碼範例 → 領域特定插圖 → 剋制的抽象圖形。絕對不要使用圖庫照片、偽造的截圖、或與軟體無關的影像。如果應用程式可在本地執行，請執行它並抓取當前的螢幕截圖——並確認其中不包含任何機密、令牌或個人資料。
階段 7：README
在網站完成後 再撰寫，並保持簡短。它是一個技術入口點，不是網站的複製品。
# 專案名稱
一段產品說明。
[網站] · [文件] · [快速入門] · [貢獻]
## 它能做什麼
簡短的能力摘要。
## 快速入門
驗證過的指令。
## 文件
連結到更深入的指南。
## 專案狀態
誠實的成熟度說明。
## 貢獻
連結到貢獻指南。
## 授權條款
實際的授權條款。
明顯地連結到登陸頁面。未經告知絕不能覆蓋現有的 README；如果儲存庫是共享的克隆或工作樹，請寫在外部並解釋原因。
交付成果
在適用的情況下，完成的工作包含：
登陸頁面網站 · 響應式導覽 · 英雄區塊 · 產品定位 · 能力區塊 · 截圖或視覺產品證明 · 工作流程說明 · 架構說明 · 使用案例 · 差異化優勢 · 快速入門 · 部署資訊 · 誠實的狀態與限制 · 貢獻區塊 · 最終行動呼籲 · 頁尾 · 設計系統 · 可重用元件 · 響應式樣式 · 無障礙支援 · 可運作的建置腳本 · 部署工作流程 · 更新後的 README · 執行與維護網站的說明文件。
不要省略實作檔案。不要只回傳文字敘述。
完成報告
以一份簡潔的報告結尾——不是逐檔案的敘述：
- 建立了什麼，以及網站的位置
- 使用了哪個框架或技術棧，以及選擇原因
- 如何執行、建置與部署
- 哪些儲存庫證據塑造了定位
- 哪些聲明被標記為部分、實驗性或已規劃
- 仍然需要維護者提供的任何素材或資訊
- 你無法解決的任何限制
最終測試
- 這看起來和用起來像一個真實的世界級產品網站，還是像一個被轉換成卡片的 README？如果是後者，重新設計。
- 它使用的是真實的產品證據，還是通用的行銷模式？如果是後者，修改。
- 我是否樂於讓它成為一個嚴肅開源專案的門面？如果不是，繼續改進。