这篇内容想聊的其实是我最近一年做产品时的一次方向转变。一开始我和团队想做一个偏底层的模型仓库把市面上的开源模型、推理接口统一封装起来做成一个类似能力中转站的东西。结果做了一半我们发现方向有问题把模型堆在一起并不能解决用户真正的问题。于是我们把项目砍掉重来改成了一个面向最终用户的 AI 创作表达平台。这次转型最大的变化不是换了个界面而是彻底换了思考方式。我们不再纠结某一款模型的榜单分数而开始纠结一句话应该怎么被生成、一段故事应该怎么被延展、一篇文案应该怎么被改写成不同的语气。这篇文章会把我们决策的来龙去脉、架构拆分、技术取舍以及踩过的坑都写出来给那些在做能力和做产品之间犹豫的人一个参考。1. 技术出发点和产品验证仓库很正常表达才有价值1.1 我为什么最初想做模型仓库这个想法的起点特别朴素。当时团队内部有不少算法同事日常会接触到各类开源模型和推理方案跑评测、调参数、比效果是家常便饭。时间久了我们发现自己手里有一堆能力碎片有的擅长文本续写有的擅长总结归纳有的在特定风格上表现出色。于是很自然想到把这些能力收拢到一个统一入口里对外提供调用接口做成一个模型搬运工。当时我设想的仓库有三个功能板块。其一是模型管理收录不同类型模型统一封装成标准接口让上层应用不需要关心底层差异。其二是体验对比在网页上放几个对话框让用户直接感受不同模型输出的差别。其三是面向开发者提供调用样例和文档方便他们接入自己的系统。听起来很合理对吧模型仓库的价值在业界已经被验证过很多次统一抽象、统一鉴权、统一计费这种模式本身没有硬伤。但问题出在用户是谁这一环。如果我们服务的是B端开发者他们关心的是模型能力边界、响应速度、价格成本仓库确实能满足。可我们没有稳定的B端客户池却想像做开发工具一样去自然获客现实很快给了我们一个冷冰冰的答案没人愿意为了调用接口而长期停留在一个没有业务场景的平台上。这个阶段大概持续了一个多月。技术上是跑通的统一封装、并发处理、按次计费这些都能实现但产品上完全立不住。我们统计后台发现接入方主要是来试用高并发时段几乎没有留存率非常低。我逐渐意识到模型本身不是产品模型解决的问题才是。1.2 实测反馈给了一记实锤用户要的不是接口是结果为了不让自己闭门造车我们找了几位种子用户做访谈其中有一位是做公众号内容的同学她的一句话让我印象特别深我不在乎你用的是哪个模型我在乎的是丢给我一个主题能不能帮我写出能直接用的段落。这句话我们消化了很久。她需要的不是模型切换器不是一个能对比效果的技术玩具而是创作表达这个连贯的过程给她主题帮她搭框架帮她写初稿再帮她改成不同风格。她甚至不关心平台有没有最强模型的标签她只关心拿到的文字是否靠谱、修改几轮后能不能快速变化。后来我又去观察了几个目标用户发现有类似的需求共性。有人在写小红书文案需要把一段产品介绍改写成轻松种草的语气有人需要把长篇报告压成几段摘要再从中提炼出金句还有人要做短视频脚本需要把大纲延展成带节奏感的口播文本。这些场景背后其实都是同一个诉求借助AI完成从想法到表达的转换。而模型仓库的产品形态天然解决不了这件事——它只会把一堆原始能力摆在你面前让用户自己挑、自己调、自己拼。1.3 关于AI创作表达平台的定位修正于是在第二个月我们决定把重心从仓库挪到表达。我用一句白话给团队定方向我们不卖模型我们卖让人把话说好、把想法变成作品的体验。这个定位听起来有点虚但落到产品上有几个具体要求。首先平台要以场景为入口不是以模型为入口。用户进来看到的是写文案写故事写总结写脚本这些任务而不是一列模型名称。其次每个场景背后都有一整套预设的提示词模板、参数策略和输出格式规范用户不需要会写提示词只需要描述自己的需求。最后生成结果不能是一次性的平台要支持二次改写、语气切换、扩写缩写在同一个流程中持续进行。这样调整之后产品形态就完全不一样了。底层当然还是模型但模型不再是界面上的主语而是后台悄悄工作的引擎。用户在前台做的是表达感受到的是内容质量而不是技术在炫技。2. 从模型聚合到表达引擎核心架构的取舍2.1 分层设计底座能力、编排中枢、体验外壳重新架构的时候我参考了自己以前做中间件的经验把平台拆成三层。最底层叫底座能力层。这一层负责连接各推理服务和开源模型部署屏蔽协议差异提供统一的调用入口。具体来说它处理鉴权、重试、超时、结果解析这些基础操作暴露给上层的是一套极简接口大致是传入文本参数和模型标识返回生成结果。这一层不关心业务只关心能不能稳定地调用能力。中间层叫编排中枢是整个平台的大脑。我们在这个层里实现提示词模板管理、变量注入、多步生成流程、模型路由这些逻辑。用户在前台点击一次生成中枢会把任务解析成一步或者多步模型操作比如先生成框架再逐段填充内容最后统一润色每一步都可以使用不同模型或者不同参数。这一层改变了我们看待模型的方式每个模型变成工作流里的一个节点而不是一个独立的服务终端。最上层叫体验外壳也就是用户直接看到的界面和交互。我们会针对文案、故事、总结等高频场景做专门的编辑器编辑器里嵌入了多个功能按钮改写、缩写、扩写、变风格、随机换一种说法。每个按钮后续都对应一条预定好的处理路径而用户感知到的就是一个能越用越顺手的创作工具。2.2 把模型封装成可插拔能力槽在设计中间层时我给自己定了一个原则绝不让业务代码直接绑定某个具体的模型输出。理由是模型更新换代的频率太高了今天觉得好用的模型三个月后可能就被更好的替代。如果业务代码里到处散落着某模型专用的逻辑后期会非常痛苦。所以我们引入了能力槽的概念。一个能力槽定义了一项抽象的生成能力比如中文创意写作长文本总结语气改写。每个能力槽下面可以挂多个模型实现并带有一个评分权重。系统在调用时会按照权重选择候选模型也可以根据预设规则切换比如主走某模型当它响应超时或者结果质量不达标时自动路由到备选模型。这样做有一个额外的好处不同能力槽可以组合使用不同模型。有些模型在总结上又快又稳但在创意续写上容易跑偏有些模型适合写故事但在执行严格的格式要求时经常不听话。把它们拆到不同能力槽里再按任务类型路由整体质量就会比重度依赖单一模型高不少。这也是我们后来敢对用户承诺多轮改写效果稳定的底气来源。2.3 创作工作流模板、变量与多步编排表达平台和普通AI问答最大的区别在于它需要处理多步创作。举一个非常常见的场景用户写一个短视频脚本。如果只是让模型直接生成通常出来的内容会比较空因为需求不够具体。我们的做法是把脚本创作拆成三步第一步让模型根据用户提供的主题生成3个不同的脚本切入点第二步从切入点里选一个生成分镜结构包括场景、画面、台词、时长第三步把所有内容整合成完整脚本并加上开头钩子和结尾引导。在技术上每一步都是一个独立的工作流节点节点之间通过变量串联。我们把用户输入、上一步输出存到上下文字段里下一步的模型调用会把上下文和新的指令一起打包。整体像一条流水线前半段输出直接成为后半段输入。模板部分我们也花了不少功夫。起初模板只是一段提示词文本后来我们给它加了参数声明、示例输出、约束条件。比如模板里可以声明输出必须是4段每段不超过50字这一步解决了大模型容易啰嗦的问题。模板还支持条件分支比如当用户勾选需要口播提示就会额外注入一条节奏指令。总之模板不是字符串替换而是一套可配置的指令状态机这是平台和普通聊天封装拉开差距的关键。3. 表达平台的表达到底做了什么3.1 五种高频率表达能力拆解我把平台里使用频率最高的表达类操作归纳成五种这里列出来方便大家理解我们到底解决了什么问题扩写把一句简单的话展开成结构完整的段落或文章。难点是保留原意同时补充合理细节。缩写把长文本压缩到指定长度要求核心信息不丢表达更紧凑。改写保持意思不变但变化语气。比如从正式风格换成口语风格或者从客观陈述换成带情绪偏好的推荐。续写按已有内容延展故事、论述或文案要求风格连贯没有明显断裂感。结构化重组把零散内容重新组织成有逻辑层次的输出比如从几个点子生成带小标题的目录。这五种操作单独拿出来都很简单但组合在一起就会产生神奇的连锁反应。一个用户刚开始只是想要一段摘要接着想改口头一点然后又想拆成三条朋友圈文案再做一条长文。平台的价值不是某一项功能很强而是这些功能在同一个上下文里可以反复叠加使用让表达不断逼近用户心里想的样子。3.2 用一份指令配置理解提示词工程的产品化有经验的开发者可能会问这些东西不就是提示词封装吗我承认它本质上确实依赖提示词工程但工程化的方式很不一样。我放一份简化过的配置示例大家感受一下scene: summary name: 长文摘要 input: - 原文 - 目标长度: 200 params: model_ability: long_text_summary temperature: 0.3 max_tokens: 400 prompt: system: | 你是一名擅长信息压缩的编辑助手。 你的任务是把用户提供的原文压缩成以“核心观点关键论据可引用金句”为结构的摘要。 不要添加原文中不存在的信息不要保留冗余修饰语。 user: | 原文内容如下 {原文} 请输出约{目标长度}字的摘要。 output_format: type: structured fields: - 一句话结论 - 核心观点列表 - 可引用金句 post_process: - enforce_max_length - avoid_repeat_words这里每一行都不是随便写的。temperature故意调低是为了让摘要任务更稳定、更少跑偏output_format声明结构化输出方便前端直接渲染成带小标题的摘要卡片post_process里还挂了一个去重复词的后处理这是我们在大量生成结果里发现的常见问题模型特别喜欢高频重复某些连接词比如首先其次值得注意的是不加后处理用户体验会差很多。产品化提示词的关键在于把技巧沉淀成可复用的配置而不是让每次请求都现场写一段自由发挥的指令。这也意味着普通用户不需要理解任何模型逻辑就能获得带约束、带格式、带后处理的高质量结果。3.3 评分、迭代与回流让成本花在刀刃上模型调用是要花真金白银的尤其是创意类表达一次多步生成可能连续调用多次模型接口。如果不加控制一个重度用户一天就可能消耗几十次调用成本很快就失控了。我们的做法是给每个生成结果增加质量评分。评分一部分来自自动规则比如结果长度是否符合预期、是否包含禁用词、是否有重复段落一部分来自用户反馈比如用户是否在生成结果上直接修改修改后是否再次生成是否点了感觉不错。两端信号合在一起给每条生成链路形成一条质量档案。质量档案最大的用处是调整模型路由权重。比如某个模型在短视频脚本场景下历史评分一直偏低系统就会自动降低它的选中概率把钱花在更可靠的能力槽上。我们还用这类数据反向优化提示词模板高分的结果会被抽取出来作为示例做小样本参考模型在后续生成时会照葫芦画瓢。相当于平台越用越懂用户喜欢的表达习惯。4. 面对真实流量前必须改造的四个环节4.1 多模型兜底和速率隔离模型依赖是舞台平台上最大的不稳定因素。我们遇到过某个推理接口高峰期响应变得极慢也遇到过线上模型突然返回乱码。一开始我们的系统很简单调用失败就直接提示用户稍后再试结果被用户骂惨了他们正在兴头上写小说突然断掉整个思路都塌了。后来我们做了一个兜底机制。每个能力槽至少配置两个模型并且在调用时设置了两级熔断第一级是响应时间超过设定秒数就立即切换备选模型第二级是内容合法性返回结果如果被安全层拦截也会触发切换到备用模型重试。这个机制看似简单却极大地提高了稳定感知。另外我们做了用户级的速率隔离。不同套餐档位拆分到不同的并发池里免费的体验用户不管多活跃也不能挤占付费用户的高并发通道。这个设计一方面是对付费用户的负责另一方面也避免免费用户因为大量调用导致整个平台成本攀高。4.2 成本分账与用户配额设计AI产品的成本结构与传统SaaS完全不一样。传统SaaS的边际成本近乎为零而AI平台每一次请求都在烧钱。如果不做精细的成本分账你就永远不知道哪个场景在赚钱、哪个场景在亏钱。我们为每个场景、每个用户都打上了成本标签。后台有一条严格的分账逻辑一次请求经过多少次模型调用、每次调用用了什么能力槽、消耗了多少输入输出token、落在哪个用户账户上都会记录在计费统计表里。月末复盘时团队直接打开报表看场景ROI很快发现有些场景虽然调用次数多但模型成本低、用户付费率高比如标题灵感生成有些场景看起来高大上但因为要多次调用长文本模型成本高且用户留存一般比如长篇故事续写。基于这个数据我们调整了用户配额策略。免费用户每天能够使用的调用次数按标准点计算不同操作消耗点数弹性变化。普通改写操作消耗1点多步脚本生成可能消耗3点。这样既保护平台成本也引导用户优先尝试我们想推广的核心能力。4.3 内容安全过滤器的位置内容安全在创作类平台里是绕不开的课题。我们的过滤器不是挂在模型前面做一次输入检查而是分为前向和后置两层。前向检查过滤明显不合规的输入后置检查在模型输出后执行保证平台返回给用户的内容同样干净。后置过滤有个容易被忽略的坑一些可以正常传播的内容在特定提示组合下可能会生成出负面结果。所以我们还加了一条规则如果生成结果多次触发后置拦截系统会自动沉默降级——不再提告用户因为安全问题拦截而是尝试换一种表达方式重新生成或者让用户修改输入。这样既守住了底线也不破坏创作体验。4.4 观测与日志不是排错用是优化表达用很多技术团队做日志是为了排查线上故障但我们从第一天起就用另一套思路。我们把每次生成请求的完整链路都记录下来包括用户的原始输入、中间变量、每一步模型输出、用户最终采纳的结果。这些数据拼接起来就是一本表达偏好实录。举个例子我们曾经发现某个场景里用户平均要生成3.7次才满意。顺手打开日志一看问题出在第一步预设的模板没有问清楚用户的目标受众导致模型生成的内容方向总是偏。我们随即在模板里加了一个受众描述字段结果生成次数降到了2.1次用户的满意度指标也明显提升。这个优化思路不是为了修bug而是为了让表达更加贴近用户预期只有数据到位了这种优化才能持续做下去。5. 我劝你也别先搭仓库除非你真的需要5.1 仓库本身的边界和适用场景我并不是说模型仓库一无是处它确实是一种合理的平台形态只是有它的适用边界。如果你服务的对象是开发者他们需要的是稳定、便宜的AI调用接口那仓库模式没有问题如果你要做的形态是为内部多个业务线统一供能仓库模式也可以帮助收敛技术复杂度。但如果你是做面向普通用户的产品我建议冷静评估一下。普通用户不会因为你集成了十款模型而觉得高级他们只会因为一次流畅的创作体验而记住你。仓库是能力的供给侧思维表达平台是需求的消费侧思维。两者并没有优劣但站的位置完全不同。我还想补充一个判断标准如果用户离开你的平台损失的是一堆能力入口说明你做的是仓库如果他们离开时觉得自己失去了一个称手的创作工具那你做的才是一个有黏性的表达平台。能力是可替换的创作习惯则很难替代。5.2 平台每次请求背后的非模型成本很多人在估算AI产品时只看模型调用成本这是一个巨大的误解。平台落地的过程中非模型成本同样不低。模板和指令需要人工设计一次高质量提示词的调优可能要反复测试几十次结构化输出的后处理需要写专门的解析器和校验器安全审查和前向过滤需要开发和维护规则日志回流和质量评分也需要建立数据管道。这些工作表面上看不直接产生生成内容但没有它们生成内容就是一堆不可控的半成品。我们在内部做过一次粗略统计产品正式上线之前真正花在大模型推理上的费用其实占比不高反而是数据标注、提示词调试、质量评估花费了大量的人力成本。尤其是评测为了让每个能力槽的效果可量化我们建立了一套标准的评测集覆盖了各类典型场景。每次优化模板或者更换模型都在同一套评测集上跑分否则根本分不清是感觉好了还是真的好了。5.3 表达平台启动时的最小闭环如果让我重新做一遍并且资源更紧张我会选择先砍到最小闭环。第一步只做四个场景改写、扩写、缩写、风格切换。这四个场景流程最短用户需求明确成本也相对可控。第二步绑定一个可靠且成本偏低的基础模型能力槽先不考虑多模型路由把稳定性跑起来。第三步做好质量和成本双观测通过用户反馈持续迭代模板。在这个闭环里真正花心思的地方是模板质量和交互细节。模板要保证四种操作输出风格稳定交互要在一键生成和多轮调整之间保持顺滑。等这个闭环跑稳了再逐步扩展新场景、接入更多模型、上线复杂多步工作流。慢慢来反而快。6. 复盘和当前状态6.1 好决策和遗憾之处复盘这一年我觉得做得最对的决定是主动把模型仓库这个执念放下了。当时团队已经写了将近一半的基础代码推倒重来的代价不可谓不大。但那个决定让我们及时停止了错误方向上的资源投入换来了一个更贴合用户的产品。如果当时不够果断我们很可能现在还在给一堆模型能力做运营疲于奔命又看不到增长曲线。遗憾的地方也有。一是我们没有更早介入用户访谈最初的模型仓库方案如果经历更充分的验证周期可能根本不会启动二是平台的提示词模板体系设计得偏重导致新场景的配置成本比较高后期我们花了大力气做简化三是没有第一时间给用户提供从生成结果反向修改输入的能力很多用户希望基于结果继续调整触发条件这个需求是上线之后被用户多次反馈我们才补上的。6.2 下一步方向和个人建议眼下平台已经稳定服务了数千名活跃用户我们对下一步的规划集中在两个方向。一个是把单次生成延伸到更长的创作流程中比如支持用户在多章节、多段落之间持续编辑和批量生成让平台真正成为一个完整的创作工作室另一个是继续完善质量反馈闭环把用户对每段内容的态度变成可学习的信号让表达系统越用越贴合每个人独特的语气和偏好。如果你也在做类似的AI产品我最想分享的一条建议是先想清楚你的用户完成的是任务还是表达。任务目标清晰可以做仓库做工具表达则关乎风格、情感、节奏需要平台本身具备表达能力。别急着堆模型列表先去倾听用户那句我想要的感觉到底是什么意思。把这句话听懂产品才不会跑偏。