上线前四周的 ASO 时间线

直接结论

ASO 工作被压缩的后果很难看：上线当周才做的关键词调研，产出的是堆砌关键词的标题；构建冻结之后才设计的截图，产出的是五张重复同一句话的图。一条四周的上线前时间线按依赖顺序摊开工作——先调研和定位，再元数据，再创意素材，最后 QA 和冻结——让每个阶段都在评审上一个阶段的产出，而不是现场即兴。第 1 周锁定定位和关键词聚类；第 2 周把聚类变成标题、副标题、关键词字段和描述草稿；第 3 周产出 screenshot recipe 和本地化素材；第 4 周跑提审前 QA 并由一个负责人冻结素材包。时间线真正的作用不在日历本身——而在强迫那些所有下游都依赖的决策，在还便宜的时候发生。

四周地图

推荐流程

第 1 周：先决策，后动笔

锁定定位陈述——应用服务谁、改善什么结果、这次发布为什么重要——并把关键词调研做到「聚类 + 归属字段」的深度。这些决策一旦停止移动，下游一切都变便宜。如果周五定位还有争议，宁可延长第 1 周，也不要在流沙上开始写元数据。

第 2 周：元数据从聚类出发，不从白纸出发

用主聚类起草标题副标题，用落选的词构建关键词字段，按商店写描述。本周结束前对照当前构建做一轮主张审计，让第 3 周的截图只为核实过的承诺做设计。

第 3 周：创意素材证明元数据

先写 screenshot recipe——每帧的角色、证明点、文案层级——再进设计。本地化变体在同一周、从同一份 recipe 产出，而不是日后才被发现的缺口。通过条件：由没写 recipe 的人确认序列证明了标题的承诺。

第 4 周：QA、冻结和缓冲

跑提审前清单：主张、截图对照候选包、关键词字段审计、跨语言一致性。然后冻结——一个负责人，QA 后零修改。剩下的日子是留给 QA 发现问题的缓冲，这正是 QA 不能放在提审当天的原因。

时间线怎么压缩

小版本可以压缩每个阶段的时长，但不能改变顺序：调研在元数据前、元数据在创意前、QA 在一切之后。两周版每个阶段砍半；两天版是对既有素材的重新核实——复用上个版本的调研可以，跳过 QA 关卡不行。

常见失败模式

创意和调研并行启动

定位还在移动时设计的截图，要么返工重做，要么更糟——带着一个已被放弃的承诺上线。

冻结是软的

如果「已冻结」的元数据还在持续接受优化，第 4 周的 QA 对实际上线的东西没有任何保证。没有一个能说「不」的负责人，冻结只是一句建议。

时间线只为旗舰发布存在

每个碰元数据的版本都值得同一顺序的压缩版。排名往往就丢在那些没人重新检查副标题现在在承诺什么的日常更新里。

上线前清单

1. 动笔之前锁定定位陈述和关键词聚类。
2. 元数据从聚类起草，主张对照构建审计过。
3. 设计开始前写完并评审 screenshot recipe。
4. 本地化变体在创意周内产出。
5. 提审前 QA 完成时仍留有数天缓冲。
6. 素材包由指名负责人冻结。

执行原则

任何阶段都可以缩短；任何阶段都不可以调序或跳过。如果发布压力逼你砍东西，砍范围——更少的截图、更少的语言——永远不要砍 QA 关卡。

为什么这件事适合放进 App Store Helper

App Store Helper 按同样的依赖顺序组织 listing 项目：定位和关键词喂给元数据草稿，元数据喂给 screenshot recipe，review checkpoint 标记每个关卡。四周时间线变成可见的项目状态——什么已锁定、什么在评审、什么已冻结——而不是一份靠某个人手工维护的日历。