给已写好的邮件加个性化时，如何映射合并标签…

在已有邮件文案和分群基础上，为每个合并标签绑定真实导出列并设置兜底值，定义按分群变化的条件内容块，审计空字段/死条件渲染并守住 PII 边界。

适用场景

解决思路

1. 确认输入：基础文案、分群映射（或列清单）、模式（promo/cold/newsletter），以及每个候选字段的填充率；模式决定 SEND E 维度的侧重（留存/新闻邮件偏重 E，按分群变化收益最大；冷启动外发个性化必须基于可验证信号）。若填充率未知，走决策门。
2. 映射每个合并标签：把文案中的每个个性化 token 绑定到一个真实导出列并记录其类型；没有匹配列的标签标记为 NEEDS_INPUT，不要猜测。
3. 为每个标签设置兜底值：每个标签都要有在字段为空时读起来自然的显式兜底（如 {{first_name | "there"}} → "Hi there," 而非 "Hi ,"；{{city | "your area"}}），并展示兜底渲染后的样子。没有兜底 = 失败。
4. 当兜底会改变句子时优先用条件块而非裸标签：如果空字段会导致语法悬空或优惠不再成立，就用条件块包裹，而不是依赖字符串默认值。
5. 按分群定义条件块：对随受众变化的内容，写以分群映射中命名分群为键的 if/elseif/else 规则（champions → 忠诚优惠，at-risk → 挽回优惠，new → 欢迎优惠）；每个块必须以 catch-all else 结尾，为不匹配任何分支的人渲染有效内容——没有默认分支的条件块对未分桶的剩余人群就是死内容渲染。
6. 运行兜底安全审计：把整个模板当作每个个性化字段都为空、每个订阅者都落到 else 分支来走一遍，确认没有 "Hi ," / 孤立逗号 / 空项目符号、没有引用缺失产品的优惠、没有渲染为空的块；列出每个标签和块的最坏情况渲染。这个审计是交付物的核心。
7. 应用 PII 守卫：说明哪些字段允许渲染进可见正文、哪些被阻止。名字/城市/最近产品类别通常可以；全名、邮箱、电话、精确地址、订单 ID 及任何特殊类别数据不应渲染进正文或主题行。标记会暴露敏感 PII 的标签，并提出更粗粒度的替代（类别而非 SKU，城市而非街道）。绝不要输出含导出中真实 PII 的示例渲染。
8. 对照台账检查个性化声明：如果某个分群变体做出促销声明（分群特定价格、保证或最高级表述），对照 memory/claims/claims-ledger.md 核实并使用已批准措辞，或标记 [needs source]。只标记，不编造依据。
9. 标注 SEND E 相关性：对每个个性化动作，说明它如何影响 E（互动/个性化），并把任何填充率或覆盖率数字标注为 Measured（从导出列统计）或 Estimated（推断——说明推断方式）。绝不把估算填充率当作实测呈现。
10. 决策门——停下来问：未提供邮件文案，或没有可分群映射/列清单；填充率未知且该字段驱动条件优惠（低填充字段会悄悄把大多数订阅者送到错误分支）。可静默继续：多个同样合理的兜底字符串选哪个（选最安全的中性默认并注明）；字段仅缺失于装饰性标签（如名字）——用兜底继续并注明。
11. 保存结果：经用户确认后存到 memory/email/dynamic-content-personalizer/YYYY-MM-DD-<email-or-segment>-personalization.md，保存合并标签/兜底映射、条件块规则和 PII 守卫决策，绝不保存原始 PII 行或含真实订阅者数据的示例渲染。

适用边界 · 注意事项

• 需要构建或命名分群时——用 list-segment-builder。
• 需要撰写主题/正文/CTA 时——用 email-creative-builder。
• 需要给 SEND 维度打分、计算 EQS 或运行 S1/S2/N1/D1 否决时——用 email-quality-auditor。