让 LLM 生成邮件主题行为什么是件危险的事先说结论在 LLM 应用落地的过程中最需要警惕的不是模型能力不够而是职责边界没划清。把“写邮件主题行”这类看似简单的任务完全交给 LLM表面上是提效实际上是在用一个不可控的生成器去承担一个需要确定性兜底的业务动作。很多团队在尝试 Agent、RAG、MCP 这些新概念时往往会先拿“让 AI 帮我写邮件”做 Demo。我见过不少这样的 POC模型跑通、文案通顺、演示效果很好但一上生产就出问题——有的主题行太“AI 味”导致打开率暴跌有的包含过于夸张的营销词被判成垃圾邮件更隐蔽的问题是主题行一旦生成没有修正机会。聊天你可以多轮追问代码你可以编译看报错但邮件发出去收件人看到的第一印象就定死了。这不是模型质量的问题而是任务性质的问题。本文想借“Never let the LLM write the subject line”这个判断把 LLM 应用中的一个核心工程原则讲透什么样的任务适合 LLM 全权负责什么样的任务必须把 LLM 放进约束框架里以及如何通过代码和配置把这些边界落进实际项目里。读完你会得到三样东西一套判断任务该不该交给 LLM 的方法论、一个完整的“LLM 生成 规则兜底”的工程示例、以及一套可以复用到其他场景的容错设计思路。1. 为什么偏偏是“主题行”先别急着把这句话理解成“LLM 写不了好文案”。真要较真LLM 写主题行的能力比大多数普通人强得多——它能模仿爆款结构、能插入数字、懂一点心理学钩子。那问题出在哪第一主题行是一次性交互。代码写错了可以改聊天回复不当可以撤回但邮件主题行一旦点下发送它就是最终版本。没有第二轮修正的机会没有用户反馈的闭环。这类“一锤定音”的任务对错误率的容忍度极低。第二主题行缺少生成时的上下文。模型生成内容时依赖的是你在 Prompt 里给的输入。但一封营销邮件的主题行是否有效取决于收件人的历史行为、当前的市场环境、品牌已有的调性甚至连发送时间都有影响。这些隐含信息很难完整写进 Prompt。没有这些上下文LLM 生成的结果就只能是“看起来合理但永远差点意思”。第三它是“高冲突”场景。主题行一边要吸引点击需要一点夸张和悬念一边又要避免挑衅和垃圾邮件特征需要克制和合规。这种微妙的平衡恰好是规则系统最擅长、而生成模型最难稳定复现的地方。你不可能每次都通过 Prompt 告诉模型“再夸张一点点但不要过头”。这个例子真正想说明的是任务本身对确定性的需求程度。主题行需要的是“在约束函数里求最大值”而 LLM 天然擅长的是“在开放空间里做生成”。两者错位了。2. 不是不信任 LLM而是边界不清很多开发者一听到“不要让 LLM 做 X”本能反应是是不是你们 Prompt 写得不行其实完全不是。这里要区分两个概念工具能力和任务约束。LLM 是一个强大的生成工具能力很强但它不感知任务场景。写代码时编译器会告诉你语法错了写 SQL 时数据库会告诉你字段不存在但生成主题行时没有任何系统会在一秒内告诉你“这个主题行会拉低打开率”。所以在弱反馈任务里LLM 的“强生成能力”反而会变成一种负担——它太会“编”了编得越像真的越难被发现偏差。更准确的说法是LLM 适合“无限逼近”的任务不适合“必须命中”的任务。代码补全编译器反馈闭环强LLM 可以不断逼近正确解。文章大纲生成本来就是开放性任务没有标准答案。主题行生成需要在品牌调性、合规边界、点击率目标等多个硬约束下求一个最优解。这不是“写得顺不顺”的问题而是“结果是否能落在业务约束内”的问题。自动回复客户消息前面几轮无所谓但涉及报价、承诺、法律条款时LLM 一旦自由发挥就是事故。所以真正需要管理的不是模型而是任务边界。那这是否意味着“主题行生成”这类任务完全不能用 LLM并不是。关键在于让 LLM 做辅助而不是决策。具体来说让 LLM 产出 8 个候选主题行然后由规则引擎筛选掉含敏感词、超长、涉嫌垃圾邮件特征的选项再由人工或简单的 A/B 机制决定最终使用哪个。当模型从“第一责任人”降级为“候选生成器”时它的能力得到利用而任务确定性由规则系统兜住。这就是整套工程设计的核心。接下来我会用代码把这个思路落地。3. LLM 在邮件主题行里的设计方案在实际项目里我推荐把“写邮件”拆成三层生成层LLM 根据用户输入和业务数据生成多个候选主题行。过滤层规则引擎对候选结果做合法性检查过滤掉不合规、超长、重复度过高的内容。决策层人工选择或者通过简单的打分机制从剩余候选中挑一个。这个三层设计的目标很清楚让 LLM 的创造性和规则系统的确定性各司其职。3.1 为什么需要过滤层先看一个现实场景。你让 LLM 给老客户写一封“产品升级通知”的主题行它生成的结果可能包括“你还没用过的新功能已经悄悄上线了”有点悬疑但可能被当作钓鱼邮件“重大消息你的产品体验即将改变”重大消息是一个高频垃圾词“你的账户因新功能升级需要立即关注”“账户”和“立即”容易触发客服投诉内容本身没有错但落在不同行业、不同目标客户身上风险等级完全不同。这就是过滤层的价值把“模型认为合理”的内容映射到“你的业务能接受”的范围里。一个轻量级的过滤函数从敏感词、长度限制、表情符号频率、垃圾邮件特征等维度打分就能砍掉相当比例的高风险生成结果。3.2 核心代码候选生成与规则过滤下面是一个完整的 Python 示例。它使用 OpenAI 兼容的接口生成 8 个候选主题行然后用规则引擎过滤最终输出 3 个安全结果。# 文件路径subject_line_engine.py import os import re from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL, https://api.openai.com/v1), ) SPAM_WORDS [免费, 中奖, 优惠, 立即, 限时, 清仓, 现金, 点击领取] MAX_LENGTH 60 MIN_LENGTH 5 MAX_SPAM_SCORE 1 def generate_candidates(prompt_text: str, n: int 8) - list[str]: 调用 LLM 生成候选主题行。 response client.chat.completions.create( modelgpt-4o-mini, temperature0.8, messages[ {role: system, content: 你是一名资深邮件营销文案专家请为邮件写出吸引人的主题行。}, {role: user, content: f邮件内容概要{prompt_text}\n请生成 {n} 个主题行每行一个不要加编号。}, ], ) content response.choices[0].message.content or lines [line.strip().strip().strip() for line in content.splitlines() if line.strip()] return lines[:n] def filter_by_rules(candidates: list[str]) - list[str]: 规则过滤长度、敏感词、垃圾词频次、全大写、重复标点。 safe [] for c in candidates: if len(c) MIN_LENGTH or len(c) MAX_LENGTH: continue if any(word in c for word in SPAM_WORDS): continue if c.isupper(): continue if re.search(r[!?。]{2,}, c): continue spam_score sum(1 for word in c.lower().split() if word in SPAM_WORDS) if spam_score MAX_SPAM_SCORE: continue safe.append(c) return safe if __name__ __main__: raw_prompt 我们发布了新的数据分析功能可帮助客户自动定位转化流失原因。 candidates generate_candidates(raw_prompt) print( 候选主题行 ) for i, item in enumerate(candidates, 1): print(f{i}. {item}) print(\n 规则过滤后 ) for i, item in enumerate(filter_by_rules(candidates), 1): print(f{i}. {item})这段代码反映的设计重点是LLM 负责数量规则负责质量两者各自只做自己擅长的事。如果你不希望直接把 OpenAI API 写死在代码里也可以把模型调用封装成接口通过配置切换不同的推理服务例如本地部署的 vLLM、Ollama或者云厂商的模型服务。LLM 的推理引擎对这套代码的影响很小因为代码关注的是生成、过滤、决策这条链路而不是具体模型。3.3 决策层的选择策略过滤层输出 3 个左右的安全候选后决策层有几种做法人工选择在管理后台展示候选列表让运营人员点选。最稳妥适合初次上线的场景。随机选择在多个安全候选中随机选一个适合测试不同文案的点击率。基于规则打分给每个候选算一个“预期点击指数”规则可以包含是否包含数字、是否包含问句、是否包含具体业务词汇。注意打分规则需要数据支撑如果没有历史数据先把分数全部置为相等。def score_candidate(subject: str) - float: 一个朴素的主题行打分函数可按业务数据迭代。 score 0.0 if any(ch.isdigit() for ch in subject): score 1.0 if subject.endswith(?): score 0.5 if len(subject) 20: score 0.5 return score def decide_subject(candidates: list[str]) - str: 决策层返回得分最高的主题行。 if not candidates: return 产品更新通知 return max(candidates, keyscore_candidate)注意这个打分函数只是演示“规则可参与决策”它不是最优算法。真实项目中分数权重应该由历史发送数据和 A/B 测试结果反推出来。4. 从邮件扩展到 LLM Agent 的职责边界理解了“LLM 生成候选 规则系统兜底”这个模式后你会发现它可以迁移到很多 Agent 场景里。现在大家都在讨论 LLM Agent、MCP、编排框架。但 Agent 项目里最常见的失控原因不是模型不够强而是Agent 的自主裁量权太大。你让它“处理一个客服工单”它可能一路写完回复并执行了发送而中间没有任何人工或规则检查点。正确做法是给 Agent 加“保险丝”步骤级约束Agent 的每一步都通过一块明确的状态机来驱动而不是让模型递归式地决定下一步。输出级校验模型生成的结果不能直接进入执行阶段必须先过一层规则校验或者人工确认。工具级权限Agent 可以调用 API但敏感操作一律需要二次确认且所有调用都要有审计日志。这跟邮件主题行里的设计是同构的。LLM 永远在意“我说的话像不像一个合理的回答”而规则系统在意“这个东西能不能安全地进入生产环境”。两者缺一不可。4.1 一个可以借鉴的 Agent 编排思路为了更直观假设你在构建一个“自动回复用户邮件”的 Agent它收到用户的售后邮件后需要生成回复草稿。你可以这样拆分生成层LLM 基于邮件内容生成回复草稿。过滤层检查草稿中是否包含不确定的承诺、价格数字、法律条款。如果包含标记为“需要人工审核”。权限层所有超出“常规说明”范围的回复比如退款、赔偿、投诉升级一律不自动发送转人工队列。对应代码可能是def draft_reply(incoming_email: str) - dict: draft llm_generate_draft(incoming_email) flags [] if any(word in draft for word in [退款, 赔偿, 期限, 法律]): flags.append(manual_review) if contains_concrete_number(draft): flags.append(manual_review) if not flags: flags.append(auto_approve) return {draft: draft, decision: flags} def execute_reply(incoming_email: str): result draft_reply(incoming_email) if manual_review in result[decision]: send_to_human_approval(result[draft]) else: send_email(result[draft])这套代码的思路比“让 Agent 自由发挥”要稳得多。生产环境里意外事故几乎都来自“模型认为没问题”的环节。5. 配置与部署如何把规则系统做成可维护的服务如果只把过滤逻辑写死在 Python 函数里项目一旦扩大规则会越堆越多最后变成一团乱麻。更好的做法是把过滤规则做成可配置化的决策表比如用 YAML 或 JSON 维护线上可以动态调整不用改代码。下面是一个过滤规则配置的示例# 文件路径subject_line_filters.yaml spam_words: - 免费 - 立即 - 限时 - 点击领取 - 中奖 length_limit: min: 5 max: 60 reject_all_caps: true reject_excessive_punctuation: true reject_patterns: - [【] - RE[:] - FWD[:]对应地在代码里读取这份配置并基于配置执行过滤# 文件路径filter_engine.py import re import yaml class FilterEngine: def __init__(self, config_path: str): with open(config_path, r, encodingutf-8) as f: self.config yaml.safe_load(f) self.spam_words self.config[spam_words] self.length_min self.config[length_limit][min] self.length_max self.config[length_limit][max] def is_safe(self, subject: str) - bool: if len(subject) self.length_min or len(subject) self.length_max: return False if any(word in subject for word in self.spam_words): return False if self.config[reject_all_caps] and subject.isupper(): return False if self.config[reject_excessive_punctuation] and re.search(r[!?。]{2,}, subject): return False for pattern in self.config.get(reject_patterns, []): if re.search(pattern, subject): return False return True这样做的好处是业务人员可以自行调整敏感词不需要改代码。规则变更可以走配置发布流程而不是发版。多环境测试、预发、生产之间可以有不同的过滤器配置。在团队协作的场景里配置化管理是保证规则系统长期可维护的底线。你永远不希望在某个凌晨三点运营人员给你打电话说“帮我加一个禁用词”而你必须发一个新版本才能解决。6. 常见问题与排查思路如果把“LLM 生成候选”这套方案落地实际运行时会遇到几个典型的坑。这里列成表格供快速定位问题现象可能原因排查方式解决方案候选结果经常被全部过滤过滤规则过严或 Prompt 没有说明约束查看过滤日志统计每次被过滤的原因分布调整规则阈值或者完善 Prompt 中的约束描述生成的主题行有明显“AI味”没有给出足够的业务语境和调性示例检查 Prompt 中是否包含品牌调性说明或示例在 Prompt 中加入正反面示例例如“不要使用感叹号保持专业语气”API 调用成本过高候选数量设置过大且每次请求都传大量上下文查看每次请求的 token 数和候选数量配置减少候选数或改用更小的模型如 gpt-4o-mini 或本地小模型过滤层被绕过代码中直接使用了原始模型输出没有走过滤函数检查调用链中是否所有输出都经过 is_safe在输出层用装饰器或中间件统一接管模型结果生成延迟高模型地址是海外服务且请求没有超时控制检查网络链路和请求耗时配置超时时间、重试机制或者把模型服务部署在更近的区域规则与业务脱节规则写死在代码里更新成本高检查规则是否可配置迁移到 YAML/JSON 配置中心7. 最佳实践与工程建议结合邮件主题行这个案例以及它映射到的 LLM Agent 应用经验我总结几点工程建议。7.1 建模阶段先划“容错边界”在写任何 LLM 应用之前先问自己一个问题如果模型输出完全错误对系统影响有多大如果影响很小可以容忍比如生成一个周末活动的建议文案那可以给模型更大的自由度。如果影响很大比如自动发送邮件、执行订单操作、修改数据库记录那必须把“LLM 输出”到“系统动作”之间加一道硬边界。这道边界可以是规则过滤、人工审核、或双重确认。不要依赖 Prompt 来保证安全因为 Prompt 是软约束规则过滤才是硬约束。7.2 日志与审计是 LLM 应用的生命线传统应用记录的是日志LLM 应用需要记录的是“决策轨迹”。每次模型输出的原始结果、过滤规则命中情况、最终决策结果、人工修改记录都应该完整落库。这样做的意义在出问题时尤其明显。如果某封邮件被投诉了你可以很快查出“当时模型生成了什么哪条规则没有拦住”。好的日志还能帮你不断优化规则和 Prompt。7.3 用“候选集”代替“单次生成”几乎所有生成类任务都可以改造成“生成多个候选 → 并行校验 → 选择一个”这样能显著提高整体决策质量。原因很简单单个生成结果如果出错没有回退空间但如果先生成 5 个过滤掉 3 个从剩下的里面选即使模型单次生成质量一般整体还是有可用的结果。这种思路同样适用于其他场景代码注释生成、SQL 语句生成、周报标题生成。它牺牲了一点延迟和 token 成本换来的却是可控性和稳定性。7.4 安全与权限的最小化原则在包含 Agent、MCP 这类工具调用的项目里一定要坚持最小权限原则。给 Agent 的 API Key 只授予执行任务所需的最小范围所有敏感操作明确拒绝。不要因为“模型很聪明能自己知道边界”而盲目放开权限。模型没有“意图”它只是在做概率生成安全边界完全由工程系统控制。这也是生产环境与 Demo 环境最本质的区别。8. 什么情况下可以放心让 LLM 直接生成主题行写到这里可能会有人问是不是所有场景都不能让 LLM 直接做决策当然不是。关键在于场景本身是否具备自修正能力。如果满足以下条件可以适当放开有即时反馈闭环。例如你可以在邮件发送后通过真实反馈微调整个生成策略。任务本身是内聚的不涉及多步操作。LLM 要做的只是生成一个文本片段不需要它决定“发送给谁、什么时候发、是否跳过审核”。错误成本可接受。例如你只是在写一个内部产品周报的标题错了也没关系因为读者是内部成员且往往有上下文。但一个典型的企业对外邮件系统以上三个条件通常都不成立。这也是为什么我建议默认警惕按需放开。如果你正在做的是一个轻量级个人工具比如用 LLM 自动给自己的笔记生成标题那直接让模型输出就好。如果模型偶尔起了一个奇怪的标题你随时可以手动改。这种场景下加太多规则反而笨重。边界不是一刀切而是跟着任务的“反馈速度和失败成本”走。9. 总结“Never let the LLM write the subject line”这句话与其说是对某个功能的具体吐槽不如说是在提醒我们LLM 是生成器不是决策器。生成器擅长提供可能决策器负责保证安全。两者没有高低之分只是职责不同。真正优秀的 LLM 应用一定是把模型的强生成能力放在“候选”的位置上同时用规则系统、人工审核、权限控制这些工程手段去处理“确定”的部分。具体到这个主题下你需要记住三个落点邮件主题行只是一次性决策任务的缩影。任何一步到位的生成任务都值得认真考虑它是否需要规则兜底。用“LLM 生成候选 规则过滤 决策层选择”的三层模式既保留了模型的文案创造力又避免了业务风险。在 Agent、MCP 等更复杂的 LLM 应用里边界设计、日志审计、最小权限是最重要的工程习惯而不是可选项。接下来你可以做的事情很具体先把自己的一个 LLM 功能拿出来画出“模型输出 → 系统动作”的链路看看中间有没有硬校验。如果没有就先从加一个轻量级过滤器开始。这套方法不难但它能把很多“看起来能跑”的 Demo变成真正敢上生产的系统。