以Harness工程化AI协作，提升研发交付质量。

这两年，越来越多的研发团队已经把AI编程工具带进了日常工作。有人用它补代码，有人让它写测试，有人拿它查文档、搭脚手架、整理方案，也有人开始让agent直接进入仓库，完成一轮搜索、修改、验证和回写。

表面上看，问题似乎已经从“要不要用AI”变成了“用哪个工具”。但真正落到交付时，大家很快会碰到另一层更现实的问题：AI的局部产出可以很快，真正进入研发流程却没那么容易。

很多返工并不是因为模型完全不会写代码，而是因为任务在交给agent之前，依据没有准备完整。页面结构还在变，状态没有补齐，接口边界没有说清，验证口径不统一，结果记录也没有固定落点。这样一来，agent只能靠上下文里零散的信息去猜。第一次也许能猜中，第二次、第三次就开始偏。代码看起来越来越多，协作成本也跟着上来了。

所以这篇文章想讨论的，不是怎样把提示词写得更复杂，也不是单纯推荐某一组工具，而是一个更接近研发现场的问题：

本文问题：怎样把AI放进一个更稳定、更可协作、更可验证、也更容易留下经验的研发流程里。

我把这套做法概括为Harness Engineering。

概念定义：harness在这里指一套让agent能稳定参与研发的工程安排：有任务入口、有执行依据、有工具边界、有验证反馈、有结果记录。

很多时候，团队对agent的期待其实很直接：

• 最好能多做一点

• 少问一点

• 出错少一点

但这三个期待背后对应的并不是单纯的模型能力，而是工程条件：

• 多做一点：上下文和工具是否完整。

• 少问一点：边界、非目标和验收方式是否清楚。

• 出错少一点：验证和回写是否形成稳定链路。

核心结论：agent要可靠参与研发，不能只靠模型回答。项目需要给它准备任务入口、执行依据、工具边界、验证反馈和结果记录。

理论篇：从Prompt到Harness

1.1 局部生成不等于稳定交付

如果只看局部，今天的AI编程工具已经足够能干。它会补函数、会改样式、会写测试，甚至会顺着仓库上下文做一轮看起来像样的实现。但研发真正关心的从来不是“能不能生成一段代码”，而是这段代码能不能进入现有流程、能不能被别人接住、能不能在后续迭代里继续维护。

前端场景里，这个问题通常表现得更早。知道“想做一个什么页面”，不代表页面结构已经稳定，也不代表视觉边界、状态覆盖和实现方式已经对齐。如果只有一段自然语言描述，agent往往会同时猜三件事：

• 页面长什么样

• 有哪些状态

• 代码应该怎么拆

首版做出来并不难。难的是后面继续改的时候，设计稿、状态演示和真实页面慢慢开始分叉。

后端的问题看上去不一样，本质却相似。很多任务一开始只有一句话，比如“做一个同步工具”“补一条处理链路”“把这个流程接起来”。这类描述说清了目标，却没有说清边界：

• 运行模式是什么

• 输入输出是什么

• 失败怎么处理

• 验证怎么做

• 结果应该记在哪里

agent当然也能先写一个版本，但这种“先跑起来再说”的方式，很难直接进入可交付状态。

提示词在这里能解决一部分问题。我们可以把背景写得更长，把要求列得更细，把“不要做什么”补充进去。但prompt通常是一次性的，它很难承担持续验证，也无法自动阻止坏模式扩散。

更常见的情况是，团队开始不断加长prompt：

• 补背景

• 补规则

• 补口径

• 补历史失败经验

短期看这有帮助，长期看会出现两个问题：

所以问题并不只在AI，而在协作链路里缺少统一入口、稳定依据、执行边界和反馈链路。

这就是Harness Engineering要解决的问题。

2.1 第一性原理：从写代码转向跑完整链路

Harness Engineering背后的第一性原理，可以先从研发现场看：

第一性原理：当模型越来越会写代码后，瓶颈不再只是“谁来写”，而是任务有没有说清、边界有没有定住、验证能不能跑、结果有没有人接。

代码生成会越来越便宜，但下面这些事仍然消耗人的注意力：

• 需求澄清

• 优先级判断

• 验收定义

• 架构取舍

• 质量判断

agent-first的研发方式不是让人退出，而是让人把注意力放在更值得判断的地方。

人的注意力应该放在判断上，而不是反复补同一类上下文：

• 目标怎么定：不要反复解释项目背景。

• 边界怎么收：不要每次口头补规则。

• 反馈怎么跑：不要每次手动提醒跑测试。

• 风险怎么判断：不要反复修同类review问题。

• 经验怎么写回项目：不要把结论只留在一次对话里。

agent能不能稳定工作，也不只取决于模型本身。它能看到什么文档，能调用哪些工具，能不能运行测试，能不能读取反馈，能不能知道什么算完成，这些都会影响它能接手到什么程度。

agent能看到什么、能调用什么，决定了它实际能完成什么。

来源：OpenAI Harness Engineering。

对agent来说，可以简单理解成三句话：

• 无法访问的知识，基本等于不存在。

• 无法执行的工具，基本等于没有。

• 无法验证的目标，很难持续修正。

工程信息越容易被agent找到、执行和检查，它能做的事就越接近一个真实工程师能接手的任务。

OpenAI的Harness Engineering实践，最值得借鉴的也在这里。它强调的不是“模型能生成多少代码”，而是当agent开始参与更多软件开发环节时，团队需要把过去靠人记、靠人判断的东西放进系统里。

继续加长prompt只能解决一轮对话的问题。Harness Engineering更关心的是，项目本身能不能提供稳定的入口、边界、验证和反馈。

2.2 最小可用harness的组成

落到项目里，可以先抓三件事：

1.隐性知识要变成可发现的上下文如果一个约束只存在于某个人的经验里，agent基本无法稳定遵守。项目入口、目录说明、架构边界、接口约定、命名规则、验证方式，都应该尽量进入仓库或任务系统。

2.反馈要变成可执行的入口“注意质量”“跑一下测试”这类提醒不够稳定。更好的做法，是把验证命令、runbook、Storybook、contract diff、lint、review gate等变成明确入口。

3.规则要逐步从提醒升级成检查不是所有规则都能一开始机械化，但重复出现的review问题不应该永远靠人提醒。可以先登记在项目约束里，再逐步变成linter、脚本、测试或CI gate。

一套最小可用的harness，至少要组织起五类东西：

一次生成不能构成工程能力，可持续的能力来自一条能跑完的链路：

agent写完代码后进入运行环境，用DevTools等反馈继续修正。

来源：OpenAI Harness Engineering。

也可以把两者的分工再压缩成一张表：

如果把这个原则落到一个普通项目里，起点不是先做一个复杂平台，而是先让仓库具备一套最小可用的harness：有入口地图，有计划协议，有验证入口，有项目约束登记，也有结果回写的位置。

方法篇：把协作链路放进项目

3.1 先固定信息落点

很多团队在使用AI时，会把大量信息放在对话里：

• 项目背景

• 任务范围

• 实现偏好

• 验证方式

• 注意事项

• 上次失败原因

这样做启动很快，但难以复用。下一次换一个agent、换一个同事、换一个任务，这些信息又要重新拼起来。

Harness Engineering的一个核心动作，就是把这些临时上下文移到更稳定的位置。

在一个项目里，可以先把信息落点分清楚。

关键不是把某个系统称为“唯一来源”，而是让每类信息都有清楚的位置。

3.2 从任务入口到评审收口

• 任务状态不要散在聊天里。

• 执行依据不要只停留在口头说明里。

• 验证结果不要只存在本机终端里。

• 评审结论不要只停留在临时对话里。

一项复杂任务在harness里的流转，可以简化成下面这条链：

这样拆开以后，agent不需要凭空理解整个组织流程。它只需要在每个位置完成明确动作：

1.从任务入口拿目标。

2.从计划里拿边界。

3.从仓库里找实现依据。

4.从验证入口读取反馈。

5.把结果写回团队能看到的位置。

基于这个目标，我目前使用的harness模板，把项目里的基础内容分成几类：

这样做的目标，不是让项目目录显得更复杂，而是让agent每次进入项目时，都能沿着同一套路径找到依据、边界、验证和结果记录。

4.1 初始化前先让agent解读模板

https://github.com/SisyphusSQ/harness-template

为了把上面的想法落到普通项目里，模板初始化后的目录可以保持相对克制。它不是要替换原项目的工程结构，而是在原项目旁边补一层协作和验证入口。

如果你拿到的是随文附带的harness模板压缩包，不建议第一步就复制文件。更合适的方式，是把压缩包和目标项目一起交给agent，让它先读模板、再读项目，最后给出初始化方案。

推荐流程：

1. 把harness模板压缩包和目标项目路径一起交给agent。

2. 先要求agent只解读，不修改目标项目。

3. 让agent输出初始化方案：会新增什么、会修改什么、会保留什么、有哪些风险。

4. 根据目标项目的技术栈、任务系统、验证命令和团队约定，选择需要初始化的层级。

5. 确认方案后再执行初始化，并在完成后运行项目验证命令和harness检查。

模板包提供的是一套可复用的项目结构，不是一组必须原样照搬的文件。落到项目里时，agent应该先理解模板，再理解目标项目，最后再把两者对齐。

模板目录把入口、计划、约束、验证和脚本放到项目内，方便后续任务复用。

一个典型初始化结果大致如下：

这个目录不是为了在项目旁边再建一套“文档工程”。这些文件的作用，是让项目本身更容易被agent使用，也更容易被团队协作维护。

AGENTS.md是入口地图，负责导航和边界说明。.agent/PLANS.md和.agent/plans/TEMPLATE.md是复杂任务的计划协议。模板要求计划写真实实现，而不是只写“开发、测试、回写”。

后端任务尤其要写清：

• 真实入口

• 输入从哪里来

• 核心对象是什么

• 哪些模块负责什么

• 失败时如何停止和恢复

• 如何验证和回写

如果团队同时使用Superpowers这类技能化工作流，可以把它看成harness的执行层补充。

harness与Superpowers的分工：

• harness：负责项目入口、计划协议、验证入口、项目约束和结果回写。

• Superpowers：负责写计划、测试驱动、系统化调试、代码评审和完成前验证。

两者不应该变成两套互相竞争的规则，而应该按同一条链路配合。

4.2 初始化后的使用方式

1.先从AGENTS.md、docs/harness/ 和plan里读取项目依据。

2.再按技能化工作流完成实现与验证。

3.最后把结果写回任务系统、PR/MR 或仓库文档。

初始化之后，推荐的使用方式也可以很简单：

1.先读AGENTS.md，找到项目入口和验证命令。

2.复杂任务不要直接开改，先按 .agent/PLANS.md 写计划，冻结本轮范围、非目标和验收方式。

3.在计划里写清真实实现链路，不用harness流程图替代业务实现图。

4.执行时按计划推进，遇到范围变化先更新计划，而不是顺手扩大任务。

5.收口前执行项目验证命令、harness检查和review gate，把结果同步回任务系统、PR/MR或仓库文档。

结果是，agent的工作不再只是一次对话里的产出，而是进入了项目自己的记录、检查和验证体系。

实践篇：前端、后端与工具分层

5.1 前端三层：设计、状态、实现

前端最容易把Harness Engineering的价值看清楚，因为页面交付天然就分层。至少有三层需要分别接住：

• 执行依据层

• 状态暴露层

• 交付实现层

前端协作效率，很多时候就取决于这三层有没有先后站稳。

前端从设计结构，到状态暴露，再到真实页面接入的三段式路径。

如果没有执行依据层，agent和工程师虽然都能开始写，但实现会持续漂移。大家面对的不是同一组约束，而只是同一句需求描述。

Storybook的价值不在于替代设计稿，而在于把运行状态显式摆出来，让评审和回归围绕现成页面行为展开。状态如果只留在设计稿或个人脑海里，后续讨论就会越来越依赖记忆，返工也会越来越随机。

当前两层已经提供稳定依据时，agent的位置才会变得清楚：它不是凭一句描述直接“生成页面”，而是在既定结构和既定状态之上补实现、补细节、补接线。

从harness的视角看，三类信息各有落点：

复杂页面任务在进入实现前，计划文件至少应该回答这些问题：

• 本轮页面范围是什么，是否包含弹窗、抽屉、批量操作、详情页或二级页面？

• 需要覆盖哪些状态，哪些状态只做占位，哪些状态本轮不做？

• 组件层级是否已经从设计结构里固定，还是允许在实现中调整？

• Storybook里要暴露哪些story，评审时看哪些入口？

• 真实页面接入哪些路由、权限、接口和埋点？

• 如果接口还没准备好，mock数据、字段假设和后续替换位置在哪里？

前端场景的关键点：设计不要只冻结“长相”，还要冻结状态。状态不要只存在于设计稿里，还要进入可运行环境。agent不应该凭一句描述生成页面，而应该在结构和状态都明确后补实现。

这也是为什么前端场景里最直接的变化通常不是“生成速度更快”，而是返工更少。结构先冻结，状态先暴露，agent、工程师和评审围绕的是同一组对象，而不是各自理解的预期。

6.1 后端三层：依据、验证、实现

后端表面上没有Pencil和Storybook，但协作链路并没有因此变短，只是把对应的位置换成了另一组工件。让事情稳定下来的，往往是先把执行依据、验证口径和失败边界说清楚。

后端也可以对应拆成三层：

