“帮我处理这个红杯”并没有唯一指定交付物。它可以指把照片中的杯子改成另一种颜色，写一个从图片里找出杯子的程序，也可以指提出把实物推到目标处的动作。这三种任务共享同一对象，却把成功放在不同地方。

图像任务要核对改色是否完成、背景是否保留；程序任务要看代码实际运行后能否找对对象；动作任务要看执行后杯子是否真的到达目标位置。模型能写出一段通顺的推杯步骤，只完成了提出计划这一层。计划里的“已到达”，不是环境里的到达证据。

为什么这些任务越来越容易从同一个入口提出？语言可以表达要求，图片与其他观测可以提供条件，输出又能是文字、代码或可交给后续系统的结构化结果。共享表示使同一底座有机会复用知识，而不是每次都从一张新标签表开始。基础模型强调这种复用范围，未必以生成内容为输出；用于表示或匹配的模型也可以成为多任务底座。但统一输入框只是接口形式，不足以证明下面所有任务都已经学会。

这条路线也不是仅靠“生成”两个字突然成立的。自监督让大量记录可以提供训练信号；数据规模与覆盖提供更多经验；表示学习让经验可复用；可扩展的网络架构和计算使大规模训练成为现实；开放的任务接口又让这些能力被更多应用调用。这些条件共同支持了变化。它们各自都有边界，更多参数或更多文本都不能单独保证任意任务成功。

“既然共用一个模型，评价为什么还要分开？” 因为评价应跟交付要求走。改图成功并不证明代码可执行；代码能通过测试，也不证明动作在真实桌面上安全有效。专用模型在某些固定任务上仍可能更准确、更省资源，共享底座的价值需要在具体使用中兑现。

类似的“在约束下构造候选”还会出现在分子、未来轨迹和研究方案里，生成因此不只服务图片与文字。应用越广，越要说清候选如何接受相应验证。下一页先追问共同前提：训练记录到底给了模型哪些经验，又漏掉了什么？