用规则引擎与大模型打造App Store审核Agent，让拒审可分析可预防

最近被拒得多了，很烦。不是一次两次，而是连续两三个提审版本接连吃灰，每次商店发来的通知都写得像一份加密电报——有条款编号，有截图标红，可就是说不清你那个功能到底哪里越了线。老实说，在动手之前我试过各种办法：对照审核指南逐条自查、把应用截图打印出来贴墙上反复看、找有经验的同行帮忙复盘，有效果，但都不够。于是我在一个周末决定不再被动挨打，亲手捣鼓了一个 App Store 审核 Agent，专门干一件事：把“被拒”从玄学变成可以分析、可以预防的对象。这篇文章就把这个 Agent 的思路、架构、实现细节和翻车经历统统摊开讲，给同样在提审循环里挣扎的开发者做个参考。

要说清楚这个 Agent 能干什么，得先从我被折磨的真实场景讲起。

1. 被拒循环里的真实处境：我为什么决定自己捣鼓一个审核 Agent

1.1 高频拒审的四种形态，其实是可以被分类的

我翻了自己近一年的提审记录，发现被拒根本不是随机事件，而是高度集中在几类问题上。

第一类是元数据与一致性审查。应用描述里写了付费订阅功能，结果截图里没有任何关于付费的界面；应用名称里带了“智能”两个字，主页却是一个静态工具页。这类问题描述起来很简单，但真到提审前，开发者往往只顾着改代码，根本没人会去逐字比对应用描述和截图内容。

第二类是注册登录与隐私权限处理不当。没有提供游客体验方式却强制要求手机号注册、权限申请时机不合理、隐私政策里写了 SDK 采集数据但应用内没有对应说明。这类问题现在越来越高频，尤其是涉及位置、相机、相册和通讯录权限的功能。

第三类是订阅购买流程不符合规范。免费试用没有清晰提示、续费说明藏在二级页面、取消订阅引导不够明显。这类问题一旦被盯上，通常不是单个界面的事，而是整套交易流程的合规性问题。

第四类是内容重复或定位不清。如果你的产品和某些已有应用在功能上高度相似，商店经常会给出一句“你的应用没有提供足够的差异化体验”就拒掉，这算是最让人头疼的一种，因为它不完全靠代码自检能解决。

我当时的感受是：大部分被拒背后是有迹可循的，只是需要有人把散落在各处的信息收拢起来做交叉判断。这个收拢和交叉的过程，非常适合交给 Agent。

1.2 被拒邮件不是诊断书，而是一张症状清单

商店的拒审通知通常会引用条款编号，比如 2.1、3.1.1、4.3、5.1.1 这类编号，但很少详细解释“你为什么会在这一步翻车”。它更像是医生给了一张症状清单，告诉你发烧了、咳嗽了，却没告诉你到底是病毒性感冒还是细菌感染。

举个例子，同样是被判 4.3 重复内容，可能是你的界面交互逻辑抄了一个热门应用，也可能是你的功能点太单薄撑不起一个独立产品，还可能是宣传语和实际体验差距过大。三种情况对应的整改动作完全不同，但通知正文几乎不会区分。

在同时维护多个产品线的时候，这种模糊性带来的代价是巨大的。你要花大半天时间对照应用截图、翻代码逻辑、试着揣摩审核员到底看到了什么。一个 Agent 如果能把通知原文、条款库、你当前代码里的功能清单放在同一个上下文里去推理，就能把“揣摩”这件事变成一个相对确定的匹配过程。

1.3 提审节奏被打乱之后，我决定把经验沉淀成系统

被拒最伤人的其实不是条款本身，而是节奏。一次提审从整理素材到最终过审，周期经常在三天到两周之间。一旦被拒，版本计划、市场排期、广告投放全部要跟着重新排。独立开发者和中小团队最怕的就是这个，因为人力本来就少，一次被拒可能直接导致一个功能延期上线。

我最后下决心做 Agent，不是因为我有多少算法功底，而是因为我觉得这笔时间账值得算。与其每次都被动等通知，再花两三天人工排查，不如把这些反复出现的判断逻辑固化成一个工具。这个工具不需要多聪明，只需要做到三件事：把通知拆干净、把条款库匹配准、把整改清单列明白。

于是在那个周末，我开始了这个被我称为“审核 Agent”的小项目。

2. Agent 的定位与架构选择：它不替你做决定，但替你把雷区摸清楚

2.1 先划清边界：Agent 能管什么，不能管什么

动手写代码之前，我先给自己定了几条铁律，避免工具失控变成负担。