很多任务之所以反复，并不是因为代码太难，而是因为执行语义没有冻结。运行模式、输入输出、异常口径、非目标范围、回滚方式没有提前写清，agent的产出就很容易停在“看起来可以跑”，却还进不了交付。

后端任务中，docs、plan、terminal、logs、repo和review共同组成验证反馈循环。

更稳的做法，是先在任务系统里明确范围和责任，在仓库文档里补齐接口与设计说明，在计划工件里写清。

更稳的做法，是先在任务系统里明确范围和责任，在仓库文档里补齐接口与设计说明，在计划工件里写清Scope、Non-Goals、Validation、Rollback，然后再让agent进入实现与测试。

例如，一个同步工具类任务，如果只写“实现同步功能”，agent只能猜运行入口、配置来源、错误处理、重试方式和验证命令。更好的计划应该回答几个问题：

• 入口命令是什么，谁会触发它？

• 输入来自配置、参数、文件、API 还是消息？

• 核心对象在哪里装配，哪些字段必须校验？

• service、repository、gateway或adapter各自负责什么？

• 失败时是重试、跳过、停止还是回滚？

• 成功与失败分别用什么命令或runbook验证？

• 结果要写回哪里？

后端任务尤其需要把“完成”的判断拆开。因为很多后端能力不是页面上马上能看到的，它可能是一条命令、一个定时任务、一个消费链路、一个API、一个数据同步过程，或者一组配置驱动的行为。

后端场景的关键点：先写清入口、输入、边界和失败策略。验证不要只写单测，要覆盖链路和失败场景。结果要能被后来的人复用。

所以对后端来说，关键不在于把实现动作再往前提，而在于把验证动作更早放进任务设计里。很多链路型任务真正决定能不能进入交付的，并不是“有没有代码”，而是“有没有一组团队共同认可的验证条件”。

7.1 工具可替换，职责位置要稳定

前面两节分别用了前端和后端场景说明同一件事：工具名可以不同，但协作链里的位置其实高度相似。我们真正需要稳定下来的，不是某个固定产品组合，而是研发协作中的职责分层。

工具可以替换，但职责分层、架构边界和跨层约束不能缺位。来源：OpenAI Harness Engineering。

可以把常见工具放回同一条链路里看。

把Pencil、Storybook、Linear、Codex、Cursor、Claude Code放在同一段里讨论，很容易把问题带偏成工具选型。但从工程视角看，这里真正重要的不是产品，而是每一层承担什么职责。

Harness Engineering要做的，就是把这些职责拆开、接稳，并让agent在自己应该工作的层面上发挥作用。工具完全可以替换，但任务编排、依据冻结、状态暴露、执行入口、验证反馈、评审收口这些位置不能长期缺位。

这也是为什么同一套方法可以同时适配Cursor、Codex、Claude Code或其他 agent工具：

• 工具负责执行能力。

• harness负责工程条件。

• 任务入口、计划协议、验证入口和回写位置稳定后，工具替换带来的迁移成本会小很多。

• 如果所有规则都绑在某个工具的私有prompt里，工具一换，团队就要重新整理协作方式。

落地篇：从轻量harness到适用边界

8.1 从最小harness开始

很多团队看到这里，第一反应可能是：这套东西是不是太完整了，落地成本会不会很高。

实际上，如果只是想从“个人会用agent”走到“团队能稳定协作”，起步不一定复杂。先把最容易反复出问题的几个位置固定下来就够了。

轻量harness模板先解决的就是这些基础问题。团队不需要一开始就建设完整平台，可以先把任务入口、计划协议、项目约束、验证入口和结果记录固定下来。只要这些位置稳定，agent协作就会比只靠临时prompt更可控。

后续再逐步补：

• 项目级linter

• contract diff

• E2E（End-to-End，端到端验证：从任务入口、计划协议、执行过程、验证入口到结果记录的完整链路检查，确认协作流程整体可跑通。）

• 外部系统readback

• 维护扫描

• 规则升级

顺序可以慢慢来，但方向应该清楚：把反复依赖人的判断，逐步写回到项目规则和检查入口里。

一个更稳妥的落地顺序可以分成三个阶段：

阶段 1：让agent找得到入口

先补AGENTS.md、验证命令和复杂任务计划模板，让agent进入项目后能快速找到任务入口、项目边界和验证方式。

阶段 2：让任务能被复盘和复用

固定plan、runbook、验证摘要和PR/MR回写格式，让一次任务结束后的结论能被后来的人继续使用。

阶段 3：让重复问题逐步机械化

登记项目约束，把高频review问题升级成lint、script、test或CI，减少同类问题反复依赖人工提醒。

这三个阶段不要求一次完成。更实际的做法，是先选一两个真实项目试运行：

• 前端可以从一个复杂页面或组件库开始。

• 后端可以从一个链路型工具或集成任务开始。

• 每次任务结束后，都补一次计划、验证和回写。

harness会逐步从模板变成项目自己的工作方式。

9.1 判断边界：轻量还是完整

Harness Engineering不是要求所有事情都走一遍完整流程。

适合轻量处理：任务影响面小、验证方式直接明确，不需要完整harness流程。

• 一次性实验、纯脑暴、小范围草稿。

• 非核心逻辑的小修小补。

• 只影响单个小文件，且验证方式直接明确。

适合启用harness：任务会影响交付、协作或后续复用，需要提前固定依据、边界和验证。

• 有明确交付目标的页面或组件开发。

• 有接口、数据结构、测试或验证要求的后端任务。

• 涉及多个模块、多个状态、接口契约、数据迁移、权限边界或外部系统。

• 需要多人协作和评审，或希望把经验写回仓库和任务系统。

仍然需要人判断：让信息进入系统，不意味着人可以退出判断。

• 需求澄清、架构取舍、业务优先级。

• 风险判断、权限边界、安全策略。

• 同类问题是否进入项目约束登记，验证结果是否写入runbook或PR/MR。

• 后续需要交接、复盘或继续迭代时，关键决策应同步回任务系统或仓库文档。

这个边界很重要。Harness Engineering的目标不是把所有研发动作流程化，而是把高风险、高协作成本、高复用价值的部分系统化。越是短平快的事情，越应该保留轻量路径；越是会影响后续交付的事情，越应该提前准备依据、边界和验证。

附：辅助初始化Prompt

下面这段可以直接复制给agent，平时不需要逐字阅读。

你是我的研发协作 agent。我会提供一个 harness 模板压缩包，以及一个目标项目路径。
请按两个阶段工作。
阶段 1：只解读，不修改文件。
1. 解压或读取 harness 模板包，说明模板包中的核心目录和文件职责。
2. 读取目标项目的现有结构，包括 README、AGENTS.md、Makefile、package.json、go.mod、pyproject.toml、docs、scripts、CI 配置等实际存在的入口。
3. 判断目标项目适合初始化哪些 harness 内容：入口地图、控制面文档、计划协议、测试 runbook、项目约束登记、agent prompts/guides、脚本检查入口等。
4. 输出初始化方案，必须包含：
   - 准备新增的文件
   - 准备修改的文件
   - 明确不覆盖或需要保留的文件
   - 需要从目标项目实际情况推导的内容
   - 初始化后的验证命令
   - 可能的副作用和回滚方式
5. 在我确认之前，不要修改目标项目。
阶段 2：确认后再执行初始化。
1. 按确认后的方案初始化 harness 文件。
2. 保留目标项目已有的工程结构、构建方式、测试命令和团队约定，不要把模板内容机械覆盖到项目上。
3. 如果发现模板假设和项目实际情况冲突，先停下来说明冲突，不要自行扩大修改范围。
4. 初始化完成后，运行可用的验证命令，并给出结果摘要。
5. 最后输出一份初始化报告，包括已创建/修改文件、验证结果、尚未机械化的项目约束、后续建议。

最后：prompt解决的是这一轮怎么说清楚，harness解决的是项目里如何持续做对。agent的可靠性不只来自模型能力，也来自任务入口、执行依据、验证反馈和结果记录是否提前准备好。

结语：让AI进入可验证的研发协作

我们讨论AI编程，最容易被放大的往往是模型能力：会不会写、写得快不快、答案漂不漂亮。但回到研发现场，很多问题最后还是落在几件具体的事上：

• 任务依据是否完整

• 边界条件是否清楚

• 验证方式是否提前准备好

• 结果有没有被记录下来

回到研发现场看，Harness Engineering做的其实是几件具体的事：

• 任务别只留在聊天里。

• 边界别只靠人记。

• 验证别只停在本机。

• 结果别只存在这一轮对话里。

它一方面把任务入口、执行依据和验证反馈接稳，另一方面把协作链里的职责分清。做好这些之后，agent才不会只是一个偶尔帮忙的生成工具，而会慢慢变成研发链路中一个更可靠的执行者。

AI可以加快生成，但稳定交付仍然依赖清晰的依据、边界、验证和记录。

当这些工程条件提前准备好，agent带来的就不只是速度，而是更少的返工、更清楚的协作界面，以及能留在项目里的经验。

从Prompt Engineering走向Harness Engineering，重点也就在这里：不只追求这一轮让模型回答得更好，而是让项目本身具备一套能支持agent反复接手、验证和回写的工作方式。

内存峰值降60%+，动图加载快75%：爱奇艺图片库一次从'能用'到'极致'的跨越

零侵入、低成本！轻松为老系统注入 AI 灵魂

治愈 Cursor AI 编程的 “幻觉”？用它就够了！

速看如何跑赢碎片化时代的流量竞速

在爱奇艺做研发，用AI写代码是什么体验？

跳转微信打开

基于华为最新仓颉编程语言，实现鸿蒙生态图片高效加载的完整实践解析

随着HarmonyOS NEXT的正式发布，越来越多的应用开始拥抱鸿蒙原生开发。作为国内领先的视频平台，爱奇艺也在积极布局鸿蒙生态，致力于为用户带来更流畅、更优质的观影体验。

在移动应用场景中，图片加载是影响用户体验的关键环节。海报、焦点图、活动图、角标……这些看似普通的图片资源，却承载着用户的第一印象。如何在鸿蒙平台上实现极致的图片加载体验，成为爱奇艺技术团队面临的重要课题。

本文将分享爱奇艺在鸿蒙原生应用开发中的技术实践——基于仓颉语言自研高性能图片库的全过程，包括技术选型思考、架构设计、性能优化以及实践成果。

2.1 ArkTS的性能瓶颈：

在鸿蒙应用开发中，ArkTS是官方推荐的主要开发语言。然而在实际开发过程中，我们发现ArkTS在处理图片密集型任务时存在一些性能瓶颈：

单线程语言模型的局限：ArkTS基于单线程事件循环模型，当遇到复杂的图片解码、处理任务时，容易造成主线程阻塞，引发UI卡顿。特别是在列表滑动、快速翻页等场景下，用户体验受到影响。

多线程使用成本高：虽然ArkTS支持Worker和TaskPool实现多线程，但开发者需要手动处理内存隔离、线程间通信、参数序列化等问题。Worker数量和TaskPool执行时间受限，需要根据任务类型进行权衡，开发和维护成本较高。

2.2 AVIF格式的迫切需求：

爱奇艺作为视频平台，对带宽和存储成本高度敏感。为了在保证画质的同时降低传输成本，爱奇艺线上图片资源已广泛采用AVIF格式。

AVIF是由开放媒体联盟推出的新一代图片格式，相比传统格式具有显著优势：

• 更高压缩效率：在相同视觉质量下，AVIF 相比 JPEG 通常可减少约 40–50% 的文件体积，相比 WebP 也可进一步降低约 20–30%，显著节省带宽与存储空间。

• 更丰富的图像质量能力：支持 10-bit / 12-bit 色深、4:4:4 色度采样及更好的渐变过渡，减少色带和压缩伪影，在复杂纹理和渐变场景下表现更稳定。

• HDR 与现代特性支持：原生支持 HDR、广色域（如 BT.2020）、透明通道（Alpha）以及动画帧，适合高质量图片与新一代显示设备。

然而，当前鸿蒙系统自带的Image组件尚未支持AVIF格式，这成为爱奇艺鸿蒙原生应用开发的一大痛点。如何在鸿蒙端实现高效稳定的AVIF加载，成为亟待解决的核心诉求。

2.3 图片库密集型任务的特性：

图片库是典型的计算密集型+IO密集型应用，主要包含三类任务：

这些任务对语言的并发能力、内存管理、性能表现都提出了较高要求。

面对上述挑战，爱奇艺技术团队进行了深入的技术调研，最终选择了仓颉（Cangjie）语言作为图片库的核心开发语言。

3.1 仓颉语言简介：

仓颉是华为自研的面向全场景智能的新一代编程语言，专为鸿蒙生态打造。它融合了多种现代编程语言的优点，具备以下核心特性：

静态强类型与内存安全

仓颉采用静态类型系统，在编译期即可发现大部分类型错误，减少运行时异常。同时，仓颉内置内存安全机制，通过所有权和生命周期管理，有效避免内存泄漏、野指针等问题，让开发者更专注于业务逻辑。

高效并发模型

仓颉提供了用户态线程模型，轻量级执行实体拥有独立上下文，却能共享内存空间，兼顾隔离与高效。编译器与运行时系统对并发任务进行了专项优化，结合轻量线程和并发对象库，实现更佳的资源管理与调度效率。

跨语言互操作

仓颉语言提供了强大的跨语言互操作能力，支持与C语言和ArkTS的无缝集成。这意味着：

