核心用法
dev-factory 是一个全自动软件开发代理系统，核心工作流包含四大阶段：
1. 智能选题：自动抓取 GitHub Trending、CVE 数据库、安全新闻等来源，发现潜在开发需求并注册到 Notion 任务队列
2. 多智能体协作开发：调用 ChatDev 2.0 的 7 个专业代理（CEO/CPO/CTO/Programmer/Reviewer/Tester/CTO Final）分工完成需求分析、产品设计、架构设计、代码生成、代码审查、测试编写和最终验收
3. 自纠错循环：测试失败时自动分析错误、生成修复方案、重新测试，最多重试 3 次
4. 自动发布：通过后自动创建 GitHub 仓库、推送代码、生成 README 和 MIT 许可证
显著优点
- 全自动化闭环：从灵感发现到生产部署无需人工介入，显著降低安全工具开发门槛
- 专业化分工：模拟真实软件公司的组织架构，各环节由专职代理负责，输出质量优于单代理方案
- 领域针对性强：专门针对安全工具和 DevOps 场景优化，内置 CVE、漏洞扫描等场景知识
- 可观测性好：Notion 队列管理 + 详细日志记录，便于追踪每个项目的开发状态
潜在局限
- 依赖外部服务稳定性：需同时维护 GLM-5 API、ChatDev 2.0 本地服务、GitHub API、Notion API 四个外部连接点
- 测试质量瓶颈：历史记录显示部分失败源于"测试代码与实现逻辑不匹配"，说明自生成测试的可靠性仍需提升
- 代码质量不可控：生成的代码风格和架构一致性依赖大模型能力，缺乏人类架构师的长期把控
- 重试机制有限：仅 3 次重试，复杂 Bug 可能无法修复，导致项目废弃
适合人群
- 安全团队需要快速原型验证 CVE 利用工具或扫描器
- DevOps 工程师需要定制化自动化脚本但缺乏开发时间
- 开源维护者希望基于 Trending 话题快速生成配套工具
- 技术研究人员探索多智能体协作开发的工作流
常规风险
- API 密钥泄露：需配置 GLM、GitHub、Notion 三类敏感密钥，存在配置泄露风险
- 自动发布风险：代码未经人工审计即推送公开仓库，可能包含安全漏洞或敏感信息
- 依赖供应链污染：自动拉取的依赖包未经验证，存在供应链攻击面
- 许可证合规：默认 MIT 许可证，若集成第三方代码可能产生许可证冲突