我用AI开发App，整整花了一年
I Tried Building a Real App with AI. It Took a Year
我和妻子想找一个能追踪习惯、爱好和家务的App，试了Streaks、HabitKit和Grit等几十款，要么功能不符，要么订阅费太贵。于是去年三月，我决定用AI自己开发一个叫HabitTed的App。起初以为只要写几个提示词，AI就能在我睡梦中搞定一切，结果却花了整整一年。虽然六小时内就做出了一个能运行的版本，但代码质量极差，视图文件长达千行，iCloud同步也有严重漏洞。最终我不得不手动重构代码、优化数据模型并修复各种Bug。这段经历让我明白，AI目前还无法完全替代工程师，它更像是一个需要严密监督的助手，而非全自动的解决方案。
我们以为只要写几个提示词，AI就能在我们睡觉或海滩小酌时把App建好，但事实并非如此。
HN 评论区
84- over_bridge
我自己也用 AI 开发过一个业余笔记 App。体验也是喜忧参半，但这很大程度上源于我自身的改变。
在 AI 出现之前，开发成本高昂，所以我会在功能规划上花几个小时。我填满了 5 本笔记本，画满了 UI 草图、数据架构和命名清单。因为每周最多只有 5-10 小时，而且我想尽快推进，所以构建过程基本上是一次成型的。
现在，我直接往 Claude Code 的聊天框里打字，代码就在我眼前生成。几个月来我什么都没规划。结果就是，这个 App 随着我的奇思妙想和情绪波动而剧烈摇摆。我可以因为洗澡时想到的点子而重写整个应用。几天后我意识到不对，又把它重建一遍。所有的重写都对代码造成了冲击，我到处都能看到早已删除的东西留下的死代码模式。
如果是专业应用，会有其他人来监督我，所以情况不太一样，但 AI 确实让快速制造大量劣质应用变得非常容易。不过，如果你非常清楚自己想要什么，那感觉就像魔法一样。
我只希望它还在遵守我精心设计的加载和缓存算法，否则我根本察觉不到。
- spprashant
我认为我们正在从“你能构建这个产品吗？”转向“我是否信任你来维护这个产品？”。软件很便宜，信任才是溢价。
那些真正用心打磨产品的开发者和公司将会脱颖而出。这其中很大一部分在于“不做什么”——而 AI 代理总是会对任何要求说“是”。
公平地说，这向来如此，但随着 AI 的规模化，这一点只会变得更加明显。
- Grombobulous
我认为作者陷入了 AI 开发中某种糟糕的中间地带：既知道代码如何工作，又试图将其塞入一个并不适合的范式（Xcode）中。
那 6 个月的清理工作，真正的“氛围编程”（vibe coder）无代码开发者根本不会去做。我也认为这类人可能会倾向于让 AI 走最简单的开发路线，这可能意味着使用更原生的 Web 技术，而不是依赖 AI 难以良好协作的 IDE 的原生应用。
比如 Expo 之类的。
我发现，在“氛围编程”场景下，iOS 应用开发最耗时的部分是应用商店流程中的各种“繁文缛节”，包括提交审核。
- alexpotato
在我的职业生涯中，作为 SRE/DevOps，我花了很多时间处理因未捕获的 bug 和/或疯狂的基础设施故障组合而导致的多次服务中断。[0]
在我看来，软件工程的基础并没有改变，只是编写代码的速度变快了。
例如，下面的计划对于人类或 LLM 构建对微小变化/错误敏感且具有灾难性故障模式的系统（如交易、航空、医疗等）同样适用：
1. 制定非常详细的运作计划
2. 将工作分解为组件
3. 针对每个组件进行工作并对其进行广泛测试
4. 一旦该组件合格，再进入下一个组件
5. 将所有组件组合在一起，并通过集成测试等确认它们能正常工作
有一种强烈的诱惑是告诉 LLM“给我建个系统”，但这是个坏主意，对人类来说也是坏主意。
当然，LLM 可以加速第 2 步，甚至可能加速第 3 步。具体到第 3 步，我认识的大部分顶尖开发者都在用 LLM 写代码，但测试要么手写，要么花大部分时间审查 LLM 写的测试代码。我认为这才是应有的方式。
- bradfa
制作生产级软件依然很难。你仍然需要知道自己在做什么。制作好的软件仍然需要投入大量的时间和智慧。
如果使用得当，LLM 工具可以极大地加速开发，使规模更小的高绩效团队变得高效得多。但这并非魔法，如果你用错了方法，它真的会成为阻碍而非助力。