iOS 上架这件事，我终于不再靠记忆点网页了

阿肥 · 2026-07-28

上周帮一个朋友看他的小团队发版流程。三个人，维护两个 App，每次提审都像一场小型战役——有人在 App Store Connect 里找构建版本，有人在截图文件夹里翻 6.7 英寸的设备截图，还有人在微信群里问"版本号到底改成多少了"。

我坐在旁边看了一会儿，突然觉得这个场景特别熟悉。因为两年前我自己也是这么干的。

那时候我觉得发版就是一件"体力活"。代码写完了，测试跑通了，最难的部分已经过去了。结果真正让人崩溃的，是从"代码完成"到"App Store 显示'等待审核'"之间那段路。上传包、等构建处理、配元数据、填隐私问卷、上传截图、写审核备注、选国家地区、提交审核——每一步都不难，但它们分散在 App Store Connect 的不同页面里，而且会在你准备点"提交"的时候突然告诉你：前面有一格没填。

这种体验，每一个上架过 App 的开发者都经历过。但最近半年，我发现这件事正在被重新定义。

 

左边是永远点不完的网页，右边是跑完就收工的终端

一、网页上架的痛，每个iOS开发者都懂

先说说手动上架到底痛在哪里。不是技术难，是流程碎。

App Store Connect 这个后台，苹果做得很完整。App 管理、TestFlight、商店元数据、订阅配置、审核提交、崩溃报告、用户评论——功能全都齐了。但"齐全"的代价是"分散"。你今天只是想确认一个构建版本有没有处理完，顺手看一下 TestFlight 的状态，再准备一下提审材料。结果打开后台，在四五个页面之间来回跳转，二十分钟过去了，你发现自己还在找那个"提交审核"按钮到底藏在哪里。

有一个开发者在泽轩604公众号上分享过他的真实经历：他做了一个很小的 App，功能不复杂，就是把 iPhone 里几个藏得比较深的显示设置整理成预设。代码是 AI 帮他写的，在 Xcode 里跑得很顺。他当时以为最难的部分已经结束了。结果后面才发现，真正磨人的，是从"手机上能跑"到"App Store 里能搜到"之间那段距离。

注册 Apple Developer，买开发者会员，登录 App Store Connect，创建 App 记录，填隐私政策，上传截图，回答 App Privacy 问卷，选国家地区，处理中国大陆区的可用性，上传 build，选择构建版本，写审核备注，Add for Review，然后——还不是结束。你还要再点一次 Submit for Review。

他原话说："我一开始以为把版本加进审核就完事了，后来才发现，只有状态真正变成'等待审核'，这件事才算送出去了。"

我看到这段话的时候笑了。因为我也犯过同样的错。这种"以为结束了其实没结束"的感觉，是 App Store 上架流程里最让人心累的部分。

更别提团队协作了。手动点后台最怕的就是"每个人都有自己的手法"。有人先传包再配 metadata，有人先写文案再上传截图。流程靠口口相传，换一个人就乱一遍。一个团队如果同时维护三四个 App，每次发版都像在打一场没有作战地图的仗。

二、先搞清楚四样东西的关系

在聊工具之前，有一件事必须先说清楚。很多文章把 App Store Connect、API、CLI 和 Skill 混在一起讲，最后统一叫做"AI 自动上架"。听起来省事，实际上容易误导。

这四样东西其实是同一件事的四个层级，各管一段：

App Store Connect 是苹果的官方平台。你在网页上看到的一切——App 管理、TestFlight、商店元数据、审核状态——都在这里。它是源头，是所有操作的最终生效地。

App Store Connect API 是苹果提供的 REST API。它让你可以用程序化的方式管理商店信息、TestFlight、审核提交、签名资源和报告。API 是苹果官方的，稳定的，有文档的。但它只是接口，不是工具——你得自己写代码去调它。

asc CLI 是一个开源的命令行工具，不是苹果官方产品。目前社区里比较活跃的是 rorkai/App-Store-Connect-CLI，截至2026年7月已经积累了约5300个 Star，配套有23个正式 Skill。它把 App Store Connect API、Xcode 构建上传和发布流程整理成了一组终端命令。你可以理解为：它是 API 上面包了一层"人话"。

ASC Skills 则是给 AI Agent 看的操作手册。它本身不拥有发布能力，而是教 Agent 什么时候该查询、什么时候先跑 dry-run、遇到阻塞该调用哪个检查命令、什么时候必须把决定权交回给人。

 

四层结构：网页是终点，API 是通道，CLI 是桥梁，Skill 是导航

