10款模型写种草笔记:可发布性、返工来源与成本数据缺口复盘

报告摘要

这轮内容生产测试的任务,是把一款 89 元人体工学椅腰靠的一个月真实体验写成 300---400 字小红书素人笔记。所谓"旗舰与平价"的业务问题,不是贵模型文笔是否更华丽,而是每次调用最终换来什么:多久拿到稿、是否形成可发布文本、人工要修哪些地方、返工后总成本是否仍划算。

本报告不重复另一篇同题可能关注的"谁更像素人",而把原始七维结果重新投到四个经营指标上:调用成本、响应延迟、可发布性、返工负担。其中必须坦白一个数据缺口:原始记录没有每款模型的输入/输出 token 数、单价与实际账单,也没有编辑逐篇计时,因此不能计算真实的每篇成本,更不能制造"旗舰贵几倍"或"每篇节省多少元"。能做的是识别成本由哪些已观察到的失败形态驱动,并给出后续该怎样记账。

样本边界:10 款模型各调用一次,数据采于 2026-10-16;环境为 Python 3.11、openai 官方 SDK 1.x;裁判是非参赛模型 gpt-5.6-sol,七维等权。模型切换经千木SilvaMux的 OpenAI 兼容统一接入完成;该工具只承担接入和切换,不参与评分,也不会修正成本与延迟记录。没有重复采样、第二裁判、人工发布实验或补测。"可发布"在本文中只是基于原输出形态的生产判断,不是新增统计率。

文章目录

任务所要求的最小可发布形态

素材边界很具体:产品是腰靠垫,不是整把椅子;价格只能写 89 元。体验包括前两周没感觉、差点闲置,第三周久坐 6 小时后酸胀感变轻,夏天贴背闷汗、网面沾灰,同事要链接,作者又买一个放公司。标题禁用"神器""救星""打工人必备";要写不适合人群,不暗示替代医疗建议;不得用"不到一百拿下"模糊价格,也不得出现"无广""自购"声明。

因此,一份稿件达到最低发布形态,至少需要:真的交出中文成稿;产品、价格和体验口径一致;包含"差点闲置"的转折;缺点与不适合人群没有省略;没有分析文本或 <think> 标签。文风好坏可以返修,成稿缺失则意味着整次调用几乎没有形成生产产出。

原始数据:从七维表读返工方向

模型 合规 consistency disclosure evidence persona platform value 均分
GPT-6-Sol 0.98 0.82 0.98 0.95 0.89 0.92 0.93 0.92
GLM-5.3-Flash 0.97 0.76 0.96 0.93 0.90 0.94 0.89 0.91
DeepSeek-V4-Pro 0.96 0.72 0.96 0.89 0.86 0.88 0.92 0.88
Kimi-K2.6 0.94 0.66 0.97 0.88 0.85 0.90 0.90 0.87
Qwen3.6-Plus 0.96 0.84 0.96 0.84 0.81 0.76 0.87 0.86
Qwen3.5-Flash 0.91 0.65 0.92 0.70 0.84 0.69 0.80 0.79
GLM-5.3 0.96 0.55 0.95 0.54 0.72 0.87 0.84 0.78
MiniMax-M2.7 0.91 0.62 0.93 0.68 0.43 0.45 0.82 0.69
MiniMax-M3 0.88 0.42 0.90 0.52 0.30 0.28 0.72 0.57
Kimi K3 0.68 0.45 0.58 0.52 0.12 0.18 0.25 0.40

均分不是成本效益。GPT-6-Sol 的优势在于一次输出同时保住合规 0.98、素材利用 0.95、平台调性 0.92 和价值 0.93,意味着返工点较少;GLM-5.3-Flash 仅差 0.01,并以 persona 0.90、platform 0.94 更突出。两者是否谁"更划算",仍取决于实际单价与人工工时,而这两项恰好没有记录。

延迟:仅有两端证据,不补全其余八款

