Landing Page Craft 是做什麼的？

這份文件記錄了 Favour 實際建立不流於模板的登陸頁面的方法，這些經驗是從他過去建立 Allowance、didii、Revolut Founder Mode、TrashPay 和 FlutterBytes 會議網站的對話中提煉出來，並透過他對使用此技能進行的測試建置所提供的直接回饋，反覆修正而成。這不是一份通用的「登陸頁面最佳實踐」指南——它具體說明了 Favour 持續追求、修正方向以及拒絕接受的事物。它也是一份不斷演進的文件：在開始之前請先查閱 references/build-log.md，並在完成後將經驗新增至此。

每次的目標：創造出具有真正觀點的東西，而不是一個只換上客戶名稱的稱職模板。而且關鍵是：一個看起來直覺且刻意為之的概念，而不是一個需要解釋才能懂的概念。

在開始之前：現有資訊是否足夠？

如果簡報沒有提供一個可以用來連結概念的實際產品——沒有名稱、沒有目標受眾的線索、沒有調性提示、沒有任何能將它與該想法的通用版本區分開來的東西——請停下來詢問。一兩個精準的問題，勝過憑空想像一個方向，然後發現它不適用。

還有兩個更需要詢問而非假設的具體時刻：

如果某個區塊明顯需要真實照片（而非抽象或向量圖形），請在繼續之前要求提供。如果無法取得，請明確說明，並改用漸層和線條來即興發揮，而不是偽造圖庫照片。
如果某個區塊需要代表性的範例內容（範例名稱、範例卡片、佔位資料），請先提出一個版本，並明確邀請對方提出修改意見，而不是默默地完成你自己的猜測。

如果有足夠的資訊——一個真實的名稱、真實的受眾、一個真實的差異點，即使只是粗略的——再繼續進行。

建置技術棧

預設目標是 Next.js、TypeScript、Tailwind CSS 和 Framer Motion。這是此技能所依據的每個專案實際使用的技術棧。絕不交付純 HTML 或 vanilla JS。

如果工作環境無法即時渲染該技術棧，請明確說出，而不是默默地用較弱的方案替代。仍然要建立真正的 React 組件，絕不使用 vanilla JS，並為預覽效果使用 CSS 轉場或 Web Animations API 來近似預期的動畫——但也應提供真正的 Next.js/TypeScript/Framer Motion 程式碼庫作為可下載檔案。並明確指出，如果一個能夠真正執行並擷取該技術棧快照的環境（例如 Claude Code）才是此任務的歸屬，尤其是在對輸出的實際視覺判斷比快速瀏覽更重要時。

表單一律提交到 Google 表單

網站上的任何表單——等候名單、聯絡、諮詢、申請演講、預訂/報名等——都是一個採用網站自身設計風格的品牌化自訂表單，其提交內容透過該 Google 表單的預填連結，在幕後轉發至 Google 表單。訪客永遠不會看到原始的 Google 表單；他們看到的是網站的樣式，而資料則會落入 Google 表單的回應（及其連結的回應試算表）中。

請儘早提出此需求，一旦確定網站需要表單就立刻提出——這就像照片一樣，是依賴於委託人的事項。請要求他們建立一個欄位與網站表單內容相符的 Google 表單，並提供其預填連結。然後將每個網站欄位對應到從該預填連結中解析出的相應 Google 表單條目 ID，並在表單的提交處理程式中提交到該連結（標準做法是向表單的 /formResponse 端點發送一個帶有 entry.<id> 參數的 POST 請求，或等效方法）。如果委託人尚未提供連結，請完整建立品牌化的表單 UI，但明確地暫留提交目標並標記為待辦，而不是憑空發明一個端點。

請務必提供步驟給委託人，說明如何取得 Google 表單的預填連結，因為大多數人不知道它在哪裡：

在編輯模式下開啟 Google 表單。
點擊右上角的三點 ⋮ 溢出選單。
選擇 「取得預填連結」。
為每個欄位填入一個可識別的佔位值（例如，在欄位中輸入該欄位本身的名稱），然後點擊底部的 「取得連結」。
點擊彈出視窗中的 「複製連結」 並將連結提供給你。

該連結包含每個欄位的 entry.<id>，這正是將品牌化表單的欄位對應到 Google 表單所需的資訊。

字體與色彩，與委託人共同選擇，而非獨自決定

在確定任何一個之前，先進行一次簡短的視覺確認，而不是默默決定：

