作者拿到的成绩
这篇值得看在哪里
李可不会写代码，却把美容门店小程序「销冠营」重做成 App。项目从 6 月 20 日开工，9 月 21 日上架 App Store。首版排队 6 天多后，他又在 iOS 27 闪退与发布时间之间做了取舍。
从美容门店小程序走向 App
「销冠营」不是凭空构想的工具，而是李可已有业务场景的延伸：他经营过 3 家美容院，也帮 20 多家门店做线上代运营。产品给美容门店使用，员工可以学习专业知识、和 AI 扮演的顾客练话术，门店在事先告知顾客后，用智能工牌记录服务过程，再自动生成复盘卡片。作者手上原本已有一套 58 个页面的微信小程序，6 月 20 日开工时没有照搬全部页面，而是先逐页决定哪些迁移、合并、延后或放弃。这说明项目的基础并不只是“会用 AI 写代码”，还包括明确的行业场景、既有产品素材和能持续验证需求的人群。
先排手续再并行开发
作者实际采用的是个体工商户主体，网站备案、App 备案和电子版权证书都挂在这个主体名下，但苹果不把个体户视为组织，最终只能使用个人开发者账号，App Store 中国区卖家名显示为本人真名。这个选择降低了主体办理的复杂度，却带来品牌展示和平台匹配上的限制。开发与手续也没有按文章章节逐项串行完成，而是先启动需要排队的事项，再和开发并行推进。销冠营在 9 月 14 日提审前已经完成 App 备案，但软著因 AI 使用声明与实际情况不符而放弃，电子版权证书到 10 月初仍处于待补正。对准备公开发布的人来说，真正需要提前管理的是主体一致性、证书材料和备案等待时间，而不是只盯着代码何时写完。
上架过程暴露真实质量边界
销冠营 1.0.0 在 9 月 14 日提交审核后，排队超过 6 天，作者申请过一次加急。更关键的风险发生在审核通过前：外测用户在 iOS 27 手机上发现 App 一打开就闪退，而作者自己的 iOS 26 手机和模拟器都没有复现。作者选择先发布，再修复并申请加急，1.0.1 随后修好闪退并发布。这是一个明确带代价的发布决策，不能简单理解为“加急解决了一切”：受影响系统的用户在那一天确实无法打开。后续作者把最新和最低系统冷启动检查写进出包流程，安卓内部测试也出现过 Android 10 冷启动连续崩溃、但 7975 条测试全绿的情况。案例最有价值的地方，是把自动化测试、模拟器验证和真实设备验收的边界讲清楚。
成本与适用人群都很具体
作者披露的实付项目包括苹果开发者账号 688 元／年、电子版权证书 600 元、阿里云 8 月约 567 元、9 月截至 28 日约 707 元，以及 9 月头 8 天约 5000 万 Token 对应约 21 元的大模型调用账单。1351 亿 Token 是所有项目合计，且绝大部分是缓存读取，不能直接当作单个 App 的开发成本。这个项目更适合已经有具体行业问题、手上有小程序或网页、愿意亲自做手机验收并处理备案提审的人；不适合寻找“一句话生成 App”的人，也不适合需要特殊许可证的行业或计划在 App 内销售数字会员、数字内容却还没研究支付规则的人。
根据作者原帖及所附飞书文档整理。完整实操与材料见原文。
原文还会展开这些问题
- 个体工商户为什么能办多数手续，却不能在苹果开组织账号？
- 销冠营为何放弃软著并转办电子版权证书？
- iOS 27 闪退为何没被自动测试和监控提前发现？
- 为什么项目要把手续排队和 App 开发同时推进？
- 已有 58 个小程序页面时，第一版如何决定取舍？
原作者原话
其实不是这些账号，而是软著（或电子版权证书）和备案，见第 4、5 章
我选择先发布、第二天加急上修复版 1.0.1
以上为原帖简短摘引。作者：李可。完整内容及访问条件以生财有术原帖为准。
