每次发版，最烦的不是改代码，是那一串重复动作：导出 IPA、登开发者后台、建版本、填元数据、传截图、提交审核。真要把这套交给 AI，第一反应大概是「它能看懂失败吗」「会不会重复上传」。这篇就按命令顺序讲，用 AI 自动上架 App Store 这件事，落到 Appuploader 的命令行上是几条命令、哪些限制得人来守。

先把四条命令摆出来，后面的内容都是围着它们展开：

1appuploader-cli skill --install user2appuploader-cli doctor --for-release --json3appuploader-cli release --dry-run --json4appuploader-cli release --json --yes

前三条要么只读、要么只是装说明，第四条才真正动账号。顺序别乱，尤其第一次跑，折腾反了容易白忙一场。

一、这四条命令分别在干什么？

skill --install user 是把技能文件装进 Claude Code，所有项目都能用；只想当前项目生效，就换 --install project。给 Codex 这类读 AGENTS.md 的 agent，用 --format agents 输出一段说明追加进去。技能文件里写的是使用规则、退出码、重试策略和命令索引，不是让 AI 自己猜参数。工具升级之后记得重新生成一次，不然文件和程序版本会错位。

doctor --for-release 是体检，只读，检查账号、配置和发布要用的资源齐不齐。 release --dry-run 是预演，同样只读，把每一步会做什么列出来。这两条跑完，AI 和人看到的是同一份报告，哪里缺东西、哪一步会跳过，心里都有数。

release --json --yes 才是执行。 --yes 不是装饰，它是在非交互环境里确认危险操作的开关——删除、吊销、撤回这类动作，没有它就不往下走。把 --yes 当成「我已经看过预演了」的签字，别当成默认参数随便加。

二、AI 看懂的边界：JSON、幂等、退出码

让 AI 操作开发者账号，最怕三件事：看不懂输出、重复执行、误删东西。命令行在这一层的设计，基本是围着这三件事来的。

--json 模式下，每一步输出一行 JSON，结果走 stdout，进度走 stderr，结构固定。失败的时候会带上 retryable 和 next_action，AI 不用猜下一步该干嘛：

1{"event":"step","step":"upload","status":"failed",2 "retryable":true,3 "next_action":"appuploader-cli release --from upload"}

创建类操作是幂等的。东西已经存在就返回 created: false，不报错；有效的证书直接复用；已经上传过的构建不会重复上传。说白了，同一条命令跑两次和跑一次，结果一样。这一条对 AI 特别关键，说实话，重试的时候最容易出乱子；有了幂等，agent 才不会把账号里堆出一串重复资源。

退出码也是稳定的，脚本和流水线能直接判断该不该重试。 AI 的安全感来自这些约束，不是来自模型有多聪明。

有个坑得提前说：别让 agent 自己拼命令、猜参数。技能文件里已经把常用流程和命令索引写好了，让它按文件里的规则调；自己发挥的部分越多，越容易在 --from、 --only 这类裁剪参数上出错。

三、release 里到底跑了哪些步骤？

一条 release 按项目里的 appuploader.yaml 往下走，大致是这些步骤：

1preflight → bundle → certs → profiles → app → version → upload2→ metadata → screenshots → custom-pages → build-wait → compliance3→ review-info → gamecenter → iap → pricing → privacy → submit → testflight

里面有些步骤是可选的，只有项目配置里写了对应内容才会执行。内购、定价、隐私标签、TestFlight 这些，不配就不跑，不会没事找事。

跑一半失败了呢？重新执行同一条命令，会从失败的那一步继续。想从头来加 --restart；想裁掉某几段，用 --from、 --to、 --skip、 --only。这个设计还挺实在的，上架流程本来就长，谁也不想因为截图传失败就从证书开始重来。

其实还有一个边界：API Key 做不到所有事。新建 App、定价、隐私标签这些，Apple 官方 API 本身不支持，命令行会自动改用你指定的 Apple ID 账号去处理。所以别以为配了 API Key 就能全程不碰账号。

