AI 如何真正理解业务：把上下文从提示词变成组织资产

会读制度，不等于懂得企业怎样运行

例如，设想一位新任运营负责人问 AI：“最近交付延误主要发生在哪里？”系统检索了流程制度，生成一段看似完整的解释，却把计划交期、客户承诺日期和实际出库时间混为一谈；它也不知道某些订单处于批准过的例外状态，更不知道同一客户在 ERP 与 CRM 中使用不同名称。

问题不是模型没有读到足够多文字，而是企业没有把判断所需的上下文组织成可用结构。制度告诉人原则，数据记录状态，系统保存对象，资深员工掌握例外，权限决定谁能看到什么。这些内容彼此分离时，AI 只能用语言流畅地猜测关系。

所以，企业 AI 的“懂业务”不是模型天然拥有的能力，而是组织把业务对象、定义、关系、时态、规则和证据边界持续提供给系统的结果。 上下文应被当作一项需要所有者、版本和反馈的企业资产，而不是一次项目里写完的提示词。

为什么上下文总比预想中复杂

首先，企业语言具有角色性。“客户”对销售可能是一个账户，对财务可能是付款主体，对服务团队可能是实际使用组织。同一个词在不同决定中指向不同对象。若只建一份全局词典，系统仍可能选错口径。

其次，业务事实具有时间性。今天有效的价格政策、审批链和组织归属，不能自动解释去年发生的交易。知识库常保留最新版文件，却缺少生效日期、废止关系和历史版本，AI 因而用今天的规则评判过去。

第三，真正影响决定的规则并不都写在文档中。某类客户承诺需要谁批准、设备告警在什么组合下才应停机、哪些合同条款可以接受，往往分散在系统配置、会议纪要和专家经验里。单纯“把文档都放进去”只覆盖可见部分。

最后，上下文有权限边界。员工能够知道某项指标的定义，不代表能看到构成它的全部客户或人员记录。若 AI 为了回答问题跨越原系统权限，所谓业务理解就建立在治理失效上。

“业务上下文六层图”

可以用“业务上下文六层图”识别一项判断需要什么。六层由具体到抽象，也相互连接。

第一层：业务对象。 明确企业正在谈论的实体与稳定标识，例如客户、订单、物料、设备、项目、合同义务和服务请求。对象需要来源、主键、别名与生命周期。没有这一层，AI 无法判断两条记录是否指向同一件事。

第二层：语言定义。 记录术语、指标、分类和单位，并说明适用角色与场景。“活跃客户”“延期”“高风险”等词必须能落到计算或判断标准。领域负责人拥有定义，技术团队负责可执行表达。

第三层：业务关系。 表达对象之间如何关联：订单依赖哪些物料，合同义务由哪个项目履行，设备故障影响哪条产线与客户承诺。关系让系统从单点信号理解影响传播，而不是只做关键词匹配。

第四层：状态与时间。 记录对象当前阶段、历史变化、生效区间、事件顺序和数据新鲜度。可靠回答不仅要问“是什么”，还要问“在什么时间点是什么”。

第五层：规则与责任。 包含政策、阈值、审批、例外、决策权和升级条件。规则要区分强制要求、经验建议和临时做法，责任要明确谁能解释、覆盖或批准。

第六层：证据与权限。 为每项事实保留来源、版本、授权范围和可信级别。输出应能指回可检查证据，并按使用者身份过滤。证据冲突时，系统需要提示而不是悄悄选择。

六层图不是要求建设一个无所不包的“企业大脑”。它的用途是围绕具体决定检查缺口。例如回答交付延误，可能只需订单、承诺、物料关系、例外规则和相关权限；与该问题无关的人力资料不应进入上下文。

AI 怎样利用上下文，而不是吞下上下文

当问题进入系统，首要动作是识别提问者、业务对象与任务类型。随后检索适用定义、关系、当前状态和规则，组合成一个有边界的“上下文包”。上下文包应标注来源和时间，并明确仍缺什么。模型负责基于这些材料组织调查、生成解释或提出下一步，而不是自行发明企业事实。

若用户继续追问，系统可以沿对象关系扩展，例如从延期订单追到物料与供应商；但扩展必须继续遵守权限和目的限制。并非上下文越多越好。大量无关文档会稀释关键信息，过长历史也可能让模型误用旧规则。

答案被业务人员确认、修正或拒绝后，反馈需要落到相应层：对象匹配错误修正标识，术语误解更新定义，遗漏例外补充规则，来源过期调整版本。只有这样，使用过程才在改善组织资产，而非每次重新“教一遍 AI”。

从一组真实问题开始建设

真实问题集。 由业务负责人收集一个场景中真实出现的问题及后续动作。不要从“我们有哪些文档”开始，而要从“谁在何时需要判断什么”开始。领域专家、数据或知识负责人、IT 与安全共同标记每个问题需要六层中的哪些内容。

上下文契约。 契约列出业务对象、关键定义、允许来源、时间要求、规则所有者、权限和正确拒绝条件。输出是一份可测试的边界：系统应该知道什么、不能知道什么、何时必须询问或升级。

最小可靠来源。 优先处理对象映射、核心定义和高频规则，再接入文档和历史案例。每个来源要有更新责任、版本与质量检查。检查点是一个答案能否稳定引用正确版本，而不是知识条目数量。

双重验证。 历史案例检验基础事实，新问题检验组合和澄清能力。领域专家评价结论及适用边界，一线使用者评价是否帮助下一步，治理角色检查越权与敏感内容。

反馈路由。 用户可以指出“对象不对”“规则过期”“缺少关系”“无权查看”等具体原因，维护团队按层处理。观察从反馈到修复的时间、相同错误复发率、答案引用覆盖、正确拒绝和人工升级，而不仅是回答满意度。

上下文工程的四个危险误区

文档堆积等于知识建设。 没有版本、对象关系和所有者的文档越多，冲突越难发现。高质量的小范围上下文优于无边界资料库。

把个人经验直接固化为规则。 专家经验可能只适用于特定客户、地区或时期。进入系统前应标注适用条件，并经过流程所有者确认。

为了便利扩大访问。 AI 的检索范围必须继承或收紧原有权限。汇总输出也可能泄露敏感事实，不能只在原文层面做权限控制。

把模型推断当企业记录。 AI 可以提出关系假设，但未经确认不能自动成为主数据或正式规则。事实资产与生成建议需要清晰分层。

对于变化极快、规则尚未形成共识的领域，先让专家在小范围探索，可能比急于固化上下文更合适。上下文治理不是为了消灭模糊，而是让模糊可见、可讨论、可更新。

让业务理解成为可持续能力

Luminent 会从企业的真实流程与问题出发，梳理六层上下文中已经存在和需要补齐的部分，连接现有系统、数据、知识与权限，并通过 POC 检查 AI 的回答和行动是否建立在可追溯语境上。这样建设的不是一段更长提示词，而是一套会随业务变化持续维护的理解基础。