很多人以为拿到 Happy Oyster access 之后，最难的部分就结束了。其实往往不是。真正的困惑通常发生在获批后的前五分钟：你终于进来了，但创建界面摆在面前时，新的问题立刻出现了。现在该选哪个模式？第一条 prompt 应该怎么写？为什么我明明有 access，却还是感觉自己不知道该从哪里开始？
我在 2026 年 4 月 21 日检查了 happyoyster.cn 当前可见的获批后创建界面。就现在这版 UI 来看，两个核心入口的正式标签是 Wandering 和 Directing。很多外部讨论会把它们简称成 Wander 和 Direct，但如果你是按当前产品界面来理解，最好先记住这两个原始标签，因为它们对应的不是两个“小功能”，而是两种完全不同的工作方式。
如果你还没拿到 access，建议先看 Happy Oyster 申请指南：怎样提高通过率并少走弯路。这篇文章默认你已经通过 waitlist 或拿到了邀请码，准备开始真正使用。
获批之后，第一步通常仍然不是“直接开始创作”
Happy Oyster 当前的 access 逻辑，并不像传统 SaaS 那样“审核通过后直接开后台”。从公开门槛来看，它明显更偏向邀请码式激活。也就是说，你拿到权限之后，最稳妥的方式仍然是回到官网 create 路径，用原来申请时使用的同一个 Google 账号登录，再根据提示输入邀请码或完成后续激活。
这一点看似繁琐，但能避免很多后续问题。最容易把事情弄复杂的做法，就是申请时用一个邮箱，真正使用时又换成另一个账号，然后开始怀疑是不是系统没有同步权限。就当前公开流程来说，尽量让申请账号、接收邀请码的账号、正式使用的账号保持一致，才是最省时间的做法。
等门槛真正打开之后，你会进入创建界面。很多新用户到这里会立刻犯第二个错误：把 Happy Oyster 当成一个“输入一句 AI 视频提示词，然后等结果”的普通工具。它当然也接受文本，但它真正希望你先做出的，不是内容风格选择，而是工作流选择。
创建界面真正要你决定的，是“探索世界”还是“导演场景”
当前创建界面把两个模式并列摆在最前面：
表面上看，这像是两个按钮；实际上，这更像是一次路线分叉。
Wandering 适合空间发现。也就是当你的核心任务不是“把某个镜头拍准”，而是先确认这个世界是否成立。你需要看环境是否有连续性，空间尺度是否读得清，场景是否真的像一个可被穿行的地方，而不是几个漂亮镜头拼出来的错觉。这时候先选 Wandering，效率通常更高。
Directing 则适合明确控制。当你已经知道自己要什么场景、什么动作、什么镜头关系，或者你要推动故事往某个方向发展时，Directing 更合适。它不是帮你“找到”世界，而是帮助你在已经成立的世界里“决定接下来发生什么”。
如果忽略这层区别，坏结果会来得很快。有人明明要做一个高度明确的 shot，却先用 Wandering，结果觉得画面太散；也有人世界还没站稳，就急着上 Directing，结果 prompt 越写越硬，最后看起来像是在强行给一个还没长出来的空间塞指令。
需要先判断空间是否成立时，先用 Wandering
Wandering 最适合那些本质上是空间问题的任务。你关心的是：这个地方作为一个“世界”是否站得住，而不是某个固定动作是不是马上发生。比如你在做游戏场景原型、概念空间探索、环境氛围验证，或者你只是想看一个 still idea 能不能变成一个可被穿行的 3D 场所，这些都更适合先用 Wandering。
这时候，prompt 的写法也应该像环境 brief，而不是像脚本分镜。一个好的 Wandering prompt，不会只写“一个很美的科幻世界”。更有用的写法通常会把地点、气氛和物理逻辑一起说清楚，例如：“一座悬崖边废弃天文观测站，下面是暴风雨海面，空间里有破碎玻璃走廊、冷色调青绿色灯光和持续强风，重点是作为一个可持续生成的地点被探索，而不是被剪成 montage。”
这种写法的价值，不在于词藻，而在于它给了模型一个稳定的“地方”。
当前创建界面里还能看到 Start frame、Third person 以及图片输入入口。这些控制项不是摆设。如果你已经有参考图，或者需要锁定一个更明确的起始构图，越早用这些信息去减少歧义，Wandering 的结果通常越稳。
当你已经知道镜头或叙事目标时，再切到 Directing
一旦你的问题从“这个世界长什么样、能不能被探索”变成“现在这段画面该怎么发生”，就应该转向 Directing。也就是说，你已经不再只是寻找环境，而是在一个已经逐渐成立的空间里安排动作、视角、节奏和结果。
这时候，prompt 也要从 mood 描述切换到 direction 描述。与其写“夜晚的赛博朋克小巷”，不如写得更像导演指令：“第三人称视角跟随一名快递员穿过狭窄霓虹小巷，镜头略高于肩部，保持稳定前移，湿地面反光持续可见，不要发生突兀场景切换。”
这种写法更有效，是因为它把注意力从“我喜欢什么风格”转移到了“这个镜头要怎么走”。对 Happy Oyster 来说，后者通常比前者更有帮助。尤其是在 Directing 模式里，稳定的镜头逻辑、锚点物体、运动路线和场景连续性，往往比堆很多形容词更重要。
如果你发现自己写出来的 prompt 全是风格堆叠，却没有一个明确动作关系，那多半还不算真正进入 Directing。
新用户最容易犯的错误，不是不会写，而是选错工作模式
第一次上手时，最常见的错误就是：拿错模式问错问题。第二常见的错误，是 prompt 太空，或者一次改太多变量，最后连自己也不知道结果到底是哪里出了问题。
常见模式大概有这些：
- 明明是一个需要强控制的场景，却先用 Wandering，结果误把“探索感”理解成“失控”。
- 世界本身还没稳定下来，就过早上 Directing，结果所有指令都像压在松动地基上。
- 风格、动作、机位、环境一起改，导致任何问题都没法单独诊断。
- 把第一轮结果当成最终交付，而不是当成判断哪一个变量需要修正的依据。
最后这一点尤其重要。第一轮生成最有价值的地方，通常不是“它已经够好了”，而是“它告诉你问题到底出在世界、镜头、动作，还是约束方式上”。如果空间成立但运动不对，就别把整个世界推翻；如果运动方向不错但环境太泛，就回去强化地点，而不是整段重写。
更稳妥的第一小时使用方式
真正高效的第一小时，通常不是一次性押注在一条万能 prompt 上，而是分成一个很短的连续流程。先用一轮 Wandering 去验证世界是否站得住；等空间开始成立，再转向 Directing 去推进你真正关心的镜头或叙事节点；最后只改一个变量，逐步收紧结果。
这样的节奏有两个好处。第一，它能避免你在世界还不稳时就急着导演细节。第二，它能更快告诉你 Happy Oyster 在你的实际工作流里究竟最适合承担哪一段任务。对游戏开发者来说，可能是先做环境探索，再做镜头测试；对 previs 团队来说，可能是先锁动作，再回过头补空间细节。关键不在于哪种模式更“高级”，而在于哪种模式更贴合你当前要解决的问题。
如果你打算把这篇文章做成完整带图版本，后续还可以再补两张真实素材：一张是你团队自己收到的邀请码或审批邮件截图，另一张是你自己的真实项目工作区截图。这两类图都不建议做 mockup。当前公开界面已经足够支持我们诚实地讲清楚 access 门槛和模式差异，没必要为了“看起来完整”去伪造最关键的可信度。
