企业官网建设流程全解析

跑酷场景可以分别描述起跳位置、障碍、落点以及相机如何跟随。这样整理后，生成结果哪里偏离更容易说明，也方便下一轮只调整其中一个变量。

仓库里有什么

这份开源 H3 Max 案例合集目前收录 15 个公开账号的 30 个案例，分成 7 类，提供中英文说明。内容包括运镜与动作、角色表演、动画、短叙事、纪实氛围、参考连续性和制作流程。雨夜天台打斗、失重宇航员、黏土小剧场、角色展示，以及用 Blender 白模交代运镜，分别对应不同问题。分类的用途是帮助读者找任务，不是给模型或作者排一个热度榜。

为什么要区分三种条目

公开提示词改编，会链接作者原文；画面逆向推导，是根据可见效果提出一个可尝试的写法；工作流整理，则说明参考、预演、剪辑或关联端点之间的关系。同一个成片可能来自多种输入，还可能经过多次生成。仅凭视频不能恢复唯一的原始 prompt，所以不能把编辑补写的文字叫作作者原始配方，更不能拿作者的视频证明这段改写已经复现成功。

从原帖开始，保留证据

整理时先查公开 X 帖子，再找作者的回复，看看是否公开了 prompt、参考图和工作流。视频部分检查了抽样帧，用来描述可见的动作与构图；每例保留作者和原始出处。我们把作者明确披露的信息与编辑推导分开：没有披露的 seed、参考素材和剪辑步骤就保持未知，不为了让表格完整而编出参数。抽样看帧也不等于逐帧或音频验证。

关系、许可和未验证部分

这个仓库由我维护的 H3Max 项目维护。网站是商业项目，开源合集可以独立阅读下载，不需要注册网站。仓库原创贡献采用 MIT，第三方视频、缩略图和作者原文仍保留原有权利。首版没有做独立生成验证，展示的预览来自原作者。开源整理、作者署名、媒体使用权和复现证据是几件不同的事，都需要写清楚。

把效果词换成可检查的动作

以跑酷为例，可以分别写起点、障碍物、起跳、落点和相机路径。生成后就能具体判断：是落脚位置不对，还是镜头越过了人物？下一轮只改相关的一项，比同时换一堆形容词更容易理解变化。短片还需要给每个动作留时间，不能把很长的剧情塞进几秒。这是让试验更清楚的写作方法，仓库没有提供证明其成功率的对照实验。

模型和入口需要对上

H3、H3 Max 和关联端点不能混为一谈。看到一个使用多份参考素材或视频编辑的案例，不代表任意 H3 Max 入口都支持那套输入。仓库因此保留了模型边界说明。使用视频创作工作台尝试时，先核对选择的模型、输入方式与案例是否对应；除非明确来自作者披露，拆解里的参数只能当作建议起点，不能当作从视频里找回的事实。

怎样留下有用的试验记录

先选一个案例，准备它要求的输入素材，再记录模型或端点、时长、分辨率、画幅、prompt，以及可用时的 seed。生成前写好验收点，比如人物保持可辨认、道具没有换手、镜头到达预期终点。看完结果后挑一个主要偏差修改，保存失败结果和修改理由。这样下一次打开项目时，就能知道已经试过什么，而不是只剩一堆最好看的导出文件。

如何维护，而不是只堆一篇长文

案例存成 JSON，再生成独立页面和中英文 README。自动检查负责发现重复案例、缺失字段、本地引用错误和未同步的生成文件，不能判断视频是否真的复现。阅读时先看预览，再展开长提示词。站内另有网页提示词案例库，可以按网页方式浏览；它与 GitHub 合集的收录内容并不完全一致，不能把两边的结果混算。

下一步更需要什么

比起只增加条目数量，我们更想补齐复现记录：输入素材、模型设置、尝试次数、每次改了什么，以及是否做过后期。失败样本也有价值，它能说明哪些约束困难、哪些修改没起作用。欢迎补充原始 prompt、纠正署名，或者提交有输入与参数的对比结果；一句“这个提示词有效”，提供的信息远不如一次清楚的实验记录。