CutClaw 深度解析：让 AI 听着音乐剪片子的多智能体视频剪辑系统

快速摘要：CutClaw 是由北京交通大学、大湾区大学 GVC Lab 与腾讯 ARC Lab 联合开源的"音乐驱动型"长视频自动剪辑框架。它把几小时的原始素材和一段音乐丢进去，再加一句文字指令，就能自动产出一支节奏精准、叙事连贯、画面有电影感的短片。和市面上"先剪片再配 BGM"的工具完全相反,CutClaw 是先听音乐、再决定剪哪里:Playwriter(编剧)、Editor(剪辑师)、Reviewer(审片人)三个智能体围绕音乐节拍协同工作,把长素材分解成可检索的语义单元,再按照副歌、主歌、桥段把镜头落到该落的拍点上。项目地址 https://github.com/GVCLab/CutClaw,:Playwriter(编剧)、Editor(剪辑师)、Reviewer(审片人)三个智能体围绕音乐节拍协同工作,把长素材分解成可检索的语义单元,再按照副歌、主歌、桥段把镜头落到该落的拍点上。项目地址 https://github.com/GVCLab/CutClaw,本机部署只需 Python 3.12 + 一张能跑解码的显卡。下文会把它的原理、流水线、安装、参数、模型搭配一条条拆开讲清楚,想直接动手的朋友可以跳到"快速上手"那一节。
—— 莫潇羽@源码七号站(www.fuyuan7.com)

一、为什么要专门聊这个项目

剪过片子的人都明白一件事:真正消磨创作热情的,不是构思,而是在时间轴上一帧一帧地拖。一个 Vlogger 出门拍一天,回来面对的可能是五六个小时的零散片段;一个做品牌宣传的同学,可能要在一周里产出十几条不同节奏、不同比例的短视频。手动剪,效率低到让人怀疑人生;套模板,又总觉得画面和音乐之间隔着一层东西,踩不到点上。

更微妙的是,剪辑这件事的"机械程度"和"创造程度"往往交织在一起。你在拖时间轴的同时,也在不断做"这一刀切在哪里更舒服"的判断。问题是,绝大部分判断其实是重复的、低创造性的,只有少数几个关键决策才真正考验审美。但人脑没办法把这两类工作分开,你不得不在重复劳动中消耗注意力,等到该做关键决策时反而疲惫不堪。这正是 AI 工具应该介入的地方——把重复的部分剥离出来,让人专注在真正需要创造力的环节。

过去这两年,所谓的"AI 一键剪辑"工具其实出了不少,但绝大多数走的是同一条路——先把视频按内容剪好,再往上盖一层背景音乐。这种做法的天花板很明显:音乐只是装饰,镜头切换的时机和音乐的呼吸完全是两回事,看起来"好像踩点了",细看会发现切点总是差那么半拍。

CutClaw 这个项目之所以值得单独写一篇长文,是因为它把这件事的逻辑彻底翻过来了:先把音乐拆开来听,再让画面去适配音乐的骨架。它不是给视频配音乐,而是让音乐去指挥视频。这一字之差,出来的成片观感完全是两个量级。

为了让大家对这种差异有更直观的感受,我打个比方。传统剪辑工具就像是先把一桌菜炒好,再去配一瓶酒;而 CutClaw 是先选好酒,再根据这瓶酒的风味去定整桌菜的搭配。前者出来的菜和酒可能各自都不差,但合在一起总差点意思;后者从一开始就考虑了配合,出来的整体体验是另一个层次。视频和音乐的关系,本质上和菜与酒非常像——单独看都成立,但只有真正"为彼此而生"的搭配,才能达到一加一大于二的效果。

我是莫潇羽,源码七号站(www.fuyuan7.com)的站长,平时会在站里持续整理一些值得动手玩一玩的开源项目。CutClaw 是最近几个月里我自己上手感受最特别的一个,所以想花点篇幅,把它从论文思路、系统结构,一直到本地部署、参数调优都讲清楚,既给想直接用的朋友一份操作手册,也给想理解原理的朋友一份架构地图。

二、CutClaw 是什么:一句话说不清楚的"剪辑师"

如果只用一句话概括,CutClaw 是一个端到端的、由多模态大模型驱动的、面向"长素材+音乐"的自动剪辑系统。但这一句话其实塞了很多信息,我们一个词一个词拆开看。

