连接密度
AI产品的核心竞争壁垒：不只是接入了多少场景，而是每个场景上跑满了多少上下文、业务规则、执行能力和兜底机制。
简介
连接密度（Connection Density）是衡量AI产品竞争力的核心指标。它不是简单的”接入了多少场景”的广度问题，而是”每个场景连接得多深”的质量问题。一个高连接密度的AI产品，在每个它覆盖的业务场景中，都沉淀了完整的用户上下文、业务规则、异常处理逻辑和自动化执行能力。
这个概念与”模型能力”形成对比：模型能力是入场券（谁都可以接入大模型API），但连接密度是护城河（积累的业务理解和系统集成无法被复制）。模型三个月一换，榜单半年一洗，但连接密度积累的上下文和规则是换不走的。
关键信息
- 类型：概念
- 领域：AI产品战略、产品竞争分析
- 相关概念：MCP 模型上下文协议（底层连接协议）、AI Agent 智能体（连接的执行载体）、Function Calling（工具调用能力）
- 首次提出：@Hank 在人人都是产品经理的文章中系统阐述
核心特性
定义
连接密度由四个层次构成：
- 上下文层：知道用户是谁、历史行为、当前状态
- 规则层：理解业务流程、权限体系、审批逻辑、异常分支
- 执行层：不仅能”告诉用户怎么做”，还能”帮用户做了”——拥有操作业务系统的权限和能力
- 兜底层：异常处理、回退机制、人工介入通道
与相似概念的区别
| 维度 | 连接密度 | 功能集成 | API接入 |
|---|---|---|---|
| 深度 | 深——跑满上下文和规则 | 中——实现了功能对接 | 浅——只建立了技术通道 |
| 替代成本 | 极高——业务理解无法复制 | 中等——需要重新开发 | 低——换个API即可 |
| 典型表现 | AI能帮你退款、能走审批流程 | AI能调用退款接口 | AI能发HTTP请求 |
典型应用
- AI客服：低密度 = 回复”请通过APP操作退款”；高密度 = 确认用户身份、查订单状态、判断退款权限、执行退款操作、更新库存和账单
- 企业办公AI：低密度 = 对话框里能聊天总结；高密度 = 审批流自动走、日程自动协调、文档自动归档、异常自动预警
- SaaS产品：低密度 = 接了个大模型API；高密度 = 每个业务触点都深度集成AI能力
常见误区
- 误区一：“接入了 = 连接了”。很多产品号称”AI Native”，点进去就是对话框接了大模型API，但用户的审批还在OA里、订单还在ERP里、数据还在BI里。对话框和业务流程之间有一条看不见但很宽的河。
- 误区二：“场景越多越好”。场景多而每个都浅，就是许愿。每多连一个场景，就多一份理解业务、适配系统、处理异常、维护迭代的投入。资源和注意力被稀释。
- 误区三：“模型强就够了”。OpenAI造了全世界最强的引擎，但光有引擎哪也去不了。它自己也在拼命做ChatGPT Agent、推Function Calling、发布Operator，因为对话框是孤岛。
不同素材中的观点
- 2026-06-22-woshipm-ai-product-connection-density：@Hank 系统阐述了连接密度的概念——模型只是入场券，连接密度才是护城河。通过ChatGPT/Claude（模型强但连接浅）vs 企业办公SaaS（场景多但做不深）的对比，指出两种产品各有困局。核心判断是”生态整合壁垒远大于单点功能竞争”，并引用《置身钉内》的钉钉AI复盘说明”场景多而浅”的陷阱。
- 2026-06-09-woshipm-to-a-era：从To A（Agent as Customer）视角补充——当Agent成为流量分发的中间层时，连接密度恰好是服务方不被绕过的护城河。Agent能调用的服务越深、上下文越丰富，越不容易被替代。
- 2026-06-19-woshipm-ai-commercialization-endgame：从商业化终局视角补充——“结果收费模式”（卖可验证的业务结果而非模型或token）本质上就是连接密度的商业变现：只有连接得够深，才能承诺和交付可验证的结果。
- 2026-07-01-woshipm-feishu-cli-open-source-strategy：以 飞书 CLI 为例给出了连接密度的一个具体实现路径——飞书开源 CLI 客户端（薄外壳、MIT 协议），却把所有的鉴权、数据存储、组织架构关系、行级权限校验全部锁死在云端。文章称之为”盘根错节的工作上下文”，本质就是连接密度的三层：组织关系上下文（谁向谁汇报、谁是 owner）、数据流转上下文（报销审批→表格状态→财务通知的跨域穿透）、权限与安全上下文（DLP 策略、行级权限）。关键洞察是”CLI 开放得越彻底，第三方 Agent 调用越频繁，企业数据就越被死死绑在飞书云端”——开放表层入口反而加深了连接密度这一护城河。
实用信息
- 衡量连接密度的检查清单：
- 用户在你产品里能完成多少个完整业务流程（不是”能调用”，而是”能跑完”）？
- 每个流程里，AI知道多少上下文（用户身份、历史、状态）？
- 每个流程里，AI能执行多少动作（不只是建议，而是操作）？
- 异常情况有多少种，AI能自动处理多少种？
- 提升连接密度的路径：底层接好 MCP 和各类协议，让用户的业务能顺畅跑起来。客户不需要知道你底下接的是哪家模型，他们只在意”这个问题你帮我解决了没有”。