最近帮一个内容团队梳理技术方案对方把预算几乎全部压在调用大模型这一项上觉得只要选一个足够聪明的模型内容生成就解决了。我在他们那份方案旁边补了整整三页注释意图解析怎么做、生成结果谁来校验、用户反馈怎么回传、缓存和降级策略是什么。这其实就是AI原生应用和AI套壳应用之间的分界线。今天我想把AI原生应用里的内容生成这条链路掰开揉碎讲一遍从意图识别到内容交付中间每一步都有坑也有对应的工程解法。这篇文章适合正在设计内容生成类产品的人也适合想知道自己手上那个会写稿的App到底怎么工作的朋友。1. AI原生应用不是给App加个AI按钮先分清本质先说一个我观察到的现象很多人认为产品里能调用大模型接口、能吐出一段文字就等于AI原生了。这就像把发动机装进马车车厢然后宣称自己造了汽车——外观变了但底盘的逻辑还是马车的。技术的表象和系统的本质经常是两回事内容生成尤其如此。1.1 传统应用叠加AI为什么跑不通传统内容产品的典型架构是数据库存内容、业务逻辑管权限和流转、界面负责展示。AI加入之后最常见做法是在界面上加一个AI生成按钮用户点一下系统调一次API把模型返回的文本直接贴进编辑框。这种方案听着简单跑起来全是问题。第一是没有上下文记忆。用户上一轮说过偏好下一轮生成时完全被忽略。前一条内容里明确了不要用太官方的语气下一条生成时系统照样端端正正地用公文腔。第二是没有质量判断。模型输出的内容是好是坏系统完全不知道只能靠用户自己修改。第三是没有意图澄清。用户说写得再生动一点系统不知道生动在这个场景里具体指什么只能重新随机生成一遍。第四是没有反馈学习。同样的错误明天还会再犯因为没有任何回路把用户改了什么带回到生成策略里。传统应用把内容当作静止的资产存起来、展示出来。AI原生应用则把内容当作一个持续计算的过程输入意图经过多步计算产出内容再根据反馈修正后续计算。这个区别决定了你根本没法用传统三层架构去封装AI能力必须在系统里设计新的数据流和反馈回路而不是在原有架构上插一根API管道。1.2 AI原生应用真正改变的是什么对照我过去做过的几个项目AI原生应用有这么几个共性特征。它们看起来简单但每一条都对应具体的工程投入理解了它们你才能理解后面每一条技术链路为什么存在。第一接受模糊输入。用户不会按照你设计的表单填写需求他们会说帮我写一段发布到小红书的文案不要太正式突出性价比。系统要做的是从这句口语里解析出任务类型、平台、风格、价值点而不是反过来要求用户把每个字段填完。第二把生成能力当作主干流程。一次完整的内容生成在内部往往会被拆成多个节点先理解需求、再检索素材、再列大纲、再分块生成、再合并润色、最后校验输出。模型调用只是其中一个节点不是全部。第三显式设置能力边界。好的AI原生应用会明确告诉用户哪些能生成、哪些不能保证比如我无法保证引用来源真实这类提示。这跟传统应用尽量让用户觉得什么都能做的思路完全不同。能力边界看似是一种让步其实是信任来源。第四反馈闭环。每一次用户接受、修改或拒绝了生成内容都应该成为系统的学习信号。没有这个闭环系统上线三个月后就会因为业务数据和用户习惯的变化而逐渐失效。2. 从人话到合格内容的生成链路四个关键环节把一次内容生成拆开来看我习惯分成理解层、生成层、交付层和评估层。评估层会在后面专门讲反馈闭环这里先把前三层串起来说清楚。2.1 理解层把用户表达变成结构化任务用户说帮我写一段产品介绍要活泼一点面向年轻用户这句话里其实藏着四个信息维度内容类型是产品介绍语气风格是活泼目标受众是年轻用户隐含约束是篇幅有限、不能太官方。如果系统直接把这句话原样丢给模型结果好坏全看运气。我常用的做法是设计一个任务规范模板。模板里包含四块内容一是明确任务定义用一句话说明本次生成的目标二是给定输入schema列出可以使用的字段比如主题、目标受众、风格、字数范围、平台渠道三是给定输出schema规定模型必须返回哪些字段例如概述分段落推荐标签四是附带正反示例至少两组让模型知道合格输出和不合格输出分别长什么样。然后让模型做结构化输出。现在主流的做法是让模型直接输出JSON再在代码里做schema校验校验不通过就重新生成最多重试两次再不行就触发兜底流程。对于专业领域还要配合知识库检索也就是业界常说的RAG模式把检索到的相关片段拼进上下文让模型基于事实生成而不是纯粹凭印象发挥。这一步经常被低估但它决定了后面的生成质量上限。你在理解层漏掉一个约束生成层再怎么调提示词也补不回来这是我反复踩过坑之后才明白的。2.2 生成层多模型协作与流程编排对于短内容一次调用确实够用。但一旦要生成几千字的长文或者包含多个环节的脚本、方案、报告就必须做流程编排。编排不是花架子它带来的是实实在在的三个好处。一个典型的工作流长这样根据主题生成大纲等用户确认大纲之后再按大纲逐段生成最后统一润色、加小标题、生成摘要。拆开的第一个好处是可干预用户只看大纲就能纠正方向不用等到全文生成完才发现跑题。第二个好处是可校验每一段都能单独检测是否合格而不是最后整篇返工。第三个好处是可复用大纲、开场、结尾这些中间产物可以缓存下来下次生成类似内容时直接用省掉重复计算。在工作流里不同节点可以分配给不同模型。我的经验是草稿、摘要、短文案用速度快的模型长文润色、复杂推理用效果更强的模型。这种异构编排在成本上的优势非常明显后面算账的时候你就知道了。系统层面要定义好每个节点的输入输出契约支持重试和降级。比如某个节点失败一次可以先换一种提示词结构重试连续失败两次就跳到人工处理队列不要让用户干等。2.3 交付层校验、格式化与渠道适配生成层的输出不能直接面向用户。我们至少要做三件事硬校验、软评估、渲染适配。硬校验是指JSON字段是否完整、长度是否在约定范围内、有没有禁用的敏感词、引用的来源是否真实存在。软评估是指让模型做一次反思式回顾评价这条内容是否满足用户指令中的风格要求、是否与已确定信息冲突。渲染适配则是把同一个结构化内容对象渲染成不同渠道版本给公众号的版本要有小标题和段落分隔给短视频的版本要重写成口播稿给邮件的版本要补上称呼和落款。这一步里最容易翻车的是格式错误。我见过一个项目让模型生成带封面图的卡片文案模型在JSON里写了一个不存在的图片链接系统没有校验直接上线用户点开卡片看到的是破图。从那之后我坚持一条铁律凡是模型生成的内容必须经过schema校验和取值合法性校验宁可多渲染一步也不能信任模型的格式声明。3. 同样一个模型为什么你做出来是玩具别人做出来是产品这是很多团队最困惑的问题。明明用的是同一个基础模型别人家的生成结果就是稳定、可用、有风格自己这边却总是时好时坏。答案不在模型本身而在于模型周边的那套工程体系。3.1 提示词工程一套可管理的约束体系提示词不是写一段好听的话就完了。我把它拆成五层来管理角色定义告诉模型它的身份和输出边界任务描述说明要完成什么、不需要做什么输入结构规定用户数据的放法输出结构约定返回内容的格式示例库提供正例和反例。更重要的是提示词必须像代码一样管理。要有版本、要有评审、要能回滚。我团队里有一个提示词文件目录每个线上模板都有提交记录和负责人改动之前必须跑一遍评测集确认没有把质量改坏才能上线。没有版本管理的提示词本质上是碰运气开发今天调好了明天可能因为一句措辞变动就全乱了。还有采样参数的问题。温度高于0.7适合创意写作、头脑风暴低于0.3适合抽取事实、结构化输出。很多人一套参数跑到底当然会觉得效果飘忽不定。另外最大生成长度一定得设置否则模型会在你要求的结尾之后继续发挥白白浪费token还破坏内容结构。3.2 硬校验与软质量双保险机制内容质量不是一个笼统的概念而是多个维度的综合结果。我通常用一张表把它拆开来看维度要解决的问题我的校验方式完整性内容是否覆盖用户要求的要点规则检查字段齐全 模型对比要点清单一致性正文是否与开头结论矛盾模型自评 逻辑规则安全性是否有敏感内容、诱导性表述敏感词库 分类模型事实性数据、引用、来源是否可验证来源白名单 无法确认时明确提示硬校验负责不可能让步的底线。举个例子如果产品面向合规敏感场景生成的任何建议都必须附带建议咨询专业人士的提示这是底线不能被模型的一次随机发挥绕过去。软评估负责读起来是否对味这种偏主观的判断。比如风格是否足够活泼没有绝对标准可以让模型输出一个1到10分的自评分低于阈值就重新生成。我强烈建议不要在软评估上迷信单一模型。自评模型常常对自身输出更宽容最好用另一个独立模型来打分或者用规则抽取一些客观特征来辅助比如句子长度方差、口语词频、段落数。把主观判断拆成客观特征才能让质量体系可度量、可回归。3.3 反馈闭环让系统越用越顺系统上线后要把用户行为数据接回来。用户对生成结果做了什么直接采用、部分修改、放弃、重新生成这四类行为就是质量判断的一手信号。有了这些数据可以做三件事。第一定期抽样本做人工标注找出用户改了哪里、为什么改的共性形成失败模式清单。第二用失败样本改进提示词或微调模型。微调不是每次都需要但收集500到1000条高质量的偏好数据之后效果提升会很明显。第三把高频失败模式做成前置规则。比如发现用户经常把生成内容太冗长改成更简短就直接在理解层给模型加一个每段不超过两句话的硬约束。没有这个闭环系统就是一个不学习的静态工具。业务数据在变用户习惯在变热点话题在变呆在原地就等于倒退。4. 成本、延迟与规模化内容生成系统的三道坎原理讲完了真正的筛选才开始。一个内容生成系统能不能从Demo走向生产环境关键看它能否同时迈过成本、延迟和规模化这三道坎。4.1 先算一笔账钱花在哪里一个内容生成请求的钱不只是最后一次调用模型的钱而是整条链路里所有token消耗的总和。假设一次典型的写稿请求包含理解层一次调用输入300 token、输出150 token大纲生成一次调用输入600 token、输出200 token分块生成三次调用每次输入800 token、输出400 token润色一次调用输入700 token、输出500 token。加起来输入约3600 token输出约2050 token总共约5650 token。如果采用某商用接口并按常见计费单位估算一条内容生成成本可能在几分钱到几毛钱之间。听起来不贵但如果平台一天生成几十万条内容成本就变成了每天数万元级别。所以成本优化从来不是小数目的事必须在系统设计一开始就纳入考量。三个最有效的省钱手段。第一是压缩上下文只塞必要知识片段而不是把整个知识库都放进去。做一个检索模块把检索到的Top3片段拼接为上下文效果比硬塞全部资料好得多。第二是用小模型做简单节点摘要、关键词抽取这类任务不需要大模型用轻量模型就能达标。第三是设置输出长度上限输出token常常被低估一个max_tokens参数能避免模型跑偏喷水。4.2 缓存、队列与自适应降级内容生成的重复率比想象中高。在工作日节奏下用户会反复要求写周报写会议纪要写同类型文案。语义缓存的价值就在这里把用户输入向量化与历史输入做相似度匹配命中就直接返回历史结果完全不调用模型。在重复性强的场景下命中率带来的成本节省非常可观。还有一部分内容是非实时的比如每日自动生成的资讯摘要、批量生成的历史内容补全。这类请求放进任务队列安排在低峰期运行。队列还有一个额外好处当模型服务不稳定时队列可以把请求缓冲住等服务恢复后再处理而不是在用户端直接报错。自适应降级是更进一步的策略根据模型服务的实时响应时间和错误率动态决定这次请求由哪个模型、以什么复杂度来执行。服务稳定时走精确路径不稳定时切换到精简路径。这套机制让系统在高负载下也能保住基本可用性而不是整个产品一起雪崩。4.3 离线指标与在线观测质量是否真的OK不能靠感觉。我在项目里建了两套观测体系。离线指标是在固定的评测集上跑看完整性、一致性、安全性等自动评分偶尔抽一批做人工评分。离线指标的价值在于回归测试提示词改了会不会让质量变差一跑便知。在线指标是看用户的真实行为核心包括采纳率、放弃率、平均修改字数、再次生成次数。在线指标最真实因为它反映了真人的真实判断。另外要有生成质量看板每分钟请求数、平均延迟、平均成本、生成成功率、自评分数分布。出了线上问题靠这个看板定位是哪一层出了问题。我踩过一个坑上线初期只盯着离线指标觉得质量很好结果线上采纳率一直很低。后来发现是因为评测集里全是理想输入真实用户输入又短又含混理解层解析失败率很高。从那以后我坚持每隔一段时间就抽取线上真实输入回灌离线评测集让评测集保持现实感。5. 一次真实的短视频脚本生成模块复盘分享一个我实际做过的项目给某内容平台做的短视频脚本生成模块。想通过这个例子说明上面这些原则到底怎么落地以及落地过程中会遇到什么意外。5.1 场景定义先想清楚不做什么项目启动时业务方给的需求是帮作者写短视频脚本要写出爆款。我做的第一件事不是选模型而是缩小边界。只做脚本生成不做发布、不做数据预测只服务周更型作者不承诺保证爆款输入固定在五个字段主题、目标观众、时长、风格倾向、拍摄场景关键词输出固定在五个部分开场钩子、正文主线、结尾号召、拍摄提示、标题建议。边界清晰之后很多问题就简单了。比如要不要根据热点自动改脚本这种需求因为不在边界内可以果断拒绝。同时我们收集了人工整理的一百条优秀脚本做结构分析总结出开场钩子要在前三秒内建立冲突或疑问这类行业规律。这些规律后来写进了提示词和校验规则里比任何泛泛的生成脚本指令都管用。5.2 原型到上线的四个关键改造原型阶段我们直接让模型按自由文本输出整段脚本效果时好时坏。改成生产系统的过程中做了四个关键改造。第一输出结构规范化。规定模型必须按JSON返回五个字段任何字段缺失就判定失败。第二增加大纲确认环节。先生成脚本大纲用户认可后才生成完整脚本。上线后用户中途改方向的需求大幅减少用户体验反而更好。第三拍摄提示可执行化。要求每一条拍摄提示都能对应到具体镜头动作比如镜头将从作者正面切到产品特写而不是拍一些好看的镜头。第四两阶段评审。规则评审检查字段完整性和篇幅限制模型自评检查风格和冲突两个阶段都通过才允许输出。改造的工程结果是生成一次脚本的模型调用次数从1次变成2到4次成本上升了一些但采纳率提升非常明显整体收益远大于成本。5.3 上线后最容易翻车的三个地方项目上线后我们先后处理了三个之前没预料到的问题。第一个是超长输入。作者会直接复制一篇长文让改成脚本输入长度超出模型窗口。我们加了前置处理逻辑超长文本先做章节摘要再把摘要拼进上下文。问题解决后这类请求的生成成功率从70%升到95%以上。第二个是版权风险。有的作者上传的内容可能是搬运素材生成的脚本会继承原作的表达。我们在提示词里加入仅参考事实不得复制原文表达的要求并在规则层对输出做相似度抽检超过阈值就拒绝交付并提醒作者。第三个是内容同质化。同一个热门主题十个作者生成的脚本结构完全一样平台内容越来越像。我们用随机多样性参数解决了结构固定下的措辞多样性每次生成时会围绕同样的剧情逻辑换用不同的案例、说法和节奏。这三个问题现在回头看每一个都值得单独写一篇排查记录这里先留个引子。在这个项目里我最大的体会是AI原生应用的内容生成难的不是让模型说出话而是让系统稳定地说出对的话。模型是引擎系统才是车。把理解、编排、校验、反馈、成本这五件事做扎实一个内容生成产品才算真正立住了。