核心用法
mano-afk 是一款面向全自动软件开发的 Agent Skill，用户仅需提供自然语言描述，系统即可独立完成从需求分析到生产部署的完整闭环。其工作流程采用六步编排：Step 0 完成用户交互与E2E配置确认；Step 1-2 由主Agent调度构建子Agent生成PRD、架构设计、代码实现与部署；Step 3-4 执行部署验证与全量测试（API测试、可选E2E测试、对抗审查）；Step 5 进入自动修复循环（最多10轮）；Step 6 完成规则与偏好更新，实现技能进化。
三角色架构是其设计亮点：主Agent负责编排与决策、构建子Agent专注代码生成、对抗子Agent独立设计测试用例并审查代码缺陷。这种分工让主Agent在代码生成阶段保持空闲，可并行处理其他任务，显著提升了整体效率。
显著优点
真正全自动：从Step 1起完全无需用户介入，所有技术决策（技术栈选型、端口分配、验证规则）均自主完成并记录于PRD.md，符合"AFK"设计理念。
质量持续进化：references/rules.md 和 references/preferences.md 跨项目持久化存储，每次修复循环的经验教训和用户反馈都会沉淀为通用规则，使后续项目输出质量不断提升。
测试覆盖全面：涵盖静态检查、API测试、可选E2E视觉测试、对抗性审查四层质量关卡。特别是对抗子Agent从用户视角和代码视角双维度挖掘潜在问题，有效弥补常规测试盲区。
架构设计严谨：本地优先架构确保代码生成、测试执行默认在本地完成；E2E云模式需用户显式配置才启用，数据隐私风险可控。
潜在缺点与局限性
E2E测试依赖外部服务：云模式下的E2E测试需调用云端VLA模型，存在数据外传风险；本地模式虽可避免此问题，但对硬件环境有一定要求。
复杂项目修复上限：自动修复循环设置10轮上限，对于架构级缺陷或需求理解偏差导致的深层问题，可能无法彻底根治。
视觉模型误判风险：E2E测试依赖视觉语言模型判断UI状态，存在将正确实现误判为失败的概率，需人工介入甄别。
技术栈默认倾向：自主决策机制虽提升效率，但可能对特定技术生态（如React vs Vue、PostgreSQL vs MySQL）的偏好固定化，需通过preferences.md主动调优。
适合的目标群体
- 快速原型验证：产品经理、创业者需在短时间内获得可演示的MVP
- 全栈开发减负：资深开发者希望将脚手架搭建、基础CRUD开发外包给Agent
- 标准化项目批量交付：外包团队、IT服务商处理大量同质化的管理后台、信息展示类项目
- 学习参考：初级开发者通过阅读生成的PRD、架构文档学习规范开发流程
常规使用风险
性能风险：构建子Agent任务可能持续30分钟以上，需合理设置超时参数；长时间运行的子Agent可能占用大量系统资源。
依赖风险：生成的项目依赖npm/pip等包管理器，子Agent安装的依赖版本可能存在已知漏洞，建议生成后执行安全审计。
部署风险：自动生成的deploy/start.sh和环境变量配置可能包含不安全的默认设置（如弱密码、开放端口），生产环境使用前必须人工复核。
数据残留风险：E2E测试序列依赖状态累积，数据库重置时机不当可能导致测试污染或误判，需严格遵循"API测试后重置、E2E序列内不重置"的原则。
权限风险：子Agent运行期间具备文件系统读写和网络访问能力，建议在隔离目录执行，避免误操作影响系统关键文件。