把这四层关系压缩成一句话就是：Skill 负责流程，CLI 负责执行，API 负责生效，人负责授权与确认。

它们不是替代关系。它们是同一条发布链路上的不同层。搞清楚这一点，后面的选择就清楚多了。

三、CLI 的真正价值：不是少点几个按钮

很多人第一反应是：CLI 不就是把网页上的按钮变成命令行吗？有什么了不起的。

如果你只是偶尔上架一个 App，确实没什么了不起。一年点两次网页，半小时搞定，不值得折腾。

但 CLI 真正的价值不在"少点几个按钮"上。它解决的是三个更深层的问题。

第一个问题：流程依赖记忆。网页操作的本质是"这个人记得下一步点哪里"。你记得先传包再配元数据，你记得去 TestFlight 页面确认构建状态，你记得提审前检查出口合规。但如果换一个人来操作呢？如果他今天状态不好，忘了其中一步呢？CLI 工作流依赖的是"仓库里写明下一步是什么"。前者适合偶尔操作，后者适合频繁发布。

第二个问题：自动化断层。现在很多团队已经在用 CI/CD 了。代码提交、编译、跑测试、打 ipa 包，这些都在流水线里。但到了"上传到 App Store Connect、配元数据、提审"这一步，流水线突然断了。有人要从 CI 环境切到浏览器，手动操作一遍，再把结果记回文档。这就像一条高速公路中间突然出现了一段土路。

第三个问题：AI Agent 的接入。这一点是最近半年才凸显出来的。当 Claude Code、Codex 这类 AI 编程工具已经掌握了你项目的上下文，让它在代码完成后突然停下，然后由人打开网页、查 App ID、复制版本号、找构建包——本质上是把一条自动化流水线从中间剪断。CLI 给 AI 的是结构化输出：JSON、状态码、错误信息。AI 不用再盯着网页截图猜按钮了，它可以回到自己更擅长的位置——读数据，做判断，跑命令，记录结果。

这里有一个真实的数据对比。泽轩604那篇文章里提到，他让 AI 通过浏览器代操的方式帮他在 App Store Connect 里走发布流程，用的是 Pro 会员，额度大约是十倍 Plus 的水平。结果就为了帮他把一个小 App 从网页里点到"等待审核"，至少烧掉了十分之一的 Pro 额度。换算一下，相当于一个 Plus 用户一整周的额度。慢不说，还贵。因为 AI 每做一步都要截图、识别页面、判断按钮位置——它在用一个本来给人眼和鼠标设计的界面，去完成一件机器更适合直接调用接口完成的事。

· · ·

四、手把手上手：从零到第一次自动提审

说了这么多价值，接下来讲实操。我不会给你一个"全自动一键发布"的脚本——那种东西在真实项目里跑不起来。我给的是一条渐进式路径，从最安全的地方开始，一步步把自动化程度提上去。

 

终端里的绿色输出，比网页上的转圈动画让人安心多了

第零步：安装。

这一步最简单。如果你用 Homebrew：

brew install asc

如果你还在用 Codex 或 Claude Code 做开发，可以顺便把 Skill 包也装上：

npx skills add rorkai/app-store-connect-cli-skills --global --agent codex

注意，名字容易混。社区里还有一个叫 asc-cli 的项目（tddworks/asc-cli），以及一个叫 ASCelerate 的（keremerkan/ascelerate）。它们都在解决类似的问题，但我这篇主要推荐的是 asc，也就是 rorkai/App-Store-Connect-CLI。它的产品方向最明确——就是给终端、CI 和 Agent 用的。

第一步：只做只读验证。

安装完不要急着提交任何东西。先让工具证明它能正确连接你的账号：

asc versionasc auth status --validateasc auth doctorasc apps list --output json --pretty

这一步只回答两个问题：它能不能正确连接你的 Apple Developer 账号，以及它看到的 App 列表是不是你想操作的那些。如果认证出了问题——API Key、Key ID、Issuer ID、.p8 私钥——在这一步就会暴露，不会造成任何副作用。

关于密钥管理，这里必须多说一句。.p8 私钥只能从 App Store Connect 下载一次，丢了就没了。不要把私钥内容粘贴给 AI 模型，不要提交到 Git，不要出现在构建日志里。本机用钥匙串存，CI 用平台的加密 Secret。这个底线不能破。

第二步：只做检查和预演。

选一个你已有的版本，运行验证和 dry-run，但不执行任何提交：

