这是很多项目最容易陷入的一种幻觉。
系统里一旦出现大量行业术语，团队就会很容易产生一种判断：
它既然已经会说行业话了，应该就已经懂业务了。但这通常是错的。
因为“会说行业词汇”和“真正完成业务适配”之间，差着整整一层系统结构。
一个法务 Agent 会说合同、违约、争议解决，不等于它知道：
- 哪类条款属于高风险条款
- 哪类问题只能提供辅助意见
- 哪类场景必须人工复核
- 哪些输入缺失时必须拒绝继续
一个医疗 Agent 会说症状、筛查、会诊、复诊，也不等于它知道：
- 当前任务是健康宣教、初筛、临床决策支持，还是正式诊疗
- 当前处于哪一个临床阶段
- 哪类建议不能自动给出
- 哪类情况必须立即升级医生
这说明一个很关键的事实：
行业词汇只能改变表层表达，
不能自动生成业务对象、业务规则、业务状态、业务评测与责任边界。为什么这个误解在 demo 中总是看起来很成立？ 因为行业术语非常容易制造“懂行感”。 模型只要能自然说出一些缩写、岗位称呼、文书名词和行业套话，用户就会迅速把“风格相似”误判成“能力相同”。
但真正的业务系统，不是靠风格运行的，而是靠结构运行的。
如果把这件事说得更硬一点，可以直接下一个判断：
业务适配不是语言风格问题，
而是领域建模问题、数据建模问题、评测问题、系统接入问题和治理问题。先看第一层，统一语言。
DDD 从来没有把 ubiquitous language 理解成一份行业词汇表。
Eric Evans、Martin Fowler 以及 Microsoft 的领域分析文档都在强调：
- 统一语言必须围绕领域模型建立
- 统一语言必须在 bounded context 内成立
- 统一语言必须被领域专家和工程团队共同使用
- 同一个词在不同上下文里可以有不同含义
这意味着，真正的业务语言不是装饰层，而是模型的外显形式。
如果一个团队只是把“客户”改成“投保人”，把“订单”改成“保单申请”，但：
- 背后对象边界没变
- 规则没变
- 状态没变
- 代码组织没变
- 上下文边界没变
那它并没有完成业务适配，只是完成了业务命名。
第二层，是 schema、ontology 和约束。
真正的业务适配，一定会落到对象、字段、关系与约束上。 Gruber 对 ontology 的定义、Stanford 的本体建模方法、OWL、SHACL、FHIR profiling、JTD 这些资料，虽然来自不同传统，但讲的是同一件事：
领域知识一旦要进入系统，
最终都要变成对象定义、属性定义、关系定义和值域/基数/校验约束。这才是系统真正能“理解业务”的方式。
因为只要不落到结构里，系统就无法稳定回答这些问题：
- 这个字段是不是必填
- 这个状态值是否合法
- 这个对象能否引用那个对象
- 这个记录在当前条件下是否合规
- 这个术语到底对应哪张表、哪个字段、哪类约束
医疗里的 FHIR profiling 是一个特别好的例子。
它处理行业差异时，不是靠“多写一点医疗术语”，而是靠 StructureDefinition 去收紧 cardinality、固定值、限制引用目标、绑定术语集、增加嵌套约束。
这非常值得记住。 因为它说明在一个真正高专业度行业里，业务适配的核心动作依然是：
- 改结构
- 加约束
- 明边界
而不是“让话术更像业内人士”。
第三层，是评测。
很多团队误以为“业务适配完成了”。 其实他们只是把模型回答写得更像行业人类。 一旦进入评测，问题就暴露了。
OpenAI、Anthropic、Google、Microsoft 近两年的官方材料都在反复强调：
- 真正的业务适配要做
domain-specific evals - 要用真实任务、真实数据、真实失败案例来测
- 要让领域专家参与定义标准、贡献样本和校准判断
- 只看通用 benchmark 或语言流畅度远远不够
这意味着，“像业内人士那样说话”根本不是通过标准。 真正的通过标准是：
- 在这个行业的真实任务上能不能做对
- 在这个行业的真实风险边界上会不会出错
- 在这个行业的参考轨迹下能不能稳定完成
LegalBench、LawBench、FinBen、MultiMedQA 这些 benchmark 的意义也在这里。 它们有价值，不是因为术语更专业，而是因为它们把行业能力拆成了：
- 推理类型
- 任务结构
- 风险场景
- 多维评测标准
这才让“行业适配”变成一个能被证伪、能被改进的问题。
第四层，是 business context 和 systems of record。
企业平台对这件事看得比任何口号都更直接。 Salesforce、ServiceNow、Microsoft、Google 这些平台，都没有把业务适配理解成“prompt 里多放行业 glossary”。 它们真正强调的是：
- semantic layer
- metadata layer
- common data model
- system of record
- business context
- governance
这背后说明的事情非常简单：
模型只有接入可信业务对象、关系、指标、主数据和权限边界，
它才有可能真正懂业务。否则，它只是用行业术语在猜业务。
Salesforce 讲统一 metadata layer 和 Tableau Semantics。 ServiceNow 讲 CMDB、CSDM 和单一数据模型。 Microsoft 讲 Dataverse 作为 trusted common data platform。 Google 讲 semantic layer、catalog、unified governance。
这些平台都在用不同语言重复同一件事：
- 业务适配来自企业定义过的数据与语义结构
- 不是来自模型自己模仿出的一套行业语气
第五层，是高风险行业的反证。
高风险行业最能把“术语感”和“业务可用性”的差别拉开。
在医疗里，模型就算会说很多临床术语，也可能：
- 对措辞顺序过度敏感
- 给出不符合指南的建议
- 在缺少关键上下文时继续自信输出
- 无法正确处理升级、拒答和人工接管
在法律里，模型就算能写出很像样的法律腔，也可能：
- 伪造法条
- 编造案例
- 沿着错误前提继续展开
- 让用户误以为自己得到了可靠法律分析
WHO、FDA、英国司法系统以及医学论文给出的共同判断都很清楚：
高风险行业需要的不是“像专业人士一样说话”，
而是“像受监管系统一样运行”。这句话非常重要。 因为它把业务适配从“风格学习”重新拉回了“系统约束”。
真正的业务适配，至少会体现在这些位置：
- schema 是否按真实业务对象设计
- 状态与流程是否按真实业务生命周期设计
- tool 参数是否承载关键业务字段
- 语义层是否绑定真实指标与主数据
- eval 是否来自真实业务任务和真实失败样本
- 是否存在拒答、升级、审批、人工接管和留痕机制
如果这些地方都没有变化，只是 prompt 里多了行业术语、行业案例和行业语气，那么系统大概率只是“行业风格化”，不是“业务系统化”。
所以，本章最值得保留的检查问题仍然非常有效：
如果把 prompt 里的行业词全部替换成通用词，
这个系统还剩下多少真实业务能力？如果替换之后，系统依然能：
- 识别真实对象
- 读取真实状态
- 调用真实工具
- 遵守真实规则
- 通过真实评测
那说明它的业务适配是真的。
如果替换之后，系统几乎只剩一句“不太像业内人士说话了”，那说明它之前依赖的主要是风格，而不是结构。
因此，本章最后想把“业务适配”重新定义一次：
业务适配不是让模型说得更像这个行业，
而是让系统的对象、字段、约束、流程、数据、评测与治理，
真正对齐这个行业。只有到了这一步，Agent 才不是“会说行业话”，而是真正开始“在行业里工作”。