直接回答
regenerate 只有在团队能说清楚“现在到底要解决什么问题”时才应该被触发。如果问题只是局部措辞不顺，通常手工微调更便宜、更清楚；如果问题在于信息层级、 framing 或表达角度，文本 regenerate 更合适；如果问题是截图顺序或视觉证明已经不成立，才应该做截图 regenerate。很多团队会在这里浪费额度和评审注意力，因为他们把“再生成几个版本”当成了诊断工具，而不是在先确定问题类型之后再选择合适的动作。一个成熟的 workflow 会把 regenerate 当成有负责人、有理由、有预期结果的受控决策。
regenerate 决策总览
| 问题类型 | 更适合的动作 | 原因 | 负责人 checkpoint | | --- | --- | --- | --- | | 某一句话不对 | 手工微调 | 当前草稿已经接近完成，改动范围局部 | 评审者确认不涉及结构变化 | | 信息层级不成立 | 文本 regenerate | 团队需要新的角度、 framing 或顺序 | ASO 或增长负责人确认新方向 | | 截图序列失效 | 截图 regenerate | 视觉证明或画面顺序已经不再支撑主承诺 | 设计或发布负责人确认序列问题 | | 决策标准不清 | 先停下来澄清 | 再多输出也无法替代缺失的判断标准 | 决策负责人先定义什么叫“更好” |
推荐决策顺序
1. 先诊断真正的问题
在 regenerate 之前，先判断问题到底是信息清晰度、结构、视觉证明，还是局部措辞。不同问题需要不同动作，跳过这一步只会制造 churn。
2. 草稿已经接近时，优先手工改
如果当前版本方向是对的，只差局部修正，手工编辑通常更优。为了一个小问题去 regenerate，成本往往过高。
3. framing 出问题时，优先文本 regenerate
当团队卡在 headline 角度、利益点顺序或叙事层级上时，文本 regenerate 才真正有价值，因为它是在策略层面探索替代方案。
4. 只有视觉系统错了，才做截图 regenerate
如果当前问题还停留在文案结构里，截图 regenerate 往往为时过早。只有当证明序列、视觉重点或画面顺序本身已经失效时，才值得走图片方向的 regenerate。
5. 每次 regenerate 都要留下原因
每一次 regenerate 都应该记录“为什么要这样做”。没有这层上下文，下一轮评审很容易重复同样的错误，因为团队已经忘了上次到底改了什么。
常见失效模式
还没定义成功标准，就先追求更多版本
这是最快消耗额度的方式。如果团队说不清楚什么结果才算更好，再多输出只会制造噪音。
文案问题没解决，就先 regenerate 截图
如果真正的问题还在信息结构层，截图 regenerate 只会把错误思路变成更精致的视觉版本。
评审历史在轮次之间消失
如果过去 regenerate 的原因没有留下来，团队就无法从迭代里学习，最后只会重复同样的 churn。
regenerate 检查清单
- 在选择 regenerate 类型前，先定义具体问题。
- 当改动范围局部且结构正确时，优先手工微调。
- 当问题在 framing 或层级上时，优先文本 regenerate。
- 只有当视觉序列本身有问题时，才做截图 regenerate。
- 在下一轮评审开始前，先记录这次决策的原因。
一个操作规则
如果团队说不清楚什么变了、为什么选这个 regenerate 动作、以及什么结果才算更好，那么现在还不应该 regenerate。
为什么这和 StorePilot 有关
StorePilot 把文本和图片 regenerate 都保留在同一个项目记录里，并让历史可见。这使团队更容易把迭代当成带权衡的选择，而不是条件反射式地继续生成，从而把额度集中花在真正影响提审准备的地方。