[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-837":3,"consumer-news-interaction-837":38,"consumer-news-related-837":41},{"detail":4,"item":34},{"card":5,"schemaVersion":21,"fields":22,"content":28},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":14,"href":15,"sourceName":12,"meta":16,"metrics":18,"tags":19,"resolved":20},"NEWS_ARTICLE:837","news","NEWS_ARTICLE",837,"资讯","很多B2B的生态合作，都是在带薪休假","博客园","有一种 B2B 生态工作，我把它叫作“带薪休假式生态”。 公司搭建了生态岗位，或者要求区域销售顺便拓展伙伴，管理层给了一个结果目标： 发展多少家伙伴，带来多少条线索，创造多少商机。 但应该找谁、为什么找、先找谁、每家公司投入多少精力、什么情况下继续、什么情况下停止，没有人说得清楚。 于是，生态人员只","","\u002Fnews\u002F837",[17],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":23,"summary":13,"description":13,"publishTime":24,"updateTime":25,"sourceUrl":26,"language":27},"付一然的ToB增长笔记","2026-09-02T13:55","2026-09-02T20:37:48","https:\u002F\u002Fwww.cnblogs.com\u002Ffyia7788\u002Fp\u002F22806779","中文",{"format":29,"policy":30,"normalized":20,"html":31,"text":32,"wordCount":33,"hasBody":20},"HTML","NEWS_CONTENT_V1","\u003Cp>有一种 B2B 生态工作，我把它叫作“带薪休假式生态”。\u003C\u002Fp>\n\u003Cp>公司搭建了生态岗位，或者要求区域销售顺便拓展伙伴，管理层给了一个结果目标：\u003C\u002Fp>\n\u003Cp>发展多少家伙伴，带来多少条线索，创造多少商机。\u003C\u002Fp>\n\u003Cp>但应该找谁、为什么找、先找谁、每家公司投入多少精力、什么情况下继续、什么情况下停止，没有人说得清楚。\u003C\u002Fp>\n\u003Cp>于是，生态人员只能凭感觉安排行程。\u003C\u002Fp>\n\u003Cp>谁回复得快，就多聊几次；谁性格投缘，就多走动；谁愿意一起喝茶吃饭，就把更多时间花在谁身上。\u003C\u002Fp>\n\u003Cp>每周行程排得满满当当，活动参加了不少，微信也加了一堆人。大家见面互相介绍业务，在群里点赞，在朋友圈互动，气氛非常融洽。\u003C\u002Fp>\n\u003Cp>最后回头一看：\u003C\u002Fp>\n\u003Cp>伙伴很好聊天，客户一个没来；情绪价值拉满，业务价值为零。\u003C\u002Fp>\n\u003Cp>这未必是生态人员不努力。\u003C\u002Fp>\n\u003Cp>更大的问题是，公司只有结果要求，却没有过程方法；只告诉他要拓展伙伴，却没有告诉他哪类伙伴值得优先投入。\u003C\u002Fp>\n\u003Cp>没有作战地图，生态工作很容易退化成随机社交。\u003C\u002Fp>\n\u003Cp>一家 B2B 公司想认真做生态，起手动作应该是画出一张伙伴地图。招募伙伴、设计返点、签合作协议，都应该建立在这张地图之上。\u003C\u002Fp>\n\u003Ch2>一、伙伴地图要解决资源投入问题\u003C\u002Fh2>\n\u003Cp>很多公司的伙伴地图，其实只是一张公司名单。\u003C\u002Fp>\n\u003Cp>咨询公司、软件厂商、硬件厂商、协会、媒体、渠道商被分门别类地放进表格，再标注一下联系人、职务和联系方式。\u003C\u002Fp>\n\u003Cp>这样的表格更接近伙伴通讯录。\u003C\u002Fp>\n\u003Cp>一张能用的伙伴地图，至少要回答几个问题：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>谁更可能把我们带到目标客户面前？\u003C\u002Fli>\n \u003Cli>谁会在服务客户的过程中，稳定遇到与我们相关的需求？\u003C\u002Fli>\n \u003Cli>谁拥有客户资源，谁又有能力调动这些资源？\u003C\u002Fli>\n \u003Cli>哪家公司值得继续向下深挖？\u003C\u002Fli>\n \u003Cli>哪家公司经过多轮接触仍然没有具体动作，可以暂时停止投入？\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>地图的价值，在于提供方向和优先级。\u003C\u002Fp>\n\u003Cp>如果所有伙伴在表格里的优先级都一样，生态人员只能根据感觉行动。\u003C\u002Fp>\n\u003Cp>今天和谁聊得开心，就多见谁；明天谁邀请他参加活动，就去谁那里；后天某个大厂发来合作邀请，就临时把资源全部转过去。\u003C\u002Fp>\n\u003Cp>最后，生态工作看起来很忙，实际上没有策略。\u003C\u002Fp>\n\u003Cp>画伙伴地图时，先要完成一个基本判断：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>哪些伙伴更有可能创造客户、商机和项目价值？\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2>二、选择伙伴，先看事实，再看可能性\u003C\u002Fh2>\n\u003Cp>判断一家公司是否值得投入，最直接的办法是回头看历史项目。\u003C\u002Fp>\n\u003Cp>过去的打单和交付过程中，有没有客户同时使用双方的产品？有没有从对方的系统取数或者调用 API？对方有没有搭售、转介绍过我们的产品？有没有把我们的能力放进它的解决方案？\u003C\u002Fp>\n\u003Cp>这些已经发生过的事情，比 PPT 里的“客户群高度重合”更有价值。\u003C\u002Fp>\n\u003Cp>客户群重合代表理论上的可能性。发生过搭售、转介绍、产品集成和联合项目，才能证明双方存在业务互补。\u003C\u002Fp>\n\u003Cp>举个例子。\u003C\u002Fp>\n\u003Cp>一家 AI 制造业销售 Agent 厂商，在服务制造企业时，经常会遇到 AI CAD 需求。\u003C\u002Fp>\n\u003Cp>它自己不做 AI CAD，但为了更专业地响应客户，需要推荐或者集成另一家厂商的产品。\u003C\u002Fp>\n\u003Cp>对于 AI CAD 厂商来说，这类伙伴的价值通常高于一家泛泛的渠道商。客户需求已经出现，伙伴只需要在自己无法满足时，把合适的厂商带进来。\u003C\u002Fp>\n\u003Cp>AI CAD 厂商还可以继续扫描整个赛道：\u003C\u002Fp>\n\u003Cp>哪些厂商正在服务制造企业？哪些厂商经常遇到 CAD 相关需求？哪些厂商自己不准备做，却需要补全方案？过去有没有发生过推荐、集成或者联合交付？\u003C\u002Fp>\n\u003Cp>这里面可能存在一类伙伴的结构性机会。\u003C\u002Fp>\n\u003Cp>类似的情况并不少见。\u003C\u002Fp>\n\u003Cp>OA 厂商服务客户时，经常遇到数据分析和 BI 需求；做业务系统的厂商，可能经常遇到电子签、数据治理或者安全合规需求；咨询公司帮助客户梳理业务时，也会发现自己无法承接的产品和交付机会。\u003C\u002Fp>\n\u003Cp>一类优质伙伴的共同点是：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>他在完成自己业务的过程中，会自然遇到属于你的需求。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>这种需求由伙伴的业务流程带出来，不需要靠介绍费生造。\u003C\u002Fp>\n\u003Cp>所以，已经发生过转介绍、搭售、产品结合和联合项目的伙伴，应该优先于只有客户群重叠的伙伴。\u003C\u002Fp>\n\u003Cp>如果双方还没有合作历史，就要继续判断客户到底重叠在哪里。\u003C\u002Fp>\n\u003Cp>“我们都服务制造业。”\u003C\u002Fp>\n\u003Cp>“我们都做中大型企业。”\u003C\u002Fp>\n\u003Cp>“我们的客户都是数字化负责人。”\u003C\u002Fp>\n\u003Cp>这种判断颗粒度太粗，很难指导行动。\u003C\u002Fp>\n\u003Cp>制造业下面还有汽车零部件、机械装备、化工、电子、医药等大量细分行业；中大型企业的定义也可能完全不同；同样是数字化负责人，面对的场景和预算来源也有很大差别。\u003C\u002Fp>\n\u003Cp>判断客户重叠，至少要继续看：\u003C\u002Fp>\n\u003Cp>双方服务的是不是同一批细分客户？进入客户的部门是否相邻？产品是不是处于同一段工作流程？伙伴能不能接触到我们的采购关键人？客户在购买对方产品时，是否容易自然产生我们的需求？\u003C\u002Fp>\n\u003Cp>对于软件厂商来说，在其他条件接近的情况下，能够形成产品、方案和数据互补的软件同业，通常可以排在只有泛客户资源的硬件伙伴前面。\u003C\u002Fp>\n\u003Cp>原因很现实。\u003C\u002Fp>\n\u003Cp>软件项目往往深入客户的业务流程、组织协同和数据体系。一家长期服务相同客户的软件厂商，更容易理解你的产品解决什么问题，适合嵌入哪一段流程，应该由哪个部门采购，也更容易判断什么时候把你带进项目。\u003C\u002Fp>\n\u003Cp>比如，OA 厂商发现客户仍然依赖人工汇总经营数据，就比较容易识别出 BI 需求；做 CRM 的厂商发现客户销售过程缺少智能分析，也可能自然想到相关 AI 产品。\u003C\u002Fp>\n\u003Cp>它们不仅知道客户是谁，通常也更清楚应该如何向客户介绍你。\u003C\u002Fp>\n\u003Cp>硬件伙伴当然也可能拥有大量客户资源，但从整体来看，他们对软件方案、业务流程和具体场景的理解通常会弱一些。\u003C\u002Fp>\n\u003Cp>有些硬件销售认识采购或者信息化负责人，却不清楚你的软件对应什么业务问题、应该进入哪项预算，以及什么时间适合推荐。\u003C\u002Fp>\n\u003Cp>即使他愿意帮忙，在客户面前也可能只能勉强说一句：\u003C\u002Fp>\n\u003Cp>“我们还有一家软件合作伙伴，你们要不要见一下？”\u003C\u002Fp>\n\u003Cp>这样的推荐缺少具体场景，客户很难产生足够重视。\u003C\u002Fp>\n\u003Cp>理解场景的软件同业，开口方式可能会具体很多：\u003C\u002Fp>\n\u003Cp>“你们现在已经积累了不少业务数据，但经营分析还依赖人工汇总。我们有一家合作伙伴专门解决这一块，可以基于现有系统搭建经营分析和管理驾驶舱。”\u003C\u002Fp>\n\u003Cp>两种推荐的信任程度和后续转化率，差别很大。\u003C\u002Fp>\n\u003Cp>当然，这不是一条绝对规律。\u003C\u002Fp>\n\u003Cp>有些硬件厂商长期扎在客户现场，对客户的业务流程、项目规划和关键人关系非常熟悉；有些软件厂商虽然产品相邻，却缺少客户信任，也没有推荐意愿。\u003C\u002Fp>\n\u003Cp>最终还是要看一件事：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>双方能不能围绕同一批客户，形成一条具体的业务连接？\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2>三、一家公司，要继续向下拆\u003C\u002Fh2>\n\u003Cp>很多生态人员认识了某家公司的一个生态负责人，再加上一两个销售，就认为这家公司已经覆盖了。\u003C\u002Fp>\n\u003Cp>然后赶紧去拓展下一家伙伴。\u003C\u002Fp>\n\u003Cp>但一家公司的销售可能有几十个，甚至几百个。\u003C\u002Fp>\n\u003Cp>不同事业部、区域和行业团队，服务的客户不同，手里的资源不同，近期工作重点不同，对伙伴的诉求也完全不同。\u003C\u002Fp>\n\u003Cp>你认识总部的生态负责人，不等于认识华东区的一线销售。\u003C\u002Fp>\n\u003Cp>你认识某个事业部负责人，不等于其他事业部了解你的产品。\u003C\u002Fp>\n\u003Cp>你和对方高层签了合作协议，也无法保证一线销售会主动向客户推荐你。\u003C\u002Fp>\n\u003Cp>所以，伙伴地图不能停留在公司名称这一层。它还要继续向下拆：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>公司—事业部—区域—行业—角色—具体个人—目标客户\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>当一家公司已经被验证有合作价值，接下来的重点应该是把它继续做深。\u003C\u002Fp>\n\u003Cp>要了解它有哪些事业部，哪些事业部最接近我们的目标客户；不同区域有哪些成熟销售；哪些顾问经常遇到相邻需求；谁愿意推荐我们；谁有能力把我们带进客户；谁只是名义上的对接人。\u003C\u002Fp>\n\u003Cp>大厂尤其如此。\u003C\u002Fp>\n\u003Cp>大厂如果能够从总部或事业部自上而下打通，再把合作传导到一线，杠杆率通常很高；但大厂内部架构复杂，一线销售业绩压力也很大，往往没有精力主动推荐一个与自己目标关系不大的伙伴产品。\u003C\u002Fp>\n\u003Cp>认识大厂高层，不等于掌握大厂资源。还要继续弄清楚：具体哪个事业部能够撬动资源，它当前的诉求是什么，近期工作重心是什么，一线销售为什么愿意带上你。\u003C\u002Fp>\n\u003Cp>有时候，一家没有什么名气的小公司，反而可能是更重要的伙伴。\u003C\u002Fp>\n\u003Cp>它的客户数量未必很多，但几个深耕区域或行业的老销售，与客户建立了长期信任。如果你的产品恰好能补齐他们的方案，他们主动推荐的意愿和能力，可能会带来很大的惊喜。\u003C\u002Fp>\n\u003Cp>大公司的资源上限高，但未必容易调动。\u003C\u002Fp>\n\u003Cp>小公司的资源规模有限，合作链条却可能更短。\u003C\u002Fp>\n\u003Cp>公司名气很重要，但不能代替具体的资源判断。\u003C\u002Fp>\n\u003Ch2>四、公司是资源容器，个人让资源流动\u003C\u002Fh2>\n\u003Cp>公司层面的地图帮助我们判断，谁可能拥有需要的客户资源。\u003C\u002Fp>\n\u003Cp>到了个人层面，要继续判断：\u003C\u002Fp>\n\u003Cp>这些资源能不能流动起来？\u003C\u002Fp>\n\u003Cp>创始人、架构师、产品经理、项目经理、顾问、销售、生态、市场，都有可能成为好的个人伙伴。\u003C\u002Fp>\n\u003Cp>判断一个人的价值，不能只看职位，也不能只看他是否热情。\u003C\u002Fp>\n\u003Cp>更值得关注的是两个问题：\u003C\u002Fp>\n\u003Cp>他是不是经常接触客户？他能不能与甲方关键人直接对话？\u003C\u002Fp>\n\u003Cp>持续接触客户需求的人，通常知道客户最近在推动什么项目、遇到了什么问题、现有方案缺少什么，也知道应该把你介绍给谁。\u003C\u002Fp>\n\u003Cp>只有客户名单的人，优先级可以往后放。\u003C\u002Fp>\n\u003Cp>客户名单只能证明他知道这家公司，无法证明他与客户建立了关系，也无法证明客户愿意听他推荐。\u003C\u002Fp>\n\u003Cp>再往后，才是只有转介绍预算的人。\u003C\u002Fp>\n\u003Cp>市场和生态人员当然也可能成为很好的伙伴。\u003C\u002Fp>\n\u003Cp>但现实中，很多公司的市场和生态手里只有“介绍好处费”，并没有可以介绍给你的客户资源。\u003C\u002Fp>\n\u003Cp>这种伙伴通常很好聊。\u003C\u002Fp>\n\u003Cp>大家建一个社群，轮流介绍我是谁、我服务什么客户、我能提供什么产品。群里气氛不错，大家也可能很喜欢你。\u003C\u002Fp>\n\u003Cp>但几个月过去，没有人能把你带到甲方关键人面前。\u003C\u002Fp>\n\u003Cp>这时，生态工作就很容易变成一场“你好、我好、大家好”的自嗨游戏。\u003C\u002Fp>\n\u003Cp>如果对方自己没有直接客户资源，就继续看他能不能把你带到公司内部掌握资源的老销售、顾问和项目负责人面前。\u003C\u002Fp>\n\u003Cp>只要能连接到一线，他仍然是一个有价值的入口。\u003C\u002Fp>\n\u003Cp>如果既没有客户资源，也无法连接一线，只能告诉你“我们这里有介绍费”，投入就要克制。\u003C\u002Fp>\n\u003Cp>所以，个人伙伴的优先级可以非常直白：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>经常见客户、接触真实需求的人，高于只有客户名单的人；只有客户名单的人，又高于只有转介绍预算的人。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>伙伴价值不取决于他和你聊了多久，而取决于他离客户有多近。\u003C\u002Fp>\n\u003Ch2>五、有些伙伴带不来商机，却能帮助你赢单\u003C\u002Fh2>\n\u003Cp>如果只用“介绍了多少条商机”评价伙伴，会漏掉一类很有价值的人。\u003C\u002Fp>\n\u003Cp>他们未必能直接介绍新客户，却熟悉你正在跟进的客户，也了解项目背后的组织关系。\u003C\u002Fp>\n\u003Cp>在销售打单过程中，他们可能知道：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>客户为什么突然启动这个项目；\u003C\u002Fli>\n \u003Cli>谁是项目的实际发起人；\u003C\u002Fli>\n \u003Cli>谁在内部支持，谁还在犹豫；\u003C\u002Fli>\n \u003Cli>业务部门和信息化部门之间有什么分歧；\u003C\u002Fli>\n \u003Cli>预算已经批了，还是仍在内部争取；\u003C\u002Fli>\n \u003Cli>客户过去做过哪些努力，最后结果怎么样；\u003C\u002Fli>\n \u003Cli>竞争对手已经接触了哪些人；\u003C\u002Fli>\n \u003Cli>客户表面上关心价格，背后更担心什么；\u003C\u002Fli>\n \u003Cli>哪位领导有拍板权，哪位领导只负责流程。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这些信息未必能直接变成一条 CRM 线索，却会显著影响销售策略。\u003C\u002Fp>\n\u003Cp>比如，一位长期服务客户的项目经理告诉你：\u003C\u002Fp>\n\u003Cp>“这个项目虽然是信息化部门牵头，但运营负责人一直觉得现有方案太复杂。下次汇报不要再讲技术架构，重点讲一线人员怎么用。”\u003C\u002Fp>\n\u003Cp>再比如，一位熟悉客户的顾问提醒你：\u003C\u002Fp>\n\u003Cp>“采购流程还没正式开始，现在谈价格太早。客户目前只是在通过方案交流确定立项范围，需要先说服财务负责人。”\u003C\u002Fp>\n\u003Cp>这些情报不会带来新商机，却可能帮助你赢下已经在跟的项目。\u003C\u002Fp>\n\u003Cp>所以，伙伴地图里还应该标注一类角色：\u003C\u002Fp>\n\u003Cp>\u003Cstrong>情报型伙伴。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>判断这类伙伴的价值，可以看几个问题：\u003C\u002Fp>\n\u003Cp>他是否熟悉客户内部组织？是否了解当前项目背景？能不能帮助识别关键人和决策链？能否帮助销售判断客户倾向、竞争态势和下一步动作？\u003C\u002Fp>\n\u003Cp>对于金额较大、决策链复杂的项目，销售甚至可以单独画一张“项目外围伙伴图”。\u003C\u002Fp>\n\u003Cp>客户现有的软件厂商、硬件供应商、咨询顾问、实施服务商、协会联系人以及离职员工，都可能掌握不同的信息。\u003C\u002Fp>\n\u003Cp>有人能带来新客户，有人能帮助你进入关键部门，有人能告诉你客户内部正在发生什么。\u003C\u002Fp>\n\u003Cp>这三种价值都值得被伙伴地图记录。\u003C\u002Fp>\n\u003Ch2>六、先理解对方为什么愿意合作\u003C\u002Fh2>\n\u003Cp>很多公司做生态，首先想到的是设计政策。\u003C\u002Fp>\n\u003Cp>介绍一个客户给多少钱，签单以后返点多少，伙伴分成几个等级，每个等级分别享受什么权益。\u003C\u002Fp>\n\u003Cp>这些政策当然有价值。\u003C\u002Fp>\n\u003Cp>但如果自己没有资源可以介绍给伙伴，只有一笔介绍费，很容易陷入“拿着锤子找钉子”的思维：\u003C\u002Fp>\n\u003Cp>我给你钱，你帮我卖。\u003C\u002Fp>\n\u003Cp>伙伴愿意介绍你，背后可能有很多原因。\u003C\u002Fp>\n\u003Cp>他需要补齐自己的方案，更专业地响应客户；希望提高客单价，增加客户黏性；或者希望通过你的产品进入原来进不去的项目。\u003C\u002Fp>\n\u003Cp>这些业务价值，通常比一笔介绍费更重要。\u003C\u002Fp>\n\u003Cp>很多人嘴上不会直接拒绝介绍费，心里却很反感一上来就谈钱。因为这等于默认，他与客户多年建立的信任，可以被直接标价。\u003C\u002Fp>\n\u003Cp>预算可以准备。\u003C\u002Fp>\n\u003Cp>合作有了进展，可以送礼物、表达感谢，也可以在规则清楚的前提下支付合理回报。\u003C\u002Fp>\n\u003Cp>但在还没有理解对方业务时，别急着把关系处理成一笔交易。\u003C\u002Fp>\n\u003Cp>如果条件允许，最好把自家销售也带上。\u003C\u002Fp>\n\u003Cp>让双方接触客户的一线人员建立联系，了解彼此正在服务什么客户、遇到什么需求、能够提供什么帮助。\u003C\u002Fp>\n\u003Cp>稳定的伙伴关系通常来自一次次互相创造价值，单次返点很难支撑长期合作。\u003C\u002Fp>\n\u003Ch2>七、先从一个轻量动作开始\u003C\u002Fh2>\n\u003Cp>很多公司喜欢从高层见面开始。\u003C\u002Fp>\n\u003Cp>双方签署战略协议，发布联合新闻，再办一场启动会，看起来非常正式。\u003C\u002Fp>\n\u003Cp>但公司级合作的复杂度很高。\u003C\u002Fp>\n\u003Cp>客户归谁，商机怎么分，销售利益如何安排，产品是否集成，项目由谁交付，出现问题谁来负责，每个问题背后都牵涉不同部门。\u003C\u002Fp>\n\u003Cp>很多合作谈得很大，落地时却没有一线人员愿意推动。\u003C\u002Fp>\n\u003Cp>伙伴合作可以先从一个轻量动作开始：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>双方各拿出十家目标客户，一起核对关系；\u003C\u002Fli>\n \u003Cli>请对方介绍一位熟悉行业的一线销售；\u003C\u002Fli>\n \u003Cli>一起拜访某个客户；\u003C\u002Fli>\n \u003Cli>邀请对方顾问参与一次方案讨论；\u003C\u002Fli>\n \u003Cli>出现相邻需求时互相引荐；\u003C\u002Fli>\n \u003Cli>共同复盘一个正在推进的项目；\u003C\u002Fli>\n \u003Cli>请对方帮助补充客户内部情报；\u003C\u002Fli>\n \u003Cli>联合验证一个具体项目。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这些动作投入小、反馈快，也能帮助双方判断合作能力。\u003C\u002Fp>\n\u003Cp>嘴上说有很多客户，不如完成一次引荐。\u003C\u002Fp>\n\u003Cp>反复强调产品互补，不如共同服务一个项目。\u003C\u002Fp>\n\u003Cp>跑过几个具体动作，双方自然会知道资源是否匹配、合作是否顺畅、哪些规则需要补充。等业务连接得到验证，再考虑升级为公司级合作。\u003C\u002Fp>\n\u003Ch2>八、伙伴地图要进入日常管理\u003C\u002Fh2>\n\u003Cp>伙伴地图不能画完以后放进汇报材料。\u003C\u002Fp>\n\u003Cp>它需要进入生态团队的日常管理，持续记录和更新。\u003C\u002Fp>\n\u003Cp>一张基本可用的地图，至少应该包括：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>伙伴所在的公司、事业部、区域和行业；\u003C\u002Fli>\n \u003Cli>双方客户重叠的具体范围；\u003C\u002Fli>\n \u003Cli>可能出现互补需求的场景；\u003C\u002Fli>\n \u003Cli>过去发生过哪些转介绍、搭售、集成和联合项目；\u003C\u002Fli>\n \u003Cli>哪些人掌握客户资源；\u003C\u002Fli>\n \u003Cli>哪些人能够触达客户关键人；\u003C\u002Fli>\n \u003Cli>哪些人熟悉客户内部情况；\u003C\u002Fli>\n \u003Cli>双方正在共同跟进哪些客户和项目；\u003C\u002Fli>\n \u003Cli>下一步准备做什么；\u003C\u002Fli>\n \u003Cli>什么情况下继续投入；\u003C\u002Fli>\n \u003Cli>什么情况下暂时停止。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>有了这些信息，生态人员的行程才不会随意安排。\u003C\u002Fp>\n\u003Cp>已经被历史合作验证的伙伴，可以优先投入；更接近目标客户、经常遇到相关需求的人，可以多花时间；只有泛泛合作意愿、长期没有具体动作的伙伴，可以暂时放下。\u003C\u002Fp>\n\u003Cp>管理层对生态工作的要求，也不能只剩下最终带来多少商机。\u003C\u002Fp>\n\u003Cp>商机有很长的滞后周期。\u003C\u002Fp>\n\u003Cp>如果只有结果，没有过程，生态人员很容易在一段时间内失去方向，最后用拜访数量、活动数量和伙伴签约数量证明自己很忙。\u003C\u002Fp>\n\u003Cp>生态工作的过程，至少应该能看到：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>重点伙伴是否完成了组织下钻；\u003C\u002Fli>\n \u003Cli>是否找到更多一线销售、顾问和项目负责人；\u003C\u002Fli>\n \u003Cli>双方是否完成客户资源盘点；\u003C\u002Fli>\n \u003Cli>是否发生联合拜访；\u003C\u002Fli>\n \u003Cli>是否出现有效转介绍；\u003C\u002Fli>\n \u003Cli>是否为重点项目提供过客户情报；\u003C\u002Fli>\n \u003Cli>原来的伙伴优先级有没有被事实更新。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这些过程不能保证一定产生结果，但它们可以帮助公司判断，生态团队是在接近业务价值，还是只获得了情绪价值。\u003C\u002Fp>\n\u003Cp>B2B 公司的生态资源始终有限，尤其是人的时间有限。\u003C\u002Fp>\n\u003Cp>今天认识谁，下个月深挖谁，哪家公司继续投入，哪家公司暂时放下，都应该是一项可以讨论、可以复盘的业务决策。\u003C\u002Fp>\n\u003Cp>否则，行程再满、活动再多、微信好友再丰富，生态团队也可能只是在带薪休假。\u003C\u002Fp>","有一种 B2B 生态工作，我把它叫作“带薪休假式生态”。 公司搭建了生态岗位，或者要求区域销售顺便拓展伙伴，管理层给了一个结果目标： 发展多少家伙伴，带来多少条线索，创造多少商机。 但应该找谁、为什么找、先找谁、每家公司投入多少精力、什么情况下继续、什么情况下停止，没有人说得清楚。 于是，生态人员只能凭感觉安排行程。 谁回复得快，就多聊几次；谁性格投缘，就多走动；谁愿意一起喝茶吃饭，就把更多时间花在谁身上。 每周行程排得满满当当，活动参加了不少，微信也加了一堆人。大家见面互相介绍业务，在群里点赞，在朋友圈互动，气氛非常融洽。 最后回头一看： 伙伴很好聊天，客户一个没来；情绪价值拉满，业务价值为零。 这未必是生态人员不努力。 更大的问题是，公司只有结果要求，却没有过程方法；只告诉他要拓展伙伴，却没有告诉他哪类伙伴值得优先投入。 没有作战地图，生态工作很容易退化成随机社交。 一家 B2B 公司想认真做生态，起手动作应该是画出一张伙伴地图。招募伙伴、设计返点、签合作协议，都应该建立在这张地图之上。 一、伙伴地图要解决资源投入问题 很多公司的伙伴地图，其实只是一张公司名单。 咨询公司、软件厂商、硬件厂商、协会、媒体、渠道商被分门别类地放进表格，再标注一下联系人、职务和联系方式。 这样的表格更接近伙伴通讯录。 一张能用的伙伴地图，至少要回答几个问题： 谁更可能把我们带到目标客户面前？ 谁会在服务客户的过程中，稳定遇到与我们相关的需求？ 谁拥有客户资源，谁又有能力调动这些资源？ 哪家公司值得继续向下深挖？ 哪家公司经过多轮接触仍然没有具体动作，可以暂时停止投入？ 地图的价值，在于提供方向和优先级。 如果所有伙伴在表格里的优先级都一样，生态人员只能根据感觉行动。 今天和谁聊得开心，就多见谁；明天谁邀请他参加活动，就去谁那里；后天某个大厂发来合作邀请，就临时把资源全部转过去。 最后，生态工作看起来很忙，实际上没有策略。 画伙伴地图时，先要完成一个基本判断： 哪些伙伴更有可能创造客户、商机和项目价值？ 二、选择伙伴，先看事实，再看可能性 判断一家公司是否值得投入，最直接的办法是回头看历史项目。 过去的打单和交付过程中，有没有客户同时使用双方的产品？有没有从对方的系统取数或者调用 API？对方有没有搭售、转介绍过我们的产品？有没有把我们的能力放进它的解决方案？ 这些已经发生过的事情，比 PPT 里的“客户群高度重合”更有价值。 客户群重合代表理论上的可能性。发生过搭售、转介绍、产品集成和联合项目，才能证明双方存在业务互补。 举个例子。 一家 AI 制造业销售 Agent 厂商，在服务制造企业时，经常会遇到 AI CAD 需求。 它自己不做 AI CAD，但为了更专业地响应客户，需要推荐或者集成另一家厂商的产品。 对于 AI CAD 厂商来说，这类伙伴的价值通常高于一家泛泛的渠道商。客户需求已经出现，伙伴只需要在自己无法满足时，把合适的厂商带进来。 AI CAD 厂商还可以继续扫描整个赛道： 哪些厂商正在服务制造企业？哪些厂商经常遇到 CAD 相关需求？哪些厂商自己不准备做，却需要补全方案？过去有没有发生过推荐、集成或者联合交付？ 这里面可能存在一类伙伴的结构性机会。 类似的情况并不少见。 OA 厂商服务客户时，经常遇到数据分析和 BI 需求；做业务系统的厂商，可能经常遇到电子签、数据治理或者安全合规需求；咨询公司帮助客户梳理业务时，也会发现自己无法承接的产品和交付机会。 一类优质伙伴的共同点是： 他在完成自己业务的过程中，会自然遇到属于你的需求。 这种需求由伙伴的业务流程带出来，不需要靠介绍费生造。 所以，已经发生过转介绍、搭售、产品结合和联合项目的伙伴，应该优先于只有客户群重叠的伙伴。 如果双方还没有合作历史，就要继续判断客户到底重叠在哪里。 “我们都服务制造业。” “我们都做中大型企业。” “我们的客户都是数字化负责人。” 这种判断颗粒度太粗，很难指导行动。 制造业下面还有汽车零部件、机械装备、化工、电子、医药等大量细分行业；中大型企业的定义也可能完全不同；同样是数字化负责人，面对的场景和预算来源也有很大差别。 判断客户重叠，至少要继续看： 双方服务的是不是同一批细分客户？进入客户的部门是否相邻？产品是不是处于同一段工作流程？伙伴能不能接触到我们的采购关键人？客户在购买对方产品时，是否容易自然产生我们的需求？ 对于软件厂商来说，在其他条件接近的情况下，能够形成产品、方案和数据互补的软件同业，通常可以排在只有泛客户资源的硬件伙伴前面。 原因很现实。 软件项目往往深入客户的业务流程、组织协同和数据体系。一家长期服务相同客户的软件厂商，更容易理解你的产品解决什么问题，适合嵌入哪一段流程，应该由哪个部门采购，也更容易判断什么时候把你带进项目。 比如，OA 厂商发现客户仍然依赖人工汇总经营数据，就比较容易识别出 BI 需求；做 CRM 的厂商发现客户销售过程缺少智能分析，也可能自然想到相关 AI 产品。 它们不仅知道客户是谁，通常也更清楚应该如何向客户介绍你。 硬件伙伴当然也可能拥有大量客户资源，但从整体来看，他们对软件方案、业务流程和具体场景的理解通常会弱一些。 有些硬件销售认识采购或者信息化负责人，却不清楚你的软件对应什么业务问题、应该进入哪项预算，以及什么时间适合推荐。 即使他愿意帮忙，在客户面前也可能只能勉强说一句： “我们还有一家软件合作伙伴，你们要不要见一下？” 这样的推荐缺少具体场景，客户很难产生足够重视。 理解场景的软件同业，开口方式可能会具体很多： “你们现在已经积累了不少业务数据，但经营分析还依赖人工汇总。我们有一家合作伙伴专门解决这一块，可以基于现有系统搭建经营分析和管理驾驶舱。” 两种推荐的信任程度和后续转化率，差别很大。 当然，这不是一条绝对规律。 有些硬件厂商长期扎在客户现场，对客户的业务流程、项目规划和关键人关系非常熟悉；有些软件厂商虽然产品相邻，却缺少客户信任，也没有推荐意愿。 最终还是要看一件事： 双方能不能围绕同一批客户，形成一条具体的业务连接？ 三、一家公司，要继续向下拆 很多生态人员认识了某家公司的一个生态负责人，再加上一两个销售，就认为这家公司已经覆盖了。 然后赶紧去拓展下一家伙伴。 但一家公司的销售可能有几十个，甚至几百个。 不同事业部、区域和行业团队，服务的客户不同，手里的资源不同，近期工作重点不同，对伙伴的诉求也完全不同。 你认识总部的生态负责人，不等于认识华东区的一线销售。 你认识某个事业部负责人，不等于其他事业部了解你的产品。 你和对方高层签了合作协议，也无法保证一线销售会主动向客户推荐你。 所以，伙伴地图不能停留在公司名称这一层。它还要继续向下拆： 公司—事业部—区域—行业—角色—具体个人—目标客户 当一家公司已经被验证有合作价值，接下来的重点应该是把它继续做深。 要了解它有哪些事业部，哪些事业部最接近我们的目标客户；不同区域有哪些成熟销售；哪些顾问经常遇到相邻需求；谁愿意推荐我们；谁有能力把我们带进客户；谁只是名义上的对接人。 大厂尤其如此。 大厂如果能够从总部或事业部自上而下打通，再把合作传导到一线，杠杆率通常很高；但大厂内部架构复杂，一线销售业绩压力也很大，往往没有精力主动推荐一个与自己目标关系不大的伙伴产品。 认识大厂高层，不等于掌握大厂资源。还要继续弄清楚：具体哪个事业部能够撬动资源，它当前的诉求是什么，近期工作重心是什么，一线销售为什么愿意带上你。 有时候，一家没有什么名气的小公司，反而可能是更重要的伙伴。 它的客户数量未必很多，但几个深耕区域或行业的老销售，与客户建立了长期信任。如果你的产品恰好能补齐他们的方案，他们主动推荐的意愿和能力，可能会带来很大的惊喜。 大公司的资源上限高，但未必容易调动。 小公司的资源规模有限，合作链条却可能更短。 公司名气很重要，但不能代替具体的资源判断。 四、公司是资源容器，个人让资源流动 公司层面的地图帮助我们判断，谁可能拥有需要的客户资源。 到了个人层面，要继续判断： 这些资源能不能流动起来？ 创始人、架构师、产品经理、项目经理、顾问、销售、生态、市场，都有可能成为好的个人伙伴。 判断一个人的价值，不能只看职位，也不能只看他是否热情。 更值得关注的是两个问题： 他是不是经常接触客户？他能不能与甲方关键人直接对话？ 持续接触客户需求的人，通常知道客户最近在推动什么项目、遇到了什么问题、现有方案缺少什么，也知道应该把你介绍给谁。 只有客户名单的人，优先级可以往后放。 客户名单只能证明他知道这家公司，无法证明他与客户建立了关系，也无法证明客户愿意听他推荐。 再往后，才是只有转介绍预算的人。 市场和生态人员当然也可能成为很好的伙伴。 但现实中，很多公司的市场和生态手里只有“介绍好处费”，并没有可以介绍给你的客户资源。 这种伙伴通常很好聊。 大家建一个社群，轮流介绍我是谁、我服务什么客户、我能提供什么产品。群里气氛不错，大家也可能很喜欢你。 但几个月过去，没有人能把你带到甲方关键人面前。 这时，生态工作就很容易变成一场“你好、我好、大家好”的自嗨游戏。 如果对方自己没有直接客户资源，就继续看他能不能把你带到公司内部掌握资源的老销售、顾问和项目负责人面前。 只要能连接到一线，他仍然是一个有价值的入口。 如果既没有客户资源，也无法连接一线，只能告诉你“我们这里有介绍费”，投入就要克制。 所以，个人伙伴的优先级可以非常直白： 经常见客户、接触真实需求的人，高于只有客户名单的人；只有客户名单的人，又高于只有转介绍预算的人。 伙伴价值不取决于他和你聊了多久，而取决于他离客户有多近。 五、有些伙伴带不来商机，却能帮助你赢单 如果只用“介绍了多少条商机”评价伙伴，会漏掉一类很有价值的人。 他们未必能直接介绍新客户，却熟悉你正在跟进的客户，也了解项目背后的组织关系。 在销售打单过程中，他们可能知道： 客户为什么突然启动这个项目； 谁是项目的实际发起人； 谁在内部支持，谁还在犹豫； 业务部门和信息化部门之间有什么分歧； 预算已经批了，还是仍在内部争取； 客户过去做过哪些努力，最后结果怎么样； 竞争对手已经接触了哪些人； 客户表面上关心价格，背后更担心什么； 哪位领导有拍板权，哪位领导只负责流程。 这些信息未必能直接变成一条 CRM 线索，却会显著影响销售策略。 比如，一位长期服务客户的项目经理告诉你： “这个项目虽然是信息化部门牵头，但运营负责人一直觉得现有方案太复杂。下次汇报不要再讲技术架构，重点讲一线人员怎么用。” 再比如，一位熟悉客户的顾问提醒你： “采购流程还没正式开始，现在谈价格太早。客户目前只是在通过方案交流确定立项范围，需要先说服财务负责人。” 这些情报不会带来新商机，却可能帮助你赢下已经在跟的项目。 所以，伙伴地图里还应该标注一类角色： 情报型伙伴。 判断这类伙伴的价值，可以看几个问题： 他是否熟悉客户内部组织？是否了解当前项目背景？能不能帮助识别关键人和决策链？能否帮助销售判断客户倾向、竞争态势和下一步动作？ 对于金额较大、决策链复杂的项目，销售甚至可以单独画一张“项目外围伙伴图”。 客户现有的软件厂商、硬件供应商、咨询顾问、实施服务商、协会联系人以及离职员工，都可能掌握不同的信息。 有人能带来新客户，有人能帮助你进入关键部门，有人能告诉你客户内部正在发生什么。 这三种价值都值得被伙伴地图记录。 六、先理解对方为什么愿意合作 很多公司做生态，首先想到的是设计政策。 介绍一个客户给多少钱，签单以后返点多少，伙伴分成几个等级，每个等级分别享受什么权益。 这些政策当然有价值。 但如果自己没有资源可以介绍给伙伴，只有一笔介绍费，很容易陷入“拿着锤子找钉子”的思维： 我给你钱，你帮我卖。 伙伴愿意介绍你，背后可能有很多原因。 他需要补齐自己的方案，更专业地响应客户；希望提高客单价，增加客户黏性；或者希望通过你的产品进入原来进不去的项目。 这些业务价值，通常比一笔介绍费更重要。 很多人嘴上不会直接拒绝介绍费，心里却很反感一上来就谈钱。因为这等于默认，他与客户多年建立的信任，可以被直接标价。 预算可以准备。 合作有了进展，可以送礼物、表达感谢，也可以在规则清楚的前提下支付合理回报。 但在还没有理解对方业务时，别急着把关系处理成一笔交易。 如果条件允许，最好把自家销售也带上。 让双方接触客户的一线人员建立联系，了解彼此正在服务什么客户、遇到什么需求、能够提供什么帮助。 稳定的伙伴关系通常来自一次次互相创造价值，单次返点很难支撑长期合作。 七、先从一个轻量动作开始 很多公司喜欢从高层见面开始。 双方签署战略协议，发布联合新闻，再办一场启动会，看起来非常正式。 但公司级合作的复杂度很高。 客户归谁，商机怎么分，销售利益如何安排，产品是否集成，项目由谁交付，出现问题谁来负责，每个问题背后都牵涉不同部门。 很多合作谈得很大，落地时却没有一线人员愿意推动。 伙伴合作可以先从一个轻量动作开始： 双方各拿出十家目标客户，一起核对关系； 请对方介绍一位熟悉行业的一线销售； 一起拜访某个客户； 邀请对方顾问参与一次方案讨论； 出现相邻需求时互相引荐； 共同复盘一个正在推进的项目； 请对方帮助补充客户内部情报； 联合验证一个具体项目。 这些动作投入小、反馈快，也能帮助双方判断合作能力。 嘴上说有很多客户，不如完成一次引荐。 反复强调产品互补，不如共同服务一个项目。 跑过几个具体动作，双方自然会知道资源是否匹配、合作是否顺畅、哪些规则需要补充。等业务连接得到验证，再考虑升级为公司级合作。 八、伙伴地图要进入日常管理 伙伴地图不能画完以后放进汇报材料。 它需要进入生态团队的日常管理，持续记录和更新。 一张基本可用的地图，至少应该包括： 伙伴所在的公司、事业部、区域和行业； 双方客户重叠的具体范围； 可能出现互补需求的场景； 过去发生过哪些转介绍、搭售、集成和联合项目； 哪些人掌握客户资源； 哪些人能够触达客户关键人； 哪些人熟悉客户内部情况； 双方正在共同跟进哪些客户和项目； 下一步准备做什么； 什么情况下继续投入； 什么情况下暂时停止。 有了这些信息，生态人员的行程才不会随意安排。 已经被历史合作验证的伙伴，可以优先投入；更接近目标客户、经常遇到相关需求的人，可以多花时间；只有泛泛合作意愿、长期没有具体动作的伙伴，可以暂时放下。 管理层对生态工作的要求，也不能只剩下最终带来多少商机。 商机有很长的滞后周期。 如果只有结果，没有过程，生态人员很容易在一段时间内失去方向，最后用拜访数量、活动数量和伙伴签约数量证明自己很忙。 生态工作的过程，至少应该能看到： 重点伙伴是否完成了组织下钻； 是否找到更多一线销售、顾问和项目负责人； 双方是否完成客户资源盘点； 是否发生联合拜访； 是否出现有效转介绍； 是否为重点项目提供过客户情报； 原来的伙伴优先级有没有被事实更新。 这些过程不能保证一定产生结果，但它们可以帮助公司判断，生态团队是在接近业务价值，还是只获得了情绪价值。 B2B 公司的生态资源始终有限，尤其是人的时间有限。 今天认识谁，下个月深挖谁，哪家公司继续投入，哪家公司暂时放下，都应该是一项可以讨论、可以复盘的业务决策。 否则，行程再满、活动再多、微信好友再丰富，生态团队也可能只是在带薪休假。",6085,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":15,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":37},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":39,"likeCount":40,"commentCount":40,"contentLikeCount":40,"contentCommentCount":40,"sourceLikeCount":40,"sourceCommentCount":40},false,0,[42,51,57,64,72,79,85,92],{"id":43,"kind":7,"title":44,"summary":45,"image":46,"href":47,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":49},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[50],"人工智能",{"id":52,"kind":7,"title":53,"summary":54,"image":14,"href":55,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":56},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":58,"kind":7,"title":59,"summary":60,"image":61,"href":62,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":63},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":65,"kind":7,"title":66,"summary":67,"image":14,"href":68,"meta":69,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":70},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[71],"软件开发",{"id":73,"kind":7,"title":74,"summary":75,"image":76,"href":77,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":78},"NEWS_ARTICLE:831","Agent Sandbox 规模化：JuiceFS 探索与实践","过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。 当 Sandbox 并发","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171045357-1907499098.png","\u002Fnews\u002F831",[7,8],{"id":80,"kind":7,"title":81,"summary":82,"image":14,"href":83,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":84},"NEWS_ARTICLE:830","百智云长期记忆服务：长期记忆与上下文窗口的区别","很多人在接触 AI 长期记忆时，第一反应是：「这不就是把聊天记录存起来吗？」其实这是一个很常见的误解。今天我们把「长期记忆」和「上下文窗口」这两个概念彻底讲清楚。 一、什么是上下文窗口 上下文窗口（Context Window）是模型在单次推理时能「看到」的文本上限。它像一个临时的工作台：模型只能处","\u002Fnews\u002F830",[7,8],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":91},"NEWS_ARTICLE:835","体验向量数据库 qdrant","作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！ cnblogs博客 zhihu Github 公众号:一本正经的瞎扯 背景 为了早点搞懂公司的百万行 C# 的祖传代码，我想在缺乏文档、缺乏帮手的情况下，先建立一个 企业知识库 来快速帮我理清头绪。 一开始，我是打算以 weav","https:\u002F\u002Fimg2022.cnblogs.com\u002Fblog\u002F1457949\u002F202202\u002F1457949-20220216153819145-1193738712.png","\u002Fnews\u002F835",[50],{"id":93,"kind":7,"title":94,"summary":95,"image":14,"href":96,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":97},"NEWS_ARTICLE:833","如何利用AI技术实现漫画翻译","漫画作为图文结合的特色文化载体，承载着各国潮流文化与人文故事，但跨语言的文字壁垒，长期制约着漫画的传播与交流。传统漫画翻译高度依赖人工操作，需要人工框选文字、擦除原图文字、翻译文案、排版适配画风，流程繁琐、耗时费力，且极易出现排版错乱、画风违和、语义偏差等问题。 随着深度学习、计算机视觉与大模型技术","\u002Fnews\u002F833",[7,8]]