根据最新信息，渣打银行、汇丰银行和OSL作为香港首批稳定币牌照的入围机构，各自在稳定币应用场景上有着不同的战略布局和重点方向。以下是三家公司的稳定币应用场景详细对比：

总结来看：

• 渣打银行侧重于零售支付创新（稳定币信用卡）与港元稳定币在金融体系的融合，同时关注新兴市场的货币替代与跨境支付需求。
• 汇丰银行以黄金稳定币为核心，切入实物资产代币化赛道，并依托传统银行优势拓展机构级区块链结算与跨境支付场景。
• OSL作为持牌数字资产平台，聚焦企业级支付与结算，通过USDGO稳定币、BizPay支付方案及RWA代币化服务，构建“发行-资产化-流通”闭环，主打跨境贸易与B2B支付效率提升。

稳定币发行基础和具体的RWA资产情况如下：

准入与持续运营的七大核心监管支柱

1. 严格的牌照与资格管理

   • 持牌经营：任何在香港发行法币稳定币（如美元、港元）或向香港公众积极推广此类稳定币的机构，必须持有HKMA颁发的牌照。
   • 本地实体：申请人必须在香港注册成立公司或为获认可的机构，并在香港设有可识别的管理层和实体办公室。
   • 适当人选：HKMA会对发行人的董事、行政总裁及稳定币业务负责人进行背景审查，确保其具备良好信誉和专业能力。

2. 资本与财务稳健性要求

   • 最低资本：持牌人必须维持不少于2500万港元的实缴股本，或等值其他货币的资本。
   • 充足流动性：需持有足够的流动净资产，以应对业务运营和潜在风险。

3. 全额、高质量储备资产托管与隔离

   • 100%资产支持：已发行的稳定币必须有100%高质量、高流动性资产（如现金、短期银行存款、高信用评级政府债券）作为全额储备支持。
   • 资产隔离：储备资产必须与发行人自有资产严格法律隔离，由符合资格的独立托管人（通常为持牌银行）持有，确保即使发行人破产，储备资产也不会被用于清偿其普通债务。
   • 禁止投资：储备资产不得投资于加密货币、衍生品等高风险资产。

4. 强制、公平的赎回保障

   • T+0至T+2赎回：持牌人必须建立机制，确保稳定币持有人能在提出申请后的1至2个工作日内，按面值赎回对应的法币。
   • 无不合理障碍：不得设置不合理的赎回门槛或过高费用。

5. 全面的风险管理与公司治理

   • “三道防线”架构：需建立完善的治理架构，董事会负最终责任，并设立独立的风险管理、合规和内部审计职能。
   • 全面风险管理：必须制定政策管理信用、市场、流动性、操作、法律及声誉等各类风险。

6. 严厉的反洗钱/反恐融资（AML/CFT）措施

   • 客户尽职审查（KYC）：必须对客户进行严格的身份识别与核实，类似“实名制”要求。
   • 交易监控：需建立系统监控稳定币交易，识别并报告可疑活动。
   • 链上身份验证：HKMA正探索要求所有稳定币持有人的身份必须持续可验证，稳定币只能转账至已验证身份的钱包地址，从协议层面杜绝匿名交易。

7. 高频、透明的信息披露与审计

   • 每日监控、每周报告：持牌人须每日编制流通稳定币面值及储备资产市值与构成报表，并每周向HKMA提交报告。
   • 定期独立审计：必须聘请HKMA认可的独立审计师，每月对储备资产的充足性和构成进行审计并出具认证报告，并在期末后1个月内向公众披露。

汇丰银行 (HSBC)
1. 黄金稳定币的特殊性：重点监管其HSBC Gold Token这类由实物黄金支持的稳定币，确保黄金储备的足额、安全托管和独立审计。
2. 代币化存款的界定：厘清其“代币化存款”产品与受《稳定币条例》监管的“法币稳定币”之间的界限，确保监管全覆盖。
3. 跨境结算合规：对其利用稳定币进行跨境支付结算的场景，加强AML和跨境资金流动监控。

持续的监管工具与执法

