打破 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 官方文档

核心结论：
“想法翻译器”范式。
使用 TRAE、VS Code+Copilot GPT 5.2、GLM+CLINE 还是 Gemini 3 Pro 产品经理都能通过 “自然语言描述需求→AI生成代码→增量迭代验证” 的通用方法，将想法直接转化为高保真原型和可讨论方案。
关键差异仅在于“执行环节”（自动 vs 手动），分析逻辑、指令模板、迭代流程一致。

一、技术本质

AI+IDE 的核心不是工具，而是“自然语言→代码→产品”的思维链
所有工具均遵循同一逻辑流： 

1 2 3 4 5 6 7

graph LR A[自然语言需求] --> B[AI生成可执行代码] B --> C{执行方式} C -->|全自动| D[AI自动运行结果] C -->|半自动| E[手动运行代码] D/E --> F[验证结果+追问] F --> G[交付高保真原型/文档]

通用操作流程（100%跨工具一致）

1. 需求描述
   用自然语言清晰描述产品逻辑（如“在页面右侧加聊天面板”）
2. AI生成代码
   AI将需求转为可执行前端代码（React/Vue等）
3. 增量迭代
   小步快跑：框架→组件→交互，逐步完善
4. 结果验证
   通过截图/Playwright对比检查还原度
5. 交付成果
   生成高保真原型/PPT/文档，用于需求对齐

二、三大核心场景：通用方法论

场景一：需求迭代与原型设计

传统痛点： 

画原型→反复改稿→与研发拉扯→上线效果失真

AI+IDE 解决方案： 

1
2
3
4
5
6
7
8
9
10

1. 用自然语言描述需求（通用指令模板）：
   “在[页面]的[位置]添加[组件]，要求：[关键细节]，注意：[特殊约束]”

2. 选择还原方式（工具通用）：
   截图法：截图+Playwright MCP（所有工具支持）
   设计稿法：Figma链接+AI Bridge（需安装对应插件）

3. 优化还原度（工具通用）：
   “检查[组件]的还原度，重点对比：字号/间距/颜色系统”
   “请复制[classname]的样式，精确还原到目标效果”

💡 真实案例（跨工具复现）：
指令：
“在电商页面右侧添加聊天面板，顶部是标题，中间是消息区（无头像），底部是输入框。要求：符合移动端尺寸，使用FRONTEND_SPEC.md规范。”
结果： 

• TRAE/Claude CLI：自动执行 → 生成高保真HTML 
• GLM 5+CLINE：生成代码 → 手动运行 → 交付原型
• Gemini 3 pro: 目前来看，效果最佳，网页的呈现程度最高

场景二：0-1项目原型与逻辑验证

传统痛点： 

接口猜谜→逻辑盲区→无法验证技术可行性

AI+IDE 解决方案： 

1
2
3
4
5
6
7
8

1. 先写实现文档（通用指令）：
   “根据需求[描述]，写一份实现文档，包含：技术栈、核心流程、关键接口。在确认前不修改代码。”

2. 生成基础框架（通用指令）：
   “创建[项目类型]的前端基础框架，使用[技术栈]，要求：[关键细节]”

3. 逐步接入逻辑（通用指令）：
   “实现[功能]，要求：[具体交互流程]，使用[工具]验证”

💡 关键技巧：
“用户视角”描述法（100%通用）：
“从[起始位置]→[操作]→[反馈]→[位置]→[内容]，完整描述交互流程”
例：
“用户点击聊天图标→右侧弹出面板→消息区显示历史对话→输入框支持发送→发送后显示思考状态”

场景三：文档编写与对齐

传统痛点： 

PPT纺织工→结构混乱→无效纠结

AI+IDE 解决方案： 

1
2
3
4
5
6
7
8

1. 写草稿（自由随性，工具通用）：
   “我需要同步[项目]给研发，核心是[功能]，支持[场景]，未来会[扩展]”

2. 生成专业文档（通用指令）：
   “根据以下草稿，生成结构化文档：总分结构+Mermaid流程图+关键逻辑说明”

3. 生成可视化图表（通用指令）：
   “输出Mermaid框架图，展示[核心流程]；生成可交互的图表用于PPT”

💡 真实案例：
草稿：
“电商Agent支持商品搜索，用户对话中识别意图，调用商品库，返回卡片式结果。”
AI输出：
生成带Mermaid流程图的MD文档 → 用于研发对齐 → 业务汇报

三、通用关键技巧

1. 页面还原双法器

2. 细节微调四板斧

3. 项目规范最佳实践

四、工具选择建议

五、终极心法：从“画图”到“说话”

“产品经理的核心能力不是画原型，而是清晰描述产品逻辑。”

• 以前：用Axure/Figma画图 → 传递模糊意图 
• 现在：用自然语言描述逻辑 → AI生成高保真原型
  工具差异仅在“执行效率”，但思维本质从未改变。

✨ 一句话总结：
“你的指令越精准，AI的原型越可靠；你的描述越清晰，协作的效率越高效。”
—— 无论用 TRAE、GLM+CLINE 还是 Gemini 3 Pro，这句真理永不淘汰。

附录：通用指令模板库（直接复制使用）

1. 页面还原指令

1

“根据[截图/Figma链接]，1:1还原前端页面。技术栈：[React/Vue]。要求：[关键细节]，注意：[特殊约束]。”

2. 交互描述指令

1

“描述[功能]的交互流程：从[起始位置]→[操作]→[反馈]→[位置]→[内容]。需要符合[FRONTEND_SPEC.md]规范。”

3. 文档生成指令

1

“根据以下草稿，生成结构化文档：总分结构+Mermaid流程图+关键逻辑说明。草稿：[粘贴你的草稿]”

写在最后： 

“不是工具让你变强，而是‘清晰描述产品逻辑’的思维让你破界。”
从此，产品经理不再需要纠结于“如何画图”，而是专注于： 

• 梳理产品逻辑（核心价值） 
• 定义用户流程（关键创新） 
• 验证技术可行性（能力飞跃）

记住：
“你的指令是钥匙，AI是开锁人，执行是你的动作——工具不同，钥匙的形状一样。”