• 可以充分利用现有的C语言图片解码库（如libavif、libwebp等）

• 可以与ArkTS UI层进行双向通信

• 可以复用现有的鸿蒙UI组件和生命周期机制

平滑迁移

对于已有ArkTS代码的项目，仓颉支持渐进式迁移。开发者可以选择性能关键模块使用仓颉重写，保持其他模块不变，降低迁移风险和成本。

3.2 支持ArkUI组件：

仓颉可以直接支持和创建ArkUI组件，这意味着图片库可以无缝集成到鸿蒙的声明式UI框架中：

这种设计让业务层可以像使用普通组件一样使用仓颉图片库，无需关心底层实现细节。

4.1 整体架构：

爱奇艺仓颉图片库采用分层架构设计，核心组件包括：

4.2 仓颉/ArkTS混合架构：

为了兼顾开发效率和性能，我们采用了仓颉/ArkTS混合架构：

• ArkTS层：负责UI展示、生命周期管理、业务逻辑

• 仓颉层：负责图片加载、解码、缓存、任务调度等核心功能

• C语言层：复用成熟的编解码库（libavif、FFmpeg等）

这种架构的优势在于：

• UI层保持ArkTS开发效率，无需切换语言

• 核心性能模块使用仓颉，发挥语言性能优势

• 复用成熟C库，避免重复造轮子

4.3 图片处理流程：

图片库采用「缓存优先、网络兜底」的三级缓存策略（内存LruCache → 磁盘缓存 → 网络请求），结合静态图与动图的差异化解码方案。加载流程从主线程 loadImage 通过 spawn 触发异步任务，经缓存层快速响应后进入解码处理：静态图直接解码为单帧 PixelMap，动图经 avif 解码和帧管理后输出多帧 PixelMap 序列，最终所有图片统一转换为PixelMap 格式，通过 launch 机制触发 ArkUI Image 组件渲染展示。这种分层设计让 UI 层无需关心图片来源，兼顾开发效率与极致性能。

4.4 动图解码优化：

动图解码是图片库的技术难点之一，我们针对仓颉语言特性进行了专项优化：

帧级锁机制：

• 按帧串行处理，确保帧顺序，防止画面错乱

• 使用仓颉的并发原语实现高效的锁机制

同步机制：

• 保证解码后的帧数据正确及时传递至渲染线程

• 平衡解码速度与渲染帧率，避免内存堆积

任务队列管理：

• 高效调度多个解码任务，避免线程阻塞

• 支持动图优先级管理，优先保证可见区域动图流畅播放

5.1 关键优化点：

互操作回调优化

通过互操作回调实现ArkTS生命周期事件与仓颉端的衔接，如aboutToReuse、aboutToRecycle等。在组件复用和回收时，及时释放仓颉侧资源，避免内存泄漏。

内存复制优化

基于memcpy高效完成C侧解析buffer的内存复制与传递。减少不必要的数据拷贝，降低内存带宽压力。

标准库优化

利用仓颉标准库优化网络请求与文件操作性能：

• 使用仓颉异步I/O接口，提升并发处理能力

• 复用连接池，减少TCP握手开销

• 批量读写磁盘，减少系统调用次数

线程调度优化

减少不必要的线程切换，内存缓存等轻量场景直接在主线程完成处理。仅在真正需要异步执行的任务（如网络请求、图片解码）才使用后台线程。

5.2 内存优化成果：

通过仓颉的内存管理优势，我们在内存占用方面取得了显著优化：

• 内存峰值降低60%+：相比纯ArkTS方案，仓颉图片库的内存峰值大幅降低

• 更稳定的内存曲线：避免GC抖动带来的性能波动

• 更可控的资源释放：利用所有权机制，确保资源及时释放

6.1 性能提升：

我们使用12张不同类型图片进行加载耗时对比测试（单位：毫秒）：

核心结论：

• 整体加载耗时显著降低，特别是网络动图场景优化幅度达75%

• 自定义程度提升，可针对业务场景进行深度优化

• 编码耗时分布更均衡，避免单一任务阻塞

6.2 用户体验提升：

在实际产品场景中，仓颉图片库带来了明显的用户体验提升：

• 首屏加载速度提升：首页海报加载更快，用户进入即可看到内容

• 列表滑动更流畅：长列表滑动时图片加载无卡顿

• 动图播放更顺滑：动图帧率稳定，无掉帧现象

• 内存占用降低：应用运行更稳定，减少OOM风险

仓颉图片库的建设是一个持续演进的过程，我们规划了以下发展方向：

7.1 功能补齐：

借助仓颉语言的高性能与并发特性，持续完善图片库能力：

• 更多格式支持：更多图片格式解码支持

• 更丰富的图片处理：滤镜、水印、智能裁剪等

• 内存优化：更精细的缓存策略，支持图片预加载与智能回收

7.2 跨平台拓展：

利用仓颉的跨平台优势，将图片库能力拓展至更多终端与平台：

• 多端复用：一套代码，支持鸿蒙手机、平板、车机、TV等多终端

• 跨平台支持：探索仓颉在其他平台的应用可能性

• 一次开发，多端复用：降低多平台维护成本

7.3 生态共建：

我们希望将仓颉图片库的实践经验回馈社区：

• 开源计划：逐步开源核心模块，与社区共建

• 最佳实践分享：通过技术文章、演讲等形式分享经验

• 仓颉生态共建：与仓颉技术团队深度合作，推动语言生态发展

仓颉图片库的建设是爱奇艺在鸿蒙生态探索中的一个缩影。从最初的技术调研，到架构设计，再到性能优化，每一步都凝聚着团队的心血。

在这个过程中，我们深刻体会到仓颉语言在系统级应用开发中的优势：

• 内存安全让开发更省心

• 高效并发让性能更出色

• 跨语言互操作让生态更开放

我们相信，随着仓颉语言的不断成熟和鸿蒙生态的持续发展，会有越来越多的开发者加入到这个生态中来。爱奇艺也将继续深耕鸿蒙平台，为用户带来更优质的视听体验。

特别感谢仓颉技术团队在项目过程中提供的支持！

也许你还想看

零侵入、低成本！轻松为老系统注入 AI 灵魂

治愈 Cursor AI 编程的 “幻觉”？用它就够了！

速看如何跑赢碎片化时代的流量竞速

在爱奇艺做研发，用AI写代码是什么体验？

创新高！ 2025年爱奇艺申请发明专利880件 过半是AI相关专利

跳转微信打开

Tenon Agent破局老系统“AI 化”难题，助力构建智能生态

大模型浪潮席卷而来，如今各团队都在思考以下问题：

“如何让我们的系统也拥有一个聪明的专属 AI 助手？

我们系统的哪些流程可以让AI来做？

我们该如何启动、有序转型？”

但理想很丰满，现实往往很骨感。当我们把目光投向现有的业务系统时，往往会面临以下几个问题：

• 前端历史包袱重：公司内部沉淀了大量的历史业务系统，前端生态非常复杂，涵盖了 Vue2、老旧的 React，甚至还有古董级的 JSP，现代 AI 对话库很难兼容。

• 后端接入成本高：AI绝不能只是个“闲聊机器人”，它必须能长出“手脚”去调用真实的业务接口（查数据、做操作）才能产生商业价值。但在传统接入模式下，为了给AI 挂载一个简单的业务工具，开发人员不得不从零手动搭建复杂的后端 Agent 工作流（Workflow），深陷于繁琐的意图解析、上下文记忆管理、以及前后端状态流转的“脏活累活”中，联调成本极高。

• 能力沦为“AI 孤岛”，优质工作流无法复用：各个业务线辛辛苦苦调优的提示词（Prompt）、封装好的优质工具接口、沉淀下来的复杂业务工作流，往往只被困在自己的系统里。客服 Agent 调不到运维的接口，财务Agent 查不了HR 的数据。“烟囱式”的AI 开发不仅让各团队在重复造轮子，更让未来系统间的“多智能体协同”沦为空谈。

基于上述痛点，海外技术团队开发上线了 Tenon Agent 解决方案，目前已在内部顺利落地了 10 余个业务项目。Tenon Agent 的核心解法可以概括为三步：

• 前端接入层：提供一套零侵入的JS 包，兼容各种前端框架，让老旧项目能以极低的成本无缝挂载大模型能力。

• 后端基座层：提供统一的Langgraph Agent框架，把繁琐的大模型交互、状态流转和记忆管理标准化，做到开箱即用。

• 能力生态层：提供公共的Skills Hub，结合奇智的MCP市场，将分散的能力逐步沉淀为全公司可复用的通用Skills 生态。

3.1 入口层 (多端触达)：

作为触达用户的最前线，支持多种形态的业务终端接入。

• Web 业务系统前端：无缝嵌入公司各类存量、新建的Web业务系统。

• 飞书端：深度集成飞书机器人，满足内部高频的办公/运维查询诉求。

• 未来扩展：架构预留了IQAgentPortal 统一门户以及A2A（Agent to Agent 智能体间通信）等其他入口接入能力。

3.2 接入层 (极简集成)：

提供零侵入的通用JS SDK与专用模块。无论老系统使用何种前端框架，均可以极低成本快速挂载AI 助手。

3.3 协议层 (交互标准)：

采用轻量级的AG-UI开源协议，AG-UI 全称Agent-User Interaction Protocol（智能体 - 用户交互协议），是由 CopilotKit 团队于 2025 年 5 月推出的开源、轻量级、事件驱动的开放协议标准，核心作用是标准化 AI 智能体（Agent）与前端用户应用之间的通信与交互流程，填补了智能体生态中「Agent - 用户端」交互的协议空白。

3.4 应用层 (管理与生态)：

管理后台： 提供可视化的Agent配置、权限管控（鉴权）、会话管理与安全审计。

Skills Hub： 打破“AI 孤岛”，将各业务线的优质工具接口沉淀为全公司可复用的公共技能市场。

3.5 编排层 (AI 大脑)：

基于通用的LangGraph运行时打造，替代繁琐的人工硬编码，全自动处理大模型的意图路由、复杂对话的状态与记忆管理，以及工具调用执行。

3.6 LLM 层 (底层基座)：

依托公司内部的奇智平台，统一接入大语言模型算力、企业级知识库，以及标准化的MCP工具市场。

传统接入方式

4.1 创建应用获取凭证

Tenon Agent有一个管理后台，只需要在平台创建Agent并绑定需要的飞书知识库、MCP和Skills，Agent即刻拥有你填写的这些能力。

4.2 后端保存凭证获取token

出于安全考虑，AK/SK必须保存在后端，由后端向Tenon Agent平台请求临时 Token给前端使用，严禁将AK/SK直接暴露在前端代码中。

4.3 前端引入JS

需两行代码，即可在任意古董级系统页面右下角悬浮生成一个专属的 AI 侧边栏/对话框，实现真正的零侵入。

通过Skills接入

为了方便使用Vibe Coding的方式接入Tenon Agent，我们还提供了接入Skills，将Skills下载到本地导入Cursor或Claude Code即可一句话接入。

5.1 跨系统排障场景

以前互动营销的营销位匹配排障，往往需要多人、多系统串联协作：开发A登录互动营销平台查策略详情，再去Kibana拉日志；根据访问日志模拟用户请求，才能拿到漏斗/过滤步骤信息。多数问题最终落在圈人条件不匹配，开发B还需要在策略引擎的标签侧按标签来源继续追踪，把问题转给BI、脸谱等标签系统接力排查，整体流程耗时且沟通成本高。

接入Tenon Agent 后，运营只要在对话里提一句「帮我查一下 uid=333333333这个用户为什么看不到 id=3082 的策略」，Agent就会自动触发策略匹配定位的排障 skill：按skill 里定义的标准流程，调用各系统提供的工具能力完成查询、模拟与过滤分析，并在必要时直接跳转到策略编辑页定位配置。最终在约1分钟内把关键结论与下一步可操作的调整方向汇总出来，将原本分散在“查平台—翻日志—模拟请求—跨团队追踪标签”的排障链路，收敛为一次对话即可完成的闭环。

收益：排障时间从原本的 30分钟 缩短至 2分钟。

5.2 多语言词条自动配置

在老旧的后台系统中配置多语言词条往往是一项枯燥且繁琐的“体力活”。研发或运营人员需要经历：查找对应的菜单入口-> 打开新增表单 -> 手动规范输入 Key 值 -> 分别切换并填入中文、英文等多语种翻译-> 点击保存。步骤繁杂、页面跳转多，遇到大批量新增时，极易产生机械性疲劳和漏填、错填的问题，新员工上手也需要记忆菜单路径。

接入 Agent 后，复杂的表单填写被彻底简化为“一句话指令”。用户只需在侧边栏用自然语言输入，例如：「增加多语言key:test_movie，中文翻译：电影」。
Agent 会自动解析这句话的意图，精准提取出Key 值和文本内容，并自动调用相关的Skill 组件。它不仅能自动识别并跳转到对应的配置页面，还能接管原生页面表单，将提取到的字段准确无误地填入对应位置（甚至可以结合大模型能力自动补全英文翻译等缺失语种），实现“所说即所得”。

收益：将原本需要多次点击、跨页面查找的十几步操作，缩短为 1 次对话，单次配置效率提升 80% 以上。

5.3 将飞书文档集成知识库 

轻松两步即可将飞书文档变为Agent知识库:

第一步：将飞书文档加入Tenon Agent飞书机器人阅读权限。