• 现场检查与非现场监测：HKMA会定期或不定期对持牌人进行现场审查，并持续通过报表进行非现场监测。
• 监管沙盒与沟通：在牌照发放前，部分机构（如渣打参与的合资公司）已通过“稳定币发行人沙盒”与HKMA进行了业务测试和监管沟通。
• 处罚权力：对于违反规定的持牌人，HKMA有权采取一系列措施，包括罚款、要求整改、暂停部分或全部业务，直至吊销牌照。虚假声称持牌或未经授权发行稳定币均属刑事犯罪。

打破 AI 与 BI 的底层壁垒：基于 Ray + Lance + Iceberg 的多模态数据湖架构实践

在企业数字化转型的深水区，数据架构正在经历一次深刻的裂变。一方面，基于结构化数据的 BI（商业智能）体系已经非常成熟；另一方面，以大模型和多模态为核心的 AI 业务正在狂飙突进。

然而，当我们要将 AI 和 BI 结合时，底层的存储和计算瓶颈却暴露无遗。本文将深入探讨一种业界前沿的多模态数据湖（Multimodal Data Lake）架构，看看如何通过 Ray on EKS + Lance + Iceberg + Trino 的技术栈组合，彻底打通非结构化与结构化数据的任督二脉。

1. 业务的痛点：当传统数据湖遇到 AI

在构建现代 AI 应用（如音视频智能分析、多模态 RAG、精准推荐）时，传统基于 Parquet 或 ORC 格式的数据湖仓往往显得力不从心：

• 多模态数据存储与检索极其低效： 传统列式存储并不擅长处理超长文本、海量图片和高维特征向量（Embedding）。读取带有百兆级别大字段的表时，内存极易溢出（OOM）。

• 探索新特征的成本高昂（Schema 僵化）： 算法团队经常需要迭代模型（如上线 v2 版本的 Embedding 算法）。在 Parquet 中新增一列特征，往往意味着要重写数十 TB 的历史数据。

• AI 与 BI 的“数据孤岛”： 数据分析师用 SQL 在 Iceberg 里查用户画像，算法工程师用 Python 在 S3 里捞原始视频。当业务需要进行跨界联动（例如：“找出所有高净值用户看过的、且情绪被识别为‘积极’的视频”）时，由于缺乏统一的元数据和联邦查询能力，只能靠写胶水脚本做低效的数据搬运。

2. 设计与方案：双轨制并行的数据底座

为了解决上述痛点，我们需要打破“一个格式打天下”的迷思，采用**“底层存储统一、中间格式分流、上层计算按需调用”**的设计哲学。

• 统一存储与元数据层： S3 作为唯一的 Single Source of Truth，结合 AWS Glue Data Catalog 作为全局统一的数据字典。

• 双轨制存储格式：

  • Iceberg 层 (BI/分析侧): 负责承载强约束、需要 ACID 事务支持的结构化数据（如用户标签、交易流水）。

  • Lance 层 (AI/多模态侧): 替代 Parquet，专门存储非结构化数据。Lance 的按列排列和碎片管理机制，天生支持高维向量的快速随机访问（Random Access），且支持零拷贝（Zero-copy）的动态列扩展。

• 异构计算与联邦查询层：

  • Ray on EKS: 作为 AI 处理引擎，混合调度 CPU 和 GPU 节点，从 S3 并发拉取非结构化数据，执行预处理、模型推理（提取 Embedding），并利用 Lance 的高 I/O 原生接口流式写入 S3。

  • EMR Trino: 作为联邦查询引擎，打破 AI 与 BI 的界限。分析师可以直接写 SQL 对 Iceberg（结构化）和 Lance（非结构化特征）两张表执行 JOIN 操作。

• 生命周期管理： 结合 S3 的冷热分层（Intelligent-Tiering 与 Glacier），并通过 Ray 定期执行 Lance 碎片的 Compaction（合并压缩），实现极具性价比的海量数据归档。

3. 架构图：平行的计算与存储宇宙

在这个架构下，AI 和 BI 不再是上下游的附庸关系，而是共享底层数据底座的平行宇宙。