"端到端"的意思是,你不需要先用别的工具去切片、转写、打标签,直接把原始视频和原始音乐文件丢进去就行。系统内部会完成素材拆解、语义理解、镜头规划、片段筛选、画面裁剪、最终渲染这一整套链路。

"多模态大模型驱动"是说,它不依赖固定模板或者传统的视觉算法,而是把视频帧、音频波形、文字指令统一交给 MLLM(多模态大语言模型)去理解。这意味着它有"看得懂画面、听得懂音乐、读得懂指令"这三种能力的合力。

"面向长素材"很重要。市面上很多 AI 剪辑工具的输入上限其实就是几分钟,因为大模型的上下文窗口有限,塞不下几小时的视频。CutClaw 的论文标题里专门写了 "Hours-Long",就是冲着这个痛点去的——它用了一个"自下而上的多模态素材解构"的设计,先把长素材压缩成结构化的语义片段,再往上层送,从而绕开了上下文长度的物理限制。

"音乐同步"则是它的灵魂。整个系统的时间轴锚点不是脚本、不是字幕,而是音乐的结构本身。你可以把音乐想象成一根带刻度的尺子,所有镜头都必须乖乖地落到这把尺子上对应的位置。这种"以乐为尺"的思路,让每一次剪辑动作都有了明确的物理依据,而不是靠剪辑师的手感去碰运气。手感这东西可遇不可求,但音乐结构是稳定的、可量化的、可被算法理解的,这就让"踩点精准"从一种玄学变成了一种工程能力。

按照官方论文的说法,CutClaw 的研究动机是模拟一个专业后期团队的协作流程。在真实的影视后期里,一支片子的诞生通常要经过编剧、剪辑、审片这几个环节,而 CutClaw 把这三种角色都做成了智能体,让它们围绕同一段音乐协同工作。值得一提的是,这种"模拟真实工作流"的设计思路,在最近一年的多智能体研究里已经成为一个明显的趋势——大家逐渐意识到,与其让一个超大模型一次性解决所有问题,不如把任务拆给多个小一点但分工明确的智能体,效果反而更稳。CutClaw 在视频剪辑这个具体场景下把这套思路落地了,而且落地得相当漂亮。下面这部分,我们就来看看这套流水线到底是怎么转起来的。

三、原理拆解:从一堆素材到一支成片,中间到底发生了什么

要把 CutClaw 的工作原理讲明白,最直观的方式是顺着数据流走一遍。一个完整的处理过程,可以划成四个大阶段:素材解构 → 编剧规划 → 剪辑执行 → 审片优化。

3.1 第一阶段:自下而上的素材解构

这是整个系统的地基。它要解决的核心问题是:几小时的视频和几分钟的音乐,信息密度差太多,直接塞给大模型根本处理不了,必须先压缩成"模型读得懂的语义单元"。

视频这一侧的处理,大致分这么几步。系统会先用镜头边界检测把整段长视频切成一个个独立的镜头(shot);接着把镜头按场景(scene)聚类,把视觉上连贯的一段镜头归到一起;然后调用视觉理解模型对每个镜头进行密集描述,生成结构化的"视觉字幕",字段一般包括摄影手法(广角/特写/航拍)、人物动态、环境氛围、主体位置、情绪倾向等等。换句话说,一段几小时的素材,在这一步之后会被翻译成一份带时间戳的、可检索的、结构化的描述清单。

音频这一侧的处理也是类似的思路,但走的是音乐结构分析的路子。系统会先做节拍跟踪,提取出每一拍的精确时间;再做音乐结构分割,把整段音乐切分成 intro(前奏)、verse(主歌)、chorus(副歌)、bridge(桥段)、outro(尾奏)这样的段落;同时还会提取能量曲线、音高轮廓、频谱重心等特征,用来判断每个段落的情绪强度。如果音乐里有人声和歌词,系统也会顺带做 ASR(自动语音识别),把歌词作为额外的语义线索。

这个解构阶段听起来像是预处理,但它其实是 CutClaw 能够处理"小时级"长素材的关键。因为经过这一步,几个小时的原始数据被压缩成了几页结构化的 JSON,后面的智能体就可以在这份"目录"上做规划,而不需要再反复扫描原始视频。同时,这些结构化数据还会被缓存下来,下次你想用同一份素材剪一支新的成片时,可以直接复用,速度会快很多。

