只有一个人懂提示词：Runway App Studio把工作方法变成团队工具

Ken Jo根据下方列出的来源制作的原创说明图。

团队有一套可靠的方法，把产品照片变成营销图片。问题是，可靠的其实是一个人：只有他知道提示词、参考资料、模型设置，以及哪个结果需要重做。其他人只能等待，或从聊天记录中重建流程。

Runway在 2026年10月26日推出App Studio，希望将这类经验作为工具分享。用户描述创意应用，系统便围绕任务构建界面。公告称，所有付费方案都可创建应用，免费用户则可运行内置应用及别人分享的应用。官方公告。

Runway开发媒体生成与制作工具。App Studio给这个熟悉领域增加了一个实用问题：团队能够为自己的重复创意工作构建界面，会发生什么？产品图、分镜和建筑预览三个例子展示其吸引力，小型试点则能检验工具是否易懂、成本可承受且适合分享。

共享界面承载的不只是保存的提示词

提示词只是可用创意流程的一部分。执行者可能还知道哪个参考是最新的、输出应多大，以及何时结果不合格。只传递提示词文本，会让许多知识继续隐含着。

应用可以让部分选择变得可见。它不用要求同事复现长对话，而是收集产品照片、目标格式和营销方向。底层流程负责重复步骤，使用者提供每次任务变化的信息。

10月26日公告介绍了结合Runway图像、视频、音频模型，以及Brand Kits、Workflows、Assets、References的应用，也说明了把成功的现有流程转成应用。对已经理解某个过程的团队而言，这是一种值得关注的封装方法。已宣布能力。

可以把它想成配有易用操作台的食谱。食谱保留顺序，操作台告诉下一位使用者把材料放在哪里。好的界面减少每次运行都得重新发现的决策。

我们认为，这是尝试产品最有力的理由。关键结果是第二个人能否在原专家不站在旁边时完成真实任务。精美界面只有在背后流程仍可理解、结果仍可审核时才有用。

复用的是流程及参考资料。每个新输出仍需要与用途相符的审核。

产品图适合作为首次试验

设想一个小品牌，要为同一产品的多个款式准备图片。团队已有获准照片、视觉方向和所需格式清单。重复任务是把这些输入变成一组一致的待审候选。

示例应用可以要求上传产品照片并选择场景，再按批准流程生成变体。请求者需要复原的隐藏设置更少，审核者也能收到更可预测的输出集合进行比较。

这个起点有吸引力，因为验收标准可以具体。标签清晰吗？产品形状保留了吗？场景符合简报吗？所需裁切能用吗？生成前写下标准，避免好看的结果分散注意，让错误产品细节被忽略。

共享工具也可能让重复错误传播更快。如果参考过时，或指令允许不必要的包装改动，每位用户都可能产生同一问题。明确资料负责人，把流程修改视为需要重新小规模评估的变化。

Runway的Brand Kits文档介绍，将已存素材和规则作为上下文使用，无需每次Agent会话都重新上传。这有助于理解共享参考资料的价值。但它仍是生成指引，团队应继续依据实际简报检查输出。Brand Kits指南，2026年10月27日查阅。

分镜应用应让创意决策更容易讨论

第二个例子是把短广告脚本变成分镜候选。可重复界面可以收集脚本、参考风格及目标画面比例，再呈现场景序列，供团队在正式制作前讨论。

部分价值来自一致性。每次请求都有相同关键输入，审核者就不用花太多时间还原请求意图，而能关注序列是否传达信息、哪里需要不同镜头或转场。

明确显示分镜状态。生成序列是讨论提案，审核者应能分辨已接受与需修改部分。应用应让人容易返回简报，避免首个输出意外成为最终决定。

这也暴露了一个设计选择：界面应提供多少自由度？控制过多会重现原本想减少的复杂性；过少则迫使用户接受不适合工作的狭窄结果。先保留真正改变创意决策的输入，只有重复使用证明必要时才增加控制。

建筑预览让交接可见

Runway发布公告介绍了建筑事务所KPF用App Studio为设计渲染制作动画。按公司的说法，设计师在静态图中指定运动并绘制镜头路径，生成有明确方向的视频。这是厂商发布的客户案例，与上面的假设流程不同。公告中的KPF案例。

这个例子的有趣之处在于输入表达意图。设计师可以指出什么应当移动、视角怎样行进，而不用让同事从笼统说明中猜镜头。专门界面可以使这次交接更精确。

评估类似流程时，请区分视觉沟通与设计验证。吸引人的预览能帮助讨论提案，却不能证明每个生成的空间细节都符合底层设计。精确属性重要时，应使用适当的原始图纸与模型。

