“不要让 AI 猜你的意图；给它不可篡改的接口契约、真实的类型声明，以及改完必须读回的物理验证纪律。”
在过去数月里，LutiveLab 连续完成了 Lutive 胶片相机与 Lutive 相册清理在 HarmonyOS NEXT 上的开发、端侧性能打磨与 AppGallery 实际上线。从最初的一行代码到最终发布，整个过程由一个人与多个专业 AI Coding Agent 协同推进。
一、为什么探索多模型分工比单会话持续提问更稳健
很多开发者在使用 AI 辅助编程时，习惯在同一个会话中从需求分析一路聊到代码实现、重构和测试。但随着上下文长度增加，模型的注意力和遵循系统约束的能力容易出现波动。
在我们的工程实践中，我们将任务拆分为清晰的职责阶段：
- 架构与方案审查：明确输入输出数据流与核心边界；
- 精准代码实现：遵循不可篡改的 API 声明，严禁凭记忆猜测签名；
- 强制物理验证：文件改完必须立即由工具读回，不轻信写入反馈；
- 独立代码审查：由不同模型视角核验边界条件与性能损耗。
二、鸿蒙端侧性能的真实挑战
相册清理类应用面临的核心挑战并非复杂的算法，而是真实相册中动辄数万张照片的加载流畅度。在 HarmonyOS NEXT 上，主线程耗时稍长便会导致列表掉帧。
我们通过端侧离屏预解码、智能聚类分析与零网络权限架构，数据处理默认保留在端侧设备，以保障高刷新率设备的滑动流畅体验。
三、写给独立开发者的一点建议
AI 改变的不是写代码本身，而是代码交付的杠杆率。保持你的设计品味、对物理细节的克制，以及对真实用户体验的敬畏，远比盲目追求全自动生成更重要。