第7章 Context 成为组织变量

前几章反复碰到同一个东西。第一章里，它是“理由的丢失”——三个月后还记得砍掉了某个功能，却想不起为什么砍。第二章里，它是接口的损耗——需求文档不是产品定义本身，而是理解的压缩版本。第三章里，它是小团队的有利条件：每个人都大致知道全局；规模扩大后，这个条件开始消失，层级随之出现。第六章里，判断和验证都离不开它。

前面只看见了它造成的后果，还没有正面解释它。这一章给它名字、定义和位置：上下文（Context）。本章的主张是，上下文不只是组织运行中默认存在的背景，还可以被当作组织变量来分析：它如何形成，在哪里损耗，转移时付出什么成本，以及技术能否改变这些条件。

7.1 什么是上下文

先用一个具体的对比把它和信息分开。

“我们上个月决定砍掉离线模式”——这是一条信息。它可以原样写进纪要，再发给没有参加过讨论的人。

文字虽然原样到了，接收者却未必能据此做出合适的后续判断。他不知道当初为什么砍——是技术做不动，还是用户不需要，还是给别的功能让路？不知道砍之前试过什么，哪些方案已经被排除；也不知道有哪些约束不能碰，当时的反对理由今天是否仍然成立。

这些“不知道”加在一起，构成了缺失的上下文。粗略地说：上下文是让一条信息能被恰当使用所需要的相关背景——目标、历史、约束、意图、当前状态、已做的决策和它们的理由、悬而未决的问题。[D]

信息和上下文之间有一个重要的不对称：文字、数字等显性信息可以较准确地复制，但接收者能否正确使用它，还取决于他已经知道什么、如何理解目标，以及是否掌握相关约束。同一份文档，交给参与了全过程的人和刚入职的人，产生的理解往往不同。文档内容相同，两个人可调用的上下文却不同。组织里的很多问题因此不是“信息没传到”，而是“让信息可用的背景没有一起到达”。

7.2 上下文如何形成，如何丢失

上下文通常不是一次性写出来的，而是在工作过程中逐渐形成。一起开过会、一起排查过故障、一起听过客户投诉的人，会共享一部分目标、历史和取舍理由；文档和数据则保存其中能够被明确表达的部分。第三章说的小团队优势，一部分就来自共同经历沉淀下来的共享上下文。

无论来自经历还是记录，上下文都可能通过三种常见方式损耗。

时间。 人会遗忘。结论如果写进系统，往往比没有记录的讨论过程和取舍理由保存得更久；时间一长，组织可能还记得“做了什么”，却说不清“为什么这样做”。

交接。 上下文通常不能只靠整段搬运来保留可用性，而要经过压缩——一小时的讨论变成五页文档，五页文档变成二十条工单，二十条工单变成代码。每一步都可能有取舍，取舍也可能丢东西。接收方拿到压缩版本后要重建，而重建出来的上下文通常会和原来的有出入——第二章在接口那里已经遇到过这条定律。

人员流动。 当关键背景只存在于个人记忆中，人员离开就会带走这部分上下文。文档库能够降低损失，却未必记录了“为什么、在当时什么约束下、排除了什么”；记录是否充分，决定了组织需要重建多少理解。

7.3 上下文转移成本：传统组织一笔隐性的账

第四章的一个成本项可以具体化为：每一次交接——需求交给设计、设计交给工程、工程交给测试、老员工交给新员工——组织都在支付上下文转移成本（Context Transfer Cost）：交出方付压缩的成本（写文档、开会讲、反复答疑），接收方付重建的成本（读、问、试错），双方共同付偏差的成本（理解不一致导致的返工）。

这笔账通常是隐性的，却能解释一些看似只在“传话”的组织装置。需求文档、评审会、项目周报、交接文档、项目经理和中层管理者承担的功能并不相同，其中一部分共同作用是：在任务跨越人员或部门时，尽量维持上下文的连续性。[D] 项目经理持续跟进需求，能够减少不同环节反复从头理解；中层汇总并解释上下信息，也可能承担上下文中继功能。这不是它们存在的全部理由，却是成本表上容易被忽略的一项。

这些装置可能昂贵、缓慢，也不能保证没有遗漏，但它们回应了真实问题：当上下文无法自然跨过分工边界时，组织需要用文档、会议、角色和流程填补断点。不同组织如何填补、为此付出多少成本，会影响它选择怎样的结构。

7.4 上下文完整性

比“上下文多不多”更有用的分析维度是：上下文完整性（Context Integrity）——与任务相关的上下文，在执行任务的主体那里保持连续、完整、可用的程度。[D]

这个定义里的三个限定分别指向不同问题。“相关”意味着上下文不是越多越好；无关材料会形成噪音，稀释注意力。“连续”意味着任务经过关键环节时，所需背景没有在交接中断裂。“可用”则意味着背景不能只是躺在某个文档里，还要能在需要时进入判断。

用这个维度重新看分工，会看到它的另一面：分工让不同的人集中发展专业能力，也把相关背景分散到了不同位置——商业背景可能在负责人那里，产品背景在产品经理那里，技术背景在工程师那里。没有任何一个人持有完整图景并不必然是缺陷，但当任务要求跨域判断时，组织就需要付出成本，把相关部分重新连接起来。许多协调装置都承担了这种修补工作。

