一个支持七八种语言的 App，商店文案改起来是真的烦。改一句描述，得登进 App Store Connect 网页，一种语言一种语言点过去改，改完想回头看"上版这句是谁动的、动了什么"看不到，网页不给你 diff。文案散在云端，既没法纳入版本管理，也没法走 PR 评审，全靠人肉记。
后来我把这套 App Store 文案搬进了 Git 管，靠的是开心上架（Appuploader）的 metadata 导出导入。思路很简单，先把商店信息导成本地文件夹：
导出目录/
├── config.yaml # 分类、版权、年龄分级
├── review_information.yaml # 审核信息
└── metadata/
└── zh-Hans/ # 每种语言一个子目录
├── name.txt
├── subtitle.txt
├── description.txt
└── ... # 每个字段一个 .txt
screenshots/ # 截图（导出时可选）
previews/ # 预览视频（导出时可选）
全是 .txt 和 .yaml，纯文本，git add 直接进仓库。下面把怎么跑、多语言和 AI 翻译怎么衔接，一段段讲清楚。
导出：把云端文案拉成本地文件夹
在 Appuploader 的应用版本详情页点「导出到文件夹」，填个导出路径（留空走默认目录）。这里有个选项——要不要连截图和预览视频一起导。勾了它会从 Apple 服务器把已上传的媒体下载下来，体积大、耗时长；你要是这轮只改文案，不勾就行，纯文本导出几秒钟的事。
导出完就是上面那个结构。每种语言一个子目录，每个字段单独一个 .txt——name.txt、subtitle.txt、description.txt、关键词、新功能、推广文本这些各占一个文件。分类、版权、年龄分级这类非文案信息落在 config.yaml，审核信息单独放 review_information.yaml。
为什么这套结构适合扔进 Git
说白了就是纯文本的天然优势。.txt 和 .yaml 都能 diff，改了哪句描述、哪个字段被谁动过，一条 git diff 看得明明白白，比在网页上凭记忆比对强太多。比如这版把某门语言的关键词整段换了，commit 记录里清清楚楚，哪天想退回上一版，git revert 一下就回去了，不用手动记上一版写的啥。
多人协作也顺了：谁改文案就开个分支、提 PR，评审过了再合，不会出现两个人同时在网页上改同一种语言、后保存的把前面的覆盖掉的惨剧。
一句话：文案一旦是本地纯文本，App Store Connect 那套"云端点来点去、改完无痕"的毛病就全绕过去了。
截图和预览视频是另一回事。它们体积大，团队 Git 仓库要是对大文件敏感，拿 .gitignore 把 screenshots/、previews/ 排除掉，只让文本进版本库就好。
多语言：按语言维护，AI 翻译起个草
多语言文案在 Appuploader 里是按语言分别维护的，每种语言下名称、副标题、描述、关键词、新功能、推广文本、各类 URL 都能填，字段旁边标了是不是 App Store 必填，省得漏填到提审才报错。还差某门语言的本地化，用「添加语言」从支持列表里多选，一次把空白本地化建好，不用一个个手点。
从零写七种语言的文案不现实，AI 翻译这步能省不少事：选一种已经填好的语言当源语言，点「翻译到其他语言」，描述、关键词、新功能、推广文本会自动翻到你选的目标语言。
这里有个坑得记牢：名称和副标题不参与 AI 翻译。因为这俩是应用级的共享字段，不是各语言独立的，得你自己手动填。别翻完一看名称还是源语言就以为工具漏了，它是故意不碰。
翻译出来的是初稿，机器对专业术语、品牌名、双关这些拿不准，发布前自己过一遍——尤其描述里涉及功能名、行业术语的地方。翻译结果和手填的没区别，哪不对直接在文本框改，改几次都行，不影响别的语言。
导回去：导入是"局部更新"，别担心覆盖
本地改完，回 Appuploader 点「从文件夹导入」，填导入路径。这步的逻辑要搞清楚——导入是局部更新，文件夹里有什么就更新什么。
只留了 review_information.yaml，那就只更新审核信息；只动了 metadata/zh-Hans/，那就只更新中文文案；空文件会被跳过，不会把 Apple 上已有的内容清空。目录里带了 screenshots/ 或 previews/，对应语言和尺寸的截图视频会被整体替换。导入完会给一份汇总，列出更新了几项、跳过几项、失败几项，每项结果都有，核对一眼对不对就行。
真要接 CI 的话，命令行也有 metadata import，把文案目录放进仓库，发版时随流水线一起导上去，网页端一次都不用开。
几个实际会碰到的问题
问：改完文案多久生效？ 分字段看。推广文本随时生效、免审核；新功能只在版本更新时必填；名称、副标题是应用级共享字段，改完得跟着下一次版本审核才生效。规划更新节奏时留意这点，别指望改个名立刻上。
问：和 fastlane deliver 比呢？ fastlane 的 deliver 也能把 metadata 存成文件夹做版本管理，CI 老手很熟。差别是 deliver 偏命令行、配置有学习成本；Appuploader 是界面导出导入为主、顺带给命令行，还带 AI 翻译和截图管理，想在 Windows 上不碰 Ruby 环境直接干这事会省心些。两个不冲突，看团队习惯。
问：只改一种语言会动到别的吗？ 不会。导入按文件夹实际内容局部更新，你只放了一种语言的目录，就只更新那一种，其余语言 Apple 上是什么还是什么。
把 App Store 文案当代码管，核心就这一条：先用 Appuploader 把 metadata 导成本地纯文本，进 Git 走正常的分支和评审，多语言配合 AI 翻译起草、人工定稿，再局部导回。一套下来，文案改动有迹可循，不用再对着网页猜上一版写的啥。
