每个人都在谈 Context，可每个人说的都不是同一件事。营销说的是消费情境，产品说的是使用情境，客服说的是服务情境——一个词越用越顺，边界却越来越模糊。这篇只做两件事：先把 Context 定义钉死，再把它和四个最容易混进来的概念分开。
一、误区一：什么都叫上下文，等于什么都不是
营销部门谈”消费情境”，产品团队谈”使用情境”，客服谈”服务情境”，数据团队谈”业务情境”，技术团队又把每一个 AI 用例都叫上下文。看似人人都在建，实际各说各话。
政治学者萨托利把这种现象称为概念拉伸：一个概念为了覆盖更多现象而不断放大边界，最后看似无所不包，却失去了区分、解释和指导行动的能力。
一个泛化的概念，会让你无法分配资源、无法建立优先级、无法衡量质量。
所以我们需要一个有边界的定义：哪些要素属于它，哪些不属于。
这也正是”上下文工程”这个词在过去一年被反复提起的原因。Anthropic 在 2025 年 9 月的技术文章里，把上下文工程定义为”在推理过程中筛选与维护最优 token 集合“。
请留意那个关键词：是筛选，不是收集。
这件事在 Baklib 里对应什么？Baklib 不是把企业所有文档”收”进去就完事。
AI 知识库回答用户的一句提问，靠的是从条目里挑出此刻相关的那几条——收集只是入口，筛选才是价值。也正因为要”挑”，条目才必须结构化，而不是一整篇让人和机器都读不完的长文。
换句话说，Baklib 做的不是”更大的仓库”，而是”更准的取舍”。Anthropic 说的”筛选与维护”，落到产品上，就是 Context Engine 每天在替你做的判断。
二、误区二：只看单一主体
第二个误区方向相反：把处境只从一方视角来描述。
真实情况是——一个处境从来不属于单个主体。 设想一位企业采购负责人打来电话，这个处境里同时站着好几方：
- 这位采购负责人：有目标、有情绪、有对这段关系的历史判断
- 他所在的企业：有合同约束、有组织决策习惯
- 接电话的你的系统或 AI：有授权范围、有响应规则
- 这段客户关系的历史轨迹：双方过去所有交互积累的共识与信任
四方同时在场。 任何一方单独描述，都提供不了 AI 做正确判断所需要的完整处境。
Agent 大量出现后，这个问题更突出了：一个替采购负责人做供应商评估的 Agent，本身也是有目标、有决策逻辑的主体。如果你的上下文框架只装人类视角，就会系统性地漏掉这位”新在场者”。
由此得到两条原则。
- 边界由要素构成，而非由视角决定——不是所有关于某处境的信息都算上下文
- 必须包含所有在场的有感主体——人类客户是主体，你的 AI 系统是主体，用户委托的 Agent 也是主体
这件事在 Baklib 里对应什么？一条 Context 条目，除了写客户本人，还要能标注它归属哪个主体、受哪条约束、来源是否可信。
Baklib 的权限感知检索会按身份与权限过滤结果，AI 不会看到不该看的知识——这就是把”四方同时在场”落进系统的第一步。
而当那个替客户做评估的 Agent 真的来了，Baklib 通过 MCP 把这份带主体维度的 Context 交给它，它才不会只站在人类一侧看世界。
三、一个定义，一条判据
把上面两条原则收拢，就是一个可以直接用的定义。
上下文（Context）：主体在特定处境下，作出正确判断与行动所需要的”最小完整上下文”。
这不是一句口号，而是一条可操作的判据：
- 凡不影响判断的信息，就不是上下文，是噪声
- 凡改变判断的信息，就必须被纳入上下文，是必需
“最小”和”完整”看似矛盾，其实是一体的：最小，是因为信息越多不等于越好；完整，是因为缺了任何一条改变判断的信息，判断就会出错。
工程界的研究恰好印证了”最小”这一侧。
Anthropic 与多项研究都观察到 context rot（上下文腐化）：随着上下文变长，模型的准确率与召回率不升反降。
经典研究”Lost in the Middle”发现，关键信息放在开头或结尾时效果最好，落到中间时性能降幅可超过 30%。
换句话说——把窗口塞满，不是让 AI 更聪明，而是让它更钝。
“装得下”不等于”用得好”。这就是”最小完整”四个字的现实依据。
这件事在 Baklib 里对应什么？这条判据，就是你在 Baklib 里建条目时的取舍标准：写之前先自问一句”它会改变哪个判断”，答不上来的，先别写。
这正是 Context Engine 要解决的核心。它不是把越多知识塞给 AI 越好，而是在权限、版本、相关性、来源、可信度之间做取舍，决定”哪条知识此刻该给谁”。
少给一条该给的，判断会偏；多给十条不该给的，判断会糊。这条边界，靠人拍脑袋定不准，得由系统一贯地守。
四、一个上下文里到底装了什么：知识、任务、交互
定义了边界，接下来是内容：同一个客户、同一个 AI，为什么昨天给的建议是对的，今天就不对？
因为它手里只有”这个人是谁”，没有”他此刻走到哪一步了”。前者是知识，后者是任务；再加上一个交互——此刻的情绪与时机。三层信息缺一层，AI 的判断就会系统性偏斜，不是偶然失误，而是必然。
第一层，知识维度——对这个主体的长期认知。 它包含该主体的历史模式、决策逻辑和深层诉求。它不是资料里的字段。
字段记录的是”注册时间 2019 年、年合同额 80 万”这类属性；知识维度要的是”他每次续约都会先压价、但真正的顾虑从来不是价格”这类有判断价值的理解。前者是标签，后者是认知。
第二层，任务维度——此刻的目标与约束。 同一家公司，处在”刚完成采购、正在推进部署”和”合同即将到期、正在评估要不要续签”这两个节点上，需要完全不同的回应。
任务维度告诉 AI 两件事：现在要帮他把什么做成，以及此刻哪些事绝对不能做。后者往往比前者更值钱——一句话在不该说的时候说出来，比不说更糟。
第三层，交互维度——此刻的实时状态与时机。 情绪、表达方式背后的真实诉求、以及时机的敏感度，都在这一层。
同样一句”你们的系统有问题”，在签约第一周说出来，和合同到期前一个月说出来，传递的是截然不同的信号。
这三层里，交互维度最容易被当成”软指标”忽略，但它的商业价值最直接。麦肯锡 2025 年的一项客户体验研究发现：首次响应在两分钟内的客户，复购意愿比更慢响应的高出约 40%，而且这个效应对高价值客户最强。
为什么对他们最强？因为他们会把延迟解读成”我不重要”。换句话说，时机本身就在替你做判断。
我见过更细的观察：客户的流失很少是”突然”的。
行业分析给出的经验曲线是，取消前四到八周情绪就会开始下滑——先是具体抱怨，再变成泛化不满，反馈量骤降、语气变平，最后近乎沉默。如果系统只看使用量、不看交互信号，就会漏掉这三十到六十天的抢救窗口。
三层是同一处境的三个视角，缺任何一层，判断都会偏，而且偏得有规律。
- 只有知识、缺任务 → AI 停留在画像层，给出一段正确但无用的客套话
- 只有任务、缺知识 → AI 给出技术上正确、处境上错误的回应
- 三层同时在场 → 信息才从”集合”变成”判断依据”
这类偏差不是”AI 偶尔失手”，而是结构性的——你换更强的模型也解决不了，因为缺的信息，模型变聪明了也变不出来。
这件事在 Baklib 里对应什么？别再建”客户资料页”，改建”三层信息条目”。
在 Baklib 里新建一个知识库，为每个重点客户建一条条目，字段分三层：
- 知识层：历史模式、决策逻辑、深层诉求
- 任务层：当前目标、此刻绝对不能做
- 交互层：当前情绪、真实诉求、时机敏感度
为什么坚持做成字段、而不是一篇文档？因为只有结构化，AI 才能按需调用——查询任务时只取任务字段，判断情绪时只取交互字段。一堆写在文档里的段落，AI 要么全读、要么读不到。这也正是”最小完整”落在能力上该有的样子。
建好之后，你还能用 21 套官方主题里的「Chat 问答」主题，起一个只读这个知识库的企业专属问答，直接问它：”这个客户现在最需要的下一步是什么？”如果它答得含糊，通常就是某层字段还空着。
五、事实，不等于意义
再往深一层，还有一个最容易被忽略的区分。
企业里的系统，几乎都在记录可观测的事实：某位客户今天登录过，翻了几眼账单就退出了，而他的合同还有四十来天到期。
这些记录准确、干净、可查询——但它们对 AI 来说是没有意义的。AI 不知道这些动作意味着什么，更不知道此刻该做什么。
要让它”懂”，必须补上另一半：这个客户是什么样的客户、他过去在什么节点做过什么决定、他真正在意的到底是什么。当事实配上这一层，同一串动作才突然有了方向——AI 才能读出”他是在用安静的方式表达不满”这种判断。
事实回答”发生了什么”，上下文回答”这对这个主体此刻意味着什么、下一步该做什么”。 这是两件完全不同的事，需要两套完全不同的建设路径。
这件事在 Baklib 里对应什么？Baklib 的价值不在”存了多少条记录”，而在”能不能把记录变成判断依据”。
这也是为什么我们说 Baklib 是做 Context 的基础设施，而不是做一个更大的数据集市——数据集市回答”发生了什么”，Context 回答”此刻该做什么”。同样是那串动作，装上意义之后，AI 才能给出建议，而不只是复述。
六、数据、画像、标签、旅程地图：四个都不等于上下文
这四个词天天和”上下文”混着用，但没有一个是上下文。它们是上下文可以引用的输入，不是上下文本身。
数据，回答”发生了什么”，不回答”意味着什么”。一家企业可以数据堆成山，上下文资产却是空白——这正是大多数企业的真实处境。
行业里有个流传很广的估算：全球每天新增的数据在”2.5 万亿亿字节”这个级别——“多”从来不是瓶颈，”准”才是。
画像，描述”他是怎样的人”，不回答”此刻该做什么”。它是相对静态的属性集合——年龄、行业、规模、历史消费偏好。
同一个高净值客户，在”准备配置资金”和”刚经历一次理赔不顺”两个处境里，需要的回应完全不同——哪怕在画像层面，他是同一个人。这就是画像的天花板：它把活人描述成档案。
标签，是结果，不是过程。一个被打上”流失风险高”的客户，在数据系统里只是一条记录。
但在上下文的视角里，他是一段持续演化的关系：风险来自哪条具体的因果链、当前处在什么窗口期、什么响应能修复、什么响应只会加速恶化。标签可以秒级生成，上下文必须在真实交互里沉淀。
而且，你那条”流失风险高”的标签，往往是在”沉默期”才亮起来的——那时候，最好的窗口已经过去了。
旅程地图，是地图，不是 GPS。它描述”一类客户的典型路径”，适合对齐跨部门的整体认知。
但它回答不了一个问题：此刻这个具体客户，走到了哪一步，卡在什么阻力上。它是地图，不是 GPS。 AI 真正需要的是能识别此刻具体处境的导航系统，而不是回到会议室对着地图复盘。
一句话收束这四组辨析。
- 数据，提供事实
- 画像，提供稳定特征
- 标签，提供分类依据
- 旅程地图，提供典型路径
而上下文，是把这些信息组织成”此时此刻意味着什么、下一步该怎么行动“的实时判断。
补一句证据边界：不少”CDP 失败复盘”都指向同一组硬伤——洞察滞后、身份解析不牢、合规后补、最后自己又变成数据孤岛。这些是厂商与行业口径，不是同行评审结论，但方向一致：数据齐了，不等于判断准了。
这件事在 Baklib 里对应什么？把一条”标签”改写成一条”处境条目”，在 Baklib 里只需要新建一个知识库、把字段填满。
日常检索时，AI 智能搜索会把相关的那几条先读一遍、再总结成几句话；需要问答时，AI 知识库用自然语言提问、从企业自己的文档里找答案；要让外部大模型也读懂，llms.txt 让 ChatGPT、Claude 一次就读对。
传统做法只能回答”这条资料存在哪”，而 Baklib 的 Context Engine 要回答的是”此刻该把哪一条交给谁”。
前者是仓库，后者才是基础设施——这也是 Baklib 这个名字背后真正想做的事。 你们仓库里那些数据、画像、标签、旅程地图，正是喂给它的输入。
再往下一层看，这份 Context 的地基是 Baklib 的知识中心本身：企业 Wiki、产品手册、帮助中心、资源管理站，加上多站点发布把同一个后台的内容分发到多个出口——地基不稳，上面的 Context 再漂亮也是空的。
这条路径就是那条价值链：Data → Knowledge → Context → Action。
数据和标签是 Data，写进系统成为 Knowledge，被 Context Engine 按权限与相关性挑出来才是 Context，AI 据此行动并回写结果，才是 Action。
所以，Baklib 是什么
Context 这个词被用滥了。但把它钉死在”主体 + 特定处境 + 最小完整”三件事上，它就不再是口号，而是一件可以被建设的东西。
Baklib｜企业 AI 上下文基础设施——让企业知识成为 AI 可以理解、调用和执行的 Context。
它做四件事。
- 是什么：企业 AI 上下文基础设施。
- 做什么：把企业分散的文档、帮助中心和业务数据，重构成 AI 可理解、可调用的 Context。
- 为什么：因为 AI 不缺算力，缺的是安全、准确的企业知识上下文。数据、画像、标签、旅程地图都只是输入，替代不了它。
- 怎么做：通过统一的知识中心、权限治理与 Context Engine，输出 MCP 和 API；再用 llms.txt 让大模型一次读懂你的站点。
- 谁在用：B2B 软件、出海企业与智能制造企业，正在用它把知识接到 Agent 上。
它想做的不是更大的数据仓库，而是把散在各处的原材料，加工成 AI 可以直接拿来判断的上下文。
一句话收尾
数据告诉你发生了什么；上下文告诉你这意味着什么、下一步该做什么。
画像是地图，上下文是 GPS——地图值得拥有，但你不能拿着地图开车。
先把定义钉死，再谈建设。这是我在企业里推行任何知识工程时，第一条要守的规矩，也是 Baklib 想帮你守住的那条底线。
Baklib · Context 系列
作者：宋学江（Baklib 产品负责人）