第二步：将飞书文档地址填入Tenon Agent系统。

Tenon Agent的愿景不仅仅是为老系统增加一个“聊天框”，而是以此为契机，推动公司内部历史业务系统的“AI 化改造”。随着越来越多系统的接入，我们将按以下三个阶段逐步构建起完善的智能体生态：

6.1 沉淀系统元知识，编撰“给 AI 看的系统说明书”

在帮助前端集成Agent的过程中，我们会引导各业务线系统性地梳理和总结现有的运维文档、操作手册，并将其转化为高质量的系统提示词。这些沉淀下来的知识，相当于为每一个历史包袱沉重的老系统，量身定制了一份“机器可读的系统说明书”，让大模型能够深度理解各个老系统的业务边界与底层逻辑。

6.2 操作能力资产化，共建标准化的 MCP 与 Skills 市场

在接入的过程中，对于老系统中的高频业务操作，不断抽象并封装成标准化的公共Skills和MCP。这种“公共格式”的统一，意味着不同系统之间不仅打破了数据孤岛，更打破了“能力孤岛”。A 系统沉淀的“账号解封”能力，B 系统的Agent 也能通过权限一键调用，最终形成公司级的 “AI 业务能力大市场”。

6.3 面向未来演进，无缝对接前沿的 AI 自动化生态

AI 领域的发展日新月异。正是因为我们在当前阶段提前做好了“系统认知标准化（AI说明书）”与“操作能力标准化（MCP/Skills）”，我们的老系统在未来将具备极强的扩展性。当行业内涌现出更强大的自主智能体框架（如OpenClaw、OpenDevin 等全自动AI工具）时，我们的系统无需进行底层的二次重构，即可实现“即插即用”。

总结而言：“Tenon”一词意为榫卯，寓意着让每一个历史包袱沉重的业务系统，都能像精妙的传统榫卯结构一样，无缝且牢固地嵌合进公司的 AI 大生态中。Tenon Agent 提供的是一张通往未来的“船票”。通过简单的接入与资产沉淀，我们让那些沉睡的老系统不仅能在今天拥有专属的 AI 助手，更能以极低的成本拥抱明天更加广阔的 AGI 生态。

目前 Tenon Agent 已在团队内部广泛应用并持续演进。未来我们将探索其与更多前沿 AGI 生态的结合。欢迎在评论区交流你们在老系统 AI 化改造中的经验与痛点！

也许你还想看

治愈 Cursor AI 编程的 “幻觉”？用它就够了！

速看如何跑赢碎片化时代的流量竞速

在爱奇艺做研发，用AI写代码是什么体验？

从Kafka到AutoMQ：爱奇艺实时流数据架构演进

让AI编程的价值可追踪、可量化--「AI编程效能量化系统」

跳转微信打开

天玑前端自研规格驱动 AI 开发流程 Specflow，实现流程标准化与提效。

在过去一年的 AI Coding 实践中，天玑前端团队经历了一个明显的瓶颈期。

早期我们沉浸在 Vibe Coding（氛围编码）的快感中——通过简单的对话、截图，AI 确实能飞快地生成页面。但随着需求进入深水区，这种模式的弊端开始显现：由于缺乏标准化约束，AI 生成的逻辑往往是“碎片化”的。面对中后台复杂的表单联动、嵌套的数据转换，AI 经常在多轮对话后开始“左右互搏”，导致开发者不得不陷入反复纠错的泥潭。

我们意识到，AI 效率的波动，本质上是上下文断层和需求共识缺失导致的。

随着业界向 Spec-Driven Development (SDD) 演进，大家开始达成共识：AI 不缺代码实现能力，缺的是精准的“指令规格”。我们需要一套流程，能把模糊的需求拆解成机器可理解的“契约”，并让 AI 在每个阶段扮演特定的专家角色（如架构师、测试员），以此来对冲个体经验带来的不确定性。

在构建我们自己的标准流之前，我们深入拆解了目前业界主流的三种规格驱动方案。它们代表了对“复杂任务拆解”的三种不同理解：

OpenSpec：“轻量级、面向变更的敏捷利器”

核心点：它非常推崇“原子化变更”。通过 Proposal（提案）和 Apply（实施）的闭环，把大的功能拆解成小的变更包。

GitHub Spec Kit：“工业级、标准化的协作协议”

核心点：极其强调“先写规格，再写任务”。它通过 Constitution（宪章）定义技术底线，确保 AI 生成的代码风格不走样。

启发：它给我们的启示是“门控”。如果需求阶段（Specify）没对齐，后续的编码（Implement）就是南辕北辙。

BMAD-METHOD：“全能型、多代理协作的工程框架”

核心点：它不再把 AI 当成一个简单的助手，而是模拟一个完整的专家团（PM、架构师、QA）。

启发：在复杂场景下，必须引入“角色思维隔离”。让 Plan 阶段像架构师一样思考，而不是一边写设计文档一边就想写代码。

为什么我们决定“集百家之长”？

调研完这些工具后，我们发现它们在 Cursor 等现代 IDE 中依然存在一些“摩擦力”：

• 心智负担重：有些流程需要开发者频繁切换文件、手动同步状态。

• 状态易丢失：在多轮对话中，AI 容易忘记最初在 spec.md 里定下的技术方案。

因此，我们决定吸收 OpenSpec 的轻量、Spec Kit 的严谨和 BMAD 的多角色思维，自研一套深度适配 Cursor 的AI研发流（Agentic Workflow）——Specflow。

方案设计：重塑 AI 研发的“流水线”

三种工具各有所长，为了满足自身业务需要，决定不采用任何社区方案，集各家所长建设适用于当前团队的 规格驱动开发（Spec-Driven Development, SDD）方案——Specflow。

整体架构

我们将这套方案的设计哲学归纳为以下四个维度：

全链路流程闭环：从“模糊”到“可交付”

不同于只关注编码的工具，Specflow 强制要求在进入代码阶段前完成深度的“需求对齐”。

• 问题澄清（Specify）：在产品文档确认后，AI 会优先识别逻辑漏洞和边界盲区，通过“问题澄清”环节强制补全细节，产出完善的业务规格书。

• 技术建模（Plan）：将业务规格映射为技术路径，包含接口定义与任务拆解，确保每一行代码都有据可查。

• 原子化实现（Implement）：基于任务组进行分步开发，并引入“人机协同”的断点 Review 机制。

严格的物理门控：拒绝“带病”进入开发

这是 Specflow 区别于社区方案的核心纪律。

• 逻辑阻断：我们引入了硬性门控（Blocker Gate）机制。如果 Specify 阶段的细节未澄清，或者 Plan 文档中的技术风险（Block 项）未被回答，流程将强制停顿。

• 确定性保障：这种设计迫使开发者“先想清楚，再写清楚”，严禁跳过设计直接编码，从而在根源上消灭了因理解偏差导致的无效重工。

单指令状态机：0 心智负担的“自动寻迹”

为了不让复杂的流程变成开发者的负担，我们实现了单指令入口（One Main Command）。

• 物理寻迹：开发者只需输入万能指令 /specflow。

• 自动识阶：系统会智能检索本地磁盘文件的状态（如 plan.md 的完成度），自动判定当前处于 PM、架构师还是开发者模式，实现研发进度的数字化自动追踪，无需手动切换工具。

SSOT 与角色思维隔离

SSOT 单文档策略：坚持 Single Source of Truth，将功能拆解、方案与任务状态集中在 plan.md 中。这让 AI 在编码时无需跨文件检索，向上滚动即可回溯初衷，大幅提升了上下文一致性并降低了 Token 损耗。

多 Agent 协作：通过特定 Prompt 为每个阶段分配专家角色（PM、TL、Dev、Admin），实现内生的“审计与校准”，确保产出质量不受个体经验偏差的影响。

概述

Specflow是一套由 AI 驱动的结构化开发流程，通过 自动探测 机制，根据ai-docs/ 目录下的文件状态，精准切换工作模式。通过Specify - Plan - Implement - Achieve四个阶段确保了需求不失真、设计不跑偏、编码可追踪、经验可沉淀。

[specflow] AI 辅助编码标准流程工作流

核心工作流 (Standard Workflow)

[Specify] 需求分析阶段

• 指令: /specflow-specify

• 职责: 严谨的资深产品经理，定义“做什么”和“为什么”。

• 核心动作: 扫描代码库提取业务规则，识别逻辑真空。

• 产物: ai-docs/{ID}/specify.md。

[Plan] 架构规划阶段

• 指令: /specflow-plan

• 职责: 架构师兼技术负责人，将业务规格映射为技术路径。

• 核心动作: 制定 [F-xx] 功能契约与 Phase 3 执行路径。

• 产物: ai-docs/{ID}/plan.md。

[Implement] 编码实现阶段

• 指令: /specflow-implement

• 职责: 严谨的软件工程师，原子化编码与实时同步进度。

• 核心动作: 按照 Group 顺序执行任务，回写标准化 Log 存证。

• 断点机制: 每个 Group 完成后强制停顿，展示 Diff 并等待授权。

[Archive] 知识归档阶段

• 指令: /specflow-archive

• 职责: 知识管理员，执行“知识脱水”与资产精细化归档。

• 核心动作: 自动映射年/季路径，更新全局索引 ARCHIVE_SUMMARY.md。

• 产物: ai-docs/{ID}/summary.md。

Specflow 是一款专为 Cursor IDE 定制的研发效能工具，通过集成常用的 Commands 与 Templates，助力开发者实现标准化开发流程。

前置要求

• IDE: 仅支持 Cursor。

• Node.js: >=18.0.0，需要 node 环境支持。

• Cursor rules：保证生成代码符合项目规范。

核心指南

• 流程标准化 (Standardization)：Specflow 的核心职责是规范 AI 的实施路径。通过统一的命令与模板，它消除了开发者与 AI 协同中的随机性，确保每一项产物的规格、路径和结构高度一致，实现研发流程的“拉齐”。

• 质量约束力(Quality Control)：Specflow 定义“如何做”，而Cursor Rules 定义“做得好不好”。代码质量是否符合项目特定的规范、架构模式及最佳实践，完全取决于规则的完善程度。它是 AI 编码时的“交通规则”。

• 业务感知进化 (Evolution)：AI 对业务背景的理解是一个动态增长的过程。

• 初期：依赖 Cursor 对代码库的静态索引。

• 长期：随着需求归档 (Requirements Archiving) 的增加，这些结构化的归档文件将成为 AI 的“经验值”。归档越多，AI 对复杂业务逻辑的上下文理解就越深，从而实现从“辅助写码”到“理解意图”的质变。

安装与配置

第一步：安装命令行工具

通过爱奇艺私有镜像源安装全局 CLI 工具：

第二步：项目初始化

进入你的项目根目录执行初始化。该操作会将必要的配置（commands 和 templates）注入到项目的 .cursor 文件夹中。

注意：如果项目目录下已存在 .cursor 文件夹，初始化操作会直接覆盖其中的同名文件夹，请在执行前确认备份。

第三步：版本更新

当 Specflow 有新功能发布或模板更新时，运行以下命令同步最新内容：

核心功能概览

初始化完成后，你可以在 Cursor 中直接使用以下资源：

• Commands: 预定义的 AI 指令集，提升代码生成质量。

• Templates: 标准化代码模板，确保团队代码风格一致。

运行环境：请确保在 Cursor Chat (Agent Mode)中执行以下操作。

流程总览

Specflow 将研发流程分为四个核心阶段，通过 /specflow 指令驱动。

Step 1：需求规格化 (Specify)

目标：消除需求模糊性，将自然语言转换为 AI 可理解的开发规范。

• 执行指令：

• 关键动作：

• 上下文补充：如有 UI 设计图，建议作为附件上传，使用 AI将图转换为 HTML/CSS 结构效果会更好。

• 问题澄清：查看ai-docs/{{需求号}}/specify.md。

▪ 在[User]区域直接勾选选项或输入回答。

▪审查业务状态机、流转逻辑及验收标准。

• 流转：再次输入/specflow，校验澄清项。若全部完成，将自动触发Plan锚点。

Step 2：技术方案与任务拆分 (Plan)

目标：明确实现路径，拆解原子化开发任务。

• 前置输入：流程会停在交互锚点，请提供接口文档(API Docs)。

• 若无文档，回复“继续”跳过。

• 核心审查项 (plan.md)：

a.[Block] 问题：必须回答，否则无法进入开发。

b.[?] 问题：可选回答，不阻塞流程。

c.方案审查：确认实现思路与验收标准是否符合预期。

d.任务组 (Groups)：检查任务拆分是否有遗漏。

Step 3：原子化代码实现 (Implement)

目标：AI 自动编码、自检，并由人工进行阶段性 Review。

• 执行逻辑：

• AI 将按照 plan.md 中的 Group 顺序进行开发。每完成一个分组，流程会暂停。

• 开发者介入：

• Review：检查当前分组的代码质量与逻辑。

• 确认/继续：回复 继续 或再次输入 /specflow 启动下一个分组。

• 状态记录：AI 会实时更新任务标记并记录开发日志。

Step 4：需求归档 (Archive)

目标：沉淀技术债背景，建立逻辑对撞索引。

• 触发时机：提测完成、合并至 develop 分支前。

• 执行动作：

a.生成摘要：创建 summary.md，记录核心技术决策。

b.迁移文档：将 ai-docs/ 移动至 history/{{年份}}/{{季度}}/。