Plaintext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

     AI & Apps Layer       BI & Analytics Layer
    (Vector/RAG/Apps)        (Dashboards/SQL)
           │                        │
    ┌──────┴───────┐         ┌──────┴───────┐
    │  AI Compute  │         │ Query Engine │
    │ Ray CPU/GPU  │         │  EMR Trino   │
    └──────┬───────┘         └────┬─────┬───┘
           │      ┌─ Metadata ─┐  │     │
           │      │Glue Catalog│  │     │
           │      └─┬────────┬─┘  │     │
           ▼        │        │    ▼     ▼
    ┌───────────────┴┐    ┌──┴──────────────┐
    │ Lance Tables   │    │ Iceberg Tables  │
    │ (Unstructured: │    │ (Structured:    │
    │ Video, Audio,  │    │ User Profiles,  │
    │ Embeddings)    │    │ Transactions)   │
    └──────┬─────────┘    └─────────┬───────┘
           │                        │
===========▼========================▼===========
                AWS S3 Storage
          (Raw / Hot Data / Archive)

4. 行业先锋实践案例

这套架构并非空中楼阁，国内外头部科技企业已经在使用类似的技术栈重构其数据湖：

• Netflix (Media Table 实践): Netflix 构建了大规模的 Media Table，将视频的 URI、基础元数据和各种机器学习模型输出的特征（Embedding）统合存储。通过类似 Lance 的格式特性，算法团队可以在不重写底层原始大文件的情况下，极其轻量地动态增加列，极大地加速了新推荐特征的探索与上线。

• Bilibili (基于 Ray + Lance 的底层数据湖): B站面临着海量视频、弹幕等多模态大向量的存储与计算挑战。他们引入了 Ray + Lance 技术栈。Ray 提供了极致的分布式计算扩展性，而 Lance 彻底解决了传统格式处理大向量时的 I/O 拥堵问题，实现了灵活的 Schema 扩展和高效的 AI 模型训练数据投喂。

5. 方案的短板与落地防坑指南

没有任何架构是银弹，在落地这套前沿方案时，仍需正视以下短板与挑战：

1. Trino 并非向量数据库： Trino 能够完美执行跨界 JOIN（例如匹配用户 ID），但绝对不能用 Trino 去执行底层的 KNN（K-近邻）高维向量相似度检索。复杂的向量计算仍需推回给在线的 Vector DB（如 LanceDB、Milvus）或在 Ray 任务中完成。

2. S3 API 限流与海量小文件灾难： 当并发处理数亿张小图片或音频切片时，极易触发 S3 的 503 Slow Down。必须在接入层做好合并（Batching/Tarball），或者在 EKS 引入分布式缓存（如 Alluxio）。

3. 跨模态的数据一致性黑洞： Iceberg 和 Lance 是两个独立的格式层，缺乏全局的分布式事务锁。如果 BI 侧的用户状态已更新，而 AI 侧的向量特征未重算，Trino 查询时可能会出现短暂的数据“错位”。这需要上层的数据编排工具（如 Airflow/Dagster）来保障任务链路的强一致性。

4. 缺乏亚秒级实时能力： 这本质上依然是一个以批处理和微批处理（Batch / Near-line）为主的数据湖仓架构。如果业务需要毫秒级的事件驱动反馈，还需要额外挂载 Flink + Kafka 组成的流计算引擎。

当我们剥开繁复的算法外衣，回归银行业务的本质时，会发现真正的解法并不在于前端的“购物车”有多绚丽，而在于底层是否构建了扎实的 Next Best Action / Next Best Offer (NBA / NBO) 引擎。

迷思：复杂的 AI 推荐系统是画蛇添足吗？

许多产品团队在设计财富管理系统时，往往会采用类似电商或内容平台的“媒体推荐逻辑”：系统模拟客户 -> 资产排序 (Ranking) -> 放入购物车 -> 客户阅读并购买。

但这并不是银行财富管理的真实逻辑。如果完全按照这条路走，之前的诸多复杂设计确实容易变成“画蛇添足”。