这里再补一个容易被忽视的细节。视觉字幕这一步生成的不是一句话描述,而是一份多字段的结构化记录。你可以把它想象成数据库里的一行,每一行里既有"这个镜头里出现了什么",也有"这个镜头是怎么拍的",还有"这个镜头看起来情绪是什么"。这种多维度的描述对后面的检索特别重要——Playwriter 在规划副歌段落的时候,可能会要求"广角、明亮、有人物快速运动",Editor 拿到这个要求之后能直接在字段上做匹配,而不是去做模糊的语义比对。结构化数据比自由文本好用得多,这是工程上一个非常关键的判断。

音频解析这块还有一个值得拉出来单说的点,叫"能量曲线"。它本质上是用一条随时间变化的数值曲线,记录每一秒音乐的"激烈程度"。你可以把它理解成把整首歌的情绪强度画成了一条心电图。Playwriter 在做规划的时候,会拿这条曲线和视觉素材的"强度"做对应——能量低谷的地方安排平静的镜头,能量高峰的地方安排冲击力强的镜头。这种对应不是简单的"快歌配快剪",而是真的让画面的呼吸跟着音乐起伏。这一点在传统的剪辑工具里基本看不到,因为传统工具最多做到节拍同步,做不到能量同步。

我自己第一次看到 CutClaw 的解构结果文件时,有一个直观的感受是它非常像一份"素材索引簿"。视频部分是一份按时间排序的镜头清单,音频部分是一份带情绪标签的段落清单,两份清单的时间轴是对齐的。你完全可以脱离最终成片,只看这份索引簿,就能猜出 AI 接下来打算怎么剪。这种"过程可读"的设计,是很多黑盒 AI 工具不具备的优点,也是莫潇羽@源码七号站特别欣赏 CutClaw 的一点。

3.2 第二阶段:Playwriter——音乐锚定的全局编剧

素材解构完之后,接力棒交给 Playwriter Agent,也就是"编剧"。这个角色的定位是全局规划者,它的任务不是去选具体某一秒的画面,而是要先把整支片子的故事骨架搭出来。

Playwriter 的输入有三样:一份音乐结构图(每个段落的时间、能量、情绪标签),一份视觉素材的语义清单,以及用户给的那一句文字指令(比如"剪一支节奏明快的城市旅拍 vlog"或者"做一支安静怀旧的回忆向短片")。它的输出是一份镜头计划(shot plan),告诉下游的 Editor:在音乐的哪一段,应该出现什么样的视觉内容,大致是什么情绪、什么景别、什么节奏。

这里有一个非常关键的设计——音乐结构是不可变的时间锚。Playwriter 不会去动音乐,它只会把视觉叙事往音乐的骨架上对齐。副歌通常是情绪最饱满的地方,Playwriter 就会在这里安排冲击力强的画面;主歌相对平缓,适合铺陈和抒情;桥段是过渡,适合穿插一些转场和情绪铺垫。这种"以音乐为锚"的规划方式,从根本上决定了成片的节奏感。

用户的文字指令在这一步起的是"风格调味剂"的作用。同样一段素材和同一首音乐,你写"快节奏的运动剪辑"和"舒缓的人物特写蒙太奇",Playwriter 给出的镜头计划会完全不一样。这就是为什么文档里说一句话指令可以指挥整个系统——它不是关键词匹配,而是大模型对你意图的整体理解。

更进一步说,Playwriter 在生成镜头计划时,内部其实做了一件挺像人类编剧工作的事情:它会先在脑子里(也就是上下文里)把整支片子的情绪曲线画一遍,然后逐段决定每一段要承担什么样的叙事功能。前奏一般是定调,告诉观众"我们要看的是一个什么样的故事";主歌是铺陈,把人物、地点、动作慢慢交代清楚;副歌是高潮,把情绪推到最满;桥段是反转或喘息,给副歌之间留出对比;尾奏是收束,通常会回到开头的某个意象,让整支片子有"环形结构"的完整感。这种叙事节奏的把控,正是过去模板类工具完全做不到的地方,因为模板没办法理解"故事要往哪里走"。