c.更新索引：更新全量的ARCHIVE_SUMMARY.md标签与索引。

• 安全机制：AI 会先进行 Dry-run（预览模式），确认无误后回复“确认”即可正式归档。

文档资产说明

Specflow 2.0：从“模拟流程”进化为“自治架构”

Subagents：深度角色隔离与上下文裁剪

• 角色原子化：将原有的资深产品经理、架构师等角色彻底解耦为独立的 Subagents，每个子代理仅加载其职能相关的指令集，避免角色重叠导致的逻辑干扰。

• 上下文精准注入：主代理根据当前阶段，仅向 Subagents 投喂必要的文档，通过裁剪非必要的历史推理，极大提升响应速度并降低长文本导致的“逻辑漂移”。

• 自主验证闭环：Subagents 拥有独立的“思考-验证”空间，在提交结果给主代理前，必须先在内部完成单测或静态检查。

Agent Skills：从“命令执行”到“意图自触发”

• 意图驱动流转：摒弃手动输入 /specflow。系统通过监控文件状态或对话意图自动触发对应的 Skills。

• 原子能力封装：将命令中的脚本片段（如 ID 锁定、季度归档、物理搬运）封装为标准化的 Agent Skills。

AI 辅助编码不该是单纯的“快”，而应该是“准”。

Specflow 的意义，就是把解决问题的战场从“编码调试期”强行推到了“需求设计期”。当设计稿和逻辑契约足够清晰时，写代码本身就成了一种极其廉价的体力活，可以放心地交给 AI。

我们正在告别那个“边写边修”的野蛮时代。未来的核心竞争力，不再是你写代码的速度，而是你定义需求、拆解任务和驾驭规范的能力。流程的确定性，才是我们对抗业务复杂性的唯一手段。

也许你还想看

在爱奇艺做研发，用AI写代码是什么体验？

创新高！ 2025年爱奇艺申请发明专利880件 过半是AI相关专利

速看如何跑赢碎片化时代的流量竞速

从Kafka到AutoMQ：爱奇艺实时流数据架构演进

大星辰-广告素材智能分析与生成平台

跳转微信打开

大咖导师团坐镇、行业顶尖模型加持!

跳转微信打开

在碎片化、高效率的消费大环境下，长视频面临着前所未有的挑战，用户观看门槛高、IP红利期缩短。如何让长内容在短平快的流量池里精准“种草”？

在碎片化、高效率的消费大环境下，长视频面临着前所未有的挑战，用户观看门槛高、IP红利期缩短。如何让长内容在短平快的流量池里精准“种草”？

速看AI剪辑给出了答案：依托“大星罗”智能分析技术，将长内容解构、重组，自动生成节奏紧凑、卖点突出的短视频合集，满足爱奇艺用户高效、多样化观剧需求。

速看的核心竞争力，在于让AI真正“读懂剧情、抓准卖点、精准把握用户口味”。我们持续孵化剪辑创意，使AI进化为垂直领域的“高级剪辑师”，实现1个IP的多样化内容裂变，助力新热IP宣发与片库二次消费。

电视剧：多元解读，强情绪共鸣

我们从剧情、话题、角色、解读等维度进行创意剪辑，沉淀出电视剧二创的多样化剪辑方法。

短剧化剪辑（爽点高度浓缩，长剧变短剧）

多故事线剪辑（如人物成长线、CP情感线等）

卖点强化剪辑（聚焦人物高光与情感爆点）

综艺：聚焦话题与情绪张力，精细化覆盖全题材

基于综艺题材差异，打造匹配其核心看点的多样化速看形式，推出如适合音综节目的“副歌速看”、适合语言类节目的“金句速看”、搞笑类“灵魂画手速看”等，精准凸显各品类特色，显著提升内容辨识度与社交传播力。

精彩剧情

音综-副歌

语言类-金句

搞笑-灵魂画手

电影：多样化“钩子”，高效种草导流

通过高能向、解说向、主题向等速看形式，以强视觉钩子瞬间捕获用户注意力，实现高效转化。

高光剧情

剧情解说

搞笑剧情

2025年，速看业务实现规模与质量的双重跃升，累计上线45个剪辑Agent，发布超2.4万内容合集；同时电视剧等核心品类的速看内容5秒跳出率优于短视频同品类大盘平均水平，内容质量表现突出。

面向2026年，将持续释放AI Agent的生产力红利，进一步提升速看内容的规模与品质：

1. 升级Agent能力：打通“创意生成-素材搜索-智能剪辑-内容包装”全流程自动化闭环。

2. 提升内容质量：持续丰富剪辑创意，优化剪辑效果，增加视频对用户吸引力。

3. 驱动数据闭环：构建“生产-分发-反馈”全链路体系，以用户行为与内容表现数据反哺生产迭代，实现持续进化。

通过“速看 AI”，我们正将“爆款”从玄学变为可复制的科学，让长视频在碎片化时代焕发新生。未来，我们将深挖AI Agent的生产力潜力，让每一个IP在AI赋能下，高效转化为多元种草内容，精准触达属于它的千万观众。

也许你还想看

在爱奇艺做研发，用AI写代码是什么体验？

从Kafka到AutoMQ：爱奇艺实时流数据架构演进

大星辰-广告素材智能分析与生成平台

爱奇艺多桌面端统一：Mac客户端架构升级实践

让AI编程的价值可追踪、可量化--「AI编程效能量化系统」

阅读原文

跳转微信打开

当AI已经成为研发标配，你还在用传统方式敲代码吗?

阅读原文

跳转微信打开

爱奇艺2025年度专利“成绩单”

爱奇艺近日公布2025年度专利“成绩单”——全年新申请专利993件，其中发明专利880件，一级专利12件，后两个数量创下5年来新高。截至2025年12月，爱奇艺申请专利总数达12506件，其中发明专利8099件；获专利授权7591件，其中发明专利3444件，仅2025年就新增发明专利授权275件。凭此成绩，爱奇艺跻身中国企业有效发明专利百强榜第72位。

值得一提的是，2025年爱奇艺新申请发明专利的AI“浓度”显著提升，过半数专利申请涉及AI技术创新，内容覆盖内容开发、制作、播出及线下沉浸式体验等各环节。 

深耕影视产业多年，爱奇艺的各项AI专利创新与具体业务场景紧密关联且具有独创性。2025年上半年，爱奇艺发布AI创意工具——“剧本工坊”，旨在为创作者的内容提炼、剧本评估工作提质增效。其中，技术团队通过大模型能力绘制出整部剧本的互动戏份、情感互动关系、冗余支线等曲线，通过曲线走势反映人物互动和故事节奏，找出节奏拖沓或转折突兀等剧情潜在问题，并可直观量化识别信息冗余、悬疑案件质量、情感浓度等，率先实现了高精度快速剧本剧情评估。这一创新填补了主流剧本评估软件的市场空白。在这一过程中，技术团队针对角色关系、叙事模式、情节关联度评估产出大量创新性专利。截至2025年底，“剧本工坊”已累计完成超1.7万部剧本小说的评估工作。

在内容新风口上，爱奇艺的技术转化也取得快速进展。2025年下半年，AI漫剧的火爆引发市场关注。但在高质量漫剧的生产过程中，基于现有大模型的“生图”“生视频”等功能，通常只关注片段内的语义正确性或人场道一致性，对时长较长的视频进行一致性控制成为制作的难点。这导致了自动生成的动漫片段很难直接作为成片，大量人工返工抵消了AI带来的效率优势。为此，爱奇艺的解法是在策略上聚焦打造由剧本自动转化为动漫的Agent（智能体）。技术团队设置多个Agent分别驱动剧本拆解、主体、分镜、视频等环节的制作及画面校验，通过Agent间的循环调用，结合爱奇艺沉淀的影视方法论，让“从剧本到成片”满足动漫叙事的连续性和片段间的一致性，同时让每个关键环节都保留出可控空间。这项专利技术已经提交专利申请并进入产品落地阶段，后续将服务于动漫、短剧、互动内容的批量生产。

不止影视内容，在沉浸式互动娱乐领域，仅2025年爱奇艺就围绕VR体验优化申请了近20项专利，全面覆盖体感、音频、光照、手势交互等诸多体验细节。这些专利技术被应用在《唐朝诡事录》《钟馗》等全感剧场项目的开发中。2026年2月8日，首家爱奇艺乐园将在扬州开门迎客，用户即可体验到沉浸式“一秒入戏”的超级娱乐体验。

作为国家知识产权示范企业，爱奇艺超1.2万件的专利申请不仅为平台自身构建了深厚的护城河，还将持续为影视产业的健康发展积累动能。

阅读原文

跳转微信打开

爱奇艺 Kafka 从私有云迈向公有云、从 Kafka 到 AutoMQ 的探索与实践。

Kafka因其高吞吐、低延时、可扩展的特性，在出现之后迅速成为流数据存储的标准组件，广泛应用于实时大数据场景。爱奇艺的流数据服务也主要基于Kafka构建，随着实时大数据应用越来越广泛，Kafka集群数量、规模越来越大，面临扩缩容繁琐、成本高、难治理等诸多问题与挑战。为解决这些问题，我们进行了Kafka服务化、上云、迁移AutoMQ等一系列探索。

本文将介绍爱奇艺Kafka从私有云迈向公有云、从Kafka到AutoMQ的探索与实践。

图1 数据通路

在爱奇艺，流数据的存储组件使用的是Kafka，计算组件主要使用的是Flink，流数据相关的典型数据通路如图1所示，主要包括如下环节：

• 数据集成：Pingback(端上投递日志)、后端日志、数据库binlog、指标等持续产生的流数据，实时写入数据总线Kafka。

• 数据仓库：由Flink程序将数据引入到实时（流式）、离线（批式）数仓。在实时数仓中，数据仍然以流数据形态存储在Kafka中，并通过Flink构建实时数仓各层数据。在离线数仓中，流数据将会聚集成批数据存储在Iceberg中，再由 Flink增量消费Iceberg构建离线数仓各层数据。实时数仓具备秒级延时，离线数仓具备分钟级以上延时。

• 数据开发：数仓的数据通过数据开发平台应用到各业务场景。在实时计算中Kafka也会作为中间流数据的存储用于任务之间的解耦。

• 数据应用：数据广泛应用到爱奇艺的推荐、搜索、广告、报表等等场景中。数据的价值随着延时增大快速衰减，为了数据价值最大化，近几年主要应用场景都已切换到流数据。

Kafka作为流数据的存储承担数据集成到大数据体系的数据总线、实时数仓存储、实时任务之间解耦等角色。

爱奇艺的流数据服务最初以Kafka集群为核心构建，提供集群生命周期管理、Topic管理、消费监控等基础能力。随着业务规模扩大、集群数量和数据量持续增长，逐渐暴露出以下问题：

1. 业务与集群强耦合：业务代码直接依赖Kafka地址访问集群，一旦需要迁移或调整集群，必须修改业务代码并重新上线，不灵活。同时也无法从平台侧统一识别和监控各业务的读写行为。

2. 缺乏统一的数据与schema管理：平台没有管理数据描述、schema、数据归属等元数据信息，无法提供数据查找功能，不利于跨团队的数据理解、复用与治理。

3. 主备数据管理缺失：对重要数据，业务侧通常配置主备链路，但平台侧缺乏对主备关系的统一管理，难以做到一致性保障与故障切换治理。

为了解决上述问题，我们将流数据存储服务升级到了如图2所示的架构，由Stream平台、Stream-SDK、存储组件三部分构成。

图2 流数据服务架构

先介绍下Stream平台，Stream-SDK和存储组件后面介绍。Stream平台由“集群管理”和“数据管理”两大模块组成。集群管理负责集群生命周期与底层资源的统一管理，侧重运维侧能力。数据管理是平台的核心，以“数据为中心”构建，面向数据开发人员提供统一的数据视图和管理能力，核心功能如下：

1. 逻辑队列：原先“集群+Topic”定位数据的方式，升级为基于“项目+队列（Topic）”的逻辑命名方式，集群仅作为队列的一个属性，消除业务对具体集群的依赖。逻辑队列还支持同时绑定主备两个集群，结合Stream-SDK可实现主备链路的一键切换。

2. Schema管理：支持为队列配置schema，并自动同步至大数据元数据中心，使队列能够在数据开发平台中自动映射为逻辑表，使用SQL直接处理流数据。

3. 数据地图：提供队列的多维度查询与检索能力，支持在线申请和授权使用队列，简化跨团队的数据查找和复用流程。

4. 数据血缘：基于Stream-SDK自动上报的读写端信息，构建应用级的读写血缘链路，帮助快速定位上下游数据关系及影响范围。

Stream-SDK是平台提供的统一数据访问客户端，封装了底层原生客户端，兼容Kafka协议和RocketMQ。业务仅需配置“项目+队列”，即可完成数据读写，无需关注具体集群地址或认证方式，从而实现业务代码与底层集群的彻底解耦。

图 3 Stream SDK 读写数据过程

Stream-SDK的数据读写流程如图3所示，主要包括两个阶段：

1. 配置获取与上报

   基于业务提供的项目、队列和Token（用于鉴权），SDK调用Stream平台的配置API，获取队列对应的集群信息、Topic、认证参数等配置，并使用原生客户端执行读写。同时，SDK会通过该API上报客户端IP、消费组、应用名称等信息，平台据此实时构建读写血缘。

