即刻App年轻人的同好社区
下载
靠 UGC 让一个 App 的年收入从 30 万美元涨到 150 万美元，其中第一个月 5000 万播放、45 万下载
最重要的一个点是，产品得先有一个能被拍出来的卖点。用户刷到视频那几秒，要马上看懂这个 App 能帮他改变什么，画面里最好还有一个能截图、能演示、能被不同创作者反复复用的核心瞬间
具体进行产品准备、创作者招聘、内容管理和设置 Spark Ads 的方法：
1. 先判断产品适不适合跑 UGC
第一，有一句话能讲清楚的卖点
第二，有一个能出现在画面里的核心瞬间
可以是截图值得分享的功能
可以是用户会自发晒出来的结果
可以是创作者拿着手机就能演示的使用场景
如果这个瞬间还没找到，先用自己的账号测内容，跑出一次自然爆款，再把钱投到 UGC 上
产品转化也要注意，下载到付费转化率最好 5% 以上，3% 也可以小规模试。onboarding、试用期后的 D3-D7 retention、付费墙表达都要先过一遍
2. 第一批创作者不要只看粉丝数
建议启动前至少准备 1.5 万美元现金
刚开始你不知道哪个会爆，也不知道多久能跑出第一个能转化的视频。真的爆了以后，你还需要快速加人、加素材、加预算
起步有两种方式：
1. 自己先发内容，找到爆款，再用 UGC 扩大
2. 先招 1-3 个创作者，一边发一边找爆款
创作者的筛选标准
- 每个人至少要有过 50 万播放的视频，最好做过同类竞品或强 UGC 项目
- 镜头前能不能自然说话
- hook delivery 行不行
- 会不会剪掉空白和废话
- 字幕位置会不会挡画面
- 是否真的属于你的 niche
- 能不能照着 script 稳定输出
- 沟通够快吗
付款形式：
- 每月 500-1000 美元，60 条视频
- 再按每 10 万播放给 20-100 美元奖金
- 通常设 100 万播放封顶，统计窗口是 1 周
可以压价，但别把创作者压到完全没动力。UGC 本质上是长期内容供给，不是一单外包素材
3. 账号和发布节奏
创作者的内容要同步发到 TikTok、Instagram、YouTube Shorts，必要时加 Snapchat
新账号建议先在 niche 里养号 1-3 天，每天 10-30 分钟，让账号的浏览、互动和内容方向先像一个真人
100-300 播放通常更像内容问题。真的 shadow ban 更接近每条都是 0 播放。所以第一周别急着怀疑账号，先看 hook、开头画面和 format
4. 用播放区间判断问题在哪
UGC 管理要先知道每天有多少播放、谁表现最好、为什么表现好
要想办法跟踪 creator views、engagement、comments 和 payout。没有这类工具时，也要先用表格把每条视频、创作者、发布时间、播放、下载、转化、奖金记录下来
判断问题可以按三个区间看
少于 1000 播放，优先改 hook
创作者 如果本身有过爆款经验，视频还一直卡在这个区间，通常是开头没抓住人
1000 到 1 万播放，优先看 retention
人点进来了，但没看完。要检查 创作者 的表达、脚本节奏、字幕、画面切换和中段信息密度
10 万以上播放但没下载，优先看 conversion
这时问题在 App 插入方式、CTA 时机、评论区承接、视频里的 demo 是否足够明确
比较能转化的内容通常有几个特征：
前 15 秒出现 App CTA
视频里有 App demo 或截图
评论区有人问 what's the app
视频里出现多次 CTA
caption 里也提到 App
常见高转化形式包括 UGC reaction + demo、talking head、和 App 强关联的 skit
5. 找到爆款后
这时候最容易犯的错是马上从 3 个 创作者 扩到 100 个
多数项目其实在 10-30 个 创作者 的区间范围里比较稳
内容策略方面，
80% 继续复制已经能转化的爆款格式，
20% 持续测新 hook、新脚本、新场景
可以用 Lightreel 盯竞品的新 hook，也会要求 创作者 上传视频时顺手把刷到的新内容格式发回来
UGC 素材会疲劳，尤其当你一天有几百万播放时，同一个风格几个月后转化就会下降。创作者每天刷同类内容，他们看到的新角度本身也是情报来源
6. 创作者文化会影响内容供给
很多 UGC 只把创作者当素材机器，所以创作者对项目没感情，内容也很交易化
可以把创作者放进一个群里，公开表扬表现好的内容，让创作者看到自己的视频带来了下载、评分、review、榜单变化
表现不合格的人也要快速处理。开掉某个人时，告知其原因
这套做法听起来重，但 UGC 扩大以后，本质上是在管理一支兼职内容团队。创作者愿意主动交好的内容形式、愿意继续合作、愿意拒绝竞品更高报价，这些都会影响后面的供给稳定性
7. 自然内容跑通后，再用 Spark Ads 放大
当你已经有 10-30 个创作者，且跑出了能转化的形式，就可以把同一批视频推到付费广告里
比较推荐 TikTok Spark Ads，因为它可以直接用创作者原帖做广告，保留自然播放、评论和 social proof。品牌账号自己上传同一条素材，信任感会弱很多
授权要在第一天就要谈好。每个创作者 都要提前同意 paid ad permission，避免某条素材跑出来以后才重新谈价
素材选择上，建议尽量多放，不要只放自然播放最高的视频。有些自然播放只有 300 的视频，在广告里也可能跑到几百万播放
投放参数先保持简单：
美国 broad campaign
每天至少 100 美元起步
ROAS 目标大于 1.5x
低于 1.5x 的素材关掉
7 天平均表现稳定后，每周加 15%-20%
建议用 MMP 做 attribution，不要只靠 TikTok 原生 SDK 判断回收
8. 可以这么开始
先用自己的账号测出一个能被拍出来的产品瞬间
然后把下载到付费转化率、onboarding、D3-D7 retention 看一遍，确认流量进来以后有机会变成收入
准备 1.5 万美元左右的测试资金，先招 1-3 个有 50 万播放经验的创作者
每人每月 60 条视频，基础加播放奖金，提前约定 Spark Ads 授权
所有内容同时发 TikTok、Instagram、YouTube Shorts
每天记录每条视频的播放、互动、评论、下载、转化和奖金
播放少于 1000 改 hook，1000 到 1 万改 retention，10 万以上没下载改 App 插入和 CTA
跑出能转化的内容风格后扩到 10-30 个 创作者，80% 押在已经跑通的内容上，20% 留给新想法试错
最后把素材放进 Spark Ads，从每天 100 美元开始，ROAS 低于 1.5x 就关，稳定后每周加 15%-20%
最重要的一个点是，产品得先有一个能被拍出来的卖点。用户刷到视频那几秒，要马上看懂这个 App 能帮他改变什么，画面里最好还有一个能截图、能演示、能被不同创作者反复复用的核心瞬间
具体进行产品准备、创作者招聘、内容管理和设置 Spark Ads 的方法：
1. 先判断产品适不适合跑 UGC
第一，有一句话能讲清楚的卖点
第二，有一个能出现在画面里的核心瞬间
可以是截图值得分享的功能
可以是用户会自发晒出来的结果
可以是创作者拿着手机就能演示的使用场景
如果这个瞬间还没找到，先用自己的账号测内容，跑出一次自然爆款，再把钱投到 UGC 上
产品转化也要注意，下载到付费转化率最好 5% 以上，3% 也可以小规模试。onboarding、试用期后的 D3-D7 retention、付费墙表达都要先过一遍
2. 第一批创作者不要只看粉丝数
建议启动前至少准备 1.5 万美元现金
刚开始你不知道哪个会爆，也不知道多久能跑出第一个能转化的视频。真的爆了以后，你还需要快速加人、加素材、加预算
起步有两种方式：
1. 自己先发内容，找到爆款，再用 UGC 扩大
2. 先招 1-3 个创作者，一边发一边找爆款
创作者的筛选标准
- 每个人至少要有过 50 万播放的视频，最好做过同类竞品或强 UGC 项目
- 镜头前能不能自然说话
- hook delivery 行不行
- 会不会剪掉空白和废话
- 字幕位置会不会挡画面
- 是否真的属于你的 niche
- 能不能照着 script 稳定输出
- 沟通够快吗
付款形式：
- 每月 500-1000 美元，60 条视频
- 再按每 10 万播放给 20-100 美元奖金
- 通常设 100 万播放封顶，统计窗口是 1 周
可以压价，但别把创作者压到完全没动力。UGC 本质上是长期内容供给，不是一单外包素材
3. 账号和发布节奏
创作者的内容要同步发到 TikTok、Instagram、YouTube Shorts，必要时加 Snapchat
新账号建议先在 niche 里养号 1-3 天，每天 10-30 分钟，让账号的浏览、互动和内容方向先像一个真人
100-300 播放通常更像内容问题。真的 shadow ban 更接近每条都是 0 播放。所以第一周别急着怀疑账号，先看 hook、开头画面和 format
4. 用播放区间判断问题在哪
UGC 管理要先知道每天有多少播放、谁表现最好、为什么表现好
要想办法跟踪 creator views、engagement、comments 和 payout。没有这类工具时，也要先用表格把每条视频、创作者、发布时间、播放、下载、转化、奖金记录下来
判断问题可以按三个区间看
少于 1000 播放，优先改 hook
创作者 如果本身有过爆款经验，视频还一直卡在这个区间，通常是开头没抓住人
1000 到 1 万播放，优先看 retention
人点进来了，但没看完。要检查 创作者 的表达、脚本节奏、字幕、画面切换和中段信息密度
10 万以上播放但没下载，优先看 conversion
这时问题在 App 插入方式、CTA 时机、评论区承接、视频里的 demo 是否足够明确
比较能转化的内容通常有几个特征：
前 15 秒出现 App CTA
视频里有 App demo 或截图
评论区有人问 what's the app
视频里出现多次 CTA
caption 里也提到 App
常见高转化形式包括 UGC reaction + demo、talking head、和 App 强关联的 skit
5. 找到爆款后
这时候最容易犯的错是马上从 3 个 创作者 扩到 100 个
多数项目其实在 10-30 个 创作者 的区间范围里比较稳
内容策略方面，
80% 继续复制已经能转化的爆款格式，
20% 持续测新 hook、新脚本、新场景
可以用 Lightreel 盯竞品的新 hook，也会要求 创作者 上传视频时顺手把刷到的新内容格式发回来
UGC 素材会疲劳，尤其当你一天有几百万播放时，同一个风格几个月后转化就会下降。创作者每天刷同类内容，他们看到的新角度本身也是情报来源
6. 创作者文化会影响内容供给
很多 UGC 只把创作者当素材机器，所以创作者对项目没感情，内容也很交易化
可以把创作者放进一个群里，公开表扬表现好的内容，让创作者看到自己的视频带来了下载、评分、review、榜单变化
表现不合格的人也要快速处理。开掉某个人时，告知其原因
这套做法听起来重，但 UGC 扩大以后，本质上是在管理一支兼职内容团队。创作者愿意主动交好的内容形式、愿意继续合作、愿意拒绝竞品更高报价，这些都会影响后面的供给稳定性
7. 自然内容跑通后，再用 Spark Ads 放大
当你已经有 10-30 个创作者，且跑出了能转化的形式，就可以把同一批视频推到付费广告里
比较推荐 TikTok Spark Ads，因为它可以直接用创作者原帖做广告，保留自然播放、评论和 social proof。品牌账号自己上传同一条素材，信任感会弱很多
授权要在第一天就要谈好。每个创作者 都要提前同意 paid ad permission，避免某条素材跑出来以后才重新谈价
素材选择上，建议尽量多放，不要只放自然播放最高的视频。有些自然播放只有 300 的视频，在广告里也可能跑到几百万播放
投放参数先保持简单：
美国 broad campaign
每天至少 100 美元起步
ROAS 目标大于 1.5x
低于 1.5x 的素材关掉
7 天平均表现稳定后，每周加 15%-20%
建议用 MMP 做 attribution，不要只靠 TikTok 原生 SDK 判断回收
8. 可以这么开始
先用自己的账号测出一个能被拍出来的产品瞬间
然后把下载到付费转化率、onboarding、D3-D7 retention 看一遍，确认流量进来以后有机会变成收入
准备 1.5 万美元左右的测试资金，先招 1-3 个有 50 万播放经验的创作者
每人每月 60 条视频，基础加播放奖金，提前约定 Spark Ads 授权
所有内容同时发 TikTok、Instagram、YouTube Shorts
每天记录每条视频的播放、互动、评论、下载、转化和奖金
播放少于 1000 改 hook，1000 到 1 万改 retention，10 万以上没下载改 App 插入和 CTA
跑出能转化的内容风格后扩到 10-30 个 创作者，80% 押在已经跑通的内容上，20% 留给新想法试错
最后把素材放进 Spark Ads，从每天 100 美元开始，ROAS 低于 1.5x 就关，稳定后每周加 15%-20%
6 02
Firecrawl 又出神作，一个非常高效节约的 pdf 解析工具 - pdf-inspector，完全开源免费
会先在本地判断 PDF 是文字版、扫描版、图片版还是混合版。文字版直接抽文本和表格，扫描页再丢给 OCR，避免每份文件都走一遍又贵又慢的 OCR。
拿 200 份 PDF 跑了几个开源主流 pdf 解析项目的性能测试，pdf-inspector 总分排第一，200 个文档只用了 0.47 秒，遥遥领先了！Rust 还是强啊，同时给 Python、Node、WASM、CLI 绑定，适合接进 RAG、爬虫、财报/论文/法律文档等处理
会先在本地判断 PDF 是文字版、扫描版、图片版还是混合版。文字版直接抽文本和表格，扫描页再丢给 OCR，避免每份文件都走一遍又贵又慢的 OCR。
拿 200 份 PDF 跑了几个开源主流 pdf 解析项目的性能测试，pdf-inspector 总分排第一，200 个文档只用了 0.47 秒，遥遥领先了！Rust 还是强啊，同时给 Python、Node、WASM、CLI 绑定，适合接进 RAG、爬虫、财报/论文/法律文档等处理
54 128
这份清单有参考价值，但别把 Reddit 当成免费的广告位
17 个 subreddit，背后其实是 17 种不同的人群和社区规则
大社区不一定更有效，精准度、内容匹配和参与方式，比所谓“月访问量”重要得多
另外个人建议要把握的核心原则：
- 先贡献，再推广
- 先理解社区，再发布产品
17 个 subreddit，背后其实是 17 种不同的人群和社区规则
大社区不一定更有效，精准度、内容匹配和参与方式，比所谓“月访问量”重要得多
另外个人建议要把握的核心原则：
- 先贡献，再推广
- 先理解社区，再发布产品
5 01
一套自动涨 Reddit Karma 的 AI Agent 5 个核心要素：
可信内容源
严格筛选
便宜触发闸门
执行账本
定期复盘
具体操作大概是
1. 先给 agent 一个可信内容源
先建了一个个人 wiki，里面放过去的视频、文章、资料和长期关注的话题
agent 每次回答前，只能从 wiki 里找已经记录过的观点。agent 可以读 Reddit 页面，但不能靠记忆重建作者立场。
AI 自动评论最容易变成泛泛的「helpful developer」语气，看起来很会答，实际每句话都像平台上任何一个 AI 助手都能说
wiki 的作用就是把 agent 能说的话限制在你自己真的经历过、写过、踩过的坑里。
如果要迁移到别的场景，wiki 可以换成：
过往文章
客户问答
产品文档
内部 SOP
销售电话记录
自己做项目时留下的复盘
先限定它能说什么，再让它去找机会说！
2. 筛选要比生成更重要
帖子是否在 48 小时内
评论区气氛是否正常
问题是否真的是现下真实痛点
wiki 里有没有对应的具体经验
评论区是否已经有人占了同一个角度
最后一条尤其关键。如果别人已经给了一个好答案，agent 要么补一个完全不同的具体角度，要么直接跳过。
3. 触发前先过便宜 workflow
每半小时触发一次，但每次触发后，先跑一个很便宜的 deterministic workflow
检查账号 ledger、21 分钟间隔、当天评论上限，再随机决定这个 slot 要不要升级成真正的 agent 来执行
大部分 slot 会直接结束，只留一行日志。只有少数 slot 会唤醒 LLM，开始找帖、筛选、写评论
对了，这个设计其实可以迁移到很多 agent loop：
固定 cron 负责可靠性
便宜 workflow 负责限频、随机、账号检查之类的简单任务
核心 agent 只在值得执行的时候来
4. 每次执行都要留下记录
没有记录，agent 很快会变成黑箱。你只知道它跑了，但不知道它为什么选这个帖子、为什么放弃另一个帖子、哪类场景最容易出错
至少要记这些字段：
候选来源
是否执行
执行内容
跳过原因
使用了哪个 wiki 角度
当时的账号状态
后续结果
一开始不要追求自动优化，先让系统把判断过程留下来。没有记录，就没有下周的改进。
5. 每周用真实结果改策略
重新抓取过去一周发过的评论，记录每条评论拿到的分数和 karma 变化，再按 subreddit 和 topic angle 做统计，比如：
哪些 subreddit 能带来 upvote
哪些话题角度一直没人理
哪些回答方式值得继续用
哪些来源应该退休
下周的 slot 和角度会根据这些结果调整。有效的 subreddit 和 angle 会拿到更多机会，没反应的会被删掉或重写
更稳的借鉴方式，是把这套结构用在低风险场景里：
- 自动整理客户反馈
- 自动扫描 GitHub issue
- 自动发现社区里的真实问题
- 自动给内部知识库补标签
- 自动从 support ticket 里找重复痛点
- 自动复盘内容或销售动作的结果
可信内容源
严格筛选
便宜触发闸门
执行账本
定期复盘
具体操作大概是
1. 先给 agent 一个可信内容源
先建了一个个人 wiki，里面放过去的视频、文章、资料和长期关注的话题
agent 每次回答前，只能从 wiki 里找已经记录过的观点。agent 可以读 Reddit 页面，但不能靠记忆重建作者立场。
AI 自动评论最容易变成泛泛的「helpful developer」语气，看起来很会答，实际每句话都像平台上任何一个 AI 助手都能说
wiki 的作用就是把 agent 能说的话限制在你自己真的经历过、写过、踩过的坑里。
如果要迁移到别的场景，wiki 可以换成：
过往文章
客户问答
产品文档
内部 SOP
销售电话记录
自己做项目时留下的复盘
先限定它能说什么，再让它去找机会说！
2. 筛选要比生成更重要
帖子是否在 48 小时内
评论区气氛是否正常
问题是否真的是现下真实痛点
wiki 里有没有对应的具体经验
评论区是否已经有人占了同一个角度
最后一条尤其关键。如果别人已经给了一个好答案，agent 要么补一个完全不同的具体角度，要么直接跳过。
3. 触发前先过便宜 workflow
每半小时触发一次，但每次触发后，先跑一个很便宜的 deterministic workflow
检查账号 ledger、21 分钟间隔、当天评论上限，再随机决定这个 slot 要不要升级成真正的 agent 来执行
大部分 slot 会直接结束，只留一行日志。只有少数 slot 会唤醒 LLM，开始找帖、筛选、写评论
对了，这个设计其实可以迁移到很多 agent loop：
固定 cron 负责可靠性
便宜 workflow 负责限频、随机、账号检查之类的简单任务
核心 agent 只在值得执行的时候来
4. 每次执行都要留下记录
没有记录，agent 很快会变成黑箱。你只知道它跑了，但不知道它为什么选这个帖子、为什么放弃另一个帖子、哪类场景最容易出错
至少要记这些字段：
候选来源
是否执行
执行内容
跳过原因
使用了哪个 wiki 角度
当时的账号状态
后续结果
一开始不要追求自动优化，先让系统把判断过程留下来。没有记录，就没有下周的改进。
5. 每周用真实结果改策略
重新抓取过去一周发过的评论，记录每条评论拿到的分数和 karma 变化，再按 subreddit 和 topic angle 做统计，比如：
哪些 subreddit 能带来 upvote
哪些话题角度一直没人理
哪些回答方式值得继续用
哪些来源应该退休
下周的 slot 和角度会根据这些结果调整。有效的 subreddit 和 angle 会拿到更多机会，没反应的会被删掉或重写
更稳的借鉴方式，是把这套结构用在低风险场景里：
- 自动整理客户反馈
- 自动扫描 GitHub issue
- 自动发现社区里的真实问题
- 自动给内部知识库补标签
- 自动从 support ticket 里找重复痛点
- 自动复盘内容或销售动作的结果
22 013
一个现实版 Pokédex，用户拿手机扫野外动物，识别后完成捕捉、收藏和稀有度揭示。两周自然流量做到 700 万+ 播放、3.2 万+ 活跃用户，广告花费为 0。
1. 先把产品讲成一句话
Gotcha 没把自己讲成 AI wildlife identifier，而是现实版 Pokémon Go
这个表达很重要，因为用户不用学新概念。听到这句话，他马上知道这东西有收集、有稀有度、有完成图鉴的冲动，也知道为什么可以拿给朋友看
消费 App 尤其要过这一关。功能解释越长，传播越难。第一版定位可以先问一个问题，用户听完一句话之后，能不能马上转述给朋友？
如果转述需要解释 20 秒，短视频第一秒就很难撑住。
2. 验证行为循环，再做具体 idea
作者没有先证明世界上已经有人做过一模一样的 Gotcha。他先看的，是用户本来就喜欢哪些行为
Gotcha 背后的产品循环：
发现
收集
稀有度
惊喜
完成收藏
这些行为早就在 Pokémon、抽卡、开盲盒、loot box、pack opening 里被验证过。具体产品可以变，人的情绪循环已经存在
做 App idea 的时候，不一定要问「有没有人做过同款」。更该问的是，用户有没有在别的场景里反复做过这件事。
3. 产品里先做一个能被拍下来的瞬间（传播点）
作者把每次捕捉设计成固定顺序：
找到动物
手机扫描
等待识别
揭示结果
显示稀有度
庆祝捕捉成功
这套顺序天然就是视频脚本，用户看到的是一段带悬念的过程。前几秒让人想知道「这到底能不能识别出来」，最后用结果和稀有度给情绪反馈
做消费 App 时，可以先倒过来想。如果要拍一条 10 秒视频，最适合被拍出来的是哪一个产品瞬间？
如果产品里没有这种瞬间，营销就会变成硬讲功能。
4. 短视频不要从功能开始拍
Gotcha 的有效视频结构不是打开 App 然后介绍按钮。它直接拍反应、动物、扫描、揭示结果。普通用户看到的是惊讶感，Pokémon 用户看到的是怀旧感
前三秒很关键，现实里可能只有一秒。第一帧必须让人有反应，后面才有机会解释产品
对 App 来说，素材可以按这个顺序拆：
先给一个能看懂的场景
再让用户期待结果
中间保留一点悬念
最后展示产品带来的变化
能让人截图、转发、拿给朋友看的画面，比一段完整的功能介绍更重要。
5. TOF 和 BOF 分开做
TOF 负责触达
Gotcha 的 TOF 是「现实版 Pokémon Go」这种简单、怀旧、容易爆量的内容
带来的用户很杂，转化率可能只有 0.5% 到 2%，但目标是让更多人看到
BOF 负责转化
播放量可以低一点，但内容要让用户相信这个 App 真的能用
比如 talking head、真实玩法、产品解释、更新内容、创始人个人露出
很多 App 素材会卡在这里。想让一条视频同时爆量、讲清楚功能、建立信任、完成转化，通常会互相拖累。先用 TOF 把人带到主页，再让 BOF 接住有兴趣的人。
6. 跑出一个素材后，不急着换方向
Gotcha 跑出「现实版 Pokémon Go」这个 hook 后，没有马上找新主题
他重复同一个概念，只换动物、反应、声音、揭示画面。对平台来说，每条视频面对的都是新用户，重复不等于浪费
消费 App 的第一批内容可以先围绕一个赢过的结构做 10 条变体。换开场画面、换使用场景、换结果、换人物反应，先确认这个结构是不是稳定
如果每条都换一个方向，很难判断到底是 idea 不行、素材不行，还是第一帧不行。
7. 评论区要能承接下载意图
把 App 名字留给评论区讨论，让用户在评论区问入口。每条「哪里下载」都会带来互动，也能触发自动 DM，把下载链接发过去
这个做法的重点，是把评论区变成转化入口。视频负责制造好奇，评论负责增加互动，自动 DM 负责把链接送到用户手里
如果要做最小版，先确认评论里真的有人问下载、问名字、问入口，再决定要不要上自动 DM 工具
最后总结成一句可操作的话
一句话定位，
产品里的可拍摄瞬间，
10 条同结构短视频，
主页里的 BOF 内容，
评论区下载入口
跑完这一轮，再看完播、分享、保存、评论和真实打开 App 的人数。
1. 先把产品讲成一句话
Gotcha 没把自己讲成 AI wildlife identifier，而是现实版 Pokémon Go
这个表达很重要，因为用户不用学新概念。听到这句话，他马上知道这东西有收集、有稀有度、有完成图鉴的冲动，也知道为什么可以拿给朋友看
消费 App 尤其要过这一关。功能解释越长，传播越难。第一版定位可以先问一个问题，用户听完一句话之后，能不能马上转述给朋友？
如果转述需要解释 20 秒，短视频第一秒就很难撑住。
2. 验证行为循环，再做具体 idea
作者没有先证明世界上已经有人做过一模一样的 Gotcha。他先看的，是用户本来就喜欢哪些行为
Gotcha 背后的产品循环：
发现
收集
稀有度
惊喜
完成收藏
这些行为早就在 Pokémon、抽卡、开盲盒、loot box、pack opening 里被验证过。具体产品可以变，人的情绪循环已经存在
做 App idea 的时候，不一定要问「有没有人做过同款」。更该问的是，用户有没有在别的场景里反复做过这件事。
3. 产品里先做一个能被拍下来的瞬间（传播点）
作者把每次捕捉设计成固定顺序：
找到动物
手机扫描
等待识别
揭示结果
显示稀有度
庆祝捕捉成功
这套顺序天然就是视频脚本，用户看到的是一段带悬念的过程。前几秒让人想知道「这到底能不能识别出来」，最后用结果和稀有度给情绪反馈
做消费 App 时，可以先倒过来想。如果要拍一条 10 秒视频，最适合被拍出来的是哪一个产品瞬间？
如果产品里没有这种瞬间，营销就会变成硬讲功能。
4. 短视频不要从功能开始拍
Gotcha 的有效视频结构不是打开 App 然后介绍按钮。它直接拍反应、动物、扫描、揭示结果。普通用户看到的是惊讶感，Pokémon 用户看到的是怀旧感
前三秒很关键，现实里可能只有一秒。第一帧必须让人有反应，后面才有机会解释产品
对 App 来说，素材可以按这个顺序拆：
先给一个能看懂的场景
再让用户期待结果
中间保留一点悬念
最后展示产品带来的变化
能让人截图、转发、拿给朋友看的画面，比一段完整的功能介绍更重要。
5. TOF 和 BOF 分开做
TOF 负责触达
Gotcha 的 TOF 是「现实版 Pokémon Go」这种简单、怀旧、容易爆量的内容
带来的用户很杂，转化率可能只有 0.5% 到 2%，但目标是让更多人看到
BOF 负责转化
播放量可以低一点，但内容要让用户相信这个 App 真的能用
比如 talking head、真实玩法、产品解释、更新内容、创始人个人露出
很多 App 素材会卡在这里。想让一条视频同时爆量、讲清楚功能、建立信任、完成转化，通常会互相拖累。先用 TOF 把人带到主页，再让 BOF 接住有兴趣的人。
6. 跑出一个素材后，不急着换方向
Gotcha 跑出「现实版 Pokémon Go」这个 hook 后，没有马上找新主题
他重复同一个概念，只换动物、反应、声音、揭示画面。对平台来说，每条视频面对的都是新用户，重复不等于浪费
消费 App 的第一批内容可以先围绕一个赢过的结构做 10 条变体。换开场画面、换使用场景、换结果、换人物反应，先确认这个结构是不是稳定
如果每条都换一个方向，很难判断到底是 idea 不行、素材不行，还是第一帧不行。
7. 评论区要能承接下载意图
把 App 名字留给评论区讨论，让用户在评论区问入口。每条「哪里下载」都会带来互动，也能触发自动 DM，把下载链接发过去
这个做法的重点，是把评论区变成转化入口。视频负责制造好奇，评论负责增加互动，自动 DM 负责把链接送到用户手里
如果要做最小版，先确认评论里真的有人问下载、问名字、问入口，再决定要不要上自动 DM 工具
最后总结成一句可操作的话
一句话定位，
产品里的可拍摄瞬间，
10 条同结构短视频，
主页里的 BOF 内容，
评论区下载入口
跑完这一轮，再看完播、分享、保存、评论和真实打开 App 的人数。
1 04
每次有新的更聪明的模型发布都要定期清理一下上下文，避免浪费 Toke（钱）！
可以按照 claude 官方的 Thariq 在一篇文章中的一些建议来优化应该能省下不少 Token，不过我甚至觉得更高效的方式是 可以直接先全部删掉，用的过程中哪里变笨了再把原来的一些配置加回来😂
1. 先查绝对规则
先去 system prompt、CLAUDE.md、Skill 里搜这些词
always
never
must
do not
这类词经常藏着过时规则。比如早期为了防止 Claude 乱写注释，system prompt 里可能会写「不要写注释」「docstring 只能一行」「不要创建 plan 文件」之类的
这些规则在旧模型上有用，但放到现在很容易出问题。用户可能明确要文档，repo 里可能本来就有详细 docstring，某个 Skill 也可能要求先写 plan。Claude 看到这些冲突，只能先花力气判断谁优先
👉 Anthropic 后来的写法是让 Claude 写得像周围代码，跟着项目已有的注释密度、命名和风格走
这句话比「永远不要写注释」更像一个可迁移的判断标准。
2. 工具说明
以前经常会在 system prompt 里反复解释工具怎么用，老担心模型会忘。新模型更适合直接从工具接口里读行为
工具的参数名、枚举值、默认值、错误信息，本身就是上下文。与其在 system prompt 里重复说明，不如把工具接口设计清楚。
3. CLAUDE.md
CLAUDE.md 最容易变成垃圾桶。项目背景也往里放，个人偏好也往里放，测试命令也往里放，最后 Claude 每次启动都要读一大堆未必用得上的东西。
更稳的写法是只留项目特有信息，比如
这个 repo 做什么，让 Claude 知道项目边界、主要模块、常见入口
代码库里有哪些坑，比如类型只能放在某个文件，测试必须用某个脚本，某个目录不能随便改
更多上下文去哪里找，比如复杂验证流程看 skills/verification.md，API 设计偏好看 references/api-rubric.md
文件系统一眼能看出来的东西，通用工程常识，某个任务才会用到的长说明，都不该长期堆在 CLAUDE.md 顶层。
4. 长 Skill 拆成按需加载（progressive disclosure）
以前会把 code review、verification、项目规范、工具说明全部塞到前面，担心 Claude 找不到。现在可以拆成多个 Skill 或 reference，让 Claude 按需加载
适合拆出去的内容包括：
- code review 规则
- verification 流程
- release checklist
- API 设计偏好
- UI mockup 规范
- 特定任务的操作 SOP
Skill 主文件只写触发条件、最短路径和索引
细节放进 references
平时不占上下文，真要用时还能找到完整材料。
5. reference
以前的 reference 经常是一份 spec.md 或 plan.md。新模型能吃更复杂的材料，没必要全都翻译成自然语言说明
原文提到l额几类更好的 reference：
- HTML artifact，比截图更容易表达 UI 结构
- 测试套件，直接告诉 Claude 行为边界
- 另一份代码库里的函数，方便 Claude 按实现迁移
- rubric，用来让 verifier agent 检查结果是否符合你的口味
做 coding agent 时，代码和测试经常比长段解释更清楚。能用测试表达的约束，就别写成需求文档。
6. 最后用 /doctor 或人工 review 瘦身
Claude Code 里可以用 /doctor 或 claude doctor 检查 Skills 和 CLAUDE.md 是否过重
人工看也可以按这几个问题来检查：
这条规则还适合现在的模型吗？
这条规则会不会和用户请求或 repo 约定冲突？
这段说明能不能放回 tool description？
这段内容平时真的需要一直加载吗？
这份 reference 能不能换成测试、HTML mockup、代码或 rubric？
第一轮删重复提醒，删过时护栏，拆长文档，把真正会影响项目结果的坑留在 CLAUDE.md 里就好了
可以按照 claude 官方的 Thariq 在一篇文章中的一些建议来优化应该能省下不少 Token，不过我甚至觉得更高效的方式是 可以直接先全部删掉，用的过程中哪里变笨了再把原来的一些配置加回来😂
1. 先查绝对规则
先去 system prompt、CLAUDE.md、Skill 里搜这些词
always
never
must
do not
这类词经常藏着过时规则。比如早期为了防止 Claude 乱写注释，system prompt 里可能会写「不要写注释」「docstring 只能一行」「不要创建 plan 文件」之类的
这些规则在旧模型上有用，但放到现在很容易出问题。用户可能明确要文档，repo 里可能本来就有详细 docstring，某个 Skill 也可能要求先写 plan。Claude 看到这些冲突，只能先花力气判断谁优先
👉 Anthropic 后来的写法是让 Claude 写得像周围代码，跟着项目已有的注释密度、命名和风格走
这句话比「永远不要写注释」更像一个可迁移的判断标准。
2. 工具说明
以前经常会在 system prompt 里反复解释工具怎么用，老担心模型会忘。新模型更适合直接从工具接口里读行为
工具的参数名、枚举值、默认值、错误信息，本身就是上下文。与其在 system prompt 里重复说明，不如把工具接口设计清楚。
3. CLAUDE.md
CLAUDE.md 最容易变成垃圾桶。项目背景也往里放，个人偏好也往里放，测试命令也往里放，最后 Claude 每次启动都要读一大堆未必用得上的东西。
更稳的写法是只留项目特有信息，比如
这个 repo 做什么，让 Claude 知道项目边界、主要模块、常见入口
代码库里有哪些坑，比如类型只能放在某个文件，测试必须用某个脚本，某个目录不能随便改
更多上下文去哪里找，比如复杂验证流程看 skills/verification.md，API 设计偏好看 references/api-rubric.md
文件系统一眼能看出来的东西，通用工程常识，某个任务才会用到的长说明，都不该长期堆在 CLAUDE.md 顶层。
4. 长 Skill 拆成按需加载（progressive disclosure）
以前会把 code review、verification、项目规范、工具说明全部塞到前面，担心 Claude 找不到。现在可以拆成多个 Skill 或 reference，让 Claude 按需加载
适合拆出去的内容包括：
- code review 规则
- verification 流程
- release checklist
- API 设计偏好
- UI mockup 规范
- 特定任务的操作 SOP
Skill 主文件只写触发条件、最短路径和索引
细节放进 references
平时不占上下文，真要用时还能找到完整材料。
5. reference
以前的 reference 经常是一份 spec.md 或 plan.md。新模型能吃更复杂的材料，没必要全都翻译成自然语言说明
原文提到l额几类更好的 reference：
- HTML artifact，比截图更容易表达 UI 结构
- 测试套件，直接告诉 Claude 行为边界
- 另一份代码库里的函数，方便 Claude 按实现迁移
- rubric，用来让 verifier agent 检查结果是否符合你的口味
做 coding agent 时，代码和测试经常比长段解释更清楚。能用测试表达的约束，就别写成需求文档。
6. 最后用 /doctor 或人工 review 瘦身
Claude Code 里可以用 /doctor 或 claude doctor 检查 Skills 和 CLAUDE.md 是否过重
人工看也可以按这几个问题来检查：
这条规则还适合现在的模型吗？
这条规则会不会和用户请求或 repo 约定冲突？
这段说明能不能放回 tool description？
这段内容平时真的需要一直加载吗？
这份 reference 能不能换成测试、HTML mockup、代码或 rubric？
第一轮删重复提醒，删过时护栏，拆长文档，把真正会影响项目结果的坑留在 CLAUDE.md 里就好了
2 00
把握这三个点找到月入 10 万美元赚钱的 App 点子：
- 用户已经在搜了吗
- 关键词还有机会打吗
- 同类产品已经有人付费吗
具体的操作：
1. 先用 Google Trends 找正在变火的需求，看看真实的用户在搜什么
这里主要看趋势方向，绝对搜索量放到后面再判断。一个词如果已经开始快速往上走，还没有明显见顶，就值得继续挖
第一轮看两件事
- 这个需求是不是在持续上升
- 这个上升是不是和真实用户行为有关
如果只是短期新闻、梗、节日热点，后面要更谨慎。你要找的是可以做成产品的需求，不只是可以写一条内容的热点。
2. 去 rising queries 里找更窄的入口
大词只能告诉你方向变热，小词（用户在这个大方向里还在搜什么更具体的问题）才告诉你从哪里切进去。
这个切口更适合新 App。服务一个具体人群和具体搜索意图，比泛泛做训练 App 更容易打进去
找这种词时，优先看三类
a. 带人群的词，比如 women、beginners、over 40、students
b. 带目标的词，比如 abs、weight loss、posture、meal prep
c. 带场景的词，比如 at home、no equipment、after pregnancy、for busy people
切入点越具体，越容易写清楚 App Store 标题、截图、onboarding 和 paywall。泛词适合大公司，新 App 更适合从小词开始打。
3. 用 ASO 看关键词能不能打
- 热度高于 20，说明有人搜
- 难度低于 60，说明还没完全被大 App 占死
这里特别要注意，热度高、难度也高，通常不适合新 App 直接硬打。热度低、难度低，也可能只是没人关心
更好的组合是中高热度 + 中低难度。说明用户已经在找，但当前供给还不够强。
4. 用 Sensor Tower 看有没有真实收入
因为搜索兴趣不等于付费需求
要去 Sensor Tower 看同类 App 有没有收入。不要找一个完全没人做的方向。对独立开发者来说，零竞争反而很危险，因为你很难判断用户会不会付费
这一步可以把很多伪需求筛掉
有人搜，但同类 App 没收入，可能只是内容需求
有人搜，同类 App 也赚钱，才可能是产品机会
判断时可以看这些信号：
同类 App 是否稳定有收入
头部 App 收入有没有明显增长
收入是否集中在少数老产品手里
评论区用户到底在抱怨什么
现有产品有没有明显做得差的地方。
5. 三个信号都过，再做第一版
趋势在涨
关键词能打
同类产品已经赚钱
这三个条件一起出现，说明你在顺着一个已经出现的需求窗口做产品了
通用的做法：
先下载头部竞品
把 onboarding 每一屏截图
丢给 Claude 分析
让 Claude 设计一个更好的流程
再让 Claude 按一屏一屏拆出新版 onboarding
最后用你熟悉的工具把第一版做出来
这一步的重点是先把产品流程想清楚，不要直接写代码。
你可以这样跟 Claude 聊：
我想做一个面向「具体人群」的「具体目标」App，下面是 3 个竞品的新手流程截图，请你帮我做 4 件事：第一，拆出每个竞品的新手流程顺序；第二，指出每一步在解决什么用户心理；第三，找出哪里可能导致用户流失；第四，重新设计一个更短、更适合转化付费用户的 onboarding，按屏幕输出。输出时按 Screen 1、Screen 2、Screen 3 写，每一屏包含标题、正文、按钮和用户看到这一屏后的心理预期。
6. 第一版要快
如果一个需求词刚开始涨，关键词还有机会打，竞品收入也已经验证，最好不要花 6 个月慢慢打磨
第一版只要完成几个东西：
一个能解决核心需求的功能
一个能承接搜索词的 App Store 页面
一个能解释结果的 onboarding
一个能测试付费意愿的 paywall
基础埋点和订阅
一开始不做太多附加功能。需求窗口还在的时候，先拿到真实下载、转化和付费数据。
最小版本可以这样：
第一天，列 20 个你熟悉领域里的增长词
第二天，用 Google Trends 看哪些词在上升
第三天，从 rising queries 里找 5 个更窄切口
第四天，用 ASO 工具看热度和难度
第五天，用 Sensor Tower 看同类 App 有没有收入
第六天，选一个三项都过的方向，拆 3 个竞品 onboarding
第七天，用 Claude 生成新版流程，开始做第一版
这套方法最适合找小型消费 App、工具 App、健身/效率/外貌/习惯类 App 。
最后在做产品前再回顾一下这三个问题：
用户已经在搜了吗？
关键词还有机会打吗？
同类产品已经有人付费吗？
- 用户已经在搜了吗
- 关键词还有机会打吗
- 同类产品已经有人付费吗
具体的操作：
1. 先用 Google Trends 找正在变火的需求，看看真实的用户在搜什么
这里主要看趋势方向，绝对搜索量放到后面再判断。一个词如果已经开始快速往上走，还没有明显见顶，就值得继续挖
第一轮看两件事
- 这个需求是不是在持续上升
- 这个上升是不是和真实用户行为有关
如果只是短期新闻、梗、节日热点，后面要更谨慎。你要找的是可以做成产品的需求，不只是可以写一条内容的热点。
2. 去 rising queries 里找更窄的入口
大词只能告诉你方向变热，小词（用户在这个大方向里还在搜什么更具体的问题）才告诉你从哪里切进去。
这个切口更适合新 App。服务一个具体人群和具体搜索意图，比泛泛做训练 App 更容易打进去
找这种词时，优先看三类
a. 带人群的词，比如 women、beginners、over 40、students
b. 带目标的词，比如 abs、weight loss、posture、meal prep
c. 带场景的词，比如 at home、no equipment、after pregnancy、for busy people
切入点越具体，越容易写清楚 App Store 标题、截图、onboarding 和 paywall。泛词适合大公司，新 App 更适合从小词开始打。
3. 用 ASO 看关键词能不能打
- 热度高于 20，说明有人搜
- 难度低于 60，说明还没完全被大 App 占死
这里特别要注意，热度高、难度也高，通常不适合新 App 直接硬打。热度低、难度低，也可能只是没人关心
更好的组合是中高热度 + 中低难度。说明用户已经在找，但当前供给还不够强。
4. 用 Sensor Tower 看有没有真实收入
因为搜索兴趣不等于付费需求
要去 Sensor Tower 看同类 App 有没有收入。不要找一个完全没人做的方向。对独立开发者来说，零竞争反而很危险，因为你很难判断用户会不会付费
这一步可以把很多伪需求筛掉
有人搜，但同类 App 没收入，可能只是内容需求
有人搜，同类 App 也赚钱，才可能是产品机会
判断时可以看这些信号：
同类 App 是否稳定有收入
头部 App 收入有没有明显增长
收入是否集中在少数老产品手里
评论区用户到底在抱怨什么
现有产品有没有明显做得差的地方。
5. 三个信号都过，再做第一版
趋势在涨
关键词能打
同类产品已经赚钱
这三个条件一起出现，说明你在顺着一个已经出现的需求窗口做产品了
通用的做法：
先下载头部竞品
把 onboarding 每一屏截图
丢给 Claude 分析
让 Claude 设计一个更好的流程
再让 Claude 按一屏一屏拆出新版 onboarding
最后用你熟悉的工具把第一版做出来
这一步的重点是先把产品流程想清楚，不要直接写代码。
你可以这样跟 Claude 聊：
我想做一个面向「具体人群」的「具体目标」App，下面是 3 个竞品的新手流程截图，请你帮我做 4 件事：第一，拆出每个竞品的新手流程顺序；第二，指出每一步在解决什么用户心理；第三，找出哪里可能导致用户流失；第四，重新设计一个更短、更适合转化付费用户的 onboarding，按屏幕输出。输出时按 Screen 1、Screen 2、Screen 3 写，每一屏包含标题、正文、按钮和用户看到这一屏后的心理预期。
6. 第一版要快
如果一个需求词刚开始涨，关键词还有机会打，竞品收入也已经验证，最好不要花 6 个月慢慢打磨
第一版只要完成几个东西：
一个能解决核心需求的功能
一个能承接搜索词的 App Store 页面
一个能解释结果的 onboarding
一个能测试付费意愿的 paywall
基础埋点和订阅
一开始不做太多附加功能。需求窗口还在的时候，先拿到真实下载、转化和付费数据。
最小版本可以这样：
第一天，列 20 个你熟悉领域里的增长词
第二天，用 Google Trends 看哪些词在上升
第三天，从 rising queries 里找 5 个更窄切口
第四天，用 ASO 工具看热度和难度
第五天，用 Sensor Tower 看同类 App 有没有收入
第六天，选一个三项都过的方向，拆 3 个竞品 onboarding
第七天，用 Claude 生成新版流程，开始做第一版
这套方法最适合找小型消费 App、工具 App、健身/效率/外貌/习惯类 App 。
最后在做产品前再回顾一下这三个问题：
用户已经在搜了吗？
关键词还有机会打吗？
同类产品已经有人付费吗？
117 434
18 岁的 Lino，2.5 个月前开始做 App，本月收入 1.8 万美元
从选题、MVP、onboarding、paywall、UGC 到 Meta ads 都讲到了
1. 先找已经有人付费的强痛点
也就是用户每天都会遇到、情绪足够强的问题，最好和外貌、身材、习惯、焦虑、效率这类高频场景有关
选定后去 Sensor Tower 看竞品收入
如果同一个 niche 里有多个头部 App 稳定做到 1 万美元/月以上，说明需求已经被验证过
竞争在这里不是坏事。完全没人做反而更危险，因为你很难判断到底有没有付费需求。
2. 7 天内上架 App Store
第一版只需要一个核心功能，动画、社区、AI chatbot、dark mode 些都不需要
先把产品放到真实用户面前，获得下载、留存、付费、反馈这些数据
早期产品还没被验证，营销分发要放在更前面。产品上线后再改 UI、补动画、加功能都来得及，但没有用户数据时，很容易把 6 个月花在一个没人想用的版本上。
3. 先做一个能拍广告的功能
toC App 需要一个用户刷到视频时立刻想试的画面。他称为 Holy Sh*t moment，翻成中文就是一个能直接当广告主画面的核心瞬间
UMAX 是上传脸然后拿评分
Cal AI 是拍食物然后得到 macros
GoTall 是判断身高潜力
这类功能不只是产品功能，也会变成 UGC 和广告素材。creator 不需要花 30 秒解释 App，只要把这个瞬间展示出来，用户就会知道自己为什么要下载
所以，做第一版前思考一下，如果用户第一次在 TikTok 上看到这个功能，会不会想马上试一下。如果答案很弱，先别急着写更多功能，想清楚这个主画面。
4. onboarding 负责把下载变成付费
onboarding 控制在 10 到 15 屏，能跳过的动画要给 Skip，转场尽量快。用户刚下载时耐心很低，前面每多一层都会掉人
问完问题后，不要立刻把用户推到 paywall。先给一个 loading screen，比如 Creating your personalized plan，即使只加载几秒，也会提高用户对结果的预期
loading 后再给一屏 summary，把用户刚才选择的内容重新展示出来。用户会感觉 App 听懂了自己，而不是所有人进来都看到同一套模板。
还有一个小技巧，onboarding 里问 first name，后面在文案里要反复用
Alright Lino
Lino, we built your custom plan
Lino, here’s what we recommend for you
这类句子不复杂，但会让产品更像在对一个具体的人说话。Lino 的 onboarding 能把 15% 下载转成付费用户，这个数字可以当参考，具体结果还要看品类和流量质量。
5. paywall 要卖变化，不要只卖功能
paywall 文案不要写 Subscribe to unlock。功能清单很难让用户付费，用户更关心自己买完以后会变成什么样
健身 App 可以写 Your 6 pack starts here
颜值类 App 可以写 Become unrecognizable in 90 days
glow up 类产品可以写 It’s time to Glow Up
这些文案都在讲用户买完以后想得到的状态。功能可以放下面解释，但第一屏要先让用户看到结果
6. 订阅结构要简单，原文建议只保留两个档位。
Yearly + Monthly
Yearly + Weekly
不要加 lifetime subscription
移动 App 早期需要持续优化转化和留存，一次性买断会让后面的 LTV 结构变差。
7. App Store 和社媒增加信任感
App Store 页面要像一个正常能赚钱的 App
logo 要专业，screenshots 要干净，每张图只讲一个信息，不要把一堆文字塞进去
作者建议找 Fiverr 或 X 上的 designer 做截图，因为 AI 做出来的 App Store screenshots 往往不够好。
8. 社媒账号也要像真的在运营
头像、bio、置顶内容、基础 posts 都要
用户从广告或 UGC 点进你的 Instagram / TikTok，如果看到 17 个粉丝、没有头像、没有内容，信任会掉得很快
9. 先用 micro-creators 测素材
不要一上来就砸 Meta ads。先用小 creator 测出什么内容能让用户下载
去 Instagram 和 TikTok 搜 niche 关键词。比如，健身 App 可以搜 How to get abs、Abs workout、Six pack
找 creator 时看几个条件：
5K 到 100K followers
稳定 5K+ views
评论多
最好露脸出镜
建议每天 DM 100+ 个 creator，第一句可以直接一点：
"Paid promo! Hey, we love your content. We’re on a mission to help people achieve [your app outcome]. We’d love to sponsor you. Let us know if you’re interested."
对方回复后，尽量拉到 Google Meet
这样更容易谈成合作，DM 里只适合开场
第一种合作结构是 CPM：
$2 CPM
至少 5 条 posts
TikTok 和 Instagram 都可发
月结
单条视频最多 $500 payout
如果 creator 不接受 CPM，可以先每条给 $20-50，再加播放奖金，比如 5 万、10 万、50 万 views 分档奖励
前几批 creator 每个人都测不同 hook、video style、sound、CTA。你要找的是能让评论区出现 App name?、Where do I download this? 这类反应的素材
一旦某条稳定跑出来，就让后面的 UGC creator 尽量复刻。复刻的重点是保留 hook、展示方式和 CTA，再做小调整。
10. Meta ads 只放大已经测过的素材
有了 15 到 30 条 creatives 之后，再进入 Meta ads testing campaign。不要只投自己觉得好看的素材，把 creator 测出来的素材都放进去，让数据筛
建议从 $100/天开始，连续跑 7 天，总预算大约 $700。低于 $50/天很难拿到足够数据
第一轮只看 3 个指标：
CPI
CTR
CPA
跑满一周后删掉没跑出来的素材，把表现好的素材放进新的 ad set，每 5 天加 20-30% 预算，避免重置 Meta learning phase
ROAS 按周看
单日 ROAS 波动很正常，每几个小时看一次只会让人乱改
周平均 1.8x 以上就继续放大。
11. 收入稳定后再回头优化产品
前面所有动作都是为了更快拿到真实用户和真实收入
等 App 有稳定收入，再补 UI、动画、附加功能和留存优化。
这时候看 3 类数据就够：
用户在哪一步流失
哪些功能用得最多
用户反复要求什么
每次更新都围绕 retention 和 LTV
先把最简单的版本推到市场里，靠用户数据决定第二版应该怎么优化。
从选题、MVP、onboarding、paywall、UGC 到 Meta ads 都讲到了
1. 先找已经有人付费的强痛点
也就是用户每天都会遇到、情绪足够强的问题，最好和外貌、身材、习惯、焦虑、效率这类高频场景有关
选定后去 Sensor Tower 看竞品收入
如果同一个 niche 里有多个头部 App 稳定做到 1 万美元/月以上，说明需求已经被验证过
竞争在这里不是坏事。完全没人做反而更危险，因为你很难判断到底有没有付费需求。
2. 7 天内上架 App Store
第一版只需要一个核心功能，动画、社区、AI chatbot、dark mode 些都不需要
先把产品放到真实用户面前，获得下载、留存、付费、反馈这些数据
早期产品还没被验证，营销分发要放在更前面。产品上线后再改 UI、补动画、加功能都来得及，但没有用户数据时，很容易把 6 个月花在一个没人想用的版本上。
3. 先做一个能拍广告的功能
toC App 需要一个用户刷到视频时立刻想试的画面。他称为 Holy Sh*t moment，翻成中文就是一个能直接当广告主画面的核心瞬间
UMAX 是上传脸然后拿评分
Cal AI 是拍食物然后得到 macros
GoTall 是判断身高潜力
这类功能不只是产品功能，也会变成 UGC 和广告素材。creator 不需要花 30 秒解释 App，只要把这个瞬间展示出来，用户就会知道自己为什么要下载
所以，做第一版前思考一下，如果用户第一次在 TikTok 上看到这个功能，会不会想马上试一下。如果答案很弱，先别急着写更多功能，想清楚这个主画面。
4. onboarding 负责把下载变成付费
onboarding 控制在 10 到 15 屏，能跳过的动画要给 Skip，转场尽量快。用户刚下载时耐心很低，前面每多一层都会掉人
问完问题后，不要立刻把用户推到 paywall。先给一个 loading screen，比如 Creating your personalized plan，即使只加载几秒，也会提高用户对结果的预期
loading 后再给一屏 summary，把用户刚才选择的内容重新展示出来。用户会感觉 App 听懂了自己，而不是所有人进来都看到同一套模板。
还有一个小技巧，onboarding 里问 first name，后面在文案里要反复用
Alright Lino
Lino, we built your custom plan
Lino, here’s what we recommend for you
这类句子不复杂，但会让产品更像在对一个具体的人说话。Lino 的 onboarding 能把 15% 下载转成付费用户，这个数字可以当参考，具体结果还要看品类和流量质量。
5. paywall 要卖变化，不要只卖功能
paywall 文案不要写 Subscribe to unlock。功能清单很难让用户付费，用户更关心自己买完以后会变成什么样
健身 App 可以写 Your 6 pack starts here
颜值类 App 可以写 Become unrecognizable in 90 days
glow up 类产品可以写 It’s time to Glow Up
这些文案都在讲用户买完以后想得到的状态。功能可以放下面解释，但第一屏要先让用户看到结果
6. 订阅结构要简单，原文建议只保留两个档位。
Yearly + Monthly
Yearly + Weekly
不要加 lifetime subscription
移动 App 早期需要持续优化转化和留存，一次性买断会让后面的 LTV 结构变差。
7. App Store 和社媒增加信任感
App Store 页面要像一个正常能赚钱的 App
logo 要专业，screenshots 要干净，每张图只讲一个信息，不要把一堆文字塞进去
作者建议找 Fiverr 或 X 上的 designer 做截图，因为 AI 做出来的 App Store screenshots 往往不够好。
8. 社媒账号也要像真的在运营
头像、bio、置顶内容、基础 posts 都要
用户从广告或 UGC 点进你的 Instagram / TikTok，如果看到 17 个粉丝、没有头像、没有内容，信任会掉得很快
9. 先用 micro-creators 测素材
不要一上来就砸 Meta ads。先用小 creator 测出什么内容能让用户下载
去 Instagram 和 TikTok 搜 niche 关键词。比如，健身 App 可以搜 How to get abs、Abs workout、Six pack
找 creator 时看几个条件：
5K 到 100K followers
稳定 5K+ views
评论多
最好露脸出镜
建议每天 DM 100+ 个 creator，第一句可以直接一点：
"Paid promo! Hey, we love your content. We’re on a mission to help people achieve [your app outcome]. We’d love to sponsor you. Let us know if you’re interested."
对方回复后，尽量拉到 Google Meet
这样更容易谈成合作，DM 里只适合开场
第一种合作结构是 CPM：
$2 CPM
至少 5 条 posts
TikTok 和 Instagram 都可发
月结
单条视频最多 $500 payout
如果 creator 不接受 CPM，可以先每条给 $20-50，再加播放奖金，比如 5 万、10 万、50 万 views 分档奖励
前几批 creator 每个人都测不同 hook、video style、sound、CTA。你要找的是能让评论区出现 App name?、Where do I download this? 这类反应的素材
一旦某条稳定跑出来，就让后面的 UGC creator 尽量复刻。复刻的重点是保留 hook、展示方式和 CTA，再做小调整。
10. Meta ads 只放大已经测过的素材
有了 15 到 30 条 creatives 之后，再进入 Meta ads testing campaign。不要只投自己觉得好看的素材，把 creator 测出来的素材都放进去，让数据筛
建议从 $100/天开始，连续跑 7 天，总预算大约 $700。低于 $50/天很难拿到足够数据
第一轮只看 3 个指标：
CPI
CTR
CPA
跑满一周后删掉没跑出来的素材，把表现好的素材放进新的 ad set，每 5 天加 20-30% 预算，避免重置 Meta learning phase
ROAS 按周看
单日 ROAS 波动很正常，每几个小时看一次只会让人乱改
周平均 1.8x 以上就继续放大。
11. 收入稳定后再回头优化产品
前面所有动作都是为了更快拿到真实用户和真实收入
等 App 有稳定收入，再补 UI、动画、附加功能和留存优化。
这时候看 3 类数据就够：
用户在哪一步流失
哪些功能用得最多
用户反复要求什么
每次更新都围绕 retention 和 LTV
先把最简单的版本推到市场里，靠用户数据决定第二版应该怎么优化。
49 021
App 看起来粗糙更常见的原因是一些小细节问题
比如，用户第一次进来不知道下一步，空页面只写 no data，点完按钮没有反馈，icon 风格不统一，文案像模板，加载时也不知道系统是不是在正常运转。
把下面这 9 点当成一张 App 质感检查清单，，在发版前从头扫一遍：
1. onboarding
好的 onboarding 要简单、直观、有一点轻松感。用户不用猜，也不用读一堆说明，最好前 30 秒就能看到一次价值。
2. 动效只放在用户需要理解的地方
按钮点下去要有反应，页面切换要自然，完成一个动作后要让用户知道刚刚发生了什么
不要为了显得高级就到处加动画。动效最有用的位置，是状态变化、确认完成、页面进入和退出。用户看完能理解动作和结果连在一起。
3. 空状态
至少要有 3 个东西：
说明现在为什么是空的
告诉用户下一步可以做什么
给一个能直接点的动作
如果只写 No data found，用户会觉得莫名奇妙。
4. 给点击和完成动作加反馈
普通点击可以用轻微 haptics，确认、完成任务、保存成功这类动作可以给更明显的反馈。
5. icon
icon 不能东拼西凑。线宽、圆角、填充、风格最好来自同一个 family
选中态也不要只靠颜色区分。可以换成 filled icon，或者让 icon weight 更重一点，用户扫一眼就知道当前在哪个 tab。
6. 让 App 感觉更快
真实速度改不了太多时，感知速度还能改
每次点击后立刻给反馈，加载时用 skeleton loader，提交动作可以先做 optimistic update，页面切换尽量顺滑。用户最怕的是等的时候完全没反馈，不知道 App 有没有在工作。
7. 文案要像真人说话
用户打开 App 时，关心的是自己正在完成的那个动作，不是在读品牌标语。产品文案越接近其当下感受，App 越不像模板
空状态、按钮、成功提示、错误提示都可以先改文案。比如，把 “No results available” 改成 “You’re all caught up”，质感会马上不一样。
8. 每周拆几个好 App
为什么这个 spacing 舒服，为什么这个动画顺，为什么这个交互一看就懂
第一次打开时怎么带用户走
空状态怎么写
按钮点下去有什么反馈
加载时怎么处理等待
选中态怎么设计
文案是不是像真人说话
高级感通常来自这些小细节。
9. 发版前做一轮小检查
第一次进来能不能知道下一步
空页面有没有解释和按钮
每次点击有没有反馈
加载时用户会不会以为卡住
icon 风格是不是统一
文案有没有模板味
先把这些地方补上，再加新功能！
比如，用户第一次进来不知道下一步，空页面只写 no data，点完按钮没有反馈，icon 风格不统一，文案像模板，加载时也不知道系统是不是在正常运转。
把下面这 9 点当成一张 App 质感检查清单，，在发版前从头扫一遍：
1. onboarding
好的 onboarding 要简单、直观、有一点轻松感。用户不用猜，也不用读一堆说明，最好前 30 秒就能看到一次价值。
2. 动效只放在用户需要理解的地方
按钮点下去要有反应，页面切换要自然，完成一个动作后要让用户知道刚刚发生了什么
不要为了显得高级就到处加动画。动效最有用的位置，是状态变化、确认完成、页面进入和退出。用户看完能理解动作和结果连在一起。
3. 空状态
至少要有 3 个东西：
说明现在为什么是空的
告诉用户下一步可以做什么
给一个能直接点的动作
如果只写 No data found，用户会觉得莫名奇妙。
4. 给点击和完成动作加反馈
普通点击可以用轻微 haptics，确认、完成任务、保存成功这类动作可以给更明显的反馈。
5. icon
icon 不能东拼西凑。线宽、圆角、填充、风格最好来自同一个 family
选中态也不要只靠颜色区分。可以换成 filled icon，或者让 icon weight 更重一点，用户扫一眼就知道当前在哪个 tab。
6. 让 App 感觉更快
真实速度改不了太多时，感知速度还能改
每次点击后立刻给反馈，加载时用 skeleton loader，提交动作可以先做 optimistic update，页面切换尽量顺滑。用户最怕的是等的时候完全没反馈，不知道 App 有没有在工作。
7. 文案要像真人说话
用户打开 App 时，关心的是自己正在完成的那个动作，不是在读品牌标语。产品文案越接近其当下感受，App 越不像模板
空状态、按钮、成功提示、错误提示都可以先改文案。比如，把 “No results available” 改成 “You’re all caught up”，质感会马上不一样。
8. 每周拆几个好 App
为什么这个 spacing 舒服，为什么这个动画顺，为什么这个交互一看就懂
第一次打开时怎么带用户走
空状态怎么写
按钮点下去有什么反馈
加载时怎么处理等待
选中态怎么设计
文案是不是像真人说话
高级感通常来自这些小细节。
9. 发版前做一轮小检查
第一次进来能不能知道下一步
空页面有没有解释和按钮
每次点击有没有反馈
加载时用户会不会以为卡住
icon 风格是不是统一
文案有没有模板味
先把这些地方补上，再加新功能！
10 04