Never let the LLM write the subject line 这句话是我最近整理 AI 写作工作流时越来越认同的一条原则。先给结论LLM 可以帮你写正文、列提纲、整理素材、生成多个候选标题但到了邮件主题行、文章标题、知识库条目标题这种最终拍板文案我基本不会让它直接定稿。不是 LLM 没有能力写标题而是标题承担的职责和正文完全不同。正文追求信息完整、逻辑清晰、表达流畅标题追求准确压缩、触发阅读、让人预期一致、被系统稳定检索。LLM 擅长前者在后者上其实并不占优。你让它随便想个标题它大概率给你一句放之四海而皆准的废话。这篇内容主要面向三类人用 LLM 辅助写邮件、写周报、写方案的重度用户做公众号、博客、产品文案的内容生产者以及正在搭知识库、RAG 检索链路或 Agent 自动化的开发者。核心思路只有一句话把生成权和确认权拆开模型负责出候选人负责拍板系统负责校验。下面按真实踩坑顺序拆开讲。1. 先搞清 subject line 到底在替谁工作1.1 邮件主题、文章标题、知识库条目标题本质是同一种东西很多人把标题当成正文的附属品写完正文再顺手让模型生成一个。但在真实系统里标题和主题行是独立的元信息它同时承担三层职责给人类判断、给系统判断、给流程判断。给人类判断收件人扫一眼邮件主题决定要不要打开读者扫一眼文章标题决定要不要点进来。这个判断发生在正文被阅读之前而且通常只有几秒钟。给系统判断邮件客户端、RSS 阅读器、知识库、RAG 检索流程都拿标题做排序、归档、召回的主要依据。系统在多数时候不看正文只看元数据。给流程判断在自动化流水线里标题经常直接变成文件名、数据库主键、日志标识。它一旦不稳定下游全部乱掉。所以 subject line 不是装饰是功能性部件。先对齐一个基础概念LLM 就是大语言模型是一种根据前文预测后续文字、帮你做文本生成的模型但它不是信息管理系统。它可以流畅地生成一段话不代表它能替你判断哪个标题最能代表这个文档。1.2 LLM 直接写标题时最常见的问题有四类空泛。这是最普遍的。让模型给周报写标题它通常给你本周工作回顾与总结这种话看起来没错但没有信息量。收件人看不到项目名、时间范围、关键产出等于没写。标题党。训练语料里点击率高的标题往往带有夸张成分模型学到的是听起来重要不是真实准确。你让它给技术文章起标题它可能给你一文搞定所有 RAG 问题这种说法你自己都不信。内容漂移。让模型先写正文再根据正文生成标题它总结的不是你的意图而是它自己生成的正文。如果正文在扩写过程中已经偏离了你的最初目标标题就会把这个偏离固化下来。正文越长漂移越明显。系统重复。批量场景里同一个模型同一批次给相似任务生成标题重复率非常高。这不是偶发是自回归模型在相近输入下的必然倾向。这四类问题几乎覆盖了我在邮件、文章、知识库、自动化项目里遇到的所有标题翻车场景。下面分析它们为什么必然出现。2. 为什么 LLM 天生写不好这个位置2.1 模型生成的是最流畅的句子不是最准确的标签自回归语言模型每生成一个 token选的是概率最高的下一个词。它擅长生产符合语言习惯的句子但这和准确代表这封邮件、这篇文章、这个条目的核心内容是两回事。标题生成本质是一个压缩任务把核心信息抽出来塞进一个很短的结构里。模型没有核心信息这个锚点它只有上下文里 token 之间的统计关联。所以你让它根据全文写个标题它并不是真的读完正文去判定重点它只是在做概率补全。模型能力强弱影响的只是补全的流畅度不影响它是否真的理解这篇内容对谁重要、在哪里检索、哪些关键词是命根子。2.2 优化目标错位流畅度换不来点击率和检索命中率邮件主题行的目标是让收件人在三秒内判断这是什么、和我有什么关系、我需要做什么。文章标题的目标是让目标读者确认这篇内容能解决我的问题。知识库条目的目标是让检索系统命中并让人在文件堆里一眼找到。这三个目标没有一个可以被语句流畅覆盖。尤其在知识库和 RAG 场景检索依赖关键词匹配和语义向量相似度。LLM 生成的意译式标题经常丢掉原文里的关键实体词比如产品名、版本号、报错代码。我自己维护过一个小型知识库前期偷懒用模型批量生成条目标题。结果检索 Spring AI 配置报错 时标题被意译成了Java 人工智能框架的集成问题向量召回勉强能中关键词字段全废。从那以后条目标题一律回到人工管理。2.3 上下文越长标题越容易被平均化直觉上给模型的上下文越多标题应该越准确。实际相反。当模型需要从很长的正文里提炼主题行时它会倾向选择一个最不具争议的平均结论把所有细节磨平。一篇文章如果既写了背景又写了踩坑过程还写了复现步骤模型给出的标题大概率是某某问题分析与解决方案这种万能句式。不是模型变笨而是长文本信息密度太高在短输出目标下模型做不了真正的取舍。它只能选择语义中心。你看到的结果就是标题越来越像模板填空。3. 正确分工LLM 出候选人做拍板系统做校验3.1 一套可复用的分工表我现在的固定思路是三层分工LLM 负责产出候选和扩展内容人负责最终确认程序或人工规则负责校验。具体到邮件、文章、知识库三种场景分工略有不同。场景可以交给 LLM建议保留给人工系统校验点邮件正文草稿、语气改写、要点归纳主题行最终确认是否包含收件人关注的项目名或动作词文章与博客提纲、正文草稿、小标题候选主标题和发布前复核标题与首段信息是否一致知识库与 RAG摘要、关键词 LLM写不好标题？人机分工协作是关键
Never let the LLM write the subject line 这句话是我最近整理 AI 写作工作流时越来越认同的一条原则。先给结论LLM 可以帮你写正文、列提纲、整理素材、生成多个候选标题但到了邮件主题行、文章标题、知识库条目标题这种最终拍板文案我基本不会让它直接定稿。不是 LLM 没有能力写标题而是标题承担的职责和正文完全不同。正文追求信息完整、逻辑清晰、表达流畅标题追求准确压缩、触发阅读、让人预期一致、被系统稳定检索。LLM 擅长前者在后者上其实并不占优。你让它随便想个标题它大概率给你一句放之四海而皆准的废话。这篇内容主要面向三类人用 LLM 辅助写邮件、写周报、写方案的重度用户做公众号、博客、产品文案的内容生产者以及正在搭知识库、RAG 检索链路或 Agent 自动化的开发者。核心思路只有一句话把生成权和确认权拆开模型负责出候选人负责拍板系统负责校验。下面按真实踩坑顺序拆开讲。1. 先搞清 subject line 到底在替谁工作1.1 邮件主题、文章标题、知识库条目标题本质是同一种东西很多人把标题当成正文的附属品写完正文再顺手让模型生成一个。但在真实系统里标题和主题行是独立的元信息它同时承担三层职责给人类判断、给系统判断、给流程判断。给人类判断收件人扫一眼邮件主题决定要不要打开读者扫一眼文章标题决定要不要点进来。这个判断发生在正文被阅读之前而且通常只有几秒钟。给系统判断邮件客户端、RSS 阅读器、知识库、RAG 检索流程都拿标题做排序、归档、召回的主要依据。系统在多数时候不看正文只看元数据。给流程判断在自动化流水线里标题经常直接变成文件名、数据库主键、日志标识。它一旦不稳定下游全部乱掉。所以 subject line 不是装饰是功能性部件。先对齐一个基础概念LLM 就是大语言模型是一种根据前文预测后续文字、帮你做文本生成的模型但它不是信息管理系统。它可以流畅地生成一段话不代表它能替你判断哪个标题最能代表这个文档。1.2 LLM 直接写标题时最常见的问题有四类空泛。这是最普遍的。让模型给周报写标题它通常给你本周工作回顾与总结这种话看起来没错但没有信息量。收件人看不到项目名、时间范围、关键产出等于没写。标题党。训练语料里点击率高的标题往往带有夸张成分模型学到的是听起来重要不是真实准确。你让它给技术文章起标题它可能给你一文搞定所有 RAG 问题这种说法你自己都不信。内容漂移。让模型先写正文再根据正文生成标题它总结的不是你的意图而是它自己生成的正文。如果正文在扩写过程中已经偏离了你的最初目标标题就会把这个偏离固化下来。正文越长漂移越明显。系统重复。批量场景里同一个模型同一批次给相似任务生成标题重复率非常高。这不是偶发是自回归模型在相近输入下的必然倾向。这四类问题几乎覆盖了我在邮件、文章、知识库、自动化项目里遇到的所有标题翻车场景。下面分析它们为什么必然出现。2. 为什么 LLM 天生写不好这个位置2.1 模型生成的是最流畅的句子不是最准确的标签自回归语言模型每生成一个 token选的是概率最高的下一个词。它擅长生产符合语言习惯的句子但这和准确代表这封邮件、这篇文章、这个条目的核心内容是两回事。标题生成本质是一个压缩任务把核心信息抽出来塞进一个很短的结构里。模型没有核心信息这个锚点它只有上下文里 token 之间的统计关联。所以你让它根据全文写个标题它并不是真的读完正文去判定重点它只是在做概率补全。模型能力强弱影响的只是补全的流畅度不影响它是否真的理解这篇内容对谁重要、在哪里检索、哪些关键词是命根子。2.2 优化目标错位流畅度换不来点击率和检索命中率邮件主题行的目标是让收件人在三秒内判断这是什么、和我有什么关系、我需要做什么。文章标题的目标是让目标读者确认这篇内容能解决我的问题。知识库条目的目标是让检索系统命中并让人在文件堆里一眼找到。这三个目标没有一个可以被语句流畅覆盖。尤其在知识库和 RAG 场景检索依赖关键词匹配和语义向量相似度。LLM 生成的意译式标题经常丢掉原文里的关键实体词比如产品名、版本号、报错代码。我自己维护过一个小型知识库前期偷懒用模型批量生成条目标题。结果检索 Spring AI 配置报错 时标题被意译成了Java 人工智能框架的集成问题向量召回勉强能中关键词字段全废。从那以后条目标题一律回到人工管理。2.3 上下文越长标题越容易被平均化直觉上给模型的上下文越多标题应该越准确。实际相反。当模型需要从很长的正文里提炼主题行时它会倾向选择一个最不具争议的平均结论把所有细节磨平。一篇文章如果既写了背景又写了踩坑过程还写了复现步骤模型给出的标题大概率是某某问题分析与解决方案这种万能句式。不是模型变笨而是长文本信息密度太高在短输出目标下模型做不了真正的取舍。它只能选择语义中心。你看到的结果就是标题越来越像模板填空。3. 正确分工LLM 出候选人做拍板系统做校验3.1 一套可复用的分工表我现在的固定思路是三层分工LLM 负责产出候选和扩展内容人负责最终确认程序或人工规则负责校验。具体到邮件、文章、知识库三种场景分工略有不同。场景可以交给 LLM建议保留给人工系统校验点邮件正文草稿、语气改写、要点归纳主题行最终确认是否包含收件人关注的项目名或动作词文章与博客提纲、正文草稿、小标题候选主标题和发布前复核标题与首段信息是否一致知识库与 RAG摘要、关键词