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/开发者工具构建者、产品驱动增长爱好者。
- 长度：1200-1800 个单词。
- 视角：第三人称分析，就像一份写给建设者观众的聪明投资人备忘录。
- 永远不要使用 em-dash（—）。
- 始终使用简单且口语化的英语，配合连接词。避免企业行话（"协同效应"、"杠杆"、"生态系统玩法"、"颠覆" -> 改用直白的语言）。
- 每个主张都必须让人觉得有证据或逻辑支持。使用具体数字。
- 每个 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 友好的 slug，例如 company-name-case-study]"
image: "[PUBLIC_IMAGE_URL]"
readingTime: "[X] Min"
published: true
---
<div style={{ textAlign: 'left' }}>
**TL;DR**
* **挑战：** [他们解决的市场核心痛点]
* **解决方案：** [他们具体构建或做了什么不同的事]
* **成果：** [2-3 个硬性指标——下载量、收入、用户、增长率]
* **投资/策略：** [他们做出的一个关键战略押注]
## The Problem
[描绘之前的状况：在这个公司的解决方案出现之前，世界是什么样的？谁在受苦，他们被迫用什么代替？使用开发者/创始人的语言使其生动。长度：2-3 段。不要使用要点。]
## The Execution & GTM Strategy
[分解为 2-4 个 H3 子部分，从以下选择：a) 分销策略，b) 货币化层，c) 技术/产品护城河，d) 内部吃狗粮时刻，e) 时机洞察]
### [H3 子部分]
[概念句。机制。1 个例子。]
## The Results & Takeaways
[3-5 个要点形式的硬性指标（下载量、收入、客户、转化率、节省的时间）]
**小型初创公司可以从中借鉴什么：**
[可操作且具体的收获，直接与目标受众相关。将经验教训与公司的具体策略联系起来。不要给出泛泛的建议。]
---
## Frequently Asked Questions
<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 测试员： em-dash 数量是否为 0？单词数是否在 1200-1800 之间？是否有硬性指标？如果没有，请重写。
5. 质量保证（QA）检查
在继续之前，再次自我审核草稿：
- MDX 规则： 是否严格遵循 MDX 格式？em-dash 数量是否严格为零？
- 语气： 是否犀利且具有分析性？
- 封面图像： 图像是否生成并准备就绪？
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]"。 - 提交更改并使用
git pull upstream main --rebase && git push upstream main（或等效的远程结构）直接推送到[TARGET_REPO_URL]的远程分支。 - QA 测试员： 构建是否通过？git push 是否成功？如果没有，修复错误。
8. 验证与交付
- 不要跳过此步骤： 在完成任务之前，您必须在仓库内运行
git log -1和git status，以证明文件已被提交和推送。 - 您对用户的最终回复必须包括：
- SerpAPI（Google Trends）研究的详细摘要。
- 上传的封面图像的公共 URL。
git log -1命令的实际输出，证明工作已完成。
- 邮件通知： 您还必须通过电子邮件将完全相同的最终摘要发送到
[ADMIN_EMAIL]。您可以快速编写并执行一个使用smtplib的 Python 脚本，使用配置的发件人邮箱和应用程序密码发送它。 - 最终 QA 测试员： 您是否发送了邮件？是否在最终消息中包含了 git log？如果没有，您就失败了整个流水线。