夜雨聆风
我把 App Store 上架准备流程,做成了一个可复用的 Skill
用 Codex 准备了一次 App 上架材料，我突然不拖延了
“
以前我想到 App 上架材料，会觉得：哎，又要开始弄那堆东西了。今天做完以后，感觉变成了：把 App 给 Agent，看它先跑一遍。 总结的SKill 上传 github 了，链接在文末～～
01
现在要上架一个 App，最容易卡住的地方，往往不是代码。
Vibe Coding完了，功能也测得差不多了，理论上应该很开心：
终于可以提交了。
但一打开 App Store Connect，心情就开始复杂起来。
你要准备截图。
-
iPhone 的一套
-
iPad 的一套
-
如果 App 支持多语言，还要中文、英文、日文各来一套
你还要写一堆信息：
-
名称 -
副标题 -
关键词 -
介绍说明 -
版本说明 -
审核备注 -
技术支持 URL -
隐私政策 URL
你还要想清楚：
“
这个 App 到底怎么介绍？第一张图讲什么？第二张图讲什么？用户为什么要下载？用户为什么愿意付费？
然后你还要准备隐私政策页面。
还要准备技术支持页面。
这些页面还得有 URL，因为 App Store Connect 要填。
这些事单独看，每一件都不难。
但它们堆在一起，就很烦。
烦到什么程度呢？烦到拖延症都要犯了。
02
我以前经常会有这种感觉：
App 已经做好了，但是上架材料没准备好。
于是心里想着：
“
明天弄一下。
然后明天又觉得：
“
截图还要修一下。文案还要想一下。隐私页还要写一下。
于是又放一放。
最后真正拖住你的，不是一个很大的困难，而是一堆小麻烦。
截图就是其中一个典型的小麻烦。
以前我基本是手作：
-
先用模拟器或者真机截 App 界面 -
然后放到设计工具里 -
加背景 -
加标题 -
调排版 -
导出成 App Store 要求的尺寸
如果只是中文 iPhone 六张图，还好。
但如果你要：
-
iPhone -
iPad -
中文 -
英文 -
日文
全部做一遍，那这个事情立刻就变得不轻松了。
不是不能做，是很耗心力。
年初的时候，我试过用 Gemini 帮我生成一个作图工具。
思路是：
“
我把真实截图给进去，然后让工具套模板，生成 App Store 风格的宣传图。
这个已经比纯手工舒服很多了。
但还是挺花时间。
你要想文案，要改模板，要看每张图的效果，要处理不同语言的长度，还要确认尺寸对不对。
尤其是 App Store Connect 对截图尺寸要求很严格，差一点都不行。
03
今天这个事情就大不一样了。
我这次准备一个 iOS App 上架材料，直接让 Codex来处理。
当然我相信不只是 Codex，Claude Code 或者其他 Agent，应该也能做类似的事情。
关键不是某一个具体工具，而是现在的 Agent 已经可以把这些步骤串起来做了：
-
理解需求 -
整理文案 -
生成素材 -
检查结果 -
发现问题后继续调整
这次我的流程大概是这样的。
先讨论截图主题。
我告诉它这个 App 是干什么的：
“
有些相机、运动相机、智能眼镜拍出来的照片本身没有定位信息，但用户希望以后能把定位补回照片里。
这个 App 可以一键开启定位记录，之后批量选择照片，根据拍摄时间把 GPS 信息回写进去。
然后我们一起梳理卖点。
比如：
-
一键开启定位记录 -
数据只保存在自己的手机上，保护隐私 -
可以随时清除定位数据 -
可以一键把 GPS 写回照片 -
批量处理时会自动跳过已有定位的照片 -
也会跳过时间不匹配的照片 -
可以选择文件夹里的照片 -
定位记录间隔可以设置 -
定位数据也可以导出为 CSV 或 Excel 用
这些信息如果直接堆给用户，肯定不好看。
所以我们把它拆成了几张 App Store 截图的主题：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
然后 Codex 生成 App Store 尺寸的图。
04
这里有一个我特别在意的点：
截图里的 App 界面不能瞎编。
App Store 上架图可以设计得好看，背景可以做，标题可以写，视觉可以包装。
但里面引用的 App 截图必须是真实界面。
不能为了好看，自己画一个不存在的界面。
所以这次我让它用真实截图来做：
-
中文界面用中文截图 -
英文界面用英文截图 -
日文界面用日文截图 -
iPhone 有一套 -
iPad 也有一套
最后生成的尺寸也按 App Store Connect 的要求来。
比如：
-
iPhone 竖图： 1284 × 2778 -
iPad 竖图： 2064 × 2752
中间还遇到过 App Store Connect 提示截图尺寸不对。
以前这种问题又要自己慢慢查，现在直接把错误提示给 Agent，它就知道要调整到哪些尺寸。
05
除了图片，文案也是一大块。
App Store Connect 里面要填的东西不少：
-
App 名称 -
副标题 -
宣传文本 -
关键词 -
描述 -
版本说明 -
审核备注 -
技术支持 URL -
隐私政策 URL -
隐私相关的问题
这类文案最麻烦的地方，不是写不出来，而是你要反复对齐。
中文怎么写，英文怎么写，日文怎么写。
三种语言的意思要一致，但不能生硬直译。
App 的卖点要说清楚，但又不能夸大。
隐私说明要严谨，不能让用户误会。
这次我先让 Codex 整理中文版本，然后我们一起调整。
中文定稿以后，再同步整理英文和日文版本，并放到同一个 Markdown 文件里，方便我对照着填到 App Store Connect。
06
还有隐私政策和技术支持页面。
这个也是很多独立开发者容易拖延的地方。
App Store Connect 会要求你填隐私政策 URL，有些本地化语言还要求技术支持 URL。
如果你本来有个人网站，那其实可以放到自己网站下面。
但你还要写页面，还要整理三种语言，还要上传，还要确保 URL 能访问。
这次我也让 Codex 帮我完成了：
-
先生成本地页面 -
中文、英文、日文各一套 -
隐私政策一套 -
技术支持页面一套 -
然后放到自己的个人网站下面
这样 App Store Connect 就可以直接填 URL。
这里还有一个小细节，我觉得挺重要。
一开始隐私政策里有一句话，大概意思是：
“
除非你主动使用系统分享功能导出或分享文件，开发者无法访问你设备上的轨迹数据、照片或导出的 CSV 文件。
我看了以后觉得不太对。
因为这句话可能会让人误会：
“
是不是用户分享了文件以后，开发者就能访问了？
但实际上不是。
任何情况下，开发者都无法访问用户设备上的轨迹、照片或者导出的 CSV 文件。
用户如果导出或分享，那也是通过系统分享给用户自己选择的对象，而不是给开发者。
所以我们又把这句改得更严谨。
这就是 Agent 做这类工作的一个好处：
“
它可以很快给你一个初稿，但你仍然要把关键判断拿回来。
尤其是隐私、权限、数据处理这类事情，不能完全甩给模型。
07
其实再往前走一步，这件事本来还可以更彻底。
因为 App Store Connect 里面最后那些信息，理论上也不需要我手动复制粘贴。
Codex 可以接上浏览器自动化，把这些东西一项一项填进去：
-
名称 -
副标题 -
关键词 -
描述 -
隐私政策 URL -
技术支持 URL -
各语言截图
也就是说，从准备材料到填表提交前检查，完全可以变成全自动。
只不过可惜的是，今天我的 Codex 用量不够了。
所以我就没有让它继续把浏览器自动化这一步也做掉。
要不然这次体验可能就更夸张了：
“
我只负责确认，剩下连复制到 App Store Connect 都不用自己动手。
08
到这里，其实上架前的一整套材料已经基本齐了。
图片有了。
iPhone 有。
iPad 有。
中文、英文、日文都有。
App Store Connect 的文案有了。
隐私政策页面有了。
技术支持页面有了。
价格建议也整理了。
截图尺寸也校验了。
如果只是完成这一次 App 上架，事情到这里就可以结束。
但我又想了一下：
这套流程以后肯定还会再用。
而且不只是我会用，很多独立开发者应该都会遇到类似问题。
于是我又让 Codex 把今天的流程整理成了一个 skill。
这个 skill 里面包含了今天沉淀出来的流程：
-
先检查 iOS 项目 -
识别本地化语言和权限文案 -
确认截图主题 -
要求使用真实 App 截图，不虚构界面 -
生成 iPhone 和 iPad 的 App Store 图片 -
整理多语言上架文案 -
生成本地隐私政策和技术支持页面 -
给出定价建议 -
最后校验图片尺寸和必要文件
以后我要再上架一个 App，就不用从头解释一遍。
直接说：
“
用这个 skill 帮我准备 App Store 上架材料。
它就知道大概要问什么、查什么、生成什么、检查什么。
09
我顺手也把这个 skill 开源了。
地址在这里：
https://github.com/acelsss/ios-app-store-launch-skill
如果你也要上架 iOS App，可以直接拿去用。
当然，你也完全可以不用这个 skill，自己用 Codex、Claude Code 或者其他 Agent，一步步完成这些工作。
但用现成的 skill 有一个好处：
省 token。
更重要的是：
省脑子。
因为上架 App 这种事情，真正烦人的不是某一步特别难，而是你要记住一堆流程，还要不停地切换状态：
-
一会儿想文案 -
一会儿做图 -
一会儿看尺寸 -
一会儿写隐私 -
一会儿填 URL -
一会儿检查审核要求
Agent 很适合处理这种“麻烦但有结构”的工作。
它不会替你做最终判断，但它可以把很多重复劳动先铺好。
10
我越来越觉得，以后我们写代码之外，还会积累很多这样的工作流 skill。
不是那种很宏大的东西，而是非常具体的：
-
如何准备 App 上架 -
如何生成产品截图 -
如何整理发布说明 -
如何做隐私政策页面 -
如何检查一个新版本发布前缺什么
这些东西以前都靠经验，靠笔记，靠记忆，靠一次次重复踩坑。
现在可以把它们整理成 Agent 能执行的流程。
这件事有点像把自己的工作习惯，慢慢打包成可复用的工具。
今天这个 App Store 上架 skill，就是这样来的。
以前我想到上架材料，会觉得：
“
哎，又要开始弄那堆东西了。
现在感觉变成了：
“
把 App 给 Agent，看它先跑一遍。
这中间的心理负担差别，还是挺大的。