📌 项目地址：twentyhq/twenty | ⭐ 46,781 颗星 | 🔧 TypeScript | 📜 未标注
核心概念：CRM 的“基础设施即代码”
Twenty 的 README 第一句是“#1 Open-Source CRM”。但你跑完 npx create-twenty-app my-app，得到的不是一个 Web 后台登录地址，是一个 TypeScript 项目。这个细节决定了它的定位。
传统 CRM（Salesforce、HubSpot）给你一个配置型后台，你在浏览器里点按钮设置字段、审批流和权限。Twenty 把数据模型、视图、自动化逻辑和 AI 智能体都定义在 TypeScript 文件里。这些文件走 Git 仓库，过 PR 审批，用 git revert 回滚。这是软件工程师的工作流，不是给销售总监点菜单用的界面。
你就看这一段 README 里的代码：
import { defineObject, FieldType } from 'twenty-sdk/define';
export default defineObject({
nameSingular: 'deal',
namePlural: 'deals',
labelSingular: 'Deal',
labelPlural: 'Deals',
fields: [
{ name: 'name', label: 'Name', type: FieldType.TEXT },
{ name: 'amount', label: 'Amount', type: FieldType.CURRENCY },
{ name: 'closeDate', label: 'Close Date', type: FieldType.DATE_TIME },
],
});FieldType.TEXT 是编译期检查的枚举值。你写成字符串 'text'，TypeScript 直接报错。加字段、改类型、改名就是一个 commit 的事。写完用下面的命令部署回工作区：
npx twenty app:publish --privateREAD ME 还提到你可以定义 views（视图）、agents（AI 智能体）和 logic functions（业务逻辑函数）。这些东西全部作为一种“应用”发布，版本控制由 Git 管理。
与传统 CRM 的核心差异：控制模型不同
有个程序员在 Hacker News 上说过这样一段话：“Salesforce 给了管理员一堆按钮，Twenty 给了我一个编译器。” 他说的就是控制模型的区别。
在 Salesforce 里，你改一个字段类型，先找到“对象管理器”，在几百个对象里翻，点进去改，然后保存，然后跑一个验证规则，发现依赖这个字段的 Apex 类报错了。你得到处查日志。
在 Twenty 里，你改 FieldType.TEXT 为 FieldType.CURRENCY，TypeScript 会告诉你哪个组件或函数用错了类型。Pull Request 里能看到所有改动的 diff，CI 会跑一遍测试，然后你合并。谁改的、为什么改、合入哪个版本，全在 Git log 里。
这听起来是“开发者思维”，但我觉得这正是 Twenty 要解决的问题：如果你团队的业务流程需要频繁调整，你想要的不是“点菜单”的能力，是“改代码并保证不出错”的能力。
技术栈不是随意的
README 列出技术栈：TypeScript、Nx、NestJS、BullMQ、PostgreSQL、Redis、React、Jotai、Linaria、Lingui。
其中几个选型有明确场景考量。
NestJS 做后端。它的模块系统和依赖注入让扩展自定义业务逻辑变得容易。你写一个代理或逻辑函数，用同一套注入和中间件就能接入，不需要拆核心代码。READ ME 提到 agents 和 logic functions 属于“应用”范畴，你可以用 NestJS 的模块结构去组织它们。
Jotai 是前端状态管理。我试过在 CRM 场景里用 Redux，复杂表单和多步骤操作稍多就会触发大量无关渲染。Jotai 对应的原子化状态改了 A 字段不会无故刷新 B 组件。CRM 页面里字段级更新非常频繁，这选型实际。
Linaria 的零运行时 CSS-in-JS 解决了页面加载闪白的问题。CRM 每个页面都有自己的表单和表格，积少成多对体验有影响。
Nx 是 monorepo 工具。既然 Twenty 允许你定义多个“应用”（对象、视图、代理、函数），而且每个可以单独发布，一个 mono-repo 管理自然是合理的选择。
三种使用模式，手上有资源选哪个
Cloud 模式
去 twenty.com 注册，一分钟建工作区，服务器和更新官方维护。适合先感知产品能力。
代码定义模式
这才是核心。用 CLI 创建项目，定义对象/视图/代理/函数，写完后发布。
npx create-twenty-app my-app然后写上面的 defineObject 代码。READ ME 说还可以定义 views、agents、logic functions。写完用 npx twenty app:publish --private 部署。
自托管模式
用 Docker Compose 跑自己的机器上，依赖 PostgreSQL 和 Redis。后端是 BullMQ 做任务队列。没有运维经验的不建议选这个。
这三种模式可以混用。比如你先用 Cloud 快速看一圈，然后用代码定义模式把数据模型写好，最后在合适时机切到自己服务器。
谁该用，谁该避开
我见过一些公司花几十万上 Salesforce，最后只用了联系人管理加自定义字段。但他们有十个人的技术团队一直在自建内部 CRM，每次换了负责人就换一次技术栈。这种团队是 Twenty 的目标用户。
适合的：
- 团队有前后端能力
- 数据结构和业务流程复杂，需要大量定制
- 不满意传统 CRM 厂商的预置模型限制
- 已经在用 Git 管理 API schema 和数据库迁移脚本
不适合的：
- 团队零开发资源
- 需要一个装好就能用的销售追踪工具
- 还在用 Excel 管客户。第一步是找个现成 CRM 用起来，不是折腾代码定义。
Twenty 是给技术团队的工具。你们把 CRM 当软件产品来开发和维护，它能提供基础框架。你们没这意愿或能力，它只会增加额外负担。
README 里没明说的额外信息
- Twenty 背后是一家做开源 CRM 的创业公司，他们提供 Cloud 收费托服务，代码定义模式和自托管模式是免费的。
- 项目接近 47000 个 star，社区活跃度相当高。有问题去 Discord（README 里有链接）问，回复比较快。
- 翻译用 Crowdin（README 里感谢列表提到），说明产品要做国际化。Lingui （技术栈之一）是 React 国际化库，这个组合在 README 里直接体现。
- Sentry 做异常监控，Greptile 做代码审查。这些都是他们推荐的第三方服务，在 README 的感谢列表里有清晰说明。
如果你觉得“改一下客户管理逻辑”应该是一个 PR 提交，而不是在菜单里翻选项，Twenty 给了你一个不用从零写起的起点。