直接结论
Apple 的 100 字符关键词字段是整个 listing 里唯一用户永远看不到的表面，这让它成为纯粹的索引空间——每一个字符都应该承载标题和副标题放不下的词。机械规则很明确：用英文逗号分隔且逗号后不加空格；绝不重复标题副标题里已有的词；单复数只留一个；删掉 "app"、"free" 这类 Apple 已经默认处理的填充词。在机械规则之上，这个字段是一个组合投资决策：它应该装的是关键词调研产出的聚类变体和长尾短语，而不是头脑风暴剩下的边角料。最常见的浪费方式有三种：重复可见元数据、一年不更新、当成和 listing 承诺毫无关联的垃圾桶。
能省出字符的机械规则
| 规则 | 原因 | 示例 |
|---|---|---|
| 逗号分隔、不加空格 | 逗号后的空格纯属浪费 | 记账,预算,报销 而不是 记账, 预算, 报销 |
| 不放标题/副标题里的词 | 那些字段已经被索引 | 标题有「习惯」→ 字段里删掉 |
| 单复数只留一个（英文） | Apple 会匹配近似变体 | recipe 通常已覆盖 recipes |
| 删掉 "app"、"free"、"iphone" | Apple 会自动补充或忽略 | 立刻省回 4–10 个字符 |
| 拆成单词优于整句短语 | Apple 会跨字段组合单词 | meal,plan 能同时匹配 "meal plan" 和 "plan meal" |
推荐流程
1. 从关键词聚类出发，而不是从空字段出发
这个字段存在的意义，就是接住在标题副标题竞争中落选的聚类变体和长尾词。如果调研阶段产出了带归属字段的聚类，关键词字段的内容其实已经被决定了。
2. 删掉所有 Apple 已经索引的内容
把标题和副标题拼成一个字符串，从关键词草稿里删掉其中出现过的每一个词，再套用上面的机械规则。多数团队这一步能省回 20–30 个字符。
3. 把省出来的字符花在新意图上
省出的字符应该承载还没被覆盖的查询意图：一个使用场景、一个问题短语、一个竞品品类标签。新意图的价值高于既有意图的第三个变体。
4. 按市场本地化，而不是按语言翻译
关键词字段是按 locale 设置的，部分商店存在 locale 交叉索引。先弄清楚哪些 locale 会喂给哪些国家商店，不要假设一份中文字段能覆盖所有中文市场。
5. 每次元数据变更时同步复查
标题或副标题一改，词就在可索引表面之间移动了。副标题加了「规划」，关键词字段里的这个词就该让位给新词。
常见失败模式
字段在重复可见元数据
最常见的浪费：品牌名、标题关键词、副标题短语在这里再抄一遍，一分收益都没有。这个字段的价值恰恰在于装那些别处看不到的词。
字段常年不动
排名在变、季节在变、功能在上新。一年没动过的关键词字段，等于调研预算只花了一次、再没复投过。
没人说得清某个词为什么在里面
当字段变成历届头脑风暴的化石层，评审就无从谈起。每个词都应该能追溯到一个聚类、一次竞品观察或一个真实查询。
关键词字段清单
- 逗号分隔、无空格、不超过 100 字符。
- 与标题副标题的词零重叠。
- 没有 "app"、"free"、"iphone"，没有单复数成对出现。
- 每个词都能追溯到调研聚类或真实观察到的查询。
- 每个 locale 的字段为其市场单独构建，不是机翻。
- 最近一次标题/副标题变更后重新复查过。
执行原则
如果把某个词从关键词字段里删掉，你说不出会因此损失什么，那它就配不上这些字符——换成一个还没覆盖的意图。
为什么这件事适合放进 App Store Helper
App Store Helper 从持有标题副标题的同一个项目里生成关键词字段，重叠剔除和字符预算是对着实时元数据做的，而不是对着表格里的过期副本。双语项目里，每个 locale 的字段可以单独评审，但共享同一套关键词策略。