Atomic CRM 是一个功能完整的客户关系管理（CRM）系统，由 Marmelab 开发并开源。你可以在 在线演示 中直接体验。
定制一套CRM到底要烧多少钱？答案可能低到让你想骂人！
试试这个开源CRM框架，它让定制客户管理系统变得跟搭积木一样简单，而且数据完全归你管！
摘要：市面上CRM要么贵得离谱，要么定制起来难如登天。一个叫Atomic CRM的开源项目正在打破这个僵局。它基于React和Supabase构建，提供联系人管理、销售看板、任务提醒等全套功能，更关键的是，它允许开发者用代码自由定制每一个细节。本文将拆解这个框架的设计逻辑、技术选型以及它如何改变中小团队对CRM的认知。
买来的CRM为什么总像一双不合脚的鞋
花几万块买一套现成的客户管理系统，结果发现里面的字段、流程、报表全是别人家的逻辑。你的销售团队要记的是“客户行业”，系统里只有“客户类型”下拉框。你的跟进节奏是每周一次电话，系统默认的提醒是每两周发一封邮件。
于是你开始妥协。用备注字段记行业信息，用日历事件代替系统提醒，用Excel导出再加工做报表。一套CRM用下来，真正顺手的只有登录页面的公司Logo。
这不是你一个人的遭遇。市面上面向中小团队的现成CRM解决方案，像SuiteCRM、Odoo、OroCRM、Vtiger，普遍存在一个问题：功能堆得越多，离你的真实业务就越远。它们试图用一个模子套住所有行业的所有公司，结果就是每个人都穿了一双不合脚的鞋。
那自己开发一套呢？找外包团队报价，少则十几万，多则上百万。养一个内部开发团队，光是招人、磨合、搭基建就要耗掉大半年。对于中小公司来说，这个成本根本算不过来。
这中间有没有一条路：既不用花几十万从零开发，又不用忍受现成产品的各种别扭？
有一家叫Marmelab的法国软件咨询公司，自己做了一套内部用的CRM，用着用着发现，这东西也许能帮到更多人。于是他们在2024年9月把它开源了出来，取名叫Atomic CRM。到今天，这个项目在GitHub上已经攒了超过1100颗星。
开箱即用的功能已经覆盖了大部分日常
Atomic CRM拿过来就能跑。联系人管理、任务和提醒、笔记记录、数据导入导出、交易看板、活动历史，这几样东西组成了一个CRM该有的骨架。
联系人管理把所有客户信息放在一个地方，找起来不用翻三个Excel文件。任务和提醒让你不会漏掉该打的电话、该发的报价。笔记功能随手记下跟客户聊到的关键信息，不用再贴满桌面的便利贴。
这些功能没什么花哨的，但每一件都是销售和客服团队每天都要干的事。
真正有意思的是它处理邮件的方式。把Atomic CRM的邮箱地址放在邮件抄送栏里，系统会自动把邮件内容保存成一条笔记。这意味着你跟客户的每一封往来邮件，不用手动复制粘贴，自动就归档到了对应的联系人下面。
交易管理用的是一个可拖拽的看板。销售团队可以直观地看到每个客户走到了哪个阶段，哪些交易卡住了，哪些快成交了。
如果你觉得这些还不够，它提供了一个完整的API接口，可以跟公司里其他的系统打通。
这些功能听起来跟其他CRM没什么两样。但区别在于，其他CRM的功能是焊死的，Atomic CRM的功能是可以用螺丝刀拧开、换掉的。
从react-admin到shadcn/ui的一次重大转身
Atomic CRM的前端经历过一次不小的手术。
最早的时候，它跑在Marmelab自己开发的react-admin框架上。react-admin提供了超过230个钩子和组件，用来搭建后台管理界面非常高效。但react-admin用的是Material UI组件库，界面风格偏厚重。
2026年3月，Atomic CRM发布v1.5.0版本，做了一次底层换血。前端框架从react-admin切到了Shadcn Admin Kit，UI组件库从Material UI换成了shadcn/ui。
这相当于给一栋楼换了地基，但住里面的人几乎感觉不到。因为两个框架共享同样的架构和API，迁移过程相对平滑。切完之后，界面变得更轻、更现代，定制起来也更灵活。
现在的技术栈长这样：前端是React加TypeScript，UI层是shadcn/ui配合Tailwind CSS，应用层跑在Shadcn Admin Kit上，数据层用TanStack Query做请求管理，后端和数据库全部托管在Supabase上。
Supabase是一个开源的火柴人替代品，底层是PostgreSQL数据库。它自动生成REST API，还能实时推送数据变更。本地开发的时候，用Docker把整个Supabase环境跑起来，数据库、认证、存储全都有了。
这套组合拳打下来，开发者拿到的是一个完整的、可运行的、带真实后端数据的CRM系统，而不是那种只有前端界面、数据全是假的那种Demo。
每一行代码你都可以改
这是Atomic CRM跟其他开源CRM最不一样的地方。
很多开源CRM说的是“开源”，但核心逻辑写在加密的文件里，或者依赖一个你改不了的闭源引擎。Atomic CRM不一样，它的数据库schema、前端组件、API路由、认证逻辑，全部摊在你面前。
想加一个字段？比如在联系人表里加一个“推荐人”字段。步骤很清晰：去Supabase的数据库管理界面给contacts表加一列，更新contacts_summary视图让新字段能被查询到，然后在前端的TypeScript类型定义里加上这个字段，最后在联系人的表单和详情页里把输入框加上。
整个过程需要你懂一点SQL和React，但不需要你是架构师级别的高手。
想改颜色和间距？主题配置在CRM组件上直接传参就行。想换掉某个组件？Atomic CRM的架构是组件化的，你可以把任何一个部分替换成自己的实现。想加一个全新的页面？在应用路由里注册就行。
这种程度的开放性，意味着你可以把Atomic CRM改造成任何你想要的样子。它既是一个开箱即用的应用程序，又是一个可以无限延伸的框架。
当然，代价是你得有TypeScript和React的编程能力，因为这里没有那种点一点鼠标就能配置好的图形界面。
部署到生产环境只需要几条命令
本地跑起来很容易。克隆仓库，运行make install安装依赖，再运行make start启动服务。make install会把前端依赖和本地Supabase环境全部搞定，包括用Docker拉起一个PostgreSQL数据库。
启动之后，前端跑在5173端口，Supabase的管理面板在54323端口，API在54321端口。
部署到生产环境，官方推荐用Supabase.com托管后端，GitHub Pages托管前端。先执行make supabase-remote-init在远程Supabase创建实例，然后运行make deploy，它会自动应用数据库迁移、部署边缘函数、构建前端并推送到gh-pages分支。
你也可以把前端部署到任何CDN，比如CloudFlare、Netlify、Vercel。后端也可以自己托管Supabase实例，数据完全掌握在自己手里。
这种部署方式意味着，你不需要买昂贵的专用服务器，不需要配置复杂的运维流水线，一个Supabase账号加一个GitHub仓库就够了。
但这件事真的适合所有人吗？
Atomic CRM的GitHub仓库里有一个文件叫AGENTS.md。这个文件不是写给人类看的，是写给AI看的。
Marmelab团队给Atomic CRM配了一套AI工具链。他们开发了一个Agent Harness，里面有一组专门针对这个项目的Claude Code智能体：规划师、开发者、审核员、文档员。你只需要用大白话描述一个新功能需求，这些AI智能体会按照一个确定性的流水线，把需求变成可以提交的代码。
他们还做了一个MCP服务器，让你可以在Claude Desktop或者Visual Studio Code里直接用自然语言跟CRM数据对话。比如你可以说“帮我查一下上周新增了哪些客户”，AI就会去数据库里查出来告诉你。
Marmelab团队自己每天都在用Claude Code写Atomic CRM的代码。他们说，有了文档的一次性工具调用，Claude就不会再根据两个大版本前的知识瞎编API签名了。
这听起来很酷。但问题是，AI生成的代码你敢直接往生产环境推吗？这些智能体写出来的东西，谁来审核？如果AI理解错了你的业务逻辑，改出来的功能跑不通，谁来修？
Marmelab的回应是：这些AI工具是辅助，不是替代。最终的代码审查、测试、部署，还是得由人来做。但至少，AI帮你把80%的重复劳动干掉了。
2026年3月发布的v1.5.0版本里，有一个不起眼的改动：表名contactNotes改成了contact_notes，dealNotes改成了deal_notes。这种命名规范的变化，看起来只是代码洁癖。但仔细想，一个开源项目愿意为了更好的可维护性去改表名、改字段名、改API契约，说明它的维护者是认真在对待这个项目的长期健康。
问题在于，当你的业务越跑越复杂，自定义的字段越来越多，分支越拉越深，你还能不能跟上上游的更新？Shadcn Registry提供了组件更新的机制，但如果你改过那些组件，更新的时候冲突怎么解决？
Atomic CRM解决了“定制难”的问题，但它解决不了“维护难”的问题。
而后者，才是每一个决定自己动手的人，真正需要想清楚的。