2. 集群变更感知与自动切换

   在运行期间，SDK每分钟与Stream平台进行心跳交互，实时感知队列关联的集群是否发生变更。一旦检测到变化，SDK会自动将读写流量切换至新集群，实现无感迁移。

借助Stream-SDK，集群的迁移成本大幅降低，也为后续从私有云迈向公有云、从Kafka切换到AutoMQ的架构演变做好了准备。

早期爱奇艺Kafka集群部署在私有云IDC，受制于IDC资源供给模式及Kafka架构固有特性，资源利用率难以保持在合理区间。自2023年起，平台逐步引入多家公有云Kafka，形成混合云架构，在资源弹性、运维效率和成本优化方面取得了显著成效。下文将介绍下上云过程。

私有云Kafka

图4 Kafka 架构

Kafka架构如图4所示，是经典的多副本容错分布式架构，由Broker和Zookeeper两类角色组成：Broker负责数据存储与客户端读写，Zookeeper负责管理集群的元数据与协作状态。在私有云中，Kafka部署在爱奇艺各IDC，其中Zookeeper通常以虚机部署，Broker则根据场景选择虚机或物理机。

私有云模式支撑了公司流数据规模的快速增长，但随着业务体量持续扩大，也逐渐暴露出以下问题：

1. 集群弹性差：Kafka的Shared Nothing架构虽然简单可靠，但每个Broker上都存储大量数据，导致扩容或缩容时必须在Broker间进行大规模数据迁移。迁移过程耗时长且会影响业务任务的读写性能，使得集群难以实现平滑弹性伸缩。

2. 资源弹性不足：私有云的物理资源从采购到报废周期较长，难以随业务流量动态变化而快速调整，导致集群资源利用率长期处于“过高或过低”的状态。同时，对于寒暑假、重点直播等短时流量高峰，也难以做到按需扩缩，影响系统整体资源效率与成本优化。

从私有云Kafka到公有云Kafka

为实现降本增效并提升流数据存储的灵活性，我们引入并上线了公有云Kafka产品。

公有云Kafka产品遵循Kafka协议，通过在Stream平台与Stream-SDK中进行统一适配，为业务侧提供一致、无差异的使用体验，实现了私有云与公有云之间统一接入和平滑切换。

借助公有云庞大的资源池和按需创建集群的能力，解决了私有云环境下资源弹性不足的问题，取得20%以上的降本效果。

公有云Kafka虽然解决了资源弹性不足的问题，但是依然有集群弹性差的问题。新出现的AutoMQ支持秒级弹性吸引了我们的注意。

图 5 AutoMQ 架构

AutoMQ采用存算分离架构，如图5所示，具备如下特性：

1. 共享存储：数据统一存储在对象存储中，Broker不再持有本地数据。为解决对象存储延迟高、IOPS较低的问题AutoMQ引入块存储作为WAL（Write-Ahead Log），数据先写入WAL再进行批量落盘到对象存储。

2. 单副本存储：云端的块存储和对象存储本身具备多副本特性，已在存储层保证了高可用，因此AutoMQ内部的Topic均采用单副本策略，避免传统Kafka中Broker之间的副本同步开销，大幅降低成本与数据复制压力。

3. 兼容Kafka协议：AutoMQ基于开源Kafka改造，保留计算层逻辑，替换底层存储实现，完全兼容Kafka协议。

4. 快速弹性：由于Broker不再存储数据，节点可快速启动或销毁，实现分钟级弹性；同时对象存储按量计费，使资源规模能够与业务流量保持高度匹配，避免资源浪费。

在完成相关性能与稳定性验证后，我们在公有云环境部署了AutoMQ，并将其纳入流数据服务存储体系。通过Stream平台逐步将私有云Kafka、公有云Kafka迁移至AutoMQ，成本进一步降低70%以上。

流数据因其低延时特性，已成为爱奇艺的重要数据通路。随着规模增长，传统私有云Kafka在弹性、成本与治理上逐渐遇到瓶颈，因此，流数据存储架构从“管集群”转向“管数据”，并通过Stream平台与Stream-SDK实现解耦与统一治理。随后引入公有云Kafka和AutoMQ，使系统在弹性、运维效率和成本上都实现了显著提升。

目前约40%的流量已迁移到公有云Kafka或AutoMQ，其中一半是AutoMQ，下一步将继续扩大AutoMQ的使用规模，并探索AutoMQ的自适应自动弹性机制，持续降本。

阅读原文

跳转微信打开

介绍基于AIGC技术构建的大星辰平台，包括具体能力与应用成果等情况。

当前广告行业竞争日益激烈，广告主与平台对广告投放素材的质量、创意多样性及更新效率的要求都在不断提高。

用户也越来越关注广告内容是否贴合自身、形式是否自然、创意是否吸引人。可以说，个性化、高吸引力的素材，正逐渐成为影响广告转化效果的关键。

在这一背景下，我们与广告团队紧密合作，借助快速发展的AIGC技术，共同构建一个以技术为驱动、数据为支撑的智能化素材生成体系，推动广告创意生产模式的整体升级。

在长期支持广告业务的过程中，我们观察到，尤其是在效果广告的素材制作环节，普遍存在以下问题：

1.质量与效率难兼顾：传统方式依赖人工创意与制作，产能有限、成本偏高，难以规模化产出高质量素材，导致素材质量参差不齐。

2.创意同质化严重：行业内素材风格、形式趋同的情况较多，难以有效吸引用户注意，导致点击与转化效果受到影响。

3.长尾场景覆盖不足：面对细分受众、小众垂直领域或突发热点时，传统生产流程响应慢，造成大量广告请求因缺乏合适素材而无法填充，直接损失广告收入。

本项目旨在与广告业务深度协同，以实际业务目标为导向，共同打造一个集智能分析、生成、优化于一体的AIGC广告素材体系。

通过多种生成式AI能力的融合应用与产品化落地，我们将团队现有的“星辰”平台升级为“大星辰”平台，实现广告文案、图像、视频等素材的自动化与个性化生产，从根源上解决上述痛点，提升用户体验，并充分挖掘效果广告收入的潜力。

项目整体框架如下示意，大星辰平台基于底层多种模型能力，整合提供体系化的广告素材生成方案，并接入到奇炬、飞云等广告业务平台，供客户及业务系统使用。

1. 图片素材制作

重点聚焦于新图片素材的生成制作以及现有图片素材的智能衍生，基于自研以及第三方大模型进行生成，提升制作效率，降低人力成本。

1.1 纯生成式素材方向

提供基于自研模型以及第三方大模型的生图方案，包括文生图、图生图等细分能力。广告相关业务人员可以自行根据营销信息、广告卖点或者参考图片素材等作为输入，批量生成目标图片素材。

1.2 图片素材衍生方向

对于已有的广告素材，包括离线或者线上在投素材，我们提供自动化的图片素材复刻以及尺寸转换方案，通过这种形式，可以批量产出优质素材。

• 图像尺寸转换

基于广告业务特性的自研扩图模型，对输入素材进行尺寸扩展生成，以适配更多可投放场景，例如2:1扩展为16:3、24:7等宽幅图片，可以投放在场景banner等广告位。

• 图片复刻衍生

基于已有素材直接做生成式的复刻衍生，可以快速批量生产，保证线上优质素材可以及时刷新，提升覆盖库存和多样性。

同尺寸图片复刻：保持原图包版及尺寸不变，画面主体内容重新生成

跨尺寸图片复刻：保持图片主体信息不变，智能调整布局跨尺寸生成新的图片，可应用于横竖图片转换

2. 视频素材制作

视频素材相对图片素材更为复杂，素材传达信息也更加丰富，在与广告团队进行充分讨论后，我们以已有素材衍生作为主要方向，同时基于最新的生成式AI持续探索全新的生成式视频素材，目前也都取得了一些成果。

2.1 视频衍生方向

• 视频素材拆条

基于视频内容理解等相关算法，对网络影视等部分行业的视频素材做多样化的智能拆条，支持面向不同用户群体、不同投放场景，分别提供高能看点、行为标签等侧重点各异的方案产出拆条素材，实现不同场景下的素材覆盖以及最终转化效果的提升。

• 视频尺寸转换

广告素材投放场景多种多样，不同投放场景对广告素材尺寸的要求也不同，因此，基于已有视频素材的尺寸转换，是日常素材生产制作的重点工作。针对此类场景，大星辰平台提供了以下多样化方案，以提升素材制作效率和效果：

智能横竖转换：AI识别视频内容主体，按照业务所需目标尺寸进行画面智能裁剪，保留主体内容，包括横转竖以及竖转横等，适配多种不同尺寸裁剪要求。

画中画智能裁剪：AI识别视频素材是否为画中画包版，支持动态裁剪，裁剪后的原版素材既可以作为素材直接投放，也可以作为新一轮衍生的输入素材。

智能包版：彻底摆脱过去人工制作素材包版的繁琐流程，基于视频内容理解以及生成式AI，仅输入原始视频素材即可实现全自动化的智能包版，适配横竖多种比例，极大提升了制作效率和个性化效果。

2.2 图生视频方向

除了基于原始视频的衍生，在生成式AI加持下，基于线上图片进一步生成视频进行投放，也是目前重点应用方向之一。区别于传统的简单特效、拼接等制作方式，基于生成式AI的图生视频方案，不仅显著提升视频画面的动态效果，也可以一并生成与画面相匹配的音效。

2.3 纯生成式视频方向

除了基于已有广告素材做各类衍生之外，考虑线上素材的多样性、用户体验以及同类素材的效果衰减，我们也需要持续制作填充全新的广告素材内容。因此，基于生成式AI，为客户/代理商制作全新的视频营销素材，也是大星辰平台的重点探索方向，经过与广告团队持续的合作实验，目前已上线验证了多条视频生成agent：

• 美女颜值视频agent：可以指定多种风格模板，自动批量生成多样化的美女颜值类视频素材，叠加客户营销信息、前后贴内容等，即可作为视频投放素材。

• 故事视频agent：可以指定多种故事类型进行批量生成，实现从故事脚本->图片->视频的自动化流程，同步叠加配音及BGM合成最终视频。

• 解压视频agent：不需要额外输入，直接生成多样化的解压视频内容作为背景，配以吸睛口播文案。

• 人物话题agent：不需要额外输入，随机选取古典名著/历史人物，并围绕生成视频话题，搭配人物自述口播台词合成最终视频。

• 行业专属模型成效显著：基于广告行业特性，构建自研生图模型，提升素材行业适配性，线上自研模型素材点击率较第三方模型提升30%。

• 多元素材生成方案拓展创意边界：通过图片复刻、图生视频、生成式视频等多种方案，实现优质创意的衍生与拓展，同时提升素材质量。以生成式视频素材为例，同周期内相比人工素材点击转化率提升27%。

• 智能适配多样化投放场景：通过自研扩图、智能包版等多种方案，实现素材的跨平台、多尺寸适配，提升运营效率。

• 自动化生产提量提效：从AI素材自动生成到包版输出，实现高效率、高质量的素材规模化生产。

• 影响广告收入显著提升：25年Q2，AI影响效果广告收入环比增长50%，在一些典型投放场景如沉浸式广告中，AI素材应用进一步深化，带来素材量级和收入的持续提升。

在当前与广告业务深度合作并取得一系列成果的基础上，大星辰平台将持续以AIGC技术为核心驱动力，将素材生产体系建设作为一项长期性、系统性的工程来推进。

未来，我们将重点围绕生产流程智能化、创意生成规模化、内容形态多元化等方向，构建更敏捷、可迭代的素材生成体系，实现从需求理解到创意生成、动态优化、批量产出的全链路提效。通过不断提升素材的制作效率、创意质量与适配能力，为广告业务带来持续的增长动力，在提升转化效果的同时拓展创意边界，最终助力广告收入实现健康、可持续的增长，也让整体业务竞争力再上一个台阶。

也许你还想看

让AI编程的价值可追踪、可量化--「AI编程效能量化系统」

告别“玄学”创作，AI重塑微短剧全链路生产方案

喜报！爱奇艺AI团队三篇论文被顶会录用

爱奇艺多桌面端统一：Mac客户端架构升级实践

奇智：生成式 AI 应用创建平台

阅读原文

跳转微信打开

基于LWA方案对Mac客户端进行架构升级，降本增效的实践成果

01#

背景

爱奇艺一直致力于提供卓越的桌面视频客户端使用体验。爱奇艺的桌面端主要包括：

• 电脑网页端

• Windows客户端

• UWP客户端

• Mac客户端

爱奇艺的桌面客户端矩阵演进历程

2022年之前

这4个端由不同的产品和研发团队设计开发，用户界面和使用体验各不相同，开发、维护、运营成本很高。

电脑网页端↓

Windows客户端↓

UWP客户端↓

UWP（Universal Windows Platform）是微软公司创建并在Windows10中首次引入的一个同性质应用程序架构平台，是创建适用于Windows的客户端应用程序的众多方法之一。此软件平台的目的是帮助发展Metro样式的应用程序，便于软件可以在Windows10和Windows10 Mobile上执行且无需重新编写。

Mac客户端↓

2022年-2023年

PC客户端团队和微软合作，提出基于微软Edge Webview 2和Web技术栈的全新桌面应用开发框架——LWA（Local Web App），并用其重构了Windows客户端，逐步完成功能全覆盖上线。

Windows客户端↓

2024年

得益于LWA框架基于标准Web技术栈开发用户界面和业务逻辑的特点，其前端业务代码用较低的成本复用到了电脑网页端，提供了一致的用户体验的同时，也实现了降本增效。

