上周四晚上快十一点我把一句话需求敲进终端然后合上电脑睡觉去了。第二天早上九点多AI Agent 停在 App Store 提审前的最后一步——960 个执行步骤、8 条人类消息、全程跑了约十个小时一个 iOS 应用已经出现在 App Store Connect 的审核队列里。说实话我一开始以为自己看错了翻了一下执行日志才确认中间那些代码、构建、截图、隐私政策、提审材料全是 Agent 自己搞定的。这个项目本身不是什么宏大产品就是一个极简习惯打卡 App但它验证了一件事AI Agent 已经能独立扛起一个“从零到提审”的完整交付链路而不是停留在帮你补全函数、写写测试用例的阶段。这篇文章就把整个过程拆开讲包括 960 步是怎么跑出来的、8 条消息分别发在什么节点、哪些地方必须人工拍板、哪些坑差点让整个流程作废以及这套玩意的成本和边界。1. 项目全貌一句话需求如何撑起 960 步1.1 需求原文与最终成果当时丢给 Agent 的需求原文是这样的做一个极简习惯打卡 App用户能自定义习惯、每天打卡、查看连续天数支持本地通知提醒界面干净清爽。免费下载用内购解锁高级功能云备份和主题。直接帮我做到 App Store 提审。就这么一段话没有产品文档没有原型图没有设计稿。Agent 最终交付的成果是一整套提审材料完整可运行的 Xcode 工程、SwiftUI 实现的功能、三套尺寸的截图、App Store Connect 里的应用版本记录、内购商品配置、隐私政策页面以及一条已经创建好的审核提交记录。说几个关键数字整个任务分解为 960 个执行步骤Agent 自动修复了 40 多次编译或逻辑错误中途只向我提了 7 次问题加上最初的需求输入我总共发了 8 条消息。Token 消耗约 95 万按当前主流模型的价格折算整个流程的 API 成本在 20 到 30 元人民币量级比我预想的低不少。1.2 为什么 Agent 可以独立跑完这个流程很多人一听“Agent 跑 App Store 提审”就觉得夸张其实拆开看这个任务链并没有超出当前 Agent 工具的能力边界。它本质上是一连串可自动化的文件操作、命令执行和 API 调用难点在于步骤多、跨度长而不是某一步特别难。这里面有几个关键技术前提。第一Agent 运行在终端环境里具备完整的文件读写、命令执行和网络请求能力可以调用 Xcode 命令行工具链、App Store Connect API、以及各类静态托管服务。第二我给它配置了完善的系统提示词明确规定了“遇到产品决策必须问用户”“连续失败三次必须暂停报告”等行为边界这让它既能自主推进又不会一路狂奔跑偏。第三也是最重要的当前主流 Agent 都支持长时间运行和状态断点恢复哪怕中间某个环节崩溃它也能从最近的检查点重新拉起继续跑不会一夜白干。1.3 环境与工具清单这次实践用到的核心工具链我列一下方便想复现的朋友对照准备运行环境macOS Xcode 16安装完整 iOS SDK 和命令行工具工程生成XcodeGen用 YAML 描述工程结构避免 Agent 直接手改复杂的 pbxproj 文件构建与签名xcodebuild 命令行自动读取开发者账号的证书和描述文件构建上传xcrun altool App Store Connect API Key实现 ipa 无人值守上传提审操作App Store Connect API创建应用版本、填写元数据、提交审核隐私政策托管一个支持强制 HTTPS 的免费静态托管服务模拟器截图xcrun simctl 控制模拟器启动、安装、截屏在这些工具的支持下Agent 不需要依赖图形界面所有操作都能通过命令行完成。这也是整个项目能跑通的最底层原因——苹果的开发工具链提供了完整的 CLI 能力Agent 只是把这些命令按顺序执行到位。2. 8 条消息背后的自治边界设计2.1 8 条消息的完整时间线好奇的人肯定先问8 条消息到底发了什么我把完整时间线贴在下面你可以看到每个消息都恰好落在需要人类判断的岔路口上。序号触发时机我实际发送的内容1任务启动完整需求描述即上面那句“极简习惯打卡 App”2方案设计阶段技术栈用 SwiftUI变现模型按你说的做UI 文案你来拟3产品命名阶段App 叫“点滴打卡”图标走极简风格主题色用深青4UI 视觉阶段强调色改成暖橙打卡动效做轻一点不要花哨5内购配置阶段试用期 7 天永久解锁定价 18 元你按这个写配置6隐私政策阶段隐私政策页面你用托管服务部署好链接发我确认7截图生成阶段三套尺寸素材和文案你定生成完我来看一遍8提审提交前材料我核过了提交审核吧这 8 条消息看起来零散但如果你把 Agent 的执行流程看成一棵树每一条消息都对应着一个“人类才能拍板”的分叉节点产品名、价格、视觉方向、法律文本、最终授权。其他所有环节包括代码怎么写、构建怎么配、错误怎么修、截图怎么生成Agent 全权负责。2.2 确认点为什么这样设计一开始我也想过完全放手让 Agent 自己连名字一起定但思考之后还是设了这 7 个确认点。原因很简单这些决策一旦做错返工成本极高而且很可能是在几百步之后才暴露出错误。举个例子如果 Agent 自己拍板了 App 名称和图标到了提审阶段发现名称和某款已上架应用撞了或者图标风格与内容审核要求冲突Agent 需要回溯修改的地方就不只是字符串还有工程配置、本地化文件、宣传图甚至可能影响已经生成的截图素材。这种“下棋时思考后面三步”的思维决定了哪些决策必须前置确认。另一个逻辑是控制 Agent 的“注意力漂移”。长时间自主执行的任务很容易在某个小问题上过度纠结或者自作聪明地改掉需求里用户其实很在意的设计倾向。通过固定确认点相当于在长任务里加入了校验锚点既能让 Agent 保持大方向正确也给了用户阶段性了解进度的窗口。2.3 960 步是怎么统计出来的你可能还想知道960 这个数字是怎么数出来的。我使用的是 Agent 执行日志中的“工具调用步数”口径每一次文件读取、文件写入、命令执行、API 请求都计为一步。模型自身的推理过程不计入步数。也就是说960 步是 Agent 实际与环境交互的次数不是它思考的次数。我翻了一下日志整个执行过程中各类操作的分布非常有趣这里用表格展示执行阶段步数主要操作内容需求解析与任务规划42 步拆解需求、生成任务清单、选择技术方案工程脚手架构建86 步编写 XcodeGen 配置、创建目录、生成工程功能实现编码312 步写入 SwiftUI 视图、数据模型、内购逻辑、通知逻辑构建调试与修复294 步执行 xcodebuild、读取报错、修改代码、重新构建UI 打磨与截图128 步调整布局参数、启动模拟器、生成三套尺寸截图提审材料与提交98 步调用 API 配置应用、部署隐私政策、创建审核提交合计960 步蛮有意思的是纯粹“写代码”的步骤只占三分之一左右剩下的大量步数都消耗在构建、调试、修复这类“试错循环”上。这和你平时写 App 的开发体验完全一致——真正花时间的从来不是敲键盘而是编译、测试、踩坑、再编译。3. 960 步执行链逐段拆解3.1 需求解析与规划阶段42 步Agent 拿到需求后并没有直接开始建工程。它做的第一件事是把一段话拆成可执行的子任务。我查看日志时发现它先建立了一个任务依赖图把“功能开发”和“内购配置”标记为并行可推进把“提审材料生成”标记为所有功能完成后的后续任务。这一阶段有个值得借鉴的设计Agent 要求自己先输出一份“三文档”再动手包括功能清单、技术选型、风险点清单。功能清单就是打卡、统计、通知、内购这些模块技术选型里它明确写了用 SwiftUI SwiftData StoreKit 2理由是工程最简单、不需要额外依赖适合快速跑通风险点清单里列了推送通知权限文案、内购商品审核联动、截图尺寸规范这些都是它根据历史经验预判的坑。这 42 步对我的启发是越是看似简单的一句话需求越不能省掉规划阶段。Agent 的规划质量直接决定了后面几百步的稳定度。如果它一上来就埋头写代码大概率会在中途反复推翻自己浪费大量步数。3.2 工程脚手架与功能编码398 步工程生成阶段Agent 选择了 XcodeGen 而不是直接创建 Xcode 工程这个选择非常关键。pbxproj 文件的格式既繁琐又脆弱哪怕是手工修改也容易出错而 Agent 通过 YAML 配置生成工程可以随时重建每次改动都可预期。配置里包含了 target、bundle identifier、签名配置、Info.plist 的权限声明、资源目录映射等信息。功能编码阶段Agent 实现的核心功能包括习惯模型的增删改查、日历打卡视图、连续天数计算逻辑、本地通知调度、StoreKit 2 内购流程。这里有一个细节让我印象很深连续天数统计的逻辑正常情况下要处理“跨年”“时区”“用户修改系统时间”这些边界情况Agent 在写代码时主动加了相关处理这说明它在训练数据里见过足够多类似的坑。编码过程中的文件读写操作非常频繁每个 Swift 文件都会经历“写入初始版本 → 构建报错 → 修改 → 再写入”的循环。日志中能看到大量 diff 记录有些文件的修改次数超过十次。这种迭代式开发对 Agent 来说完全不存在“烦躁”情绪但对人来说手动盯这么多轮确实容易疲劳这也是它能跑完一整夜的原因。3.3 构建调试智能修复回环294 步这个阶段是 960 步里的重头戏也是最容易被低估的部分。Agent 每完成一批代码修改就会执行一次构建命令常见的错误包括缺少 import、类型不匹配、API 使用错误、资源文件缺失等等。它处理错误的逻辑让我想起资深工程师的排查思路。比如有一次构建报错日志显示 Agent 没有直接去改报错的那一行而是先读取了相关的完整文件上下文又查了 SwiftData 的模型定义最后判断出问题根源是模型关系声明和视图层的数据绑定不一致于是改了模型层的数据访问接口而不是仓促地在报错行打补丁。这种“先定位根因再动手”的行为模式不是靠硬编码规则能实现的而是模型推理能力的体现。当然也有翻车的时候。有一次 Agent 为了修复编译错误误删了 Info.plist 中一个必要的权限声明导致下一次构建出现了新的错误。日志显示它发现自己引入了新问题后主动回退了文件改动改为更保守的修复方式。这恰好印证了当前 Agent 的能力边界它很强但也需要试错空间而试错循环本身就是步数的大头。3.4 截图资源与提审材料226 步截图和提审材料阶段Agent 的操作包括启动模拟器、安装应用、执行操作脚本、生成截图、用脚本检查截图尺寸和内容是否符合规范。这一步的实际难度在于模拟器启动很慢安装应用和渲染页面都需要等待Agent 必须正确处理超时和状态检查。提审材料部分更是琐碎到让人头大。应用描述、关键词、支持网址、营销网址、隐私政策网址、版权信息、审核备注每一项都必须填写完整而且格式要求严格。Agent 处理这些内容时展现了一个让我很欣赏的能力——它会根据 App 的实际功能自动生成文案然后在确认点发给我审阅而不是自己默默填完。这与它系统提示词里的规则直接相关也说明“哪些内容需要人确认”这件事是可以通过提示词设计来控制的。整个流程最后一步Agent 调用 App Store Connect API 创建了审核提交。我在日志里看到它按顺序完成了构建上传、版本创建、元数据填充、内购商品关联然后停在最终的确认提交节点等我发第 8 条消息。这个设计非常稳妥因为提审是不可逆的动作提交后如果有问题只能等审核结果再处理交给用户做最终确认是合理的。4. Agent 自动化提审的实操要点4.1 用 App Store Connect API 完成提审操作如果你也想复现类似流程最需要提前准备的是 App Store Connect API Key而不是 Apple ID 密码。API Key 允许 Agent 以开发者账号的身份操作应用管理相关接口而不会暴露账号密码安全性和可分配权限都更可控。我在创建 API Key 时分配了“App Manager”角色因为只有这个角色及以上才能修改应用版本信息和提交审核。如果只给了“Developer”角色Agent 会在创建版本或提交审核时收到 403 错误这个坑我后面踩到了现在提前写出来。API Key 的私钥文件和 Key ID 存到本地安全目录Agent 通过环境变量读取不会写进工程或日志里。上传构建包用的命令类似下面这个样子xcrun altool --upload-app -f /path/to/App.ipa -t ios \ --apiKey $APPSTORE_API_KEY --apiIssuer $APPSTORE_ISSUER_ID注意这里必须使用 API Key 认证方式而不是传统的 Apple ID 方式。传统方式会在终端弹出交互式验证Agent 根本没法处理API Key 则完全适合无人值守场景。4.2 提审材料的自检清单Agent 在提审前会执行一轮自检我整理了一下它的检查逻辑可以作为任何人手动提审前的对照清单检查项具体内容失败后果应用元数据名称、描述、关键词、分类是否完整提审被拒截图素材三套尺寸是否符合要求内容是否清晰提审被拒隐私政策URL 可访问必须强制 HTTPS元数据缺失被拒权限声明通知权限用途说明是否合理被拒或功能审核拦截内购商品至少一个商品处于有效状态并关联版本提交报错构建版本构建号与代码版本号一致且已上传完成无法进入提审流程审核备注测试账号、功能说明是否填写审核周期变长这份清单本质上是把苹果审核指南里的硬性要求结构化。Agent 在自检时一旦发现某项缺失会先尝试自我修复修复不了才发起人工消息这和“确认点”的设计逻辑一致。4.3 成本与时间对照整个项目跑了一夜我睡前和醒来分别记录了状态。开始时间是晚上 10 点 50 分左右最终完成时间是第二天早上 9 点出头中间有几次因为构建排队和上传等待的停顿实际 Agent 工作状态和等待状态交替出现。当然这并不能说明 Agent 比真人开发者更高效而是它在无人值守时可以连续推进把碎片时间全部利用起来这一点人做不到。成本方面Token 消耗 95 万。如果你是自部署模型或者使用编程专用模型成本可能略有浮动但整体上这个量级意味着让 Agent 跑一个完整提审流程比请人干活便宜得多但比纯代码补全贵得多因为它需要大量的试错和工具调用每个工具调用都会消耗上下文窗口。5. 踩坑实录与排查思路5.1 Agent 陷入死循环如何熔断凌晨三点左右日志显示 Agent 在重复尝试解决同一个构建错误连续构建四次都失败而且修改的内容越来越偏开始改动一些与错误无关的代码。这个问题如果不及时控制Agent 可能一直空转到天亮消耗大量 Token。我的解决方案是预先在系统提示词里写下熔断规则连续三次同类失败必须停止当前策略切换到“读取更多上下文 → 重述问题 → 换一种方案”的模式如果连续六次失败直接停止并向用户报告。这个规则生效后Agent 在第二次触发熔断时改用了一种更简单的方式实现功能绕开了复杂 API构建立刻通过。后来我发现熔断规则不仅救了这一次还避免了后续多个潜在死循环。5.2 模拟器截图尺寸和比例不匹配截图阶段踩了一个典型坑Agent 生成的截图放进提审材料后我人工复核发现部分内容被裁切原因是模拟器窗口的渲染比例和最终输出尺寸不一致尤其是带圆角和刘海屏的设备直接用系统截图命令输出的是带黑边的原始帧需要额外裁剪或遮罩处理。Agent 的调整方式是在截图命令里加入了遮罩参数和分辨率控制把输出精准对齐到苹果要求的像素尺寸。另一个小坑是App Store 对 iPhone 和 iPad 的截图尺寸要求不同Agent 第一次只生成了 iPhone 尺寸iPad 截图缺失被它后续的自检发现并自动补齐。这类问题如果人工审核通常要花不少时间去核对规范Agent 反而做得更细致。5.3 App Store Connect API 权限不足比死循环更隐蔽的是权限问题。Agent 第一次尝试创建 App 版本时API 返回 403它立刻停下来问我。我检查后发现API Key 的角色是“Developer”只有“App Manager”才有权修改版本并提交审核。这个问题的麻烦之处在于它不报错说“权限不足”而是报一个相对模糊的“无权限操作”如果没有足够的经验很容易误判为 API 调用参数错误。排查过程其实不难登录 App Store Connect 后台查看用户信息里的 API Key 角色即可。但这件事提醒了我给 Agent 配置的正式环境权限必须提前按照实际任务需求规划好不要抱着“先给最小权限试试”的心态否则中途返工浪费的时间远超配置那几分钟。5.4 内购商品状态与提审的联动关系内购配置阶段有一个很容易被忽略的隐藏规则——内购商品需要有效状态才能随 App 一起提审。第一次尝试提审时Agent 报错提示“没有可用于审核的内购项目”原因是我确认第 5 条消息后它在后台创建了内购商品但商品状态还停留在“缺失元数据”的草稿阶段没有完整填写当地化名称和价格。Agent 根据报错提示补充了完整元数据把商品状态推进到“等待审核”然后再走提审流程就通畅了。这个坑我觉得特别值得记录因为很多备案类操作都有类似的前置依赖Agent 如果只是机械执行而不理解状态机流转很容易卡在这种隐性问题上一筹莫展只有具备完整工作流认知的模型才能主动发现。6. 几点复盘体会6.1 一套能复用的“一句话需求”模板这次的经历让我总结出一条经验不是所有一句话需求都适合交给 Agent 去跑能跑通的需求往往具备两个特征一是交付物边界清晰二是决策点可以前置枚举。比如“做到 App Store 提审”就是清晰边界而“做一个大概率能火的 App”就不是因为后者没有一个客观的完成标准。如果你也想做类似实践我建议需求描述里至少要包含四要素产品形态、核心功能、变现模式、交付标准。我这次的描述恰好都覆盖了Agent 才能立刻进入执行状态而不是反复追问。少一个要素你可能会多发好几条消息甚至可能让 Agent 在错误的路上狂奔很远。6.2 人在回路中的角色不是监工而是决策者这 8 条消息让我重新思考了“人机协作”这件事。我全程没有盯过一行代码也没有在编译错误上报时报时跑去引导它修改我只是在几个关键决策点上做了选择题。这种感觉很像带一个能力很强的实习生你不用告诉他每行代码怎么敲但你需要在产品方向、技术路线、上线决策上把好关。对于想要低门槛体验 AI Agent 开发能力的朋友我建议从一个交付路径明确的小工具开始先把基础设施配好再逐步放开确认点。AI Agent 的能力提升速度不会慢但人这一侧对任务边界和风险控制的理解才是真正决定项目成败的东西。