免费 iOS boring time

免费 iOS boring time 免费 iOS boring time Modified July 21, 2025 打包上传，让 AI 写了一封解释文件，第四次提交。提交时离打车去机场的时间只有一个半小时，行李都还没收拾完。忐忑的到机场，上飞机，到目的地，下飞机，重新连接网络，查看邮件，发现苹果通知版本审核通过了。这个产品目前没有任何收费功能，也没有广告植入，也没有啥用户流量。越是简单的小游戏，细节越是魔鬼，零代码编程，对我来说就已经意义重大了。和很多竞品相比，唯一的体验优势就是没有广告，除此之外，体验优势几乎没有，需要进一步打磨。如果想赚钱，需要看到可观的长期留存和足够多并且足够稳定的日活用户。 AI 适合快速原型产品，体验打磨这事用 AI 挺难的，它特别容易过度发挥，即便我设置了 cursor rules 也经常拦不住它的骚操作，导致测试工作变得极为艰巨，你不知道它改动一次会带来多少额外的关联错误。以至于我现在习惯加一句，最小化改动。为了便于开发和维护，以及本能拒绝某些合规成本，服务端全部采用 firebase，所以，国内用户如果不使用海外漫游网络，那么登录，服务端存储和分享回放功能就无法使用，另一方面说，也等于拒绝了国内的用户流量。（当然，作为单机游戏，国内用户还是可玩的）开发规划：第一步，3 月到 4 月，主要是验证 AI 编程，实现谷歌和苹果双平台发布。25 年前做网站就没有障碍，是中国最早掌握做交互网站的人群之一，但移动互联网这么多年，没有亲自下场做过任何一个 App，感谢 AI，终于让自己实现了移动互联网产品开发。下个版本（8 月份才会开始），将考虑开发玩家排行版，成就系统，以及自动在线更新游戏库（数独，堆叠三消）。当然，收入预期，依然为 0。下述分享一些执行中的习惯，交互认知思考： 1、不介意让自己当傻瓜这一点很重要，其实我说过我虽然有程序员经验，但不太擅长前端交互部分的设计，而且没有过移动开发的经验。更是和当下技术脱节了超过十年。所以我会经常问 AI 非常菜鸟，非常白痴的问题，而且会反复问。我有一个好习惯，就是我希望理解更多系统层面的逻辑，但是平时，如果问身边的人，第一，很多人都会有形象包袱，不想让别人觉得自己什么都不知道。第二，就算敢于提问，如果没听懂别人的解释，也不太好意思反复问。但是面对 AI 就没这个心里障碍，不怕暴露自己的无知，大胆问，随便问，而且还可以很嚣张的连续问很白痴的问题，并让 AI 用最初级的方式讲解。 2、约束 AI 的过度发挥一般，遇到所谓执行逻辑的错误是比较难以处理的，也就是代码不报错，执行结果和预期不一致，这种调试过程就比较复杂。而这时候，AI 很容易过度改动，甚至为了解决所谓的表象问题，大范围修改结构和基础代码，导致整个项目崩溃。之前提过 2.1 不断的 git commit ，任何一个正向进步，赶紧 commit。那么 2.2 让 AI 不要修改，先告知问题和解决方案，很多次你会发现它误解了你的问题，或者把问题扩大化，或者改动方案是无法容忍的。 2.3 继续让 AI 先不要试图解决问题，而是增加调试输出项，执行后把调试信息喂给它，重复 2.2 调试是很需要你的经验，对业务逻辑的理解，AI 现在可以给出很不错的调试日志，部分业务甚至可以做到自我测试迭代，但目前对于游戏而言，人的测试，我认为目前是不太容易取代的。毕竟游戏是给人玩的，只有人才能体会和判断到所谓游戏交互的是否顺畅，是否合理，以及难度是否恰到好处。 2.4 当确认 AI 应该是真的找到了问题时，强调，最小化改动。我发现这条太重要了。过度修改，过度冗余，甚至是引入过度的掩饰策略而不是解决问题，都是 AI 常见的行为。 AI 有些策略根本不是解决问题，而是掩饰问题，或者让你牺牲某些产品特性回避问题，特别操蛋。我现在习惯说一句，最小化改动，只改动部分，不要改动其他。 3、不断执行整理和清理的操作你自己要心里有数，我旧文也提过，哪些功能，调用是可以复用的，刚开始开发可能是一个一个独立开发的，开始归纳，合并，统一逻辑，让 AI 合并相似逻辑，整理归一化的基础结构。另外，针对 cursor，当你拥有了一些全局通用的结构，参数，定义，并且需要频繁强调的，可以放在项目 rules 里，设置为 always，否则它后续会忘掉这件事，继续制造垃圾。归一化之后，让它反思代码，冗余的，废弃的代码尽量删除，否则以后遇到其它问题，它检查代码的时候会经常陷入这些废弃代码，浪费时间还会误入歧途。我旧文提过，我做了逻辑归一后让它尽量做了清理，但后来发现并不彻底，依然有不少垃圾存余，不奢求完美清理吧，但尽量要做这件事。有一个概念很重要，AI 修改过多次的代码，会有大量废弃的冗余的部分，一定要不断让 AI 清理，逻辑拆分，后则后续的修改和调整将异常艰难，有人说代码冗余太多可以重做，不过有些复杂的业务逻辑跑通挺辛苦的，重做也不容易。清理也要小心，它有时候也会粗枝大叶，直接把正在使用的一些调用逻辑直接清理了，不要让它直接清理，先给出清理方案，让 AI 再三检查相关代码。我发现好几次都是差点清理掉正在使用中的代码。这个 vscode + copilot 有劣势，因为只局限在限定文件，可能对一些调用加载关系检验不充分。 4、安全校验幸亏我追查了 firebase 远程前端数据调用的逻辑（用很白痴的方式反复问 AI 来理解），对可以分享的非敏感数据做了匿名化授权，结果 AI 对我做的准备视而不见，直接把登录远程数据库的 key 写到了前端，还好我让他做安全检验，自己发现了这个问题，不幸的是没多久它又犯了同样的错误。所以每次发布前我都会让进行代码安全校验和参数传递的安全审核。但安全加固其实也是适度就好，它会过度进行安全策略，而且代码本身也会存在一些命名或者定义冲突，以至于正常使用的功能被阻挡，就很无语，我只能再次界定，哪些安全策略（轻度且覆盖完整的）是可行的，哪些是过度的。毕竟我这个休闲游戏而已，不需要太复杂的安全防御策略。有人说你应该让 AI 做全自动测试和迭代，特别是 claude 4 opus 有很强的自我测试迭代能力，我觉得也要看你的诉求场景，比如休闲游戏，这个必须玩家亲自体验，很多游戏中的体验感，难度设计才有真正的体会到，当然也必须承认测试成本挺高的，一些高难度的游戏关卡需要较多时间和运气才能执行完。 5、关于测试那么仅从功能测试而言，一种合理的策略是降低难度参数来测试基本能力，比如测试游戏回放能力，把 2048 的入门难度定义到了 128，这个就是为了测试方便。此外，测试挖阿挖的高难度通关回放，会把卡牌类型临时定义为 3 种（随便点都能过），等功能测试完毕后改为 12 种（非常非常难）。难度设计的测试必须自己是专业玩家，比如数独就很典型，坦白说到现在数独难度依然不合理，极限难度过于简单了，暂时也没有时间继续调整。 AI 过度修改是个很烦的话题，所以你哪怕只改很小的一个局部，但有时它会把很多功能和特性改的面目全非，所以可能很小一个修改就需要做全局的测试，这也是让我后来时间严重不足，测试严重不充分的原因，当然前面也提到了，要严格约束其修改范围。还要重复一下，以上一切的背景是所谓 vibe coding，零代码编程，从头到尾没有自己做代码的设计，做代码的手工调整，结构也是 AI 设计的，但是我会通过对话做调整和优化，有人说你应该把代码结构做好再给 AI，小问题应该手工修改，很多问题就不会出现，对不起，这不是我的初衷。重复一遍，零基础开始做项目是值得鼓励的，但不要认为零基础是理所当然的，这只是起点，在前进的过程中，通过和 AI 的不断对话和交流，让自己变成有基础，懂技术。这里我的习惯是一个对话 AI（chatgpt），一个编程 AI（cursor）。各种白痴问题我一般都是问 chatgpt，但我注意到需要不断和 cursor 核对相关内容，有几次几乎被 chatgpt 带到沟里去。我要做个 Web 分享能力，chatgpt 一直要求我做完整的 flutter build web，其实根本不需要，后来 cursor 建议我做一些简单的前端代码即可，可以直接 flutter deploy only hosting 发布上去。再拿这个说法问 chatgpt，它又说是的，当然可以，这样更简单。学习的时候也要不断核对。 6、要氪金程序员也要氪金，氪金才能变得更强。提醒一下各位老板，不要吝啬这个，一个程序员一个月在 AI 上花 100 200 美金我认为是很合理的，不要在这里抠门（20 刀/月的 pro 版本只是入门费用）。我认识的老板们会花的更多，很多都是自己玩的开心，不过如果对业务确实有帮助，给普通程序员花更多钱在 AI 上也是值得的。不要总想着薅羊毛，如果你看中 AI 产出价值，这些羊毛的成本节省几乎不值一提。大体这些。打包上传，让 AI 写了一封解释文件，第四次提交。提交时离打车去机场的时间只有一个半小时，行李都还没收拾完。忐忑的到机场，上飞机，到目的地，下飞机，重新连接网络，查看邮件，发现苹果通知版本审核通过了。这个产品目前没有任何收费功能，也没有广告植入，也没有啥用户流量。越是简单的小游戏，细节越是魔鬼，零代码编程，对我来说就已经意义重大了。和很多竞品相比，唯一的体验优势就是没有广告，除此之外，体验优势几乎没有，需要进一步打磨。如果想赚钱，需要看到可观的长期留存和足够多并且足够稳定的日活用户。 AI 适合快速原型产品，体验打磨这事用 AI 挺难的，它特别容易过度发挥，即便我设置了 cursor rules 也经常拦不住它的骚操作，导致测试工作变得极为艰巨，你不知道它改动一次会带来多少额外的关联错误。以至于我现在习惯加一句，最小化改动。为了便于开发和维护，以及本能拒绝某些合规成本，服务端全部采用 firebase，所以，国内用户如果不使用海外漫游网络，那么登录，服务端存储和分享回放功能就无法使用，另一方面说，也等于拒绝了国内的用户流量。（当然，作为单机游戏，国内用户还是可玩的）开发规划：第一步，3 月到 4 月，主要是验证 AI 编程，实现谷歌和苹果双平台发布。25 年前做网站就没有障碍，是中国最早掌握做交互网站的人群之一，但移动互联网这么多年，没有亲自下场做过任何一个 App，感谢 AI，终于让自己实现了移动互联网产品开发。下个版本（8 月份才会开始），将考虑开发玩家排行版，成就系统，以及自动在线更新游戏库（数独，堆叠三消）。当然，收入预期，依然为 0。下述分享一些执行中的习惯，交互认知思考： 1、不介意让自己当傻瓜这一点很重要，其实我说过我虽然有程序员经验，但不太擅长前端交互部分的设计，而且没有过移动开发的经验。更是和当下技术脱节了超过十年。所以我会经常问 AI 非常菜鸟，非常白痴的问题，而且会反复问。我有一个好习惯，就是我希望理解更多系统层面的逻辑，但是平时，如果问身边的人，第一，很多人都会有形象包袱，不想让别人觉得自己什么都不知道。第二，就算敢于提问，如果没听懂别人的解释，也不太好意思反复问。但是面对 AI 就没这个心里障碍，不怕暴露自己的无知，大胆问，随便问，而且还可以很嚣张的连续问很白痴的问题，并让 AI 用最初级的方式讲解。 2、约束 AI 的过度发挥一般，遇到所谓执行逻辑的错误是比较难以处理的，也就是代码不报错，执行结果和预期不一致，这种调试过程就比较复杂。而这时候，AI 很容易过度改动，甚至为了解决所谓的表象问题，大范围修改结构和基础代码，导致整个项目崩溃。之前提过 2.1 不断的 git commit ，任何一个正向进步，赶紧 commit。那么 2.2 让 AI 不要修改，先告知问题和解决方案，很多次你会发现它误解了你的问题，或者把问题扩大化，或者改动方案是无法容忍的。 2.3 继续让 AI 先不要试图解决问题，而是增加调试输出项，执行后把调试信息喂给它，重复 2.2 调试是很需要你的经验，对业务逻辑的理解，AI 现在可以给出很不错的调试日志，部分业务甚至可以做到自我测试迭代，但目前对于游戏而言，人的测试，我认为目前是不太容易取代的。毕竟游戏是给人玩的，只有人才能体会和判断到所谓游戏交互的是否顺畅，是否合理，以及难度是否恰到好处。 2.4 当确认 AI 应该是真的找到了问题时，强调，最小化改动。我发现这条太重要了。过度修改，过度冗余，甚至是引入过度的掩饰策略而不是解决问题，都是 AI 常见的行为。 AI 有些策略根本不是解决问题，而是掩饰问题，或者让你牺牲某些产品特性回避问题，特别操蛋。我现在习惯说一句，最小化改动，只改动部分，不要改动其他。 3、不断执行整理和清理的操作你自己要心里有数，我旧文也提过，哪些功能，调用是可以复用的，刚开始开发可能是一个一个独立开发的，开始归纳，合并，统一逻辑，让 AI 合并相似逻辑，整理归一化的基础结构。另外，针对 cursor，当你拥有了一些全局通用的结构，参数，定义，并且需要频繁强调的，可以放在项目 rules 里，设置为 always，否则它后续会忘掉这件事，继续制造垃圾。归一化之后，让它反思代码，冗余的，废弃的代码尽量删除，否则以后遇到其它问题，它检查代码的时候会经常陷入这些废弃代码，浪费时间还会误入歧途。我旧文提过，我做了逻辑归一后让它尽量做了清理，但后来发现并不彻底，依然有不少垃圾存余，不奢求完美清理吧，但尽量要做这件事。有一个概念很重要，AI 修改过多次的代码，会有大量废弃的冗余的部分，一定要不断让 AI 清理，逻辑拆分，后则后续的修改和调整将异常艰难，有人说代码冗余太多可以重做，不过有些复杂的业务逻辑跑通挺辛苦的，重做也不容易。清理也要小心，它有时候也会粗枝大叶，直接把正在使用的一些调用逻辑直接清理了，不要让它直接清理，先给出清理方案，让 AI 再三检查相关代码。我发现好几次都是差点清理掉正在使用中的代码。这个 vscode + copilot 有劣势，因为只局限在限定文件，可能对一些调用加载关系检验不充分。 4、安全校验幸亏我追查了 firebase 远程前端数据调用的逻辑（用很白痴的方式反复问 AI 来理解），对可以分享的非敏感数据做了匿名化授权，结果 AI 对我做的准备视而不见，直接把登录远程数据库的 key 写到了前端，还好我让他做安全检验，自己发现了这个问题，不幸的是没多久它又犯了同样的错误。所以每次发布前我都会让进行代码安全校验和参数传递的安全审核。但安全加固其实也是适度就好，它会过度进行安全策略，而且代码本身也会存在一些命名或者定义冲突，以至于正常使用的功能被阻挡，就很无语，我只能再次界定，哪些安全策略（轻度且覆盖完整的）是可行的，哪些是过度的。毕竟我这个休闲游戏而已，不需要太复杂的安全防御策略。有人说你应该让 AI 做全自动测试和迭代，特别是 claude 4 opus 有很强的自我测试迭代能力，我觉得也要看你的诉求场景，比如休闲游戏，这个必须玩家亲自体验，很多游戏中的体验感，难度设计才有真正的体会到，当然也必须承认测试成本挺高的，一些高难度的游戏关卡需要较多时间和运气才能执行完。 5、关于测试那么仅从功能测试而言，一种合理的策略是降低难度参数来测试基本能力，比如测试游戏回放能力，把 2048 的入门难度定义到了 128，这个就是为了测试方便。此外，测试挖阿挖的高难度通关回放，会把卡牌类型临时定义为 3 种（随便点都能过），等功能测试完毕后改为 12 种（非常非常难）。难度设计的测试必须自己是专业玩家，比如数独就很典型，坦白说到现在数独难度依然不合理，极限难度过于简单了，暂时也没有时间继续调整。 AI 过度修改是个很烦的话题，所以你哪怕只改很小的一个局部，但有时它会把很多功能和特性改的面目全非，所以可能很小一个修改就需要做全局的测试，这也是让我后来时间严重不足，测试严重不充分的原因，当然前面也提到了，要严格约束其修改范围。还要重复一下，以上一切的背景是所谓 vibe coding，零代码编程，从头到尾没有自己做代码的设计，做代码的手工调整，结构也是 AI 设计的，但是我会通过对话做调整和优化，有人说你应该把代码结构做好再给 AI，小问题应该手工修改，很多问题就不会出现，对不起，这不是我的初衷。重复一遍，零基础开始做项目是值得鼓励的，但不要认为零基础是理所当然的，这只是起点，在前进的过程中，通过和 AI 的不断对话和交流，让自己变成有基础，懂技术。这里我的习惯是一个对话 AI（chatgpt），一个编程 AI（cursor）。各种白痴问题我一般都是问 chatgpt，但我注意到需要不断和 cursor 核对相关内容，有几次几乎被 chatgpt 带到沟里去。我要做个 Web 分享能力，chatgpt 一直要求我做完整的 flutter build web，其实根本不需要，后来 cursor 建议我做一些简单的前端代码即可，可以直接 flutter deploy only hosting 发布上去。再拿这个说法问 chatgpt，它又说是的，当然可以，这样更简单。学习的时候也要不断核对。 6、要氪金程序员也要氪金，氪金才能变得更强。提醒一下各位老板，不要吝啬这个，一个程序员一个月在 AI 上花 100 200 美金我认为是很合理的，不要在这里抠门（20 刀/月的 pro 版本只是入门费用）。我认识的老板们会花的更多，很多都是自己玩的开心，不过如果对业务确实有帮助，给普通程序员花更多钱在 AI 上也是值得的。不要总想着薅羊毛，如果你看中 AI 产出价值，这些羊毛的成本节省几乎不值一提。大体这些。大家好，我是小林，这篇教程作者是曹大，AI 编程开源知识库作者。产品官网 boringtime.web.app app store 和 google play 均可下载，产品英文名 boringtime ，中文名无聊时光。友情提醒，如果使用境内网络，第三方登录和远程存储记录和在线分享将不可用。坦白讲，测试非常不充分，仍有不少问题有待逐步发现。下面是我整理曹大开发这个产品的心路历程，有一定删减，推荐看下曹大的踩坑心得，原文推荐关注公众号： caoz 的梦呓。 AI 编程，让我这种已经落伍退役的中老年程序员们焕发了第二春。先回顾一下 3 月初，开始尝试 AI 零代码编程三小时零基础 AI 编程做产品，到底行不行？ 4 月初，零代码编程产品发布上线，期间谷歌市场公测通过。 5 月初，谷歌市场正式版发布，苹果市场更新，继续优化调整。最近 Claude 4 发布，我第一时间开始使用，并利用它对之前代码进行了一次清理。有读者质疑我的能力，认为不是 cursor 的问题，是我的问题，我坦白，他说的是对的。确实我很多年没有碰编程，最近只尝试了两个月，就跑出来分享，水平不足是必然的。我的读者，有人编程水平比我高，用 AI 工具的效率比我高，很合理，也很荣幸。其实发现自己的认知盲区也是好事情，当天我就去研究了 cursor rules 是什么，该如何设置，目前已经设置了一些规则，但是怎么说呢，和我预期还是有些不一致，有些规则执行的还是挺有效果的，有些规则似乎没有按照我的预期执行，可能还是我水平不足。此外，也了解了 mcp 的设置方法，但是目前还没有设置，后续会基于开发需求酌情考虑。整个开发过程本身也是我的体验目标，这也是为什么我从 copilot 换到 augment 又换到 cursor。对于一个自媒体作者来说，多了解几种可能更有利于和读者沟通分享。我从做这件事开始，就没有把自己当作一个程序员，从一开始，就没有基于程序员的思路做完整的架构设计，代码结构，数据结构设计，这不也是想更好理解 AI 编程的能力边界在哪里，当然也是因为自己的慵懒。我的开发模式其实特别业余，甚至都没有想明白这个游戏最终应该是什么样子的，先让 AI 做做看，做出来看看行不行，如果特别不行，可玩度很差，直接放弃掉，是的，我放弃了几个小游戏。如果发现做出来还是可玩的，但是交互体验不好，再想想怎么修改和优化，一点点打磨，所以，这个过程中，确实垃圾代码，冗余逻辑和各种前后不一致的情况就会很多。最近通过 firebase 做了云端的玩家登录和游戏记录，回放记录存储能力，在这个过程中，就发现各种不一致，各种测试的复杂度特别高，那么趁着 Claude 4 发布的东风，也是下定决心，彻底清理一次。我先讲一下遇到的问题，因为之前是一个游戏一个游戏开发的，每个游戏的玩家数据状态，存储，回放，游戏难度选择列表，回放列表，全都是独立生成的，数据结构也都是各自的，在做云端处理的时候，需要一个个去进行处理，而且不断的版本迭代中，命名规则也在各个版本里被改的面目全非，比如中等难度，有的地方赋值时 normal，有的地方判断时 mediate，就特别多诡异问题。代码不复用，数据结构不复用，命名规则不一致，各种参数硬编码在代码里，就都是我们常见的代码屎山表现。通过 claude 4，我开始逐步进行清理，要求玩家游戏状态（胜利次数，连胜次数，最佳时间等）归一化，数据结构归一，存储逻辑归一；游戏难度选择页统一，基于参数通过配置文件获取不同游戏的特征字符串。回放记录的生成的获取统一，同样基于配置文件获取相应的命名规则，保证存取一致性，云端同步逻辑归一，不再区分游戏进行数据同步，游戏只是一个字段而已。游戏回放记录列表页归一，和难度选择页同理。清理工作中间有些反复（主要是测试有些繁琐，而且很难一次成功），不过差不多两三天时间还是基本搞定了。可复用代码归一，游戏配置归一之后，清理之前冗余代码，重复的逻辑。再往后又校验了一下回放存储的逻辑，因为之前都是系统生成的，发现数独存储内容过于庞大，不够精简，重新自己设计了存储结构，让它重新按照我设计的结构进行记录存储和回放实现，存储资源减少了 94%。对于一些有优化空间，但暂时还不算什么风险的地方，也是睁一眼闭一眼，懒得改来改去。此外还做了一个狠心的决定，就是不做向后兼容，因为中间很多地方涉及命名规则一致性的问题，其实新版本如果还要兼容旧版本的统计数据和回放记录就会又要保留超级多垃圾，想想玩家日活双平台一起都不一定有两位数，算了，不在这个环节上较劲了，保持代码的干净。新的结构，所有数据会有服务端保存，而且结构也都做了相应的标准化处理，以后再有版本升级，或玩家的设备变更，就可以轻松做到数据的持续化。清理屎山后，还在 github 官方创建了相应的项目，并进行了远程代码同步，这样防止我工作电脑受损后项目无法恢复。不过，这个项目目前设置了私有化状态，就不跟大家分享了。我用自己的切身行动来讲，不需要等一切都做的很好再去分享，不需要怕人说自己不专业，水平不足；其实更多的人是菜鸟对不对，更多的是刚入行的新手对不对，还有更多的人还没有行动，还在纠结和犹豫对不对，如果我的分享能帮助到这些人，让他们对相关领域有了进一步的认识，或者能鼓励他们进一步的尝试行动，就很棒了对不对。专业的人士质疑你没什么关系，正好可以基于此查漏补缺提升自己，所谓分享即学习，就算开始设计的不好，弄成一坨屎山，也是可以优化，可以调整的，没什么大不了，但该怎么调整，确实需要自己心里有数，所谓低耦合，高复用，依然是降低后期维护成本重要的原则，就算是 AI 编程时代，一样有效。就比如我今天说我自己的例子，如果做不到归一化处理，我需要对每个游戏，每个难度的数据存取和胜利条件触发的数据变化做校验，做设计；但是如果归一化了，那不就简单多了，后续如果有新的游戏开发计划，只要还在这个结构内，很多功能就自然而然的加个配置参数就行了。 6.1 正式封版，进入发布流程，在最后两天还在较劲给产品提供网页分享能力，6.1 日，在测试极为不充分的情况下，双平台发布，当天，谷歌秒过，第二天，苹果驳回。仔细看了一下果然是严重的功能 bug，根本原因是，我没有苹果测试机，mac os 和 ios 测试配置环境完全不一样，mac 通过不等于 ios 可以访问；此外，谷歌官方感觉就没测试，firebase 正式环境和测试环境的一些参数完全不同，其实也有严重 bug，是测试环境没发现的。修补后，谷歌，iOS 二次提交，谷歌再次当天秒过，iOS 第二天继续驳回。驳回的时候早上 7 点多刷手机看到了，本来要继续睡的（只睡了 3 小时），跳起来继续改，说是隐私策略要求必须提供账户删除策略，以及不允许有 upcoming 占位标识（第一次又没说）。改到中午 11 点半，之前约了朋友午餐局，先去赴约，下午回家继续改，提交，此时已经战战兢兢，因为当时第二天中午就要出发了，心想这应该是出发前最后一次提交，再不给通过这俩月就煎熬第二天早上七点多，再次焦虑刷手机，再次看到苹果驳回，还是隐私政策，说我收集用户跟踪数据没有使用透明框架，什么见鬼的跟踪，我要跟踪啥，我自己都不知道，继续跳起来干活，让 cursor 检查了一下，就是配置文件引入了跟踪系统，代码里一行调用都没有，确认安全后直接配置文件删除相关引用，重新打包，二次测试的时候犯了些错误（测试环境和正式环境的差异，是苹果安全策略的限制，测试时候误以为有严重 bug，其实没有），浪费了一个多小时。