ever-co/ever-gauzy

Gauzy 把小型公司通常分散在多个 SaaS 里的模块拼到一起：工时追踪、员工档案、CRM 联系人、项目任务、报价、开票和账务。如果你经营一家服务型团队，希望这些数据集中在自己能掌控的系统中，它值得看一下；如果你只需要其中某一个模块，它就不合适。

解决什么问题

小型工作室常见的状态是：工时记在一个工具里，客户资料在另一个工具里，开票在第三个工具里，审批靠聊天软件催。每次交接都要手工导出或复制粘贴，同一个客户在三个系统里有三个名字。Gauzy 把员工工时、项目任务、客户联系人、报价和发票放在同一个组织下，工时条目和由它生成的发票行属于同一套数据，最终得到一份“谁在哪个项目上花了多少时间、应该怎么计费”的统一记录。

有什么不同

这个项目的特点在于覆盖面的广度，而非某个模块的深度。README 列出的人力资源（含入职、休假审批）、招聘（ATS）、CRM、销售漏斗、提案、账务与开票、费用、库存、设备共享、目标与 KPI，以及多组织管理和对外的组织/员工公开页面。对小公司来说，这意味着一个登录、一份人员/客户/资金数据库，而不用再做系统集成。

支撑这种广度的是 API 优先的设计：后端是 NestJS 配 TypeORM/MikroORM，前端是 Angular，同一套 API 也可以直接给自建客户端使用 API 文档。因此你可以在它之上做一个很窄的前端。代价是套件类产品常见的：采用 Gauzy 意味着同时接受它在工时、计费和联系人上的整套数据模型；README 也明确说托管版本目前处于 Alpha 测试阶段，需谨慎使用。

谁值得试

适合：几十人规模的服务型公司或软件工作室，希望自托管、把工时和项目绑定、并按时长开票。不适合：只需要开票的独立自由职业者，或者已经有 ERP、只想补一个工时工具的大企业；在这两种情况下，附带的 HR、ATS、库存等功能都是负担。

想先体验又不想自己搭基础设施，项目提供了托管实例 app.gauzy.co，但它被明确标注为 Alpha/测试版。愿意直接看代码或扩展的团队可以用 README 链接的 Gitpod 环境 Gitpod 入口，同一页面也给出了手动构建的方式。

使用条件与边界

生产环境 README 推荐 PostgreSQL 或 MySQL，部署推荐 Kubernetes 或 Docker；SQLite 是默认选项，但被描述为适合演示。自己运行意味着要维护数据库和容器/部署流程，对自托管软件来说这很常见，但对非技术团队不是一条命令的事。

最可能影响决策的限制是许可证。默认是社区版许可，另有 Small Business 和 Enterprise 许可，项目提供了各版本对比页 许可对比。如果 Gauzy 会成为商业流程的核心，迁移前应先确认自己落在哪一档。README 也直说无法保证 100% 安全、软件按原样提供，因此正式使用时需要自己规划备份，并对客户端到后端的通信启用 HTTPS/WSS。

HotRepo 点评

唯一的带日期记录是 2026-10-25 登上 GitHub 每日 Trending 榜一次，当天 8,584 stars、+34。只有一天记录、也没有更早的可比历史，因此无法从 HotRepo 的数据判断关注度是否持续；项目本身创建于 2019 年。决定投入之前，先读许可对比页、确认你的使用场景属于哪一档——决定它能否替代现有工具栈的是许可，而不是功能清单。