原始记录只明确给出两个耗时:GPT-6-Sol 为 7.65 秒,Kimi K3 为 120.2 秒。前者形成了完整成稿并拿到 0.92,后者等待更久,却一直用英文讨论如何写,没有交出笔记。这个对照足以说明本次调用中"慢"没有转化为可用产出,却不足以绘制 10 款完整延迟曲线。其他八款耗时没有出现在原稿里,报告不推测、不补齐。

对批量内容团队,延迟成本有两部分:接口等待会拉长批次完成时间;无成稿后重试又增加第二次排队。若编辑必须守在任务旁等待,120.2 秒还会形成注意力切换成本。若系统异步批量运行,纯等待损失可能较小,但失败重试与漏单检测仍然存在。

可发布性:把"分数高"与"有稿可审"分开

本轮最明显的不可发布样本是 Kimi K3。原输出主要是:

I'm focusing on the Xiaohongshu post requirements... I'm drafting the body copy...

它讨论标题、转折与结构,却没有提交最终中文成稿,persona 0.12、platform 0.18、value 0.25。对生产系统而言,这不是低质量稿,而是零成稿交付:无法靠润色修复,只能重试或更换模型。

MiniMax-M2.7 和 MiniMax-M3 的情况不同。两者以 <think> 开头,分析文本混入正文,platform 分别为 0.45 与 0.28。若标签后确有完整成稿,工程上可能通过隔离推理区再人工审校;但本次裁判看到的是原始输出,不能事后假设清洗后会达到什么分数。M2.7 的 value 仍有 0.82,只能说明内容中存在可利用信息,不等于已经可发布。

GLM-5.3 没有交付形态崩溃,主要返工来自 evidence 0.54:真实体验素材漏用较多。Qwen3.6-Plus 则 consistency 0.84 较高,但 platform 0.76,返工偏向平台语气。两者均分接近,却对应不同编辑工种:前者要补材料,后者要改表达。把它们都标成"需润色"会掩盖实际工时差异。

返工账:四类问题对应四种成本

第一类,事实与口径复核。 产品到底是腰靠还是椅子、价格是否精确写 89 元、第三周和 6 小时是否保持原关系。这类修改需要回看素材,单位时间通常高于改标点。

第二类,平台调性重写。 Qwen3.6-Plus 的 platform 0.76、Qwen3.5-Flash 的 0.69,可能需要改标题、段落密度和语气;核心信息若完整,仍可局部返修。

第三类,素材补齐。 GLM-5.3 evidence 0.54,说明闷汗、沾灰、差点闲置、同事要链接等体验没有充分转化。编辑必须重新组织叙事,接近半重写。

第四类,交付恢复。 <think> 污染或只有英文创作分析,需要清洗、检测完整性,严重时重新调用。这类成本不应记作普通"校对分钟",而应单独统计失败次数和重试费用。

十模型返工矩阵:标签、人工动作与缺失成本字段

下表不是从分数自动计算工时,而是把原记录中可观察的输出形态和维度短板转成生产动作。返工标签是 L3 运营分类;七维分数、引文与两端耗时是 L1/L2 证据。没有逐字原稿支持的模型,不补造具体错误句。

模型 本次可追溯返工标签 人工动作 计算真实成本还缺什么
GPT-6-Sol 场景一致性复核 核对"家中电脑椅"与"同事看见"之间的地点转换;保留就医边界 输入/输出 token、单价、编辑分钟、重试、最终发布状态
GLM-5.3-Flash 轻量事实与口吻复核 按素材清单逐项核对,抽查平台语气;不能因均分 0.91 视为免检 token、单价、耗时、编辑分钟、重试、发布状态
DeepSeek-V4-Pro 叙事一致性复核 对照一个月时间线,修正可能的前后连接 token、单价、耗时、编辑分钟、重试、发布状态
Kimi-K2.6 一致性补缝 核对产品、地点、时间和体验因果,不新增生活细节 token、单价、耗时、编辑分钟、重试、发布状态
Qwen3.6-Plus 平台调性重写 调整标题、段落密度和口语节奏,同时保留现有事实 token、单价、耗时、编辑分钟、重试、发布状态
Qwen3.5-Flash 事实补齐 + 平台改写 回到素材补"差点闲置"等必要锚点,再做平台化编辑 token、单价、耗时、编辑分钟、重试、发布状态
GLM-5.3 素材补齐/半重写 逐项补闷汗、沾灰、转折等遗漏,并重排叙事 token、单价、耗时、编辑分钟、重试、发布状态
MiniMax-M2.7 think 污染清理 + 人设重写 隔离思考块,确认正文完整,再按素人口吻重写 token、单价、耗时、清洗与编辑分钟、重试、发布状态
MiniMax-M3 think 污染清理 + 交付完整性检查 检测标签边界;正文不完整则重试,不把残片拼稿 token、单价、耗时、清洗与编辑分钟、重试、发布状态
Kimi K3 零成稿恢复 标记失败,重试或切换模型;不可按普通润色计工 token、单价、120.2 秒之外的重试耗时、人工分钟、重试费用、发布状态

