最近在忙一件事：给公司搭一套系统。
想要的东西说起来很朴素：客户从哪来、谁去接待、服务完谁记账，这些事能在同一个地方看到。
听起来像是个买来的活儿。我一开始也这么想，去市面上一圈一圈地扒，扒完之后发现根本不是。
这篇不推荐任何产品。我把扒出来的判断写下来，你要是也在挑，可能省你几天时间。
先搞清楚”系统”这个词的三种意思
我一开始就把这三类东西混着比，比到后面发现根本不在一个维度上：
| 类型 | 它是什么 | 你买到的是 |
|---|---|---|
| 垂直业务系统 | 某一件事的完整解法，开箱即用 | 一间装好的样品房，房型固定 |
| 通用开发底座 | 后台、权限、多租户、各类业务模块 | 毛坯地基加全套管线 |
| 内容站系统 | 内容和流量入口 | 前台门面，接得住留资 |
第一类最省事，也最容易卡死。第二类最灵活，但要自己长肉。第三类不适合承载业务，却是我最后认为最该先做的。
一、垂直系统：房间装好了，但你不能改墙
这类东西的好处很直接，客户进来、打标签、分配跟进，全都有现成的，装上就能用。
我卡住的地方在于，它是围绕”一个渠道”长出来的。换渠道、换接待策略、换话术逻辑，全都要动它的代码。
更麻烦的是我怎么都问不出它的边界在哪：官网抓不出正文，也没有公开价目，得找客服要。一个定价不透明的工具，当临时工具用没问题，当长期地基，我下不去手。
还有件事让我警觉。我顺手把上游那个渠道的官方文档摸了一遍，发现它的能力是收紧趋势的：接口分批限流，长期不活跃的应用连客户信息都拿不到；聊天记录类的数据只能回拉几天，而且必须客户本人同意；自动应答还有时间和条数上的硬顶。
也就是说，你把生意建在这一层上，你的天花板不取决于你多努力，取决于上游哪天改规则。
二、通用底座：能长多大，全看你自己
这类是我最有兴趣的一类，因为它给的是地基，不是房子。
我重点看了它的授权方式和模块清单，有三个发现：
第一，协议宽松到几乎没限制。个人用、企业用、拿来改、拿来卖，都不用付钱，连署名都不用留。作者还公开说过不会出商业版。这对想做产品的人是好消息：你不用担心上游哪天推出一个比你便宜的同款。
第二，它原生支持多租户。一套代码，多个客户各看各的数据。这是”一套系统卖给多个客户”从技术上能不能成立的分水岭。不过我查到两个它自己承认的坑：有些手写的数据库查询不会自动带上租户条件，还有前端那部分没适配独立域名。真要做多客户交付，这两处得自己兜住。
第三，也是最重要的一条：它不解决”客户从哪来”。
这条我一开始没意识到。我以为”客户管理”就等于”获客”。看进去才发现，它的客户管理是给内部销售用的，管的是商机、合同、回款。至于渠道二维码、加好友、跟客户聊天的记录，它一个都没有，官方文档里也看不到计划。
我甚至翻到它的说明里直接写着这块业务可以外包：官方自己就是把这块当生意在接的。
所以选它，等于你接受了：获客这一层得自己造。
三、通用底座带的那堆模块，能当企业级用吗？
这也是我纠结最久的地方。它的模块清单确实长，人力、财务、仓储、生产、办公都有，看名字一套完整的企业系统该有的都有。
但”能跑起来”和”能扛真实业务”中间隔着几条沟，我至少量出来四条：
财务这一关最难过。真企业的财务不是记记账，是多主体的核算规则、税务口径、成本怎么分、报表怎么合。它的财务模块自己写的是”轻量”。这个词在企业客户面前是要被追问的。
第二关是模块之间通不通。理想状态下，签了合同应该自动带出采购、入库、出库、开票、应收、凭证，这一串在成熟的老牌系统里是连贯的。它这边是模块并列，看着很全，但中间那些连接点大概率要自己接。我打个比方：你买到的是一箱零件，不是一台机器。
第三关是合规和兜底。审计日志要到什么颗粒度、数据怎么分级、出事之后找谁，这些是企业选型最先问的。它这块是空的，因为作者压根不卖这个，出问题只能去提问或者找人外包。
第四关是行业深度。批次怎么追溯、多个计量单位怎么换算、不同生产类型的工单怎么排，这些是通用模板给不了的，是靠一个行业一个行业熬出来的。
所以我的结论是：它是骨架，不是成品。
这直接影响你怎么对外说。如果打算拿它做交付，最好别打”企业级”这三个字，会招来一堆你答不上来的提问。说成”轻量的进销存””项目型管理””行业小系统”，反而更准，也更好卖。而企业客户真正会付钱的，是骨架之外那层肉，也就是实施、适配、兜底，还有把模块串起来的那部分工作。
四、最后定了：四层，各干各的
扒完之后我放弃了”找一个万能系统”的想法，改成搭四层：
业务层：通用底座。管数据怎么存、怎么流，一套代码支撑多个客户。
智能层：我自己养的智能体。判断、接待、跟进、写内容，这些是”谁来干活”。
入口层：内容站。负责被搜到、接住留资，把线索送进业务层。
内容资产层：短剧这类单独成线，不跟上面三层搅在一起。
为什么不一层全包？因为把智能写死在一套业务系统里，你想换策略、换渠道，就得改人家的代码。分开之后，换哪一层都不动其他层。
层与层之间只走接口，不做代码级合并。这里有个细节值得说：底座的多租户是数据层面的（每条数据打个租户标记），我的智能体那层是容器层面的（一个客户一套独立环境）。两套机制不通用，中间得专门写一层做映射，这是躲不掉的工作量。
五、六个方向，我排了个先后
方向上我想要六个：获客、销售、客服、内容运营、短剧、数据分析。但真按顺序做，我不会一起上。
| 方向 | 难度 | 能不能马上见到东西 |
|---|---|---|
| 客服 | 低 | 能，最快 |
| 内容运营 | 低 | 能，我本来就在做 |
| 数据分析 | 中 | 能，较快 |
| 销售 | 中偏上 | 要开发，和获客连着做 |
| 获客 | 高 | 要开发，而且最贵 |
| 短剧 | 高 | 慢，单独一条线 |
顺序上我先动客服。理由不复杂：它不需要碰任何平台的红线，用底座自己的沟通模块加上我的智能体，当天就能跑出一个能给人看的东西。
然后是内容到线索这条闭环。这一步我特意绕开了平台渠道：内容站被搜到、读者留个信息、线索进业务层、智能体去跟进。整条链子全在自己手里，没有一条依赖别人开的接口。等这条跑顺了，再去考虑那些更重更贵的渠道。
这里有个原则我想强调一下：获客、销售、客服其实是同一份数据在三个阶段，拆开做等于做三遍。它们应该连体。而内容和短剧跟这条数据流没什么交集，就单独开线，别让它们拖住主线。
六、两条底线，写在最前面
不管最后选哪条路，有两件事我从一开始就划了线。
第一条是客户数据的合规。跟客户聊天产生的记录，不是你想存就能存的，得客户本人点头，能回看的时间也有限。换个服务商，同一个客户在两边的编号可能都对不上。这不是技术问题，是这套玩法自带的约束，绕不开，只能按规矩设计。
第二条是别碰非官方协议。网上有一批东西打着”不受限制””不会封”的旗号，走的都是官方没开的口子。这种把业务建上去，风险全是自己的。我不碰。
说在最后
这轮下来我最大的收获，其实是想清楚了一件事：没有一套系统能同时给你骨架和肌肉。
骨架可以买，甚至可以不花钱买。肌肉是你自己的业务理解，别人替不了。
想清楚哪层买、哪层造、哪层别碰，这件事本身比选哪个产品值钱得多。
我是俊，一个还在用 AI 做产品、也还在学着把系统想清楚再动手的程序员。