Playwriter 输出的镜头计划通常是一份分段的结构化文档,每一段会标明对应的音乐时间区间、目标镜头数量、情绪基调、关键视觉元素、与上一段的衔接关系。这份文档既是 Editor 的工作清单,也是 Reviewer 后续做评估时的参考标准。可以说整支片子的灵魂在 Playwriter 这一步就已经定下来了,后面 Editor 和 Reviewer 做的都是"如何把这个灵魂落地"的事情。

3.3 第三阶段:Editor 与 Reviewer 的协同博弈

镜头计划只是骨架,还没有落实到具体某一段视频的某一秒。这一步交给两个智能体配合完成:Editor(剪辑师)负责选,Reviewer(审片人)负责审。

Editor 的工作方式是"自顶向下的细粒度视觉接地"。它拿着 Playwriter 给的镜头计划,到素材库里去找最匹配的片段。具体来说,它会先按语义检索(比如"日落时分海边奔跑的人"),把候选镜头筛出来;再做时间戳层级的精挑细选,精确到这个镜头里要用哪几秒、要从哪一帧开始切、在哪一帧结束。每一个剪辑点的选择,都要满足两个条件:语义上贴合 Playwriter 的描述,以及时间上对齐到对应的音乐拍点。

但 Editor 不是一锤子买卖。每次它给出一份候选剪辑方案,Reviewer 都会对这份方案做评估。Reviewer 关注的维度比 Editor 更宏观,大致包括:画面美学质量(构图、曝光、稳定性)、与指令的契合度、与音乐节奏的同步度、整体叙事的连贯性。如果 Reviewer 发现某些镜头不达标,会把意见反馈给 Editor,Editor 再去重选或者微调。这个"剪—审—改"的循环会迭代多轮,直到 Reviewer 给出通过。

这种设计其实非常像现实中的后期工作流:一个剪辑师埋头剪,一个导演坐在后面看,看不顺眼就让你重剪。CutClaw 把这两个角色都搬进了系统里,而且让它们以对话的方式协作,这是它出片质量明显优于"一次性生成"类工具的原因之一。

这里再展开一点,讲讲为什么"两个智能体协作"会比"一个智能体自己做完"效果更好。从工程经验上看,大模型在做创造性任务时有一个普遍现象:它生成的第一版结果往往是"中规中矩"的安全选项,缺少灵感和细节;但如果你让它对自己的输出做批评和反思,再让它根据批评去重做,第二版结果通常会明显更好。这种"生成—批评—重做"的循环,在大模型领域有个名字叫 self-refine,被证明能在很多任务上带来稳定的质量提升。

CutClaw 把这个机制做成了双角色,而不是让同一个模型既当 Editor 又当 Reviewer,这背后有两层考量。一层是角色分工带来的"立场清晰"——Editor 的目标是把镜头拼出来,Reviewer 的目标是挑毛病,两个角色各有各的偏好,不会因为同一个模型既要"自夸"又要"自批"而产生角色混淆。另一层是可以给两个角色配不同的模型,比如让 Editor 用一个更擅长视觉细节的模型,让 Reviewer 用一个更擅长综合判断的模型,这样组合的总体效果会比单模型更稳。

实际跑下来你会发现,Reviewer 给出的反馈往往非常具体,不是泛泛地说"这段不好",而是会指出"第三个镜头的运动方向和上一个镜头冲突,造成视觉跳脱"或者"副歌第二句的画面和音乐能量不匹配,情绪没起来"。这种细粒度的反馈让 Editor 能精准地知道要改哪里,而不是把整条时间轴推倒重来。

3.4 第四阶段:渲染与内容感知裁剪

所有镜头都敲定之后,系统会进入最终的渲染阶段。这一步除了把片段拼接、对齐音轨之外,还有一个很实用的特性——内容感知裁剪。

现在的短视频要发抖音、视频号、小红书、YouTube Shorts,每个平台的画面比例都不一样,9:16、1:1、4:5、16:9 全都有。传统做法是要么手动重新构图,要么粗暴地居中裁切,经常会把主体裁掉一半。CutClaw 的思路是先用视觉模型识别出每一帧里的核心主体(人物、动物、关键物体),然后让裁剪框跟着主体走,在不同比例下都尽量保留视觉重心。这个细节看起来不起眼,但在批量发布的场景里能省掉非常多的二次返工。

