GlotShot 的早期审核经历很像独立开发者第一次做 Mac App Store 产品时的集中补课。2026-01-20，0.0.2 被四项问题打回：Apple 商标/术语、Google Play 元数据、启动白屏、Support URL 不合格。

第一轮修完后，0.0.4 又在 2026-01-23 被 Guideline 2.1 打回：App does not export the screenshots，File path is broken in the export message。中文翻译就是：App 无法导出截图，导出消息里的文件路径损坏。

最终 0.0.7 修复后通过。这个案例的价值不是证明 GlotShot 多坎坷，而是把 MAS 上架最容易漏的几类问题放在同一页：元数据、支持页、启动、沙盒导出、localhost 权限。

开发细节补充：这篇记录放在 GlotShot 的产品日记里，不是为了把一个功能包装成故事，而是把“07 · 审核复盘：从元数据到导出路径的两轮拒审”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 macOS / App Store / 本地化，当前公开状态是 失败复盘 / App Store / 转型观察，所以文案不能脱离真实发布进度。

对应的 docs 线索主要来自 商店素材工具 docs、UX 优化计划、隐私与 IAP 文档、App Store 检查清单。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。GlotShot 对应的素材工具文档覆盖 UX、隐私、付费墙、MAS 构建和 App Store 检查，说明它服务的是完整上架流程。 Poster、Icon、设备框、多语言标题和批量导出是真实需求，但普通静态海报越来越容易被 Codex 自动生成。 开发记录的价值在于把截图规格、文案本地化、隐私页面和审核材料放在同一个发布闭环里。 2026-01-20 / 2026-01-23 GlotShot 经历两轮拒审，覆盖 Apple 商标元数据、Google Play 引用、Support URL、启动白屏、导出失败和沙盒路径问题，最终 0.0.7 修复通过。 后续方向必须越过模板层，走向 3D 设备场景、产品视频、动态演示和转化率素材组合。

从产品功能看，GlotShot 关联的能力包括：Poster / Icon 双模式、多设备框和批量导出、多语言营销文案本地化、适配应用商店素材规格。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。

从工程推进看，这篇日记对应的检查点是：App Store 上架素材生产线；工具服务另一个 App 发布的案例。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。

从隐私和合规看，当前约束是：素材生成和本地翻译流程优先在用户设备上完成。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。

从课程和复用看，这篇内容可以沉淀到 App Store 素材、本地化、批量图片生成、独立开发发布流程。它的价值不只是给访问者看一个产品，而是展示一个独立开发者怎样把想法转成可验证的产品：先收窄场景，再选技术路径，再做体验最小闭环，最后把审核、推广、运营数据和失败教训都纳入下一次迭代。

商店素材产品要服务一次完整发布，而不是只做一个图片编辑器。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是在 AI 已经能批量生成基础海报后，继续提供更专业、更难替代的视觉结果。

所以这篇日记的结论不是“功能已经写完”，而是把一个阶段的判断公开化：哪些证据足够支撑继续推进，哪些资料还需要回到源码、商店材料、公开文案或运营观察里补齐。这样的记录会比单纯的发布公告更慢，但也更真实，能让产品页、发布记录和课程内容保持同一条事实线。

验收时我会把它拆成四个层次：第一层是用户路径能不能走通，第二层是异常状态有没有被诚实处理，第三层是页面上的按钮、状态、截图和文案是否对应真实发布渠道，第四层是公开证据能否支撑这个判断。只要其中一层对不上，产品看起来再完整，也不能算真正进入下一个阶段。

交接时也要保留边界：源码、构建、测试、商店元数据、公开文案、平台反馈和运营观察分别保存原始资料。产品日记只把这些事实翻译成读者能理解的过程，不替任何私有记录保存原始材料。

把这些内容公开出来，还有一个很现实的原因：AI 教程如果只展示成功结果，很容易让人误以为产品是一次生成出来的。真实情况恰好相反，真正可学习的是一次次收窄、验证、失败、补证据和重新提交。日记越具体，后续读者越能看到判断的脉络，而不是只看到一个漂亮的截图。

第一轮原文要点

Guideline 5.2.5：metadata 里不当使用 App Store 相关术语，可能造成 Apple 产品或服务混淆。Guideline 2.3.10：描述包含 Google Play 等第三方平台引用，对 App Store 用户不相关。

Guideline 2.1：App 启动后显示空白页。Guideline 1.5：Support URL 指向 GitHub Issues，不是用户可用的支持信息网页。完整原文留在内部归档。

第二轮原文要点与翻译

Apple 原文要点：App does not export the screenshots；File path is broken in the export message。中文翻译：App 不能导出截图，导出提示里的文件路径是坏的。

这个问题比元数据更接近真实功能。素材工具的核心就是导出，如果审核员在沙盒环境下导不出来，产品再会做海报也不算完整。

我们怎么解决

第一轮修复包括：副标题移除不合适的 App Store / Apple 术语，描述和 Promotional Text 删除 Google Play / Android 等第三方平台引用，Support URL 改为专门支持页，修复初始化白屏。

第二轮修复进入 0.0.7：对用户生成的 scene name 做文件名清理，避免斜杠等特殊字符生成非法路径；验证 user-selected read-write entitlement；补 network client entitlement，允许 App 在沙盒中访问本地 Ollama / localhost。

复用教训

App Store 元数据不是 README，不能把跨平台表达原样搬过去。Mac App Store 用户看的是这个 App 在 Apple 平台上的体验，所以第三方平台语境要克制。

沙盒导出一定要做脏数据测试：非法字符、中文/日文文件名、空文件名、超长路径、用户选择目录、取消导出、权限不足。素材工具最怕的不是功能少，而是关键出口在审核设备上断掉。