夜雨聆风自己做应用，哪里不顺眼就改哪里，可以满足最细微的需求。
需求
昨天我先把最小原型搭起来了，至少在本机上已经跑通。但一进入下一步，问题就很明显了：页面不太漂亮，同步也不行。现在用的是基于 iCloud Drive 的同步，效率非常低。如果想让朋友一起用，这套方案根本撑不住。
真正麻烦的不是「加一个同步按钮」，而是多人同时改同一份仓库文件时，后端管理会一下子变复杂。冲突怎么处理，状态怎么保持一致，同步怎么做得足够顺，这些都绕不过去。
以我现在能接受的成本看，最便宜也最快的后端方式就是 Apple 的 CloudKit。它本质上是一套集成数据库，只要订阅了 Apple 开发者账户就能直接使用，而且把一部分冲突检测之类的问题也一起封装掉了。
所以这次迭代的目标其实很清楚，就是把页面美化好，再安排一个合适的同步功能。
方案
AI 听到这个需求后的第一反应，是先不管三七二十一做出一个非常粗糙的版本。这个阶段看起来很快，实际上需要不断返工。
因为这种功能必须拿两台 iOS 设备测试，操作本来就麻烦；一旦出了问题，还得我回到 AI 那里一点点描述，再让它改，效率非常低。
这时我想到 Harness Engineering 的一个核心观点：你得让 AI 知道什么结果算对，让它自己跑测试。
我给 Codex 开发的插件，正好可以让它读取最新文档，再调用合适的命令行工具自动跑测试。所以在提出更多需求之前，我先让 AI 把测试文件写扎实。这样以后它每次改动代码，都可以自己先跑一遍，验证有没有把整个项目的逻辑改坏。这是第一个真正有用的收获。
第二个收获是 UI 设计。我发现目前的本地代码，那些代写出来的界面，实际上并没有什么审美可言。直接在现有代码里一点点修，效率也不高。
更好的方法反而是先把原型在别处做出来。比如快速用 Google Sketch 之类的软件生成应用原型，或者用 AI Studio 生成网页原型，让它先跑起来，先长出一个像样的样子。然后再把截图直接丢给 Codex，让 Codex 对其进行实现。
最终做下来，整个应用的效果确实漂亮了很多。虽然这只是一个功能简单的应用，但代码行数早就已经过万了，写起来非常厚重。有了 AI 之后，执行层面的负担的确轻了很多。
此次开发整体的经验，最后还是落在三个判断上。
第一，架构先行。一定要与 AI 多次讨论计划。先确定哪些需求重要，哪些可以砍掉。再反复讨论它当前的实现方式有没有潜在问题。如果有问题，之后要怎么改进，也要先在计划上搞清楚，再让 AI 照着计划去执行。
第二，测试流程一定要放进去。AI 在编写长代码时总会出各种各样的问题。必须有一个方案能直接告诉它哪里出了问题，它才能继续修改。所以无论 AI 执行什么任务，测试流程都应该放进去。
第三，对于开发平台的理解也会跟着变化。iOS Application 的开发，实际上要比网页开发复杂得多。但应用本身会更稳定，因为它是在 Apple 的框架规范之下开发的。
不过回头看，我整个开发 App 的过程，和开发网页应用的过程几乎没有区别。未来如果没有网络限制，如果浏览器的功能更强大一点，实际上我们也不需要再针对某个系统专门开发本地 App，直接用网页就可以解决。
这样看的话，整个应用市场其实正在更快地走向「即用即抛」的软件。
心法
这些是写给那些想要快速用 AI 来开发 App 的人的。
在 AI 时代，教程其实不需要细节到手把手教你每一步要做什么。更重要的是把关键节点、核心思想和判断标准告诉 AI，让它先帮你设计一套行动方案，你再对着执行和修正。某种程度上说，把我这两篇文章直接交给 AI，当作背景材料，让它参考这些文字来满足你自己的需求，就是一种很实用的方法。
如果再补一些更具体的信息，我现在用的技术栈其实也不复杂。开发平台上，我会优先选 iOS，不是因为它天然更简单，而是因为安卓要适配不同手机，复杂度会更高。真要往下做，你还需要一个苹果开发者账号，这样才能访问苹果平台独有的一些功能。
编程工具这边，你也需要一个适合本地协作的 AI。我目前用下来体验最好的是 Codex，所以需要订阅 ChatGPT。当然，这些也都有国产替代方案，整体思路是一致的，无非是把同样的需求交给别的 AI，让它告诉你应该怎么替代。
至于设计思想，其实还是前面那几条经验。需求永远是核心，所以在任何行动之前，都要先把问题说清楚，再与 AI 充分讨论计划。然后先做出最小的可运行原型，让它先跑起来，再慢慢优化。与此同时，测试要不断补上，这样 AI 在添加新功能的时候，才不至于把原有功能一起改坏。
只要把这些节点抓住，用 AI 来开发 App 的过程通常都会顺很多。
