用 Claude.md 把 iOS App 发布打包这件事管明白

你有没有这种经历：

临近发版，群里问一句“打包命令是啥？”半小时没人回。
证书/Provisioning profile 换过一轮又一轮，只有某位同事的脑子里记得怎么配。
App Store Connect 提交时被卡住：隐私条款、导出合规、版本号、截图、支持文案……一地鸡毛。

所以我看到“把 Apple Support App 发布打包进了 Claude.md 文件”这种说法，第一反应不是嘲讽，而是：这思路挺对。

Claude.md 的价值很简单：

把项目的“发布知识”变成一份可执行的说明书
让 AI 工具（例如 Claude Code）在代码库里有明确的规则可遵循
新人照着做就能发版，老同事少背锅 😅

下面给你一套能直接落地的写法：Claude.md 怎么写、写哪些、怎么用它完成一次 iOS 发布打包。

你需要的不是“文档”，是“发布剧本”

很多团队的文档死因只有一个：

写得很漂亮
没人照着执行

所以 Claude.md 的目标要明确：每一步都有输入输出。

举例：

输入：当前分支、版本号、构建号
输出：TestFlight 可安装包 / App Store 提交状态 / Release notes

把这套流程写进 Claude.md，AI 才能帮你“跑流程”，而不是跟你聊天。

推荐目录：把 Claude.md 写成“发布控制台”

你可以按这个结构来写（下面直接给模板）。

项目基本信息（Bundle ID、最低系统、依赖）
版本号与构建号规则
打包方式（本地 / CI）
证书与签名（谁维护、放哪、怎么更新）
TestFlight 流程
App Store 提交流程
发布检查清单（可勾选）
回滚与紧急修复策略
常见报错与处理

这套结构的好处：遇到问题能快速定位，不用全文搜索。

Claude.md 模板（可直接复制进仓库根目录）

文件名就叫：Claude.md

# Project Release Playbook (Claude.md)

## 0. TL;DR（发版用最短路径）
- Release branch: `release/x.y.z`
- Version: x.y.z
- Build: CI 自动递增（或手动：+1）
- Build command: 见「3. 打包」
- Upload: 见「5. TestFlight」
- Submit to App Store: 见「6. App Store」

## 1. 项目信息
- App Name: <你的 App 名>
- Bundle ID: com.xxx.yyy
- iOS Min Version: 16.0
- Xcode Version: 15.4（固定版本，别随便升级）
- Workspace/Project: <xxx>.xcworkspace
- Scheme: <SchemeName>

## 2. 版本号规则
- Marketing Version: x.y.z（产品对外版本）
- Build Number: 递增整数（每次上传 TestFlight 必须 +1）
- Tag 规则：`vX.Y.Z` 对应 App Store 版本

## 3. 打包（本地）
> 目标：导出 App Store 包（.ipa）

### 3.1 清理与依赖
- `bundle install`
- `bundle exec pod install`（如用 CocoaPods）
- `xcodebuild -version`（确认 Xcode 版本）

