LLM写邮件主题行是陷阱？生成候选+规则校验+人工兜底的工程化方案

之前在做一套企业内部的邮件触达系统时业务方提了一个需求根据邮件正文自动生成邮件主题行。当时第一反应是“这不是 LLM 最擅长的活吗”于是直接调模型批量生成结果上线后邮件打开率不升反降还出现了几封主题行和正文完全无关的严重事故。排查一圈后发现问题根本不是模型能力不够而是我们把“生成主题行”这件事想得太简单了。今天这篇就围绕 “Never let the LLM write the subject line” 这条经验展开聊聊 LLM 生成邮件主题行邮件标题的坑、根因、以及一套能落地的工程化方案。这篇文章适合正在做邮件服务、消息通知、营销自动化或者想在业务里接入 LLM 文本生成能力的新手和初中级开发者。读完你会理解为什么不能让 LLM 直接“自由发挥”写主题行什么场景下可以安全使用 LLM以及如何通过 Prompt 设计、规则校验、候选生成、人工兜底等方式把 LLM 从“作者”变成“参谋”。1. “LLM 写主题行”为什么是个陷阱1.1 先还原一下当时的场景需求本身不复杂系统里每天会有几十封业务邮件正文是运营写好的但主题行经常空着或者随手填一个“通知”“周报”之类的词。业务方希望用大模型自动生成主题行提高邮件的打开率和阅读体验。最初我写了一个非常简单的 Prompt大意是“请根据以下邮件正文生成一个吸引人的主题行。”然后循环调用 LLM API 处理所有邮件。刚跑通时看着效果还行主题行读起来通顺也有一定吸引力。但随着样本量变大问题开始暴露。1.2 LLM 生成主题行的三个典型问题我总结了实际踩过的三类问题第一类是信息不准确。模型会在主题行里补充正文中不存在的细节。比如正文只是在同步项目进度主题行却生成“重大突破”“版本即将上线”这会让收件人对邮件内容产生错误预期。第二类是风格漂移。同样一批邮件LLM 生成的每封主题行风格差异很大有的是疑问句有的是感叹句有的又变成了名词短语。放在单封邮件里没问题但放在一个完整的邮件序列里会显得非常不专业。第三类是缺乏“人味”和决策依据。主题行本质上不是单纯的自然语言生成任务它背后涉及邮件目标、受众画像、品牌语气、营销策略。这些信息如果不在 Prompt 里给足LLM 只能靠猜猜出来的结果自然不稳定。1.3 这句英文在提醒我们什么“Never let the LLM write the subject line” 这句英文翻译过来就是“永远不要让 LLM 直接写主题行”。这里的“写”指的是完全放手让模型自由生成、直接作为最终输出。更准确地说我们不应该让 LLM 独自承担主题行的最终决策责任。这句话背后其实是一个通用的 LLM 工程原则LLM 适合做“生成候选”而不适合做“最终决策”。尤其在文案类任务里模型生成的文本质量波动大缺少稳定性和规则约束必须外面再包一层规则校验和人工确认机制。2. 根因分析LLM 为什么写不好主题行要解决这个问题不能只停留在“效果不好”的层面。我们需要理解LLM 生成主题行时的内部逻辑和人类写邮件标题时的思考过程本质上存在几个错位。2.1 训练目标与主题行逻辑不匹配LLM 的训练目标本质上是预测下一个 Token它学到的是一种“文本延续”的概率分布。当你给它一段邮件正文它能生成最“像话”的下一段文字但这种“像话”并不等于主题行该有的逻辑。邮件主题行需要完成至少三个任务概括正文核心信息、吸引收件人打开、符合邮件发送方的商业意图。而 LLM 在生成时更倾向于流畅、通顺、信息密度高的表达它并不天然理解“打开率”“点击率”这些概念。换句话说模型的目标函数和业务的目标函数不一致。2.2 上下文缺失LLM 不知道“你是谁”“发给谁”邮件主题行的质量高度依赖上下文。一封给老客户发的促销邮件和给内部同事发的系统告警邮件主题行的写法完全不同。前者可能适合制造稀缺感和紧迫感后者应该冷静、准确、包含必要的告警标识。但如果我们的 Prompt 只传了邮件正文LLM 根本不知道这封邮件的发送方是谁品牌语气是什么收件人是谁处于什么生命周期阶段这封邮件的历史行为数据如何这次发信的营销目标是什么。这些缺失信息LLM 是不可能凭空猜对的。它只能根据训练语料里的统计规律生成一个“最平均”的主题行而这个“最平均”往往就意味着平庸甚至在某些场景下非常突兀。2.3 风格漂移与事实幻觉风格漂移的根因在于LLM 每次生成都是一次全新的采样。模型没有长期记忆也不存在一个“统一风格控制器”。要让主题行风格稳定只能靠 Prompt 中的风格描述、示例few-shot、以及生成后的规则校验来共同约束。事实幻觉则更危险。当模型生成的文本里包含正文没有的信息时读者会认为这是发件人有意写的从而产生误解。尤其是在系统通知、账单提醒、安全告警这类邮件里主题行的错误信息可能直接影响用户操作甚至带来合规风险。2.4 评估标准缺失没有反馈闭环传统软件开发里我们写一个函数输入固定输出可以断言。但 LLM 生成文本是概率性的同样一个 Prompt 多次调用得到的结果可能不同。如果没有自动化评估手段我们根本无法判断“这次生成得好不好”。正常的工程化做法是建立反馈闭环把生成结果的结构化特征主题行长度、关键词是否命中、是否包含敏感词、是否包含幻觉信息抽出来做规则校验再结合用户的打开率、退订率等真实反馈持续调优。但初期我们完全没有做这套东西所以问题只能在上线后暴露。3. 哪些场景适合/不适合让 LLM 写主题行经过了这次事故我重新梳理了 LLM 生成主题行的场景边界。并不是所有场景都不能用 LLM而是需要分类讨论。3.1 适合 LLM 参与的场景以下场景推荐 LLM 参与生成主题行营销邮件的 A/B 测试需要生成多个风格不同、吸引眼球的主题行让运营人员从中选择。非关键通知的标题建议比如周报汇总、动态推送允许生成结果有一定风格波动。内容型邮件的主题行生成例如资讯周报、博客更新正文本身就是公开内容模型基于正文生成主题行相对安全。多语言场景LLM 生成长度短、结构清晰的多语言主题行比人工翻译成本低很多。在这些场景里LLM 的价值是“批量产出候选方案”最终决策权仍然掌握在运营或规则引擎手里。3.2 不适合 LLM 直接生成最终结果的场景以下场景需要高度谨慎系统告警邮件主题行必须包含精确的错误类型、影响范围、恢复状态LLM 自由发挥会造成信息失真。账单与交易通知涉及金额、时间、订单号等事实信息主题行应该由模板渲染而不是 LLM 生成。合规敏感邮件法律通知、合同变更、隐私政策更新主题行措辞需要法务确认不能让模型“发挥”。高频率 A/B 测试流量很小、无法承受状态波动的场景比如全量发送的系统邮件。判断原则其实很简单如果主题行出错会导致严重后果就不要让 LLM 直接写如果主题行只是“多个可变选项之一”可以放心让 LLM 参与生成。4. 正确的使用姿势让 LLM 生成候选而不是最终决策在安全边界内使用 LLM 生成主题行核心思路可以总结成一句话LLM 负责天马行空规则负责拉回地面人来负责最后一公里。4.1 核心链路设计我在项目里把流程改成了这样邮件正文 业务元数据 ↓ Prompt 组装角色、任务、约束、示例 ↓ LLM 批量生成 N 个候选主题行 ↓ 规则校验层过滤长度、敏感词、幻觉检测 ↓ 打分排序关键词命中、风格一致性 ↓ 人工/规则最终选择 → 发送这个链路看起来多了一步实际上能避免绝大多数问题。4.2 Prompt 设计的关键给足上下文要让 LLM 产出高质量候选Prompt 就不能只传正文。完整 Prompt 至少应该包含角色设定你是一名资深的邮件营销文案专家任务说明根据正文和给定的信息生成多个主题行候选邮件目标是通知、营销、还是维护客户关系语气要求正式、轻松、有紧迫感还是中性风格示例给 2-3 个符合要求的例子禁止事项不得编造正文中不存在的信息不得使用诱导性词汇输出格式按 JSON 数组返回方便程序解析。当 Prompt 的信息密度足够高时LLM 的生成质量会明显提升风格漂移问题也会缓解。4.3 规则校验层把“概率输出”变成“可控输出”规则校验层是整套方案的稳定器。即使 LLM 偶尔发挥失常规则也能把不合格的结果拦截下来。校验规则可以按下面几类设计长度校验主题行长度限制在多少字以内电商邮件通常控制在 20-30 个字符中文邮件可以放宽到 20-40 个字符事实校验主题行是否包含正文中的关键数字、专有名词、日期敏感词校验是否包含垃圾邮件常见触发词例如“免费”“中奖”“立即购买”等结构校验是否包含正文中不存在的主体信息风格校验是否以禁止的标点符号开头或结尾例如多个感叹号。4.4 永远保留人工兜底无论 Prompt 多完善、规则多严格都不能完全信任自动生成的最终结果。工程上可以这样设计把 LLM 候选 规则校验后的结果作为“推荐”推送给运营人员确认确认后进入正式发送队列。如果运营人员有批量发送需求也可以设置“白名单模板”只有命中模板格式才自动发送。5. 完整实战Python 调用 LLM API 生成邮件主题行下面进入实操环节。我们以 Python 为例演示如何实现一套“生成候选 规则校验 可选人工确认”的主题行生成流程。示例中调用 LLM API 的代码以 OpenAI SDK 风格示意具体版本与模型名称请根据你的实际环境调整。5.1 环境准备本示例使用的环境如下Python 3.9示例在 Windows / macOS / Linux 均可运行openaiSDK不同版本 API 差异较大示例中用到的方法以 1.x 版本为基础实际版本请按官方文档调整无需额外安装 Web 框架纯脚本演示你需要一个可用的 LLM API Key建议通过环境变量传入不要硬编码在代码中。版本说明LLM 工具链迭代很快本文示例重点演示设计思路不绑定某个具体模型。你完全可以替换为其他兼容 OpenAI API 的模型服务。5.2 项目结构初始化项目目录结构如下subject-line-generator/ ├── config.py # 配置常量与 Prompt 模板 ├── llm_client.py # LLM API 调用封装 ├── validator.py # 规则校验层 ├── generator.py # 主流程生成候选 校验 排序 └── main.py # 命令行入口示例5.3 配置与 Prompt 模板创建config.py把“容易变化”的内容统一放这里方便维护。# config.py import os # 从环境变量读取 API Key不要硬编码 LLM_API_KEY os.getenv(LLM_API_KEY) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.example.com/v1) LLM_MODEL os.getenv(LLM_MODEL, your-model-name) # 生成候选数量 CANDIDATE_COUNT 5 # 主题行长度约束单位字符 MIN_SUBJECT_LENGTH 4 MAX_SUBJECT_LENGTH 60 # 敏感词表可根据业务积累持续扩充 SENSITIVE_WORDS_WARNING [免费, 中奖, 限时抢购, 立即购买, 稳赚] SYSTEM_PROMPT 你是一名资深的邮件营销文案专家擅长撰写既准确又有吸引力的邮件主题行。 你的任务是根据用户提供的邮件正文和业务说明生成 {candidate_count} 个主题行候选。 要求 1. 主题行必须准确概括正文核心内容不得编造正文中不存在的细节或事实。 2. 主题行风格应符合用户指定的语气。 3. 避免使用夸大、诱导、垃圾邮件常用词汇。 4. 每个主题行控制在 {min_length}-{max_length} 个字符之间。 5. 只输出 JSON 数组数组中的每个元素是一个字符串不要输出其他内容。 示例输出格式 [主题行候选1, 主题行候选2, 主题行候选3] 这里有一点需要说明Prompt 中使用了{candidate_count}、{min_length}、{max_length}占位符实际组装时会调用format()填充。把系统提示词放在配置里后续要调语气、改字数限制都只需要改配置不需要动代码。5.4 LLM API 调用封装创建llm_client.py封装一次对 LLM 的调用。示例中只保留最核心的调用逻辑。# llm_client.py import json import openai from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL client openai.OpenAI(api_keyLLM_API_KEY, base_urlLLM_BASE_URL) def generate_subject_candidates(system_prompt: str, user_content: str) - list[str]: 调用 LLM 生成主题行候选列表。 返回解析后的字符串列表。如果解析失败返回空列表。 try: response client.chat.completions.create( modelLLM_MODEL, messages[ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperature0.9, ) content response.choices[0].message.content.strip() # 兼容模型多输出一段说明文字的情况尽量提取 JSON 数组 candidates _parse_json_array(content) return candidates except Exception as e: print(f[llm_client] 调用失败: {e}) return [] def _parse_json_array(text: str) - list[str]: 从模型输出中解析 JSON 数组。 try: data json.loads(text) if isinstance(data, list): return [str(item).strip() for item in data if str(item).strip()] except json.JSONDecodeError: pass # 如果模型输出包含前后解释文字尝试截取 [ ] 之间的内容 start text.find([) end text.rfind(]) if start ! -1 and end ! -1 and end start: try: data json.loads(text[start : end 1]) if isinstance(data, list): return [str(item).strip() for item in data if str(item).strip()] except json.JSONDecodeError: pass return []这段代码有两个细节temperature0.9是刻意调高的。因为我们需要模型产出多个风格不同的候选温度太低时5 个候选可能长得差不多_parse_json_array做了解析兜底。实际使用中模型偶尔会输出“以下是生成的候选...”这类带前后缀的内容不能直接json.loads。5.5 规则校验层创建validator.py把不可控的模型输出过滤成可控的结果。# validator.py from typing import Callable from config import SENSITIVE_WORDS_WARNING def validate_length(subject: str, min_length: int, max_length: int) - bool: 校验主题行长度不满足则丢弃。 return min_length len(subject) max_length def contains_sensitive_word(subject: str, sensitive_words: list[str] | None None) - bool: 检查主题行是否包含敏感/诱导性词汇。 words sensitive_words or SENSITIVE_WORDS_WARNING for word in words: if word in subject: return True return False def validate_subject(subject: str, min_length: int, max_length: int) - bool: 综合校验单个主题行是否合格。 if not subject: return False if not validate_length(subject, min_length, max_length): return False if contains_sensitive_word(subject): print(f[validator] 命中敏感词过滤: {subject}) return False if subject.endswith((, !, , ?)): print(f[validator] 过滤高营销感标点结尾: {subject}) return False return True def filter_candidates( candidates: list[str], min_length: int, max_length: int, ) - list[str]: 过滤候选列表返回通过校验的主题行。 valid [] for item in candidates: if validate_subject(item, min_length, max_length): valid.append(item) else: print(f[validator] 候选未通过校验: {item}) return valid校验规则是逐步叠加的。最初我们只写了长度校验后来发现“免费”“立即购买”这类词对系统通知类邮件是致命的才补了敏感词校验。建议你根据业务反馈持续扩充校验函数。5.6 主流程创建generator.py把“组装 Prompt → 调用 LLM → 过滤校验”串起来。# generator.py from config import ( CANDIDATE_COUNT, MAX_SUBJECT_LENGTH, MIN_SUBJECT_LENGTH, SYSTEM_PROMPT, ) from llm_client import generate_subject_candidates from validator import filter_candidates def build_user_prompt( email_body: str, email_goal: str, tone: str, audience: str, ) - str: 组装用户部分 Prompt尽量把业务上下文描述清楚。 return f 【邮件正文】 {email_body} 【邮件目标】 {email_goal} 【目标受众】 {audience} 【语气要求】 {tone} 请根据以上信息生成主题行候选只输出 JSON 数组。 def generated_subject_lines( email_body: str, email_goal: str, tone: str, audience: str, ) - list[str]: 主流程生成候选 - 过滤 - 返回最终可用主题行列表。 system_prompt SYSTEM_PROMPT.format( candidate_countCANDIDATE_COUNT, min_lengthMIN_SUBJECT_LENGTH, max_lengthMAX_SUBJECT_LENGTH, ) user_prompt build_user_prompt(email_body, email_goal, tone, audience) print( 正在调用 LLM 生成候选...) candidates generate_subject_candidates(system_prompt, user_prompt) print(f 模型返回 {len(candidates)} 个候选: {candidates}) valid_candidates filter_candidates( candidatescandidates, min_lengthMIN_SUBJECT_LENGTH, max_lengthMAX_SUBJECT_LENGTH, ) return valid_candidates5.7 命令行入口创建main.py方便直接运行验证。# main.py import os from generator import generated_subject_lines if __name__ __main__: # 示例模拟一封项目同步邮件的正文 sample_body 各位同事 本周的项目进度如下 1. 用户中心模块已完成接口联调预计下周三进入集成测试。 2. 支付模块开发进度 80%主要剩余退款流程的异常处理。 3. 风险控制模块已完成第一轮代码评审当前存在 3 个待修复问题。 请相关同学反馈当前风险项和需要的支持。 项目组 result generated_subject_lines( email_bodysample_body, email_goal内部项目进度同步不制造紧急感语气克制, tone专业、中性、不夸张, audience内部项目成员和技术负责人, ) print( * 40) print(最终可用主题行候选:) for idx, item in enumerate(result, start1): print(f{idx}. {item}) # 如果没有可用候选这里应该触发人工兜底逻辑 if not result: print(警告没有候选通过校验请人工编写主题行)5.8 运行与预期结果在项目根目录执行export LLM_API_KEY你的-api-key export LLM_BASE_URLhttps://你的服务地址/v1 export LLM_MODEL你的模型名称 python main.py预期输出类似下面这样实际内容因模型而异 正在调用 LLM 生成候选... 模型返回 5 个候选: [项目进度周同步用户中心联调完成, 本周项目进展同步与风险反馈, 激动人心的突破, 项目周报 2024-01-10, 请查收本周项目进度] [validator] 候选未通过校验: 激动人心的突破 [validator] 候选未通过校验: 请查收本周项目进度 最终可用主题行候选: 1. 项目进度周同步用户中心联调完成 2. 本周项目进展同步与风险反馈 3. 项目周报 2024-01-10注意输出中出现了“激动人心的突破”这条候选。它本身不是坏文案但在内部项目同步邮件里语义过度渲染会被规则直接过滤。这正是整套链路的意义LLM 负责发散的候选生成规则负责守住质量底线。6. 进阶用 Agent 编排框架把流程化6.1 为什么需要 Agent 编排如果只是生成主题行单个函数调用就够了。但在实际业务里“生成主题行”往往只是邮件发送流水线的一个环节。你可能还需要抓取网页或知识库内容作为邮件正文素材调用向量数据库做 RAG 检索补充背景资料维护多个大模型供应商的切换与降级把生成结果写入工单系统或 CRM。这时候就需要引入 Agent 编排框架把这几个独立能力串成一个工作流。这也是近一年 LLM 应用开发里讨论热度很高的方向比起单独调 API开发者更关心如何把模型能力稳定地编排进业务流程中。6.2 一个简单的生成-校验-重试循环即使不引入重型框架也可以实现一个“生成 → 校验 → 重试”的轻量循环提高整体可用性。# retry_example.py import time from config import CANDIDATE_COUNT, MAX_SUBJECT_LENGTH, MIN_SUBJECT_LENGTH from generator import build_user_prompt from llm_client import generate_subject_candidates from validator import filter_candidates def generate_with_retry( email_body: str, email_goal: str, tone: str, audience: str, max_retry: int 2, ) - list[str]: 生成候选如果全部被过滤则重试最多重试 max_retry 次。 for attempt in range(max_retry 1): print(f--- 第 {attempt 1} 次尝试 ---) user_prompt build_user_prompt(email_body, email_goal, tone, audience) candidates generate_subject_candidates( system_prompt, user_contentuser_prompt, ) valid filter_candidates( candidatescandidates, min_lengthMIN_SUBJECT_LENGTH, max_lengthMAX_SUBJECT_LENGTH, ) if valid: return valid print(本批次全部候选未通过校验准备重试...) # 简单退避避免立即重试导致限流 time.sleep(1.5) return []这个循环解决的是“LLM 一次生成效果不好”的容错问题。如果第一次生成的候选都被规则拦截就换一批重新生成。虽然不能保证每次都产出好结果但显著提高了最终成功率。如果未来业务复杂度继续上升可以调研 Spring AI、LangChain、Dify 等编排框架把 Prompt 模板管理、模型供应商切换、数据检索、人工审核流都纳管进来。当前阶段一个轻量 Python 脚本已经足够。7. 常见问题与排查思路问题现象常见原因解决思路生成的主题行与正文无关Prompt 缺少足够上下文只传了正文在 Prompt 中补充邮件目标、受众、语气必要时提供 few-shot 示例多个候选风格差异过大温度过高或 Prompt 中没有风格约束降低 temperature在 Prompt 中明确“语气要求”并给出风格示例主题行包含正文中不存在的细节LLM 幻觉在 Prompt 中强调“不得编造事实”增加命名实体/日期校验生成结果频繁被规则拦截规则过于严格或模型输出格式不稳定先单独检查模型输出格式再检查规则约束是否合理适当放宽非关键规则API 调用超时或限流并发过高增加超时、重试、退避机制考虑批量排队模型输出带有解释文字难以直接解析输出格式约束不够在 Prompt 中写清楚“只输出 JSON 数组”后处理提取 JSON 片段发送后打开率仍然很低只优化主题行邮件正文/发送时间等其他因素影响建立 A/B 测试用真实反馈数据迭代排查时建议按这个顺序来先看模型原始返回确认生成质量再跑一遍校验函数确认拦截规则最后检查 Prompt 是否把关键业务信息传全了。绝大多数问题都出在 Prompt 的上下文缺失上。8. 最佳实践与工程建议8.1 人机协作别让模型独自决策在“生成主题行”这个场景里最安全的人机协作模式是LLM 产出多个候选规则引擎过滤明显不合理的内容人工从通过校验的候选中选择或者把高频使用的固定模板沉淀成可复用方案。如果邮件的量级很大可以把“人工确认”做成抽检模式低风险邮件走自动高风险邮件强制人工确认。8.2 建立结构化日志与反馈闭环每次生成请求都应该记录邮件 IDPrompt 版本模型输入输出完整内容校验函数的命中情况最终使用的主题行后续打开率、点击率如果能拿到。这些日志不仅是排障依据也是持续优化 Prompt 和规则的数据基础。通过对比不同 Prompt 版本的打开率能更客观地评估效果。8.3 安全与合规注意调用 LLM API 时务必注意以下几点API Key 通过环境变量或密钥管理服务注入不要硬编码在代码里更不要提交到 Git 仓库。发送给模型的邮件正文可能包含内部敏感信息。上线前要评估数据出境范围并选择符合合规要求的部署方式。涉及用户隐私和账单信息的邮件主题行建议使用模板渲染不让任何生成式模型介入。避免使用疑似垃圾邮件的敏感词否则可能影响邮件到达率。8.4 性能与成本优化LLM 调用不是免费的生成主题行这种短文本任务重点从两个方向控制成本尽可能用轻量模型。生成短文本并不需要超大参数的模型选择能力满足要求的模型延迟和成本都会显著下降。设计缓存。相同正文或相同模板的邮件可以直接命中历史生成结果避免重复调用。结尾回到开头那个需求。现在我们的邮件系统里依然保留了“自动生成主题行”的功能但它已经变成了一个“候选池”LLM 负责根据正文、受众、语气生成多个选项规则校验层负责过滤不可用的内容运营人员一键确认后才进入发送队列。这之后再也没有出现过“主题行与正文完全无关”的事故。“Never let the LLM write the subject line” 并不是让你彻底不用 LLM而是提醒你要让模型做它擅长的事同时用工程手段守住质量底线。如果你也在做类似的文案生成类功能不妨先把“模型写什么都能用”的思维放下改成“模型生成 规则校验 人工兜底”的三角结构。这套思路迁移到邮件正文摘要、短信文案、应用推送通知标题等场景同样适用。