电脑网页端↓

2025年

PC客户端团队再接再厉，将LWA方案继续复用到了MacOS操作系统。

本文下面重点分享基于LWA方案对Mac客户端进行架构升级的实践。

LWA桌面应用开发框架介绍

背景

在2022年以前，爱奇艺Windows客户端使用自研的RND（React Native for Desktop）框架来开发界面和交互。RND框架的技术原理和Facebook当年的RN（React Native）框架很像。RND和RN一样使用JS和React框架来开发前端界面和业务逻辑，支持热更新，开发快捷。但是，RND没有RN框架那么完善的开源社区资源，例如各种UI组件库和原生模块等，需要RND框架团队自己实现，成本较高。不幸的是，后来组织架构调整，RND框架团队解散，由业务团队继续维护。但是，在后续迭代中遇到一些底层问题，如通信效率等，难以推进优化和解决，大大限制了产品需求落地。

因此，PC客户端团队积极寻求替代方案。

方案对比

PC客户端团队基于和微软公司良好的合作关系，提出基于Microsoft Edge WebView2的桌面前端应用开发框架LWA（Local Web App）。该方案得到了微软公司的大力支持，由微软与爱奇艺团队合作开发。

在Windows操作系统平台上，LWA方案使用WebView2作为运行时容器和渲染引擎，相较于当时其他桌面前端开发方案具有一定优势：

WebView2技术优势：

• 官方支持：微软出品，Win10(部分)/ Win11自带，持续更新，文档齐全。

• 社区支持：因其主体部分采用Web标准而受行业支持。

• 稳定可靠：微软的专业团队会持续迭代升级webview2，提升其性能和稳定性。

• 复用技术：标准Web开发。

LWA方案原理

LWA方案通过内嵌网页的方式，以标准Web的形式支持业务逻辑实现和界面展现，并通过宿主来进行能力扩展。

• 宿主程序负责应用程序生命周期和内嵌网页的管理，其可以是现行模式，或是基于WPF或Windows App SDK。

• 内嵌网页通过WebView容器（Windows平台采用微软的Edge WebView2，其他系统平台可以更换）加载，并通过JS Bridge 和 Post Message的方式进行通信。

• 内嵌页面资源可通过离线包管理，以实现加速，因此支持热更新。

LWA框架架构图↓

LWA方案优势

• Web前端技术栈：采用了标准的web技术栈，享有业界最新主流的界面与交互能力，更为完善的特效支持，某些产品和交互需求的实现更为便捷

• 可扩展：业务代码和原生的能力交互层隔离，可扩展为多个平台运行，易于迁移（比如迁移到Mac端）

• 自打包和升级体系：可以享有基于微软框架的LWA技术能力的加持，如热更新

LWA方案上线效果

LWA方案落地上线时，我们做了几个典型场景的性能评估，优化效果明显。

• 重构随刻热点页面（RND → LWA）

• 冷启动至主界面呈现耗时减少38.8%。

• 重构收银台页面（内嵌 Web 页 → LWA）

• 点击至主界面呈现耗时减少74.7%，流失率降低至少 1.69pp。

• 重构登录页（C++ → LWA）

• 点击至主界面呈现耗时各有千秋，快捷登录1.10s → 0.70s，扫码0.34s → 0.80s。

• 重构主窗口（RND → LWA）

• 页面滚动、页面切换、过渡效果，实现性能体验效果提升。

Mac客户端概况

在架构升级之前，Mac客户端采用苹果公司的Mac Catalyst方案，将iPad端的代码复用适配到Mac端。因此，之前的Mac客户端的用户界面跟老版iPad客户端很像，而跟Windows客户端有着显著差异。然而，后来iPad客户端界面大改版，考虑到大屏响应式设计成本，采用了iPad端和Mac端界面分道扬镳的策略，代码差异越来越大，复用性越来越低，Mac端更新频率下降。

痛点：

• 在各种尺寸显示器上的使用体验不够理想

• 新功能需要兼顾iPadOS和MacOS两个系统上的体验导致产品、设计和研发成本较高

大屏体验不佳↓

iPad端界面大改版后跟Mac端分道扬镳↓

02#

目标

将LWA方案应用到Mac端，复用Windows客户端的前端业务代码，跟Windows客户端、电脑网页端一样，提供更优秀的大屏用户界面和交互体验，并降低产品、设计、研发、运维成本。

03#

方案选择

按照LWA框架架构设计，针对不同的操作系统平台，需要选择不同的Web容器，并实现LWA原生支持能力。

针对MacOS，出于稳定性和实现成本的考量，Web容器优先选择使用系统自带的WKWebView。而关于LWA原生支持能力，我们最终决定采用基于AppKit框架重写原生层，并移植Windows播放器业务逻辑的方案。尽管原生层复用MacCatalyst方案代码成本最低，但因经过MacCatalyst技术转换的WKWebView不支持MSE特性而被迫放弃；而直接移植iOS播放器又面临基础库适配工作量大、后续维护门槛高的难题。相比之下，将Windows端由C++开发的播放器核心逻辑移植到MacOS，不仅能复用已有的JS Bridge接口、节省开发投入，更有利于由PC团队统一维护和未来跨平台的业务逻辑共享，同时推动了播放器底层架构的优化与解耦，为多端协同奠定了长远基础。

04#

开发实践

新Mac客户端专项从2025年Q2开始开发，投入3个主力开发人力，众多开发团队做配合，历时4个月的时间，完成了开发和上线。3个主力开发分别负责：LWA原生容器开发、JS代码迁移和适配、C++代码移植和适配（包含播放器）。

LWA原生容器开发

MacOS上的LWA原生容器基于WKWebView构建，作为连接原生层与JS层的核心框架，主要负责通信桥梁与基础功能，主要界面与交互逻辑则由Web端的JS代码处理。其核心功能包括：

• 虚拟域名与资源加载：支持虚拟域名、本地资源匹配加载及跨域访问。

• 请求处理：通过Runtime Hook拦截HTTPS请求，并分别转发至本地文件系统或原生网络库。

• JS Bridge通信：实现Command接收与Event应答的双向通信机制。

• 导航栏交互：将自定义系统按钮、窗口拖拽及点击事件传递至JS层处理。

• 窗口状态管理：同步全屏/小窗状态，管理多窗口，并更新原生播放器位置。

JS业务代码适配

JS代码由于运行在Web容器中，跟操作系统隔离，天然具备跨平台运行能力，很容易复用和移植到不同的操作系统平台。不过，由于MacOS的WKWebView使用的浏览器内核是webkit，而Windows上我们使用的WebView2的浏览器内核是Chromium，仍然存在一些差异。在实践的过程中，我们确实发现了一些MacOS上的兼容性问题，需要对代码做少量修改和适配。我们将遇到的问题和解决办法进行了整理，以便持续迭代桌面客户端JS业务代码时，能避免引入兼容性问题，从而减少多平台重复的测试验证成本。

C++代码移植和适配

Windows客户端的C++代码中大部分业务逻辑其实是平台无关的，可以移植到MacOS端，主要是将跟平台耦合的那部分代码进行适配。另外，由于Windows和MacOS在操作系统特性和应用开发生态上存在较大差异，需要针对这些差异点做针对性的开发和适配。

播放器移植适配

播放器是客户端的核心功能，内部业务逻辑非常复杂，依赖库众多，迁移适配的工作量也很大。我们认真梳理了不同平台播放器的层次结构，找出相同点和差异点，设计合理的架构，最大化代码复用，节省开发成本。

• 基础库和核心库：复用iOS代码，适配MacOS

• 播放器功能：复用Windows平台C++代码，适配MacOS

• JS Bridge：针对MacOS，使用Objective-C语言对标Windows平台重新实现

• 播放器组件和播放窗口功能：复用Windows客户端上的LWA JS代码，适配MacOS的工作量极少

形态差异

老Mac客户端采用Mac Catalyst技术将iPad App适配到MacOS，因此其播放器使用iOS标准原生技术栈进行开发。

新Mac客户端由于复用Windows客户端的LWA方案，因此也和Windows客户端一样，通过在原生播放器上叠加一个背景透明的Web容器来实现，原生播放器只负责渲染播放画面，播放器的各种UI控件和业务逻辑均在Web容器内用JS语言来实现。不同之处在于原生播放器和Web容器：

• 原生播放器：视频播放能力依托于操作系统的底层能力，在MacOS上无法直接复用Windows上的播放内核，需要独立封装，不过可以基于爱奇艺iOS播放内核对MacOS进行适配，复用大部分iOS播放内核的能力。

• Web容器：不同的操作系统各自有其自带的Web容器能力，虽然理论上也可以使用跨平台浏览器内核，实现复用，比如Chromium，但是相比于使用系统自带的Web容器，实现成本高，并且显著增加安装包大小。因此，目前我们针对Windows平台使用微软的Edge WebView2，针对MacOS平台使用系统自带的WKWebView。

可复用的部分

Windows客户端播放器中可复用的代码主要涵盖：

• 通信层：JS Bridge原生部分（大部分）

• 核心层：基础播放功能（协议解析、播控、状态机、容错等）与本地播放

• 辅助层：设备云控、播放特性、码流播控、设置与配置

AI辅助编程提效

将C++代码适配到MacOS平台

在复用C++代码到MacOS平台的过程中，需要将大量之前依赖Windows平台API的C++业务代码适配MacOS平台。比如，在Windows平台，一般使用.ini配置文件，读写逻辑用的是Windows系统API：GetPrivateProfileInt、WritePrivateProfileString这种形式的API，在MacOS上没法用，于是，我们直接用Curosr IDE重写了一个ini配置文件工具类。AI非常擅长开发这类工具类，效果非常好，提效明显。

将C++代码转成Objective-C代码

在复用C++代码到MacOS平台的过程中，还需要将很多C++代码转换成MacOS主流的Objective-C代码，以便和其他复用自iOS端的基础库配合使用。AI也非常擅长这个场景，效果也非常好，提效明显。

C++代码→ObjC代码

AI辅助开发JS版MacOS收银台

由于在LWA架构下，用户界面主要由JS实现，而MacOS上的收银台和Windows上的很不一样，因为必须使用苹果应用商店要求的苹果内付费机制，因此需要全新开发。

我们借助Cursor IDE，使用提示词+MCP（自研的设计稿转前端代码的MCP）的方式，实现React组件开发提效，时间节省30%。

05#

成果和收益

正式上线

9月10日，全新升级的爱奇艺Mac客户端16.9.0上线App Store。

桌面端体验统一

全新Mac客户端上线，解决了之前Mac端在大屏上体验不佳的问题，并能跟随Windows客户端一起快速迭代，不断带给用户新的功能和更优的体验。

降本增效

为了控制测试范围，全新Mac客户端16.9.0版本复用的JS业务代码的版本对齐的是Windows客户端13.7.5版本，而9月10日上线时，Windows客户端的最新版本是13.9.0，相差了3个大版本。后来，Mac客户端16.9.5版本需要对齐到Windows客户端13.9.0版本，也就是在Mac客户端的一个版本迭代周期中带入Windows客户端3个版本的内容。看似任务很艰巨，但是得益于LWA方案的优势，经过对3个版本共91个需求的梳理，仅5个需求需要迁移适配，且适配工作量很小，而其余86个需求的代码可以完全复用。需求复用度达到95%，极大节省了开发成本。

06#

未来规划

1. 持续优化新Mac客户端的使用体验

MacOS有很多独特的系统特性是Windows系统没有的，比如MacOS上的Handoff接力功能，需要持续迭代支持。另外，性能也和Windows客户端一样需要持续监控和优化。

2. 推动桌面客户端架构升级以适应多平台

LWA方案中的JS代码天然适应多操作系统平台，因为有W3C标准作为保障，每个操作系统平台都有支持W3C标准的Web容器。在将LWA方案复用到MacOS平台时，我们发现C++代码其实也是天然适应多操作系统平台的，因为这些操作系统本身基本上都是基于C和C++语言开发的。但是，C++代码一开始并未考虑到适应多操作系统的需求，因此直接耦合依赖了很多Windows系统的API和能力，要更容易地复用尽可能多的C++代码，需要升级代码架构，对代码进行合理的拆分和解耦，最终实现理想的最大化代码复用的效果。

3. 将LWA方案复用到UWP客户端

从文章开头的截图可以看出，爱奇艺UWP客户端与Windows客户端在UI设计风格上显著不同。由于在同一操作系统平台上维护两个产品的设计、开发和运营需要较高的成本，这使得更新迭代的速度有所放缓。基于将LWA方案成功移植到Mac客户端的经验，爱奇艺PC客户端团队计划继续推进多桌面端的统一之旅，尝试将LWA方案应用于UWP客户端，为用户提供一致且优秀的使用体验。

也许你还想看

让AI编程的价值可追踪、可量化--「AI编程效能量化系统」

告别“玄学”创作，AI重塑微短剧全链路生产方案

盘活数据资产，驱动价值释放：数据仓库与 ChatBI 的融合之道

基于StarRocks释放天玑买量数据价值

爱奇艺大数据异构计算实践

AI&算法| 大数据
大前端 | 大后端 | 播放

阅读原文

跳转微信打开

“AI编程效能量化系统：让AI编程的价值可追踪、可量化”

01#

背景：AI编程时代，我们面临的新挑战

随着AI编程的普及与深入，AI编程工具如Cursor、Cline、Claude Code等正成为开发者日常的得力助手。

