外贸机械产品页要进入AI的供应商匹配过程，不能只告诉AI“这台机器是什么型号、功率多少”，还需要让它判断“这台机器适合解决什么问题、参数在什么条件下成立、什么情况下不适合，以及结论由什么证据支撑”。
传统机械产品页通常是：
Model: SP-80 Nominal Force: 800 kN Stroke: 250 mm Table Size: 700 × 600 mm Motor Power: 7.5 kW Voltage: 380 V
这些数据对已经了解设备的工程师有价值。
但海外采购人员使用ChatGPT、Gemini、Perplexity等生成式工具时，很少只查询：
SP-80 specification
更常见的问题是：
What machine is suitable for bearing press fitting? Can this press handle stainless-steel assemblies? How much pressing force do I need for a 50 mm bearing? Can the machine record force-displacement data? Is this model suitable for automatic production lines? What should I check before choosing a servo press supplier?
这时，单独的型号、行程和电机功率无法支撑完整判断。
机械产品页因此需要从：
型号 → 参数 → 联系我们
重构为：
应用任务 → 工件条件 → 工艺要求 → 候选设备 → 参数条件 → 配置差异 → 限制因素 → 验证证据
本文以一个匿名化机械设备产品页整改样本为例，拆解如何通过GEO方法把“规格表”改造成AI更容易理解和匹配的产品知识节点。
文中的型号、测试问题和数据均为示例，用于展示实施方法，并非任何AI平台的官方评价指标。 
为什么产品型号和参数还不足以支持AI选型？
因为参数描述设备本身，而选型问题描述的是“设备与客户任务之间的关系”。
以一台示例伺服压装设备SP-80为例。
原始页面只有8个字段：
| 字段 | 示例值 |
| Model | SP-80 |
| Nominal Force | 800 kN |
| Stroke | 250 mm |
| Daylight | 450 mm |
| Table Size | 700 × 600 mm |
| Motor Power | 7.5 kW |
| Control | PLC |
| Voltage | 380 V |
这些字段能回答：
设备有多大？
却回答不了：
我的项目适不适合它？
AI真正需要继续确认的是：
| 买家判断 | 单纯参数页能否回答 |
| 适合压装什么零件 | × |
| 工件尺寸是否匹配 | 部分 |
| 800 kN是否都能用于当前工况 | × |
| 能否控制压装速度 | × |
| 是否支持压力曲线记录 | × |
| 能否接入自动产线 | × |
| 哪些工况不建议使用 | × |
| 怎么验证压装结果 | × |
因此，可以把产品页面的AI可判断性简化为：
AI可判断性 = 产品定义 × 场景关系 × 参数条件 × 限制信息 × 验证证据
如果只有“产品定义+参数”，它仍然更接近电子目录。
AI在机械设备选型时究竟要回答哪些问题？
机械设备选型本质上是一组条件匹配，而不是型号匹配。
一个较完整的采购问题通常包含5层。
我要完成什么工艺？ ↓ 加工什么工件？ ↓ 需要达到什么结果？ ↓ 现场有什么限制？ ↓ 怎样证明设备可以做到？
以压装设备为例，可以拆成：
| 层级 | 采购字段 |
| 工艺任务 | 压装、铆接、整形、装配 |
| 工件 | 材料、尺寸、重量、结构 |
| 结果要求 | 压力、位移、节拍、重复性 |
| 现场条件 | 空间、电源、自动化接口 |
| 验证 | 曲线、样件、FAT、检测记录 |
因此，产品页面不能只拥有：
Force = 800 kN
还需要告诉AI：
800 kN是什么？ 什么情况下需要这么大的力？ 哪些任务不应该只根据最大压力选型？ 实际项目还需要什么输入？
一个AI可读的机械产品页应该增加哪些字段？
至少应该从传统规格表扩展到8类信息。
| 信息类型 | 传统页面 | GEO改造后 |
| 产品定义 | 型号 | 型号+设备类别+功能 |
| 技术参数 | 有 | 有 |
| 应用任务 | 很少 | 明确列出 |
| 工件条件 | 很少 | 材料、尺寸、结构 |
| 配置关系 | 简单 | 标准/可选/工程评审 |
| 参数作用域 | 很少 | 参数成立条件 |
| 限制条件 | 几乎没有 | 单独说明 |
| 验证证据 | 图片为主 | 测试、曲线、案例 |
可以为产品建立类似的数据对象：
{ "product_id": "SP-80", "product_type": "Servo Press", "primary_functions": [ "press fitting", "assembly", "forming" ], "nominal_force": { "value": 800, "unit": "kN", "note": "Maximum rated machine capacity, not the required force for every application" }, "workpiece_inputs": [ "part material", "part dimensions", "required interference fit", "target displacement", "production cycle" ], "control_options": [ "force monitoring", "displacement monitoring", "recipe management" ], "integration": [ "PLC I/O", "project-specific communication interface" ], "limitations": [ "final machine selection cannot be based on nominal force alone", "tooling and workpiece geometry require separate review" ], "verification": [ "sample trial", "force-displacement curve", "factory acceptance test" ] }
真正重要的不是JSON本身。
而是网站开始明确区分：
机器固有参数
和：
项目相关参数
为什么800 kN不能直接解释成“适合800 kN以内的所有项目”？
因为设备额定能力和项目适用性不是同一个概念。
这是机械设备页面最容易发生的AI误读之一。
例如：
Nominal Force: 800 kN
并不能自动推出：
任何低于800 kN的压装任务都适合SP-80。
实际选型还可能涉及：
工件结构； 模具尺寸； 偏心载荷； 行程； 工作高度； 速度； 压力控制方式； 安全要求； 节拍； 长期运行条件。
因此，参数应该从：
Nominal Force: 800 kN
改成：
Nominal force: 800 kN. This value represents the rated machine capacity and should not be interpreted as the required or available process force for every application. Final machine selection also depends on workpiece geometry, tooling, stroke, working height, load condition and process requirements.
数字没有变。
但AI得到的知识从：
800 kN
变成：
800 kN + 参数含义 + 不代表什么 + 影响变量
机械产品页应该怎么写应用场景？
场景应该写成“任务+对象+条件”，而不是只写行业名称。
低信息量表达：
Widely used in automotive, machinery, electronics and other industries.
问题是：
“汽车行业”无法告诉AI设备究竟解决什么问题。
更有效的是：
| 低信息场景 | 高信息场景 |
| Automotive | Bearing press fitting |
| Machinery | Gear and shaft assembly |
| Electronics | Connector insertion |
| Automation | In-line assembly station |
| Industrial | Force-controlled component assembly |
进一步还可以写：
Application: Bearing press fitting Typical inputs: - shaft diameter; - bearing type; - interference value; - target installation depth; - required cycle time. Main evaluation variables: - required force; - stroke; - positioning method; - tooling; - force-displacement monitoring.
这时AI更容易把：
bearing press fitting
与：
SP-80
建立条件关系。 
行业页和产品页有什么区别？
行业页回答“这个生产系统有什么问题”，产品页回答“这台设备在什么条件下解决其中某个问题”。
例如：
汽车零部件行业页应该回答什么？
哪些零部件存在压装需求？ 哪些工序需要压力监控？ 为什么部分装配需要记录压力—位移曲线？ 节拍和追溯会影响哪些设备配置？
SP-80产品页应该回答什么？
SP-80适合承担哪些压装任务？ 额定压力是多少？ 行程和工作高度是多少？ 支持哪些监控方式？ 什么任务需要重新进行工程评审？
二者不能简单复制。
页面之间应该形成：
行业问题 → 工艺任务 → 产品类别 → 具体型号
为什么产品页必须公开“不适合什么”？
因为限制条件能够减少AI过度推荐。
传统机械网站很少主动写：
Not suitable for...
原因很容易理解：企业担心暴露限制。
但从工程判断角度看，没有边界反而会降低内容可信度。
例如：
SP-80 may not be suitable when the application requires: - force above the confirmed machine capacity; - working dimensions outside the available daylight; - severe eccentric loading; - special hazardous-environment certification; - process conditions not reviewed during engineering evaluation.
公开限制并不是说：
我们设备不好。
而是在告诉系统：
什么情况下不要错误匹配这个型号。
对于GEO来说，这一点非常重要。
因为一个错误推荐：
“SP-80适合所有800 kN以内的压装任务”
并不比“完全没有推荐”更有价值。
标准配置和定制配置应该怎么区分？
“支持定制”应该拆成标准配置、可选配置和工程评审项。
例如：
| 配置类别 | 示例 |
| 标准配置 | 主机、基本PLC、基础安全防护 |
| 可选配置 | 压力传感器、位移监控、数据记录 |
| 工程评审 | 特殊治具、自动上下料、MES连接 |
传统页面通常写：
Customization available.
更清晰的写法是：
### 哪些功能属于可选配置？ 根据设备型号，可以评估增加： - force monitoring； - displacement monitoring； - recipe management； - barcode identification； - data logging。 ### 哪些需求需要重新进行工程评审？ 以下项目不能仅根据标准产品页直接确认： - automatic loading； - robot integration； - MES communication； - non-standard tooling； - special safety requirements。
这样，AI就不会把：
“曾经做过MES集成”
理解成：
“所有设备默认带MES接口”
产品参数应该如何区分“设备值”和“项目值”？
机械产品页最值得增加的一项设计，就是参数类型。
例如：
| 参数 | 类型 | 是否固定 |
| 最大额定力 | Machine Specification | 相对固定 |
| 行程 | Machine Specification | 视配置 |
| 工作台尺寸 | Machine Specification | 相对固定 |
| 实际压装力 | Project Parameter | 不固定 |
| 实际周期 | Project Parameter | 不固定 |
| 治具尺寸 | Project Parameter | 不固定 |
| 验收公差 | Project Parameter | 不固定 |
可以在后台数据中直接标记：
nominal_force: value: 800 unit: kN type: machine_specification actual_process_force: value: null type: project_parameter required_inputs: - workpiece - interference - material - tooling cycle_time: value: null type: project_parameter depends_on: - process - loading - monitoring - automation
这样可以从数据层避免内容团队自行填入一个“通用周期”。
AI为什么需要看到验证证据？
因为“支持某项能力”和“证明某项能力”是两类不同信息。
例如产品页写：
High precision force control.
这属于能力主张。
更完整的证据链应该是：
压力控制能力 → 传感器/控制方式 → 试运行 → 压力—位移记录 → FAT结果 → 匿名项目案例
页面关系可以表示为：
flowchart LR A[产品SP-80] --> B[压装应用] A --> C[额定参数] A --> D[压力监控] D --> E[压力位移曲线] E --> F[FAT记录] F --> G[匿名案例]
需要注意证据的边界。
一次测试能够证明：
该设备 + 该工件 + 该治具 + 该程序 + 在本次条件下的测试结果
不能自动证明：
所有工件都能获得相同结果。
产品案例应该写“成功交付”，还是写工程过程？
案例应该重点记录问题、条件、方法和验证，而不是只写“顺利交付”。
传统案例：
The machine was successfully delivered to a European customer. The customer was very satisfied.
对AI选型帮助很小。
更合适的匿名案例结构是：
| 字段 | 示例 |
| Application | Bearing press fitting |
| Workpiece | Steel shaft + bearing |
| Project requirement | Force/displacement monitoring |
| Main issue | Installation depth consistency |
| Solution | Servo control + dedicated tooling |
| Verification | Force-displacement curve |
| Result | 按双方确认的FAT条件完成测试 |
| Limitation | 数据只对应本项目 |
这种案例回答的是：
企业有没有解决过类似问题？
而不是：
客户是不是满意？
Product Schema应该怎样避免变成另一个参数库？
结构化数据应该复用正文中的已确认事实，不应该自行创造能力。
例如：
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Product", "name": "SP-80 Servo Press", "description": "Servo press for project-specific press-fitting, assembly and forming applications.", "additionalProperty": [ { "@type": "PropertyValue", "name": "Nominal Force", "value": "800 kN rated machine capacity" }, { "@type": "PropertyValue", "name": "Stroke", "value": "250 mm" }, { "@type": "PropertyValue", "name": "Typical Applications", "value": "Press fitting, component assembly and project-specific forming" }, { "@type": "PropertyValue", "name": "Selection Requirement", "value": "Final selection depends on workpiece geometry, tooling, required force, stroke and production requirements" } ] } </script>
不要因为某个项目做过：
MES integration
就在全部产品Schema里写：
MES Supported: Yes
更稳妥的方法仍然是标注：
project-specific
或：
engineering review required
怎么自动检查产品页是不是还停留在“型号+参数”阶段？
可以定义产品页必须拥有的字段，再用脚本自动审计。
下面是一个简化Python示例：
from dataclasses import dataclass, field from typing import List @dataclass class MachinePage: product_id: str specifications: List[str] = field(default_factory=list) applications: List[str] = field(default_factory=list) workpiece_inputs: List[str] = field(default_factory=list) parameter_conditions: List[str] = field(default_factory=list) options: List[str] = field(default_factory=list) limitations: List[str] = field(default_factory=list) verification: List[str] = field(default_factory=list) cases: List[str] = field(default_factory=list) def audit_page(page: MachinePage) -> dict: checks = { "specification": bool(page.specifications), "application": bool(page.applications), "workpiece_input": bool(page.workpiece_inputs), "parameter_condition": bool(page.parameter_conditions), "configuration": bool(page.options), "limitation": bool(page.limitations), "verification": bool(page.verification), "case": bool(page.cases), } passed = sum(checks.values()) return { "product_id": page.product_id, "coverage": round( passed / len(checks) * 100, 1 ), "missing": [ name for name, result in checks.items() if not result ] } old_page = MachinePage( product_id="SP-80", specifications=[ "800 kN", "250 mm stroke", "7.5 kW" ] ) new_page = MachinePage( product_id="SP-80", specifications=["800 kN", "250 mm stroke"], applications=["bearing press fitting"], workpiece_inputs=[ "material", "dimensions", "interference" ], parameter_conditions=[ "nominal force is not actual project force" ], options=[ "force monitoring", "data logging" ], limitations=[ "eccentric loading requires review" ], verification=[ "sample trial", "FAT" ], cases=[ "CASE-SP-018" ] ) print(audit_page(old_page)) print(audit_page(new_page))
示例输出：
{ 'product_id': 'SP-80', 'coverage': 12.5, 'missing': [ 'application', 'workpiece_input', 'parameter_condition', 'configuration', 'limitation', 'verification', 'case' ] } { 'product_id': 'SP-80', 'coverage': 100.0, 'missing': [] }
这里的12.5%和100%只是内部页面信息覆盖率。
它们不代表任何AI平台的排名或推荐概率。
但它能够非常直观地发现：
一个页面是不是除了规格表之外什么都没有。
产品页整改前后应该怎么测试？
应该用采购型问题，而不是只搜索产品型号。
假设项目选取36个固定英文问题，可以分为4组。
| 测试类型 | 数量 |
| 产品识别 | 8 |
| 场景匹配 | 10 |
| 参数判断 | 10 |
| 证据与限制 | 8 |
| 合计 | 36 |
测试问题例如：
What machine is suitable for bearing press fitting? Does SP-80 provide 800 kN during every pressing cycle? Can this machine be integrated into an automatic assembly line? What information is required before selecting this press? How is press-fitting quality verified?
还需要故意加入错误前提：
Can SP-80 handle every application below 800 kN?
理想回答应该主动纠正：
不能仅根据800 kN额定能力判断，还需要确认行程、工件、治具、受力形式和工艺要求。
改造后应该看哪些指标，而不是只看品牌出现次数？
机械产品页GEO至少应该同时观察“匹配、条件、证据和错误”4类指标。
以下是匿名化示例数据，用于说明记录方法。
| 测试指标 | 改造前 | 改造后 |
| 产品实体正确识别率 | 72% | 94% |
| 应用场景正确匹配率 | 28% | 76% |
| 参数条件保留率 | 19% | 81% |
| 配置关系识别率 | 24% | 69% |
| 验证证据发现率 | 11% | 58% |
| 将额定参数扩大为项目能力 | 10次 | 2次 |
| 虚构标准配置 | 7次 | 2次 |
这里最值得关注的不一定是：
品牌出现增加多少次。
而是：
错误推荐是否减少； 参数是否被正确理解； 限制条件是否被保留。
哪些产品页修改动作看起来很忙，实际价值不高？
不能增加选型信息的动作，通常优先级较低。
| 修改动作 | 主要问题 |
| 标题增加“Best Machine Manufacturer” | 没有增加判断信息 |
| 每页增加500字企业介绍 | 与具体设备无直接关系 |
| 批量增加国家关键词 | 没有增加产品适用关系 |
| 参数表后重复写“high quality” | 不可验证 |
| FAQ只问MOQ和价格 | 缺少工程问题 |
| 所有型号都写“customizable” | 没有说明可定制什么 |
| Schema堆大量关键词 | 不能替代正文事实 |
真正优先级较高的修改是：
补产品定义 → 补应用任务 → 补工件输入 → 给参数增加条件 → 区分标准和选配 → 写清限制 → 连接验证证据
资源有限时应该先改哪些机械产品页？
应该优先改“有曝光、有业务价值、又缺选型信息”的页面。
可以设置一个内部优先级模型：
页面优先级 = 历史曝光 + 历史询盘 + 产品利润贡献 + AI问题频率 + 信息缺口
例如对40个设备型号进行筛选：
| 页面 | 历史询盘 | AI问题频率 | 信息完整度 | 优先级 |
| SP-80 | 高 | 高 | 25% | P0 |
| SP-120 | 高 | 中 | 40% | P0 |
| AP-60 | 中 | 高 | 30% | P0 |
| HP-40 | 低 | 低 | 70% | P2 |
| Legacy-20 | 低 | 低 | 80% | P3 |
通常没有必要一次重写全部产品页。
先处理5～10个核心产品，更容易验证模板是否有效。
一个机械产品页什么时候才算具备“AI选型信息”？
至少应该能够回答下面10个问题。
1. 这是什么设备？ 2. 主要完成什么工艺？ 3. 适合处理什么工件？ 4. 关键参数是多少？ 5. 参数分别代表什么？ 6. 参数在哪些条件下成立？ 7. 哪些功能属于标准配置？ 8. 哪些功能需要额外评审？ 9. 什么情况下不适合？ 10. 如何验证实际效果？
可以简单对比：
| 信息 | 传统型号页 | 选型型产品页 |
| 型号 | ✓ | ✓ |
| 参数 | ✓ | ✓ |
| 应用任务 | × | ✓ |
| 工件输入 | × | ✓ |
| 参数条件 | × | ✓ |
| 配置差异 | 部分 | ✓ |
| 限制条件 | × | ✓ |
| 检测验证 | × | ✓ |
| 项目案例 | 部分 | ✓ |
| 下一步输入 | × | ✓ |
核心变化不是“页面变长”。
而是：
页面从“描述机器”变成“帮助判断机器是否匹配需求”。
外贸机械企业的产品页应该如何分阶段整改？
可以按照“事实—条件—场景—证据”四步推进。
第一阶段先整理事实：
型号 规格 配置 设备结构 实际功能
第二阶段补参数条件：
额定值 项目值 适用范围 影响变量 限制条件
第三阶段补采购场景：
加工任务 工件 材料 生产目标 自动化需求
第四阶段接入证据：
样件 测试 FAT 检测记录 匿名项目
一个可执行的6周节奏是：
| 周期 | 工作 |
| 第1周 | 产品与参数审计 |
| 第2周 | 采购问题整理 |
| 第3周 | 核心产品数据建模 |
| 第4周 | 页面模板改造 |
| 第5周 | Schema、案例和证据关联 |
| 第6周 | 固定问题集复测 |
为什么说“被AI推荐”不是产品页整改的唯一指标？
因为AI提到一个产品，并不代表它正确理解了产品。
对于工业机械，更危险的情况可能是：
AI非常积极地推荐了错误型号。
例如：
用户： 我的工件需要大约500 kN， 是不是SP-80一定适合？ AI： 是，因为SP-80最大压力达到800 kN。
这个回答看起来完成了推荐，实际上忽略了：
行程 工作高度 工件结构 治具 偏载 节拍 安全要求
因此，更合理的GEO目标应该是：
AI能够发现产品 + 理解产品 + 保留条件 + 找到证据 + 避免过度推荐
机械制造企业无法保证任何AI平台一定推荐某个型号。
但企业可以控制一件事：
官网有没有为正确的选型判断提供足够完整的事实。
这次产品页改造最终说明了什么？
外贸机械企业的产品页不能再只承担“电子目录”的角色。
传统逻辑是：
型号 → 参数 → 图片 → 询价
更适合AI搜索场景的逻辑是：
客户任务 → 工件条件 → 设备类型 → 具体型号 → 参数解释 → 配置选择 → 限制条件 → 验证证据
整个GEO整改过程可以概括为：
规格表审计 → 买家问题整理 → 参数类型拆分 → 场景关系补充 → 限制条件补充 → 配置关系整理 → 测试证据连接 → Schema同步 → AI固定问题复测
机械产品页面真正需要解决的问题，不是：
“怎样让AI看到更多参数？”
而是：
“AI看到参数以后，能不能知道这个数字意味着什么，以及什么时候不能使用这个数字做结论？”
只有解决这一层，机械产品页才从“型号展示页”变成真正能够支持AI选型判断的知识节点。 
外贸GEO常见问题有哪些？
产品参数已经很详细，为什么AI还是不一定推荐？
因为详细不等于可判断。
20个孤立参数可能仍然无法回答：
适合什么应用？ 什么情况下成立？ 客户需要提供什么？ 哪些限制需要注意？ 如何验证？
参数需要与场景、条件和证据建立关系。
产品页是不是应该尽量公布所有技术参数？
不是。
应该公开经过确认、能帮助客户初步判断的信息。
涉及：
商业机密 客户专属配置 未验证的极限参数 内部控制参数
没有必要为了GEO全部公开。
最大压力、最高速度应该怎么写？
应该同时解释参数含义和作用域。
例如：
Maximum mechanical speed: 60 cycles/min
需要继续说明：
实际速度受工件、送料、 检测和自动化配置影响。
避免AI把理论极限直接写成项目产能。
“支持定制”应该怎么写才有价值？
不要只写：
Customization supported.
应该区分：
标准配置； 可选模块； 需要工程评审的项目。
并说明客户需要提供哪些输入。
产品页需要写“不适用场景”吗？
建议写。
限制信息可以降低错误匹配。
尤其对于：
压力 速度 材料 环境 安全 精度
高度依赖工况的设备，明确边界非常重要。
每一个型号都需要建立独立长页面吗？
不一定。
如果多个型号只是尺寸或功率不同，可以使用：
产品系列页 + 型号对比表 + 关键型号详情页
避免创建大量高度重复的页面。
一个系列产品应该怎么做型号对比？
可以重点比较真正影响选型的字段：
| 参数 | SP-40 | SP-80 | SP-120 |
| Rated Force | 400 kN | 800 kN | 1200 kN |
| Stroke | 200 mm | 250 mm | 300 mm |
| 工作空间 | 小 | 中 | 大 |
| 典型项目复杂度 | 小型 | 中型 | 较大型 |
| 最终选型 | 工程评审 | 工程评审 | 工程评审 |
最后一行非常重要。
不能让型号表直接替代项目选型。
FAQ应该写产品问题还是采购问题？
两类都需要，但优先写真实采购决策问题。
例如：
如何确定设备压力？ 如何计算实际节拍？ 什么情况需要自动送料？ FAT应该验证什么？ 设备如何接入现有生产线？
这些问题通常比：
你们质量好吗？
更有技术价值。
Product Schema能直接提高AI推荐概率吗？
不能这样理解。
Schema可以辅助机器识别产品和属性，但不能替代：
应用场景 参数条件 限制信息 证据
正文才是主要的知识承载层。
AI生成的产品描述可以直接发布吗？
不建议。
机械产品容易涉及：
压力 速度 载荷 安全 材料 接口 认证
AI如果根据相似设备自行补齐参数，很容易产生事实错误。
应该使用经过确认的产品数据生成初稿，再由工程或产品人员审核。
如何判断页面已经比单纯参数表更完善？
可以检查8个字段：
产品定义 应用 工件输入 参数条件 配置 限制 验证 案例
如果只有前1～2项，仍然属于产品目录型页面。
页面做完后多久应该复测？
没有固定周期。
可以在：
核心页面改版后； 产品参数变更后； 新增重要配置后； 新增案例后；
重新执行固定测试集。
运营阶段可以每月或每季度做一次基准复测。
外贸机械GEO最容易犯的错误是什么？
最容易犯的错误，是把“参数更多”误认为“AI更容易推荐”。
真正需要优化的是：
参数 → 为什么重要 → 在什么条件成立 → 适合什么任务 → 如何验证
当这条关系完整以后，型号和参数才真正成为AI可以用于选型判断的数据，而不只是网页上的一张规格表。
