在 Claude Code 中建立著陸頁

一個可在 Claude Code 中建立、發布和改善行銷頁面的實用設定。有五件事完成了大部分工作：儲存庫、託管服務、品牌工具包、效能和漏斗資料。 掌握這些，其他一切就只是反覆迭代。

在發布前檢視頁面的兩種方式（第 4 節）：一個供你和 Claude 使用的本機開發伺服器，以及供非技術人員使用的 Claude Design。如果你使用 Design，請先閱讀第 4 節的嚴格規則——那裡沒有復原功能。

主線：工作不會在部署時結束。 一個上線但未追蹤的頁面，是無法改善的頁面。

操作順序

請依序執行。每一步會讓下一步更加容易。

先建立儲存庫 — 在任何程式碼之前。版本控制是所有其他操作的復原按鈕。
第二步設定託管和部署管道 — 當網站還很簡單且壞掉的部署無關緊要時。
第三步建立品牌工具包 — 在寫任何文案之前，讓第一版草稿就已經符合品牌調性。
建立頁面 — 先做視覺/靜態部分，再來是互動功能，最後才是追蹤。
第一天就發布最簡追蹤功能 — 然後根據真實資料最佳化速度和文案。

1. 使用儲存庫（GitHub 或同等服務）

如果你已經在使用 Claude Code，這點不言而喻。如果你只是剛入門，這是一個暖身：儲存庫能提供版本控制、雲端備份，以及——最重要的是——部署策略。

main 分支是正式環境，任何內容只能透過你合併的 Pull Request 進入。將此規則明確寫入 CLAUDE.md — 請參閱 starters/CLAUDE.md。

循環流程

這是整個週期。每一項工作，無論多小，都執行此流程。

同意版本號碼。 Claude 建議一個，你同意它——或者你直接指定你要的版本。無論哪種方式，版本號碼在任何工作開始之前就確定，而且決定權在你，不在 Claude。
Claude 建立分支 — git checkout -b v1.03。
你在分支中進行工作。 Commit 只提交到這個分支。
Claude 將分支推送到 GitHub。
Claude 開啟 Pull Request。
你在 GitHub 上審查並核准它，然後你合併它。 這就是部署。這是唯一會變更正式環境的時刻，而且始終是人為決定。
git checkout main 然後 git pull。 不要跳過此步驟。你本機的 main 現在正好落後一個 merge，從過期的 main 開始下一個分支是導致分支分歧、幽靈衝突以及 git pull 拒絕快轉的原因。
重複步驟 1，並使用下一個版本號碼。

Claude 提出，你決定，Claude 執行。 版本號碼、合併和部署是你的；建立分支、推送和發起 PR 是 Claude 的。如果某個呼叫不明確，Claude 會詢問。

有效的版本命名： v1.0x 用於修補（文案、設定、小修正），v1.x 用於次要工作（新頁面、新功能），v2.x 用於重新設計。

兩個值得保留的審查關卡：

在合併前審查整個分支的 diff，而不僅僅是每個 commit。 單獨看沒問題的 commit 組合起來可能變成一個真正的錯誤。對「從分支點開始的所有內容」進行一次完整閱讀——最好由第二位審查者或一個全新的 Agent 來做——可以捕捉到按任務審查結構上無法發現的問題。
在任何會收集使用者資料的部署前，執行安全性審查。 對一個處理表單的分支進行一次審查，就曾捕捉到一個真實的漏洞，其中一個原始的物件展開讓訪客可以為伺服器管理的欄位提交值。將其視為一項關卡，而不是一個可有可無的選項。

2. 託管在具有真實部署管道的地方

AWS Amplify 效果很好：免費方案涵蓋低流量著陸頁，超出部分費用也不高。請查看當前條款——AWS 在 2025 年重組了其免費方案。Netlify、Vercel 和 Cloudflare Pages 提供類似的功能。

真正的好處是部署路徑：合併一個 PR，網站就會重建並上線。

將儲存庫連接到託管服務是人們經常卡住的步驟，而這只是一個點擊路徑，不是設定檔：在託管服務的主控台中，建立一個新的 Web 應用程式 → 授權它連接到你的 GitHub 帳戶 → 選擇儲存庫和 main 分支 → 它會偵測你的建置規格 → 第一次部署執行。之後，每次推送到該分支時，它都會重建。請在網站還只是一個簡單的「hello」頁面時執行此操作，這樣一個壞掉的管道對你來說不花任何成本來除錯。

第一天就設定好，趁它還便宜的時候：

