部落格流程
你能獲得什麼： 一篇回應真實搜尋需求、符合你的語氣、附有已核實事實、1200x630 圖片與有效 frontmatter 的文章，靜靜躺在專屬的資料夾中等你審閱。
首要步驟： 在專案根目錄放入一份填寫完整的 BLOG.md（此儲存庫中有範本）。每個階段都會讀取它。
每次都先閱讀
- 專案根目錄的
BLOG.md：包含網站、讀者、目標、語氣、應避免的詞彙、分類、發文節奏、SEO 與圖片規則、frontmatter 預設值以及修正清單。當BLOG.md與此技能衝突時，以BLOG.md為準。 - 在撰寫任何 frontmatter 之前，閱讀
references/frontmatter-contract.md。 - 閱讀你正在執行階段的參考檔案，以及你需要的其他檔案。
還沒有 BLOG.md？ 停下來並提議建立一份。閱讀對方 3 到 5 篇現有的文章或頁面，詢問範本每個部分中的問題，寫好檔案並請對方檢查。沒有它寫出來的文章聽起來不像任何人。
運作方式
一篇部落格文章是對人們在 Google 中輸入的某個問題的解答。知識可以來自談話、電子報或客戶通話；這篇文章會圍繞一個搜尋來重建：一個符合該搜尋的標題、接近頂端的答案、以及以人們搜尋方式表述的標題。
在寫新文章之前先更新。 檢查現有文章或頁面是否已經針對該搜尋主題。一篇 Google 已經顯示、有點擊但沒有流量的文章，比一篇從零開始的新文章更有價值，而且只需要花費一小部分心力。兩個頁面瞄準同一個搜尋通常會兩敗俱傷。
工作資料夾
每篇文章一個資料夾，位於對方的專案中：posts/<YYYY-MM-DD>-<slug>/。日期是計畫的發佈日。slug 是最終的網址和檔案名稱。每個階段會將一個檔案寫入此資料夾，因此資料夾就是記憶：任何階段都可以重新執行或稍後繼續，而無需重做之前的階段。
| # | 階段 | 讀取內容 | 寫入內容 | 操作說明 |
|---|---|---|---|---|
| 1 | 發想 | BLOG.md、搜尋資料、現有文章與頁面 | posts/_ideas/topic-ideas.md | references/01-ideation.md |
| 2 | 簡報 | 一個主題 | brief.md | references/02-brief.md |
| 3 | 研究 | brief.md | research.md | references/03-research.md |
| 4 | 草稿 | research.md、brief.md、BLOG.md | draft.md | references/04-draft.md |
| 5 | 視覺 | draft.md | visuals.md、<slug>.svg、<slug>.png | references/05-visuals.md |
| 6 | 發佈 | draft.md、visuals.md | src/content/blog/ 中的文章、public/images/blog/ 中的圖片、publish.md | references/06-publish.md |
完整鏈條： 對一個主題依序執行階段 2 到 6。階段 1 是一個批次步驟：當想法清單快用完時執行它，在每週一篇的節奏下大約每月一次。
「規劃我的第一篇貼文」（或「規劃我的下一篇貼文」）： 階段 1，然後階段 2。執行發想，顯示候選清單，讓對方挑選一個主題（不一定要是第一個；在 topic-ideas.md 中記錄選擇及原因），然後撰寫其簡報。在簡報完成後停止，並說明下一個階段。當對方要求「尋找主題想法」時，只執行階段 1；當他們要求「撰寫 <主題> 的簡報」時，只執行階段 2。
單一階段： 對方指定階段和文章。讀取該階段的檔案及其輸入，並跳過其餘部分。
更新： 跳過階段 1 和 2。建立資料夾 posts/<today>-<slug>-refresh/，以更新模式執行階段 3 和 4，然後執行階段 6。
以上路徑是起始網站的。如果 BLOG.md 列出了其他資料夾，請使用那些。
規則
這些規則覆蓋任何階段的檔案。BLOG.md 可以添加更多規則。
- 絕不虛構來源、統計數據、引用或連結。 文章中的每個 URL 都必須在研究期間開啟過。無法驗證的主張必須刪除，或標記為
[UNVERIFIED]讓對方確認。對方自身的經驗在標明為他們的經驗時可視為來源。來自其作品的數據需要專案中的檔案或記錄在research.md中的有日期聊天引用（階段 3）；否則即為[UNVERIFIED]，且不會出現在發佈的檔案中。 - 根據當前文件核實關於工具和平台的資訊。 功能和限制經常變更，去年的操作指南今天可能已經過時。
- 搜尋數字必須是數據或明確標示。 搜尋量和難度必須來自某人執行過的某個工具，並附上日期，否則檔案中必須註明「未估算」。將猜測的數字當作數據呈現比沒有數字更糟。
- 對方在發佈前審閱每篇草稿。 新文章需設定
draft: true。此技能絕不會自行推送、部署或切換draft狀態。唯一的例外是對已發佈文章的更新，它會保持draft: false（請參閱階段 6）。 - 批准：時間、方式以及編輯的去向。 此技能在此定義此規則；階段 6 會遵循它。
- 時間： 在階段 6 寫入發佈檔案且對方讀過文章後的任何時間。同一個工作階段也可以。
- 方式： 一個變更。對方在
src/content/blog/<slug>.md中將draft設為false，或告訴 Claude 這麼做。同時確認date是發佈日。 - 編輯的去向： 在階段 6 之前，編輯應在
posts/<folder>/draft.md中進行。在階段 6 之後，僅在發佈的檔案中進行。draft.md保留為移交時的草稿，而publish.md會列出其後所做的每一項變更。 - 什麼會阻止發佈： 在發佈日之前仍有待辦事項（缺少的頁面、
[UNVERIFIED]的主張、連結稽核列出的行）會使文章保持draft: true，直到問題解決。
- 日期是發佈的門檻。 起始網站會隱藏設定在未來日期的文章，直到當天並將其列在「即將發佈的文章」下。
- 客戶工作保持匿名，除非客戶同意被指名。移除名稱是起點：檢查仍能識別其身分的類別、地點和時間組合（「佛蒙特州一家在三月開業的蠟燭店」即為一個名稱）。將營收轉換為比率或百分比。
- 先給答案。 用一段讀者能從自身工作中識別的背景脈絡開場，然後在第三段結尾前給出答案。文章開頭絕不能是問句。
- 為搜尋而寫，附帶一個行動呼籲。 以人們搜尋的方式表述標題，數字用阿拉伯數字，段落要短。主要行動是 BLOG.md 第三節中的那個，且與
src/site.config.mjs中的cta匹配。起始網站會在每篇文章結尾顯示該按鈕和一個訂閱框，因此正文中不需要結尾的呼籲行動連結。正文中最多可以一次連結到主要行動，在文字中，僅在符合文章脈絡時，且只能連結到存在的頁面或cta地址。 - 僅連結到在文章發佈當天上線的頁面。 這表示所有指向自己網站網域的文章和頁面的連結。將自己網站的連結寫成相對路徑（
/about/）。階段 6 包含檢查。 - 語氣屬於對方。 一篇讀起來像是陌生人寫的稱職內容的草稿，即使每一條規則都通過，也算是失敗。
修正成為規則
當對方兩次修正同一件事時（一個詞、一個開頭、一個標題風格），提議在 BLOG.md 的「修正」部分中添加一行帶有日期的記錄。階段 4 在每次草稿前都會讀取該部分，因此一次修正就能永久解決。
在移交草稿之前
在草稿中搜尋 BLOG.md「應避免的詞彙」中的每個詞，例如：
grep -n -i -E "word one|word two|—" posts/<folder>/draft.md
詞彙搜尋會遺漏句型。在階段 4 中執行句型搜尋（「詞彙搜尋遺漏的句型」），然後通讀草稿一遍，尋找 BLOG.md 列出但無法透過搜尋捕捉的句型，例如開頭問句或結尾摘要。同時對照 research.md 檢查每個事實性句子（階段 4）。
然後用幾行文字告訴對方：草稿的位置、目標搜尋、計畫發佈日期、任何標記為 [UNVERIFIED] 的內容、任何保密性問題，以及他們需要決定的事項。
可選項：電子報版本
如果對方也發行電子報（Substack、Beehiiv、Kit 或類似平台），相同的知識也可以在那裡發佈。為電子報版本設定自己的標題和自己的搜尋詞組，這樣兩個頁面就不會在 Google 中競爭，並將電子報檔案加入階段 1 和 2 的重疊檢查中。
工具
Claude Code，或能夠存取專案檔案的 Claude。搜尋資料來自免費工具：Google 自動完成、Google Search Console、免費的 Ubersuggest 方案以及一般的 Google 搜尋第一頁。如果某個工具未連接，請對方貼上他們看到的內容（Ubersuggest 在其網站上運作良好），或將數字標記為未估算。一個沒有資料和工具的新網站仍然可以繼續：references/01-ideation.md 有相關路徑。
本次工作階段無網路存取： 階段 1 會根據現有證據對想法進行排序，並將其他想法標記為「未檢查」。對方在階段 2、在簡報被批准之前，為他們選擇的單一目標搜尋貼上自動完成建議和第一頁結果。沒有人需要為整個候選清單貼上內容。將 API 金鑰保留在 BLOG.md 和文章資料夾之外。