但好消息是，你并没有全盘走错，只是把层级放错了。 复杂的 AI 系统不应该被推翻，而是应该被“降维”成 NBA/NBO 战略下的一个具体技术实现。

简而言之：NBA / NBO 是战略原则，而 Recommendation Cart / Opportunity Hub 是技术实现。

在每一个时间点 $t$，银行核心决策引擎要计算的是：

$$Action_t = \arg\max E(\text{Customer Value} \mid State_t)$$

这里的 $State_t$（状态）包含了客户的账户余额、交易行为、收入周期、宏观市场等。这就是 Next Best Action 引擎的数学本质。

国际银行的核心逻辑：从客户洞察到行动触发

一家顶级的国际银行，其标准的财富管理运作框架是非常连贯的：Customer（客户） → Context（场景） → Decision（决策） → Action（行动）。

为了让这个 NBA/NBO 引擎真正落地，我们需要构建以下四大核心支柱：

1. 科学的客户金融分类（四个关键维度）

要做到精准推荐，首先要对客户的资金和偏好进行立体分类：

• 风险维度 (Risk, R1-R5)： 这是合规与投资者保护的底线（如从 R1 保本型到 R5 激进型）。

• 时间维度 (Horizon)： 银行实际销售中，时间往往优先于风险。资金需要被划分为流动资金（0-6个月）、配置资金（1-3年）和财富资金（5年以上）。

• 空间与主题维度 (Space/Theme)： 涵盖区域（如 US/Asia/EU）与行业板块（如 US Tech, Global AI），这通常由银行的 CIO Office 来定义。

• 驱动维度 (Macro Driver)： 这是非常高级的视角，即客户对宏观事件（利率、金价、地缘政治）的敏感度。

2. 场景触发 (Liquidity Events)

银行并非让 AI 漫无目的地随时向客户推销产品，真正的 NBO 是事件驱动 (Event Driven) 的。

当客户发生特定的资金事件（如工资到账、年终奖发放、大额应收账款到账、分红或存款积累）时，系统才会触发相应的行动。

3. 基于 SOP 的推荐脚本

在顶级机构中，推荐内容的决定权不在单纯的算法，而在由 Investment Office 和投资委员会主导的 SOP（标准作业程序）。

例如，当系统监测到客户收到一笔奖金（Bonus Trigger），且客户画像为“风险 R3 + 周期 3年 + 偏好美股”，客户经理 (RM) 的系统面板上就会直接弹出一条 SOP 指令：建议推荐 60% 债券基金 + 30% 股票 + 10% 黄金。RM 的核心工作是执行这一 SOP，而非自己盲目搭配。

4. 大数据与客户画像 (Customer Affinity Model)

结合客户的职业、行业、年龄、性别和收入等数据，系统通过大数据关联分析，输出的是产品兴趣概率 (Probability of Interest)。

将这个概率与合规适配度 (Suitability)、资金流动性 (Liquidity) 和触发事件 (Event) 结合，才能输出最终的 Next Best Offer。

终极蓝图：国际银行顶级财富管理五层架构

理顺了上述逻辑，我们再来看系统架构。之前设计的“推荐购物车”其实仅仅处于交付层，属于“购买过该产品的客户还买了什么”的辅助模块。真正的系统核心应该深藏于后端。

如果您正在规划一个国际银行级别的 Wealth NBA/NBO 引擎，它应该呈现为高度清晰的五层架构：

• Layer 1: Customer Intelligence（客户智能层） - 负责画像提取与概率预测。

• Layer 2: Investment Strategy（投资策略层） - 承载 CIO Office 的市场观点与宏观驱动逻辑。

• Layer 3: Event Engine（事件引擎层） - 实时监听资金与流动性事件。

• Layer 4: NBO Decision Engine（决策引擎层） - 结合前三层数据，结合合规规则，输出最优动作。

• Layer 5: Channel Delivery（渠道交付层） - 此时，RM Dashboard、手机 App 以及我们之前设计的 Opportunity Hub / 购物车，才作为触达端发挥作用。