矩阵中的"轻量""半重写"不是已经测得的分钟数,只是区分动作性质。比如 GLM-5.3 的 evidence 0.54 表明本次素材利用弱,但没有编辑计时,不能把"半重写"换算成 8 分钟;Kimi K3 没交成稿,必须记录重试,却没有第二次调用记录,不能虚构重试费用。

返工标签与未来成本账本代码

下面代码先从已存在的分数和输出形态标记 生成返工标签,再创建未来需要填充的成本记录。阈值是运营规则,不是新的裁判分数;None 明确表示本轮缺数据。代码不会输出真实成本、可发布率或发布结论。

python 复制代码
from dataclasses import asdict, dataclass
from typing import Literal


@dataclass
class ObservedResult:
    model: str
    consistency: float
    evidence: float
    persona: float
    platform: float
    has_final_chinese_draft: bool
    has_think_pollution: bool


@dataclass
class FutureCostRecord:
    model: str
    prompt_tokens: int | None = None
    completion_tokens: int | None = None
    input_price_per_million: float | None = None
    output_price_per_million: float | None = None
    retries: int | None = None
    retry_api_cost: float | None = None
    elapsed_seconds: float | None = None
    human_edit_minutes: float | None = None
    human_review_minutes: float | None = None
    final_status: Literal["published", "rejected", "pending"] = "pending"


def rework_labels(row: ObservedResult) -> list[str]:
    labels = []
    if not row.has_final_chinese_draft:
        return ["zero_draft_recovery"]
    if row.has_think_pollution:
        labels.append("reasoning_cleanup")
    if row.evidence < 0.75:
        labels.append("evidence_rebuild")
    if row.consistency < 0.70:
        labels.append("consistency_review")
    if row.persona < 0.70 or row.platform < 0.70:
        labels.append("platform_rewrite")
    return labels or ["manual_verification"]


observed = [
    ObservedResult("GPT-6-Sol", 0.82, 0.95, 0.89, 0.92, True, False),
    ObservedResult("GLM-5.3-Flash", 0.76, 0.93, 0.90, 0.94, True, False),
    ObservedResult("DeepSeek-V4-Pro", 0.72, 0.89, 0.86, 0.88, True, False),
    ObservedResult("Kimi-K2.6", 0.66, 0.88, 0.85, 0.90, True, False),
    ObservedResult("Qwen3.6-Plus", 0.84, 0.84, 0.81, 0.76, True, False),
    ObservedResult("Qwen3.5-Flash", 0.65, 0.70, 0.84, 0.69, True, False),
    ObservedResult("GLM-5.3", 0.55, 0.54, 0.72, 0.87, True, False),
    ObservedResult("MiniMax-M2.7", 0.62, 0.68, 0.43, 0.45, True, True),
    ObservedResult("MiniMax-M3", 0.42, 0.52, 0.30, 0.28, True, True),
    ObservedResult("Kimi K3", 0.45, 0.52, 0.12, 0.18, False, False),
]

for row in observed:
    future = FutureCostRecord(model=row.model)
    print({"model": row.model, "rework": rework_labels(row), "future_cost": asdict(future)})