到这里,一支由 AI 剪出来的、踩着音乐节奏、满足你文字指令的短片,就正式产出了。

四、CutClaw 和"普通 AI 剪辑工具"的本质区别

把原理讲完,再回过头来对比一下,可能更容易理解 CutClaw 到底强在哪里。莫潇羽@源码七号站这里整理了一张对比表,方便快速看清差异。

这张表里我个人觉得最容易被忽视、但实际价值最高的一项,是"素材复用"。因为长视频的解构是 CutClaw 里最耗时的一步,而一旦解构完成,这份语义化的素材库就变成了你自己的"可检索资产":今天用它剪一支快节奏运动片,明天用它剪一支抒情回忆向,后天再剪一支竖屏广告,都不需要从头处理。这对于经常输出多版本内容的创作者来说,几乎等于把剪辑流程的边际成本压到了接近零。

五、快速上手:本地部署的完整流程

讲完原理,我们来看怎么把这套系统在自己的机器上跑起来。CutClaw 的官方仓库给出了非常清晰的部署步骤,下面我把整个过程拆开,顺带补充一些自己踩过的小坑。

5.1 环境准备

CutClaw 的依赖比较干净,基本就是 Python 生态那一套。建议使用 Conda 来管理环境,避免和系统里其他项目打架。

# 克隆仓库
git clone https://github.com/GVCLab/CutClaw.git
cd CutClaw

# 创建并激活独立环境
conda create -n CutClaw python=3.12
conda activate CutClaw

# 安装依赖
pip install -r requirements.txt

这里有一个细节值得提一下:官方强烈建议安装支持 GPU 加速的 Decord 或 NVDEC 构建版本,用来做视频解码。原因很现实——长素材的解码本身就是一个 IO 和算力密集的过程,如果用 CPU 解码,几个小时的视频光是抽帧就要等很久。如果你的机器有 NVIDIA 显卡,务必把硬解码这一步配上,后续的素材解构阶段速度会有量级差异。

5.2 素材目录结构

CutClaw 对素材目录有一套约定俗成的结构,启动之前先把文件按下面的方式摆好:

resource/
├── video/      # 放原始视频,支持 .mp4 / .mkv 等常见格式
├── audio/      # 放配乐文件,支持 .mp3 / .wav
└── subtitle/   # 可选的 .srt 字幕文件

subtitle 目录是可选的,但很值得用一下。如果你的视频里有人说话,提前提供一份现成的字幕文件,可以让系统跳过 ASR 环节,既节省时间又能避免 ASR 识别错误带来的语义偏差。

5.3 启动方式一:Streamlit 可视化界面(推荐新手)

对于第一次接触这个项目的朋友,我建议直接用官方提供的可视化界面。命令很简单:

streamlit run app.py

执行之后,浏览器里访问 http://localhost:8501 就能看到操作界面。在界面里,你可以下拉选择已经放进 resource/video 和 resource/audio 的文件,在指令框里输入一句话(比如"做一支节奏明快的城市夜景 vlog,突出霓虹和人流"),点击运行,剩下的就交给系统。

可视化界面的好处是参数都有默认值,你不需要去记任何命令行选项,适合先把流程跑通、对系统的能力有一个直观感受。

5.4 启动方式二:命令行(适合脚本化和批量任务)

跑通流程之后,如果你想把 CutClaw 集成到自己的工作流里,或者要批量处理多支片子,命令行的方式更灵活。

python local_run.py \
  --Video_Path "resource/video/your_video.mp4" \
  --Audio_Path "resource/audio/your_music.mp3" \
  --Instruction "你的剪辑指令"

这是最基本的调用方式,三个必填参数分别是视频路径、音频路径和文字指令。系统会按默认配置跑完整条流水线,把成片输出到 output/ 目录下。

如果你想对流程做更精细的控制,可以通过 --config.XXX 的方式覆盖默认参数,比如:

python local_run.py \
  --Video_Path "resource/video/travel_day1.mp4" \
  --Audio_Path "resource/audio/upbeat.mp3" \
  --Instruction "把当天的高光时刻剪成一支 60 秒的短片,以海边和日落为情绪高潮" \
  --config.MAIN_CHARACTER_NAME "Alex" \
  --config.VIDEO_FPS 2 \
  --config.AUDIO_TOTAL_SHOTS 50

