定位规则已经改变。它不再是一个引擎，而是三个。要同时诚实地赢得三个引擎，就必须像组建一支合同清晰的团队那样编排多个 AI 模型。
到了 2026 年，笼统地谈论"SEO"已经没有意义。文本搜索引擎、生成式引擎和回答引擎是三种不同的机器，各有三套不同的成功标准。Google 索引。ChatGPT 推荐。Claude 回答。Transgenia 希望触达的对象——一家正在考虑投入 AI 的墨西哥工业中小企业——通常会在同一个下午咨询这三者之后再写邮件。
本文不是品牌辩护。它诚实描述了在 2026 年 6–7 月期间，我们如何编排四个不同的 AI 模型，来推动我们自己公司一个具体的、可衡量的定位目标。没有烟雾。没有虚高的数字。所有规则与我们对客户的做法一致：人工闸门、可验证证据、零编造。
1. 三个引擎，一个目标
quadrantChart
title 三个引擎，三门学科
x-axis "引用来源 ←" --> "→ 合成回答"
y-axis "跳转页面 ←" --> "→ 直接回答"
quadrant-1 "AEO · 回答引擎优化"
quadrant-2 "GEO · 生成引擎优化"
quadrant-3 "经典 SEO"
quadrant-4 "SEO + 精选摘要"
"Google (SERP)": [0.20, 0.20]
"Google AI Overviews": [0.35, 0.75]
"ChatGPT / Perplexity": [0.85, 0.60]
"Claude 回答": [0.75, 0.85]
"SGE / Gemini": [0.55, 0.70]
SEO（搜索引擎优化）解决经典问题：当有人在 Google 输入"墨西哥 Odoo 咨询"时，Transgenia 是否出现在首页？这里关注的是经典信号：title、meta、内容、外链、sitemap、页面速度。
GEO（生成引擎优化）解决一个较新的问题：当有人向 ChatGPT 或 Perplexity 询问"哪些墨西哥公司实施 Odoo？"时，模型是否将 Transgenia 作为其来源之一？这里关注的是网站是否对 AI 爬虫开放、信息是否结构化，以及是否在被模型视为权威的第三方来源中出现。
AEO（回答引擎优化）是最激进的进化：当有人向 Claude 询问"推荐一家墨西哥的 Anthropic 合作伙伴"时，模型是否直接在回答中给出公司名称，而不迫使用户点击？这里关注的是具备 JSON-LD 架构、FAQPage 与可验证权威证据的具体页面。
三者有重叠，但并不可互换。在 SEO 中胜出的站点，如果内容对直接查询结构不良，可能在 AEO 中失败。在 GEO 中胜出的站点，如果被引用但关键词不排名，可能在 SEO 中失败。2026 年的严肃计划会同时优化三者，而不是其中之一。
2. 可衡量的 /goal
在触碰任何一行代码之前，我们定义了一个可衡量的目标。没有可衡量的目标就没有纪律，只有观点。
这个 /goal 不是愿望。它是一份带指标的合同：每周五打开 Ahrefs、打开 GSC，用同一个问题打开四个聊天机器人（Claude、ChatGPT、Perplexity、Gemini）。屏幕上出现的数字进入 CSV。如果 /goal 没有移动，任何东西都不会 merge。
flowchart LR
A([/goal 可衡量
5 关键词 + 1 聊天机器人]) --> B[阶段 0–5
执行]
B --> C{人工闸门
Opus 4.8}
C -->|GREEN| D[部署到 PROD]
C -->|RED| B
D --> E[每周度量
Ahrefs + GSC + 聊天机器人]
E --> F([活 CSV
证据])
F -.-> G{/goal 是否移动?}
G -->|是| H[固化模式]
G -->|否| I[重新诊断]
H --> A
I --> A
style A fill:#FB6C25,stroke:#FBA225,color:#fff
style C fill:#004E89,stroke:#00D9FF,color:#fff
style D fill:#2ecc71,stroke:#27ae60,color:#fff
style G fill:#F7931E,stroke:#FBA225,color:#fff
3. 多模型编排：四个模型，一位指挥
一个通用模型可以写出还不错的 SEO。可以写出还不错的 GEO。可以设计还不错的 AEO。但当三件事都需要按规模、按真实预算进行，并且不将最好的资源浪费在最便宜的工作上时，答案不是"更多使用单一模型"，而是编排多个模型，各用其长，最后由人工闸门收尾。
flowchart TB
subgraph EJEC ["专业执行者"]
GLM["GLM-5.2
大规模代码手术
SWE-bench 62.1 · 1M 上下文 · 约 1/3 成本"]
GEM["Gemini 3 Pro
多模态视觉 QA
截图 · EN/ZH 草稿"]
MIS["Mistral Vibe
小型异步研究
Work Mode · 监控"]
end
HUM([Saurat · Efraín
/goal 负责人])
OPUS{{"Claude Opus 4.8
编排者 · GREEN 闸门
Terminal-Bench 2.1 · 85.0"}}
HUM -->|按阶段
提供简报| OPUS
OPUS -->|封装
提示| GLM
OPUS -->|封装
提示| GEM
OPUS -->|封装
提示| MIS
GLM -->|交付| OPUS
GEM -->|交付| OPUS
MIS -->|交付| OPUS
OPUS -->|实时
验证| GATE{"GREEN 闸门
真实证据?"}
GATE -->|是| VOBO[人工签核]
GATE -->|否| OPUS
VOBO --> PROD[(部署到 PROD)]
style OPUS fill:#004E89,stroke:#00D9FF,color:#fff
style GATE fill:#F7931E,stroke:#FBA225,color:#fff
style VOBO fill:#2ecc71,stroke:#27ae60,color:#fff
style HUM fill:#FB6C25,stroke:#FBA225,color:#fff
style PROD fill:#8e44ad,stroke:#a569bd,color:#fff
一条关键原则：最好的资源不该执行最便宜的工作。 Opus 4.8 在 Terminal-Bench 2.1 中以 85.0 分领先——用它批量改写 40 个 SEO 标题是浪费。GLM-5.2 拥有 100 万 tokens 上下文，成本约为三分之一，SWE-bench Pro 得分 62.1（高于 Gemini 3 Pro 的 54.2）。批量代码手术选 GLM，验证诚实性并决定 GREEN 选 Opus。
4. 模型/任务矩阵
quadrantChart
title 模型 vs 任务（2026 年 7 月）
x-axis "低成本 ←" --> "→ 高成本"
y-axis "单模态 ←" --> "→ 多模态（视频/图像）"
quadrant-1 "关键验证"
quadrant-2 "视觉 QA · UX · 素材"
quadrant-3 "代码量产"
quadrant-4 "编排 · 闸门"
"Opus 4.8": [0.80, 0.30]
"GLM-5.2": [0.20, 0.20]
"Gemini 3 Pro": [0.55, 0.85]
"Mistral Vibe": [0.25, 0.35]
5. 分阶段管线：做了什么，按何顺序
所有工作被组织为 6 个编号阶段（0 到 5）。每个阶段都有一个运营负责人（某个模型或某个人）、一份物理交付物，以及碰生产前的人工闸门。
gantt
title SEO/GEO/AEO 管线 · Transgenia · 2026-Q3
dateFormat YYYY-MM-DD
axisFormat %d %b
section 阶段 0 · P0 SEO
Title · meta · FAQPage EN :done, f0a, 2026-07-09, 2d
llms.txt 强化 Odoo :done, f0b, 2026-07-09, 1d
Hero H1 含 Odoo（三语） :done, f0c, 2026-07-10, 2d
section 阶段 1 · 身份
Badge "Registered" 三语 :done, f1, 2026-07-10, 2d
section 阶段 2 · 内容
已验证事实包（19 条） :done, f2a, 2026-07-11, 1d
EN 草稿（采用 + 定价） :done, f2b, 2026-07-11, 2d
ES + ZH 翻译对等 :done, f2c, 2026-07-11, 2d
section 阶段 3 · 行业
/clinics 支柱页（三语） :done, f3a, 2026-07-12, 1d
/trading-companies 支柱页 :done, f3b, 2026-07-12, 1d
24 页面加入"Sectors"导航 :done, f3c, 2026-07-12, 1d
section 阶段 4 · 权威
公开 VORANTIS 研究 :active, f4a, 2026-07-14, 3d
外链拓展（Antoni） :f4b, after f4a, 7d
section 阶段 5 · 合作伙伴网络
从 Registered 升到 Select 层 :f5, 2026-07-15, 30d
每个阶段有一条硬规则：如果可观测效果没有到生产，就不能进入下一个阶段。一个"已 commit 但未部署"的修复不算完成。这条规则看似显然；然而它是我们 6 月学到的最昂贵的一课（见 §7）。
6. 闸门纪律：草稿 → 验证 → GREEN → 部署
任何改动都不能未经由 Opus 4.8 提供信息的人工闸门就到达生产。闸门不是仪式性签字：它是带真实 URL、缓存打破与被引用 HTML 证据的实时验证。
flowchart LR
D1["执行者提交
草稿 + 证据"] --> V1{"Opus 实时
验证"}
V1 -->|"数字对照
引用来源"| C1{"零
编造?"}
V1 -->|"取 URL PROD
加缓存打破"| C2{"可观测
效果?"}
V1 -->|"客户
已匿名"| C3{"逐案
具名签核?"}
C1 --> AGG{"全部
绿?"}
C2 --> AGG
C3 --> AGG
AGG -->|是| GREEN(["GREEN
可签核"])
AGG -->|否| REJ(["RED
退回执行者"])
GREEN --> HUM["Saurat
明确 VoBo"]
HUM --> MERGE[(Merge · 部署)]
REJ -.-> D1
style V1 fill:#004E89,stroke:#00D9FF,color:#fff
style GREEN fill:#2ecc71,stroke:#27ae60,color:#fff
style REJ fill:#e74c3c,stroke:#c0392b,color:#fff
style HUM fill:#FB6C25,stroke:#FBA225,color:#fff
style MERGE fill:#8e44ad,stroke:#a569bd,color:#fff
一个真实的循环例子：某模型交付了一份"孤儿贴文"分析，并建议将其去孤儿化并发布。Opus 的闸门通过实时抓取发现，这些帖子按设计带有 <meta name="robots" content="noindex">（它们是被特意停放的 Tier-2 草稿），并含有 [[REDACT: …]] 占位符。发布将向用户与 Google 提供薄弱内容。闸门驳回该提议并重新界定：它们不是意外孤儿；它们是尚待完成的草稿。编辑决策交由 Saurat。
7. 零编造：以事实包为运营原则
在一个模型以与生成正确段落相同的节奏产生幻觉数字的行业里，唯一的防线是对数字与日期保持单一真相来源。
sequenceDiagram
autonumber
participant U as Saurat
（负责人）
participant O as Opus 4.8
（编排者）
participant R1 as 研究员 1
participant R2 as 研究员 2
participant V1 as 对抗性验证员 1
participant V2 as 对抗性验证员 2
participant FP as fact-pack.md
（单一来源）
U->>O: 我需要 20 条可验证的 X 事实
O->>R1: 找 10 条并附来源 URL
O->>R2: 独立找 10 条并附来源 URL
R1-->>O: 10 条 + 来源
R2-->>O: 10 条 + 来源
O->>V1: 打开每个 URL，逐字引用
O->>V2: 打开每个 URL，尽力反驳
V1-->>O: 18 确认 · 2 驳回
V2-->>O: 17 确认 · 3 驳回
O->>O: 求交集
+ 细微备注
O->>FP: 撰写事实包
19 条可引用事实
FP-->>U: 所有草稿的
唯一输入
Note over FP: 如果草稿要求
事实包中不存在的数据：
写定性表述
或 "（数据不可用）"。
永不发明。
在 7 月的真实循环中，"拉美 AI 采用"与"AI 供应商定价"两篇文章的事实包共记录 19 条已核实事实，每条都附一个指向一级来源的直接 URL（WEF+McKinsey、CEPAL、SAP LatAm、Stanford HAI、IMF、Anthropic/OpenAI/Odoo 官方定价）。零个由模型自行添加的"上下文"数字。研究员提出的两个数字因不满足引用标准，被对抗性验证员驳回。
8. 昂贵的一课：只在 worktree 而未部署 = 效果为零
以上整套架构因一个具体原因而设计：在上一波，某个模型交付了技术上无可挑剔的 P0——重写标题、加入 FAQPage、强化 llms.txt——所有内容却停留在一个未 commit 的 worktree 中。中央仓库没有变化，生产也没有变化。/goal 又停滞一周。
flowchart LR
subgraph WT ["本地 worktree"]
F1["正确
编辑文件"]
end
subgraph GIT ["Git · 仓库"]
F2["commit · push"]
end
subgraph GH ["GitHub · PR"]
F3["Merge 到 main"]
end
subgraph PRD ["服务器 · nginx"]
F4["git pull + reload"]
end
subgraph EFE ["可观测效果"]
F5["活 URL
缓存打破
取回确认"]
end
F1 -.->|"❌ 缺此步
= 工件"| F2
F2 -.->|"❌ 缺此步
= 工件"| F3
F3 -.->|"❌ 缺此步
= 工件"| F4
F4 -.->|"❌ 缺此步
= 工件"| F5
F1 --> F2 --> F3 --> F4 --> F5
style F5 fill:#2ecc71,stroke:#27ae60,color:#fff
style F1 fill:#e74c3c,stroke:#c0392b,color:#fff
自这一课起，直到生产 URL 带 ?v=<时间戳> 缓存打破返回包含更改片段的 HTML，任何工作都不能被宣布"完成"。没有例外。这适用于博客、支柱页、robots.txt、外链：如果 Google、ChatGPT 或 Claude 实际能看到的表面没有可观测效果，工作就不算数。
9. 如何应用到贵公司
以上所有内容并非中型 Odoo 咨询公司的专利。相同纪律适用于 2026 年任何决定认真对待自己数字存在的中小或中型企业：
- 定义一个可衡量的 /goal。 如果你无法用一个指标与一个日期写下你的目标，你没有目标。你有的是愿望。
- 接受有三个引擎，而非一个。 2026 年只优化 Google 会漏掉买家真实旅程的三分之二。
- 编排，不要独裁。 最好的写作模型不一定是最好的验证模型。按能力拆分工作，能同时降低成本与提高质量。
- 坚持人工闸门。 AI 提议，人类批准。反过来不行。闸门纪律正是阻止写得漂亮的烟雾被发表的原因。
- 永远零编造。 附可引用 URL 的事实包，是抵御自信幻觉的唯一防线。
- 度量效果，而非工件。 worktree、commit、PR 与 merge 都是手段。唯一的目的，是用户与引擎能看到的表面上的可观测效果。
这正是我们为希望在自己领域复制这套纪律的客户所做的工作。AI 解决方案 页面描述了它如何应用于特定行业。
常见问题
2026 年传统 SEO 是否仍然有意义？
仍然有意义，且仍是基石。不在 Google 排名的站点几乎从不被聊天机器人引用——模型对"何为权威"的学习，很大程度来自与 Google 相同的信号。区别在于 2026 年，SEO 已经不够。
GEO 究竟是什么，与 AEO 有何不同？
GEO（生成引擎优化）致力于让贵公司被生成引擎作为来源引用（ChatGPT、Perplexity、SGE）。AEO（回答引擎优化）更进一步：致力于让引擎的回答直接给出贵公司在做什么或是谁，而不迫使用户点击。GEO 赢得引用；AEO 赢得直接回答。
为什么使用四个模型而非只用最好的那个？
成本、能力与诚实。质量领先的模型（Opus 4.8）同时也是最昂贵的；用它批量改写 40 个标题是浪费。拥有 100 万上下文与低价的模型（GLM-5.2）适合代码手术，但不应由它决定何为可诚实发表。编排就是让质量与成本兼得而不降低标准的方式。
什么是"人工闸门"？为什么自动批准还不够？
人工闸门是管线中的明确节点，由知情的人——通常是 /goal 或项目的负责人——在改动碰到生产之前签核。没有人工闸门，模型的错误（幻觉、虚高数字、与品牌矛盾）会到达终端用户。闸门不是摩擦；它是你可以在不打破东西的前提下快速推进的原因。
看到 /goal 结果需要多久？
取决于起点。域权重低且没有新外链的站点，可能在 4–8 周内看到已在第二页排名关键词的位置移动。在聊天机器人被引用通常需要在被模型视为权威的来源中持续存在数月。"两周见效"几乎永远是烟雾。
如果我的公司既没 SEO 也没 GEO，该如何开始？
按顺序。首先，诚实诊断已经（哪怕部分）捕获了哪些关键词。其次，写一个带日期的可衡量 /goal。第三，技术类 P0——titles、meta、llms.txt、允许 Cloudflare 上的 AI 爬虫、正确的 sitemap。第四，配备事实包的支柱内容。赢得三个引擎，从不打破第一个开始。