结语

在银行业，系统的复杂度往往来源于严格的合规要求，而非深奥复杂的黑盒算法。

全球 90% 的银行在搭建 NBA 引擎时，容易把架构重点放错，过度追求前端 AI 的拟人化推荐。当你开始从“客户资金事件 -> 分类适配 -> 投资主题 -> 产品组合 -> RM 触达”这个纯正的银行业务视角来思考时，你的架构方向就已经无限接近瑞银（UBS）或摩根士丹利等全球顶级财富管理机构的真实运作逻辑了。

保持思路的连贯与克制，让系统回归业务本身，才是财富管理数字化转型的终极答案。

摘要：本报告旨在通过数字化重构，将银行从依赖客户经理（RM）体力的“线性增长模型”，转型为由“AI+数据”驱动、边际成本递减的“指数增长平台”。我们的核心目标是通过系统杠杆，在不线性增加人力成本的前提下，实现 AUM 规模与利润率的同步增长。

一、 核心战略：财富管理的“第一性原理”与破局

财富管理业务的本质可拆解为三个元要素：

1. 信任 (Trust)： 解决“为什么选你”——从依赖 RM 个人关系的“人际信任”，转向由机构专业支撑的“系统信任”。
2. 理解 (Understanding)： 解决“你懂我吗”——从 RM 的感性经验，转向基于行为金融学的数字化精准画像。
3. 效率 (Access & Efficiency)： 解决“响应速度”——实现决策闭环的自动化，使服务的边际成本趋近于零。

二、 CEO 决策看板：逻辑模型与 KPI 体系

1. 核心利润逻辑公式

基于第一性原理，我们将利润增长重构为“执行力”与“防御力”的双引擎驱动模型：

$$ { Revenue = \left( \underbrace{\left[ \sum (Leads \times CVR \times \text{Avg Ticket}) \times \frac{1}{T} \right]}{\text{新钱执行力引擎 (Flow)}} + \underbrace{\left[ AUM{base} \times (1 + R_{SAA} - Churn) \right]}_{\text{存量策略引擎 (Stock)}} \right) \times Net\ Margin} $$
$$ { Profit = Revenue - \left( TotalRMCost + OtherVariableOpsCost - CostSaved \right) }$$

• 新钱执行力： 钱转得有多快？（由转化率 $CVR$ 和决策速度 $1/T$ 决定）。
• 存量策略： 钱留得有多稳？（由配置收益 $R_{SAA}$ 和流失率 $Churn$ 决定）。
• 效率杠杆： 靠人还是靠系统？（由 $RM\ Leverage$ 决定单位资产的人力成本）。

2. 六大二级指标监控手册

三、 本质转型：从“加功能”到“重构路径”

深化分析：业务能力与利润指标联动矩阵

按照“利润导向”，业务功能进行重组，并增加了缺失的 AI 乘数效应。

四、核心 KPI 指标计算手册

1. 利润与效率指标

• Cost per AUM (单位资产管理成本)：
  $${ Cost\ per\ AUM = \frac{\text{Ops Cost}}{\text{Total AUM}} }$$

  • 监控： 随着 AUM 扩张，此指标应呈平滑下降曲线，证明规模效应。

• STP Rate (直通处理率)：
  $$ { STP\ Rate = \frac{\text{无需人工干预的订单数}}{\text{总订单数}} }$$

  • 监控： 反映系统自动化程度，直接决定了 $RM\ Leverage$ 的上限。直接体现 Wealth Shopping Cart 减少中后台人工干预的能力。

• Revenue per Employee (人均产出)：
  $${ Revenue\ per\ Employee = \frac{\text{Wealth 总收入}}{\text{总编制人数 (FTE)}} }$$

  • 监控： 衡量人力资源是否真正从繁琐的事务工作中释放，转向高净值客户的深耕。

2. 增长与质量指标

• 1/T (Velocity)： 监测“线索生成”到“下单执行”的时间天数。
• Churn Rate： 监测存量 AUM 的流失率。
• SAA Alpha： 监测 CIO 配置策略对比市场基准带来的超额收益。

