独立开发者上线健身App：子代理QA系统如何替代人工测试

一个人做完整款产品是什么体验？最近，独立开发者完成了一款名为Salute的跨平台健身应用，覆盖训练记录、营养追踪和习惯养成三大模块。从架构设计到应用商店上架，他完整经历了solo builder的全流程，并在技术选型和工作流上做出了一些值得关注的决策。

最反直觉的一点：他主动选择了"慢启动"。

通常独立开发者追求快速迭代、小步快跑，但这次他花了大量时间在前期——画流程图、梳理边界情况、用Miro做可视化映射。这套方法来自他的巴西柔术教练：先练技术，再上力量。前期架构的沉淀，反而让后期返工大幅减少。

跨平台框架选了Flutter。他没有做React Native的深度对比，纯粹基于实践体验：稳定性足够、生态成熟、文档结构清晰。对于资源有限的个人开发者，"够用且省心"本身就是决策依据。

真正有意思的是他的开发工作流。他测试了Claude Code、Gemini Pro、GPT类工具、FlutterFlow和Firebase Studio，最终搭建了一套子代理（sub-agent）工作流。核心设计是知识层：把Flutter官方文档、Android Material Design规范、iOS人机界面指南拆解成模块化"技能"，再汇总到一份CLAUDE.md中央指令文件里。代理每次调用时都有统一的上下文，UI/UX和架构决策的一致性由此保障。

但最让他提效的，是一套基于多代理的QA流水线。

独立开发者的经典痛点是测试瓶颈。外部测试者反馈周期长、质量不稳定，他需要更确定性的方案。于是内部搭了一套代理QA系统，由多个专职代理组成：

Screeners（筛查代理）：每个代理负责应用的一个具体模块，比如 onboarding 流程。它们的任务是模拟用户路径，标记异常行为。

这套系统的价值在于把"人工抽查"变成了"自动化遍历"。代理可以7×24小时执行重复性测试，覆盖边界情况的速度远超真人。对于没有专职QA的solo项目，这相当于用架构设计补足了人力缺口。

整个案例的启示在于：当资源极度受限时，工作流设计本身就成了产品竞争力。不是堆人力，而是用代理系统和知识管理把一个人的产出放大到小型团队的规模。这种"结构即杠杆"的思路，可能是AI工具普及后独立开发者最需要重新理解的能力。