Claude Sonnet 5.5全面实测：视频制作、Computer Use、iOS/macOS开发与Godot游戏开发

1. 从一条标题说起为什么我花了两周时间死磕这个模型看到“Claude Sonnet 5.5全面实测”这个标题的时候我第一反应是又来了每次新模型发布都有人喊“超越GPT”结果上手一跑该翻车还是翻车。但这次不太一样——标题里提到的几个方向视频制作、Computer Use、iOS和macOS原生APP开发、Godot游戏开发恰好覆盖了我日常工作中最核心的几条流水线。我平时接的活儿比较杂既有短视频的批量剪辑和生成也有帮客户做iOS端的小工具偶尔还接一些独立游戏的开发外包。所以我没有犹豫直接花了两周时间把手上正在跑的五个项目全部切到这个模型上重新做了一遍目的很简单看看它到底能不能打哪些场景真的能提效哪些场景是吹出来的。这篇文章不是那种“跑个demo就发结论”的评测。我会把每个方向的实测过程、踩过的坑、最终跑通的方案全部摊开来讲。如果你是做视频自动化的、在折腾Computer Use的、或者正在用Godot做独立游戏的这篇内容应该能帮你省下不少试错时间。如果你只是好奇这个模型到底能不能替代现有的工作流我也会给出非常具体的判断依据而不是模棱两可的“看情况”。先说结论方向它在代码生成和跨应用操作上的进步是实打实的尤其是Computer Use这一块比我之前用的方案稳定了不止一个档次。但在视频制作和Godot游戏开发这两个方向上它的表现是“能用但需要大量人工兜底”离“全自动”还有相当距离。下面我按模块拆开讲每个模块都会给出具体的操作步骤、参数配置和实测数据。2. 视频制作能力实测从脚本到成片的完整链路2.1 我搭建的测试环境与素材规格为了测试视频制作能力我准备了三组不同复杂度的素材。第一组是纯文本脚本转短视频时长控制在60秒以内画面以文字动画和简单转场为主。第二组是带配音的口播视频需要模型根据脚本自动匹配画面素材和背景音乐。第三组是产品演示视频需要从一段录屏中自动提取关键帧、添加标注和缩放效果。硬件环境是一台M1 Max的MacBook Pro32GB内存系统版本是macOS Sonoma。软件层面我用了FFmpeg 6.0作为底层处理工具配合一个自己写的Python调度脚本。模型接入方式是通过API调用每次请求带上完整的脚本和素材描述。这里要说明一点我测试的不是某个特定的视频编辑软件内置的AI功能而是直接调用模型能力来生成可执行的FFmpeg命令和剪辑决策。第一轮测试下来最直观的感受是模型对视频结构的理解比上一代强了很多。你给它一段脚本它能自动拆解成“开场钩子-核心内容-结尾引导”这样的三段式结构并且为每个段落推荐合适的画面类型。比如开场部分它会建议用动态文字加快速转场核心内容部分建议用实拍素材或屏幕录制结尾部分建议用固定画面加订阅引导。这个拆解逻辑是合理的符合短视频的完播率优化原则。但问题出在具体执行层面。模型生成的FFmpeg命令经常有参数错误比如滤镜链的拼接顺序不对、编码器参数和容器格式不匹配。我统计了一下第一轮生成的50条命令里能直接跑通的只有12条剩下的都需要手动修正。修正的主要类型包括-vf和-af的顺序颠倒、-c:v libx264和-c:v h264的混用、以及时间戳相关的-ss和-t参数位置错误。2.2 脚本转分镜的提示词设计技巧经过几轮调整我摸索出了一套比较稳定的提示词模板。核心思路是不要让模型直接生成最终命令而是让它先输出结构化的分镜描述我再根据分镜描述来生成命令。这样做的原因是模型在自然语言描述层面的准确率远高于直接生成代码层面的准确率。具体模板是这样的首先给模型一个角色设定比如“你是一个有十年经验的短视频剪辑师擅长把口播脚本转化为高完播率的分镜方案”。然后给出约束条件包括视频总时长、目标平台抖音/视频号/YouTube Shorts、画面比例、是否有人出镜。接着提供脚本原文要求模型按以下格式输出每个分镜包含时间区间、画面类型、文字内容、转场方式、音效建议。最后加一句“只输出分镜表格不要输出任何解释性文字”。实测下来这个模板的可用率能达到85%以上。模型输出的分镜表格可以直接导入到我的调度脚本里由脚本根据画面类型去素材库匹配对应的视频片段或图片。匹配逻辑是我自己写的用到了简单的文本相似度计算和标签匹配。这里有个小技巧在素材库的元数据里提前打好标签比如“城市夜景”“办公室”“产品特写”“人物微笑”等模型输出的画面类型描述只要包含这些关键词就能自动匹配上。2.3 自动剪辑中的参数计算与避坑要点自动剪辑环节最核心的参数是转场时长和背景音乐淡入淡出时间。我一开始让模型自己决定这些参数结果它给出的转场时长从0.1秒到2秒不等完全没有规律。后来我改成固定规则硬切转场0秒叠化转场0.5秒滑动转场0.3秒缩放转场0.4秒。背景音乐淡入1.5秒淡出2秒人声出现时音乐音量降到-18dB人声结束时恢复到-12dB。这些参数不是拍脑袋定的。转场时长0.5秒左右是经过验证的短于0.3秒观众几乎感知不到长于0.8秒会显得拖沓。背景音乐淡入1.5秒是为了避免音乐突然切入的突兀感淡出2秒是为了让结尾更自然。人声和音乐的音量差控制在6dB左右既能保证人声清晰又不会让音乐完全消失。注意模型生成的音量调整参数经常用线性值而不是分贝值比如它写volume0.5但实际想要的是volume-6dB。这两个值差很远0.5的线性值约等于-6dB但如果是0.3的线性值就约等于-10.5dB。建议在脚本里统一做一次转换避免音量忽大忽小。还有一个坑是帧率匹配。模型默认按30fps生成时间参数但我的素材库里有25fps和60fps的片段。如果直接拼接会出现音画不同步或者画面卡顿。解决办法是在FFmpeg命令里统一加-r 30强制输出帧率同时对非30fps的素材先做一次帧率转换。这个转换会稍微增加处理时间但能保证最终成片的流畅度。2.4 实测数据与效果评估三组素材跑完我记录了一些关键数据。第一组纯文本转短视频从脚本输入到成片输出平均耗时4分20秒其中模型调用占1分10秒FFmpeg渲染占3分10秒。成片质量方面画面节奏和文字动画的配合度不错但文字排版偶尔会出现溢出画面边界的情况需要手动调整字体大小和位置。第二组口播视频平均耗时7分50秒主要时间花在素材匹配和音频对齐上。模型在匹配画面素材时的准确率大约是70%也就是说有30%的画面需要我手动替换。替换的原因主要是素材库覆盖不足比如脚本里提到“海边日落”但素材库里只有“城市日落”模型就硬匹配了一个城市日落的片段导致画面和文案不符。第三组产品演示视频平均耗时12分钟这个环节模型的表现最差。它很难理解录屏中的操作逻辑比如什么时候该放大某个按钮、什么时候该添加箭头标注。我最后是手动标注了关键时间点然后让模型根据时间点生成缩放和标注命令。即便如此生成的命令还是有20%左右需要修正。综合来看视频制作这个方向模型能帮你省掉分镜设计和命令编写的时间大约能提升40%的效率。但素材匹配和精细调整仍然需要大量人工介入。如果你的素材库足够丰富且标签体系完善效率提升会更明显。如果素材库比较杂建议还是以人工剪辑为主模型辅助生成分镜和命令。3. Computer Use能力深度拆解从“玩具”到“工具”的跨越3.1 Computer Use到底能做什么Computer Use这个概念简单说就是让模型直接操作电脑界面像人一样点击按钮、输入文字、拖拽窗口。我最早接触这类能力是在去年当时试了几个方案最大的感受是“演示很惊艳实用很崩溃”。因为模型经常点错位置、识别错元素、或者在某个弹窗上卡死。但这次Sonnet 5.5的Computer Use能力让我第一次觉得这个东西可以真正放进工作流里了。我测试的场景主要有三个第一是自动化填写网页表单比如批量提交产品信息到多个平台。第二是跨应用的数据搬运比如从邮件里提取附件、保存到本地文件夹、再上传到云盘。第三是软件操作自动化比如在图像处理软件里批量执行“打开图片-调整尺寸-添加水印-导出”这一套动作。3.2 元素定位的稳定性与容错机制Computer Use最核心的能力是元素定位。模型需要根据屏幕截图判断哪个位置是按钮、哪个位置是输入框、哪个位置是下拉菜单。我实测下来在标准分辨率和常见UI框架下定位准确率能达到90%以上。但在以下几种情况下会翻车一是自定义绘制的控件比如游戏界面或某些设计软件的工具面板二是动态加载的内容比如无限滚动的列表三是弹窗和遮罩层模型有时候会忽略弹窗的存在继续操作底层的元素。针对这些问题我总结了几条实操经验。第一尽量在操作前把窗口最大化减少界面元素的相对位置变化。第二对于动态内容先让模型执行一次滚动到底部的操作确保所有元素都加载出来。第三遇到弹窗时先让模型识别弹窗的关闭按钮或确认按钮处理完弹窗再继续后续操作。第四给模型提供一些辅助信息比如“当前页面有一个登录弹窗请先关闭它”这样能显著降低误操作的概率。提示模型对按钮文字的识别能力很强但对图标按钮的识别能力较弱。如果界面上有纯图标的按钮建议提前在提示词里描述清楚比如“右上角有一个齿轮形状的设置按钮”。3.3 跨应用操作的实际表现跨应用操作是Computer Use最有价值的部分也是最容易出问题的部分。我测试了一个典型场景从邮件客户端读取一封包含附件的邮件把附件保存到指定文件夹然后用压缩软件打包最后通过浏览器上传到云盘。整个流程涉及四个应用模型需要自己切换窗口、识别当前应用、执行对应操作。实测结果是在macOS上这个流程的完成率大约是75%。失败的情况主要有两种一是切换应用时焦点没有正确转移导致后续操作作用在了错误的窗口上二是文件保存对话框的路径输入框识别错误模型把路径输入到了文件名输入框里。针对第一个问题我的解决办法是在每次切换应用后加一个“等待0.5秒并确认当前活动窗口标题”的步骤。针对第二个问题我改成用快捷键调出路径输入在macOS的保存对话框里按CommandShiftG然后输入路径这样比直接点击路径输入框更稳定。在Windows上完成率略低一些大约是65%。主要差异在于Windows的窗口管理逻辑更复杂而且不同应用的UI框架差异更大。不过Windows上有一个优势很多操作可以通过命令行完成所以我在Windows上会混合使用Computer Use和命令行脚本把适合命令行的步骤交给脚本把必须图形界面操作的步骤交给模型。3.4 性能开销与并发策略Computer Use的性能开销主要来自屏幕截图的传输和模型推理。每次操作前都需要截一张图发给模型模型返回操作指令后再执行。这个往返时间在本地网络环境下大约是1.5到2秒。如果操作步骤很多累积起来就很可观了。我测试的那个四应用流程总共执行了23步操作耗时约45秒。如果纯手工操作熟练的话大概20秒能完成。所以从单次操作来看Computer Use并不比人快。但它的优势在于可以并发。我同时开了三个虚拟机实例每个实例跑一个Computer Use任务三个任务并行执行。这样总体吞吐量就上去了。不过并发也带来了新的问题资源竞争。三个实例同时截图和推理CPU和内存占用都很高。我的配置是每个实例分配4核CPU和8GB内存三个实例跑起来后系统负载在70%左右还能接受。如果再加实例就需要升级硬件了。还有一个实际问题是错误处理。并发执行时如果某个实例卡住了很难及时发现。我的做法是给每个任务设置超时时间比如单步操作超过10秒没有进展就判定为失败然后自动重启该实例的任务。这个超时时间需要根据具体操作的复杂度来调整简单的点击操作5秒就够了复杂的表单填写可能需要15秒。4. iOS与macOS原生APP开发从零到上架的完整记录4.1 开发环境搭建与项目初始化用Sonnet 5.5来辅助iOS和macOS开发我的整体感受是它像一个非常熟悉Swift和SwiftUI的搭档能帮你快速写出可运行的代码但在架构设计和细节处理上还需要你自己把关。我这次用两周时间做了一个macOS端的菜单栏工具和一个iOS端的习惯打卡应用两个项目都是从零开始最终都成功上架了。开发环境是Xcode 15.4Swift 5.10最低支持版本iOS 16和macOS 13。项目初始化阶段我让模型帮我生成项目结构。具体做法是描述清楚应用的功能、目标平台、需要的页面和核心交互然后让模型输出一个文件目录树和每个文件的职责说明。这个环节模型表现很好生成的目录结构清晰合理符合MVVM架构的常见组织方式。比如macOS菜单栏工具模型建议的结构是AppDelegate.swift负责生命周期和菜单栏图标管理StatusBarController.swift负责菜单项的构建和事件处理SettingsWindowController.swift负责偏好设置窗口Services/目录放业务逻辑Models/目录放数据模型。这个结构比我平时随手写的要规范后续维护起来确实方便。4.2 SwiftUI界面代码的生成质量SwiftUI代码生成是这次测试的重点。我让模型生成了大约30个界面组件包括列表、表单、详情页、设置页、弹窗等。整体来看代码的语法正确率很高基本没有编译错误。但在布局细节上经常需要手动调整。一个典型问题是间距和对齐。模型生成的VStack和HStack经常缺少spacing参数或者padding的值不符合苹果的人机界面指南。比如它会给一个按钮加.padding(.horizontal, 20)但按照iOS的规范标准按钮的水平内边距应该是16点。这种小偏差积累多了界面看起来就会有点“不对劲”但又说不上哪里不对。我的解决办法是在提示词里明确指定设计规范。比如“请遵循苹果人机界面指南标准间距使用8的倍数按钮水平内边距16点垂直内边距12点圆角半径10点”。加上这些约束后生成的代码明显更规范了。另外我还会让模型在生成界面代码时同时输出一个预览用的PreviewProvider这样我可以直接在Xcode的预览里看到效果快速判断是否需要调整。4.3 数据持久化与网络层的实现细节数据持久化方面我测试了三种方案UserDefaults、文件存储和Core Data。模型对UserDefaults和文件存储的代码生成非常熟练基本一次通过。Core Data的代码生成稍微复杂一些需要提供数据模型描述模型才能生成对应的NSManagedObject子类和增删改查代码。这里有个小坑模型生成的Core Data代码默认使用NSPersistentContainer但在macOS上如果要用App Group做数据共享需要改成NSPersistentCloudKitContainer或者手动配置NSPersistentStoreDescription。这个细节模型不会主动提需要你自己在提示词里说明。网络层我用的URLSession配合async/await。模型生成的网络请求代码质量不错能正确处理错误和超时。但我发现它在处理Codable解析时偶尔会忽略可选字段的decodeIfPresent导致字段缺失时直接抛错。解决办法是在提示词里加一句“所有非必填字段使用decodeIfPresent并提供默认值”。加上之后就没再出现过这个问题。注意模型生成的网络代码默认没有做请求重试和缓存策略。如果你的应用对网络稳定性要求高需要自己补充重试逻辑和URLCache配置。我一般会加一个简单的指数退避重试最多重试3次间隔分别是1秒、2秒、4秒。4.4 上架流程中的自动化辅助上架环节是我觉得模型帮助最大的地方之一。iOS应用上架需要准备一堆材料应用图标、截图、描述文案、关键词、隐私政策链接等。模型可以帮你生成描述文案和关键词建议还能根据你的应用功能自动生成隐私政策模板。我实测下来生成的描述文案质量不错稍作修改就能用。关键词建议也比较合理覆盖了核心功能和常见搜索词。但上架过程中有一个环节模型帮不上忙证书和描述文件的配置。这部分需要在苹果开发者后台手动操作或者用fastlane这样的工具自动化。我这次是用fastlane match来管理证书用fastlane deliver来上传元数据。模型可以帮你生成Fastfile的配置代码但具体的证书生成和账号授权还是需要人工完成。另外App Store Connect的审核指南经常更新模型的知识可能不是最新的。我建议在提交前自己过一遍最新的审核指南特别是关于隐私权限和数据收集的部分。我这次就因为一个权限描述文案写得不够具体被审核打回来一次修改后重新提交才通过。5. Godot游戏开发实测从入门到做出可玩Demo5.1 Godot项目结构与GDScript代码生成Godot是我最近才开始用的引擎之前主要用Unity。这次借着测试模型的机会我用Godot 4.2做了一个2D平台跳跃游戏的Demo包含角色移动、跳跃、敌人巡逻、收集品和简单的关卡切换。整个项目从零开始大概花了三天时间其中模型帮我生成了大约70%的代码。Godot的项目结构比较灵活但也有一些约定俗成的组织方式。模型建议的结构是scenes/目录放场景文件scripts/目录放GDScript脚本assets/目录放图片和音频autoload/目录放全局单例。这个结构清晰易懂我后续找文件很方便。GDScript的代码生成质量整体不错。角色移动的代码模型生成的版本包含了加速度、减速度、最大速度、跳跃高度、土狼时间coyote time和跳跃缓冲jump buffer这些常见参数。土狼时间和跳跃缓冲是平台跳跃游戏的手感优化技巧模型能主动考虑到这些说明它对游戏开发领域有足够的理解。不过参数的具体数值需要自己调模型给的默认值偏保守手感偏“重”我调了几轮才找到合适的值。5.2 场景搭建与节点组织的实操要点Godot的场景系统是基于节点的每个场景是一个节点树。模型在生成场景代码时会输出一个.tscn文件的文本内容。这个文本格式是Godot特有的模型生成的基本正确但偶尔会有节点路径写错或者属性名拼错的情况。我踩过的一个坑是模型生成的CharacterBody2D节点在_physics_process函数里直接用了velocity属性但忘记调用move_and_slide()。结果角色能接收输入但不会移动。这个错误很隐蔽因为代码不报错只是没效果。后来我在提示词里加了一句“确保在_physics_process末尾调用move_and_slide()”就没再出现过。另一个坑是碰撞层的设置。Godot的碰撞系统用层layer和掩码mask来控制哪些物体可以碰撞。模型生成的代码经常忘记设置碰撞层导致角色和敌人、收集品之间的碰撞检测失效。解决办法是在场景初始化时显式设置collision_layer和collision_mask的值。我一般把角色放在第1层敌人放在第2层收集品放在第3层地形放在第4层。然后角色的掩码设置为1234敌人的掩码设置为14收集品的掩码设置为1。5.3 游戏逻辑中的状态管理与信号传递Godot的信号signal机制是解耦游戏逻辑的关键。模型对信号的使用比较熟练能正确生成signal定义、emit_signal调用和connect连接。但在复杂的游戏状态管理中模型生成的代码有时候会过度依赖信号导致逻辑分散在各个脚本里难以追踪。我的做法是对于简单的交互比如“玩家碰到收集品收集品消失并加分”用信号连接很合适。但对于核心游戏状态比如“游戏开始-进行中-暂停-结束”我会用一个全局的GameManager单例来管理通过状态机模式来切换。模型可以帮你生成状态机的框架代码但状态之间的转换条件和具体逻辑需要你自己定义清楚。这里分享一个实用技巧在提示词里明确要求模型“使用状态机模式管理游戏状态状态转换条件用枚举定义每个状态有独立的进入、更新、退出函数”。这样生成的代码结构清晰后续扩展新状态也很方便。我这次做的Demo里游戏状态机就用了这个模式后来加了一个“关卡完成”状态只花了十分钟就接进去了。5.4 导出与跨平台发布的注意事项Godot的导出流程相对简单但也有一些需要注意的地方。我这次导出了macOS和iOS两个平台。macOS导出比较顺利配置好导出模板和签名证书后直接导出.app文件就能运行。iOS导出稍微麻烦一些需要在导出设置里填写Bundle ID、团队ID和签名证书信息然后导出Xcode项目再用Xcode编译和上架。模型可以帮你生成导出配置的说明文档但具体的证书和描述文件配置还是需要手动完成。另外Godot 4.2的iOS导出插件还在完善中有些功能可能不稳定。我测试下来基本的2D渲染和触摸输入没问题但音频播放偶尔会有延迟。如果要做商业项目建议先在真机上充分测试。提示Godot的导出模板需要单独下载而且版本要和编辑器版本严格匹配。我一开始用了4.1的导出模板配4.2的编辑器结果导出失败报了一堆看不懂的错误。后来下载了4.2对应的导出模板才解决。这个坑很隐蔽因为编辑器不会提示你模板版本不匹配。6. 常见问题与排查技巧实录6.1 模型调用层面的高频问题在实际使用中我遇到最多的模型调用问题是超时和返回格式错误。超时通常发生在请求内容较长的时候比如一次性让模型生成整个项目的代码。解决办法是把大请求拆成小请求比如按文件拆分每次只生成一个文件的代码。返回格式错误主要是模型没有严格按照要求的格式输出比如要求输出JSON但实际输出了Markdown。解决办法是在提示词里加一句“只输出JSON不要输出任何其他文字”并且在代码里做一次格式校验如果解析失败就重试。还有一个问题是模型的“幻觉”。它有时候会引用不存在的API或者库函数。比如在生成Swift代码时它用了一个UIView.animateWithDuration的方法但正确的写法是UIView.animate(withDuration:)。这种错误在编译时会被发现但会浪费一些时间。我的做法是对于不熟悉的API先让模型输出API的签名和文档链接确认存在后再让它生成调用代码。6.2 视频制作中的音画同步排查音画不同步是视频制作中最常见的问题。排查思路是先检查素材的帧率和音频采样率是否一致再检查FFmpeg命令中的时间参数是否正确。我遇到过一次音频比画面快了0.5秒的情况原因是音频素材的采样率是44100Hz但命令里写的是48000Hz导致音频被加速了。解决办法是在命令里统一指定-ar 48000并且在拼接前用ffprobe检查每个素材的实际参数。另一个常见问题是转场处的黑帧。这通常是因为两个视频片段的时长计算不准确导致转场时出现了空白。解决办法是在拼接前先计算好每个片段的精确时长用-t参数截取确保片段之间没有间隙。如果用了xfade滤镜做转场还需要注意offset参数的计算它决定了转场从哪个时间点开始。6.3 Computer Use操作失败的快速定位Computer Use操作失败时第一步是看截图。模型每次操作前都会截一张图如果操作失败可以对比操作前后的截图看看界面发生了什么变化。常见的情况有点击位置偏移了几个像素、弹窗遮挡了目标元素、页面加载未完成导致元素不存在。第二步是看操作日志。模型返回的操作指令里包含了它识别到的元素描述和坐标。如果坐标明显不对说明元素定位出了问题。这时候可以尝试调整截图分辨率或者给模型提供更详细的界面描述。第三步是简化操作。如果某个步骤反复失败可以把它拆成更小的步骤。比如“填写表单并提交”可以拆成“点击姓名输入框-输入姓名-点击邮箱输入框-输入邮箱-点击提交按钮”。拆得越细每一步的成功率越高。6.4 移动端开发中的签名与证书问题iOS和macOS开发中签名和证书问题是最让人头疼的。常见错误包括证书过期、描述文件不匹配、Bundle ID冲突、权限配置缺失。排查方法是先在Xcode的“Signing Capabilities”面板里检查证书和描述文件的状态如果有红色警告点击“Try Again”让Xcode自动修复。如果自动修复失败就需要手动去开发者后台重新生成证书和描述文件。还有一个容易忽略的问题是权限描述文案。iOS应用如果使用了相机、相册、定位等权限必须在Info.plist里填写对应的描述文案。文案要具体说明用途不能写“需要此权限以提供服务”这种模糊表述。我这次就因为定位权限的描述文案写得太笼统被审核打回来一次。后来改成“用于在您打卡时记录当前位置方便您回顾打卡地点”就通过了。6.5 Godot开发中的常见报错与解决Godot开发中我遇到最多的报错是“Invalid call. Nonexistent function”和“Node not found”。前者通常是因为调用了不存在的函数或者函数名拼写错误。后者是因为节点路径写错了或者节点还没有被添加到场景树中。解决办法是用get_node_or_null代替get_node并在调用前检查节点是否存在。对于节点路径尽量使用相对路径而不是绝对路径这样场景结构变化时不容易出错。另一个常见问题是性能问题。Godot的2D渲染性能很好但如果场景中有大量节点或者每帧都在创建和销毁节点就会出现卡顿。解决办法是使用对象池来复用节点避免频繁的创建和销毁。模型可以帮你生成对象池的代码框架但池的大小和复用策略需要根据具体游戏来调整。7. 一些个人体会和后续可以尝试的方向两周的实测下来我对Sonnet 5.5的整体评价是它在代码生成和跨应用操作上的进步非常明显尤其是Computer Use的稳定性已经达到了可以放进生产环境的水平。视频制作和Godot游戏开发这两个方向它的表现是“辅助角色”能帮你省掉大量重复劳动但核心创意和精细调整还是得自己来。我目前还在尝试的一个方向是把Computer Use和视频制作结合起来让模型自动操作视频编辑软件完成一些重复性操作比如批量添加字幕、批量调整片段顺序。这个方向目前还在实验阶段主要难点在于视频编辑软件的界面比较复杂元素定位的准确率还不够稳定。如果后续有进展我会再整理一篇实操记录。另外对于想要上手这些能力的朋友我的建议是先从一个小场景开始比如用Computer Use自动填写一个表单或者用模型生成一个简单的SwiftUI界面。跑通之后再逐步扩大范围。不要一上来就搞大项目因为模型的能力边界需要你在实践中慢慢摸清楚哪些它能做好、哪些它做不好只有自己试过才知道。