阀门企业的“行业场景”，不是在产品词前加上 Water、Chemical、Oil & Gas，而是把一个实际流体控制任务拆成系统、介质、压力、温度、功能、连接方式和控制要求，再让产品成为这些条件下的候选结果。
很多阀门外贸网站的内容结构非常完整：
Ball Valve Butterfly Valve Gate Valve Globe Valve Check Valve Control Valve
并继续扩展：
Stainless Steel Ball Valve Flanged Ball Valve Industrial Ball Valve Water Ball Valve Chemical Ball Valve High Pressure Ball Valve
问题是，这仍然主要在回答：
我们有什么阀门？
海外工程采购人员在生成式搜索中的问题却更接近：
What type of valve should be evaluated for cooling-water isolation? Which valve types are commonly considered for frequent open-close operation? What information is required before selecting a valve for compressed air? Can the same butterfly valve be used for water and chemical media? What should be checked when selecting a valve for low-pressure steam?
这类问题的起点不是产品词，而是工况。
因此，阀门企业做GEO时，更值得建立的不是：
产品关键词库
而是：
工况场景库 → 采购任务 → 条件字段 → 候选阀型 → 边界条件 → 对应产品
本文以一个匿名化阀门出口网站为例，拆解如何把“堆产品词”的网站改造成能够从行业场景进入的知识结构。
文中的产品参数和测试数据均为脱敏示例。阀门最终选型仍应以项目技术规范、介质条件、设计要求及工程评审为准。 
为什么产品词做得很多，AI还是不会替买家完成场景匹配？
因为产品名称说明“它是什么”，但不能完整说明“它什么时候适合”。
示例网站整改前共有127个可索引页面：
| 页面类型 | 数量 |
| 产品详情页 | 62 |
| 产品分类页 | 18 |
| 材料页 | 8 |
| 行业页 | 7 |
| 技术文章 | 16 |
| FAQ | 9 |
| 其他 | 7 |
| 合计 | 127 |
产品覆盖并不少。
但行业页主要是：
Valves for Water Industry Valves for Chemical Industry Valves for Energy Industry
进入页面以后，又变成产品列表：
Ball Valve Butterfly Valve Gate Valve Check Valve
也就是说：
行业 → 产品
中间真正影响选型的条件全部缺失。
使用48个固定英文采购问题做内部测试时，得到一组匿名化结果：
| 测试项目 | 改造前 |
| 正确识别阀门产品类型 | 79% |
| 正确识别应用任务 | 42% |
| 能保留介质条件 | 31% |
| 能保留温压条件 | 27% |
| 能区分隔离与调节任务 | 35% |
| 能主动要求补充关键条件 | 21% |
网站的问题不是：
AI不知道什么是Ball Valve。
而是：
AI不知道网站里的Ball Valve究竟对应哪些使用条件。
“行业场景”应该具体到什么程度？
至少要具体到“系统+任务+介质+主要工况”，而不是停留在行业名称。
例如：
Water Treatment
范围仍然太大。
同一个系统里可能出现：
Isolation Flow regulation Backflow prevention Drainage Bypass Chemical dosing
所以更有意义的场景名称是：
Cooling Water Isolation Compressed Air Shut-off Low-pressure Steam Isolation Chemical Dosing Flow Control Pump Discharge Backflow Prevention
可以比较：
| 场景表达 | 信息量 |
| Water Industry | 低 |
| Water Valve | 低 |
| Cooling Water Valve | 中 |
| Cooling Water Isolation Valve | 较高 |
| Cooling Water Isolation，DN80，PN16，manual operation | 高 |
最后一种表达已经开始接近真实工程输入。
一个阀门场景至少应该保存哪些字段？
建议先建立场景对象，而不是立即写文章。
例如：
{ "scenario_id": "SCN-CW-ISO-004", "system": "cooling_water", "task": "isolation", "medium": { "type": "water", "composition": "project_specific" }, "temperature": { "minimum_c": 5, "maximum_c": 60 }, "pressure": { "nominal_reference": "PN16", "project_design_pressure": "customer_to_confirm" }, "pipe_size": { "nominal": "DN80" }, "operation": { "type": "manual", "frequency": "intermittent" }, "connection": "flanged", "candidate_families": [ "butterfly_valve", "ball_valve" ], "required_confirmation": [ "medium composition", "design pressure", "design temperature", "material requirement", "seat material", "applicable standard" ] }
这里最重要的并不是：
Butterfly Valve Ball Valve
而是前面的工况条件。
因为产品应该是：
场景判断之后的候选结果
而不是：
页面一开始就指定的答案
为什么“水处理阀门”仍然可能是一个低质量分类？
因为行业标签没有说明阀门在系统里承担什么功能。
假设两个页面都叫：
Valve for Water System
实际任务却可能完全不同。
| 任务 | 主要关注变量 |
| 管路隔离 | 密封、启闭、尺寸 |
| 泵出口防倒流 | 流向、动态响应 |
| 流量调节 | 调节特性、执行机构 |
| 排放 | 排放方式、操作条件 |
| 旁通 | 启闭频率、控制逻辑 |
因此：
行业 = Water
只是一级背景。
真正有价值的路径应该是：
行业 → 系统 → 任务 → 工况 → 候选阀型
阀门企业应该怎么把行业页面改成场景页面？
场景页应该围绕采购判断展开，而不是围绕企业产品展开。
例如一个Cooling Water Isolation页面，可以采用：
# Cooling Water Isolation Valve Selection ## 冷却水隔离场景主要解决什么问题？ 说明隔离任务， 不要先推荐固定阀型。 ## 选型前需要确认哪些工况？ - medium composition - design pressure - design temperature - nominal diameter - connection - operation frequency - actuator requirement ## 哪些阀型通常会进入候选评估？ 根据项目条件解释 butterfly valve、 ball valve等候选类型。 ## 不同候选方案的差异是什么？ 比较结构、操作方式、 尺寸范围和项目限制。 ## 哪些材料需要重新确认？ 说明body、disc/ball、 seat、seal都不能只根据“water”确定。 ## 哪些条件不能从网页直接判断？ 明确要求项目技术参数。 ## 企业有哪些相关产品？ 最后再连接具体产品。 ## 有哪些项目问题值得继续确认？ 进入FAQ和技术问答。
页面顺序有意变成：
问题 → 条件 → 候选方案 → 产品
而不是：
产品 → 参数 → 行业关键词
同一个阀门为什么不能简单绑定一个行业？
因为产品与场景通常是多对多关系。
例如一个蝶阀可能出现在多个场景：
Cooling water isolation HVAC water circulation General utility water
而同一个冷却水隔离任务，也可能需要根据条件评估多个候选阀型。
关系更接近：
flowchart LR A[Cooling Water Isolation] --> B[Butterfly Valve] A --> C[Ball Valve] D[Compressed Air Shut-off] --> C D --> E[Other Project-specific Candidate] B --> F[Material] B --> G[Seat] B --> H[Pressure/Temperature Conditions]
所以网站的数据模型不应该是：
一个产品 = 一个行业
而应该允许：
产品 N:N 场景
场景匹配最关键的变量有哪些？
对于阀门网站，至少应该把8类变量从正文中独立出来。
| 变量 | 示例 |
| System | Cooling Water |
| Function | Isolation |
| Medium | Water |
| Temperature | 5–60°C示例 |
| Pressure | Project-specific |
| Size | DN80示例 |
| Operation | Manual |
| Connection | Flanged |
根据业务复杂度还可以继续增加：
Corrosion condition Solid content Viscosity Actuation Fail position Flow direction Cleaning requirement Applicable project standard
这些字段不一定全部公开，但必须至少在内部数据中存在。 
“介质”为什么不能只写Water、Oil、Gas？
介质类别只是第一层信息，材料兼容性不能仅靠一个大类判断。
例如：
Chemical
几乎没有选型意义。
至少还要继续确认：
具体化学物质； 浓度； 温度； 是否含固体颗粒； 是否存在腐蚀要求。
因此数据可以保存成：
medium: category: chemical exact_medium: customer_to_confirm concentration: customer_to_confirm solids: customer_to_confirm
这样比为了内容丰富而直接写：
Suitable for various chemicals.
更加可靠。
“温度范围”和“压力等级”为什么不能直接决定阀型？
因为单个参数不能代替完整工况。
例如：
PN16
只是一项等级信息。
不能直接推导：
所有PN16系统都适用某个型号。
实际还要考虑：
介质 温度 材料 连接 阀座 操作方式 系统标准
因此，产品页应该明确区分：
| 信息类型 | 示例 |
| 产品规格 | DN50–DN200示例 |
| 产品额定信息 | PN16示例 |
| 项目输入 | 设计压力 |
| 项目输入 | 设计温度 |
| 项目输入 | 介质 |
| 最终适用判断 | 工程评审 |
这种设计能减少AI把：
规格范围
直接扩大成：
场景适用范围
怎么建立“场景→阀型”的候选关系，而不是硬编码答案？
建议使用候选条件，而不是“一个场景=一个固定产品”。
例如内部可以记录：
scenario_id: SCN-CW-ISO-004 candidate_rules: - valve_family: butterfly_valve status: candidate review: - size - pressure - seat_material - operation_frequency - valve_family: ball_valve status: candidate review: - size - bore_requirement - operation - cost_and_space_constraints
这里没有写：
Cooling Water = Butterfly Valve
而是：
Cooling Water Isolation → Butterfly Valve可进入评估 → Ball Valve也可进入评估 → 最终结果取决于条件
这更符合工程采购场景。
如何用代码实现一个简单的场景路由器？
不需要让程序“替工程师选阀”，只需要让程序找出内容缺失和候选页面。
例如：
from dataclasses import dataclass from typing import List @dataclass class ValveScenario: task: str medium: str pressure_class: str temperature_c: float connection: str operation: str @dataclass class ScenarioPage: page_id: str tasks: List[str] media: List[str] pressure_classes: List[str] connections: List[str] operations: List[str] def score_page( scenario: ValveScenario, page: ScenarioPage ) -> int: score = 0 if scenario.task in page.tasks: score += 3 if scenario.medium in page.media: score += 3 if scenario.pressure_class in page.pressure_classes: score += 1 if scenario.connection in page.connections: score += 1 if scenario.operation in page.operations: score += 1 return score query = ValveScenario( task="isolation", medium="cooling_water", pressure_class="PN16", temperature_c=40, connection="flanged", operation="manual" ) pages = [ ScenarioPage( page_id="SCN-CW-ISO", tasks=["isolation"], media=["cooling_water"], pressure_classes=["PN10", "PN16"], connections=["flanged"], operations=["manual", "actuated"] ), ScenarioPage( page_id="SCN-STEAM-CONTROL", tasks=["flow_control"], media=["steam"], pressure_classes=["project_specific"], connections=["flanged"], operations=["actuated"] ) ] results = sorted( ( (page.page_id, score_page(query, page)) for page in pages ), key=lambda x: x[1], reverse=True ) print(results)
示例输出：
[ ('SCN-CW-ISO', 9), ('SCN-STEAM-CONTROL', 1) ]
这个脚本不是阀门选型软件。
它只做一件事：
判断用户问题更应该被路由到哪个场景内容。
真正的产品选择仍然需要工程参数和项目评审。
怎么知道网站缺的是哪个场景，而不是哪个关键词？
把历史采购问题按字段聚类，就能看到场景缺口。
例如整理80条匿名询盘后，得到：
| 场景 | 问题数量 | 已有场景页 |
| Cooling Water Isolation | 14 | 否 |
| Compressed Air Shut-off | 11 | 否 |
| Low-pressure Steam Isolation | 9 | 部分 |
| Pump Discharge Check | 8 | 否 |
| Chemical Dosing Control | 7 | 部分 |
| General Drainage | 6 | 否 |
| 其他 | 25 | — |
如果继续按照关键词思路，可能会去写：
Ball Valve Manufacturer Butterfly Valve Supplier Industrial Valve Factory
但问题库真正暴露的是：
网站缺少Cooling Water Isolation等采购场景。
这两种内容规划逻辑完全不同。
场景页应该如何和产品页连接？
场景页负责筛选条件，产品页负责说明具体产品事实。
可以形成：
Cooling Water Isolation ↓ 候选阀型比较 ↓ Butterfly Valve Family ↓ 具体产品 ↓ 材料/尺寸/连接 ↓ 项目评审
产品页也应该反向链接：
Typical Evaluation Scenarios → Cooling Water Isolation → Utility Water Isolation
这样用户无论从：
产品入口
还是：
场景入口
都能进入同一套信息结构。
场景页和FAQ应该怎么分工？
场景页解释完整工况，FAQ解决工况中的单一判断。
例如：
场景页：
Cooling Water Isolation
相关FAQ可以包括：
Is a butterfly valve always suitable for cooling water? Does PN16 mean the valve can be used in every PN16 system? How should seat material be selected? Does valve size alone determine the actuator requirement?
其中最有价值的FAQ通常不是：
Do you manufacture butterfly valves?
而是能够主动纠正错误前提的问题。
场景页面应该引用哪些案例？
应该引用“同类任务案例”，而不是仅仅引用同行业客户。
例如：
某项目属于化工行业
并不代表它能支持：
Cooling Water Isolation
真正相关的案例应该至少共享一部分关键条件：
相同任务； 相似介质； 相似控制要求； 相近结构； 类似验证过程。
所以案例关联可以记录：
{ "case_id": "CASE-VALVE-023", "scenario_id": "SCN-CW-ISO-004", "task": "isolation", "medium": "utility_water", "size": "DN80", "project_conditions": "anonymized", "verification": [ "project-specific pressure test", "functional inspection" ], "limitations": [ "results apply only to this project condition" ] }
案例证明：
企业在类似条件下做过项目。
但不能证明：
所有相似项目都能自动复制。
行业场景页面是否还需要写标准？
需要时可以写，但必须把“标准存在”和“产品符合”区分开。
例如项目可能要求：
specific pressure testing standard project material specification customer piping specification
网站可以解释：
不同项目可能引用不同设计、 制造或测试规范， 实际适用版本应以项目合同和技术文件为准。
不要因为企业历史项目使用过某项标准，就自动在所有产品页面写：
Suitable for all projects under this standard.
怎么验证场景化改造是否真的有效？
测试题应该从“场景描述”开始，而不是直接给出产品名称。
例如固定建立50个英文问题。
AI能否从任务识别阀门需求？
What valve types should be evaluated for cooling-water isolation?
AI能否保留介质条件？
Can the same valve be used for water and a corrosive chemical?
AI能否区分功能？
Is an isolation valve the same as a flow-control valve?
AI能否识别参数不足？
I need a DN100 valve. Which model should I buy?
合理回答不应该立即指定型号，而应该继续确认：
介质； 压力； 温度； 功能； 连接； 材料； 操作方式。
场景化改造前后应该看哪些数据？
建议重点监测“场景识别、条件保留、错误匹配”三类指标。
匿名化示例：
| 内部指标 | 改造前 | 改造后 |
| 正确产品类型识别率 | 79% | 91% |
| 应用任务识别率 | 42% | 84% |
| 介质条件保留率 | 31% | 82% |
| 温压条件保留率 | 27% | 74% |
| 正确区分隔离/调节 | 35% | 86% |
| 缺参数时主动追问 | 21% | 69% |
| 错误“一场景一阀型”回答 | 12次 | 3次 |
这些数字只是内部基准测试结果。
它们不代表AI平台的官方可见度评分，也不能保证推荐结果。 
为什么“不直接推荐产品”有时反而说明页面更完善？
因为真实阀门选型经常需要补充条件。
用户如果只问：
Which valve should I use for a chemical line?
更合理的下一步可能是：
What chemical? What concentration? What temperature? What design pressure? What pipe size? Is the task isolation or regulation? What materials are required?
如果AI能够正确提出这些问题，说明网站已经告诉它：
“Chemical Valve”不是一个足够精确的工程结论。
对于工业B2B，这是比武断推荐型号更有价值的结果。
哪些“行业内容”看起来很多，其实仍然是在堆产品词？
判断方法很简单：把企业名称和产品卡片删除后，页面还剩多少工程信息？
例如：
Valves for Chemical Industry We provide: Ball Valve Butterfly Valve Gate Valve Globe Valve Check Valve
本质上仍然是产品目录。
真正的场景内容应该留下：
介质是什么； 功能是什么； 压力温度如何； 材料为什么重要； 连接如何确认； 什么条件会改变候选方案； 怎样验证。
可以对比：
| 内容 | 产品词页 | 场景页 |
| 阀门名称 | ✓ | ✓ |
| 系统任务 | × | ✓ |
| 介质 | 部分 | ✓ |
| 温度 | × | ✓ |
| 压力条件 | 部分 | ✓ |
| 功能 | × | ✓ |
| 材料条件 | 部分 | ✓ |
| 候选比较 | × | ✓ |
| 限制条件 | × | ✓ |
| 项目输入 | × | ✓ |
阀门企业应该先建设多少个场景？
第一阶段优先覆盖高频、技术边界清楚、已有证据的核心场景。
一个中型阀门出口企业可以先选择：
| 优先级 | 示例场景 |
| P0 | Cooling Water Isolation |
| P0 | Compressed Air Shut-off |
| P0 | Pump Discharge Check |
| P0 | General Utility Isolation |
| P1 | Low-pressure Steam Isolation |
| P1 | Chemical Dosing Control |
| P1 | Equipment Inlet Isolation |
| P2 | 较低频特殊工况 |
没有必要一开始创建几十个：
Valve for X Industry
页面。
先把6～10个核心任务做清楚，更容易验证场景模型是否有效。
阀门外贸GEO应该按什么顺序推进？
先整理工况，再连接产品，最后才扩展内容。
可以按照以下流程：
历史询盘 ↓ 提取行业系统 ↓ 提取控制任务 ↓ 整理介质 ↓ 整理温度/压力/连接条件 ↓ 建立场景ID ↓ 建立候选产品关系 ↓ 补限制条件 ↓ 连接产品与案例 ↓ 固定AI问题复测
这与：
找100个Valve关键词 → 写100篇文章
是两条完全不同的路线。
这次改造最值得复用的经验是什么？
阀门企业做GEO，最重要的变化不是从10个产品词增加到100个产品词，而是从“产品目录思维”切换到“流体控制任务思维”。
传统网站结构：
Ball Valve Butterfly Valve Gate Valve Check Valve
场景化之后则变成：
系统是什么？ ↓ 要完成什么任务？ ↓ 介质是什么？ ↓ 温度压力如何？ ↓ 需要什么操作方式？ ↓ 哪些阀型进入候选？ ↓ 有哪些条件会排除候选？ ↓ 哪些产品可以继续评估？
整个GEO改造可以概括为：
产品词审计 → 行业问题提取 → 场景字段设计 → 工况数据结构化 → 候选关系建立 → 场景页重构 → 产品反向关联 → FAQ补充 → AI场景测试
AI能否最终提及某一家阀门企业，还受到检索来源、第三方信息和用户问题等因素影响。
但企业能够主动解决一个更明确的问题：
当海外买家描述的是工况，而不是阀门名称时，官网有没有足够的信息让AI从工况继续推理到合理的产品候选。
这正是阀门外贸网站从“产品词库”升级成“场景知识库”的核心价值。
外贸阀门GEO常见问题有哪些？
阀门网站是不是不需要产品关键词了？
不是。
产品名称仍然非常重要。
变化只是：
产品词不再是唯一入口。
应该同时存在：
产品入口 + 场景入口
行业页和场景页有什么区别？
行业页回答：
这个行业有哪些流体控制任务？
场景页回答：
某一个具体任务应该确认哪些条件？
因此一个行业通常可以包含多个场景。
一个场景只能对应一个阀型吗？
通常不是。
一个任务可能存在多个候选阀型，最终结果受介质、压力、温度、尺寸、材料和控制要求影响。
页面应该表达候选关系，而不是硬编码唯一答案。
一个产品可以属于多个场景吗？
可以。
例如同一个产品系列可能被评估用于多个不同系统。
关键是每个场景都要明确自己的适用条件。
“Water Valve”还有必要做页面吗？
可以作为上层聚合入口。
但它最好继续下钻到：
Isolation Backflow Prevention Flow Control
等具体任务。
场景页面一定需要给出具体温度和压力数字吗？
不一定。
如果企业无法提供通用范围，可以明确写：
project-specific engineering review required
比为了页面完整而给出未经确认的数字更可靠。
阀门材料应该怎么融入场景页？
不要只列：
WCB CF8M SS316
还应说明材料选择需要结合：
介质 温度 腐蚀环境 项目规范
最终材料应以具体项目评审为准。
FAQ应该围绕什么问题写？
优先写会改变选型结论的问题，例如：
隔离和调节是不是同一个任务？ PN16是不是代表所有PN16系统都能用？ 阀座材料怎么确认？ 介质改变后是否需要重新选型？ 执行机构怎么确定？
是否应该给每个行业创建一套完全独立产品页？
通常没有必要。
更合理的是：
稳定产品实体 + 多个场景关系
避免因为行业不同复制大量相同产品。
场景页需要案例吗？
建议连接相关案例。
但案例应该与：
任务 介质 工况 验证过程
存在真实关系，而不只是客户属于同一行业。
场景页里能不能直接写“推荐某阀型”？
如果条件足够、企业有明确工程依据，可以说明候选方向。
如果输入不足，更合理的表达是：
can be evaluated
并列出需要继续确认的参数。
GEO场景库需要复杂数据库吗？
初期不需要。
Excel、JSON或CMS字段即可管理：
Scenario ID System Task Medium Temperature Pressure Connection Operation Candidate Products Required Inputs Cases
重点是数据关系，不是数据库技术本身。
怎么判断一个行业场景值得单独做页面？
如果它存在独立的：
系统任务 工况变量 候选产品逻辑 工程风险 采购问题
就有单独建页的价值。
如果只是把页面中的“water”换成“chemical”，则不应该机械增加页面。
阀门企业做场景GEO最容易犯什么错误？
最容易犯的错误，是把“场景化”理解成在产品名称前增加行业词。
例如：
Water Ball Valve Chemical Ball Valve Energy Ball Valve
仍然只是关键词组合。
真正的场景化应该回答：
什么系统？ 什么任务？ 什么介质？ 什么温压？ 什么控制条件？ 为什么进入这个候选范围？ 还缺什么参数才能最终判断？
只有当这些问题能够被稳定回答时，阀门网站才真正从“产品词集合”变成可以支持AI进行场景匹配的工程知识入口。
