渐识的审核还在排队，趁这个空档把整套流程盘成文章。这篇不讲产品（那是上一篇的事），讲基础设施：一个独立开发者（外加几个 AI 助手）怎么把”从立项到上架”的每个环节都做成文档驱动、脚本执行的流水线——以及为什么到最后，每个环节的产出物都是一份文档。

立项：PRD 不是给人看的，是给产线看的

立项期的产物是一份 PRD 和一张功能清单。听起来普通，关键在它们的形态：PRD 按”三端对齐”写（iOS、后端、产品设计各自要做什么、契约是什么），功能清单用编号加状态标记（F1 到 F21，✅ 完成、⚠️ 有缺口），UI 原型直接是一份可点开的 HTML 交互稿。

这样的形态不是给人汇报用的，是给下游消费的：功能清单的状态标记直接变成开发任务的验收线；三端对齐方案变成各端的接口契约测试。立项文档的读者如果是”未来的执行者”（不管是不是 AI），它就必须是结构化、可核对的——这跟写给人看的宏伟蓝图是两种文体。

开发与测试：每个环节留一份”可复查的证据”

开发期的纪律是两条：CHANGELOG 逐条记录到 commit 号；每个重要修复跑一轮独立审计（安全审计、模型交叉审计都做过，Blocker 和 Major 级问题单独列账）。

测试期沉淀了四样东西：后端 pytest 全绿的测试套件（账号生命周期、危机干预专项各有独立测试报告）、iOS 双构建冒烟报告、一份持续维护的手工测试清单、以及版本化的截图目录（每次商店截图重制都按日期归档，历次对照能看出迭代轨迹）。

这里的关键不是”测试多”，而是每个结论都有一份落盘的报告。下一节会看到，这些报告在发布期全被消费了。

发布：把”提审前的所有检查”做成两件工具

发布期是自动化的重头，沉淀成两件东西。

其一，一份四段式发布清单：A 段是代码内已就绪项（构建设置、隐私声明、 ATS、debug 路径禁用——全部可以脚本核对）；B 段是必须人工完成的项（密钥轮换、服务器部署、ASC 网页表单）；C 段是给审核员的备注模板；D 段是回滚预案（后端切回旧版本目录、App 走加急审核、数据每日备份、紧急止血用”移除销售”）。

A 段和 C 段的形态很重要：A 段每项都是机器可验证的（比如”Release 构建禁用订阅 dev 激活路径”对应一个 #if DEBUG 编译检查），C 段直接可复制进 ASC 后台。清单里不允许存在”检查一下XX”这种不可执行的条目。

其二，一条打包上传流水线，把从构建到提审的链路固化成了标准步骤：前置检查（Xcode 版本、签名身份按 SHA-1 而不是名字确认、描述文件与证书配对验证、上传密钥就位、加密豁免声明）→ 升构建号 → Archive → 打包 IPA → altool 上传 → 到 ASC 验证状态 → 提交审核。每一步配一份报错对照表——签名不匹配、构建号冲突、合规性缺失，遇到报错先查表再动手。

前置检查里最反直觉的一条：同名证书可能有好几张，名字不可靠，SHA-1 哈希才唯一。就这一条，能消掉描述文件报错类问题的大半。

审核回合制：被拒不是事故，是一次迭代

第一轮拒绝对应的修复是纯元数据（补 EULA 链接），第二轮三项（内购推广图、第三方 AI 披露、账号删除入口）各自有响应动作。到第三轮，修复、构建、上传、重新提审已经全链路脚本化——凌晨自动完成提交，人只看结果。

支撑回合制的是几个基础设施：ASC 的 API 密钥分级（上传构建和改账号级设置需要的能力不同，自动化前先核对能力矩阵）；对 API 边界的了解（等待审核状态下连删除推广图都会被 409 拒绝——有些操作只能网页端）；以及把每次拒绝响应写进迭代日志，下次同类问题直接查表。

工具的脾气也记进了对照表：上传工具的”重复构建号”报错存在竞态误报，正确姿势是报错先查构建列表，列表里 VALID 就不重传。

技能层：把流程打包成可以点名的能力

清单和流水线再往上封装一层，就是技能（skill）。这台机器上现在维护着 60 多个技能，从工程方法（代码评审、调试方法论）、工具链（iOS 打包、游戏引擎各专项）到情报工具（多引擎检索、竞品动态监控），外加写作产线的几条（文章研究写作、批量改写、发布管线）。它们是这套自动化里复用率最高的资产。

一个技能的标准结构是三件套：SKILL.md（触发条件加执行步骤——比如打包技能的描述里写着，用户哪怕只说”打包一下”或”提审”也应该触发）、references（报错对照表、专项检查清单这类厚参考）、scripts（可直接执行的部分）。它解决的问题很具体：上一节那条打包流水线，如果没有技能封装，每次都要有人记得”先查构建列表再信工具输出”；封装成技能后，触发即执行，坑表随行。

技能还改变了跨项目复用的方式。iOS 的打包技能是渐识项目磨出来的，下一个 iOS 项目直接复用；博客产线技能从 CSDN 迁移项目长出来，反过来服务每天的日常更新。项目会结束，技能会留下——这是这套自动化里唯一越用越厚的部分。

真正自动化的是”接手”，不只是”执行”

回过头看，这套流水线里脚本只占一半。另一半是文档网络：PRD 和功能清单定义”做什么”，测试报告证明”做对了”，发布清单保证”不漏项”，迭代日志记录”踩过什么”，项目状态文档让任何一个新会话读完就能接手——它的开头甚至写着”读完本文即可接手项目，无需重新考古”。

这套东西的真正价值在上周被验证了一次：审核拒绝的响应涉及四个环节的改动，从定位到重新提审没有人工串联——因为每一步的”下一步是什么”都写在文档里，执行者（不管是我还是另一个助手会话）照着走就行。

所以完整的答案分三层：把重复动作变成脚本，把隐性知识变成文档，把两者打包成可以点名的技能。脚本省时间，文档保交接，技能让任何一个新会话第一天就拥有老手的手感。只做第一层的自动化，每次发布还是得有人盯着——因为”该跑哪个脚本、注意什么”的知识在人脑子里。

上架结果出来后我会再写一篇收尾：数据、复盘，以及哪些自动化在下个版本要再进一步。

本系列：（一）三轮审核闯关 ｜ （二）本文 · 全流程自动化
相关：博客侧的同款产线思路，见 博客产线（二）：10 个并行 agent 一天翻新 93 篇旧文章。