1. 从销售团队的抱怨说起为什么通用CRM总差那么一口气飞致云这家公司做开源项目的人应该不陌生JumpServer、DataEase、MeterSphere这些项目在圈子里口碑都不错。但今天不聊他们的开源产品聊一件更接地气的事——他们给自己的销售团队做了一套专属的CRM Skills。这个事有意思的地方在于它不是又一个我们做了一个CRM系统的常规叙事而是把AI智能体能力嵌进了CRM的日常操作里让销售流程从人找信息变成信息找人。先说一个几乎所有销售团队都遇到过的场景。公司花大价钱上了一套CRM字段设计得密密麻麻客户名称、联系人、商机阶段、预计成交金额、跟进记录、下次联系时间……理论上这套系统应该让管理变得清晰透明。但实际跑起来是什么样销售嫌录入麻烦能拖就拖管理者看到的漏斗数据永远是滞后的、残缺的真正有价值的客户沟通上下文散落在微信聊天记录、邮件、会议纪要里CRM里只剩下干巴巴的已联系三个字。这个问题的本质不是销售懒而是通用CRM的设计逻辑和销售的真实工作流之间存在断层。通用CRM假设销售愿意主动、规范地录入信息但销售的天性是把时间花在能出单的地方。你让他填十个字段他可能只填三个你让他每次沟通后写跟进记录他可能攒到周末一次性补。数据质量一旦崩了CRM就退化成一个昂贵的通讯录。飞致云做这套专属CRM Skills切入的正是这个断层。关键词里的Cordys CRM是他们自研的CRM产品Skills指的是AI智能体技能模块AI智能体是底层能力。把这几个词串起来理解就是在Cordys CRM的基础上针对飞致云自身的销售场景定制了一套AI智能体技能让CRM具备主动理解、主动补全、主动提醒的能力。这套东西适合谁来参考一是正在用CRM但数据质量堪忧的销售管理者二是想在自己的业务系统里嵌入AI能力的产品和技术团队三是对AI智能体落地场景感兴趣、但看腻了demo想看点真实工程实践的开发者。我见过太多AICRM的方案停留在PPT层面要么是加一个聊天框让AI回答本月销售额多少要么是做一个花哨的客户画像看板但数据源根本喂不进去。飞致云这套Skills的价值在于它是面向自身销售场景打磨出来的不是通用产品这意味着它必须解决真实业务里的脏活累活。下面我会从场景拆解、技术选型、Skills设计、落地踩坑几个维度把这套东西掰开揉碎讲清楚。2. 销售场景里那些说不清道不明的需求才是Skills的靶心2.1 通用CRM的三个结构性缺陷要理解专属Skills为什么有必要得先看清楚通用CRM到底哪里不够用。我把它归纳为三个结构性缺陷这三个缺陷不是靠加字段、加报表能解决的。第一个缺陷是录入的被动性。通用CRM的所有数据入口都依赖人工触发——销售主动新建客户、主动更新阶段、主动写跟进记录。但销售的工作节奏是碎片化的一通电话打完可能马上要接下一个一场会议结束可能立刻要赶去下一个场地。在这种节奏下要求销售停下来打开CRM、找到对应客户、填写结构化字段本身就是反人性的。结果就是数据录入严重滞后管理者看到的永远是过去时。第二个缺陷是上下文的丢失。销售和客户之间的沟通是连续的、多模态的——微信语音、邮件往来、线下会议、电话沟通。通用CRM只能记录最终的结构化结果比如商机阶段从初步接触推进到方案报价但推进的原因、客户的真实顾虑、竞争对手的动态这些关键上下文全部丢失在系统之外。下一个接手的人或者管理者想了解情况只能再去问销售而销售的记忆本身也是模糊的。第三个缺陷是动作的割裂。通用CRM告诉你这个客户三天没跟进了但它不会告诉你该跟进了而且根据上次沟通记录你应该重点回应客户对部署成本的顾虑。前者是提醒后者是建议。通用CRM只能做到前者因为它不理解业务语义不知道部署成本对这个客户意味着什么。2.2 飞致云销售场景的特殊性飞致云不是一家卖标准品的公司它的销售场景有几个鲜明特点这些特点决定了它不能直接套用市面上的通用CRM方案。首先是产品线复杂。JumpServer是堡垒机、DataEase是BI工具、MeterSphere是测试平台每条产品线的目标客户、决策链条、竞争格局都不一样。一个销售可能同时跟多个产品线的商机每个商机需要了解的技术细节和商务策略完全不同。通用CRM的字段体系很难同时适配多条产品线的差异化需求。其次是开源产品的销售逻辑特殊。飞致云的产品都有开源版本这意味着客户可能已经在用社区版销售面对的是一个已经了解产品但需要说服付费的场景。这和从零介绍产品的销售逻辑完全不同。销售需要知道客户用的是哪个版本、社区活跃度如何、有没有提过issue、有没有在社区里表达过对某些功能的诉求。这些信息散落在GitHub、社区论坛、工单系统里通用CRM根本接不住。第三是决策链条长且技术导向。飞致云的目标客户以中大型企业的技术团队为主决策往往涉及运维负责人、架构师、采购、甚至CTO。每个角色的关注点不同——运维关心稳定性架构师关心集成能力采购关心价格CTO关心整体技术栈的匹配度。销售需要针对不同角色准备不同的沟通材料这个准备工作如果全靠人工效率极低。2.3 Skills要解决的核心问题定义基于上面的分析飞致云这套CRM Skills要解决的核心问题可以定义为三个层次。第一层是自动补全。销售不需要手动录入所有信息Skills能够从销售与客户的沟通记录中自动提取关键信息补全到CRM的对应字段里。比如从一封邮件里识别出客户提到的预算范围、决策时间节点、技术顾虑自动填充到商机备注里。第二层是上下文重建。Skills能够把散落在不同渠道的沟通信息聚合起来形成一个连续的客户上下文。销售打开一个客户卡片看到的不是零散的跟进记录而是一条完整的时间线包含每次沟通的要点、客户的反馈、待办事项。第三层是动作建议。Skills不只是提醒该跟进了而是基于客户上下文给出具体的跟进建议——该联系谁、该说什么、该准备什么材料。这就把CRM从一个记录系统变成了一个辅助决策系统。这里要强调一点这三个层次是递进关系不是并列关系。没有第一层的数据质量第二层的上下文就是空中楼阁没有第二层的上下文第三层的建议就是瞎猜。很多AICRM的方案失败就是因为跳过了前两层直接做第三层结果AI给出的建议脱离实际销售用两次就不信了。3. 为什么是Skills而不是一个大而全的AI助手3.1 从万能助手到技能模块的思路转变早期做AICRM的方案很多团队的第一反应是做一个销售AI助手——一个聊天窗口销售可以问它任何问题它来回答。这个思路听起来很美但落地效果普遍不好。原因很简单销售的问题太发散了AI的回答质量参差不齐一旦有几次答非所问销售就再也不用了。飞致云选择Skills路线本质上是把一个万能助手拆成一组专用技能。每个Skill只做一件具体的事做深做透。比如从会议纪要提取商机信息是一个Skill根据客户历史沟通生成跟进话术是另一个Skill识别商机风险信号又是一个Skill。这种拆法的好处是每个Skill的输入输出边界清晰质量可控销售用起来心里有底——他知道这个Skill能干什么、不能干什么。这其实和人类团队的分工逻辑是一样的。你不会招一个什么都懂的销售你会招一个擅长打新客户的销售和一个擅长维护大客户的销售。Skills就是这个逻辑在AI层面的映射。3.2 Skills的粒度设计多大算合适粒度设计是Skills落地最关键的决策之一。粒度太粗一个Skill承担太多职责质量不可控粒度太细Skills数量爆炸销售记不住也用不过来。飞致云的做法我理解是遵循了单一职责场景闭环的原则。所谓单一职责就是一个Skill只解决一个明确的问题。所谓场景闭环就是这个Skill的输出能够直接支撑销售的下一个动作不需要销售再做二次加工。举个例子。会议纪要信息提取这个Skill输入是一段会议录音转写文本或会议纪要输出是结构化的商机信息——客户提到的需求点、顾虑点、决策时间、参与人角色。这个Skill的职责很单一就是提取。但它的输出是闭环的因为提取出来的信息可以直接更新到CRM里销售不需要再手动整理。反过来如果做一个客户全生命周期管理的Skill那就太粗了。它要处理从线索到成交的所有环节每个环节的逻辑都不一样AI很难做好。这种粒度就是失败的。3.3 和Cordys CRM的耦合方式Skills不是独立存在的它必须和Cordys CRM深度耦合。这里的耦合有两个层面。数据层面的耦合Skills需要读取CRM里的客户信息、商机信息、历史沟通记录作为输入也需要把处理结果写回CRM。这就要求CRM的数据模型设计得足够灵活能够承载Skills产生的结构化信息。如果CRM的字段是写死的Skills提取出来的新维度信息就无处存放。交互层面的耦合Skills的触发时机很关键。是销售主动点击触发还是系统根据某些条件自动触发飞致云的做法我推测是两者结合——关键节点自动触发比如会议结束后自动提取纪要日常操作手动触发比如销售想生成跟进话术时主动调用。自动触发的好处是减少销售的认知负担但要注意不能过度打扰否则销售会觉得烦。实操心得Skills和CRM的耦合不要追求一步到位。我见过一些团队一开始就想把Skills嵌入到CRM的每个操作节点结果系统变得极其复杂销售根本搞不清楚什么时候该用什么。更务实的做法是先做几个高频场景的Skills跑通之后再逐步扩展。4. 拆解几个核心Skill的实现逻辑4.1 沟通记录结构化从非结构化文本到CRM字段这是最基础也是最关键的一个Skill。销售和客户的沟通记录可能是邮件、微信聊天记录、会议纪要、电话录音转写格式五花八门。这个Skill要做的就是把这些非结构化文本变成CRM里的结构化字段。实现逻辑上我理解分三步走。第一步是信息抽取用大模型从文本里识别出关键实体和关系——客户名称、联系人、提到的产品、预算数字、时间节点、顾虑点。第二步是字段映射把抽取出来的信息映射到CRM的对应字段上。这里有个难点同一个信息可能有多种表达方式比如预算大概在五十万左右和我们今年这块的投入预算是50W需要归一化处理。第三步是置信度评估对于抽取置信度低的信息不直接写入CRM而是标记出来让销售确认。这里有个容易踩的坑不要追求100%的自动填充。有些团队为了让演示效果好把所有抽取结果都自动写入结果错误信息混进CRM销售还得花时间清理反而增加了工作量。正确的做法是设置一个置信度阈值高于阈值的自动写入低于阈值的进入待确认队列。飞致云作为一家工程文化很强的公司我猜他们在这一点上应该是比较克制的。4.2 商机风险识别让AI学会看危险信号这个Skill的价值在于提前预警。销售在跟进商机的过程中有些风险信号是隐性的销售自己可能都没意识到。比如客户突然减少了沟通频率、邮件回复变慢、开始询问竞品信息、关键决策人不再参与会议。这些信号单独看可能没什么但组合起来就是危险信号。这个Skill的实现逻辑是规则模型的混合方案。规则部分处理明确的信号比如超过14天没有沟通记录、商机阶段停留超过30天、客户明确提到竞品名称。模型部分处理模糊的信号比如沟通语气的变化、邮件回复时长的趋势、会议参与人的变化。两部分结合给出一个风险评分和风险原因说明。我特别想说的是风险识别Skill的输出不能只是一个分数。销售看到风险评分85分是懵的他不知道该干什么。好的输出应该是这个商机存在流失风险主要信号是决策人张总最近三次会议都没参加且客户开始询问竞品A的报价。建议尽快安排一次与张总的一对一沟通重点了解组织内部是否有变化。4.3 跟进话术生成基于上下文的个性化建议这个Skill解决的是该说什么的问题。销售在跟进客户时经常面临不知道说什么的尴尬。尤其是跟进一些进展缓慢的商机硬聊显得刻意不聊又怕客户忘了自己。这个Skill的输入是客户的完整上下文——历史沟通记录、当前商机阶段、客户的关注点、最近的互动情况。输出是一段个性化的跟进话术建议。比如上次沟通时客户提到对部署成本有顾虑可以这样切入王工上次您提到部署成本的问题我们最近刚好有一个针对中小规模部署的优化方案成本可以降低30%左右方便的话我给您详细说说这里的关键是上下文要足够丰富。如果Skill只能看到CRM里的结构化字段生成的话术就会很空洞。它需要能够读取历史沟通记录里的细节理解客户的真实关注点。这也是为什么前面强调沟通记录结构化是基础——没有这个基础话术生成就是无源之水。4.4 多产品线知识注入让Skill懂业务飞致云有多条产品线每条产品线的技术细节、竞争格局、客户痛点都不一样。如果Skills对这些业务知识一无所知生成的内容就会很泛销售一看就知道是AI瞎编的。所以需要有一个知识注入的机制。把每条产品线的核心卖点、常见客户问题、竞品对比、成功案例等知识以结构化的方式注入到Skills的知识库里。当Skill生成话术或建议时能够引用这些业务知识让输出更专业、更贴合实际。这个知识库的维护是个持续工作。产品更新了、竞品出新版本了、有了新的成功案例都需要及时更新到知识库里。我建议指定专人负责知识库的维护并且建立一个反馈机制——销售在使用过程中发现Skill的输出不准确可以一键反馈由专人核实后更新知识库。5. 落地过程中那些文档不会写的坑5.1 数据质量是地基但地基往往是烂的做AICRM最大的幻觉是只要模型够强脏数据也能处理好。实际跑下来你会发现数据质量差到一定程度再强的模型也救不回来。飞致云在落地这套Skills之前肯定花了大量精力做数据清洗和规范化。具体来说有几个数据问题特别致命。一是客户名称不统一同一个客户在CRM里可能有XX科技有限公司、XX科技、XX公司三个版本导致Skills无法关联上下文。二是沟通记录缺失很多销售根本不写跟进记录Skills没有输入自然没有输出。三是字段填写随意商机阶段乱标、金额随便填导致Skills的判断依据不可靠。解决这些问题没有捷径就是治理激励。治理层面做数据清洗、建立字段填写规范、设置必填项校验。激励层面把CRM数据质量和销售的绩效挂钩让销售意识到填好CRM对自己有好处。飞致云作为一家内部推行这套系统的公司我猜他们在推行初期也经历过销售的抵触这个坎必须过。5.2 销售不信任AI建议怎么办这是所有AI销售场景都会遇到的问题。销售会觉得AI懂什么销售我干了十年销售还需要它教我这种抵触情绪如果不解决Skills做得再好也没人用。飞致云的策略我推测是从辅助性场景切入而不是替代性场景。什么意思就是先做那些销售本来就要做但很烦的事情比如整理会议纪要、填写跟进记录、查找客户历史信息。这些事情销售自己做要花时间AI做了销售直接受益抵触情绪就小。等销售习惯了AI的辅助再逐步引入建议性的功能比如风险预警、话术建议。另一个关键是可解释性。AI给出一个建议要告诉销售为什么这么建议。比如风险预警不能只说这个商机有风险要说因为决策人最近三次会议都没参加且客户开始询问竞品报价。销售看到具体的依据才会认真考虑这个建议。5.3 模型成本和响应速度的平衡Skills背后是大模型调用每次调用都有成本而且响应需要时间。如果销售每次打开客户卡片都要等好几秒才能看到AI生成的内容体验就会很差。飞致云的做法我理解是分级处理。高频、轻量的操作走小模型或缓存保证响应速度低频、重量的操作走大模型保证质量。比如客户卡片的上下文摘要可以缓存销售打开时直接展示而跟进话术生成是低频操作可以接受稍长的等待时间。还有一个优化点是预计算。有些Skills的输出不依赖实时输入可以提前算好。比如商机风险评分可以每天凌晨批量计算一次销售白天查看时直接读结果。这样既降低了实时计算的压力又保证了数据的时效性。5.4 和现有工作流的融合问题Skills再好如果和销售现有的工作流不融合就是孤岛。销售不会为了用Skills而改变自己的工作习惯Skills必须嵌入到销售已有的工作流里。飞致云的做法应该是在CRM的关键操作节点嵌入Skills。比如销售打开一个客户卡片时自动展示AI生成的上下文摘要和跟进建议销售写完跟进记录后自动触发信息提取和字段补全销售准备发邮件时自动推荐话术模板。这些嵌入点要选在销售本来就要做某个操作的地方而不是额外增加操作步骤。实操心得嵌入点的选择有个简单的判断标准——如果这个操作销售每天要做超过5次就值得嵌入Skills如果一周才做一次嵌入的优先级就低。把有限的开发资源投入到高频场景上ROI最高。6. 从飞致云这套Skills里能抄走什么6.1 场景优先技术其次飞致云这套Skills最值得学习的地方是它的出发点不是我们有什么AI能力而是销售有什么痛点。先定义清楚要解决什么问题再选择用什么技术。这个顺序不能反。很多团队做AI业务系统上来就研究用什么模型、搭什么架构结果做出来的东西技术很先进但业务不买账。正确的做法是先和业务团队泡在一起看他们每天在干什么、卡在哪里、最烦什么然后针对性地设计Skills。6.2 小步快跑单点突破不要试图一次性做一套完整的AICRM体系。飞致云也是从一个或几个核心Skill开始跑通之后再扩展。先做一个沟通记录结构化的Skill让销售感受到不用手动填CRM了的好处建立信任再逐步增加其他Skill。每个Skill上线后要有明确的衡量指标——使用率、准确率、销售满意度。数据不好就迭代数据好就推广。这种小步快跑的方式比憋大招一次性上线要靠谱得多。6.3 知识库是长期竞争力Skills的模型能力是通用的但注入的业务知识是专属的。飞致云的产品线知识、客户案例、竞品对比这些是别人抄不走的。所以知识库的建设要当成一项长期工程来做持续积累、持续更新。我建议把知识库的维护和销售的日常工作结合起来。销售在跟进客户过程中发现的好话术、好案例、竞品新动态可以随手提交到知识库。这样知识库就是活的而不是一个需要专门花时间维护的负担。6.4 给不同规模团队的建议如果你是一个小团队想参考飞致云的做法我的建议是从最简单的Skill开始。比如先做一个会议纪要自动整理的Skill技术门槛低效果立竿见影。不要一上来就做风险识别、话术生成这些复杂的Skill。如果你是一个中型团队已经有了一定的CRM数据积累可以从沟通记录结构化和上下文摘要这两个Skill入手。这两个Skill是基础做好了之后其他Skill才有发挥空间。如果你是一个大型团队有多条产品线、复杂的销售流程那飞致云这套多产品线知识注入的思路就很值得参考。但要注意复杂度越高越需要专人负责Skills的运营和迭代不能做完就扔在那不管。7. 关于AI智能体落地的一点个人观察我跟踪AI智能体在企业级场景的落地有一段时间了飞致云这套CRM Skills让我比较认可的一点是它的克制。它没有宣称要颠覆销售流程或者替代销售而是老老实实地做辅助——帮销售省时间、帮管理者看全局。这种定位反而更容易落地。我见过太多AI智能体项目死在期望值管理上。一开始吹得天花乱坠业务方期望很高结果上线后发现只能做几件小事落差太大项目就被砍了。飞致云的做法是先把小事做好让业务方感受到实实在在的价值再逐步扩展边界。这个节奏感很重要。另外一点观察是AI智能体在垂直场景的价值远大于通用场景。通用的AI助手谁都能做但针对飞致云销售场景定制的Skills需要深入理解开源产品的销售逻辑、多产品线的协同、技术导向的决策链条。这些领域知识才是壁垒。对于想在AI智能体方向深耕的团队来说选一个垂直场景扎进去比做一个什么都懂一点的通用助手要有前途得多。最后说一个技术之外的体会。飞致云这套Skills能跑起来很大程度上是因为他们是自己用自己的产品——销售团队就在公司内部产品团队可以随时和销售沟通、快速迭代。这种吃自己的狗粮的模式是AI智能体落地最理想的环境。如果你所在的公司没有这种条件那就要想办法建立类似的反馈闭环比如指定几个销售作为种子用户深度参与Skills的设计和迭代。没有真实用户的持续反馈AI智能体很难做好。