Profit 的反推拆解（顶层）

我们不从功能开始，而从 Profit 构成开始：
$$ \textbf{Profit} = AUM \times Net\ Margin - Cost_{Ops} - Cost_{IT}$$

3. Profit → 二级 / 三级指标 → Business Capability 映射表（核心成果）

一级利润目标 ：AUM 扩张（新增 + 存量）

二级指标 ：Leads → AUM 转化效率

二级指标 ：AUM 留存能力

一级利润目标 ：Net Margin 提升

二级指标 ：Product Mix Margin

二级指标 B2：Cross-sell Depth

一级利润目标 ：Velocity（钱转得更快）

二级指标 ：Decision-to-Trade Velocity

一级利润目标 ：Cost 杠杆（指数增长的关键）

二级指标 ：RM Leverage

二级指标 D2：STP & Ops Efficiency

五、以 RM 为中心来思考 Revenue 和 Profit

Revenue 公式重新定义为：
$$ {\begin{aligned} Revenue &= \underbrace{RM FTE}{人} \times \underbrace{Meeting / RM / Year}{RM Capacity} \ &\times \underbrace{Deal / Meeting}{Productivity} \times \underbrace{USD / Deal}{Avg Ticket} \times \underbrace{Percentage}_{Fee Rate} \end{aligned}} $$

单位消去过程：

1
2
3
4

人 × (Meeting / 人 / 年)
× (Trade / Meeting)
× (USD / Trade)
× Percentage

最终单位：USD / Year

什么时候这个公式是“100% 正确的”？什么时候会失效？

成立的前提

• Breakage / Transaction-driven 收费
• RM 是主要但不是唯一触达渠道
• Digital Sales 可以放大交易次数
• 不考虑持有期管理费

可能失效 / 需要升级的情况

六、一个“非常重要但现在才显性化”的洞察

RM Productivity Multiplier 是整个模型中,唯一可以“非线性放大”的变量:

• RM FTE：线性，贵
• RM Capacity：接近线性，有上限
• Avg Ticket：受客户资产约束
• Fee Rate：受市场与监管约束

只有 Productivity Multiplier：

• AI 可以提升
• 不增加人
• 不碰监管红线
• 对老客户同样有效
  $$ { Profit = Revenue - \left( TotalRMCost + OtherVariableOpsCost - CostSaved \right) } $$
  注意一个非常重要的点：
  RM FTE 同时出现在 Revenue 端 和 Cost 端
  这正是 “算法驱动 vs 人力驱动”

核心结论：

产品人员可以通过 “自然语言描述需求 → AI生成视频代码 → 增量迭代验证” 的工作流，将想法直接转化为高质量视频内容，无需学习 AE、DaVinci、Final cut pro 等专业剪辑软件。

一、为什么要用 AI+IDE 做视频？

传统视频制作的痛点

AI+IDE 视频创作的优势

1. 零学习成本：用自然语言描述即可，无需掌握时间轴、关键帧等概念
2. 代码即视频：所有动画都用代码描述，版本可控，可追溯
3. 增量迭代：小步快跑，随时调整，即时预览
4. 一键渲染：代码写完后，一键生成 MP4 视频

二、方法论：自然语言 → 代码 → 视频

核心思维链

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

graph LR

A[自然语言需求] --> B[AI生成视频代码]

B --> C[本地运行预览]

C --> D[验证效果]

D -->|不满意| E[追加指令调整]

E --> B

D -->|满意| F[渲染输出MP4]

实践案例：Wealth Copilot 产品介绍视频

背景：需要将一份 HTML 格式的 PPT 演示文稿（7 页 slides）转换为产品宣传视频。

完整工作流程：

Step 1: 需求描述

向 AI 提供清晰的需求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

我需要用 Remotion 制作一个产品介绍视频。
素材来源：solutions/presentation_market.html
这是一个关于 "AI-Native Wealth Insight Copilot" 的演示文稿，包含 7 个 slides：

