执行手册

从需求验证、发布上线到增长复盘的实操步骤，按卡片逐条推进。每本手册含前置条件、所需工具、执行步骤、验收标准与失败信号。

手册列表

统一执行框架

前置条件：明确目标用户、可用时间窗口、可调用工具与发布渠道。

验收标准：每一步均有可观察结果，能判断是否继续投入。

失败信号：连续两轮无关键指标改善，或用户反馈与假设明显冲突。

所需工具：基础分析面板、内容编辑器、发布平台账号与反馈收集表。

来源参考：各手册步骤依据 playbook-sources.md 中引用的 Indie Hackers、YC Library、Paul Graham、Stripe 和 Ahrefs 文档整理。

通用检查项

  • ☐ 关键步骤是否执行完成
  • ☐ 数据结果是否达到通过条件
  • ☐ 是否记录未通过原因并安排修正

通过条件：检查项全部完成，且有至少一项核心指标改善；否则判定未通过。

01

从零到一：AI 产品出海上线清单

从 idea 验证到正式上线的完整清单，覆盖产品、技术、支付和合规要点。

产品上线

前置条件

  • 有一个具体的目标用户画像（职业、痛点、使用场景）
  • 已确定至少 3 个同类竞品的存在（说明市场有需求）
  • 可用时间：连续 2 周每天 4 小时以上
  • 有 GitHub 账号、Vercel 或 Cloudflare Pages 账号
  • 有 OpenAI / Claude API Key（已测试可调用）

所需工具

  • 需求验证：Reddit Search、Google Trends、Ahrefs Webmaster Tools（免费版）
  • 原型：v0.dev 或 Bolt.new（快速生成 MVP UI）
  • 部署：Vercel（前端）+ Supabase（数据库，免费起步）
  • 支付：LemonSqueezy（无需海外实体）或 Stripe（需公司）
  • 监控：Sentry（错误）、Plausible 或 GA4（流量）
  • 反馈：Tally.so 或 Typeform（用户调研表）

执行步骤

实战案例：针对该手册给出一条可复用的真实执行样本与结果记录。

  1. 用户痛点验证（第 1-2 天）：在 Reddit 用关键词搜索目标赛道的抱怨帖，记录至少 10 条真实吐槽；同步用 Google Trends 确认搜索趋势向上
  2. 竞品拆解（第 3 天）：注册 3 个竞品，截图其核心功能、定价页、App Store 差评，填写竞品对比表（差异化机会栏必须填写）
  3. MVP 定义（第 4 天）：用一句话写出"谁用它做什么事，得到什么结果"，然后列出 MVP 的 3 个核心功能，超出范围一律不做
  4. 搭建 MVP（第 5-10 天）：用 v0.dev 生成初始 UI，接入 AI API 实现核心功能，部署到 Vercel/Cloudflare；不做用户注册系统，先用邮件收集
  5. 定价页上线（第 11 天）：添加定价方案（Free + $9/月 Pro）和付款按钮，接入 LemonSqueezy，走通完整支付链路
  6. SEO 基础配置（第 12 天）：设置 title/description/canonical，生成 sitemap.xml 和 robots.txt，提交 Google Search Console
  7. 上线前检查（第 13 天）：手动走通核心路径 3 遍，用不同设备测试移动端布局，确认错误监控已接入
  8. 发布（第 14 天）：在 Reddit、Twitter 发布公告，发 Show HN 帖，记录第一天的访问量和转化数据

验收标准（可检查）

  • 上线后 48 小时内有 100+ 独立访客（通过 Plausible 验证）
  • 至少 5 个用户走完核心功能，且无报错（Sentry 验证）
  • 定价页可点击，支付测试通过（LemonSqueezy 测试模式验证）
  • Google Search Console 已提交索引且无覆盖率错误
  • 获得 3 条以上真实用户文字反馈（邮件或调研表）

