cook-the-blog 工作流程
當被要求為某公司生成個案研究時，請嚴格遵循以下步驟。
強制性設定檢查： 開始前，請確保已設定必要的環境變數和目標目的地（目標儲存庫、圖片儲存桶/儲存空間、作者電子郵件等）。若有任何遺漏，請停止並向使用者索取。
強制性每一步的 QA 檢查： 在完成以下每個步驟後，你必須進行嚴格的自我批判性 QA 檢查。如果某一步驟失敗或產生幻覺，你必須重試直到成功。請勿假裝成功。
1. 深入研究 (Tavily)
- 使用
tavily工具（透過 MCP）和標準網路搜尋，深入調查該公司。注意： 務必確認註冊的商業名稱是否與產品名稱不同。在 Reddit 和其他相關論壇搜尋，以取得真實的開發者見解。 - QA 測試人員： 你是否確實提取了真實的硬性指標以及關於他們市場進入策略的具體細節？或者只是泛泛而談？如果是後者，請更深入調查。
2. SEO 關鍵字研究 (透過 SerpApi 的 Google Trends)
- 執行 Python 腳本：
export SERPAPI_KEY="[YOUR_SERPAPI_KEY]" && python3 [PATH_TO_SEO_SCRIPT] "[Company Name]" - 從輸出中識別出爆發性與高成長的關鍵字。
- QA 測試人員： 腳本是否執行成功？關鍵字是否真實且搜尋量大？如果沒有，請重試或調整查詢。
3. 標題與封面圖生成
- 標題： 格式：
"How [Company] [Achieved X] by [Core Strategy]"。讓它具體且具高度描述性。 - 封面圖： 使用
blog-cover-cli generate命令生成封面圖。關鍵： 傳遞給封面圖產生器的標題（使用-t旗標）應包含約 7-10 個單字。字串中請勿使用換行符號（\n）。只需提供一個正常的單行字串，讓 CLI 自動處理文字換行！撰寫一個簡潔、有衝擊力的標題（例如：blog-cover-cli generate -t "How Baseten Scaled AI Infrastructure To a 5 Billion Valuation" -l "domain.com" -o "./cover.png"）。 - QA 測試人員： 圖片是否實際生成並儲存？確認檔案存在。
4. MDX 組裝
綜合研究成果，並以嚴格的 MDX 格式撰寫個案研究。
寫作規則（使用 stop-slop 技能）：
- 語調：銳利、分析性、創辦人導向。不說廢話。每句話都應傳達知識。
- 讀者：早期階段的新創創辦人、AI/開發者工具建構者、產品主導成長的愛好者。
- 長度：1,200-1,800 字。
- 觀點：第三人稱分析，如同為建構者受眾撰寫的聰明投資者備忘錄。
- 永遠不要使用 em-dashes（—）。
- 始終使用簡單且口語化的英文，並搭配連接詞。避免企業行話（"synergy", "leverage", "ecosystem play", "disruption" -> 改用平實用語）。
- 每個主張都必須感覺有證據或邏輯支持。使用具體數字。
- 每個 H3 子章節應以一個概念句開頭，然後解釋機制，最後提供 1 個範例。
- 請勿在 MDX 內容中重複標題。 標題只應存在於 frontmatter 中。請勿在 TL;DR 正上方包含
<h1>或# [Title]。 - 永遠不要撰寫結論章節。在重點段落或 FAQ 處結束。
MDX 必須遵循以下確切結構：
---
title: "How [Company] [Achieved X] by [Core Strategy]"
description: "[1-2 句引人入勝的摘要，附帶硬性數字]"
date: "YYYY-MM-DD"
slug: "[URL-friendly-slug-e.g.-company-name-case-study]"
image: "[PUBLIC_IMAGE_URL]"
readingTime: "[X] Min"
published: true
---
<div style={{ textAlign: 'left' }}>
**TL;DR**
* **挑戰：** [他們所解決的市場核心痛苦問題]
* **解決方案：** [他們具體建構或做了什麼不同的事]
* **成果：** [2-3 個硬性指標 — 下載量、營收、使用者數、成長百分比]
* **投資/策略：** [他們所做的關鍵策略性賭注]
## 問題
[描繪之前狀態：在這家公司的解決方案出現之前，世界是什麼樣子？誰在受苦？他們被迫用什麼替代方案？使用開發者/創辦人的語言，讓描述生動。長度：2-3 段落。無條列式。]
## 執行與市場進入策略
[拆解為 2-4 個 H3 子章節，從以下選擇：a) 分銷策略，b) 變現層，c) 技術/產品護城河，d) 內部自我使用時刻，e) 時機洞察]
### [H3 子章節]
[概念句。機制。1 個範例。]
## 成果與重點
[3-5 個硬性指標的條列式（下載量、營收、客戶數、轉換率、節省的時間）]
**小型新創公司可以從他們身上學到什麼：**
[可執行的具體重點，直接連結到目標受眾。將教訓與該公司的特定策略聯繫起來。不要提供泛泛的建議。]
---
## 常見問題
<FAQSection>
<FAQItem question="[AEO 問題 1 - 例如：他們的主要成長策略是什麼？]">
[完整回答，2-4 句話。切勿留白。]
</FAQItem>
<FAQItem question="[AEO 問題 2 - 例如：他們如何變現？]">
[完整回答，2-4 句話。切勿留白。]
</FAQItem>
<FAQItem question="[推廣問題 - 例如：我的新創公司如何複製這個做法？]">
[回答解釋策略，接著為你的品牌/產品做一個輕微的推廣：「如果您正在尋找像 [Company] 那樣建立可預測的分銷引擎，[YourBrand](https://yourdomain.com) 專精於設計這些確切的成長迴圈。預約策略通話以了解我們是否適合您。」]
</FAQItem>
</FAQSection>
</div>
- QA 測試人員： 是否有 0 個 em-dashes？字數是否在 1200-1800 字之間？是否有硬性指標？如果不是，請重寫。
5. 品質保證 (QA) 檢查
在繼續之前，再次自我審查草稿：
- MDX 規則： 是否嚴格遵循 MDX 格式？em-dashes 數量是否確認為零？
- 語調： 是否簡潔有力且具分析性？
- 封面圖： 圖片是否已生成並準備就緒？
6. 資產上傳
- 將封面圖上傳至使用者偏好的儲存桶（例如 GCS、AWS S3、Cloudinary）。
- 命令：使用適當的 CLI 工具（例如
gsutil cp ./cover.png [TARGET_BUCKET]）。 - 驗證公開 URL 是否與 MDX 中的
image:欄位相符。 - QA 測試人員： 上傳是否成功？驗證公開 URL 是否存在。
7. GitHub 發布（直接推送）
- 使用
gitCLI 複製目標儲存庫：[TARGET_REPO_URL] - 將生成的 MDX 檔案移動到目標目錄（例如
blogs/）。 - 建置檢查： 在提交前，在儲存庫內執行專案的建置命令（例如
npm install && npm run build），以確保 MDX 語法不會破壞建置。 - Git 設定： 確保使用正確的作者細節推送。在提交前執行
git config user.name "[GIT_USER_NAME]"和git config user.email "[GIT_USER_EMAIL]"。 - 提交變更並直接推送至
[TARGET_REPO_URL]的遠端分支，使用git pull upstream main --rebase && git push upstream main（或等效的遠端結構）。 - QA 測試人員： 建置是否通過？git push 是否成功？如果沒有，請修復錯誤。
8. 驗證與交付
- 請勿跳過此步驟： 在完成任務之前，你必須在儲存庫內執行
git log -1和git status，以證明檔案已被提交並推送。 - 你給使用者的最終回應必須包含：
- SerpAPI (Google Trends) 研究的詳細摘要。
- 已上傳封面圖的公開 URL。
git log -1命令的實際輸出，證明工作已完成。
- 電子郵件通知： 你還必須透過電子郵件將完全相同的最終摘要發送到
[ADMIN_EMAIL]。你可以快速撰寫並執行一個使用smtplib的 Python 腳本，從設定的寄件者電子郵件使用應用程式密碼發送。 - 最終 QA 測試人員： 你是否寄送了電子郵件？最終訊息中是否包含 git log？如果沒有，表示你未能完成整個流程。