asc validate --app "你的APP_ID" --version "1.2.3"asc release stage --app "你的APP_ID" --version "1.2.3" --build "BUILD_ID" --dry-run

dry-run 会生成一份发布计划：它会修改什么、使用哪个构建、还缺哪些信息。你就像看菜单一样看一遍，确认没问题。这一步不会对你的 App 产生任何实际影响。

第三步：先接 TestFlight。

TestFlight 比正式发布安全得多。先让 CLI 自动上传构建、等待处理、分发到内部测试组。这一步可以反复练。版本号、构建号、签名、测试分组——当这些都能在终端里稳定运行时，你才有信心把 App Store 提审也接进来。

 

TestFlight 是上架前最好的练兵场

第四步：正式提交，但保留人工确认。

当 TestFlight 跑顺之后，正式发布就是把最后几步接上：

asc publish appstore --app "APP_ID" --ipa "/path/to/MyApp.ipa" --version "1.2.3" --submit --confirm

注意那个 --confirm。它的意思是：执行到这一步时，必须有人确认才会真正提交。我建议把这个确认节点放在审核过的 CI 环境里，或者人工批准的流程之后。让 Agent 自行决定"现在适合发布"，这件事目前还不靠谱。

提交后可以用状态监控命令持续跟踪审核进度：

asc status --app "APP_ID" --watch

五、五条不能交给便利性的安全边界

自动化是好事。但有些事情，不能因为方便就让步。这五条边界，是我在调研这些工具时反复看到的提醒，也是我认为每一个准备接入 CLI 发布的团队都应该知道的。

 

自动化不意味着降低安全标准

边界一：API 私钥不能出现在对话里。前面说过了，.p8 只能下载一次。本机用钥匙串，CI 用加密 Secret，采用完成任务所需的最低权限。不要把私钥粘贴到任何聊天窗口、AI 对话框或日志文件里。

边界二：新建 App 记录仍然需要网页。苹果官方 API 目前不能直接创建新的 App 记录。也就是说，"很少打开网页"是合理目标，"永远不需要网页"不是。第一次创建 App、填写 App Privacy 问卷、处理某些合规弹窗，这些环节很可能还是要退回浏览器。

边界三：构建上传不等于 API 直接收 IPA。苹果官方文档明确区分了 API 与构建上传。上传仍需依靠 Xcode、Transporter 等交付路径。asc 可以把这些工具编排到同一套命令里，但不能把底层限制写没。搞清楚这个边界，就不会在"为什么 asc 不能直接传 ipa"这个问题上浪费时间。

边界四：第三方工具要固定版本。asc 是活跃的开源项目，不是苹果官方产品。团队接入时应该固定版本号，升级前查看 Release Notes，先在测试 App 上验证，再更新生产流水线。不要在周一早上随手升个级，然后发现发版流程挂了。

边界五：先检查遥测策略。asc 默认发送匿名化的命令级使用遥测。它声明不收集参数值、凭据、私钥、App ID 和响应内容。有严格合规要求的团队，接入前跑一下：

asc telemetry statusasc telemetry disable

六、更完整的画面：从内测到上架的端到端流程

聊到这里，你可能会觉得 CLI 发布已经是一个独立闭环了。但实际上，App Store 提审只是整个版本交付链路的最后一段。在它之前，还有一段同样重要的工作：内测验证。

蒲公英那篇文章里给了一个我觉得很清晰的框架：内测分发是上架前的验证层，CLI 发布是验收后的执行层，人是两段流程之间的闸门。

具体流程长这样：

先用内测签名打一个包，上传到内测平台（蒲公英、Firebase 或你自己的分发系统），交给测试者在真实设备上完成安装、体验和反馈验收。这一步暴露的是安装兼容性、功能完整性和用户体验问题。

验收通过后，切换到 App Store 签名和导出配置，重新构建。注意——内测包和商店发布包可能使用不同的签名与导出配置。它们可以来自同一份代码、同一个提交、同一条 CI 流水线，但不是"同一个 IPA 原样上传两次"。

然后 CLI 接手：检查商店侧条件（元数据是否齐全、构建是否处理完成、合规信息是否完整），预演变更（dry-run），人工确认后执行提交。

 

一条从代码到商店的完整链路，中间那道闸门不能省

这里最值得注意的设计是"闸门"。不是所有步骤都应该全自动。内测验收是一道闸门——产品或测试负责人确认通过，才进入发布流程。正式发布前又是一道闸门——CLI 做完所有准备，把计划展示出来，人确认后才提交。

