beedle 是做什麼的？
建立搜尋引擎和 AI 爬蟲能讀取的行銷頁面，讓陌生人在十秒內理解，並且只宣稱能被證實的事。少即是多：每個區塊都必須證明自己存在的價值。每個迭代結束時都會進行獨立審查。
教訓： 在開始步驟 1 之前，如果專案中有 design/LESSONS.md，請先閱讀並遵循其中關於其行銷網站的任何指示。這些是擁有者的修正。
1. 了解專案
在你詢問任何問題之前，先找出已經存在的東西：技術棧與主機、任何現有網站、產品的真實名稱、儲存庫、商店列表、定價、螢幕截圖、設計標記或主題、分析工具，以及 docs/marketing/page-brief.md。
使用專案已經使用的技術棧來建置。對於新網站，請遵循 reference/zh-TW/seo.md（「選擇技術棧」）。行銷內容絕不使用 Flutter Web 或客戶端渲染，因為爬蟲可能永遠無法看到它們。
使用專案的主題（如果有的話，像是 design/THEME.md、*.tokens.json）。如果沒有，請從應用程式移植標記。如果也沒有可以移植的應用程式，請撰寫 reference/zh-TW/small-theme.md 中的一個小檔案，因為一個頁面不需要完整的設計系統。僅在使用者要求主題，或多個網站或應用程式需要共用一個主題時，才使用 ultrahand:theme 技能。
2. 選擇頁面類型和發布狀態
閱讀 reference/zh-TW/page-types.md。選擇一種類型和一種狀態（發布前或已發布），並記下網站所需的支援頁面。
3. 撰寫簡報
在專案中儲存 docs/marketing/page-brief.md，使用此範本。這是審查員用來檢查頁面的合約，也是下一個工作階段的起始點。
# 頁面簡報
- 類型和狀態：
- 目標受眾：（對象是誰，以及他們已經知道什麼）
- 頁面的唯一任務：
- 主要行動呼籲：（確切文字和目標連結）
- 次要動作：（一個，較不明顯，或「無」）
- 搜尋詞組：（此受眾實際會輸入的 3-5 個詞）
- 反對意見：（人們會離開的真正原因）
- 分析工具和 Cookie：（載入哪些，或「無」）
## 宣稱
| 頁面上的宣稱 | 證據 |
| --- | --- |
| <每個數字、引言、比較、「首個」、「最快」...> | <檔案、連結或測量結果，附日期> |
| <對該產品或功能的簡單描述> | <檔案或連結，或如果只有 README，則為「僅 README」> |
## 等待人員處理
- <誰：他們必須做什麼，或「無」>
僅詢問專案本身無法回答的問題，通常是目標受眾和證明。絕不虛構證明。缺少的推薦見證就是一個缺少的區塊，而不是一個可以填入的佔位符。使用會明顯失敗的標記，例如 APP_STORE_ID_TODO，而不是看似合理的假值。
當你只有 README 時， 仍然可以建立頁面。它可以清楚說明產品是什麼以及做什麼：將這些行標記為 僅 README。它無法證明數字、日期、版本、授權、價格、安全性、隱私權或可用性，因此請為每一項尋找主要來源：程式碼、LICENSE 檔案、發布頁面、註冊表或商店列表、測量結果，或擁有者註明日期的說法。引用該來源。如果沒有，則從頁面上移除該宣稱。
只有人能提供的任何東西 一旦你得知，就立即放到「等待人員處理」之下：真實的螢幕截圖、網域、待確認的價格。它會一直留在那裡，直到他們完成。
4. 先撰寫文案
遵循 reference/zh-TW/message.md。在任何版面配置之前先撰寫文案。從那裡的五個區塊開始。只有在你能說出某個區塊回答的是哪個反對意見時，才新增一個區塊，並將該反對意見記錄在簡報中。
5. 建置
遵循 reference/zh-TW/seo.md 了解頁面內及頁面旁應包含哪些內容。使用真實的產品螢幕截圖或影片，絕不將重新製作的內容標記為螢幕截圖。擷取真實應用程式運行範例資料的畫面是真實的：在頁面上將其說明為範例，並在宣稱表格中說明你是如何製作的。如果沒有真實的東西可以展示，則省略圖片，或者如果頁面類型需要，則留下一個標記。避免訊息參考中列出的設計特徵，因為它們會讓頁面在任何人閱讀之前看起來像是生成的。
6. 自我檢查
建置網站並對建置後的輸出執行審核，然後修復你能修復的每個錯誤：
beedle audit --dir <已建置的網站>
對於每個非行銷的區段，新增 --exclude docs（可重複）。如果 beedle 不在 PATH 中，請告知使用者審核未執行，以及 INSTALL.md 說明了如何加入它。
只有人能清除的錯誤則保留，例如沒有人購買的網域的 DOMAIN_TODO 標記。絕不要為了獲得乾淨的執行結果而換成假值。確保它已列在「等待人員處理」之下，然後繼續進行審查。
7. 審查迭代
每個迭代都必須由一個新的審查員在其自己的工作階段中進行審查，然後你才能告知使用者頁面已準備就緒。迭代 指的是首次建置以及之後每次改變頁面的提示，因此即使是一行程式碼的變更也必須審查。僅在使用者明確要求跳過本次迭代審查時才跳過，並告知你已跳過。
自行啟動審查，無需被要求。你無法公正地審查自己的頁面：你看到的是你原本打算建置的東西。遵循 review/zh-TW/round.md。簡而言之，撰寫簡報，在背景執行 beedle review --brief <brief> --add-dir <project>，然後根據調查結果採取行動。在此之前，不要發布、部署或宣告頁面完成。
8. 報告
說明你建置了什麼、類型和狀態、裁決結果，以及審查發現了什麼、修復了什麼、留下了什麼未解決的問題，以及其成本。
如果裁決結果是「在人員採取行動之前無法發布」，請以此作為開頭：頁面尚未準備就緒、必須由誰做什麼，以及一旦他們完成後，下一個迭代將檢查什麼。絕不要將其緩和為「幾乎完成」。
始終列出發布後留給擁有者的事項：Search Console 和 Bing Webmaster 驗證，以及在已部署頁面上執行 Rich Results Test。
除非使用者要求，否則不要部署。
9. 學習
當擁有者修正結果或陳述持久的偏好時，在專案的 design/LESSONS.md 中新增一行（如果需要的話請建立它）。如果此次修正顯示這些規則對所有專案都是錯誤的，也請在此修正規則。