失败信号（何时暂停/回滚）

  • 上线 7 天后访客不足 50，说明选题方向或发布渠道有问题，暂停推广，重新做用户访谈
  • 用户到达定价页后离开率超过 90%，说明价值主张不清或定价有误，回滚到定价页修改
  • 核心功能报错率超过 10%，立即停止推广，优先修复
  • Reddit 帖被删除或用户反馈"这个已经有了"且竞品完全满足需求，重新评估差异化

可打勾检查清单

  • ☐ 记录了 10 条以上 Reddit 真实痛点
  • ☐ 完成 3 个竞品注册与功能对比表
  • ☐ MVP 核心功能已定义（3 个以内）
  • ☐ MVP 已部署到公开 URL
  • ☐ 定价页和支付链路已测试通过
  • ☐ SEO 基础配置完成（sitemap/robots/GSC）
  • ☐ 错误监控（Sentry）已接入
  • ☐ 上线公告已发布到至少 2 个渠道
  • ☐ 上线后 48 小时访客数已记录
  • ☐ 收到至少 3 条用户文字反馈

来源参考：YC "How to Plan an MVP"——MVP 需围绕"可验证假设"交付，而非功能完备度。Indie Hackers 实践：先明确人群-痛点-付费理由，再写任何代码。

02

SEO + 内容矩阵搭建指南

用 AI 高效搭建有机流量引擎，从关键词研究到内容生产的系统化方法。

SEO流量

前置条件

  • 产品已上线，有公开 URL 和可被索引的页面
  • 已提交 Google Search Console 并验证所有权
  • 有 Ahrefs（付费）或 Ahrefs Webmaster Tools + Ubersuggest（免费组合）账号
  • 确定内容语言（英文优先，面向全球用户）
  • 可投入：每周至少 6 小时用于内容生产与发布

所需工具

  • 关键词研究：Ahrefs（KD 筛选）、Google Search Console（已有排名词）、AnswerThePublic（问题型关键词）
  • 竞品分析：Ahrefs Site Explorer（竞品流量来源）
  • 内容生产：Claude API 或 ChatGPT（草稿）+ Grammarly（润色）
  • 发布平台：产品博客（Next.js / Ghost）或 Notion + Super.so
  • 内链追踪：Screaming Frog（免费版支持 500 页）
  • 排名监控：Google Search Console + SerpRobot（免费监控 10 词）

执行步骤

实战案例：针对该手册给出一条可复用的真实执行样本与结果记录。

  1. 种子关键词收集（第 1 天）：列出产品解决的 5 个核心问题，每个问题写 3-5 个搜索词，得到 15-25 个种子词
  2. 关键词扩展与筛选（第 2 天）：用 Ahrefs 对每个种子词扩展，筛选条件：KD < 30、月搜索量 > 200、有商业意图；目标积累 50-100 个关键词
  3. 关键词分层（第 3 天）：按用户旅程分 3 层——信息型（"how to..."）、比较型（"X vs Y"）、交易型（"best X tool"）；优先做交易型
  4. 内容大纲生成（每篇 2 小时）：抓取目标词 Top 5 排名文章的 H2/H3 结构，用 AI 生成综合大纲，人工补充独特视角和数据
  5. AI 写稿 + 人工润色（每篇 3-4 小时）：AI 负责初稿（1500-3000 字），人工添加：真实案例、具体数据、个人观点；检查无事实错误
  6. 技术 SEO 检查（每篇发布前）：确认 title 含目标词（60 字符内）、meta description（155 字符内）、URL 简短、图片有 alt 属性、至少 2 个内链
  7. 发布与索引提交（每篇 30 分钟）：发布后立即在 GSC 使用"URL 检查"手动请求索引，同时发 Twitter thread 预热
  8. 月度复盘（每月最后一天）：在 GSC 查看过去 28 天有点击但位置在 4-20 名的文章，选排名 4-10 的文章优先更新

验收标准（可检查）

  • 第 1 个月末：发布 12-20 篇文章，至少 5 篇被 Google 索引
  • 第 2 个月末：GSC 显示至少 10 个词有展示量，至少 2 篇文章有自然点击
  • 第 3 个月末：至少 1 篇文章排名进入目标词 Top 20
  • 内容质量标准：每篇文章包含至少 1 个具体数据点、1 个真实案例