從 main 自動部署。
具有 HTTPS 的自訂網域。
帳單警示。 你剛剛將信用卡資訊與一個雲端帳戶綁定。設定一個在你覺得金額會讓你驚訝的數字時發出預算警示——只需兩分鐘，它能將一個低機率的糟糕驚喜轉變為一封電子郵件。
安全標頭——靜態主機預設不帶任何安全標頭。
對內容雜湊的建置資源設定長快取的 Cache-Control。簡單、永久，否則因為它永遠不會阻塞任何事情而無限期推遲。

網域和 DNS，這裡的陷阱是可預測的：

裸域不能使用 CNAME — www.example.com 可以，example.com 不行。你需要你的 DNS 提供商提供的 ALIAS/ANAME 記錄，或主機自己的頂層（apex）選項。及早決定你的標準 URL 是否有 www，並將另一個重新導向到它。
HTTPS 憑證需要 DNS 記錄來驗證，並且在該記錄解析之前不會頒發。在認定 DNS 變更有問題之前，請留幾個小時讓它生效——傳播延遲看起來就跟失敗一模一樣。

會浪費實際時間的部署陷阱：

確切知道哪些部分會自動部署，哪些不會。 如果你的堆疊中有任何部分（無伺服器函數、後端、Worker）是透過單獨的手動命令部署的，請用全大寫字母寫在 CLAUDE.md 中。典型的靜默失敗是合併一個分支，其中可見的網站更新了，但後端沒有，而且一切看起來正常。
自動部署移除了你的最後一個檢查點。 在合併即部署的模式下，PR 審查就是關卡。驗證必須在合併之前完成，而不是之後。
建置主機上的 npm ci 比你本機的 npm install 更嚴格。 一個與 package.json 有細微差異的鎖定檔（lockfile）在較新版本的 npm 上可以正常安裝，但在主機較舊的版本上會導致建置失敗。建置在主機上失敗但本機正常？首先懷疑鎖定檔。
在建置規格中鎖定你的執行環境，而不僅僅在版本檔案中。 單獨一個 .nvmrc 並不可靠——在建置命令中也要呼叫版本管理工具。
每個新的環境變數都需要在託管服務的主控台中個別新增，與讀取它的程式碼分開。這是一個令人驚訝的常見「為什麼壞了」的答案來源。
Content-Security-Policy 是會咬你的那個標頭。 你頁面實際通訊的每個第三方來源——分析工具、標籤管理工具、像素、字型、表單端點——都必須在正確的指令中被允許清單，否則會在正式環境中被靜默封鎖，而在本機開發環境中卻運作正常。症狀：「追蹤在本機運作正常，上線後卻沒反應。」在除錯其他任何事情之前，先在瀏覽器主控台檢查是否有 CSP 違規。
針對已部署的成品進行驗證，而不是原始碼檔案。 透過檢查真實的正式環境回應（curl -I、瀏覽器開發工具）來確認修復，而不是透過閱讀應該會產生它的設定來確認。「我的變更到底部署了沒」也一樣——檢查建置 ID/時間戳記，而不僅僅是檢查合併是否發生。

表單實際上是如何提交的

靜態託管沒有後端。靜態頁面上一個簡單的 <form> 沒有實際作用——這讓很多人在第一天感到驚訝，而這正是整個頁面的重點。三個可行的選項：

選項	適用時機	注意事項
託管的表單服務	你想要今天下午就讓它運作	按流量計費的月費；他們的品牌標誌；你的資料存在他們那裡
無伺服器函數（Lambda、Netlify/Cloudflare Functions）	你想要控制權和接近零的成本	你現在要自己處理驗證、垃圾郵件和 CORS
你的 CRM 的嵌入表單或 Webhook	無論如何，潛在客戶都需要進入 CRM	嵌入的體積和樣式限制；通常載入速度慢

無論你選擇哪一個：

CORS 會是你的第一個錯誤。 一個與你的頁面不同來源的無伺服器端點必須明確允許清單該來源，否則瀏覽器會在請求發送之前就封鎖它。也請將 localhost 加入允許清單，否則你無法在本機測試。
加入一個蜜罐（honeypot）欄位（一個人類不會填寫但機器人會填的隱藏輸入），並拒絕任何填寫它的請求。這是存在最便宜的垃圾郵件過濾器。
永遠不要將原始請求的主體直接展開寫入資料庫。 這就是訪客如何設定你打算在伺服器端控制的欄位。明確地挑選出你想要的欄位。
如果可能，讓端點保持暖機（warm）狀態。 一個經歷冷啟動的無伺服器函數，會讓頁面上最重要的時刻——點擊提交——感覺像是壞掉了。

3. 給 Claude 一個品牌工具包 —— 並強制載入它

這是這份清單中槓桿效應最高的一件事。最低限度，工具包應包含：

你的產品 · 你的目標市場 / 客戶檔案 · 你的訊息傳遞策略 · 你的顏色 · 你的字型 · 你的 Logo

