Vibe coding 仅仅是个开始。

开源的 Convergence App Builder。
从意图生成可运行的应用，然后根据业务需求验证每一个 agent 轮次。

快速开始 · 为什么选择 convergence · 测试框架 · 参与贡献

QuantumByte 处于早期阶段，目前可用，并且有意采用公开构建的方式。我们正在寻找志同道合的创始贡献者，你们相信软件应该由理解问题的人来塑造，而不仅仅是由会写代码的人来塑造。 **[在 Discord 上加入创始团队](https://discord.gg/zFD35kwHmU)** ## 为什么选择 convergence Vibe coding 降低了软件创建的门槛。这是一项突破。 但是，一个应用在真正准备好投入实际运营之前，可能早早就看起来已经完成了。界面可以正常渲染，主流程也能运行，演示效果令人印象深刻。然而，重要的需求可能仍然缺失、被误解或默默失效。 我们将此称为 **false convergence**。 代码生成让你得到了一个可以构建的应用。而 convergence 关注的是接下来会发生什么： - 应用是否仍然符合最初的意图？ - 关键的业务需求是否得到了满足？ - 有什么证据支持每一个判定结论？ - 在人类信任它之前，必须修复什么？ QuantumByte 将应用生成转化为一个持续的循环： ``` Intent -> Build -> Verify -> Evidence -> Repair or Ready ``` 当前的开源版本从明确的业务需求开始。在每一个 agent 轮次之后，一个独立的只读测试框架会逐项检查应用需求，并返回带有证据的结构化判定结论。 ## 今天发布的内容 ### App 构建器 - 通过对话捕获意图和生成产品概述 - Agent 在专属的项目仓库中生成应用 - 在每个完成的 agent 轮次后进行构建恢复 - 提供带有健康检查和设备边框的实时应用预览 - 具备项目亲和性和轮次恢复能力的 Worker 协调 ### Requirements 测试框架 - 源自产品概述的 requirements - 用户锁定的权威 requirements - 对每个 requirement 进行独立的只读审计 - 带有证据的结构化 `SUCCESS` 或 `FAIL` 判定结论 - 将 `INCONCLUSIVE`（不确定）与真正的失败区分开 - 当相关文件发生更改时进行基于 Diff 的重新验证 - 非阻塞的后台运行，并在 UI 中实时显示判定结论 ## 快速开始 ### 前置条件 - Docker 和 Docker Compose（Postgres、Redis 和 minio 运行在容器中） - Node.js 20+ 和 npm - Python 3.11+ - 当前 worker 实现所需的 Anthropic API key ### 本地运行 ``` git clone https://github.com/QuantumByteOSS/quantumbyte.git cd quantumbyte make install make db-up make migrate make dev ``` 打开 [http://localhost:3000](http://localhost:3000)。运行 `make help` 查看所有开发命令。 有关环境变量、服务拓扑和故障排除，请阅读 [docs/running.md](docs/running.md)。 ## 测试框架的工作原理 ``` User intent | v Product overview -> Builder agent -> Working app | v Read-only harness | +------------------+------------------+ | | | Verdict Evidence Watched files | | | +------------------+------------------+ | v Repair or ready ``` 构建器和验证器是刻意分离的。构建器可以编辑项目。测试框架在不继承构建器对话的情况下，一次评估一个业务需求，并且它无法修改正在审计的仓库。 ## 架构 - **`apps/web`**：使用 Next.js、TypeScript 和 Prisma 的工作区、聊天、实时预览和 requirements UI - **`apps/orchestrator`**：使用 Python 和 PostgreSQL 的项目分配、worker 协调和恢复 - **`apps/worker`**：使用 Python 和 Claude Agent SDK 的 agent 执行、构建循环、工作区管理和 requirements 测试框架 - **PostgreSQL**：项目、消息、worker、requirements 和判定结论的 source of truth - **Redis**：基于项目的测试框架锁 - **minio**：用于存储 agent 生成的资源的 S3 兼容存储 当前的 worker 使用 Claude Agent SDK。提供商中立的 agent 边界和额外的模型提供商已列入路线图。 有关系统概述，请参阅 [ARCHITECTURE.md](ARCHITECTURE.md)。 ## Convergence 编程 QuantumByte 是一个早期的可执行系统，其灵感来源于 **Convergence 编程**，这是一个用于 AI 辅助编程和 agent 的研究框架。 传统的软件生成通常被定义为 `specification -> program`（规范 -> 程序）。Convergence 编程研究的是更宏大的发展轨迹： ``` lossy intent -> generated behavior -> observation -> evidence -> repair -> readiness decision -> action or block ``` 当前的测试框架实现了该议程的一部分：根据明确的业务需求对生成的软件进行持续验证。它目前尚未声明实现了完全基于现实世界的验证、完整的生产就绪状态或提议的 ConvergenceBench 评估框架。 ## 路线图 - [x] 从意图到应用的生成 - [x] 实时预览和健康检查 - [x] 持续的业务需求测试框架 - [x] 基于 requirement 的判定结论和证据 - [ ] 一键自托管 - [ ] 模型和 agent 提供商适配器 - [ ] 概念、代码和蓝图编辑器 - [ ] 基于现实世界的证据和就绪检测门槛 - [ ] ConvergenceBench 参考任务和评估工具 有关里程碑的详细信息，请参阅 [docs/roadmap.md](docs/roadmap.md)。 ## 为什么开源 AI 应用生成层正在变得大众化。我们宁愿推动这一进程，也不愿假装并非如此。 生成更多的代码并不是一个持久的问题。更棘手的问题是：随着系统的变化，如何保持人类意图、AI 的理解、生成的行为和运营需求保持一致。 我们正在开放引擎，以便程序员和研究人员可以检查测试框架、挑战其假设、复现其行为，并帮助构建更好的方法，以决定 AI 生成的软件何时真正准备好。 ## 许可证 QuantumByte 采用 [Apache License 2.0](LICENSE) 授权。

标签：AI编程, MITM代理, 代码生成, 低代码开发, 应用构建框架, 搜索引擎查询, 测试用例, 渗透测试工具, 版权保护, 自动化验证, 请求拦截, 逆向工具