失败信号（何时暂停/回滚）

  • 发布 20 篇后无任何文章被 GSC 收录，检查 robots.txt 是否误屏蔽爬虫，或 sitemap 是否正确提交
  • 3 个月后无任何关键词有展示量，说明关键词选择过于宽泛或竞争过高，重新筛选 KD < 15 的词
  • AI 生成内容被 Google 标记为 Spam 或流量骤降，立即停止 AI 批量发布，改为纯人工写作模式
  • 内容生产速度无法维持每周 3 篇，降低频率到每周 1-2 篇，保证质量优于数量

可打勾检查清单

  • ☐ Google Search Console 已验证并提交 sitemap
  • ☐ 积累了 50 个以上筛选后的目标关键词
  • ☐ 关键词已按信息型/比较型/交易型分层
  • ☐ 第一篇文章已发布并请求索引
  • ☐ 每篇文章发布前完成技术 SEO 检查
  • ☐ 内容发布节奏已确定（每周篇数）
  • ☐ 月度复盘已安排（日历提醒已设置）
  • ☐ 第 1 个月末：12 篇以上已发布
  • ☐ 第 2 个月末：GSC 显示自然点击
  • ☐ 至少 1 篇排名进入目标词 Top 20

来源参考：Ahrefs 关键词研究指南——从种子词出发构建关键词池，用难度与搜索量做优先级筛选。Google SEO Starter Guide——SEO 是长期迭代，先保证抓取/索引基础，再做内容优化。AI 负责效率，差异化仍需人工投入真实见解。

03

独立开发者出海支付集成攻略

对比 Stripe、LemonSqueezy、Paddle，降低支付试错成本，含完整集成步骤与合规要点。

支付合规

前置条件

  • 产品核心功能已可用，定价方案已确定（金额、周期、功能差异）
  • 已确定是否有海外注册实体（影响支付平台选择）
  • 网站已有独立域名和 HTTPS
  • 已准备好 Privacy Policy 和 Terms of Service 页面草稿
  • 开发环境已可运行 Webhook 本地调试（推荐用 ngrok）

所需工具

  • 无实体方案：LemonSqueezy（推荐，处理全球税务）或 Paddle（更适合 SaaS 场景）
  • 有实体方案：Stripe（功能最全，费率 2.9% + $0.30）
  • 本地调试：ngrok（Webhook 本地转发）、Stripe CLI（Stripe 专用）
  • 税务合规：Stripe Tax（自动计算各地区税率）、TaxJar（美国各州销售税）
  • 法律文件：Termly.io（Privacy Policy/ToS 生成器）
  • 测试卡号：Stripe 测试卡 4242 4242 4242 4242 / LemonSqueezy 测试模式

执行步骤

实战案例：针对该手册给出一条可复用的真实执行样本与结果记录。

  1. 选择支付平台（第 1 天）：无海外实体选 LemonSqueezy，注册时选"Software / SaaS"类别；有实体选 Stripe，准备 EIN 或公司注册文件
  2. 创建产品和定价（第 1 天）：在后台创建 Product → 添加 Price（按月/按年），设置试用期（如有），记录 Price ID
  3. 集成支付按钮（第 2 天）：使用平台提供的 Hosted Checkout（最快，1 小时内完成），将 Price ID 绑定到定价页按钮
  4. 配置 Webhook（第 2-3 天）：注册 Webhook 端点（本地用 ngrok），订阅关键事件：order_created（LemonSqueezy）或 checkout.session.completed + customer.subscription.deleted（Stripe）；在事件触发时更新用户权限
  5. 实现用户权限同步（第 3-4 天）：付款成功 → 数据库写入 plan=pro + 到期时间；订阅取消 → 写入 plan=free；退款 → 撤销权限
  6. 配置客户门户（第 4 天）：启用平台的 Customer Portal，让用户自助取消/升级/更换支付卡，减少客服工作量
  7. 税务和合规设置（第 5 天）：开启自动税务计算，确认结账页面显示含税价格，添加退款政策说明
  8. 全链路测试（第 6 天）：用测试卡走通：新用户订阅 → 功能解锁 → 取消订阅 → 功能撤销 → 退款 → 权限检查