字體： 查看 references/typeface-library.md，尋找近期未過度使用的候選字體。然後提出三個獨特、非顯而易見的顯示字體候選方案，並實際用每種字體渲染出產品名稱，以環境支援的任何方式呈現（圖片、快速預覽、即時組件）——永遠不要只列出字體名稱。讓委託人從實際的字形中選擇，而不是根據對字體名稱印象的猜測。字體庫之外的全新字體也是很受歡迎的選項——如果被選中，之後請將它新增至 references/typeface-library.md。絕不能跳過這個提案與確認步驟——即使有很明顯的強烈建議，或已經要使用字體庫中的字體，仍然要展示候選方案並確認，而不是默默決定。
色彩與主題： 提出一個調色盤（4–6 個命名值），並說明每個選擇背後的理由，且理由需基於主題。在此有意識地決定淺色或深色主題，而不是預設使用深色（請參閱 references/taste-rules.md 中的主題規則——許多品牌使用淺色主題效果更好）。在最終確定兩者之前，請先確認。
風格方向： 除字體和色彩外，從 references/section-bank.md 中命名的風格系列（極光/柔和光暈、霓虹光芒黑暗科技、乾淨科技有機、編輯/野獸派、極簡高調、奢華/高級展示、企業 B2B/金融科技）中，為整個頁面選擇一個主要的風格系列——選擇必須基於簡報的特定原因，而不是出於習慣。這是之後從區塊庫中選取素材的範圍；從外部借用是刻意的點綴，而非預設行為。

到目前為止，兩個測試建置都跳過了這個步驟，並獨自決定了這兩者——結果兩次都僥倖成功，但這是運氣，不是流程按預期運作。

先決定網站類型

在開始其他工作之前，先確定這個網站屬於七種形狀中的哪一種——下面的品味規則和框架適用於所有類型，但區塊庫存，以及對於企業、歐洲和微型企業類型，其視覺方法會有所不同：

產品登陸頁面（Allowance、didii、TrashPay）——專注於等候名單或下載、定價、使用案例、功能網格。
作品集 / 案例研究頁面（Revolut Founder Mode）——設計師自身的概念提案：個人簡介區塊、證明作品相關性的真實數據、「聯絡我們」而非等候名單。
活動 / 會議頁面（FlutterBytes）——演講者展示、歷屆活動記錄、組織團隊致謝、贊助商、議程。
企業頁面（一個時尚品牌、一家麵包店、一間沙龍、一個工作室——一個已存在的真實世界企業，而非新創公司）——銷售已存在的實際產品或服務，因此傾向於圖像豐富和氛圍優先，而非功能網格優先。目標是大約 75% 的區塊應圍繞真實攝影（菜單/型錄/畫廊/空間）建構，並將簽名動作和動畫規則疊加在圖像之上，而非取代圖像。
混合型——上述兩到三種的刻意組合（一個同時也在推廣活動的產品，或一個擁有過去作品作品集的企業）。選擇主導類型來決定整體結構和間距，然後借用次要類型所需的特定區塊。
歐洲風格網站——模仿高端歐洲工作室/Framer 模板作品風格的乾淨、內斂、高級感網站。與其他類型基礎相同，但英雄區塊刻意簡潔：將一張或多張合適的真實照片（從 Unsplash、Pexels 或 Pixabay 獲取並下載）設定為英雄背景，置入一個約 98% 寬度的圓角矩形框架內，上方不疊加繁複的簽名視覺元素。無等候名單。簡潔，但不無聊。
微型企業登陸頁面——一個緊湊、高階的一頁式網站，正好四個區塊（英雄、服務方案、證明、聯絡），旨在為尚未擁有網路形象的、通常是傳統的企業（機械經銷商、大宗出口商、製造商、工業供應商、批發商）進行提案。這個頁面必須足夠有說服力，讓一個沒有網站的企業相信擁有網站是值得的，因此它重度依賴高品質的真實攝影、真實的信號（數據、客戶標誌、認證），以及一個自信且多變的英雄區塊——請參閱 references/site-types.md 了解五種英雄迭代輪換方式和強制性的「聯絡我們」區塊。

請閱讀 references/site-types.md，了解每種網站的區塊庫存和結構說明。如果它真的不屬於這些類別中的任何一種，則將其視為最接近的產品登陸頁面並進行調整。

流程

