这几年我一直泡在AI应用开发这条线上从模型微调到RAG都折腾过一圈。前阵子有个朋友问我现在最该做什么方向的项目我脱口而出的一句话是我做这个项目时反复想明白的事情别再去做模型仓库了AI应用现在最缺的不是“更多模型入口”而是能让普通人把AI真正用起来的“创作表达平台”。所以我花了几个月时间自己从零做了一个这样的平台——它不追求收录多少模型而是把重点放在“帮人完成一次完整的表达”上。这个想法最开始并不被理解身边不少人劝我现有工具已经那么多做个新平台还有意义吗我坚持做下去的理由其实很简单市面上的AI工具要么停在“对话窗口”要么停在“模型列表”真正贴着创作者的表达场景设计的东西确实少。这篇文章就说说我为什么绕开模型仓库这个坑又是怎么把一个AI创作表达平台一步步落地的包括核心功能设计、实操实现以及踩过的那些比较典型的坑。1. 为什么不做模型仓库1.1 模型仓库赛道的问题模型仓库类的产品说白了就是把各种大模型的API集中到一个页面里用户进来选一个模型开个对话框提问拿结果走人。这种模式听起来很轻开发成本也不高但实际运营下来问题很明显用户在这类产品里几乎没有忠诚度可言。模型的能力差异不大入口体验也趋同用户今天用你明天看到另一个平台界面更顺眼就走了。我调研了市面上不少同类产品发现月留存能做到20%以上都算是很优秀的成绩了。更关键的问题是模型仓库解决的是“找到模型”的问题可普通人用AI真正面临的困难根本不是“模型不够多”而是“不知道拿这些模型干什么”。我自己身边就有不少内容创作者他们连ChatGPT、Claude、文心一言都装了好几个每一个都会用但真要写一篇完整文章的时候还是习惯自己闷头写。模型在那里摆着但创作的流程没有形成。缺的不是工具是一个能够承载完整创作流程的“工作台”。1.2 创作表达平台解决的真实问题我当时决定换个角度去做一个名为“AI创作表达平台”的东西核心思路不是“这里有120个模型你可以选”而是“你想写一篇小红书笔记我帮你把整个流程安排好”。用户不需要关心底层用的是哪个模型他只需要在这个平台里描述自己想要什么效果平台根据内容类型、风格需求、历史偏好自动帮他调用合适的模型组合把文字生成、配图建议、标题改写、排版整理这些动作串起来。这个方向的出发点是“表达场景”而不是“模型能力”。比如一个用户想写一篇招聘文案传统做法是打开某个大模型把需求打进去得到一段文字自己再复制到Word里排版再找图再调整。而在创作表达平台上用户只需要建一个“招聘文案项目”平台自动生成文案初稿、提炼几个标题方向、给出配图建议、顺便排好格式最后可以一键导出为完整文档。用户做的是决策和修改不是从零开始跟多个工具搏斗。1.3 平台定位与目标用户明确不做模型仓库之后整个平台的目标用户就非常清楚了。第一类是有稳定创作需求的个人创作者比如做自媒体的朋友、写公众号的、做短视频脚本的第二类是工作中经常要产出文档的职场用户比如产品经理、市场运营、行政人员第三类是小型团队需要一个轻量的AI内容协作工具但不想买那些昂贵的企业级套件。这几类用户的共同特点是有表达需求、有产出压力、但不愿意在“怎么调模型”这件事上花时间。他们想要的是“打开平台——描述需求——获得一个接近成品的内容——快速修改——交付”。所以我在设计平台的时候所有功能都围绕着“让表达过程更顺”来展开模型选择是后台的事情用户看到的只有场景化的工作台。2. 平台的核心功能拆解2.1 创作工作台从“选模型”到“做完一件事”平台第一版上线的时候我犯过一个错误把页面做成了模型选择器加一个聊天框结果用户反馈“这不就是个套壳聊天工具吗”。后来我把整个交互逻辑推翻改成“工作台”模式。用户进入平台后看到的是一个空白的创作项目而不是模型列表。他可以先创建项目填写项目类型文章、脚本、海报文案、周报等平台根据项目类型自动推荐相关功能组件。举个例子用户创建了一个“公众号文章”项目工作台左侧是选题建议区中间是正文编辑区右侧是AI操作面板。AI操作面板里不是一堆模型参数而是“提取核心观点”“换个开头”“生成三个标题”“检查错别字”这样的动作按钮。用户点一个按钮底层才去调用相应的模型。这种设计让用户感知到的是“平台在帮我干活”而不是“我在跟某个模型聊天”。2.2 表达编排器把模型输出串成一篇完整内容这是整个平台最核心的部分也是和普通聊天工具拉开差距的关键模块。所谓表达编排器抽象来看是一套节点系统每个节点可以是一个 AI 调用动作也可以是一段人工输入的素材节点之间可以串联、分支、合并。用户在一个项目里可以自由编排流程比如“先让AI生成大纲 → 我修改大纲 → AI根据修改后的大纲扩写正文 → 我再改一部分 → AI生成摘要和标题”。底层实现上我设计了一个简单的有向图数据模型节点之间用连线表示依赖关系。每个节点保存自己的输入、输出、使用的Prompt模板、调用的模型ID等。这个设计让平台天然支持“半自动”创作AI做AI擅长的事人做人该做的判断两边可以在一条流程里交替工作最后合成一份完整的交付物。2.3 素材库与提示词模板管理创作者在平台上积累下来的内容资产也值得被系统管理。所谓素材库不只是图片和文字还可以是之前用过的提示词、生成过的满意段落、收藏的文章结构。我花了很大力气做素材库的标签体系和搜索功能因为当素材积累到一定量之后如果找不到等于没有。提示词模板则是这个系统的隐性骨架。我针对不同场景写了很细的模板比如“小红书种草文”模板里会包含语气要求、段落结构、emoji使用建议、结尾引导等。这些模板内置在场景工作台里用户不会直接看到Prompt内容但生成的文字明显带着该场景的风格。这样既降低了用户的上手门槛也保证了输出质量的一致性。2.4 一键导出与发布表达平台必须解决“最后一公里”的交付问题。用户辛苦生成的内容如果只能停留在平台内部那就没有意义。所以我实现了比较完善的一键导出功能支持导出为Markdown、Word、图片长文等格式还接入了主流内容平台的发布接口用户整理好内容后可以直接在平台里填标题、选封面、设置发布时间一键发布。这个功能看似简单其实是整个平台最受欢迎的部分之一。因为在真实创作流程中“从生成到发布”往往要经历复制、粘贴、排版、传图等一系列琐碎动作一键导出把这些时间成本全部砍掉用户实测下来从打开平台到一篇公众号文章发布出去最快可以控制在二十分钟以内。3. 实操过程与关键实现3.1 技术选型与整体架构整个平台我选择的技术栈比较务实前端用Vue 3加Vite后端用Python的FastAPI数据库用的PostgreSQL缓存和异步任务用的Redis加Celery。为什么不用Node后端因为我要处理的文本生成任务涉及大量异步调用、流式处理和重试机制Python生态在这块的库更成熟FastAPI的原生异步特性也足够支撑流式输出。在架构上最核心的不是前端也不是数据库而是“模型网关”这一层。我把它做成一个独立的内部服务统一封装不同模型提供商的API差异。上游业务服务只跟网关打交道传一个标准化的输入结构网关负责把请求翻译成各个模型的格式发起调用解析返回结果再做统一的错误处理和重试。这样上层场景功能不用关心具体接入了哪些模型底层新模型接入时也不会影响业务代码。# 模型网关统一调用接口的简化示例 class ModelGateway: def generate(self, request: GenerationRequest) - GenerationResponse: provider self.get_provider(request.model_id) start time.time() for attempt in range(3): try: result provider.call( messagesrequest.messages, temperaturerequest.temperature, max_tokensrequest.max_tokens ) return GenerationResponse( contentresult.content, usageresult.usage, latency_msint((time.time() - start) * 1000) ) except ProviderTimeoutError: backoff 2 ** attempt time.sleep(backoff) raise ModelUnavailableError(request.model_id)自建网关的好处非常明显几个模型的接口我都真实对接过参数命名、返回格式、限流策略差异非常大。有些模型支持流式有些只支持一次性返回有些返回带usage统计有些压根不告诉你怎么算token。如果没有这层抽象上层业务代码会充满各种分支判断场景功能根本没法快速迭代。3.2 表达编排器上下文如何流动表达编排器的数据模型是平台最值得复用的部分。我设计了两张核心表一张存节点一张存连线。节点表记录节点类型、位置、输入、输出、关联的Prompt模板ID、使用的模型配置连线表记录边的关系和上下游节点ID。每一个创作项目就是一整份节点加连线的集合项目的状态由这些节点共同决定。运行的时候编排器从入口节点开始遍历图结构取前序节点的输出作为后序节点的输入形成上下文传递。这个过程我特意做成了“半自动”节点可以标记为“自动执行”或“等待人工确认”。人工确认节点不会自动调用AI而是把前序结果摆在用户面前用户编辑完再点击继续。这解决了AI内容生成中的一个大问题一旦某一步的输出跑偏后续所有内容都会跟着偏给人一个校正点可以大大降低整体返工率。{ project_id: proj_1024, nodes: [ {id: n1, type: prompt_runnable, action: generate_outline, model: gpt-x, inputs: [], auto: true}, {id: n2, type: human_review, action: edit_outline, inputs: [n1], auto: false}, {id: n3, type: prompt_runnable, action: expand_article, model: gpt-y, inputs: [n2], auto: true} ], links: [ {from: n1, to: n2}, {from: n2, to: n3} ] }我实测下来的体感是这个“人工确认点”的设计让整体生成质量上了一个台阶。纯自动跑全流程可能10次里有3次结果需要大幅修改加上人工确认点之后10次里有8次只需要微调用户的信任感会强很多。这个太重要了。3.3 提示词模板的工程化设计提示词模板是AI应用里最容易被人低估的部分但它实际决定了下限。我在平台里内置了一套模板管理机制每个模板由三部分组成角色设定、任务说明、输出格式约束。角色设定决定内容的口吻任务说明决定具体做什么输出格式约束决定返回内容的排版结构。三个部分都是用变量占位符来动态填充的。举一个实际模板例子某个公众号文章场景的模板角色设定是“你是一名资深公众号主编擅长把复杂的主题写得通俗易懂”任务说明是“根据用户提供的素材生成一篇包含引言、三个核心论点、结尾总结的公众号文章”输出格式约束是“标题不超过30个字使用二级标题分隔段落每段不超过200字”。用户在前端不用看到这些后台模板会根据素材自动填充。模板的管理后台也很关键。我让模板版本化每次修改都保留历史版本这样场景功能的A/B测试就有据可依。平台上线之后我持续优化模板每周都会根据用户的修改习惯调整模板里的约束语句比如发现用户经常把“结尾总结”部分删掉那模板里就把这一段的权重降低改成“结尾给出一个行动建议”。3.4 异步任务与超时处理长文本生成是平台中耗时最长的操作调用一个模型生成两三万字等待时间可能超过一分钟。如果前端一直等着同步返回体验会非常糟糕。我采用了项目制加异步任务的处理方式用户发起AI操作时后台马上返回一个任务ID前端立刻进入“生成中”状态后端通过WebSocket推送任务进度生成完成后通知前端自动拉取结果。超时处理也是踩坑重灾区。不同模型走完一个完整调用链的时间不一样最长的可能超过120秒普通的HTTP请求早该断了。我在网关层设置了动态超时策略根据输入文本长度和模型类型估算预期耗时超时上限设置为预估值的1.5倍加10秒如果真超时了不做静默失败而是返回部分结果并明确提示用户“链路超时内容不完整建议只对当前节点重试”。# 异步任务状态流转核心逻辑 class TaskManager: def submit(self, node_execution_request): task Task(statuspending, project_idrequest.project_id) chain celery.chain( collect_previous_outputs.s(request.node_id), call_model_gateway.s(request.model_id), save_node_output.s(request.node_id), notify_ws.s(request.project_id) ) chain.apply_async() return task.id我发现异步化改造之后用户对平台耐心度完全不一样了。之前同步等待时用户超过30秒就开始焦虑不安现在异步任务加进度提示即使耗时一分半用户也会接受只要能看到“正在生成第二个部分”这类进度变化。4. 常见问题与排查实录4.1 各家模型接口差异太大抽象层怎么取舍这是我在网关层最头疼的问题。不同模型商API的认证方式不同有的是HTTP Header带Key有的是请求体带签名返回结构更是五花八门有的返回choices字段有的返回replies字段还有的返回结构里套了两层data。如果追求所有模型都统一到同一个参数体系会发现根本做不出来总有些特殊参数是某家模型独有的。我的取舍原则是“求同存异”。网关定义了通用参数集包括模型ID、temperature、top_p、max_tokens、system_prompt、messages。每家模型接入时通过适配器把通用参数映射成各自的API格式映射不了的独有参数放在ext_param里透传。这样既保证90%的场景可以用统一代码跑又不会因为某家模型的特殊能力而放弃接入。4.2 生成结果和预期偏差大如何用“人工确认”兜底平台内测阶段用户反馈最多的问题就是“AI生成的东西和我想要的不太一样”常见情况包括语气太浮夸、结构太死板、写了太多车轱辘话。一开始我想靠改提示词解决反复调整模板后发现提示词能控制方向但没办法精准控制用户的个人审美。后来我在工作台里增加了一个“示例输入”功能用户可以先给一段自己写的文字或者贴一篇自己喜欢的文章系统会自动分析这段文字的语言风格生成风格特征描述再把这些描述混入后续所有Prompt中。这个功能上线后用户对生成结果的满意度明显提升。同时在编排流程里强制插入至少一个“人工确认点”相当于给用户一个纠偏机会而不是把整条结果一次性扔给用户。4.3 用户不理解“编排”概念怎么办要承认“编排”这个词对普通用户来说还是太技术化了。一开始我在界面上写“创建工作流”用户根本不知道是什么意思。后来我改成“从文案到发布一站式完成”用户就懂了。更进一步我把编排器隐藏起来用户在普通模式下看不到节点连线只看到“上一步”“下一步”的向导式流程。只有切到“进阶模式”才会看到节点编辑器。这个改动让我明白一个道理高级概念可以做进底层但用户界面一定要用他们能理解的表达方式。所谓编排对用户来说就是“先让AI生成大纲我看一眼再让AI写全文”平台只需要把这个过程包装成顺滑的步骤导航就够了。4.4 长文本生成超时甚至中断长文本生成中断的原因通常是模型提供商主动断连或者生成过程中网络持续不稳定。排查下来还有一类原因是输入提示词过长超出了模型的上下文窗口被模型直接拒绝。解决方式是前置检查网关在处理请求前先估算token使用量如果超出上限直接提示用户“素材过长了建议拆分后再生成”而不是等模型报错。另外我还在后端增加了断点续传的逻辑。当一个节点生成失败时不会让整个项目报废而是在节点上保留一个“重试”按钮用户可以单独重跑当前节点而不用从头执行整条流程。这个能力对使用编排器的高级用户特别重要会直接影响他们对平台稳定性的判断。5. 最后再分享一点实用体会做完这个AI创作表达平台之后我对“AI应用该怎么做”这件事有了更具体的判断。像模型仓库这类工具本质还是在“卖工具”用户用完就走而表达平台的核心是把用户包裹在一个完整场景里帮他从头到尾把一件事做完。这种产品逻辑听起来简单实现起来却需要在“AI能力”和“用户意图”之间搭一座非常细的桥提示词模板、节点编排、素材管理、导出发布处处都是细节。如果你也打算做类似方向的AI应用我的建议是先别急着写代码拿“表达场景”拆一拆你的目标用户。比如你身边最常写文案的那几个人他们每天重复的步骤是什么哪一步最难哪里最耗时把这些环节抽象成产品模块再思考底层应该用什么样的模型组合。这比先堆一堆模型列表再想怎么引流靠谱得多。还有一个我踩了几次坑才总结出来的小技巧Prompt模板一定要和版本管理绑定。很多AI项目早期迭代很快模板改一版就覆盖一版等发现效果倒退时想回滚都回不去。我在模板管理里加了版本对比功能每次修改前都能看到当前线上版本的生成效果示例避免凭感觉乱调。这个小改动帮我省下了大量反复验证的时间。平台做出来之后我陆续让一些写作量比较大的朋友试用他们的反馈让我确信这个方向是对的。一个写产品文案的朋友之前每天要花半天时间憋稿现在他用我的平台先把产品信息丢进去让AI生成三个方向的开头自己挑一个再让AI扩写改几轮半小时就交出一篇能直接用的初稿。做产品就是这样选对切入点其实比单纯比谁的功能多要重要得多。模型仓库那一波已经足够拥挤了真正贴近人的创作需求去设计表达平台反而是一条值得长期走的路。