Agent 能管的是信息收集、条款匹配、风险预检和整改清单生成。你可以把一封拒审邮件粘进来，或者把提审前要填写的元数据、隐私政策摘要、截图说明丢进来，它输出一份带风险等级的报告。Agent 不能管的是：替你改代码、替你回应审核团队、替你保证这次一定过审。

这个边界必须想清楚。很多人一听“审核 Agent”，第一反应是“是不是能骗过审核”“能不能绕过规则”。恰恰相反，我把这个 Agent 定位成一个合规性自检工具，它存在的意义是让你更准确地理解自己的产品哪里越了线，而不是帮你造假或者掩饰。产品本身如果有硬伤，Agent 会劝你改，要不要改、怎么改，决定权依然在你手上。

2.2 为什么选用“规则引擎 + 大模型”的混合架构

最开始我也想过纯规则引擎方案：拿一堆 if-else 去匹配通知文本里的关键词。比如匹配到“试用”“订阅”“退款”，就直接跳到订阅合规检查流程。但跑了几天就发现不够用，因为审核通知里的自然语言变种实在太多，今天说“free trial”，明天说“subscription terms”，后天可能变成一句话里同时夹着三个条款编号。规则永远比不过措辞的变化速度。

反过来，如果完全依赖大模型来做判断，又会产生幻觉问题。我实测过直接把通知文本丢给大模型让它给结论，它经常会把没出现过的问题也列进去，比如自行脑补出“应用可能包含隐藏功能”，实际上完全没这回事。这会把人带偏。

最后的方案是混合架构：规则引擎负责抽取结构化信息和精确匹配条款编号，大模型负责处理语义模糊的部分，比如解释“为什么这个交互会被认定有误导性”。两边的结果汇总到一个报告生成器里，由报告生成器按固定模板输出，确保格式稳定、不会跑偏。

2.3 核心工作流：收集→解析→匹配→追问→生成

整个 Agent 的核心流程我用一句话就能讲清楚：把一份杂乱的审核材料，经过五个环节，变成一份可执行的整改报告。

第一步是收集，支持手动粘贴文本或上传文件。第二步是解析，把应用名称、版本号、被拒条款号、审核员描述从原始文本里拆出来。第三步是匹配，拿解析结果去本地审核条款库中找最接近的历史案例和风险描述。第四步是追问，Agent 针对信息缺失项主动提出三类问题：这些功能在最新版本中是否被修改过？隐私政策是否已同步？截图中是否有即将上线的新界面？第五步是生成，按风险等级输出整改清单。

如果你已经用过市面上各种大模型对话产品，你会发现这个流程本质上就是一个带状态机的多轮会话系统。不同的是我加了一道规则引擎的保险，所有结构化的字段都必须通过规则解析得到，大模型只负责对非结构化文本做语义补充。

2.4 成本、延迟与可解释性的折中选择

很多朋友问我这套东西跑起来贵不贵。我用的方案是调用通用大模型 API，加上本地规则库和本地 OCR 工具。单次解析审核通知的调用成本基本可以忽略不计，大概和一瓶矿泉水的价格相比都算便宜，延迟在几秒到十几秒之间，完全够用。

我更看重的是可解释性。Agent 给出的每一条风险提示，都必须能回溯到审核通知原文或者条款库里的某一条记录。这个设计让我不会盲目相信它的结论。如果 Agent 说“当前提审存在订阅条款风险”，我必须能点击看到它依据的是哪一段原始描述。只有这样才能在误判发生时快速定位问题，而不是把一个正确功能改成错误功能。

3. 从一堆废话里挖出真信息：拒审消息解析模块的实现细节

3.1 第一步：把邮件文本拆成结构化字段

写解析模块的时候，我告诉自己不要急着上大模型，先老老实实用正则把基本字段抽干净。审核通知的格式整体比较固定，App名称、版本号、Build编号、条款编号基本都有固定位置。

我写了一段类似这样的解析脚本：

import re def parse_rejection_text(raw_text): app_name = re.search(r"(?:App Name|应用名称)[:：]\s*([^\n]+)", raw_text) version = re.search(r"(?:Version|版本)[:：]\s*([\d.]+)", raw_text) guideline_terms = re.findall(r"Guideline\s+(\d+(?:\.\d+){1,2})", raw_text, re.IGNORECASE) return { "app_name": app_name.group(1).strip() if app_name else None, "version": version.group(1).strip() if version else None, "guideline_terms": guideline_terms, "original_length": len(raw_text), }

这段代码的作用不是展示什么高深技巧，而是传达一个思路：先让机器把最确定的信息摘出来，后面喂给大模型的上下文才不会是几百行杂乱无章的邮件全文。过滤噪音这一步往往决定整个 Agent 的判断质量。

