Twenty：用代码定义和交付开源 CRM

Twenty 想把 CRM 变成技术团队可以持续开发的软件：客户、商机等业务对象可以用代码定义，再通过 CLI 发布到工作区。它的重点是让团队沿用开发、交付和版本管理的方式，调整自己的业务系统。

对前端和全栈开发者，这个项目值得看的地方是扩展入口：React 界面、NestJS 后端，以及面向 AI 编程工具的官方 skills。不过，README 展示的是产品定位和上手路径，还不足以证明复杂业务接入后的成本。

为什么要把 CRM 当成代码来维护

常见 CRM 定制会涉及字段配置、页面调整和流程编排。Twenty 的主张是，把这些能力做成可组合的基础构件，再允许开发者用代码扩展。

原文列出的构件包括对象、视图、工作流和 agents。对象负责描述业务数据，视图负责组织数据的呈现方式；开发指南还覆盖 logic functions，也就是承载业务逻辑的函数。

Twenty 最有价值的主张，是让 CRM 的定制跟上业务变化，并进入团队熟悉的软件交付流程。

但这里要分清目标和证据。原文强调可以像其他技术栈一样构建、发布和管理版本，却没有展开版本回滚、环境隔离、数据迁移等细节。不能仅凭这句话，就认为它已经覆盖一般团队的全部交付要求。

从定义商机到发布，开发入口是什么

项目给出的起点很直接：执行 npx create-twenty-app my-app，生成一个应用。

下面这段代码展示了如何定义商机对象，包含名称、金额和预计成交时间三个字段：

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 },
  ],
});

要看的是 fields：字段通过 FieldType.TEXT、FieldType.CURRENCY 和 FieldType.DATE_TIME 声明类型，而不是只提供显示名称。原文没有继续说明货币配置、日期时区或字段变更如何作用于已有数据，这些需要进一步验证。

完成定义后，用 npx twenty app:publish --private 发布到工作区。注意保留 --private 参数；README 没有解释它的完整权限语义，不能据此推断数据访问边界。

这段示例证明了对象定义的代码入口。虽然原文也说对象、字段和视图都能用代码定义，但没有给出视图、agents 或逻辑函数的实现示例。

AI 编程和部署分别提供了哪些选择

Twenty 为 AI 编程工具提供官方 app skills，列出的适配工具包括 Claude Code、Codex、Cursor 和 Pi，以及 skills CLI 支持的其他运行工具。原文给出的命令是：

npx skills add https://github.com/twentyhq/twenty/tree/agent-skills --list

这里的 --list 用于列出可选 skills，不应把运行这条命令等同于已经完成全部安装。还有一个发布前提：agent-skills 分支由 main 首次成功发布后创建；在此之前，原文要求使用本地构建说明。仓库中的 SKILLS.md 则解释其他 skill 类别及适用人群。

部署有两条路径。托管服务宣称可以在一分钟内创建工作区，不用管理基础设施，并持续保持更新；自行部署则支持 Docker Compose，也提供本地开发指南。

技术栈也比较清晰：后端是 NestJS、BullMQ、PostgreSQL 和 Redis；前端是 React、Jotai、Linaria 和 Lingui。这能帮助团队初步判断维护门槛，但熟悉框架并不等于熟悉整个 CRM 的数据与权限模型。

我的判断

我认可它把 CRM 定制纳入代码管理的方向。相比不断堆叠后台配置，代码定义更有机会进入评审和版本管理；相比从零开发 CRM，它又提供了对象、视图和工作流等基础能力。

代价也很明确：团队需要学习 Twenty 的 SDK、发布机制和扩展边界。业务简单、主要依赖运营人员配置的团队，未必能从代码定制中获得足够收益。

原文自称「#1 Open-Source CRM」，但没有提供排名口径，也没有给出性能、交付效率或维护成本的对照数据。托管工作区一分钟内就绪，也只是环境启动速度，不能当成业务落地速度。当前材料适合用于筛选候选方案，还不足以支撑选型结论。

能拿来做什么

• 用 create-twenty-app 做一个最小商机应用，跑通对象定义和私有发布，再检查新增、修改字段时已有数据如何处理。
• 如果团队使用 Claude Code、Codex 或 Cursor，可以先列出官方 skills，确认分支可用，再用一个明确的小需求检验它们能提供多少有效指导。
• 前端和全栈团队可以按现有技术栈评估维护能力，同时核查权限、数据迁移和发布回滚；这些关键问题在原文中没有说清。
• 在托管服务与 Docker Compose 之间做选择时，把工作区启动和业务交付分开评估，先验证自己的核心流程能否实现。