用 Codex 建立你的第一個流量頁面，從簡報到可發布的草稿
將第一流量頁面決策和事實包轉化為一個完整的、可審查的草稿，而不發布通用或發明的內容。
建立一個訪客真正可以使用的頁面
你選擇了頁面。現在讓它在變長之前先有用。Codex 應該將你的證據組織成一個回答，而不是把一個關鍵字填充進一篇部落格文章。
完成的定義： 一份可發布的草稿，包含直接回答、證明、限制、有用的下一步，以及每個不確定的主張都標記為需要審查。
預留 60 到 90 分鐘。 帶上已批准的第一流量頁面決策、它的證明請求和你的事實包。你是在建立一份可審查的草稿，而不是給 Codex 權限去發布、更改 CMS 或發明缺失的部分。
在草稿之前先寫簡報
建立 first-traffic-page-brief.md，包含：客戶問題；頁面承諾；事實包中的五個事實；一個限制；要連結的頁面；訪客行動。然後執行：
閱讀我的第一流量頁面決策、流量任務和事實包：[路徑]。
建立 first-traffic-page-draft.md。用 2-3 句話的直接回答開始。
然後只使用幫助訪客決策所需的段落：適合度、步驟或比較、
證明、限制和下一步行動。僅使用已確認的事實。
將缺失的主張標記為 NEEDS OWNER FACT。包含建議的內部連結，但不要加入它們。
不要發布、編輯網站檔案、發明範例、價格、評論、成果或來源。用實際的決策填滿簡報，而不是標題
這是第 9 課選擇的記帳頁面的精簡簡報：
Customer question（客戶問題）：自由接案設計師在自我評稅截止日前應該收集哪些記錄，
以及每月記帳協助何時可能適合？
Page promise（頁面承諾）：此檢查清單說明在探索通話前要收集什麼，
以及每月服務從哪裡開始、到哪裡結束。
CONFIRMED facts（已確認的事實）：為個人經營設計師提供每月記帳；
探索通話在入職之前；存在入職檢查清單；個人稅務申報被排除；
存在文件化的交接流程。
Limitation（限制）：我們目前無法說明服務是僅限布里斯托還是英國遠端。
Link to（連結到）：在檢查清單解釋服務適合度之後，/bookkeeping-for-designers。
Visitor action（訪客行動）：檢查所述的每月服務範圍是否適合。如果你無法寫出限制，你就還沒有完成事實包的工作。限制是一個值得信賴的頁面防止訪客做出錯誤假設的地方。
品質檢查： 簡報中的每個事實都存在為 CONFIRMED 的事實包資料列。不要貼上原始研究筆記或一個競爭對手的頁面並稱它為證明。
以正確的順序給 Codex 輸入
不要貼上一堆筆記然後說「把它做好」。將輸入放在這些標籤下，即使一個標籤只有一句話：
輸入 | 提供什麼 | 為什麼重要 |
|---|---|---|
讀者問題 | 來自第一流量頁面決策的確切問題 | 防止草稿變成一個廣泛的主題概述 |
直接回答 | 你目前用平實語言的最佳回答 | 給 Codex 一個要證明的結論，而不是一個要重複的關鍵字 |
已確認的事實 | 五到十列事實包資料 | 提供只有你能證明的事實 |
限制 | 服務、產品或建議不適用的情況 | 防止過度主張 |
下一步行動 | 一個相關的預約、購買、註冊、比較或頁面 | 在回答之後給訪客一條有用的路徑 |
如果你無法提供一個直接回答，要求 Codex 給出兩個標記為 NEEDS OWNER DECISION 的可能立場。不要讓它替你選一個激進的承諾。
在要求完整文章之前先使用一個骨架
大多數第一流量頁面只需要這個結構：
Title（標題）：用平實語言表達的客戶決策
Opening（開場）：用兩三句話的直接回答
Section 1（第 1 節）：這是為誰準備的，何時適用
Section 2（第 2 節）：決策標準或步驟
Section 3（第 3 節）：已確認的證明、流程或範例
Section 4（第 4 節）：限制、替代方案或何時不選擇此選項
Section 5（第 5 節）：下一個有用的行動一個產品頁面可能以一個適合度表格開頭。一個本地緊急服務頁面可能以一個安全邊界和預約路徑開頭。一個 SaaS 比較可能以一個決策矩陣開頭。不可妥協的部分是回答、證據、限制和下一步行動。
在要求完整文章之前先要求一個章節計畫
對初學者而言，大綱審查比 2,000 字的改寫便宜。先使用這個：
閱讀 first-traffic-page-brief.md 和 fact-pack.md。建立一個頁面計畫，而不是文章。
對於每個章節，顯示：它回答的訪客問題；它將使用的 CONFIRMED 事實包資料列；
任何限制；以及它應該引導到的下一個章節或行動。包含不超過六個章節。
不要發明範例、撰寫頁面文案、編輯檔案或發布。只有當章節有明確的任務時才批准這個計畫。以檢查清單而言，計畫可能是：直接回答；要收集的記錄；每月協助何時適合；服務不包含什麼；探索通話後會發生什麼；下一步行動。它不需要一段很長的記帳歷史、一個通用的 SEO FAQ 或一個競爭對手比較。
如果 Codex 給你一個通用的文章大綱，回覆：
這個大綱沒有使用已批准的簡報。將它改寫為針對指定客戶問題的決策頁面。
在每個章節旁，引用允許它的事實包資料列。刪除沒有訪客決策或已確認事實的章節。以兩個階段審查草稿
第一階段：主張審查
將草稿與事實包並排打開。標記每個數字、日期、價格、能力、地點、客戶成果、比較陳述和政策主張。每個標記都需要一個狀態：
CONFIRMED：存在於事實包中並附有來源。NEEDS OWNER FACT：可能為真但你尚未提供證明。REMOVE：模糊、不必要或無法驗證。
比較 first-traffic-page-draft.md 與 fact-pack.md。建立一份主張審查表，包含：
草稿主張、狀態（CONFIRMED / NEEDS OWNER FACT / REMOVE）、事實包來源和所需行動。
不要改寫頁面或新增主張。第二階段：訪客價值
只讀標題、開場、標題和最終行動。訪客必須能夠回答：這是為我準備的嗎？我應該決定什麼？什麼證明使它可信？如果不能，先改變結構再打磨句子。
第三階段：頁面機制
在任何人將草稿移入 CMS 或儲存庫之前，要求 Codex 提供一個機械式交接：
閱讀已批准的草稿、主張審查表和 first-traffic-page-brief.md。
產出一份 CMS 中立的實作表，包含：
1. 建議的 URL slug 和標題。
2. 按順序的標題大綱。
3. 內部連結的來源句子、錨點文字和目的地。
4. CTA 文字、目的地和所需的擁有者確認。
5. 圖片或表格需求，附有替代文字和每個視覺元素證明的內容。
6. 僅反映完成頁面的中繼資料選項。
7. 一份發布檢查清單和回溯說明。
不要編輯 CMS、提交檔案、上傳圖片、建立重新導向、發布或更改追蹤。這是開發者或 CMS 編輯器可以安全工作的地方。如果你確實將 Codex 用在一個本地網站儲存庫中，給它實作表，並要求它在觸碰任何東西之前列出它要更改的檔案。要求一份差異，並對照事實包審查該差異。
像訪客一樣審查
問題 | 通過條件 |
|---|---|
開場回答了問題嗎？ | 訪客在捲動之前就知道頁面的結論 |
建議具體嗎？ | 它使用你的證明、流程、限制或範例 |
頁面誠實嗎？ | 它說明了誰不適合或什麼無法證明 |
有下一步行動嗎？ | 行動自然地從決策中延伸出來 |
如果十個競爭對手可以不經修改地發布這個頁面，加入更好的第一方證明或縮小問題。不要加入填充內容。
為後續課程儲存一個交接
建立 first-traffic-page-handoff.md：
# First Traffic Page Handoff（第一流量頁面交接）
- Customer question（客戶問題）：
- Page promise（頁面承諾）：
- Confirmed facts used（使用的已確認事實）：
- Claims needing approval（需要批准的主張）：
- Page to link from（要從哪裡連結）：
- Page to link to（要連結到哪裡）：
- Visitor action（訪客行動）：
- Draft path（草稿路徑）：
- Reviewer（審查者）：這個小檔案是清晰度、連結和發布審查的輸入。即使你獨自工作也保存它。
當草稿很薄弱時該做什麼
它讀起來像每一個競爭對手的頁面。 簡報可能沒有獨特的證明。不要要求更有說服力的語氣。加入一個文件化的流程、具體的限制、批准的範例或更狹窄的客戶問題。
它有幾十個 `NEEDS OWNER FACT` 標籤。 停止起草。只向擁有者發送阻塞性問題，更新事實包，然後重新生成受影響的章節。一個充滿佔位符的頁面不是一份準備好校對的草稿。
它回答了問題但沒有下一步行動。 決定這個頁面是要引導到一個服務、產品、註冊、工具還是另一個指南。如果沒有幫助，不要強迫一個銷售 CTA。使用一個有用的相關頁面，並記錄缺失的轉換路徑以供以後使用。
將大綱、草稿、主張審查、實作表和交接保存在一個資料夾中。清晰的記錄讓你在第 11 課改善一個元素，而不是失去頁面最初被撰寫的理由。
用一份真實的頁面檢查清單審查草稿
在稱呼一份草稿為可發布之前，按這個順序檢查：
檢查項目 | 檢查什麼 | 何時停止 |
|---|---|---|
問題匹配 | 標題和開場反映頁面決策 | 草稿回答的是更廣泛的主題 |
事實邊界 | 每個重要主張都出現在主張審查中 | 價格、成果、能力、地點或政策沒有來源 |
讀者路徑 | 標題從回答移動到證據再到下一步行動 | 兩個段落重複相同的觀點或一個段落沒有任務 |
連結路徑 | 頁面指向一個真正有用的目的地 | CTA 或內部連結與問題無關 |
手機掃描 | 短段落、有用的表格標籤、可讀的 CTA | 關鍵指示依賴於密集的文字牆 |
對 CMS 編輯器而言，將檢查清單變成一份發布前的註釋表。對儲存庫而言，只在 Codex 顯示提議的檔案清單後，才讓它執行可用的本地檢查。人工批准是針對內容和實際的網站變更，而不是針對一個通用的綠色勾選標記。
一份壞的草稿和正確的修復
壞的開場： 記帳對每個自由工作者都很重要。我們友善的團隊可以為你節省時間並減少壓力。
它失敗，因為它沒有回答決策、做出了一個沒有支持的成果主張，並且沒有提供證據或範圍。
更好的方向： 此檢查清單幫助個人經營設計師在決定每月記帳支援是否適合之前收集記錄。它涵蓋了文件化的入職交接，不取代個人稅務申報。
它不是巧妙的，但讀者可以理解它。從那裡，頁面可以用實際的檢查清單和一個清晰的服務邊界來贏得信任。
不要讓格式隱藏未完成的工作
表格、圖片佔位符、FAQ、中繼資料和精美的標題可以讓一個未完成的草稿看起來完成。在發布之前，掃描 TODO、TBD、NEEDS OWNER FACT、括號佔位符文字和來源筆記。解決或移除每一個。讀者永遠不應該看到內部的證據邊界；他們應該看到一個只陳述你能支持的內容的頁面。
課程地圖
下一課：將一個頁面變成 Google 和 AI 搜尋中最清晰的答案。保存已批准的草稿和你的審查筆記。
作者：Martin Hayes，Auspia GEO 手冊建構師，為超過 200 個執行檢查清單設計。Martin 專注於撰寫實用、可審查的內容工作流程。
![建立流量頁面工作包流程圖]()
對這項作業使用此順序：從真實輸入開始，檢查證據，準備一個可審查的輸出，然後選擇讀者的下一步。