將其放在一個資料夾中（brand/）。範本：starters/brand-kit/brand.md。

然後讓它自動載入。 在 CLAUDE.md 中寫上「讀取品牌工具包」的指示只是建議性質——它不會被一致地遵循。一個 SessionStart 鉤子能將檔案內容 cat 到上下文中，這不是非必要的，也不會被跳過。這一個改變就是「有時符合品牌調性」和「預設就符合品牌調性」之間的區別。請參閱 starters/settings.json。

在會話開始時載入：品牌工具包、一份簡短的架構文件（網站的建置、託管和部署方式），以及最近的會話日誌。

妥善建構它：

將「品牌的外觀」與「品牌的說話方式」分開。 保持始終載入的檔案精簡——色板、字型、Logo、產品、受眾。將更深層的語調/訊息傳遞材料指向為「在處理文案工作時閱讀此內容」。所有自動載入的內容都會在每個會話中永遠佔用上下文空間。
給顏色賦予角色，而不僅僅是十六進制碼（「主要強調色 — 用於主要 CTA」）。角色能阻止 Claude 在需要顏色時發明一個。直接說明規則：工具包之外的顏色不應出現在任何地方。否則，來自範本和產生器的非品牌預設顏色會悄悄地滲入。
兩到三個修改前後的語調範例，比任何形容詞清單能更快地教會語調。
如果你的訊息傳遞內容具有商業敏感性，請將其加入 gitignore，但仍然在 CLAUDE.md 中引用它——這樣你既能獲得一致的載入，又不會將策略或定價發布到儲存庫。
外部同步的品牌文件會過時。 如果語調或受眾文件是從共享磁碟複製過來的，在進行文案傳遞前，請根據其原始來源重新驗證——行銷決策是在對話中做出的，但這些決策可能永遠不會回到文件中。

品牌工具包應強制執行的文案紀律：

永遠不要在一個以擷取電子郵件為任務的頁面上承諾「無需註冊 / 無需電子郵件」。 在表單出現之前，它看起來像是在減少摩擦，但就在你最需要信任的時刻，它變成了一個矛盾。相反地，在時間、成本和回報上給予保證——「2 分鐘 · 免費 · 你的結果會立即透過電子郵件寄出。」
每當產品變更時，重新審核安撫性微文案（reassurance microcopy）。 它會在頁面變體之間被複製，並且會比它原本服務的產品更長壽，正是因為它聽起來很有幫助。
廣告的承諾、頁面的承諾和表單的實際要求必須完全一致。 不一致會表現在真相到來的那個步驟的流失率上，而不是在不一致被引入的那個步驟。當某個步驟有流失，請懷疑它前面的步驟。

4. 在發布前檢視它

在不部署的情況下檢視頁面的兩種方式。兩者都使用——它們是給不同的人使用的。

本機開發伺服器

供你和 Claude 在建置過程中使用。Claude 可以啟動開發伺服器、驅動真實瀏覽器、截取結果畫面，並讀取主控台和網路日誌——因此「這個畫面是否正確呈現」可以透過觀察來回答，而不是透過檢查程式碼。

永遠不要同時為同一個專案執行兩個開發伺服器。 在啟動另一個之前，先檢查是否有現有程序並將其終止——特別是在平行 Agent 可能各自啟動一個的情況下。
將自動重試循環限制在約 3 次嘗試以內。 一個圍繞開發伺服器和瀏覽器自動化的無限制「持續重新載入並嘗試不同時間直到成功」循環，是真實的資源耗盡風險，而不僅僅是煩人——它曾經直接導致機器當機。
驗證清理而非相信它。 「我停止了伺服器並關閉了分頁」就像任何其他未經驗證的聲明一樣——請檢查程序清單。
預期本機環境與正式環境在設計上會有所不同。 任何依賴真實分析 ID 或即時 API 端點的功能，在本機環境中通常都是無效的（no-op）。這是預期行為，不是錯誤——請將其記錄下來，以免每隔幾週就被重新診斷一次。
預設情況下，讓你的端對端測試指向 localhost，而將指向真實部署 URL 的動作設為一個刻意、單獨的操作——否則一次例行測試執行就會對正式環境進行真實的提交。

Claude Design (claude.ai/design)

供其他所有人使用。Claude 可以將一個頁面推送到 Claude Design 專案中，為你提供一個可分享的 URL，讓客戶、設計師或非技術合作夥伴可以在瀏覽器中直接以視覺方式編輯文案和版面，無需任何本機設定。在頁面與真實網站連接之前，這對於簽核非常有用。

一個嚴格規則：永遠不要盲目寫入 Design

