Dyad 评测：本地 AI 应用构建器，但许可证与功能边界需要先看清
Local, open-source AI app builder for power users ✨ v0 / Lovable / Replit / Bolt alternative 🌟 Star if you like it!
秒懂
- 它是什么？
- Dyad 是一个本地运行的开源 AI 应用构建器，面向想要替代 v0、Lovable 或 Bolt 的开发者。它强调隐私与自带 API 密钥，但仓库中 src/pro 目录采用不同的许可证，且 README 未提供任何安装命令或使用细节。
- 适合谁用？
- Dyad 适合那些对数据隐私敏感、希望完全掌控 AI 应用生成流程的开发者，尤其是愿意自带 API 密钥、不想被云端服务锁定的用户。不适合需要开箱即用、依赖官方托管服务的团队，因为目前没有明确的服务端部署方案。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，为谁准备
Dyad 面向的是受够了云端 AI 应用构建器的开发者。v0、Lovable、Bolt 这类工具把生成和部署都放在云端，代码、提示词、甚至生成的中间产物都可能经过第三方服务器。Dyad 的定位是让整个流程在本地机器上跑，数据不出设备，且用户自己提供 AI 的 API 密钥。README 里强调“Local, private and no lock-in”，这直接点出了它的目标用户：对数据隐私敏感的自由职业者、独立开发者，以及那些不想被单一云厂商绑定的团队。它不是一个面向非程序员的玩具，而是给“power users”准备的工具，这个词写在项目描述里，暗示使用者需要自己处理 API 密钥、本地环境甚至可能的配置问题。
本地运行的核心机制：从 README 能读出什么
仓库的 README 非常简短，没有架构图，也没有数据流说明。我们能确认的机制只有三层：第一，它是桌面应用，支持 Mac 和 Windows，通过下载二进制文件运行，不需要注册账号。第二，它接受用户自己的 AI API 密钥，这意味着所有请求都从本地直接发往模型提供商，而不是经过 Dyad 的服务器。第三，项目用 TypeScript 编写，主要基于 React 和 Next.js，从 topics 里能看到这些技术标签。但具体如何将自然语言转换成应用代码，是调用 Agent 还是多步流水线，是流式生成还是逐文件写入，这些在材料中完全找不到。这种信息缺失本身就是一个信号：如果你想深入定制它的生成逻辑，可能需要直接读源码，而不是依赖文档。
获取与运行：下载即可，但命令与配置一概没有
README 给出的唯一获取方式是访问 dyad.sh 网站，点击下载对应平台的安装包。没有提供 npm 安装命令，没有 Docker 镜像，也没有从源码构建的指引。这意味着如果你想在 Linux 上运行，或者想自己编译最新提交，目前没有现成路径。下载后如何配置 API 密钥？支持哪些环境变量？是否有一个设置界面？这些都没有说明。唯一能确定的是，项目有持续发布，最新版本是 v1.14.0，发布日期为 2026 年 9 月 9 日，说明开发活跃。但活跃的发布节奏不能弥补文档的空白。对于习惯命令行操作的用户来说，这种“下载即走”的体验可能很顺畅，但如果你想自动化部署或集成到 CI，就会立刻碰壁。
许可证的双轨制：Apache 2.0 与 Functional Source License 的边界
Dyad 的许可证策略值得仔细看。README 明确说，仓库中 src/pro 目录以外的代码采用 Apache 2.0，而 src/pro 目录内的代码采用 Functional Source License 1.1（FSL）。FSL 是一种“fair-source”许可证，它允许非商业使用和修改，但对商业再分发或托管服务有限制，通常在一段时间后自动转为 Apache 2.0。这意味着，如果你打算基于 Dyad 构建商业产品，或者在公司内部使用，必须首先确认你用的代码是否涉及 src/pro。如果涉及，你需要理解 FSL 的具体条款，尤其是对“生产使用”的定义。仓库根目录的 LICENSE 文件与 src/pro 下的 LICENSE 文件分开，这本身是一个清晰的信号，但用户很容易忽略。一个粗心的开发者可能以为整个项目都是 Apache 2.0，结果把 FSL 代码集成到闭源产品里，这会带来法律风险。
真正的限制：文档缺失与平台覆盖的盲区
Dyad 最大的限制不是功能，而是可验证性。作为评测者，我无法从 README 中得知它是否支持流式响应、是否能处理大型代码库、是否支持自定义模型端点。它列出了 Anthropic、DeepSeek、Gemini、OpenAI、Ollama 等关键词，但没有说明这些是内置适配器还是仅仅通过 OpenAI 兼容 API 间接支持。另一个现实问题是平台覆盖：只提 Mac 和 Windows，Linux 用户被排除在外。对于许多 AI 开发者来说，Linux 是主力环境，缺少 Linux 支持会直接劝退一批潜在用户。此外，没有说明离线时是否可用，也没有说明本地是否有缓存机制来减少 API 调用成本。这些空白意味着，在你亲自下载并测试之前，你无法判断它是否适合你的工作流。
替代方案：v0、Lovable 与 Bolt 的差异点
Dyad 把自己定位为 v0、Lovable、Bolt 的替代品，但它们的差异非常明显。v0 是 Vercel 的产品，深度绑定 Vercel 的部署流程，生成代码后可以直接推送到 Vercel，它的优势是前端生态集成，但数据在云端。Lovable 面向更广的用户，包括非程序员，它强调用自然语言生成完整应用，但同样托管在云端。Bolt 是开源的，但官方版本通常需要连接远程 AI 服务，本地部署需要额外配置。Dyad 的差异点在于“本地”和“自带密钥”：它把生成过程完全放在你的机器上，密钥由你管理，这意味着你的代码片段和提示词不会离开你的电脑。这与 v0 的云端处理形成鲜明对比。但这也带来一个代价：你失去了云端工具提供的托管、数据库、身份验证等配套服务，必须自己处理这些环节。
维护与升级成本：发布节奏快，但升级路径不明
从发布记录看，Dyad 的维护相当活跃，v1.14.0 在 2026 年 9 月 9 日发布，几天前还有两个 beta 版本。这种频率说明项目处于快速迭代期，但快速迭代也意味着 API 或行为可能频繁变化。如果你是重度用户，每次升级都可能遇到兼容性问题，尤其是当你自己修改了生成模板或依赖了内部接口时。由于没有提供变更日志的链接，也没有说明升级是否保留用户配置，你无法预知升级风险。贡献指南存在（CONTRIBUTING.md），但没有具体内容。如果你打算自己修补问题并向上游提交，需要先阅读该文件，但它的存在本身是一个积极信号。总体而言，维护成本取决于你愿意投入多少时间去跟踪每个新版本的变化。
编辑结论
Dyad 适合那些对数据隐私敏感、希望完全掌控 AI 应用生成流程的开发者，尤其是愿意自带 API 密钥、不想被云端服务锁定的用户。不适合需要开箱即用、依赖官方托管服务的团队，因为目前没有明确的服务端部署方案。也不适合对许可证纯洁性要求极高的企业，src/pro 目录使用 Functional Source License 1.1，并非纯 Apache 2.0，使用前必须逐行检查代码来源。建议先下载对应平台的二进制文件，验证其是否支持你常用的模型（如 OpenAI、Anthropic、Ollama），并确认自定义 API 端点的配置方式，因为 README 中并未给出任何配置示例。最终判断：Dyad 是一个有明确本地优先定位的项目，但文档的缺失和许可证的双轨制会阻碍严肃采用。
社区笔记