cook-the-blog

cook-the-blog 工作流

当被要求为某家公司撰写案例分析时，请严格按照以下步骤操作。

必须进行的设置检查： 开始前，确保已配置所需的环境变量和目标位置（目标仓库、图片存储桶／存储服务、作者邮箱等）。如果缺少任何信息，立即停止并向用户索取。

每一步都必须进行 QA 检查： 完成以下每一步后，都必须进行严格且自我批判的 QA 检查。如果某一步失败或内容是臆造的，必须重试，直到成功为止。不得谎称成功。

1. 深入研究（Tavily）

• 使用 tavily 工具（通过 MCP）和标准网页搜索，深入研究该公司。注意： 务必确认注册的企业名称是否与产品名称不同。搜索 Reddit 和其他相关论坛，了解真实的开发者见解。
• QA 测试员： 你是否确实提取了真实、具体的硬性指标，以及有关其 GTM 策略的具体细节？还是只写了泛泛而谈的内容？如果内容空泛，就继续深入研究。

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 个单词。
• 视角：第三人称分析，采用面向开发者受众的聪明投资人备忘录风格。
• 不得使用破折号（—）。
• 始终使用简单、自然的英语，并使用连接词。避免企业套话（“synergy”“leverage”“ecosystem play”“disruption”应替换为通俗表达）。
• 每项主张都应有证据或逻辑支撑。使用具体数字。
• 每个 H3 小节都应先提出一个概念句，再解释其机制，然后给出一个示例。
• 不得在 MDX 正文中重复标题。 标题只能出现在 frontmatter 中。TL;DR 前不得添加 <h1> 或 # [Title]。
• 不得撰写结论章节。以要点段落或 FAQ 结束。

MDX 必须严格遵循以下结构：

---
title: "How [Company] [Achieved X] by [Core Strategy]"
description: "[1-2 sentence compelling summary with hard numbers]"
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**
* **Challenge:** [The core painful problem in the market they addressed]
* **Solution:** [What they specifically built or did differently]
* **Results:** [2–3 hard metrics — downloads, revenue, users, growth %]
* **Investment/Strategy:** [The one key strategic bet they made]

## The Problem
[Paint the before-state: What was the world like before this company's solution? Who was suffering, and what were they forced to do instead? Make it visceral use developer/founder language. Length: 2-3 paragraphs. No bullet points.]

## The Execution & GTM Strategy
[Break into 2–4 H3 sub-sections picking from: a) THE DISTRIBUTION STRATEGY, b) THE MONETIZATION LAYER, c) THE TECHNICAL / PRODUCT MOAT, d) THE INTERNAL DOGFOODING MOMENT, e) THE TIMING INSIGHT]
### [H3 Sub-section]
[Concept sentence. Mechanism. 1 Example.]

## The Results & Takeaways
[3–5 hard metrics in bullet points (downloads, revenue, customers, conversions, time saved)]

**What a small startup can take from them:**
[Actionable and specific takeaway connected directly to the target audience. Tie the lesson directly to the company's specific strategy. No generic advice.]

---

## Frequently Asked Questions

<FAQSection>
  <FAQItem question="[AEO Question 1 - e.g., What was their primary growth strategy?]">
    [Fully answered in 2-4 sentences. Never leave blank.]
  </FAQItem>

  <FAQItem question="[AEO Question 2 - e.g., How do they monetize?]">
    [Fully answered in 2-4 sentences. Never leave blank.]
  </FAQItem>
  
  <FAQItem question="[Promotion Question - e.g., How can my startup replicate this?]">
    [Answer explaining the strategy, followed by a subtle pitch for your brand/product: "If you are looking to build a predictable distribution engine like [Company], [YourBrand](https://yourdomain.com) specializes in engineering these exact growth loops. Book a strategy call to see if you are a fit."]
  </FAQItem>
</FAQSection>

</div>

• QA 测试员： 是否完全没有破折号？字数是否为 1,200 至 1,800 个单词？是否包含硬性指标？如果不是，请重写。

5. 质量保证（QA）检查

继续之前，请再次自查草稿：

• MDX 规则： 是否严格遵循 MDX 格式？是否完全没有破折号？
• 语气： 是否简洁有力且善于分析？
• 封面图片： 图片是否已生成并准备就绪？

6. 资源上传

• 将封面图片上传到用户指定的存储桶（例如 GCS、AWS S3、Cloudinary）。
• 命令：使用适当的 CLI 工具（例如 gsutil cp ./cover.png [TARGET_BUCKET]）。
• 确认公开 URL 与 MDX 中的 image: 字段一致。
• QA 测试员： 上传是否成功？请确认公开 URL 可访问。

7. GitHub 发布（直接推送）

• 使用 git CLI 克隆目标仓库：[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]"。
• 提交更改，并使用 git pull upstream main --rebase && git push upstream main（或等效的远程仓库配置）直接推送到 [TARGET_REPO_URL] 的远程分支。
• QA 测试人员： 构建是否通过？Git 推送是否成功？如果没有，请修复错误。

8. 验证与交付

• 务必完成此步骤： 任务完成之前，必须在仓库内运行 git log -1 和 git status，以证明文件已提交并推送。
• 给用户的最终回复必须包含：
  1. SerpAPI（Google Trends）研究的详细摘要。
  2. 已上传封面图片的公开 URL。
  3. git log -1 命令的实际输出，以证明工作已完成。
• 电子邮件通知： 还必须通过电子邮件将完全相同的最终摘要发送至 [ADMIN_EMAIL]。你可以快速编写并执行使用 smtplib 的 Python 脚本，通过配置的发件人邮箱和应用专用密码发送邮件。
• 最终 QA 测试人员： 你发送邮件了吗？最终消息中包含 git log 了吗？如果没有，则整个流程失败。