7.5 AI 改变了什么

AI 在这里带来的变化，不是自动拥有了组织的上下文，而是提高了组织处理上下文的技术能力。

设想一次从客户投诉到产品修改的任务。AI 可以帮助记录讨论和决策过程，这是捕获；从历史材料中找出相关投诉和旧方案，这是存储与检索；把客户语言转成产品需求、再转成技术描述，这是转换；把分散材料整理成当前图景，这是综合；在后续步骤中继续调用这些记录，则是保持。这里的每一步都只是能力：前提是原始材料被记录、系统有权访问、检索结果相关，而且模型能够一致地使用它们。

因此，更完整的因果链是：AI 先提高捕获、检索、转换和综合材料的能力；这些能力如果可靠地进入工作流程，才可能降低上下文转移成本；转移成本下降后，任务相关背景才更有可能在执行过程中保持连续。[D/H] 这为一个人或小单元跨越多个专业环节提供了可行性，但不保证整合一定发生。专业能力、认知负荷、风险和监管要求仍可能要求分工。

这里有一个必须先说清的边界：上下文窗口大，不等于有效上下文多。[D] 模型能接收多少材料，只说明原料容量；相关材料有没有进入系统，能否被准确找到、正确理解并在不同步骤中一致使用，是另一回事。容量、检索精度、相关性过滤、理解质量和状态一致性都会限制最终效果。第五章区分了“可获得”与“可靠”，这里也一样：AI 提供了压缩上下文转移成本的可能，这个可能兑现到什么程度，需要证据检验。

7.6 集中的代价

提高上下文完整性，不等于必须把所有背景和判断权集中到一个人身上。上下文可以由多人共享，也可以由系统保存。不过，当组织选择把关键背景和决策过度集中在单一主体时，至少会出现两类代价。

第一，单点故障。如果关键背景只在一个人或一个系统里，这个主体的离开、失效或权限中断，都可能让任务停摆；如果判断权也随之集中，误判还可能缺少及时纠正。分工会造成交接损耗，但第二个人重新理解问题的过程，有时也构成交叉验证。

第二，独立判断可能被稀释。如果所有人都依赖同一份摘要、同一套筛选结果或同一个 AI 助手，上下文看似更一致，遗漏也可能更一致。多人基于不同材料和经验独立形成判断，再相互检验，能够暴露单一视角看不见的问题。[D]

所以，本章的结论不是“上下文应该尽可能集中”。组织需要同时处理两件事：让执行者获得足够连续的相关背景，也保留必要的独立判断。两者并非天然对立，但具体设计可能让它们发生冲突。技术降低上下文处理成本后，可选方案会增加；怎样平衡，仍取决于任务风险、可验证性和对独立判断的需求。

7.7 上下文边界

本章把问题落到一个新的组织设计问题上。

传统组织设计常问：这个人负责什么，向谁汇报，与谁交接？本章在这些问题之外增加一个分析视角：一个任务的有效上下文，应该在哪里保持连续，在哪里可以允许断开？[D] 断点可能落在岗位、部门或组织边界上。若两个环节高度依赖共同背景，把它们分开就会产生较高的转移成本，组织可以考虑让责任更连续；若相关背景容易表达和验证，交接就更可行。这里讨论的是整合的可行性，不是要求所有强关联环节都由一个人完成。

这个问题所划出的，就是上下文边界（Context Boundary）。一旦“上下文在哪里连续”可以被显式设计，岗位所打包的能力就不再是划分任务的唯一依据。这个问题也为第三部分讨论责任单元准备了划界依据；在进入第三部分前，第八章先完成协调成本的分析。

本章命题与边界

[D/H] 上下文是让信息能够被恰当使用的相关背景；任务跨越人员和边界时，这些背景通常要经过表达、压缩与重建，由此产生上下文转移成本。AI 可以提高上下文的捕获、检索、转换和综合能力；当这些能力足够可靠并进入工作流程时，转移成本可能下降，上下文完整性也可能提高。组织设计因此需要在岗位与汇报关系之外，显式考虑上下文应在哪里保持连续、在哪里可以交接。

证据分级：上下文与信息的区分、压缩—重建损耗、上下文转移成本对组织装置的解释，以及有效上下文能力的构成，均为本书的分析框架 [D]，其中与分工、层级相关的部分有第一、三章的存量理论支持 [E]；“AI 能显著压缩上下文转移成本”是待验证假设 [H]——它的可观察预测是：在其他条件相近时，AI 深度参与的任务链应减少交接所需时间与交接返工率。交接次数是否下降，还取决于组织是否随之重划责任边界。

边界条件：上下文集中带来的收益受单点故障风险与独立判断需求约束；高风险、强监管、需要交叉验证的任务，职责分离本身可能具有保护价值。有效上下文能力不等于模型的上下文窗口容量；本章有关成本下降的推论，还要求相关材料能够被记录和访问，并被系统可靠地检索、理解和使用。

下一章处理上下文之外的最后一块：协调。上下文转移便宜了之后，协调成本是不是就跟着降了？答案比看起来复杂——AI 压缩旧协调成本的同时，会制造新的协调成本。