1. 标题页 - 展示产品名称和关键指标
2. 核心价值 - 客户价值与业务价值
3. SOP 设计 - 工作流程图
4. 合规框架 - 4层合规架构
5. 零幻觉策略 - 安全保障措施
6. 真实案例 - 两个使用场景
7. 总结 - 4个核心要点

要求：
- 视频尺寸 1920x1080
- 每个 slide 展示 6 秒
- 添加平滑的转场动画
- 使用红色主题色 #dc001c
- 动画风格：专业、简洁

Step 2: AI 生成项目框架

AI 会自动创建 Remotion 项目结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

movie/
├── package.json # 项目配置
├── tsconfig.json # TypeScript 配置
├── remotion.config.ts # Remotion 配置
├── src/
│ ├── index.tsx # 入口文件
│ ├── Video.tsx # 视频主组件
│ └── components/ # Slide 组件
│ ├── TitleSlide.tsx
│ ├── CoreValueSlide.tsx
│ ├── SOPDesignSlide.tsx
│ ├── ComplianceSlide.tsx
│ ├── AntiHallucinationSlide.tsx
│ ├── ExamplesSlide.tsx
│ ├── SummarySlide.tsx
│ └── Transition.tsx
└── out/
└── video.mp4 # 最终输出

Step 3: 增量迭代开发

第一轮：先让 AI 创建基础框架和第一个 slide

1
2
3
4
5
6
7

请先帮我：
1. 初始化 Remotion 项目
2. 创建 Video.tsx，定义 7 个 slide 的时间轴
3. 先实现 TitleSlide 组件，包含：
- 标题 "AI-Native Wealth Insight Copilot"
- 副标题高亮框
- 4 个关键指标卡片（带动画）

第二轮：验证效果，继续添加其他 slides

1
2
3

TitleSlide 看起来不错！请继续创建：
- CoreValueSlide：左右两栏布局，展示 For Customers / For Business
- SOPDesignSlide：顶部流程图 + 底部两个信息卡片

第三轮：添加转场效果

1
2
3
4

请在每个 slide 之间添加转场动画：
- 使用红色主题色的滑入效果
- 奇数 slide 从左滑入，偶数从右滑入
- 转场时长 0.5 秒

Step 4: 本地预览与调整

1
2
3
4

# 启动 Remotion Studio 实时预览
npm run dev
# 或直接渲染视频
npm run build

Step 5: 最终渲染输出

45 秒后，得到 out/video.mp4：

• 1920x1080 高清分辨率
• 7 个 slides，每个 6 秒
• 流畅的 spring 动画
• 专业的红色主题转场

三、核心技巧与指令模板

1. 视频描述的最佳实践

好的描述：

1
2
3
4
5
6
7
8
9
10

生成一个产品介绍视频，要求：
- 尺寸：1920x1080
- 时长：45秒（7个slides，每个6秒）
- 主题色：#dc001c（红色）
- 动画要求：
* 标题从下方弹性滑入
* 卡片依次弹出，间隔0.5秒
* 使用 spring 动画曲线
* 列表项从左侧滑入
- 转场：红色背景滑入滑出，交替方向

差的描述：

1

做个产品介绍视频，好看一点。

2. 常用的动画指令模板

3. 增量迭代的沟通策略

不要一次性要求太多：

1
2
3
4
5
6

错误："请帮我创建所有 7 个 slides，每个都要有复杂的动画"
正确：
1. "先创建项目框架和第一个 slide"
2. "验证 OK 后，再创建第 2-3 个 slides"
3. "继续添加剩余的 slides"
4. "最后添加转场效果"

4. 处理 AI 生成错误

当渲染出错时，使用 “删除法”：

1
2
3
4
5

渲染时报错：Minified React error #130
请帮我：
1. 先删除复杂动画，用最简单的静态布局测试
2. 确认能正常渲染后，再逐步添加动画
3. 每次只添加一个动画效果，验证后再继续

四、工具链选择

推荐技术栈

对于产品宣传视频，强烈推荐 Remotion：

1
2
3
4
5
6
7
8
9