验收标准（可检查）

  • 测试模式下完成完整支付链路：订阅 → 激活 → 取消 → 降级，每步均有数据库记录变化
  • Webhook 事件在后台日志中全部显示为 200 成功
  • 结账页面显示正确的产品名称、价格和税务信息
  • 客户门户可正常打开，用户可自助操作
  • Privacy Policy 和 Terms of Service 页面有效链接，结账页可点击访问
  • 退款流程测试通过，退款后用户权限在 5 分钟内降级

失败信号（何时暂停/回滚）

  • Webhook 持续失败（非 200 响应），立即检查服务器日志，不要上线，先在本地用 ngrok 复现
  • LemonSqueezy 审核拒绝注册，检查产品描述是否涉及违禁品类，或联系客服补充资质
  • 真实用户支付后收到报错，立即切换为维护模式，先退款，再排查 Webhook 逻辑
  • Stripe 账号被 hold（资金冻结），立即联系 Stripe 客服，补充合规材料，不要继续收款
  • 税务计算错误导致多收/少收，暂停新用户订阅，修复税率配置后重新上线

可打勾检查清单

  • ☐ 支付平台账号已注册并通过验证
  • ☐ 产品和定价已在后台创建，Price ID 已记录
  • ☐ 定价页支付按钮已集成
  • ☐ Webhook 端点已注册并订阅关键事件
  • ☐ 付款成功/取消/退款均触发正确的用户权限变更
  • ☐ 客户门户已启用
  • ☐ 税务自动计算已开启
  • ☐ Privacy Policy 和 ToS 页面已发布
  • ☐ 测试模式全链路已走通（含退款场景）
  • ☐ 切换为生产模式前再次确认测试通过

来源参考：Stripe Checkout 官方文档——建议先用托管结账页快速上线，减少支付接入复杂度。无海外实体时优先 LemonSqueezy 验证商业模式，月收入超过 $1000 后再考虑注册实体切换 Stripe。

04

Product Hunt 发布流程

发布前准备、发布日执行、发布后跟进的完整节奏，含素材规格和时区策略。

发布营销

前置条件

  • 产品已上线，核心功能稳定，无重大 Bug
  • 有英文版产品描述（tagline + 详细介绍）
  • 有 Twitter/X 账号，已有一定粉丝基础（>100 更佳）
  • 有支持者名单（可提前告知发布日期的群体，如早期用户、社群成员）
  • Product Hunt 账号注册超过 1 周（新号直接发布可信度低）

所需工具

  • 素材制作：Figma / Canva（Gallery 图）、Loom（演示视频录制）、Kapwing（GIF 制作）
  • 定时发布：Buffer 或 Typefully（社媒帖子排期）
  • 邮件通知：Mailchimp / Resend（给早期用户发发布通知）
  • 监控：Product Hunt 后台实时排名、Google Analytics 实时流量
  • 协作：Discord 或微信群（协调发布日的支持者同步 upvote）

执行步骤

实战案例：针对该手册给出一条可复用的真实执行样本与结果记录。

  1. 发布前 14 天——找 Hunter：联系 Product Hunt 社区有影响力的 Maker（followers > 1000），请求作为 Hunter；或自己提交（Maker 自提交同样有效）
  2. 发布前 10 天——准备素材：Logo（240×240 px，PNG，背景透明）、Gallery 图 3-5 张（1270×760 px）、演示 GIF 或视频（建议 30-60 秒），撰写 tagline（60 字符内，含核心价值主张，不用感叹号）
  3. 发布前 7 天——预热：在 Twitter 发"即将发布"预告，分享产品截图和使用场景，邀请早期用户加入等候列表
  4. 发布前 3 天——组织支持者：向早期用户、社群成员发送通知，告知发布日期和时间，请求在发布日关注并 upvote（不要说"帮我投票"，说"帮我看看"）
  5. 发布前 1 天——准备好发布用文案：写好所有社媒文案（Twitter、LinkedIn、Discord 群公告），提前存入 Buffer 待定时发送
  6. 发布日 00:01 PT——发布：太平洋时间 0 点 1 分（北京时间 16:01）提交；立即发布 Twitter 公告，触发 Buffer 定时帖，在所有关联社群同步消息
  7. 发布日全天——高频响应：每 30-60 分钟查看评论，逐条回复，展示创始人在线；发布 Launch Offer（限时折扣，72 小时内）；不要刷屏请人投票
  8. 发布后 24 小时——总结复盘：记录访客数、注册数、付费数、upvote 数；给所有评论者发私信感谢；将 "Product Hunt 入选" badge 添加到网站首页