然而，我们也发现随之而来的是两大核心痛点：

1.AI对话难以追踪

软件开发逐渐从“以代码为中心”转向“以对话为驱动”，对话变得越来越重要。

我们在阅读AI生成的代码时，不仅关注代码本身，更希望了解当时与AI交互的上下文。

但是这些对话散落在每个开发者的本地环境中，无法统一管理与共享，查看AI生成代码时经常因为没有当时生成的上下文而一头雾水。

2.AI贡献难以量化

AI到底为我们写了多少有效代码？AI到底为我们提升了多少效率？哪些模块的AI贡献最大？

缺乏统一的度量体系和方法，我们难以区分AI写的代码和人工编写的代码，难以客观评估AI投入的实际产出，更无法系统化地优化使用策略。

正是由于以上问题的存在，我们需要建立一套可追溯、可量化的AI编程效能体系，以全面评估AI在开发过程中的实际贡献，提升团队协作透明度与工程效能。

在开发本系统之前，团队成员也曾尝试过一些“土法炼钢”的方式来追踪、量化AI的使用效果：

1.Wiki截图，手动存档

将与AI的对话记录逐一截图，并以需求为单位粘贴到团队Wiki中。

弊端：给程序员带来大量额外工作，难以坚持；信息零散，无法搜索和统计分析；

2.代码注释，脚本统计

通过如全局的cursor rule，让AI在生成代码前后加上特殊注释（如// @AI-Generated-Begin、// @AI-Generated-End），然后通过脚本扫描这些注释来统计AI代码行数。

弊端：如果在AI生成代码中增加人工代码，注释会特别复杂，影响代码可读性；注释易被人为修改，指标缺乏客观性。

03#

解决方案：AI编程效能量化系统

整体方案如下图所示：左侧插件解决“可追踪”的问题，右侧系统实现“可量化”的目标。

可追踪：统一管理AI对话

我们开发了一款VSCode插件，能够：

1. 自动读取Cursor等AI工具的本地数据库；

2. 支持将AI对话记录以Markdown格式一键保存至项目源码中；

将与AI对话保存在源码中有两点好处：

1. 团队间的AI对话可以共享。

2. 全局搜索相关代码的时候可以方便找到当时的AI对话。

可量化：精准计算AI贡献

同时，有了这个插件，我们通过插件可以将本地的AI交互数据无感上传到云端，在云端进行聚合分析。

结合GitLab提交数据，我们可以和AI生成的代码做对比，就可以精确计算出AI生成代码占比。

核心指标

基于收集的信息，我们可以计算出以下核心指标：

04#

效果展示：

插件部分

通过插件我们可以清晰看到今天、本周、本月的AI使用情况以及环比上个周期的使用情况。

并且我们可以看到这个workspace下所有与AI的对话情况，支持一键以markdown的形式保存在项目源码中。

个人仪表盘

个人活跃度：直观地看到每天和AI对话的次数，对话次数越多，颜色越深。

0对话：灰色；1-34对话：浅绿色；35-68对话：绿色；69-102对话：深绿色；103+对话：黛绿色

个人AI研发核心指标：自己AI代码占比、各种语言AI占比、采纳比例。

个人使用趋势：可以查看自己近期的使用趋势

团队仪表盘

团队总览：可以看到团队有多少人在使用AI编程、使用时间等信息。

团队AI研发核心指标：可以看到团队中AI代码占比、各种语言AI占比、采纳比例。

团队的排行榜：

团队指标成果展示：

随着这个插件和系统的上线推广，我们团队AI编码率从之前32%（9月份）提高到54%（10月16日-10月29日，系统上线后）。

05#

方案细节与关键机制

插件侧（数据收集）

为确保数据上传的顺畅与准确，插件侧进行了多项优化。

1. 多源数据采集：支持从主流AI编程工具中提取完整的交互历史记录

2. 智能项目识别：通过算法自动识别对话记录所属的代码项目，确保数据准确归属

3. 增量同步机制：基于时间戳的增量数据上传，避免重复采集，提升效率

4. 数据完整性保障：支持手动补传和批量重传，确保数据不丢失

服务侧（据清理、分析）

系统通过定时任务每15分钟自动执行统计算法：

1. 获取活跃用户与最近提交（Git Diff）

2. 提取对应AI对话生成的代码片段

3. 清洗、比对新提交代码

4. 若命中AI片段→标记为AI代码，否则为非AI代码

本项目AI参与度

本项目通过本系统统计AI代码占比如下：

VSCode插件：95.98%

后端服务：70.42%（部分公共代码复用老项目）

前端数据看板：91.74%

除了开发部分，本项目全流程使用AI参与：包括系统设计、数据分析、测试、文档，全与AI协作完成。

06#

未来规划：从Cursor到企业级AI效能平台

未来的规划主要分三步：

1. 提高插件使用体验和完善指标体系建设。

2. 通过MCP协议上报的方式，支持Cline、TRAE等更多AI编程工具。

3. 探索代码提效推动产能提升的路径，是产能提升可量化。

07#

结语

“让AI编程可追踪、可量化，通过自动记录与分析，助力团队清晰度量AI价值，提升产能。”——这正是「AI编程效能量化助手」的使命。

如果你也在探索AI编程的效能提升之路，欢迎与我们交流合作。

让AI的价值，不止于感觉，更见于数据。

也许你还想看

基于StarRocks释放天玑买量数据价值

告别“玄学”创作，AI重塑微短剧全链路生产方案

爱奇艺大数据异构计算实践

爱奇艺积分系统架构演进：从 MySQL 到 MongoDB 的统一存储实践

AI&算法| 大数据
大前端 | 大后端 | 播放

阅读原文

跳转微信打开

还在熬夜剪片，苦等一个不确定的爆款？别再内耗了！爱奇艺AI微短剧全链路智能生产平台，就是你的“爆款制造机”。

01#

1条视频剪5小时，你的钱和时间都去哪了？

你是不是也这样？为了追一个热点，对着海量素材反复拉片，眼睛都快熬瞎了，好不容易剪出一条自认为的“爆款”，投放出去却石沉大海。一条几分钟的微短剧素材，从找“爽点”到剪辑成片，动辄花费3-5个小时。时间没了，预算烧了，爆款却依然遥不可及。

我们不禁一遍遍地问自己：我的钱和时间，到底都去哪了？

02#

压在每个内容人身上的“三座大山”？

这背后，是整个内容行业都在面临的困境：

• 效率，是永远的痛：纯靠人工，产能就是天花板，根本跟不上市场的“投喂”速度。

• 质量，像一场赌博：爆款的诞生，严重依赖个人经验和那点说不清道不明的“网感”，我们称之为“玄学”。

• 时效，是错失的黄金：等剧上线再动手？对不起，第一波流量红利早已被瓜分完毕。

当规模化生产成为刚需，这种“手工作坊”式的模式显然已经走到了尽头。难道，我们就只能在这场关于效率、质量、时效的“不可能三角”里，继续内耗下去吗？

03#

破局的答案：让AI成为你的“超级合伙人”

今天，我们想给你一个确定的答案。这个答案，就是今天要介绍的——爱奇艺AI微短剧全链路智能生产平台。

它不是要替代你，而是要成为你最强大的助手，把那些消耗你时间和金钱的重复性劳动，变得自动化、智能化。简单来说，它用三大“超能力”，直接回答了文章开头那个扎心的问题：

1. 帮你“抢”时间：在剧集更新前就完成素材生产，让你从追赶者变成领跑者。

2. 帮你“省”金钱：搭建十余条自动化批量产线，让爆款经验被指数级复制，大大提升投放ROI。

3. 帮你“赢”概率：通过学习爆款配方，自动理解并组合出最具爆款潜质的内容，告别“玄学”。

数据不会说谎：这套体系让我们的核心爆款衍生内容，投放效果实现了指数级的突破；而通过“抢跑”提前生产的素材，效果更是比上线后制作的素材提升了数十倍！你的钱和时间，本该花在这样的确定性增长上。

04#

揭秘AI超能力：它究竟是如何做到的？

超能力①：一个“吃透”上千部剧的超级大脑

AI凭什么这么神？首先，我们给它投喂了海量的“精神食粮”，为它打造了一个“超级大脑”。

• 微剧片段库：它看过的剧，可能比你刷过的还多。我们让它深度学习了上千部微短剧，它能自动理解每一帧画面的内容，智能切分片段，精准找到想要的素材再也不是问题。

• 微剧爆文库：我们还让它沉淀了优质爆款素材库。一条视频为什么火？“钩子”在哪？情绪如何递进？故事线怎么组织？AI把这些爆款密码一一破解，沉淀为可复用的方法论。

有了这个大脑，AI不再是冰冷的机器，而是一个真正“看懂”了微短剧，并且知道观众想看什么的专家。

超能力②：一座流水线式的“爆款智能工厂”

有了“超级大脑”，生产爆款就从“手工作坊”变成了“智能工厂”。

1. “千变万化”的裂变策略：发现一个爆款后，它就像一个创意矩阵，能瞬间对任意素材进行结构重组和元素再创作，衍生出无数种创意策略。

2. “无中生有”的预测策略：如果是一部全新的剧，没有历史爆款参考怎么办？AI把创作规律总结、提炼，变成了一套套可复用的“创意配方”。当一部新剧进来，AI就能像个经验丰富的主编，迅速判断出：“这部剧适合用‘逆袭打脸’的配方，还是‘情感拉扯’的配方？”

在一次新剧测试中，AI智能选出的素材，转化效果直接冲到TOP1，投放表现远超同期行业平均水平数倍之多！

爆款衍生案例:

悬念结尾前置:揭露身份

爆文开头复刻:同事侮辱

开头解说:原因揭晓

全篇解说:一段解说一段剧情穿插

超能力③：一台让你“抢跑”的时光机

在微短剧的世界里，时间就是生命线，只需要上传任意剧集视频，AI直接火力全开，全自动理解所有需要的底层数据，并自动批量完成多策略爆款衍生视频，真正的实现统一时间直接完成一文多发。

这意味着，当竞争对手还在焦急等待剧集上线才能开始剪辑时，你已经手握海量的营销素材，“万事俱备，只欠东风”。这一招“抢跑”，让我们的素材投放时效平均提升了超过50%，效果更是实现了颠覆性的增长。

05#

未来已来：把时间和精力还给创意

所以，回到最初的问题：你的钱和时间都去哪了？

过去，它们消耗在了无尽的重复劳动和不确定的“试错”中。而现在，AI为你提供了一个全新的答案。它不是要取代你的创意，而是要将你从繁琐、重复的“剪辑体力活”中解放出来，让你把宝贵的时间和精力，重新投入到真正的创意、故事和情感本身。

当AI成为我们手中最锋利的“剪刀”，一个属于内容创作的“工业化革命”时代，已经悄然来临。而你，将成为这场变革的真正受益者。

也许你还想看

盘活数据资产，驱动价值释放：数据仓库与 ChatBI 的融合之道

基于StarRocks释放天玑买量数据价值

会员业务预防系统腐化的探索与实践

混合云场景下基于Anycast网络建设内网DNS服务

喜报！爱奇艺AI团队三篇论文被顶会录用

AI&算法| 大数据
大前端 | 大后端 | 播放

阅读原文

跳转微信打开

融合数据仓库与ChatBI激活数据资产释放业务价值提升智能决策效率

01#

Chat BI 相关背景介绍

首先和大家分享下数据仓库与Chat BI融合的背景，主要围绕BI系统的发展历程、各阶段数据获取路径、Chat BI的优劣势及核心关注点展开。

1. BI系统的发展历程

BI系统的发展可归纳为三个版本，不同版本在服务用户、核心能力及开发者要求上存在显著差异：

（1）BI 1.0 时代（报表系统）

服务用户：主要面向业务负责人，无法满足所有数据需求者。

核心特点：系统开发周期长（通常以周为单位），用户仅能获取结果数据。

开发者工作：需搭建数据仓库，并对数据资产进行盘点、建立资产目录；数据分析师、产品运营等有自主能力的人员，需通过资产平台检索资产并自行编写SQL取数，效率较低。

（2）BI 2.0 时代（敏捷 BI 时代）

服务用户：覆盖更多有个性化需求但无SQL编写能力的人群，通过拖拉拽、圈圈点点的操作方式满足需求。

核心特点：开放底层数据，用户可选择的数据范围更广；依托OLAP技术发展，数据查询效率大幅提升，无需长时间运行大任务。

开发者工作：要求更高，除资产管理外，还需进行数据建模，将数据打成大宽表作为数据集发布到分析平台。

（3）BI3.0 时代（Chat BI时代）

服务用户：无聚焦限制，所有用户均可使用，通过问答方式提取数据。

核心特点：底层架构与BI2.0无太大差异，主要是在原有架构上叠加大语言模型。

核心优势：降低用户使用门槛，提升数据获取便捷性。

2. 各阶段数据获取路径对比

（1）BI 1.0 时代

路径：用户发起需求→与BI需求BP对接沟通→用户等待→BI研发人员开发→测试人员测试→数据交付→用户分析数据。

用户体感：流程规范，无需自主操作，体感相对较好，但周期长。

（2）BI 2.0 时代

路径：分析师 / 产品运营确认数据源→自助取数→数据核对→数据分析。

用户体感：需自主完成多个环节，对用户能力有一定要求，灵活性提升但操作成本增加。

（3）BI 3.0 时代