这个设计背后的逻辑很简单：越是接近现实责任的地方，越不能把人完全拿掉。

Apple Developer 注册、付款、双因素认证、个人还是组织开发者——这些是身份问题。协议、税务、银行、隐私、版权、中国大陆区合规——这些是法律责任问题。密钥管理、版本号、构建号——这些是工程纪律问题。这些东西不能让 AI 瞎编，也不能让自动化流程替你做决定。

比较健康的做法是：人负责身份、授权、事实和责任；AI 负责执行、检查、记录和重复劳动。CLI 是中间那条干净的轨道，让 AI 沿着命令往前走——哪一步失败了，失败信息会回来；哪一步成功了，状态也会回来。这个过程容易复盘，也容易写进团队的 SOP。

七、工具矩阵：不只有 asc

asc 不是唯一的选择，但它是我目前看到最适合 AI Agent 调用的那个。如果你还想看看其他方向，这里快速扫一遍整个工具生态。

审核前预检类：devsemih/appstore-review-skill 支持 Swift、Flutter、React Native、Expo、KMP 多框架，跑一下就能拿到秒级的合规审计报告。RevylAI/greenlight 更进一步，不仅扫描问题，还能自动修复。如果你经常因为审核被拒而返工，这类工具值得在提审前跑一遍。

全栈开发类：Jonnycatx/apple-full-stack-genius-skill 专注 iOS 26+ 设计规范和 Swift 6 严格并发，基准测试显示辅助下的应用质量达标率 94%。vabole/apple-skills 提供权威的 Apple 参考文档和编码准则。如果你在做 iOS 开发，这些 Skill 可以显著提升 AI 写出来的代码质量。

截图与素材类：出海小达人那篇文章里提到的 Stitch（Google 的 UI 原型工具）可以自动生成 App Store 截图框架，配合 Fastlane 在所有设备尺寸上批量截图。Veo 3 可以生成 30 秒 App Preview 视频。如果你有多个语言版本需要维护，这套组合能省掉大量的手工截图工作。

老牌工具 Fastlane：四万多 Star，生态成熟，Ruby DSL 驱动。它更像传统 CI/CD 时代的发布流水线工具——强，全面，但思路是 lane 和配置文件。如果你的团队已经重度使用 Fastlane，不一定要换，但可以在 Fastlane 的 lane 里嵌入 asc 命令，取两家之长。

全流程自动化：出海小达人描述的"单人 AI 工作室"模式——Antigravity 做指挥中枢，Stitch 做 UI，Gemini CLI 做本地化，Veo 3 做视频，最后通过 App Store Connect API 提交。这套组合能把首次发布周期从8周压缩到2到3周，更新周期从3到4周压缩到不到1周。听起来很激进，但它的核心设计是"每个阶段结束后人先审查批准，再进入下一阶段"——AI 执行，人做决策。

工具很多，但选择的标准只有一个：能降低你的真实交付成本

· · ·

八、写在最后：工具不是越自动越先进

回过头来看这五篇文章，它们讲的其实是同一件事的不同切面：iOS App 的发布流程正在从"依赖记忆的网页操作"变成"可以写进仓库的工程流程"。

asc CLI 是这个趋势里目前最成熟的一个切入点。它不完美——新建 App 记录还得回网页，构建上传还是得走 Xcode 或 Transporter，第三方工具需要固定版本和谨慎升级。但它的方向是对的：把发布步骤沉淀成可检查的流程，让 AI 不用假装自己是一个坐在屏幕前点鼠标的人。

我自己最大的感受是什么？真正值钱的不是工具本身，是你把流程从脑子里搬到代码里的那个动作。当你把"下一步该干什么"写成了脚本、CI 配置或者 Agent Skill，你就不再依赖某个人的记忆和状态了。新人来了，看文档就能跑。你休假了，同事接手不会乱。Agent 接入了，它沿着命令走，不用在网页里东张西望。

如果你一年只更新一两次，始终由同一个人维护一个 App，配置 API 密钥、CLI 和工作流的成本，可能比打开网页更高。这不丢人。工具不是越自动越先进，能降低你的真实交付成本，才叫合适。

但如果你同时维护多个 App，每月都有版本发布，商店文案需要多个语言，团队已经在用 CI/CD——那我真心建议你从一个非关键 App 开始试。保留你现有的内测流程，只把"验收通过之后"的那段交给 CLI。先跑通 TestFlight，再扩展到正式提审。

自动化不是为了省掉脑子。是为了把重复劳动机器化，把确认权留在人手里。