Karpathy 的一条实测记录在 AI 圈流传得很快给模型一段《魔戒》原文直接产出一段中土世界风格的视觉画面任务完成后的账单大约是 10 美元。这条动态里的模型代号是 Opus 5很多人第一反应是“10 美元真便宜”但更值得拆解的其实是背后的工程链路小说文本如何变成结构化的场景数据场景数据又如何变成可复用的视觉提示词最终驱动图像或视频模型成像。本文不打算复述评测细节而是结合 Karpathy 提出的 LLM Wiki 范式把这条“文本到画面”的工作流拆开给出一套可以在本地跑通的最小方案并讨论成本、提示词组织、结果验证和生产落地的注意事项。1. 这次实测背后的技术主线从文本到镜头语言的自动化1.1 为什么文本生成视频不是“一段话 一个按钮”如果你只是把“请画一个中土世界的场景”丢给图像模型得到的通常是一张风格漂移、细节模糊的图片更不用说生成连贯的视频。真实项目里的文本到视频流程至少包含四个阶段文本解析、场景规划、视觉生成、结果校验。Karpathy 实测中的 Opus 5 之所以能“直出中土世界”并不是单一模型的魔法而是这些阶段被高效串了起来。第一阶段要理解小说段落里到底有什么时间、地点、人物、光线、天气、氛围、镜头暗示。一段托尔金的文字可能写“山脚下的巨大阴影正在逼近”LLM 需要把它拆成“黄昏、山脚、巨大阴影、逼近感”这样的结构化元素。第二阶段要做镜头规划决定视角、景别、运动方式。第三阶段是把这些规划翻译成视觉模型能理解的语言比如“广角镜头低机位夕阳逆光史诗感”。第四阶段是检查生成的画面是否符合原文描述不符合就重新生成。这个链路与传统的“提示词工程”完全不同。传统做法是人力反复修改一段 prompt直到模型输出满意。而 Karpathy 测试体现的是自动化管线让 LLM 负责分析和规划让视觉模型负责执行。这种分工的核心收益是可复现只要输入文本不变、结构化配置不变结果就相对可控。1.2 多阶段协作理解、规划、生成、检查这里可以把它看成一个多 Agent 协作系统即使不引入复杂的 Agent 框架也可以用简单的函数调用来实现。理解 Agent输入小说原文输出 JSON 格式的场景元素列表。规划 Agent根据场景元素和预先定义的视觉风格库输出分镜表和提示词块。生成 Agent调用图像或视频生成 API输出媒体文件。检查 Agent使用多模态模型对比原文与画面输出合规性评分或缺失项。Karpathy 实测里的 10 美元大概率就是这些阶段调用 API 的总费用。相比人工反复试 prompt 的时间成本10 美元换来的是一整套自动化能力。它真正验证的不是“某个模型会读小说”而是“文本到视觉的工程化管线已经可以低成本跑通”。2. LLM Wiki 范式把零散的 Prompt 和知识变成可复用的工程资产2.1 Karpathy 口中的 LLM Wiki 到底是什么在讨论工作流之前必须先理解热词里反复出现的“LLM Wiki”。这个说法的核心观点是LLM 项目积累的知识不应该散落在聊天记录、共享文档和一堆命名混乱的 prompt 文件里而应该像 Wiki 一样组织成有层级、可链接、可版本更新的知识库。Wiki 的典型特征是“页面 链接 目录”。LLM Wiki 借鉴了这种形式但内容不只是文字还包括提示词模板、结构化的 JSON Schema、示例输出、失败案例、模型行为记录。Karpathy 之所以提出这种范式是因为大模型项目越做越复杂后最大的瓶颈不是模型能力而是团队对“模型在什么输入下有什么表现”缺乏统一认知。每个人都在本地有自己的 prompt 实验但没有形成可持续迭代的知识资产。在实际项目里LLM Wiki 可以是一个 Git 仓库目录结构也许是这样llm-wiki/ ├── prompts/ │ ├── scene_extraction.md │ ├── camera_planning.md │ ├── visual_prompt_generation.md │ └── style_guide.md ├── schemas/ │ ├── scene_element.json │ └── shot_plan.json ├── examples/ │ ├── lotr_scene_good.json │ ├── lotr_scene_bad.json │ └── failure_cases.md ├── models/ │ ├── opus5_behavior.md │ └── video_model_notes.md └── README.md这种结构让每个提示词模板都有“页面”每个页面说明适用场景、输入输出、已知限制。最重要的是失败案例被记录下来后续开发不再重复踩坑。2.2 在文生视频工作流里Wiki 可以沉淀哪些内容针对“读《魔戒》生成中土世界”这个场景LLM Wiki 至少可以沉淀以下几类内容。第一场景元素抽取的提示词模板。LLM 如何稳定地输出时间、地点、人物、光影、镜头建议需要一个经过验证的 prompt。模板要写明输出 JSON 的结构并给出一个《魔戒》风格示例。第二视觉风格库。每个项目可能需要统一的美术风格比如“电影感、写实、史诗、低饱和度”。风格库以 Wiki 页面的形式维护每条风格包含描述、参考图 URL、适合的模型参数、历史生成效果评注。第三角色一致性卡片。生成多个镜头时甘道夫、弗罗多半身像不能被画成完全不同的两个人。Wiki 里需要保存每个核心角色的特征描述以及模型对该描述的表现记录。第四失败案例。比如“当原文出现多云天气时画面总是过曝”记录问题、原因定位、解决方式。这是普通 prompt 文档最难覆盖的也是 LLM Wiki 最有价值的地方。3. 环境准备与模型选型控制成本和可复现性3.1 文本模型选型为什么需要结构化输出这一条链路里文本模型承担“读小说”的职责。推荐选择支持函数调用或 JSON 输出的大语言模型。Claude Opus 系列、GPT-4o、DeepSeek 等都可以关键是它必须稳定输出你定义的 schema。结构化输出之所以重要是因为后续视觉生成工具只能消费结构化的参数。你需要从小说段落中提取一个 JSON比如{ scene_name: 魔戒再现, time_of_day: 黄昏, weather: 多云, location: 夏尔边境的丘陵, characters: [ { name: 弗罗多, appearance: 棕色卷发绿色斗篷, state: 紧张地眺望远方 } ], lighting: 暖金色逆光, atmosphere: 不安与宿命感, camera_suggestion: 低角度广角镜头缓慢前推 }如果模型输出的是自然语言你需要额外写解析逻辑如果直接输出 JSON就能立刻传给下一个模块。在测试中我会使用 Python OpenAI 兼容接口的方式通过response_format或者tools参数强制输出 JSON。3.2 视觉生成模型选型文生图、图生视频还是文生视频视觉生成侧有三种路线成本和质量差异很大路线优点缺点适用场景文生图速度快成本低模型成熟只有静态画面无运动分镜设计、概念图图生视频能保留角色和画面一致性需要先生成一张图流程更长从关键帧生成短视频文生视频从文本直接生成视频角色一致性、物理规律差快速预览适合脑暴Karpathy 实测里的“直出中土世界”更像是一条自动化流程的输出结果不一定是单个文生视频模型。很多项目实际采用“文生图 图生视频”的组合先由 LLM 生成关键帧描述再生成关键帧最后让视频模型把关键帧变成镜头。这样既控制了成本又避免了文生视频的随机性。3.3 成本预算10 美元到底花在哪里10 美元不是凭空估算的。以一次典型执行为例大致可以拆成项目次数单次成本小计文本模型调用抽取场景10.1 美元0.1 美元文本模型调用生成分镜 prompt30.2 美元0.6 美元图像生成关键帧30.5 美元1.5 美元视频生成关键帧到动态镜头32.6 美元7.8 美元质量检查多模态评分30.0 美元0.0 美元总计约 10 美元。这类估算受模型定价、生成分辨率、时长影响很大但比例是接近的视频生成占大头文本模型只占零头。这也解释了为什么工作流优化的重点应放在“减少无效视频生成”上而不是省文本模型那几美分。4. 搭建最小工作流让 Opus 5 读懂《魔戒》并画出中土世界4.1 项目结构为了便于复现我建议先搭一个最小的 Python 项目。目录可以这样组织lotr-visual/ ├── main.py ├── config.yaml ├── requirements.txt ├── prompts/ │ ├── extract_scene.txt │ └── make_visual_prompt.txt ├── schemas/ │ └── scene_element.json ├── data/ │ ├── input.txt │ └── lotr_style_wiki.md └── output/ └── frames/主要依赖是openai、pyyaml、requests。如果你使用的是国内可直连的模型服务接口兼容 OpenAI 的话也可以直接使用该 Python SDK。4.2 第一步从小说段落提取场景元素假设data/input.txt里放了一段《魔戒》原文他走在山脊上脚下是灰色岩石远处烽火正在点燃 浓烟卷向灰暗的天空。风从北方吹来带着远处的凉意。 山顶之上阿拉贡停下脚步凝视着东方的黑暗。下一步是调用文本模型让 Opus 5 或者同等模型输出 JSON。Python 代码可以这样写import openai import json import yaml with open(config.yaml, r) as f: config yaml.safe_load(f) client openai.OpenAI(api_keyconfig[api_key], base_urlconfig[base_url]) with open(prompts/extract_scene.txt, r) as f: system_prompt f.read() with open(data/input.txt, r) as f: novel_text f.read() response client.chat.completions.create( modelconfig[text_model], temperature0.2, response_format{type: json_object}, messages[ {role: system, content: system_prompt}, {role: user, content: novel_text} ] ) scene json.loads(response.choices[0].message.content) print(json.dumps(scene, ensure_asciiFalse, indent2))这里的关键点有两个。一是response_format强制 JSON避免后续解析失败。二是temperature0.2控制文本理解任务的随机性让输出更稳定。system_prompt里需要说明 JSON 的字段定义以及必须基于原文抽取不能脑补。4.3 第二步基于 Wiki 模板生成视觉 Prompt拿到结构化的场景 JSON 后还需要结合风格库生成视觉模型能理解的 prompt。视觉模型通常更吃“描述性语言”而不是 JSON。所以要做一次翻译。在prompts/make_visual_prompt.txt中可以设计这样的模板你是一名资深电影分镜师。根据以下场景信息生成一个视觉模型使用的提示词。 场景信息 {scene_json} 风格参考 {loki_wiki_content} 要求 1. 提示词用英文或中文包含主体、环境、光线、构图、镜头运动。 2. 使用风格参考中的美术风格词。 3. 只输出提示词不要解释。代码调用如下with open(prompts/make_visual_prompt.txt, r) as f: prompt_template f.read() with open(data/lotr_style_wiki.md, r) as f: style_content f.read() user_content prompt_template.format( scene_jsonjson.dumps(scene, ensure_asciiFalse), lotr_wiki_contentstyle_content ) response client.chat.completions.create( modelconfig[text_model], temperature0.5, messages[ {role: system, content: 你是专业的分镜师。}, {role: user, content: user_content} ] ) visual_prompt response.choices[0].message.content print(visual_prompt)这个步骤是整个流程中最容易被人忽略的。因为原始小说语言是文学性的视觉模型理解不了“烽火点燃”“远方黑暗”的隐喻。经过 LLM 转写后视觉 prompt 会变成类似Cinematic wide shot, a lone ranger standing on a rocky ridge, watch fires burning in the distance, smoke swirling in dark grey sky, north wind rustling his cloak, low golden sunlight breaking through clouds, epic fantasy style, muted color palette, shallow depth of field, camera dolly in.这个 prompt 已经接近 Midjourney、Stable Diffusion 或视频模型能够处理的语言。4.4 第三步调用视觉模型生成图像或视频拿到视觉 prompt 后可以调用你选定的视觉生成 API。以文生图为例伪代码如下import requests image_response requests.post( config[image_api_url], headers{Authorization: fBearer {config[image_api_key]}}, json{ prompt: visual_prompt, size: 1280x720, style: cinematic, }, timeout60 ) image_url image_response.json()[data][0][url] print(生成图像:, image_url)如果使用图生视频服务还需要先保存这张图片然后把它作为输入传给视频模型。不同服务的接口差异很大但共同点是视觉 prompt 越具体越容易获得符合预期的结果。5. 运行验证与输出检查5.1 预期输出把整条流程跑通后你会得到三个关键产物结构化的场景 JSON视觉模型提示词一张或多张关键帧以及可选的短视频理想情况下关键帧应该能看出“山脊、烽火、阿拉贡、灰暗天空”这些原文元素。如果只是生成了一幅泛泛的史诗风景说明场景抽取或 prompt 转写丢失了信息。5.2 检查清单生成结果是否符合原文建议用以下清单逐项打分检查项通过标准示例主体人物出现阿拉贡且有“凝视东方”的动作是环境元素山脊、灰色岩石、烽火是光线氛围灰暗天空、北方冷风感部分镜头感远景镜头人物位于画面三分之一处是风格统一色调偏冷史诗感符合 wiki 风格库是如果某项不通过优先回到“视觉 prompt 转写”这一步补充缺失的描述词而不是随机重生成。注意验证时不要只看画面“美不美”要逐项对比原文。AI 生成结果漂亮但丢失关键信息在生产上仍然是无用结果。6. 常见问题排查6.1 LLM 返回的 JSON 经常解析失败现象json.loads抛异常或者输出的 JSON 字段缺失。原因模型输出可能带 Markdown 代码块标记或者字段名与 schema 不完全一致。检查方式打印原始content内容确认是否有json包裹。用json.loads(content.strip().removeprefix(json).removesuffix())做兼容处理。解决方案在 system prompt 中强调“只输出纯 JSON不要 Markdown”同时使用response_format{type: json_object}。如果仍失败增加一次重试并把上一次失败输出作为反例注入 prompt。6.2 视觉生成结果角色不一致现象生成阿拉贡第一帧和第二帧时面容、发型、服装差距很大。原因视觉模型本身没有跨帧记忆每次 prompt 只能依赖文字描述。解决方案把角色一致性特征写入 Wiki并在视觉 prompt 中固定重复关键特征词。例如“阿拉贡深色长发、灰色旅行斗篷、络腮胡、手持精灵长剑”。如果使用图生视频先用同一张角色正面图作为参考帧可以大幅提升一致性。6.3 成本超出预算现象跑了 5 个分镜账单接近 50 美元。原因视频生成按秒计费单次生成 5 秒视频可能需要 2~5 美元如果反复重试成本会指数上升。解决方案先使用文生图确认分镜质量再上升到视频生成。同时设置 API 调用上限和超时时间避免失控。代码里可以加入简单预算控制total_cost 0 max_cost 10.0 if total_cost estimate_cost max_cost: print(预算不足停止生成) break6.4 API 限流和超时现象调用视觉模型时报 429 或 ReadTimeout。原因短时间请求过多或生成的视频耗时过长导致 HTTP 连接超时。解决方案增加退避重试import time for retry in range(3): try: res requests.post(..., timeout120) break except requests.exceptions.Timeout: print(f超时第 {retry 1} 次重试) time.sleep(5 * (retry 1))生产环境建议使用异步任务队列而不是在 Web 请求里直接同步调用视频生成 API。7. 最佳实践用 LLM Wiki 管理整个生成链路7.1 设计提示词模板提示词模板不要只保存在代码里要把它们放到prompts目录里并为每个模板写清楚版本、用途、输入输出示例。这样当模型行为变化时你能够快速定位是模板问题还是模型问题。推荐在模板头部用注释写元信息# prompt: extract_scene # version: 1.2 # 用途: 从小说原文中提取结构化场景元素 # 输出: JSON字段见 schema/scene_element.json # 已知限制: 对“双关语”和“隐藏情绪”支持一般7.2 维护角色一致性卡片在 Wiki 中为每个重要角色建立独立页面。页面内容包括角色特征、服装、道具、常见动作、历史生成失败记录。生成多个镜头时先读取这些页面把角色特征合并进视觉 prompt。# Aragorn - 外貌深色长发灰色眼睛面部有胡茬 - 服装深灰色旅行斗篷银黑色剑柄 - 标志性动作站立时手按剑柄凝视远方 - 语气用于文本模型坚定、克制、带一丝疲惫 - 生成记录 - 2025-01-10远景图成功人物太小 - 2025-01-11半身像风格偏现代需要降低面部皮肤光滑度7.3 记录失败案例每一个生成失败都是重要资产。建议在 Wiki 中维护一个“失败案例”页面格式如下## 失败案例阿拉贡面部崩坏 - 问题生成图像中人物五官扭曲 - 触发条件visual prompt 中未包含“脸部特写”限制且使用了高采样步数 - 原因模型对小尺寸人物面部特征表达较弱 - 解决在 prompt 中加入“close-up on face, detailed features”并固定一个角色参考图 - 验证复测通过花费 0.3 美元这样后续项目如果遇到类似问题可以直接搜索解决方案而不是重新踩坑。8. 扩展方向从单镜头到长片单镜头跑通之后下一步可以尝试多镜头叙事。把一个章节拆成多个场景每个场景生成一段短视频再拼接成完整的“小说预告片”。这个方向的核心挑战有两个一是跨场景的角色一致性二是镜头之间的转场逻辑。角色一致性可以通过“角色参考图 文本特征”解决转场逻辑则可以用 LLM 先输出分镜序列再根据镜头运动方向决定切点。另一个可以研究的方向是互动式 Wiki。当 LLM Wiki 内容足够多时可以让模型在生成前自动检索相关页面而不是把所有内容塞进上下文。比如只根据当前场景查询“光影描述”和“角色阿拉贡”页面减少 token 消耗也避免无关内容干扰。回到 Karpathy 的实测10 美元直出中土世界真正值得学习的不是那 10 美元而是它把“读文本、想镜头、做画面”这三个环节工程化的方法。如果你也想复现建议先从“一个静态段落生成一张关键帧”开始把每一步的输入输出对齐再逐步加入视频生成。过程中把每个有效和无效的尝试都记入 LLM Wiki这会成为你项目里比代码更值钱的资产。