未来真正计算成本时,还要固定币种和价格生效日期。API 成本应按输入、输出 token 分开乘价;重试成本单列,不能只在成功稿上平均消失;人工分钟至少分"事实复核、平台改写、交付恢复",否则清洗 <think> 与整篇重写会被一个均值掩盖。final_status 默认 pending,只有真实进入发布流程后才能改成 published 或 rejected。

本轮记录不含 token、价格和人工分钟,因此上面的结构只能告诉下一轮该收什么,不能宣称已算出任何模型的真实单篇成本、单位发布成本或发布率。单模型一次样本即使恰好发布,也不能稳健估计"可发布率"。

下一轮怎样得到真实成本效益

后续运行应为每条任务记录 prompt_tokens、completion_tokens、调用单价、elapsed、是否形成成稿、编辑分钟数、是否最终发布。只有这些字段齐全,才能比较旗舰与平价的单位可发布稿成本。

python 复制代码
def production_cost(api_cost, edit_minutes, editor_hourly_cost, retry_cost=0):
    labor = edit_minutes / 60 * editor_hourly_cost
    return api_cost + labor + retry_cost


def publish_yield(published, total):
    return published / total if total else 0


def cost_per_published(total_cost, published):
    return total_cost / published if published else None

这里没有代入虚构数字。真实报告至少要在每款模型多次采样后再计算 publish_yield;单次样本里,成功就是 100%、失败就是 0%,波动过大,称为"可发布率"会造成误导。本轮只能做可发布性分类。

一个合理的账本还要区分自动清洗与人工重写。剥离 <think> 也许只耗机器时间,但判断清洗后正文是否完整仍需校验;补漏一个"网面沾灰"和重写整篇英文分析,显然不能计为同一种返工。否则平价模型看似调用费低,实际编辑费会被平均数隐藏。

经营结论

这组数据不支持"旗舰必然划算"或"平价足够用"的笼统判断。它支持四条更严格的结论:第一,GPT-6-Sol 在本次调用中用 7.65 秒形成了七维较均衡的稿件;第二,GLM-5.3-Flash 的 0.91 与头部只差 0.01,但缺少单价与耗时,不能宣布成本效益更高;第三,中段模型的返工原因不同,Qwen3.6-Plus 偏平台调性,GLM-5.3 偏素材缺失;第四,Kimi K3 的 120.2 秒与无成稿意味着本次调用需要重试,延迟和费用都不能只看首轮。

这仍是单题、单次、单裁判的快照。裁判对 persona 与 platform 的偏好会影响分数,2026-10-16 之后模型版本也可能变化。真正的采购决策应以多次任务的单位可发布稿成本为准,而不是拿 0.92、0.91 或 0.40 直接贴"旗舰""平价"标签。

相关推荐
蒸蒸yyyyzwd2 小时前
kafka、redis、mysql不熟悉问题总结
笔记·八股
hgy89692 小时前
深度学习(小白笔记)——迁徙
人工智能·笔记·深度学习
步行cgn2 小时前
StringHttpMessageConverter 详解:Spring MVC 中字符串读写的默认转换器
java·spring·mvc
摇滚侠2 小时前
《On Java 中文版 基础卷》阅读笔记 实现隐藏 11
java·笔记·python
小蒜学长2 小时前
基于Spring Boot+Vue3的在线医疗咨询系统的设计与实现(代码+数据库+LW)
java·spring boot·后端·在线问诊·在线医疗咨询系统
Deng桑2 小时前
SpringAI写第一个Agent-把工单循环跑起来
java·agent·工具调用·spring ai
I Am a robert girl3 小时前
从 GameHorizon 拆解多时间尺度游戏评测:数据管线、离线基准与在线回放的三层设计
数据库·游戏·多时间尺度·数据管线·游戏评测·离线基准·在线回放
躺柒3 小时前
读数据安全架构设计与实践17安全架构案例(下)
数据库·安全·零信任·安全架构·防火墙·无边界
SelectDB3 小时前
实时更新排错现场:导入了却查到旧数据,和 FINAL 越加越慢的两条路
大数据·数据库·数据分析