有一次在内容生成系统里收到这样一条请求项目标题填的是“五岁时我就立刻被西班牙人剪了朋克头发当时我愁眉苦脸被送到了欧洲演戏Leon结果正当我与杀手里昂产生了感情时娜塔莉·波特曼将我替换了下来下半部由她主演”项目正文、关键词、摘要描述全是空的。如果直接让模型照着这句话写一篇技术博客结果大概率会是一篇关于电影人物关系的虚构文章而不是用户真正需要的内容。当然这里更大的问题可能是用户根本不是在提需求只是在测试系统边界。这个场景真正暴露的不是模型生成能力而是内容生成系统里很容易被忽视的一层意图识别和输入质量判断。一个只能按照提示词硬写的系统面对这种低质量、高歧义的输入时会陷入典型的“两难”不写用户会觉得系统不智能写了系统会把一个玩笑性质的文本当成事实依据接着往下编。我更倾向于把这类问题当作工程问题来处理而不是靠换一个更大的模型来解决。下文是我在这一类内容系统上摸爬滚打后的一个总结。核心判断很简单内容生成系统的竞争力不只是“能写出什么”还包括“知道哪些输入不该直接写”。后者往往决定系统在真实场景里可不可用。1. 为什么一段玩笑式输入会让内容系统陷入两难1.1 表面上是信息缺失实际上是意图信号混乱先把这个输入拆开看。它有实体、有故事、有转折甚至还牵扯到经典电影和真实演员。用户确实给了一点东西不是完全空白。但问题在于这整段文本被放在了“项目标题”这个字段里而真正描述项目用途的正文、关键词、摘要字段全是空的。这意味着内容系统接收到的不是一个明确指令更像是一段“没有被包装成需求”的叙述。系统需要在多个方向上猜测用户是想写一篇影评是想讨论演员替换背后的选角逻辑是想让模型基于这个玩笑续写故事还是单纯在测试系统会不会被带偏又或者只是用户不熟悉表单把标题栏当成了聊天输入框这些猜测之间差异很大生成出来的内容方向完全不同。如果系统不先做判断而是直接进入生成那么“写什么”就是一个随机结果。在真实业务里这种情况并不少见。很多用户不会按照结构化表单填字段他们会把一段不完整的话、一个截图、甚至一个情绪丢给系统然后期望系统自动补全成一篇可用内容。对产品设计者来说这就是一个典型的输入质量问题。所以表面问题是“项目正文为空”实质问题是“意图信号不可靠”。这两个问题要分开处理。1.2 强行生成会带来什么后果如果系统强行按照这段标题生成会出现一个很有意思的连锁反应。首先模型会因为标题里的“杀手里昂”“娜塔莉·波特曼”这些实体把它识别成一个和电影《这个杀手不太冷》相关的内容。然后它会顺着标题中“我被替换了下来”这种表述把一段明显不符合事实的玩笑内容当成“用户提供的事实背景”开始一本正经地论证换角、剧情、人物关系。这会产生两个问题。第一个问题是事实错误。模型不是直接说“我不知道你在说什么”而是会用训练数据里的电影常识去补全这段叙述生成出来的文字看起来逻辑通顺但整个立论基础就是错位的。比如它可能会把“五岁时被剪朋克头”“送到欧洲演戏”“与杀手里昂产生感情”这些虚构情节当成真实经历然后写出一篇第一人称的奇幻故事。用户如果只是测试系统可能会觉得好笑但如果用户真的把这个输出当成参考就会被误导。第二个问题是质量反馈失真。很多团队会用“生成结果是否流畅”来评估系统能力却忽略了流畅背后的事实偏离。这种“流畅的错误”比“明显的失败”更难追溯。因为问题不是出在写作环节而是出在最开始的任务接收环节。等到发现输出不对时用户已经流失了。我见过不少团队把精力放在优化提示词、调整模型参数、增加内容模板上却跳过了“先判断这个输入能不能支撑一篇长文”这一步。方向一旦错了后续再精细的优化都是在地基上装修。2. 拆解一次从无意义输入到可用文章的处理流程2.1 先用输入质量检查把请求分成四类要解决这个问题第一步不是改造模型而是在模型前面加一个输入质量检查层。它的职责不是生成内容而是给请求打标签。我在实际项目里会把输入请求分成四类每一类对应不同的处理策略。类型输入示例信息完整度意图清晰度处理策略明确任务有标题、有正文、有关键词、有摘要高高直接进入生成流程信息缺失只有标题没有正文和关键词中中先补全或澄清信息污染标题和正文互相矛盾或关键词与内容无关中低抽取可信信息再确认任务不匹配一段电影玩笑被当作技术任务提交低低拒识或转为闲聊回复上面那个玩笑输入更接近“任务不匹配”同时兼有“信息缺失”。因为它被放在标题字段里但没有说明到底要写什么类型的文章。判断成“任务不匹配”之后就不应该直接进入长文生成而应该走澄清流程。这个分类不一定非要靠大模型。规则、分类模型、人工判断都可以参与。重要的是先有一个明确的分桶逻辑而不是把一切都丢给生成模型。2.2 当数据不完整时应该补全而不是硬编一旦系统把请求标记为“信息缺失”常见做法就是尝试补全。补全不是让模型瞎猜而是先从已有文本里提取可用的实体和线索。比如从这段标题里可以提取出“西班牙人”“朋克头发”“欧洲演戏”“Leon”“杀手里昂”“娜塔莉·波特曼”等实体。系统可以判断出这是一个和经典电影相关的文本但依然无法判断用户到底想要“影评”“故事续写”还是“技术文章”。这时候有两种做法。一种是继续硬编让模型根据已有信息生成一篇“看起来合理”的文章。这种做法的优点是响应快缺点是风险高。因为用户没有给出真正的任务边界生成的每句话都是基于猜测最终结果大概率不是用户想要的。另一种做法是进入“补全态”让系统主动指出缺失的信息并引导用户补齐关键字段。比如返回一句“当前输入缺少文章类型和目标读者请补充后重试”或者给出几个可选项让用户点击。这种方法多了一次交互但能显著降低无效输出。我一般会优先选择后者。哪怕产品要求全自动化也可以在输出中明确标注“这是基于有限信息的任务拆解不是最终文章”把不确定性显性化。这比假装自己什么都知道要安全得多。2.3 规则、模型、人工如何分层兜底在真实系统里输入判断通常不是单层逻辑而是三层配合。规则层最便宜也最稳定。它可以做这些事检查必填字段是否为空。检查标题和正文是否互相重复。检查标题里是否出现异常符号、URL、脚本标记。检查文本长度是否明显过短或过长。这些检查不需要模型参与几行代码就能完成。它挡不住语义问题但能挡掉大量明显异常的请求。模型层负责语义理解。比如用分类模型判断意图用实体识别提取关键信息用主题分类判断内容方向。这一层能处理规则层看不出来的歧义但它也有不确定性。所以需要设置置信度阈值低于阈值就进入人工或澄清流程。人工层解决的是模糊地带。系统可以把低置信度的请求推送给人审也可以提供可视化界面让人快速标记。人工不是用来处理所有请求的而是用来校准机器判断的。通过人工标记的结果再反哺规则和模型。三层各司其职才能既控制成本又控制风险。只靠任何一层都容易出问题。3. 内容生成系统落地时真正需要的四块拼图3.1 意图识别别把聊天当真需求设计意图识别时目标不是把字面内容理解得多深而是判断“用户到底想要系统执行什么动作”。是写文章是问答是摘要是聊天是测试还是其他意图标签集合可以设计成一组有限的选项而不是开放式的。比如写文章问答摘要改写聊天测试其他对每个输入模型给出一个意图标签和置信度。置信度高于阈值就按对应流程处理低于阈值就进入澄清。上面那个玩笑输入更可能落在“测试”“聊天”或“其他”上而不是“写文章”。如果系统错误地把它识别成“写文章”后面再好的生成配置都会放大这个错误。这里还有一个需要特别注意的点系统要防止输入内容试图绕开设定把模型带到闲聊模式。这不是鼓励做攻击性讨论而是工程上要考虑输入文本可能通过某些措辞诱导模型偏离任务。意图识别层本身就要承担一部分防诱导责任。3.2 知识边界控制知道什么该答、什么不该答内容生成模型有一个天然问题用户提供的输入并不等于可验证事实。尤其当输入里真假混合时模型很容易把用户单方面陈述当成背景知识。所以知识边界控制非常重要。我的常用做法是在提示词里明确区分“用户输入中给出的假设”和“系统可信知识”。如果输入涉及真实人物、作品、时间线且与常见常识冲突生成器不能顺着用户说法往下编而应该标注“无法确认”或“信息与常见知识不一致”。但提示词约束只是缓解。更可靠的方式是引入外部资料库或检索增强生成用可验证材料约束输出。对于没有素材支撑的任务不要强行生成“确定性内容”。这个玩笑输入最大的问题就是它建立在虚幻剧情上同时又混入了真实演员和真实电影。如果不做知识边界控制模型很容易把虚构和现实混成一团。做了边界控制后系统至少可以回一句“你的描述更像一个虚构故事是否要我基于这个设定续写而不是当成事实来介绍”这样既保持了可读性又避免了事实错误。3.3 输出流程约束从跑通到稳定很多人以为内容生成就是“输入提示词输出成品”。但在工程落地时我强烈建议把“一次生成终稿”改成“分两阶段生成”。第一阶段先生成任务理解。包括用户可能想要什么主题。内容边界是什么。需要补充哪些素材。打算采用什么结构。第二阶段等用户确认后再生成完整正文。这样做会增加一次交互成本但能显著减少“写得漂亮却完全跑题”的情况。尤其面对低置信度输入先让系统说自己“理解了什么”比直接输出洋洋洒洒几千字要稳妥得多。参数方面如果输入置信度偏低可以降低 temperature 或 top_p让输出更保守。很多模型接口允许按请求动态调整这些参数不需要全局固定。低置信度输入用保守参数高置信度输入可以适当放开这样效果更可控。另外输出后处理也不能省。校验关键词是否出现、长度是否正常、有没有重复段落、有没有以“在当今时代”这类空泛套话开头。这些机械检查不能提升上限但能兜住下限。3.4 人工介入与反馈闭环内容系统不是只要上线就能自动进化。如果没有反馈闭环它的判断能力会一直停留在上线那天。常见问题是系统只记录了成功生成和用户点击数据忽略了“低置信度输入被退回”和“用户后续自己修改标题重新提交”的记录。实际上这些被退回或被修改的样本才是优化判断能力最值钱的数据。可以把用户修改后的成功请求作为正样本把用户完全不满意或直接流失的请求作为负样本定期更新分类规则和提示词。比如做一次周度的样本复盘抽看那些低置信度输入看是规则层漏掉了还是模型分类错了还是人工误判了。长期下来系统对“什么输入能写、什么输入不能写”会越来越清楚。这不是某个模型参数自动解决的而是工程流程持续迭代的结果。4. 在真实业务里怎么设计最小可用拒识流程4.1 一个五步判断框架如果你也要做类似的内容系统可以参考下面这个五步判断框架。它不需要一开始就做得很重但能把模糊输入挡在生成之前。步骤判断项判断方式如果通过1字段完整性规则检查必填字段进入下一步2意图清晰度模型分类 置信度高置信度才继续3主题相关性是否落在允许生成的主题范围不在则拒识4可验证素材是否有可引用资料或明确素材不足则澄清5生成策略自动生成 / 大纲 / 澄清 / 拒识选择对应出口用这个框架处理那段玩笑输入流程会是第一步字段就不完整因为正文、关键词、摘要为空第二步意图清晰度偏低因为看不出用户要写文章还是闲聊第三步主题相关性无法判断第四步素材不足。最终结果就是进入澄清或拒识而不是硬生成一篇长文。这个框架的好处是每一层都有明确出口不会把所有压力都压到生成模型上。坏处是需要维护规则和模型标签体系初期会有一点成本。但相比生成一堆无效内容带来的信任损失这个成本值得。4.2 没有足够输入时宁可澄清也不要强行生成很多产品会担心“拒绝用户”会降低体验所以宁可强行生成也不澄清。但从用户视角看收到一篇完全跑题的长文比收到一句“信息不足”更让人失望。澄清话术不需要复杂可以直接说当前提供的信息不足以判断你需要的文章类型。请补充目标类型、核心主题或参考素材。如果产品必须保留自动生成能力也可以输出一个“基于有限信息的任务拆解”而不是最终成品。比如先把主题、大纲、素材缺口列出来让用户确认后再进入完整生成。这样系统既没有拒绝用户也没有假装自己无所不知。还有一个原则不要把用户输入里的错误设定直接当成事实写进文章。系统可以指出“你的描述与常见信息不一致”但不要开始论证哪个版本正确。守住这一点内容系统才不会变成谣言放大器。4.3 长期维护日志、评估和迭代内容系统的拒识能力不是一次开发就结束的它需要持续维护。日志至少应该包含这些字段输入原文字段状态哪个字段缺失分类标签置信度分数实际输出类型用户后续反馈有了日志之后可以统计几个关键指标自动生成率、澄清率、拒识率、无效输出率。理想状态不是澄清率越高越好而是无效输出率越来越低。今天被澄清的请求经过边界判断后是否合理今天被拒识的请求是否真的是误伤。复盘方式可以很简单每周从低置信度输入里随机抽 50 条人工看一遍。如果发现模型总是把“电影玩笑”识别成“影评需求”就在分类层加几条同类示例或调整阈值。如果发现规则层把某些正常的简短标题误伤成“信息缺失”就放宽规则。经过几轮迭代这个流程会越来越贴合真实业务。到那时系统不是“更会写”而是“更知道什么时候不该写”。4.4 适用边界哪些系统能自动做哪些不能最后说一个边界问题。五步拒识流程适合垂直内容工具、企业知识库、低风险科普内容这类场景因为这些场景的输入类型相对固定误判成本可控。但在医疗、法律、金融、新闻等高风险领域情况完全不同。这类场景即使有再强的拒识能力也不能完全去掉人工审核。系统的职责不是直接判断“能不能写”而是把材料整理好提供给人类专家做最终判断。换句话说内容生成系统不能替人做所有决定。它真正擅长的是把“模糊的、低质量的、高风险的输入”挡在生成之前减少无效劳动的浪费。至于那些确实需要深度判断的内容它应该学会说“我不知道”或“我需要更多信息”。回到开头那个例子。如果你也遇到有人拿一段真假混合的玩笑输入来测试系统最合理的做法不是逼模型写出一篇漂亮的文章而是先确认这是一个真实任务还是一个边界测试内容生成系统的真正能力不是把任何输入都变成文章而是知道什么时候该写、什么时候该问、什么时候该停下来。