直接结论
一份能转化的应用描述，是同时写给两种读者的：只看前三行的人类，和会读完全文的商店算法。前 170 个字符——「更多」折叠线之前的部分——必须直接给出核心承诺和最强证明，因为对大多数访客来说，这就是描述的全部。折叠线以下，结构比文笔重要：利益点开头的短段落、可扫读的功能块（每条都带具体结果）、社会证明，以及结尾一组承接长尾意图的使用场景清单。Google Play 的描述参与关键词索引，目标短语要自然地出现在正文里；App Store 的描述几乎不影响排名，应该纯粹为转化优化。常见的失败方式：开头讲公司历史、罗列功能不讲结果、一份文案不加区分地同时用于两个规则不同的商店。
两种读者
| 读者 | 看到什么 | 描述欠他们什么 |
|---|---|---|
| 快速扫读的人 | 前 170 字符，顶多加几个小标题 | 立刻给出核心承诺和最强证明 |
| Google Play 索引 | 全文 | 目标关键词短语自然出现 3–5 次 |
| App Store 审核团队 | 全文 | 与应用实际行为一致的主张 |
推荐结构
1. 开头块：170 字符的电梯陈述
一到两句话说清应用给谁用、交付什么结果、以及手头最强的可信度标记。这一块要最后写——等描述其余部分把重点厘清之后再回来提炼。
2. 利益点段落，不是功能堆砌
每段以结果开头（「再也不丢发票」），机制随后（「一键扫描并自动归类」）。没有结果的功能只是规格说明，规格说明不产生转化。
3. 一个可扫读的功能块
中段放一组要点列表，服务快速下滑的读者。每条要点都是「功能 + 具体结果」的组合，句式保持平行，扫读才不费力。
4. 证明与信任
评分里程碑、媒体报道、用户数或一句简短引用。一个块就够了；把历年所有奖项都堆上去，读起来反而像不自信。
5. 结尾的使用场景清单
以「适合……」的场景收尾。长尾意图天然住在这里——那些用户按问题而不是按品类搜索时输入的短语。
分商店调整
Google Play
描述会进搜索索引。把每个目标短语自然地织进正文——3000 字符里出现三到五次很正常；关键词墙既让用户起疑，也有政策风险。
App Store
描述文本不是有效的排名输入，所以每句话都要么抓注意力、要么建立信任。关键词的任务交给标题、副标题和关键词字段。
常见失败模式
第一行在讲公司
「成立于 2019 年，我们相信……」把唯一有保证的曝光机会花在没有访客想了解的事情上。第一句要说用户能得到什么。
只有功能没有结果
「自定义标签、文件夹和筛选」没有意义，直到它变成「两秒找到任何一条笔记」。每个功能都要挂上它的后果。
一份描述通吃两个商店
把 App Store 文案原样搬去 Google Play，等于放弃索引覆盖；把 Play 文案搬来 App Store，往往是在只看说服力的地方堆关键词。
描述评审清单
- 前 170 字符单独成立，说清承诺和证明。
- 每个段落以结果开头，而不是功能名。
- 有一个句式平行、可扫读的要点块。
- Google Play 版自然织入目标短语；App Store 版是纯转化文案。
- 所有主张与应用当前行为一致，没有可被审核团队挑出的内容。
- 本地化版本按市场重新组织结构，而不是逐句翻译。
执行原则
如果所有人只读前三行——对大多数访客来说事实就是如此——他们能否知道这个应用做什么、凭什么可信、给谁用？答不上来，描述就还没写完。
为什么这件事适合放进 App Store Helper
App Store Helper 用驱动标题和截图的同一份定位与关键词聚类来起草描述，并把 Google Play 版和 App Store 版作为两份独立可评审的素材放在同一个项目里。折叠线以上的开头块、利益点结构和双语版本始终对齐同一套策略，而不是在多份文档之间漂移。