直接结论
AI 起草 listing 文案的速度超过任何团队，这把瓶颈——以及质量标准——转移到了评审环节。可用的评审流程把 AI 产出当作带有三类典型风险的初稿：产品兑现不了的自信主张；流畅但泛化、放在品类里任何一个应用上都成立的措辞；以及对既定关键词策略的偏移——因为模型优化的是阅读流畅度，不是搜索落位。因此评审按顺序检查三层：真实性（每条主张都对应真实功能或可测量的结果）、差异化（这段文案不能原样贴到竞品 listing 上）、落位（目标关键词待在策略分配的字段里）。跳过结构化评审的团队，要么在规模化地发布平庸文案，要么把省下的起草时间全部烧在评论区里反复争论口味。
三层评审
| 层 | 问题 | AI 的典型翻车方式 |
|---|---|---|
| 真实性 | 产品真的做得到吗？ | 为了凑齐利益点句式而发明听起来合理的功能 |
| 差异化 | 竞品能原样照抄吗？ | 流畅的品类套话（「提升你的效率」） |
| 落位 | 关键词在策略指定的位置吗？ | 为了行文顺畅挪走或丢掉关键词 |
推荐流程
1. 喂给生成器的是策略，不只是产品
产出质量由输入质量决定。提示词上下文应该包含定位、带归属字段的关键词聚类、主张边界（产品不做什么）和语气参照。没带着策略生成的文案，就得在评审时把策略倒着补回去——这是最贵的顺序。
2. 先跑真实性检查
把每条事实性主张对照当前版本核实。这一步需要的是懂产品的人，不是文笔好的人。发明出来的功能要立刻处决——那是被拒和退款风险，不是文风问题。
3. 对着真实竞品跑差异化检查
打开三个竞品 listing，把草稿放在旁边读。任何一句能无缝放进竞品 listing 的话，都是被品类壁纸浪费掉的位置——换成只有这个产品才能说的话。
4. 机械地核对关键词落位
拿草稿对照落位地图逐项 diff：主聚类在标题、第二角度在副标题、变体在关键词字段或 Play 正文。这是机械检查，应该走清单，不应该走讨论。
5. 局部手改优先；只有结构性失败才 regenerate
草稿方向对的时候，手工修改能保住已经通过评审的部分。只有 framing 本身错了——角度错、受众错、证明顺序错——才值得 regenerate，而且要记下原因，让下一次提示词更聪明。
常见失败模式
凭感觉评审
没有三层结构，评审就变成口味辩论。结构化检查一轮收敛；无结构的讨论串会产出五轮「要不再试一版？」。
把流畅当成准确
AI 文案在任何准确度水平上读起来都很自信。流畅恰恰是未经核实的主张能混过评审的原因——真实性检查之所以存在，就是因为文采会掩盖错误。
用 regenerate 代替决策
当评审者说不清哪里不对时，团队就开始空转 regenerate 来代替判断。每次 regenerate 都必须点名它要修复的失败；否则迭代只是原地运动。
把双语产出当翻译来审
如果 AI 同时产出了中英两版，要分别用各自语言对照策略评审——而不是互相对照。两个各自流畅的版本可以朝不同方向偏离策略，同时表面上还互相吻合。
AI 文案评审清单
- 生成提示词包含定位、带归属字段的聚类和主张边界。
- 每条主张由懂产品的人对照当前版本核实过。
- 草稿对照三个竞品 listing 检查过套话。
- 关键词落位对照策略地图机械核对过。
- 手改优先于重新生成；每次 regenerate 都有点名的原因。
- 每个语言版本都用母语对照策略单独评审。
执行原则
AI 起草省时间的前提，是评审比写作便宜。让它保持便宜的方法：把三层检查——真实、差异、落位——变成显式步骤，并拒绝一切说不出失败原因的 regenerate 请求。
为什么这件事适合放进 App Store Helper
App Store Helper 在已经持有定位、关键词聚类和主张历史的项目里生成文案，草稿从一开始就带着策略，而不是策略盲的。评审节点和 regenerate 原因按素材记录，迭代因此有纪律，双语真实性检查也成为流程步骤，而不是靠某个人记得去做的人情。