AI 6小时写出原型，这款iOS习惯应用却磨了近一年才上架

英国开发者Alex Hyett去年3月用Cursor写了一个iOS习惯追踪应用的原型，只花了一个周末、大约6个小时。但从那个周末到应用真正在App Store上线，他又用了近一年时间返工代码、修数据同步、改数据模型。

这不是"AI替你写完App"的故事，更像一份账本：AI确实能把"写出能跑的东西"这件事的门槛压到几乎为零，但"能跑"和"能上架"之间，隔着开发者自己是否看得懂AI写的代码。

HabitTed：原型到上架，中间经历了什么

Hyett和妻子想找一款习惯追踪App，试了几十个都不满意，干脆自己做。他用Cursor写代码，一个周末、大约6个小时，做出了HabitTed的原型：能创建习惯、打卡、支持多种目标类型，还带iCloud同步。

原型能跑，代码却经不起看。部分视图代码接近1000行，Xcode编译器一直提示要拆分；同样样式的按钮，不同页面写法完全不一样。Hyett没再让AI去改，自己手动把每个视图拆到100行以内，统一了风格。

测试之后，问题更麻烦：

• iCloud同步其实没生效——卸载重装，数据全部消失，找不回来
• 习惯记录一多，详情页统计就变慢，因为每次打开都要重新遍历全部数据
• 数据模型设计得又乱又复杂，改字段结构会让老数据直接崩掉，他不得不重新做一套迁移方案

修完这些，应用又赶上iOS 26发布。系统的透明度效果开关捅出新bug：深色模式下，习惯详情页标题栏变成白底白字，什么都看不清。AI这次帮不上忙——模型的知识范围赶不上刚发布的系统版本，一度反过来说他记错了iOS版本号。他靠读其他开发者的博客临时解决，Apple自己在26.1里修掉了这个bug。

这是个案。Hyett做过多种语言开发，这次是他第一次写Swift。别的项目未必是"6小时原型、近一年工程"这个比例。

AI写出功能，不等于交付产品

Hyett把这段经历总结成一句话：AI能带你走到80%，但最后20%可能要花掉80%甚至更多时间——如果你不理解它写的代码，这个比例还会更糟。这是他自己的总结，不是通用工程比例，目前也没有更多案例或数据能验证这个"80/20"是否普遍成立。

上架一款App，从来不只是把代码跑通。持续测试、适配新系统、做官网、准备商店截图，这些工作量常被低估。HabitTed从能跑的原型到真正上架，中间是重构、迁移、性能优化和系统兼容修复，不是"再润色一下"就能过去的。

对独立开发者，这是一笔明确的账：自己做一款App，未必比买现成应用便宜，只是把订阅费换成了时间和维护成本。对技术负责人，教训更直接——AI把原型做出来的速度，不能当成工程交付的产能，中间还隔着测试、架构和长期维护。

定价逼出的自研：谁在为这波AI编程买单

Hyett夫妇试过市面上的习惯追踪App。Streaks完全免费，但用分页布局，不支持纯计数（比如追踪头痛次数，而不是设定每天要发生几次）；HabitKit有GitHub风格的贡献图；Grit功能最接近需求。订阅定价让他犹豫，干脆自己做。

这张表能看出这波AI编程热潮里，真正改变处境的是谁。不是"要不要用AI写代码"的技术圈争论，而是普通用户要不要为一款习惯追踪App付十几到三十英镑年费，以及独立开发者要不要花近一年时间，把订阅费换成自己的时间成本。

Hyett在文章里还提到他对行业的担忧：初级岗位减少、资深开发者过度依赖AI导致能力退化、AI热潮降温后可能没有足够多能"接盘"的开发者。这些是他个人的观察，目前没有证据支撑这是行业定论，值得记一笔，不必当真已经发生。

接下来最值得盯的变量，是这个"6小时原型、近一年工程"的比例会不会在别的开发者身上重复出现。如果更多没有资深iOS背景的人，用AI从0到1把应用做到上架，也卡在同样的同步、性能和系统适配问题上，这就不是Hyett一个人的经历，而是AI辅助开发目前的真实上限。