解析完字段之后，我会把结构化结果和原文拼接成一段新的提示词，一起送给大模型。这样做的好处是，大模型不需要自己去猜应用名字和条款编号，它只需要集中精力分析语义风险。

3.2 第二步：把历史被拒记录变成自己的审核条款库

解析只是入口，真正的大头是审核条款库。我没有去网上照搬别人的清单，而是把自己过去数十条被拒邮件和当时的产品状态全部整理成结构化记录。

每条记录包含四个字段：条款编号、严重级别、高频触发点、建议动作。比如条款编号里常见到的 3.1.1 和 5.1.1，分别对应交易机制相关和隐私权限相关的审核条款。严重级别我会分成高中低三级，触发点则记录具体的界面或代码行为。

表格形态大致是：

这个条款库最值钱的地方不是条款文本，而是“触发点”和“建议动作”之间的因果关联。因为它埋在我的失败经验里，带有真实的代码上下文。Agent 在做匹配时，并不是只给一个条款号，而是把“你的登录页没有游客入口”这种具体描述和历史上的类似案例做类比，给出的整改建议才能落地。

3.3 让 Agent 学会“追问”：上下文记忆与迭代排查

第一版 Agent 非常蠢，拿到一封拒审邮件后直接给一个结论，准确率不到六成。问题出在我没有设计追问环节，模型只要信息不足，就会自信地编一个理由。

后来我加入了上下文记忆和追问机制。核心是让 Agent 在首轮分析后不要急着下结论，而是先出具一份“不完整项清单”，把信息缺失的部分标出来。比如：

以下是商店审核拒绝通知的原文，以及我们提取到的结构化信息。 请你先不要给出最终整改方案，而是完成三件事： 1. 提炼通知里涉及的核心风险点； 2. 判断哪些问题属于信息缺失、哪些属于确定违规； 3. 列出至少三个需要开发者进一步确认的问题。

这招相当有效。因为审核通知里经常出现“需进一步查看附件截图”这样的模糊表述，如果不追问，Agent 会拿着不完整的信息强行推理。加入追问后，它会把“截图内容未知”作为一个风险前提标注在报告里，我会在解析完截图后回填信息，再让 Agent 进行第二轮交叉验证。

3.4 截图与界面描述联动：最麻烦但收益最高的一步

不少拒审通知会附带截图，图里的信息往往比文字更有价值。但大模型没法直接看图，我就在流程里加了一个 OCR 工具，先把截图里的中文、英文文字全部提取出来，再把关键控件位置和文字描述传给 Agent 分析。

这一步实现起来非常麻烦，因为截图质量参差不齐，有的图里文字被遮挡，有的图是深色模式，OCR 结果全是乱码。我处理的办法是尽量只提取与拒审条款相关的关键区域，比如订阅确认弹窗、权限申请弹窗、登录页面。

但收益也确实高。之前有个案例，审核通知说“不能确定用户是否已知情”，我们通过 OCR 发现元数据截图里订阅金额显示不全，原因很快定位。可以说，文本解析解决 60% 的问题，截图联动解决 25% 的问题，剩下的 15% 要靠人对产品的判断。

4. 提审前风险预检：把“被拒”从事后后悔变成事前预防

4.1 预检清单的构成：一半来自官方条款，一半来自自己的血泪史

Agent 除了能在被拒后帮忙分析，还能在提审前主动做风险预检。我给它维护了一张动态预检清单，每次准备提审新版本时，它会按清单逐项询问开发者并提供判断依据。

清单分成四类。第一类是页面与流程检查，包括新功能是否有完整入口、原有功能是否被意外移除、空状态界面是否合理。第二类是权限与隐私检查，包括权限申请是否在功能使用时弹出、隐私政策是否覆盖所有数据采集行为、第三方 SDK 是否有对应声明。第三类是交易与订阅检查，包括价格展示是否一致、免费试用描述是否清晰、取消订阅入口是否可达。第四类是内容与元数据检查，包括应用名称是否包含堆砌关键词、截图是否与最新功能一致、描述里是否有夸张宣传语。

这些检查项不是我从某个现成工具里抄来的，而是大量历史被拒邮件做了反向归纳之后得到的。每一类问题后面都挂着一串真实案例，Agent 会根据当前版本的功能变更点自动决定哪些检查项需要强制提醒。

4.2 最容易翻车的元数据细节：描述和截图交叉一致

