Twenty：把 CRM 当代码来写的开源方案，直指 Salesforce 与 AI 时代的定制难题

客户关系管理软件是企业软件里最古老的品类之一，长期被 Salesforce 这样的商业巨头占据。传统 CRM 的问题很熟悉：字段和流程要在管理后台里一点点点选配置，配置无法进入代码仓库，没有评审，也难以回滚。业务一变，团队就得在黑盒界面里反复折腾。Twenty 要解决的正是这个矛盾。它在 GitHub 上已有五万九千多个星标，把自己定位为 Salesforce 的开放替代方案，并明确提出为 AI 而设计。项目的核心主张很朴素：技术团队需要的是一套可以拼装的构件，而不是一个写死的成品。官方的说法是，Twenty 是你像对待技术栈里其他部分一样去构建、发布和版本化的 CRM。这句话点出了它与老牌产品的根本区别。在开源生态里，它处在业务应用层，面向的是既想拥有数据与代码控制权，又不愿从零造轮子的工程团队。它不是又一个只能照单全收的开箱即用系统，而是一个把 CRM 当作可编程平台的基础设施，让销售、运营和开发在同一套语言里协作。Twenty 的能力可以从几个层面理解。第一层是基础构件，也就是对象、视图、工作流和 agent。对象对应客户、商机这类业务实体，视图决定数据如何被呈现，工作流负责自动化，agent 则把 AI 直接放进业务流程。

第二层是它最有辨识度的做法：把这些构件写成代码。按照 README 的示例，开发者通过 twenty-sdk 的 defineObject 声明一个 deal 对象，指定单复数名称、显示标签，以及名称、金额、预计成交日期等字段，字段类型分别是文本、货币和日期时间。这些定义和普通 TypeScript 文件一样，可以放进 Git、走代码评审、随版本演进。第三层是发布机制，一条 app:publish 命令就能把应用以私有方式推送到工作区。与在界面里逐项配置相比，这种方式让变更可追溯、可复现、可自动化。第四层是对编码 agent 的原生支持：项目提供官方的 Twenty app skills，可在 Claude Code、Codex、Cursor、Pi 等通过 skills CLI 支持的环境中使用，让 AI 助手也能按规范帮你搭建应用。底层技术栈为 TypeScript、Nx，后端用 NestJS 搭配 BullMQ、PostgreSQL 和 Redis，前端用 React，配合 Jotai、Linaria 与 Lingui。上手路径分成三条，对应不同的人群。想最快体验的人，可以直接在 twenty.com 注册云端工作区，官方称不到一分钟即可启动，不用管理基础设施，也始终保持最新。想做二次开发的团队，可以运行 npx create-twenty-app my-app 生成脚手架，然后用代码定义对象、字段和视图，再发布到自己的工作区。文档里还有专门的应用开发指南，覆盖对象、视图、agent 和逻辑函数。对数据位置和合规有要求的团队，可以按文档用 Docker Compose 在自己的服务器上自托管，也可以按本地环境指南参与贡献。典型用法包括：为销售团队建立带自定义字段的商机管道，为客户成功团队定制专属视图，或者用工作流与 agent 处理重复的跟进动作。

项目说明中还提到可以阅读面向使用者的用户指南和面向开发者的参考文档，两类读者各有入口。社区方面，项目设有 Discord、路线图、功能请求渠道，并使用 Crowdin 做多语言翻译，仓库话题里带有 good-first-issue 与 hacktoberfest，对新贡献者比较友好。需要提醒的是，README 只给出了入口，更细的功能边界仍要靠阅读文档来确认。Twenty 的意义不止于多了一个开源 CRM。它代表了一种趋势：业务软件正在从界面配置走向代码定义，再走向让 AI agent 参与构建与运营。当对象和视图都是代码时，编码 agent 才能真正读懂并修改它们，这也解释了为什么项目要专门提供面向 Claude Code、Cursor 等工具的技能包。对工程团队来说，这意味着 CRM 可以进入和其他系统相同的交付流水线，享受版本控制、评审和自动化部署。对中小团队来说，开源与自托管降低了被单一供应商锁定的风险。不过，我们也应看到潜在风险。其一，代码化定制把门槛交给了开发者，非技术的业务人员未必能独立维护。其二，自托管意味着要自己承担运维、备份与升级的责任。其三，README 提到 agent-skills 分支要在首次成功发布后才会创建，说明部分配套能力仍在演进，生产使用前应核对最新文档。值得持续观察的方向包括：应用生态能否形成可复用的模板市场，agent 在真实销售流程中的可靠性，以及社区对大型企业场景的适配程度。如果这些环节成熟，Twenty 有机会成为开源企业软件里一个很有代表性的样本。