Danny Postma 用 Claude Code 搭了一套自己的 AgentOS，早上写目标，晚上回来审 PR，现在大约 95% 的编程相关任务都交给这套系统跑

一个需求进去，系统会自己写 spec、做计划、审计划、写代码、审代码、修代码、更新 wiki，最后提 PR。人不用守着终端等下一步，只在要批准、要选择、要判断的时候出现

这套系统里，每个 agent 只负责一个环节

- spec agent 写规格
- plan agent 写开发计划
- review agents 看可行性、范围、一致性
- senior developer 写代码
- code review coordinator 审代码
- code steward 更新 wiki

他展示的一个任务，下午 3 点启动，晚上 9 点跑完。第二天回来，PR 已经在那里。

权限要比 prompt 更早设计

每个 agent 都在独立容器里跑，用完就清理
客服 agent 能访问前端 MCP，但碰不到 Gmail 和 GitHub
规划 agent 只能访问计划工具。文件系统走 Cloudflare R2 + MCP，可以限制只读、只写、禁止删除
agent 会犯错，也可能被 prompt 注入影响。权限从底层收住，系统才敢让它连续跑几个小时。

人只处理判断题

AgentOS 有一个 inbox
agent 卡住、要批准、要选项时，把问题发进来
比如标题用哪段文字，Danny 在手机上点一下，流程继续跑。

成本方面

一开始他用 Anthropic 云托管 agent，效果好，但每天大概要花 500 美元
后来他把一部分 worker 搬到 Hetzner 的 10 美元 VM 上跑
规划 agent 继续用强模型，执行类 worker 放到便宜、速度快的模型上。

最后，agent、技能、模板都变成 YAML 文件，再用 AgentOS CLI 同步配置、创建项目、启动目标。

Postiz 是一款多社媒的发布平台，月营收已经接近 20 万美元了

创始人把 Postiz 放进更大的增长场景里，B2C App 怎么靠社媒拿到几百万播放，创作者怎么批量发布内容，UGC 怎么持续铺出去。产品从功能介绍改成结果证明

1. 先选一个能反复公开的可信指标

Postiz 每天发 MRR，表面看是展示收入，实际是在建立权威性信任度

如果你没有收入，也可以换成 SEO 流量、注册用户、活跃用户、公开 analytics dashboard、客户案例数据。重点是持续公开同一个指标，让别人知道你在这个细分领域里一直有结果。

这个指标后面会变成所有内容的信任底座。你写教程、发案例、做 AEO、找 creator 合作，别人先看到的是你已经做出来的东西。

2. 旧渠道先降权，别把预算押错地方

广告越来越贵。以前每天可能只有 10 个 startup 在投，现在几千个产品都能快速做出来，广告自然更贵。B2C 订阅尤其难算账，用户获取成本 $50，月费 $9，留存稍微差一点就亏

SEO 能带流量，但流量未必带收入。Postiz 的 SEO 流量一直涨，收入没有跟着涨。现在用户有问题会直接问 ChatGPT / Perplexity / Claude，传统 blog 流量的购买意图变弱了

公司账号日常更新和 build in public 也要重新看，适合维持存在感，适合建立信任，直接拉 MRR 有点难。

3. 把高表现内容改成 X Articles

X Articles 现在还有红利，因为平台想留住长内容阅读时间

最重要的两个信号是收藏和阅读时长。一个视频可以有 65 万播放和很多互动，但一篇长文如果收藏更多、阅读时间更长，X 也会继续推

可以先拿已经跑过的推文或视频改成 article，再用 30 秒左右的短视频 quote repost。短视频负责拿第一波注意力，长文负责承接阅读和收藏

这里要注意内容必须指向同一个主题。视频和长文脱节，quote repost 可能有浏览，article 本身吃不到。

4. 教程要贴着产品结果写

Postiz 的教程能带订阅，因为教程围绕“怎么靠社媒赚钱”展开，排程功能只是完成结果的一环