这里几个参数稍微解释一下。MAIN_CHARACTER_NAME 用来告诉系统主角是谁,这样在素材解构和镜头检索阶段,系统会更倾向于保留有主角出现的镜头,出来的成片更有人物中心感。VIDEO_FPS 控制抽帧密度,默认值通常足够,如果你的素材里运动镜头特别多,可以适当调高,代价是处理时间会变长。AUDIO_TOTAL_SHOTS 是最终成片里的镜头总数,数值越大节奏越快、剪点越多,反之节奏越缓。

六、模型选择与 LiteLLM 网关

CutClaw 本身不绑定具体的某一个大模型,而是通过 LiteLLM 这个 API 网关来统一调度。也就是说,你可以根据自己的资源情况和偏好,把不同环节的模型替换成不同的厂商或者本地部署的版本。LiteLLM 的模型名称一般是 provider/model-name 的格式,比如 openai/gpt-5 或 anthropic/claude-4.5。

按照官方的推荐组合,系统里大致分三类角色,每类角色有比较适合的模型:

视频理解这一层,主要任务是对镜头和场景进行语义描述,需要模型有比较强的视觉细节捕捉能力,Gemini 3、Qwen3-VL、GPT-5 这一档的模型都能胜任。如果你想压成本,也可以选择参数量更小但视觉能力够用的开源 VLM,代价是描述粒度会粗一些。

音频处理这一层,既要做 ASR(把人声转成文字),也要做音乐结构解析。Gemini 3 这类多模态模型在这两个任务上表现都不错。如果你已经有现成的字幕,ASR 这一步可以省掉,音乐结构解析的部分对模型的多模态能力依赖也会小很多。

智能体这一层,也就是 Playwriter、Editor、Reviewer 这三个角色,需要模型有比较强的规划、推理和指令跟随能力。MiniMax、Kimi、Claude 4.5 这类对长上下文友好、推理稳定的模型是比较合适的选择。Editor 和 Reviewer 之间的多轮迭代特别吃模型的"听话程度",所以如果你发现成片质量不稳定,首先要考虑的是不是这一层的模型选小了。

LiteLLM 的好处在于,你不需要为每个模型单独写适配代码。在 CutClaw 的配置文件里,把模型名称换成你想用的那个,API key 设置好,就能直接生效。这种解耦设计让 CutClaw 在未来面对新模型时能很快适配,也让用户可以按自己的预算和延迟需求去做组合。

如果你想在本地部署中尽量降低对外部 API 的依赖,可以考虑这样的组合:视觉理解层用本地部署的 Qwen3-VL 或者 InternVL,音频解析层用开源的 Whisper 加上音乐结构分析的开源库,智能体层用本地的 Qwen 或 DeepSeek。这种纯本地的方案对硬件要求会高一些,通常需要一张显存比较大的显卡,但好处是数据完全不出本机,适合对素材保密要求高的场景。

另一种思路是混合部署:把素材解构这种重计算、低对话频率的任务放在本地,把智能体的对话推理放在云端 API。这种组合既能控制成本,又能享受云端大模型的推理能力。具体怎么搭,要看你手边的资源,源码七号站后面会出一篇专门的"模型组合实战"来对比不同搭配下的效果差异。

七、典型使用场景与实操建议

讲完技术细节,我们来聊聊几个比较典型的使用场景,以及在每个场景下我自己摸索出来的一些经验。这部分内容,源码七号站后面也会陆续更新更详细的手把手教程,感兴趣的朋友可以关注 www.fuyuan7.com 上的开源专栏。

7.1 旅拍 Vlog 的快速成片

这是最直接的应用场景。一天的拍摄,几个小时的素材,如果按传统方式去剪,至少要花一个晚上。用 CutClaw 的话,流程大概是这样的:把当天所有的素材合并(或者直接放进同一个目录),挑一首和当天调性匹配的音乐,写一句指令描述你想要的风格,剩下的交给系统。

我自己的经验是,指令不要写得太抽象,尽量给出几个明确的关键词。比如不要只写"做一支旅拍",而是写"以海岸线为主线,突出两个人物的互动,情绪从清晨的安静到傍晚的热烈,节奏中等偏快"。这样的指令能让 Playwriter 的规划更有方向感,出来的成片也更接近你的预期。

7.2 多版本的内容批量产出

如果你需要为