验收标准（可检查）

  • 发布日结束时排名进入当日 Top 10（可接受 Top 20）
  • 获得 100+ upvote
  • 发布日获得 200+ 独立访客（通过 GA 实时数据验证）
  • 所有评论在 4 小时内收到回复
  • 至少收到 5 条有实质内容的用户评论

失败信号（何时暂停/回滚）

  • 发布后 2 小时 upvote < 10，且排名持续下滑——不要恐慌购买投票，检查社群通知是否正常发出，重新激活支持者群
  • 账号被 Product Hunt 标记为可疑（投票来源异常）——立即停止任何组织投票行为，联系客服解释，接受结果
  • 发布日网站宕机（访客涌入超负荷）——立即联系 Vercel/Cloudflare 支持，临时升级实例规格，在评论区说明并道歉
  • 发布后收到大量负面评论（产品问题）——诚实回应，当天发公告说明改进计划，不要删除批评性评论

可打勾检查清单

  • ☐ Product Hunt 账号注册超过 7 天
  • ☐ Hunter 已确认（或确认自提交）
  • ☐ Logo（240×240）已准备
  • ☐ Gallery 图（1270×760，3-5 张）已准备
  • ☐ 演示 GIF 或视频（30-60 秒）已准备
  • ☐ Tagline（60 字符内）已确认
  • ☐ 发布日社媒文案已写好并排期
  • ☐ 早期用户/支持者通知已发出
  • ☐ Launch Offer 已准备
  • ☐ 发布日有专人全天在线响应评论
  • ☐ 发布后 Badge 已添加到网站
  • ☐ 复盘数据已记录（访客/注册/付费/upvote）

来源参考：Paul Graham "Do Things That Don't Scale"——早期增长需要创始人主动参与，发布日的核心是前 4 小时的 upvote 速度。不要买票，建立真实支持者社群。

05

低成本获取前 1000 个海外用户

不靠广告投放，用内容和社群驱动方式获取种子用户，含 Reddit、Twitter 和合作渠道策略。

增长冷启动

前置条件

  • 产品已上线，至少有一个可用的免费方案或免费试用
  • 有基础的邮件收集机制（注册表单或 Mailchimp 订阅）
  • Reddit 账号已注册且账号年龄超过 2 周（防封号）
  • Twitter/X 账号已建立，有个人简介和头像（非空账号）
  • 明确产品的核心用户画像：他们在哪些社区聚集？

所需工具

  • 社区：Reddit（目标 subreddit 列表）、Indie Hackers、Hacker News
  • 社媒：Twitter/X + Typefully（排期工具）+ Hypefury（Thread 优化）
  • 邮件：Resend 或 Mailchimp（早期用户序列邮件）
  • 分析：Plausible（流量来源追踪，看哪个渠道带来最多注册）
  • CRM：Notion 表格（手动记录早期用户联系方式和反馈）
  • 内容工具：Canva（社媒配图）、Loom（演示视频）

执行步骤