我观察到，很多同行被拒并不是败在代码上，而是死在元数据上。说得直白点，审核员在有限时间里对你的产品建立认知，基本靠应用描述、商店截图、关键词和内购项目名称。如果这四种信息互相打架，即使代码再合规，也很容易因为“功能描述不准确”被拦下来。

我在预检阶段让 Agent 做一次交叉一致性检查：把应用描述里提到的每一项核心功能，与商店截图里的文字和界面一一对照。举个我自己的例子：有次新版加入了生成头像功能，但提交的截图还是上上个版本的工具页，实际试玩环节根本没有头像入口，结果被判定为“描述与功能不符”。这种问题其实非常蠢，但人工核对的时候很容易因为熟悉产品而忽略。Agent 一分钟就能查出来，因为它不带任何产品滤镜。

4.3 让经验持续回流：每一次被拒都更新预检清单

Agent 最让我满意的一点，是它具备经验回流的闭环能力。每次被拒之后，我会把审核邮件、被拒时提交的元数据、当时的代码版本、后续处理方案一起打包写入条款库。

同时，我会让 Agent 从这次被拒中提炼出一个新的检查项。比如某次因为订阅取消流程不够明显被拒，条款库里就自动多了一条“取消订阅路径必须从设置页到达，且点击次数不超过两层”，这个检查项以后每次提审都会出现。

这个机制让工具越用越准，不是靠某种玄学，而是靠案例驱动。每次新被拒就像往数据库里扔了一块拼图，下一次提审时 Agent 会拿当前产品和历史上所有被拒过的产品做相似性类比，提前告诉你有哪几条坑大概率还会踩。

5. 实测效果与翻车现场：用了一个多月，它帮我避开了大部分坑

5.1 一组不吹牛的实测样本

我把自己过去六个多月的被拒记录整理成测试集，总共三十多封历史邮件，跑了一遍 Agent。结果是有近九成的邮件能被正确定位到核心条款和主因，极少数邮件解析失败，还有一封被误判成完全无关的风险类型。

真正上项目实测发生在最近一个月。我提审了两个新版本，Agent 在预检阶段分别提前发现了一个真实问题。其中一次是订阅页面的试用说明文字被折叠到二级页面，它直接拉响了高风险预警，我赶在提审前把文案挪到首屏，避免了一次整体退回；另一次是隐私政策里漏掉了新接入的统计 SDK 声明，Agent 在授权环节拦住了我。

这一阶段我自己的提审心态明显稳了很多。以前提审完总有一种交卷前的焦虑，现在至少知道该补的都补了，剩下的风险是可解释、可接受的。

5.2 翻车现场：它也曾把我带进沟里

如果不聊翻车，这篇分享就不够完整。我的 Agent 在测试中最大的问题有两个：一是过度解读，二是幻觉条款。

最典型的一次，它对“登录页没有游客模式”给出了高风险警告，理由是“可能被判定为强制注册”。但实际上这是一个内部工具型应用，用户群体本来就需要账号权限，强制登录不存在误导性。Agent 分不清“强制注册”和“场景内必须登录”的区别，差一点让我花了一天时间去加一个没必要的游客入口。

另一次它干脆引用了条款库里根本不存在的编号，我查了半天才发现是它自己拼接出来的。从那以后我在报告模板里加了一行强制提示：“所有条款编号必须来自原文或条款库，禁止自行补充。”这句话写进 Prompt 之后，类似幻觉减少了很多。

现在的处理原则是对 Agent 输出的高风险项逐条验证，中低风险项只做参考。它负责初筛，我负责终审，双方配合才能既高效又不跑偏。

5.3 我建议的最终工作流：Agent 初筛，真人终审

如果你也想做一套类似的审核 Agent，我给一条建议：不要从公开的通用清单开始，而是先从自己近一年的被拒邮件开始反推。别人的高危项可能是你的正常功能，只有你自己真实被拒过的案例才最值得沉淀成规则。

目前我日常提审的流程非常简单。提交前，把所有物料发给 Agent，让它生成一份风险分级报告。我逐个处理高风险项，处理完把改动说明写进对话记录，再让它重新分析一次。确认没有新的高风险提示后，才进入提交流程。

整个过程并不复杂，但它把我从“靠运气提审”变成了“带着报告提审”。

最后再分享一点个人体会。这个 Agent 不会魔法，它不能保证你一次过审，也不能代替你做产品判断。它真正解决的，是把那些藏在条款编号和模糊措辞里的信息差抹平，让你在提审前就完成一次内部预演。被拒本身不是终点，而是一个信号，关键是你能不能快速读懂它。我的选择是把读信这件事交给 Agent，把判断和行动留给自己。