一天原型，一周成品：开发 Lody iOS 实况
内容提要
作者用一周时间，通过给 AI 下约束性指令，从零开发出 Lody 的 iOS 客户端。先让 AI 调研可行性，确定离屏 WebView 承载 WASM、原生只管宿主的架构。随后每天用简短 prompt 推进：先对齐系统设计再谈特色，方案未定不写代码，删除多余 Tab Bar，先 review 再改，追问 CI 慢的原因，用截图验收。最终完成 122 个提交、640 个文件，Swift 代码占比从 15% 升至 46%。
延伸解读
架构决策的连锁影响
文章指出，可行性调研发现无法直接引入 Lody 的 RPC 或 shared 总入口，因为依赖链会拉进 Node 的文件系统和 CRDT/Zstd，导致 RN 打包失败。这一约束直接决定了后续架构：用离屏 WebView 承载 Flock 的 WASM，原生只负责宿主和看门狗。许多看似奇怪的设计都源于此。这提醒读者，早期技术调研的结论会深远影响项目结构，在启动前明确边界条件至关重要。
用约束性指令驱动 AI 开发
作者在初始化指令中未描述具体功能，而是给出架构约束：使用 RN 模板、Native 模块统一由 Kit Module 承载、不考虑安卓、UI 无法达到时用 Swift 编写。功能由 AI 从“iOS 客户端”自行推导。这种做法的核心是让 AI 在明确的边界内自主决策，而非逐步指定实现。对于希望借助 AI 构建项目的开发者，提供清晰的约束比详细的功能列表更能激发有效产出。
验收协议如何成为质量保障
从第二天起，作者建立了严格的验收协议：单元测试、类型检查、lint 和构建都不算验收，验收必须落成不可修改的轮次，并补充证据类型——截图证视觉、录屏证时序，缺一即判失败。一周内产生 26 个验收主题，同一主题最多 4 轮。这种机制将主观判断转化为可重复的客观标准，尤其适合 AI 生成代码的验证，减少人为遗漏。
RN 与 Swift 的混合边界策略
文章反驳了“AI 时代应直接写原生”的观点，实际做法是 RN 当基座，核心交互用 Swift 实现。Swift 代码从第一天的 656 行增长到周末的 22,388 行，占比从 15.4% 升至 45.7%，聊天、列表、云端等模块大量使用 Swift。判断标准明确：RN 达不到体验要求就用 Swift，而非用 RN 模仿系统效果。这种混合策略在保持开发效率的同时，为未来可能的完全原生重写减少了工作量。
Q&A
Lody iOS 客户端为什么选择离屏 WebView 承载 WASM 的架构？
因为可行性调研发现，直接引入 Lody 的 RPC 或 shared 总入口会拉进 Node 的文件系统和 CRDT/Zstd 依赖，导致 React Native 无法打包。所以决定让离屏 WebView 承载 Flock 的 WASM，原生只负责宿主和看门狗。
开发 Lody iOS 时，作者如何用 prompt 推进每天的工作？
作者每天用简短 prompt 推进，先对齐系统设计再谈特色，方案未定不写代码，删除多余 Tab Bar，先 review 再改，追问 CI 慢的原因，用截图验收。例如第一天发 141 条，大部分只有几个字，形式是指出一件事，AI 给判断，作者拍板。
Lody iOS 项目最终完成了多少提交和文件？Swift 代码占比变化如何？
一周内完成 122 个提交、640 个文件。Swift 代码占比从第一天的 15.4% 升至周末的 45.7%，Swift 行数从 656 行增长到 22,388 行。
作者在开发中如何处理 RN 与 Swift 的边界？
作者以 RN 为基座，但一部分屏幕直接用 Swift 实现。判断标准是：RN 达不到的体验要求就用 Swift，而不是用 RN 去模仿系统效果。核心交互如聊天列表、输入框、列表行、diff 查看器都在 Swift 里。
验收协议是如何在开发过程中逐步形成的？
第一天原型能确认可用，第二天改界面后无法确认，当晚提交中出现验收协议，规则很硬：单元测试、类型检查、lint、构建都不算验收；验收要落成不可修改的轮次。第四天作者说“verify 的脚本正确的话我就不看了”，使其成为必经之路。后续增加设备租约、证据类型（截图证视觉、录屏证时序），缺一样整轮判失败。
作者使用了哪两个 AI agent？它们的分工有何不同？
使用了 Claude Code 和 Codex。Claude Code 主要把模糊想法变成物件，产出设计文档、设计稿、规格和任务清单，共 35 个会话。Codex 负责变成能跑的代码和物证，是 Swift 和 UIKit 的主力，全周 307 轮对话、约 52 小时对话墙钟，还负责 CI、签名和依赖切换。
