最近在GitHub Trending上看到一个很有意思的项目，叫Goldie。简单来说，它是个编码Agent工具，专门帮iOS开发者自动生成App Store上架用的截图和预览视频，并且在导出素材的同时做一层苹果上架合规校验。我之所以第一时间就点进去，是因为每次发版本，最让人烦躁的就是凑齐那一堆设备尺寸的截图、处理预览视频，还要反复对照审核指南检查素材有没有踩线。这篇评测我会从工具原理、实操流程到踩坑记录完整过一遍，想给自己上架流程减负的开发者，或者对编码Agent这类工具真实落地场景感兴趣的朋友，都值得往下看。
1. 为什么我会盯上Goldie：上架素材这活儿早就该自动化了
1.1 手动做一套上架素材的真实工作量
在聊Goldie之前，先说说我自己的痛。你以为上架App Store最麻烦的是写代码、应付审核？对我这种独立开发者和几个人的小团队来说，最焦虑的反而是上架前那一堆视觉素材。
以一套标准的iPhone截图为例，App Store Connect要求你至少提供6.7英寸和6.5英寸两种尺寸的截图，如果你还有iPad版本，那又要一套。截图不是单纯把手机屏幕拍照导出来就行，你要用真机或模拟器跑进各个关键页面，保证状态栏时间正确、数据不是测试环境的脏数据、页面没有明显的开发期标识。然后按尺寸要求导出，有些还要做本地化，一套中英文下来，光截图就十几张。这还不算预览视频。视频要求15到30秒，要展示App的核心功能，又不能用广告式的剪辑，格式和编码都有讲究。
以前我干这些事的方式可以说相当原始：手动跑模拟器，找个好看的位置截图，再拖进Photoshop里改尺寸、调状态栏、标注释；视频则用QuickTime录屏，然后导进Final Cut剪一遍。一次发版，半天到一天就耗在这上面了。关键是这活儿没有任何技术含量，纯重复劳动，做完一点成就感都没有。
1.2 老方案Fastlane snapshot不够用的地方
后来我也用过Fastlane的snapshot和frameit，这确实是很多团队标配的方案。它能通过XCUITest自动在模拟器里跑一遍用例，把截图批量导出来，再用frameit套上手机外框，做基本的标注和文字说明。
但实际用下来，它有几个让我不太舒服的地方。一是它的定位更偏向“批量截图工具”，流程固定，你得自己维护XCUITest用例，如果App页面结构经常改，测试代码维护成本很高。二是它对预览视频这套逻辑支持得很弱，基本还是靠你手动录屏再合成。三是它不关心苹果的合规要求，尺寸对不对、状态栏时间是不是假的、页面里有没有第三方logo，它一概不管，最终把关还是得靠人肉。
所以Fastlane解决的是“把截图这件事从手工变成半自动”，但离“上架素材直接可用”还有一段距离。我真正想要的是一个工具，能让机器自己去理解App、去跑页面、去截符合规范的图，甚至能在导出时就告诉我哪些素材可能会被苹果拒审。Goldie的定位正好踩在这个需求上。
1.3 Goldie解决的痛点和适用人群
Goldie本质上是一个围绕“App Store素材生成”场景做垂直优化的编码Agent。它利用大模型理解自然语言任务的能力，自动完成测试代码生成、模拟器操作、截图导出、视频录制与合成、合规校验一整套流程。
我把它跑通一遍后的感受是，它最大的价值不是某个单一功能多强，而是把这些功能封装成了一条完整的流水线。你给它一个App工程和一份配置，它能在几分钟内产出一套符合App Store Connect基本要求的截图和预览视频，并出一份合规校验报告。报告里会标出哪些素材尺寸不对、哪些截图包含非正常状态栏内容、视频编码是否符合要求等等。
适合谁用？如果你和我一样，是独立开发者、两三个人的小工作室，或者在大团队里负责发版和元数据维护，手里有几个App要长期维护上架素材，那Goldie能省下非常可观的时间。如果你只是偶尔发一次版、App也比较简单，也可以拿它当自动化脚本用。但它毕竟是个编码Agent，有一定使用门槛，至少你得能读懂配置文件、会基础的Git操作，并且拥有macOS和Xcode环境。这不是一个从零也能点开即用的傻瓜工具。
2. Goldie原理拆解：编码Agent如何把截图变成合格的上架素材
2.1 编码Agent的“写代码-跑测试-看结果”闭环
要理解Goldie，得先理解什么叫编码Agent。你可能用过GitHub Copilot或者ChatGPT写代码，它们属于“生成建议”，你复制代码、贴进工程、自己验证。而编码Agent不一样，它是一个能自己行动的程序：接收任务、读取代码、写文件、执行命令、观察输出、根据报错修改代码，如此循环，直到任务完成。
Goldie就是这样一种Agent，只不过它的任务领域被限制在了“App Store素材生成”上。它内部会调用大模型来规划步骤，再利用Xcode的命令行工具执行具体操作。比如，任务目标是“进入首页、点击商品详情、截图”。Agent会先读取你的App工程结构，找到UITest target或应用的启动配置，然后生成一段XCUITest代码，用xcodebuild跑起来。如果跑的过程中元素定位失败，它会从日志里读到报错，再修改代码重试。
这个过程很像我带一个实习工程师干活：你说清楚目标，他写代码尝试，报错了就自己看日志修正。但Agent不会抱怨、不会累，而且迭代速度很快。不过这也意味着，它生成的代码不一定完美，偶尔也会有跑不通或者跑错地方的情况，所以你要保留人工确认的环节。
2.2 截图矩阵：从一台设备到几十个坐标系
截图上架不是“一张图走天下”。苹果要求提交的截图按设备屏幕尺寸区分，而且不同语言、不同设备可能要用不同的截图。Goldie在配置阶段会要求你定义目标设备矩阵和语言列表，然后自动展开成一个后台任务矩阵。
执行的时候，它会对每一组“设备尺寸+语言”的组合执行一次独立的入口。比如我配置了iPhone 6.7英寸、6.5英寸、5.5英寸三种尺寸，加上英语、简体中文两种语言，那就是六个组合。Agent会逐个启动对应的模拟器，设置语言环境，运行XCUITest，在关键节点调用命令截屏。
这里的难点在于状态栏。苹果对截图的状态栏内容有要求，不能是假时间、假信号。Goldie的解决方案是尽可能让模拟器保持真实状态，同时在导出阶段检查状态栏文字是否和预期一致。如果模拟器区域设置不对，或者时间格式不对，校验模块会直接报警。这比我自己手动PS一张张改要省心得多，因为它是从源头保证截图是“真”的。
2.3 预览视频自动生成的实现思路
预览视频这块，Goldie用了个比较聪明的组合方案。它先通过XCUITest定义一段“页面游览路径”，让模拟器按照预设的顺序依次进入不同页面，每一步之间留出足够的时间给用户“看明白”。同时，它调用模拟器的录屏能力，把这整段操作过程录下来，得到一段基础的原始视频。
接着是后处理环节。原始视频需要压缩编码、裁剪尺寸，还要保证格式符合App Store Connect要求。Goldie会检查视频分辨率、时长、编码格式、文件大小，如果不符合要求就自动转码或者报警。据我实测，它输出的是M4V容器、H.264编码的视频，时长控制在30秒以内，这样上传App Store Connect的时候基本不会因为格式问题被拒。
这里我想特别提醒一点：预览视频的“游览路径”设计非常关键。如果路径设计得不好，比如在一个页面停留时间太短、点击位置漂移，生成的视频会给人一种“手忙脚乱”的感觉。Goldie允许你在配置里给每个步骤设置停留时间，我建议至少留2秒，这样成片才稳。
2.4 内置合规校验模块在做什么
Goldie的合规校验模块是我最看重的部分。它做的事情可以理解为“在你提交素材到App Store Connect之前，先让机器替你审一遍”。
这些规则覆盖面很广，包括硬性规格和内容规范。硬性规格好理解：尺寸对不对、分辨率够不够、文件体积是否超限、视频时长和编码是否符合要求。内容规范则相对主观，比如截图上有没有出现明显的占位符、模拟器状态栏时间是否异常、画面中是否包含可能与审核指南冲突的信息。另外，它也会检查素材和App实际页面是否情绪一致，简单说就是“有没有过度美化导致误导用户”。
这个模块不是单纯的静态检查，而是结合了规则引擎和视觉模型。尺寸、格式这类信息用命令行工具读一下就能判断，图形和文字层面的问题则需要更复杂的分析。实测下来，它对“尺寸错误”和“状态栏异常”这类硬性问题判断非常准确，对内容层问题的判断则偏向给出提示而不是直接否决，这点比较合理。
3. 实操复现：从GitHub拉取项目到跑通第一次导出
3.1 环境准备与安装
我这次是在一台macOS 14的Mac mini上跑的，Xcode版本是15.2，已经装好了iOS 17.2的模拟器运行环境。Goldie本身的安装不复杂，但我建议先确保本机环境干净，因为你之后跑模拟器、编译测试工程都离不开这套底子。
第一步是拉代码。如果你只是想先体验一下，我建议用浅克隆，只拉最近一次提交就够了。
git clone --depth 1 https://github.com/GoldieApp/Goldie.git cd Goldie然后看官方文档确认依赖项。我这台机器上预先装了Homebrew、Python 3.11和ffmpeg，后面用起来都很顺。如果你本机没有ffmpeg，建议提前装好，因为视频合成和转码阶段会用到它。
brew install python ffmpeg装完之后，Goldie提供了命令行入口，我用的是它的CLI模式。第一次跑初始化命令时，它会自动检测Xcode和模拟器环境，并生成一份默认配置文件。这一步算是比较贴心的设计，省去了手动建目录的麻烦。
3.2 编写项目配置
Goldie的配置文件默认是一个YAML文件，里面定义App路径、Bundle ID、目标设备、语言、输出目录等关键信息。我用自己的一个开源Demo工程做测试，配置大概长这样：
app: path: ./DemoApp/DemoApp.xcodeproj scheme: DemoApp bundle_id: com.example.demoapp devices: - name: iPhone 15 Pro Max size: 6.7 - name: iPhone 14 Pro size: 6.1 - name: iPhone 8 Plus size: 5.5 languages: - en - zh-Hans scenarios: - name: home description: 进入首页并停留 steps: - type: launch - type: wait duration: 2 - name: detail description: 点击第一个商品进入详情页 steps: - type: launch - type: wait duration: 2 - type: tap element: "first_product_cell" - type: wait duration: 2 output: screenshots_dir: ./artifacts/screenshots video_dir: ./artifacts/preview report_dir: ./artifacts/report compliance: enabled: true strict: false这里最需要花心思的是scenarios部分。你要用自然语言描述“进入哪个页面”“点击什么元素”。Agent就是根据这些描述去生成XCUITest代码的。描述越准确，它生成的代码越靠谱。比如“点击第一个商品进入详情页”这种描述，它一般能自动定位到列表的第一个cell。但如果你的页面元素没有明确的accessibilityIdentifier，它就会去猜类名，这时候出错的概率会明显上升。
3.3 运行自动截图并解读产物
配置写完后，运行截图的命令很简单：
goldie run screenshots这条命令会逐个启动模拟器，针对每个设备、每个语言跑一遍所有场景，然后在关键节点截图。整个流程跑起来很像我平时跑Fastlane snapshot，但它的输出更详细：每一步是成功还是失败、Agent这次重试了几次修改代码、当前跑到哪个组合，日志里都看得到。
我第一次跑的时候，6个组合大概花了12分钟。这个速度不能说快，但考虑到它帮你把前面所有逻辑都跑完了，也还能接受。截图产物按“设备尺寸/语言/场景”的目录结构存放，命名里带了尺寸和语言标记，后续上传的时候非常容易对应。
有一点要提醒：截图生成后，最好自己跑一遍看内容是否真的对应了你想要的页面。我遇到过一次Agent“自作聪明”地跳过了某个页面，原因是我描述里没说清楚必须先登录，它就直接进了列表页。不是工具不好用，是我的场景描述得不够完整。这里的经验是，scenario描述里要把前置条件写清楚。
3.4 生成预览视频的关键步骤
截图搞定后，生成预览视频的入口是另一个子命令：
goldie run preview它会复用你已经定义好的场景路径，在模拟器里重新走一遍，同时开始录屏。我这里遇到的一个问题是，模拟器录屏对系统资源占用比较高，第一次跑的时候同时开着好几个模拟器，结果视频掉帧严重。后来我改成每个模拟器串行执行，问题就消失了。
录屏结束后，Goldie会自动做裁切和转码，然后输出到视频目录。我检查了一下生成的视频，分辨率和模拟器屏幕分辨率一致，时长大约20秒，用的是H.264编码。把它传到App Store Connect测试了一下，直接就能识别，没有报格式错误。
如果视频需要配背景音乐或解说，Goldie本身没有做这个功能。它定位是生成“干净的操作演示视频”，如果你要加音轨，还是得导出后再用剪辑工具处理。这个取舍我觉得合理，毕竟自动配音这个方向太容易翻车，不是所有App都适合。
3.5 合规校验报告怎么看
跑完截图和视频后，Goldie会在report目录下生成一份合规校验报告。我打开看到一个类似这样的结构：
{ "summary": { "total_checks": 48, "passed": 43, "warnings": 4, "failed": 1 }, "failed_checks": [ { "check": "screenshot_dimension", "asset": "artifacts/screenshots/iPhone8Plus/zh-Hans/home.png", "message": "Expected 1242x2208, got 1242x2208 but scale factor mismatch", "suggestion": "Recheck device scale setting" } ], "warnings": [ { "check": "status_bar_time", "asset": "artifacts/screenshots/iPhone15ProMax/en/detail.png", "message": "Status bar time text may be frozen, verify manually" } ] }报告分三级：failed、warnings、passed。failed说明有硬性问题，这张素材基本不能直接用；warnings的提示通常需要人工确认，比如状态栏时间是不是假的、截图里的数据是不是本地mock数据。这类问题机器很难判断，所以列为警告让开发者复核，我认为是很务实的设计。
我那次唯一一个failed是iPhone 8 Plus的截图尺寸比例不对。原因是模拟器启动后，系统状态栏的高度因为机型原因发生了变化，导致截出来的图实际尺寸和预期有偏差。Goldie检查得很严格，直接判了不过。我按照提示重新确认了模拟器设置，再跑一遍就通过了。
4. 苹果上架素材合规校验中的关键细节
4.1 审核指南里针对素材的硬性要求
苹果在App Store审核指南里对截图和预览视频有明确的硬性要求，这些东西平时不仔细看很容易忽略，但恰恰是自动校验最喜欢抓的点。
截图方面，最常见的要求包括：必须使用真实设备或官方模拟器截取的画面，不能是合成图或网页模拟图；截图内容要和App实际功能一致，不能出现App里不存在的功能；状态栏必须真实显示，不能P一个假信号、假时间上去；截图尺寸要匹配所选择的设备规格。这些规则听起来很基础，但我见过不少团队就是栽在“P图太狠”上，审核反馈直接写“截图内容与App实际体验不符”。
预览视频方面，苹果要求视频长度不能超过30秒，必须使用M4V格式，编码推荐H.264，分辨率要和目标设备屏幕比例一致。另外，视频不能包含市场营销性质的广告剪辑，不能出现未发布的版本内容，也不能展示与App无关的第三方品牌。这些限制让“视频自动化”变得比截图更复杂，因为内容层面的合规很难靠脚本解决。
4.2 Goldie的校验规则分几层
Goldie把校验规则分成了三层，这个设计我很喜欢，也建议大家理解一下，因为知道它在查什么，你才能更好地处理报告。
第一层是规格层。它读取图片和视频的元数据，检查尺寸、分辨率、比例、文件大小、编码格式、时长、帧率。这一层几乎不需要智能分析，用sips、ffprobe这类工具就能搞定，也是最可靠的一层。凡是failed的，基本都是这一层查出来的。
第二层是内容层。它会利用OCR和计算机视觉技术识别画面里是否存在文字、是否被遮挡、状态栏时间是否异常、有没有明显的占位符或空白页面。这一层准确率比规格层低一些，所以Goldie通常把它作为警告而不是拒绝。比如它识别到某张截图的标题栏文字和预期不符，就会提示你人去确认一下。
第三层是语义层。比如检查截图/视频和App Store Connect里填写的描述是否一致，有没有“挂羊头卖狗肉”的内容。这一层目前还是比较基础的，更多是给出参考建议。我估计这也是整个工具后续迭代空间最大的地方，毕竟要让AI完全理解“内容是否误导用户”这种主观问题，还需要更强大的模型能力。
4.3 把合规校验接到CI/CD里防回归
Goldie并不强制你把它集成到CI，但我的推荐是：如果你在一个多人维护的App工程里，一定要把它接进CI，尤其是截图素材这种很容易随着版本迭代而“过期”的东西。
比如你的开发同事改了一个页面的UI布局，但忘了更新上架截图，旧的截图可能还挂在App Store Connect上。如果审核员刚好下载新版App对比，发现截图里是旧界面，非常容易以“误导用户”为由拒审。这类问题靠人工很难发现，因为截图是静态文件，不跑起来对比根本看不出差异。
我是这样设计的：在GitHub Actions里加一个workflow，当App工程里涉及UI文件变更的PR被创建时，自动运行Goldie的截图生成加合规校验，把报告作为artifact上传，并在PR评论里扼要说明检查结果。这样开发者还没合并代码，就能看到“你的改动导致旧截图尺寸失效”或“新页面里有占位符文字，素材需要重出”。这比发版本前再临时补素材要从容得多。
name: AppStoreAssetsCheck on: pull_request: paths: - "DemoApp/**" jobs: check: runs-on: macos-14 steps: - uses: actions/checkout@v4 - name: Run Goldie compliance run: goldie run compliance --config .goldie.yml - name: Upload report uses: actions/upload-artifact@v4 with: name: compliance-report path: artifacts/report/这里有个成本问题要提前说：GitHub Actions的macOS runner是按分钟计费的，跑一套完整的截图矩阵可能要十几分钟，消耗不小。我自己的做法是拆成两档：PR阶段只跑合规校验，不重新生成素材；正式release前跑一次全量生成。这样日常迭代成本可控，关键节点又有保障。
5. 实际运行中我踩过的坑与排查记录
5.1 Agent生成的XCUITest代码总会偶发找不到元素
我用Goldie跑了几次下来，遇到频率最高的问题就是：Agent生成的XCUITest代码在定位元素时偶发失败。比如配置里写“点击第一个商品进入详情页”，它有时候能找到，有时候找不到。后来看日志发现，它生成的定位逻辑大多依赖app.buttons["xxx"]或者app.cells.element(boundBy: 0)这种方式，一旦页面加载慢，或者有启动弹窗挡在前面，就定位失败了。
我的排查思路是：先在App的目标页面元素上手动加上accessibilityIdentifier，然后把这个identifier直接在scenario描述里写清楚。比如描述改成“点击identifier为product_cell_0的元素”。这样Agent生成代码的时候会优先用明确的标识符，而不是靠猜测。加完之后，偶发失败的情况基本消失了。
如果你的App确实不方便改代码，那也可以在Goldie配置里给场景增加一个“前置等待”步骤，比如等待2到3秒再点击。这个方法也能降低失败率，但会增加生成时间。
5.2 本地化语言没有真正生效
另一个我踩到的坑是语言切换。我在配置里写了zh-Hans，但生成的截图里部分界面还是英文。排查了一下发现，问题出在模拟器的区域设置上。Goldie在启动模拟器后执行的是xcrun simctl的某个语言设置命令，但如果模拟器之前已经被手动改过区域，或者App的本地化文件没有正常加载，就会出现中英文混杂的情况。
这里我建议跑之前先用命令确认模拟器状态：
xcrun simctl list devices然后再执行Goldie的语言切换命令，确保当前模拟器已经被重置过。实在不行，就删掉对应的模拟器，让它完全重新创建。重新创建虽然多花点时间，但能保证一个干净的环境，截图里不会残留上次运行的数据。
5.3 录制的预览视频被校验拦下
预览视频第一次跑的时候，我被Goldie的校验报告拦下了，提示“H.264编码中检测到高轮廓级别，部分设备可能无法播放”。我一开始还没看明白，后来查了一下，苹果虽然推荐H.264，但对具体的profile level是有兼容性要求的。Goldie转码时默认用了比较高的渲染参数，导致profile level超过了某些旧设备的解码能力范围。
解决办法是在配置文件里增加一个视频编码参数，强制指定Baseline或Main profile，并限制最大比特率。改完重新跑一次，校验就通过了。这个问题说实话，如果没有工具这个环节的自动检查，我可能根本不会注意到，直接上传到Connect上，等审核时再说。到时候再改素材，整个发版节奏都要受影响。
5.4 跑完整矩阵太耗时怎么优化
全套矩阵跑下来，时间是最让人头疼的。我最初把所有目标设备、所有语言、所有场景一次性全跑，耗时超过了30分钟，中途如果有一两个组合失败，又得重跑，消耗很大。
我的优化方法是分阶段执行。日常开发阶段，只跑一台目标设备（比如最新的iPhone 15 Pro Max）和一种语言，快速验证Agent生成的代码逻辑是否正常。正式出素材前，再全量跑一次完整矩阵。另外，可以把设备列表按大小分组，每组之间用后台任务并行跑，但要注意控制在2个并行以内，否则模拟器同时开太多，反而会因为资源竞争导致失败。实测下来，串行加少量并行是最稳的组合，跑完整矩阵大约20分钟出头。
5.5 校验误报的例外处理
Goldie的合规校验有时候会误报，最常见的是状态栏时间检查。模拟器里的时间是开机时的时间，如果中途待机久了，秒数可能不会实时刷新，OCR检测到时间“静止”就报警告。这个问题在真实设备上也会出现，苹果审核其实不会因为秒针没动就拒你的素材，所以看到这类警告，手动确认一下没有异常就可以忽略。
还有一次是截图里有个正常的加载动画，被OCR识别成了“内容被遮挡”。这种属于误报，不影响使用。Goldie的strict模式可以把这类警告升级成failed，但我建议平时不要开strict，宁可多花30秒人工确认警告项，也别被误报卡住流程。
6. 最后聊几句真实的使用体会
Goldie不算一个“装上就好”的工具，刚开始配置场景、跑命令、处理校验报告，都是需要花时间学习和试错的。但它确实把上架素材制作这件事从“纯手工”推进到了“半自动加自动质检”的阶段。对我来说，最大的收获是发版前不用再盯着PS和Final Cut发愁，素材出问题也能在提交前发现，而不是等审核意见回来再手忙脚乱地补。
如果你打算自己试，我有个建议：第一次跑不要追求全量矩阵，先拿一个最简单的App、一台设备、一种语言，把整条流程跑通。确认Agent生成的截图和视频符合你的预期后，再逐步扩展开来。另外，scenario描述里尽可能写清楚每个步骤的前置条件和要点击的控件identifier，这能省下大量调试时间。
Goldie这种编码Agent的模式，也让我对后面这类工具更期待了。目前它主要聚焦在App Store素材这块，但同样的思路完全可以延伸到其他上架平台，或者扩展到应用商店元数据检查、版本说明生成这些周边环节。工具已经帮我们做了很大一部分工作，剩下的关键判断，还是得靠开发者自己来把好最后一关。