实战案例：针对该手册给出一条可复用的真实执行样本与结果记录。

  1. 找准目标社区（第 1 周）：在 Reddit 搜索产品解决的问题，找到 3-5 个相关 subreddit（每个至少 10k 成员）；在 Indie Hackers 找到对应讨论帖；列出目标 Twitter 账号（同赛道的 maker、用户）
  2. Reddit 预热——先给后拿（第 1-2 周）：每天在目标 subreddit 回答 2-3 个问题，不提产品；发现与产品相关的帖子时，在评论区提供具体帮助，最后一句自然提及"我在做类似工具"
  3. Reddit 发布帖（第 2 周末）：用 Show HN 或 "I made a thing" 格式发布，标题格式：[产品名] — [解决什么问题] ([使用场景])；正文分享创业故事，附截图，结尾说"欢迎免费试用"
  4. Twitter Building in Public（每日）：每天发 1-2 条：一条产品进展（数据、里程碑）、一条行业观察；周五发"本周总结"thread（数字 + 学到什么 + 下周计划）；对同赛道 maker 的推文真诚回复
  5. Hacker News Show HN（第 3 周）：在太平洋时间周一至周三早 8-10 点发 "Show HN: [产品名] — [一句话描述]"；发布后全天回复每条评论；不要在 Show HN 发布后 24 小时内删除帖子
  6. 直接联系早期用户（持续）：找到在 Reddit 发过相关痛点帖的用户，发私信："看到你在 X 帖子里说了 [痛点]，我做了一个工具可能对你有帮助，愿意免费试用吗？"——每周联系 10-20 人
  7. 互补产品合作（第 4 周）：找到 3-5 个用户重叠但功能互补的产品，提议互相在 Newsletter 或社媒推荐；或做"联合工具包"内容（"5 个工具帮你做 X"）
  8. 转化早期用户为传播者（持续）：给每个付费用户发手写（AI 生成也行）感谢邮件，问他们愿不愿意写一句推荐语；把推荐语放到主页作为 social proof

验收标准（可检查）

  • 第 1 个月末：注册用户 50+，其中有 5 个以上主动提供了反馈
  • 第 2 个月末：注册用户 200+，有 3 个以上付费用户
  • 第 3 个月末：注册用户 500+，用户自发在社媒提及产品（无提示）至少 3 次
  • 流量来源：至少有 2 个渠道（Reddit、Twitter、HN）各自带来 20+ 注册

失败信号（何时暂停/回滚）

  • Reddit 帖子被删除或被大量举报——检查是否违反了 subreddit 规则，切换到另一个 subreddit，或调整发布策略（先评论后发帖）
  • Twitter 增粉停滞（3 周无增长）——检查内容类型，从"产品功能更新"转向"行业见解"或"创业经历"，这类内容传播更广
  • 直接联系用户被视为 Spam（收到多次投诉）——立即停止私信策略，改为公开内容吸引用户主动来找你
  • 3 个月后仍无付费用户——说明产品价值主张不够清晰或定价有问题，不是渠道问题；回到产品层面重新验证
  • 早期用户流失率超过 50%（注册后 7 天内不活跃）——说明核心功能未解决真实痛点，暂停增长，优先改产品

可打勾检查清单

  • ☐ 目标 subreddit 列表已确定（3-5 个）
  • ☐ Reddit 账号年龄超过 2 周
  • ☐ 在目标社区完成 2 周"先给后拿"预热
  • ☐ Reddit 发布帖已上线并全天响应评论
  • ☐ Twitter Building in Public 内容已开始每日输出
  • ☐ Show HN 帖已发布
  • ☐ 直接联系早期用户（每周 10-20 人）已执行
  • ☐ 至少找到 1 个互补产品合作对象
  • ☐ 每周流量来源数据已记录（Plausible）
  • ☐ 第 1 个月末：注册用户 50+
  • ☐ 第 2 个月末：注册用户 200+ 且有付费用户
  • ☐ 第 3 个月末：用户自发提及次数已记录

来源参考：Paul Graham "Do Things That Don't Scale"——早期增长需要手动拉用户，不要被"自动增长幻想"拖住。前 1000 个用户不需要 scale，需要深度连接。每一个早期用户都值得亲自回复和服务。Indie Hackers 实践：先提供价值，再提产品。

广告位占位 (728x90)