### 3.2 构建归档
```bash
set -e

# 例：workspace + scheme
xcodebuild \
  -workspace <xxx>.xcworkspace \
  -scheme <SchemeName> \
  -configuration Release \
  -archivePath build/<AppName>.xcarchive \
  clean archive

3.3 导出 ipa

xcodebuild -exportArchive \
  -archivePath build/<AppName>.xcarchive \
  -exportPath build/export \
  -exportOptionsPlist ExportOptions/AppStore.plist

导出产物：build/export/<AppName>.ipa

4. 签名与证书

Signing 管理方式：Automatic / Manual（写清楚）
证书维护人：@xxx
profile 更新方式：
- 走 Apple Developer 后台更新
- 更新后同步到 CI（如有）

常见错误：

Provisioning profile 不匹配
Team ID 错
entitlements 变化导致签名失败

5. TestFlight 流程

目标：把 build 上传到 TestFlight，给测试同学装

5.1 上传方式

Xcode Organizer 上传
或 fastlane：

bundle exec fastlane ios beta

5.2 上传后要检查

处理 Export Compliance（加密合规）
处理测试信息（Test Details）
Internal Testing 分组是否正确

6. App Store 提交流程

目标：提交审核并上线

6.1 提交前准备

截图/预览视频是否更新
隐私信息（Privacy Nutrition Label）是否变化
支持链接/隐私政策链接是否可访问
登录账号信息（如需要审核账号）

6.2 提交流程

App Store Connect -> 选择版本 -> 选择 build -> 填写 release notes -> 提交审核

6.3 上线方式

手动发布 / 自动发布（写清楚策略）

7. 发布检查清单（打勾用）

[ ] 版本号 x.y.z 已更新
[ ] Build number 已递增
[ ] 关键埋点/日志无敏感信息
[ ] Crash-free 指标无明显回退
[ ] 主要流程走一遍：登录/支付/订阅/核心功能
[ ] 支持文案与 FAQ 已更新（如有）

8. 回滚与紧急修复

线上问题分级：P0/P1/P2
回滚策略：
- 服务端开关优先
- 需要发紧急版本：hotfix/x.y.z+1
紧急联系人：@xxx @yyy

9. 常见坑位速查

上传 TestFlight 提示 ITMS-xxxx：多半是 plist/隐私/签名问题
构建号不递增：App Store Connect 不让过
Xcode 升级导致 bitcode/链接问题：锁定版本，别手欠


你复制过去，把尖括号的内容填掉，基本就能用。

---

## 怎么让 Claude Code 真正“按你的流程干活”

Claude.md 写完，不是摆设。

你可以这么用它：

### 场景 1：发版前 30 分钟，自动生成“发布待办”
你对 Claude Code 说：

- “读取 Claude.md 的检查清单，结合当前 git 分支和最近 20 条提交，给我生成一份这次发版待确认事项。”

你会得到一个很实用的输出：

- 哪些文件可能忘了改版本号
- 哪些功能改动需要更新 release notes
- 有没有碰到签名相关文件

### 场景 2：新人接手发布，不再靠口口相传
你把任务丢给新人：

- “按 Claude.md 第 3～6 节跑一遍，遇到错误把完整日志贴出来。”

新人至少不会卡在“我该从哪里开始”。

### 场景 3：CI 失败了，定位快一倍
你把 CI 日志贴给 Claude Code，并补一句：

- “按 Claude.md 的签名与证书约定来排查，告诉我最可能是哪一类错误，给出修复动作。”

比你在群里喊“有人看下吗”有效多了。

---

## 一份更“人话”的发布清单（建议贴到 PR 描述里）

发版当天别搞大段文字，短句最管用：

- 版本号：x.y.z
- 构建号：xxx
- 本次改动：
  - 修了什么
  - 加了什么
  - 有啥需要注意的
- 风险点：
  - 影响登录？支付？推送？
- 回滚开关：
  - 哪个配置能一键关掉新功能

你会发现：**沟通成本直接下去。**

---

## 避坑清单（都是真疼过的那种）

- **Xcode 版本别乱升**：你一升，CI 跟不上，证书跟不上，CocoaPods/SPM 也跟着炸。
- **构建号必须递增**：上传失败最常见原因，没有之一。
- **ExportOptions.plist 别靠猜**：团队统一一份，放仓库里，改动要走 PR。
- **隐私与合规别拖到最后一分钟**：App Store Connect 一卡，你就只能干等。
- **把“支持文案/FAQ”当发布的一部分**：用户遇到问题，第一时间不是给你发邮件，是去打 1 星。

---

## 你现在就能做的三件事

- 在仓库根目录新建 `Claude.md`，用上面模板填一版。
- 把“发布检查清单”贴到发版 PR 模板里，让每次发版都走一遍。
- 让团队约定：发布相关变更（证书、导出配置、fastlane）必须更新 Claude.md。

发版这件事本来就不该靠记忆力。把流程写死，大家都能少熬夜。😌

用 Claude.md 把 iOS App 发布打包这件事管明白：一份能直接照抄的发布清单（含模板）