取得方向。 品牌名稱、其功能、目標受眾、任何參考網站或提到的氛圍。如果確定網站將需要表單（等候名單、聯絡、諮詢、訂單），請立即根據上面的表單章節提出 Google 表單的依賴需求——要求委託人建立 Google 表單並提供其預填連結，這樣就不會在最後階段手忙腳亂。
在觸碰任何區塊之前，先找到一個核心概念。 不是功能列表——而是使用者從此產品實際獲得或感受到的單一事物，用一句簡單的話陳述，再加上兩個或三個支援性想法。之後，每個區塊的簽名動作都會根據這個概念進行檢查。同時，直接詢問委託人他們是否已經有想要納入或說明的概念、視覺效果或想法——特別是英雄區塊——這樣他們自己的願景就能餵養這個概念，而不是被一個憑空發想的概念所覆蓋。
與委託人共同選擇字體和色彩（見上文），基於主題，而非獨自決定。
決定網站類型（見上文）並瀏覽其區塊庫存。檢查 references/build-log.md，了解近期專案使用了什麼，這樣這個專案就不會意外地與上一個相似。
並排地，對每個區塊執行以下接收檢查表，然後在編寫任何版面或程式碼之前誠實地評分。

每個區塊的接收檢查：
- 這個區塊是什麼？它應該獲得多少視覺份量？英雄區塊理應獲得比信任簡介更多的份量。
- 產品大致關於什麼？這個區塊根據其實際標題、副標題和內容具體關於什麼——而不是根據其類別的通用標籤？
- 基於該內容，應該有什麼樣的概念？請查閱 references/concept-gallery.md 尋找已發明過的概念——重複使用一個尚未降溫的概念、改編一個，或發明全新的概念並在之後將其新增。
- 區塊設計庫提供了什麼？從 references/section-bank.md 中挑選兩到三個候選列（先按區塊類別匹配，再按專案的風格方向匹配），並將其與從零開始發想的選項進行比較，然後根據該庫的「改編而非移植」規則選出勝出者——該列的調色盤、字體和像素規格會重新對應到此專案，且該區塊仍需為此特定品牌通過兩秒測試。
- 什麼動畫或懸停互動能讓它栩栩如生？該庫的動畫欄是一個可從中汲取的詞彙庫（虛線偏移繪製、里程表計數、flex-grow 展開、交錯進入、遮罩揭示）——但仍需確保一個頁面上絕不重複使用相同的原始動畫。
- 標題和副標題有多長？短的標題可以採用居中/環繞處理（參閱 references/taste-rules.md 中的佈局原型）；長的則不行。
- 前一個區塊使用了什麼佈局和簽名動作？上一個專案使用了什麼？不要重複任何一個。
誠實評分，使用可驗證的檢查而非舒適的評分：
- 這個概念是否落入了三個通用 AI 設計預設值之一（暖奶油色 + 襯線字體 + 赤陶色、近乎黑色 + 一個酸性強調色、或對開/細線新聞報紙風格），而沒有特定於簡報的理由？如果是，那就是失敗——回到接收檢查。
- 如果對一個完全不同的產品執行相同的提示，這個確切的選擇是否會出現？如果是，那它還不夠具體。
- 一個陌生人能否在大約兩秒鐘內、沒有任何說明的情況下，理解它所代表的東西？一個只有在解釋後才有效的概念，無論其推理多麼巧妙，都是失敗的。
評分是一項始終執行的紀律，而不是需要展示的東西——委託人看到的是最終的概念和明確的結果，而不是計分板。並且要誠實面對真正的限制：如果無法實際看到渲染結果，自我評分更接近於仔細的程式碼審查，而非真正的視覺判斷，因此要傾向於懷疑而非寬容。如果環境能夠實際執行並擷取建置的快照，請利用這一點——實際查看勝過預測。
建立完整的初稿，使用評分過的概念以及 references/taste-rules.md 中的既定規則。
逐個區塊進行品質檢查，針對已建置的頁面。對於每個區塊，詢問：
- 這個區塊是否明顯與步驟 2 的核心概念相關聯，還是它只是孤立地說明自身功能？
- 任何雙欄區塊的非文字側是否真正「活躍」——一個動畫化的迷你介面、螢幕片段或自成一體的概念——或者它是一個死氣沉沉的平面圖像？不是問「這是雙欄嗎」，而是問「這裡有什麼是靜態的、但不應該是的嗎」？
- 這裡是否使用了一個樸素的邊框卡片，而一個淡化的分隔線或更經過設計的東西可能效果更好？整個頁面是否總共只使用一到兩個包含卡片的區塊？如果它是一個卡片，它是否有真正的客製化巧思（光澤漸層填充、玻璃般邊框、動畫圖示）和真正的懸停互動？
- 所有圖示是否都來自所選的自訂圖示庫（Lucide/Phosphor/Heroicons/Tabler），頁面上是否有任何 emoji 作為替代？
...

（此處為截斷的內容，原文後續還有更多詳細規則）

Landing Page Craft