在將任何內容寫入 Claude Design 專案之前，Claude 必須先取得目前的遠端版本，與其比對差異，並在覆寫前與你確認。每次都要。

Design 端沒有版本歷史、沒有復原功能，也沒有垃圾桶——一個畫布檔案比一個未追蹤的本機檔案更脆弱。盲目覆寫協作者的編輯是永久無法還原的，而且它已經導致損失了整整一個晚上手寫的文案。

將頁面製作成自包含的靜態 HTML/CSS/JS。 開發伺服器在推送之前可以產生成品，或者你可以在本地開發並將最終的靜態版本推送至 Design。
在材質設計（Material Design）上節省時間： 如果你從一個設計系統或 UI 函式庫開始，請確保它與 Claude 相容。否則，請堅持使用簡單的、自包含的 HTML/CSS。
Claude Design 對於非技術審查很有用。 讓利害關係人進行視覺編輯，同時讓 Claude（和你的開發團隊）保留對程式碼的控制權。

5. 第一天就發布並追蹤

部署不是終點。一個沒有追蹤的即時頁面，你無法改善它。這是整體策略：第一天就發布並加入最簡追蹤，然後針對真實資料進行迭代。

最低限度

Google Analytics（或同等服務） — 頁面瀏覽量、跳出率、轉換率。
一個表單提交事件 — 無論你的表單如何提交（託管服務、無伺服器、CRM），將其連接到一個轉換事件。
Facebook Pixel（或其他像素） — 用於廣告再行銷和轉換追蹤。

最佳化循環

查看資料 — 漏斗在哪裡流失？
形成假說 — 為什麼是那裡？
修改 — 變更文案、版面、CTA。
測試 — A/B 測試或僅是監控變更前後的差異。
重複。

速度

將你的頁面在 Google PageSpeed Insights 上進行評分。 目標是行動裝置 90+ 分。
較小的圖片、較少的請求、更快的字型。 懶加載非關鍵資源。
使用 Preconnect 提示來加速第三方連線。
測試真實使用者體驗。 PageSpeed Insights 是實驗室資料；你也需要現場資料（Chrome 使用者體驗報告，CrUX）。

6. 進階：表單和轉換

轉換事件

轉換是你在頁面上的主要目標——購買、註冊、下載。 每一個表單提交都應該觸發一個轉換事件。

表單提交的標準程式碼（使用 Google Tag Manager）：

// 假設你使用 Google Tag Manager
dataLayer.push({'event': 'formSubmission'});

A/B 測試

不要在產品頁面上預設使用 A/B 測試。 它引入複雜性，而且通常你用之前的工具包中的資料做得更好。相反地：

對高流量頁面進行 A/B 測試。
對低流量頁面，使用逐步推出（canary release）或簡單的「變更前後」比較。

表單處理（進階策略）

對於高流量頁面：

使用 Webhook 直接發送到你的 CRM 或後端。
新增 Honeypot 欄位以對抗機器人。
實作速率限制（Rate Limiting）。
使用 reCAPTCHA（但要注意使用者體驗）。

7. 故障排除

常見錯誤

「追蹤在本機運作正常，上線後卻沒反應。」 — 檢查 CSP 違規，然後檢查 CORS。
「我的變更沒有部署。」 — 檢查建置日誌；確認合併確實觸發了建置。
「表單提交失敗。」 — 檢查 CORS；檢查表單端點是否正常運作；檢查 Honeypot 邏輯。
「頁面載入緩慢。」 — 執行 PageSpeed Insights，檢查網路請求，最佳化圖片。

永遠不會失敗的調試策略

簡化問題，直到它消失或可以被觀察到。 孤立變數。移除分析工具。使用簡單的 HTML。那就是你的起點。

檢查基礎知識：

頁面在瀏覽器中載入嗎？
表單有提交嗎？
追蹤事件有觸發嗎？
資料到了分析工具嗎？

記錄所有內容，即使它有效。 一個用於本地開發的 console.log 在正式環境中更有價值。

立即開始

使用此技能的最快方法：

複製或分叉此儲存庫（或使用 starters/ 目錄中的範本）。
設定你的儲存庫（如果尚未設定）。
選擇一個託管服務（AWS Amplify、Netlify、Vercel、Cloudflare Pages）。
建立你的品牌工具包（使用 starters/brand-kit/brand.md 範本）。
在 CLAUDE.md 中加入「SessionStart」鉤子（使用 starters/settings.json 範本）。
建立你的第一個著陸頁（使用 starters/page-template.html）。
發布它。
針對真實資料進行疊代。

記住： Claude 處理執行的重複性工作。你專注於策略、創意和決定。

david-samurai/LandingPageSkill

LandingPageSkill 是什麼？

在你喜歡的 AI 中提問

說明文件