{

 "dependencies": {
 "remotion": "^4.0.421",
 "react": "^18.2.0",
 "typescript": "^5.3.0"
 }
}

为什么选择 Remotion？

1. React 友好：使用熟悉的 JSX 语法描述视频
2. 时间精确：帧级别的动画控制
3. 参数化：可以通过 props 调整视频内容
4. 可编程：数据驱动，可以从 API 获取内容生成视频
5. 高质量：渲染输出为 H.264 编码的 MP4

进阶工具：Remotion Skills

Remotion Skills 是官方提供的最佳实践检查工具，可以自动分析你的代码并提供优化建议。
安装方式：

1
2
3
4

# 方式 1：使用 Skill.sh 命令行（推荐）
npx skills add https://github.com/remotion-dev/skills --skill remotion-best-practices
# 方式 2：从 GitHub 仓库下载
# 下载 https://github.com/remotion-dev/remotion/tree/main/packages/skills

示例输出：

1
2
3
4

✓ 使用 spring 动画替代线性动画，提升视觉效果
✓ 建议使用 Sequence 组件管理时间轴
⚠ 发现未使用的 import，建议清理
✓ 图片建议使用 @remotion/media-utils 进行预加载

这个工具特别适合在项目完成后或遇到性能问题时使用，能够帮助你写出更专业、更高效的 Remotion 代码。

五、从实践总结的方法论

核心心法

“视频创作的未来不是剪辑，而是描述。”

传统流程：

1
2
3
4

想法 → 画分镜 → 找素材 → 剪辑 → 渲染 → 修改 → 重新渲染
↑___________________________________________↓

（循环多次，耗时数天）

AI+IDE 流程：

1
2
3

想法 → 自然语言描述 → AI生成代码 → 预览 → 追加指令 → 渲染
↑______________↓
（分钟级迭代）

关键成功因素

1. 需求描述要具体

• 明确尺寸、时长、颜色
• 描述动画的起止状态和持续时间
• 提供参考示例或截图

2. 采用增量开发

• 先框架，后细节
• 先静态，后动画
• 先单页，后多页

3. 建立反馈循环

• 每完成一个阶段就预览验证
• 发现问题立即调整，不累积
• 使用版本控制（git）管理代码

4. 理解动画原理

• 掌握基本的动画概念：opacity、transform、spring、easing
• 知道如何描述时间：帧 vs 秒（30fps 下 30 帧 = 1 秒）
• 学会使用 spring 物理动画替代简单的线性动画

六、完整指令模板

项目初始化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

请帮我创建一个 Remotion 视频项目：

项目需求：
- 视频主题：[描述视频内容]
- 尺寸：1920x1080
- 帧率：30fps
- 总时长：[X 秒]
- 包含 [N] 个场景/页面

请创建完整的项目结构：
1. package.json（包含 remotion 依赖）
2. tsconfig.json
3. remotion.config.ts
4. src/index.tsx（入口）
5. src/Video.tsx（主组件）
6. src/components/ 下的各个 Slide 组件

转场效果

1
2
3
4
5
6
7
8

请在 slides 之间添加转场效果：

要求：
- 类型：滑入滑出
- 颜色：[主题色]
- 方向：交替从左/右滑入
- 时长：0.5 秒（15 帧）
- 实现方式：使用 Remotion 的 Sequence 组件

写在最后

通过 Wealth Copilot 视频的实践，我验证了这套方法的可行性：
从需求到视频，45 分钟完成：

• 5 分钟：描述需求，AI 生成项目框架
• 20 分钟：增量开发 7 个 slides
• 10 分钟：添加动画和转场
• 10 分钟：调试优化
• 45 秒：最终渲染输出

相比传统方式的优势：

• AE/DaVinci：学习 1 个月，制作 3-5 天
• AI+Remotion：描述 5 分钟，制作 40 分钟

终极心法：
“你的指令越精准，AI 的视频越可靠；你的描述越清晰，视频的传播力越强。”
视频创作不再是设计师的专利，产品人员用自然语言也能创作出专业级的产品宣传视频。

参考资源：

• Remotion 官方文档