四、凭据怎么放才不交给 AI？

推荐用 Apple ID 加 App 专用密码登录。这个密码不是账号登录密码，是 Apple 单独生成的一串 xxxx-xxxx-xxxx-xxxx，用它可以免双重验证，功能还全，泄露了也能单独吊销。

在终端里，密码放在环境变量里，用 --password-env 指定变量名；在 CI 里，设好 APPUPLOADER_APPLE_ID 和 APPUPLOADER_PASSWORD，命令需要时会自动登录，连 login 都不用先跑。命令行没有明文密码参数，凭据只从环境变量、项目配置或已登录的会话里读。它不会出现在命令历史里，也不会进 AI 的对话记录。

API Key 是另一条路，适合本来就有 Apple 官方 API 流程的团队。但它有功能缺口，前面说过，建 App、定价、隐私标签这些它管不了。普通密码加双重验证也能用，终端会提示输验证码，脚本里可以传 --2fa-code，或者用 --2fa-from-file 让登录进程等另一个进程写码。能不用这条就不用吧，无人值守的场景太容易卡住（别问我怎么知道的）。

千万别把账号密码直接写进给 AI 的提示词。用专用密码、环境变量、最小权限的账号，这三样比什么提示都管用。

五、哪些事必须人来决定？

AI 能接手的是重复动作：装技能文件、体检、预演、执行、读 JSON、按 next_action 重试。有几件事，我建议留在人手里。

预演报告呢，得人看一遍。它会告诉你哪些步骤会跳过、哪些资源会新建、哪些配置缺了。跳过太多不一定是好事，可能是配置没写对。

提交审核之后，发布这一步永远是手动的。流水线跑到提交为止，审核通过后要执行 appuploader-cli version publish <版本号>，版本号必须写明，执行前还会再确认一次。这个设计挺好，AI 不会在你睡着的时候把版本发出去。

审核被拒、元数据有法律风险、隐私标签填得对不对，这些也不是命令能判断的。 AI 适合干重复且有确定结果的活，账号安全和「要不要发」这两件事，得留在人手里。

六、和 Fastlane、Xcode、Transporter 怎么配合？

印象里，Fastlane 是 iOS 自动化的老牌方案，证书、构建、上传能串成一条流水线，适合长期维护、团队规模大的项目；前提是有一套 Mac 或 macOS 构建机。Xcode 和 Transporter 是苹果自己的路，最稳，但也绑在 Mac 上。 Appuploader 的命令行走的是跨平台路线，Windows、Linux、macOS 都能跑，Linux runner 也能接，还给 AI agent 留了技能文件。

这三者不是替代关系。构建、上传、审核本来就是三段活：它负责上架这一段，不负责把你的 Swift 代码编成 IPA。IPA 还是得由 Xcode、KXBuild、云 CI 或者框架自带的云打包先产出来。 工具之间是接力，先看清楚自己卡在哪一段，再决定换谁。

七、第一次用，按这个顺序试试

先把 Appuploader 客户端装好， appuploader-cli 就在安装目录里，不用单独下载。把它加进 PATH，之后在任意目录都能直接运行。然后去 account.apple.com 生成一个 App 专用密码，只显示一次，当场存好。

在 App 工程目录里跑一次 init，生成 appuploader.yaml，把 Bundle ID、版本和元数据位置填好。接着装技能文件，让 AI 先做体检和预演：

1appuploader-cli init --bundle-id com.example.app --name "My App"2appuploader-cli skill --install user3appuploader-cli doctor --for-release --json4appuploader-cli release --dry-run --json

预演结果对得上，再让 AI 执行 release --json --yes。第一次别拿正式版练手，实在想试，干脆找个测试 App 或者先走 TestFlight，把证书、描述文件、截图这些环节都过一遍。跑顺之后再考虑接 CI，反正流程是同一套命令。