如果你的产品是工具，教程最好从用户想要的结果出发。比如 App 想拿下载，就写内容分发、UGC、短视频、lead magnet

产品在教程里可以自然出现。读者买到的是一条通往结果的路径，工具位只是其中一环。

5. AEO 要去 LLM 会引用的地方铺内容

AEO 和 SEO 的差别很大。SEO 要把内容放在自己网站，因为用户从 Google 点进来。AEO 不一定需要内容在你的网站，LLM 会从很多页面里找引用

建议把内容放到 Reddit、LinkedIn Articles、X Articles、GitHub awesome-list 这些高权重的地方

先去 ChatGPT 里用客户会问的方式搜索你的品类，看谁被引用。再去这些位置补真实、有用的回答和文章。

这里越细分越容易。Postiz 如果抢“social media scheduler”，对手是 Buffer、Sprout Social 这类大公司。但是押“social media tool for agents”，竞争范围小很多，内容也更容易被 LLM 抓到。

6. Lead magnet 适合放在 Instagram 和 LinkedIn

不建议在 X 上做 comment-to-DM，因为容易踩平台规则。Instagram 和 LinkedIn 更适合跑这套。

做法是先发很多视频，找到一个明显有效的视频，再不断复用。换封面、换音乐、换一点文案，继续引导用户评论关键词，然后 DM 交付教程、清单或资料。

账号要先 warm up。先在细分领域里点赞、评论，让平台知道这个账号应该被推给谁。新号直接批量发 lead magnet，很容易看起来像工具号

Lead magnet 也会疲劳。比较稳的做法是维护一个大的 source of truth，比如一篇长文、一个视频教程、一个完整清单。后面每个 lead magnet 都指向它，素材可以换，交付物不用一直重做。

7. UGC / AI UGC 按概率来跑

UGC 的逻辑是规模测试。单条视频通常不会直接爆，但一条 UGC 成本大概 $20-30，一个 creator 每天可以产 1-2 条，多个账号一起跑，就能更快测出哪个角度有效

有人用 10 个账号同时跑。等某条视频起量，再拆解为什么起量，然后重复这个角度

AI UGC 也是同一套逻辑，只是把真人出镜换成 AI 人物。适合有明确场景、明确痛点、明确前后变化的产品。画面里要让人马上看懂产品能帮他拿到什么结果。

整套打法的顺序很重要。先证明你有结果，再把结果写成内容，再把内容铺到平台和 LLM 会分发的位置。

靠 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%

Firecrawl 又出神作，一个非常高效节约的 pdf 解析工具 - pdf-inspector，完全开源免费

会先在本地判断 PDF 是文字版、扫描版、图片版还是混合版。文字版直接抽文本和表格，扫描页再丢给 OCR，避免每份文件都走一遍又贵又慢的 OCR。

拿 200 份 PDF 跑了几个开源主流 pdf 解析项目的性能测试，pdf-inspector 总分排第一，200 个文档只用了 0.47 秒，遥遥领先了！Rust 还是强啊，同时给 Python、Node、WASM、CLI 绑定，适合接进 RAG、爬虫、财报/论文/法律文档等处理

这份清单有参考价值，但别把 Reddit 当成免费的广告位

17 个 subreddit，背后其实是 17 种不同的人群和社区规则

大社区不一定更有效，精准度、内容匹配和参与方式，比所谓“月访问量”重要得多

另外个人建议要把握的核心原则：
- 先贡献，再推广
- 先理解社区，再发布产品

一套自动涨 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 里找重复痛点
- 自动复盘内容或销售动作的结果

一个现实版 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 的人数。

每次有新的更聪明的模型发布都要定期清理一下上下文，避免浪费 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 里就好了

把握这三个点找到月入 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 。

最后在做产品前再回顾一下这三个问题：

用户已经在搜了吗？
关键词还有机会打吗？
同类产品已经有人付费吗？

测了 100 多条，筛选出最有效的 10 个 facebook 广告内容 hooks
记得把握住一点，先制造一个很小的情绪缺口