这是普通的创意实践：不同成果回答不同问题。草图帮助讨论方向，技术文档确定规格。生成预览也应在审核中有明确角色，避免其优点引出无依据的结论。

从私有应用与一个清晰验收测试开始

Runway创建指南介绍了并排的对话面板与实时预览。用户可请求修改、检查Code视图，并在准备好后发布。文档称开始创建会话需要约 700积分余额，创建费用以约 50积分一批 收取。这是余额与计费规则，不是一个完成应用的固定价格。创建指南，2026年10月27日查阅。

从已经知道何为好结果的任务开始。试验应用无法独自把不明确的简报变清楚。缩小用途，评估另一个人能否在少量说明下正确使用。

1. 选择一项重复任务和获准输入样例。 产品图场景使用团队有权处理的小组素材，以及验收标准明确的现有简报。
2. 从Runway侧栏打开App Studio。 描述输入、目标输出及界面应暴露的决策，把审核步骤也列为任务一部分。
3. 扩展前检查首次预览。 看不熟悉原提示词的同事是否理解字段与必填输入；如有问题，提出具体改动。
4. 用相同代表性输入执行流程。 记录被拒结果和获准结果，检查审核者是否得到足够上下文来理解输出。
5. 首次发布限制受众。 在Publish面板选择适当的有限范围，与目标协作者验证访问。交接有效后再扩大分享。
6. 记录版本和积分用量。 记下改了什么、检查哪些样例，以及谁负责参考资料。重要修改后重复验证。

这些是评估计划，不需要假定预览能运行就适合所有同事或输入。第一次成功交接应帮助团队找到该简化什么，再邀请更多人使用。

积分让问题从创建转向运营

发布公告称，创建、运行与托管都消耗现有Runway积分。公开分享应用的访问者支付自己的生成费用，创建者负责创建、自己的生成以及托管。10月26日公布的费用责任。

内部评估应分别记录这些类别。团队可能在生成合格素材前，先为界面调整花费积分，也可能为一个获准结果生成多个候选。只计算最后成功的一次，会隐藏学习和迭代成本。

记录可以简单：初次创建、后续修改、生成尝试、接受结果，以及应用保持可用的时间。使用工作区实际用量，别从起始余额推算单张图成本。有用的指标取决于应用想改善的任务。

也记录工具周围的人力。生成更便宜却需要更多手工修补，未必帮得上忙。流程消耗更多积分，却让请求与审核更明确，也可能值得。比较应覆盖完整的重复工作，并在两边采用相同质量标准。

分享与维护需要负责人

Runway分享文档描述私有预览，以及创建者、工作区、指定人员等受众选项。发布公告还描述受账户与Enterprise控制约束的公开链接分享；访问者仍需要Runway账户。请从实际工作区启用的选项出发，分发链接前验证谁能打开。分享指南，10月27日查阅。

这里应区分应用与输出。某人可以运行工具，但生成素材可能属于特定项目或仍为私有。资产指南说上传与生成素材默认私有，部分协作功能会在项目或工作区内共享。请同时检查应用受众和结果去向。资产管理指南。

维护也需要实际退出路径。现行创建指南称，App Studio暂不支持删除或取消发布；把受众设为 Only you 可阻止他人打开。试点结束或工具被替换时，应按这一已记载行为规划。当前应用管理限制。

团队理解结果、受众、运营费用及由谁保持流程更新后，再扩大分享更合适。

指定负责人无需复杂。有人知道品牌参考何时变化、大家用哪个版本，以及结果不合格时怎样处理即可。目的是让共享应用比缺少文档的提示词集合更容易维护。

重要的用户是第二个人

App Studio最有意思的承诺，是传递实用知识。团队可将有价值的创意过程，交付成另一个人理解的界面。这比询问能否用一句话生成应用，更有评估意义。

观察第二个人如何使用：误解哪些输入、过早信任哪些输出、哪里仍需要原专家。那些时刻会说明流程是否真正可复用，以及下一版应该改什么。

来源

• Runway App Studio介绍，2026年10月26日。
• 使用App Studio创建应用，2026年10月27日查阅。
• 分享App Studio应用，2026年10月27日查阅。受众可用性遵循工作区的账户与管理员控制。
• 在Agent中使用Brand Kits及管理资产，2026年10月27日查阅。

所提流程与试点仅作说明。KPF案例来自Runway公告；本文未进行应用创建基准测试或积分成本测量。

Telli.sh推荐

将每次流程修改背后的创意简报、审核笔记和决策保存在一起。创建Telli.sh账户，整理参考资料与项目笔记。