我们怎么决定接入一个模型

为什么不首发接入

模型厂商发布会的样片，是从成千上万条生成里挑出来的最好的那条——这没什么可指责的，所有行业的宣传片都这么做。但创作者要的不是模型的最好状态，是它的平均状态和最差状态：跑一个三十镜头的项目，决定成片质量的是最差的那三个镜头。

所以我们的规矩是：没测过的模型不进正式工作流。片场租一颗镜头都要先拍测试片看边缘画质，生成模型决定的是你整部片子的成色，凭什么发布当天就敢往正式项目里放。「首发接入」在营销上很好看，但翻车的成本是创作者付的——这个账我们替用户算。

三项测试：拿真实的活儿去压

共测不是跑分。跑分测的是模型在标准题上的表现，我们测的是它在你的项目里会怎么表现。三个维度，全部用真实创作任务：

• 一致性：拿同一套角色定妆照（正面、侧面、45 度），连续生成十个不同景别和角度的镜头，数几个镜头里角色还是同一张脸。这是连续创作的生死线——单张惊艳但十张十个样的模型，只能进灵感探索，进不了生产。
• 指令跟随：写一条包含明确空间关系和多主体属性绑定的提示词（「穿黑色制服的少年在画面左侧，穿白色连衣裙的少女在前景背对镜头」），看它执行了几成。再测动作容量：10 秒塞两个连续动作，会不会丢一个。
• 可控性：只改提示词里的一个变量（运镜从「推镜」改成「环绕」），其他不动，看画面是不是只有这一处变了。可控性差的模型，每次修改都是重新抽卡，改十次等于生成十次全新的。

参与共测的是资深创作者，不是我们自己——工具团队测模型有盲区，我们太知道怎么「顺着模型写」了，而创作者会按自己的习惯写，那才是模型上线后要面对的真实输入。

通过之后：先写方言档案，再接入

共测通过的模型也不会直接出现在界面上。下一步是把测试期攒下的经验写成这个模型的方言档案——我们内部叫提示词技能卡，每张卡五节：

• 调性：它吃什么句式。Seedance 吃叙事长句，写法像给摄影师念分镜；Nano Banana 官方明确拒绝关键词堆砌；Midjourney 系吃标签流。同一个需求，三种完全不同的写法。
• 字数甜区：比如 Seedance 官方建议中文不超过 500 字，超了它只抓重点丢细节——这类信息藏在各家文档的角落里，大多数人不知道。
• 否定处理：它有没有负向参数，没有的话「不要 XX」要怎么正向化改写。
• 硬约束：API 级的规则——参考图上限、模式互斥、引用语法。比如可灵 3O 引用素材必须显式写明用途，只给图不说用途是官方文档警告过的头号失败模式。
• 范例：用户的原始输入 → 按这个模型的方言改写后的理想输出，覆盖常见失败模式。

这套档案有两个用途：现在，它是我们提示词优化功能的底层知识；长远看，它是比模型本身更耐用的资产——模型半年换一代，但「怎么测一个模型、怎么记录它的方言」这套方法不过期。

「接入」意味着什么：动作，不是列表

最后一步才是接入，而且接入的形式和大多数平台不同：模型不是以名字挂在一个下拉列表里，而是被编排进创作动作——生成角色、生成画面、规划分镜、空间预演。你选择的是「给这个角色出一张侧面定妆照」，不是「用 XX 模型 v2.3」。

这么做有一个直接的好处：模型换代时你的项目不动。动作还是那个动作，底下的模型换了，方言档案换了，你的资产、流程和使用习惯原地保留。我们见过太多创作者的工作流跟着某个具体模型版本走，模型一停服，整套流程报废——把模型当基础设施是危险的，它是耗材。

也有测完没接的模型：单项能力惊艳，但一致性过不了线，或者 API 约束和工作流冲突。这些我们会持续跟进版本，什么时候过线什么时候接。列表长短从来不是我们的 KPI，创作者敢在正式项目里用，才是。

常见问题