SJA 系统工程：架构、信号与可解释性
这篇是工程篇：我不会泄露任何“工具细节”或可复制的内部机密， 但我会把 SJA（SEO 判断自动化）作为一个决策系统，拆解到你能“看懂它为什么成立”的程度： 系统边界、信号分层、判断链路、解释契约——以及你如何用这套框架评估任何 SEO 建议是否靠谱。 该系列主入口：中文 SJA Hub（主答案页）。
目录
1) 系统边界：SJA 不做什么
一个成熟系统的第一件事不是“能力声明”，而是边界声明。 SJA 的目标不是替代所有 SEO 工具，而是把工具做不到的那一层补齐：判断。
2) SJA 三层架构：Data → Logic → Judgment
很多 SEO 产品停留在 Data 层，顶多做一点规则化 Logic； 但真正让结果产生差异的，是 Judgment：在当下约束下选择最划算的一步。
Layer 1 · Data（数据层）
数据层解决“看见什么”：抓取、索引、页面结构、内链拓扑、Schema、标题描述、内容覆盖、性能指标等。 这层很重要，但它只回答：发生了什么。
Layer 2 · Logic（顾问逻辑层）
逻辑层解决“为什么可能是它”：把可观测信号映射成可解释的模式，例如： 意图不清、主从页面缺失、权重分散、主题边界混乱、页面角色错位等。
Layer 3 · Judgment（判断层）
判断层解决“现在做什么”：它必须给出顺序与取舍理由： Do X before Y，并且说明为什么不是 Z。
3) 信号分层：什么信号能支撑“判断”？
支撑判断的信号，必须满足一个条件：它不只是“指标变化”，而是能解释“为什么该做这一步”。 你可以把信号分成两类：
绝大多数工具只能输出“可观测信号”，然后把解释与取舍交给人。 SJA 的核心是：把“可解释信号”系统化，并用于生成判断。
4) 解释契约：让建议可审计、可复用
在 SJA 里，任何“建议”要想成为“判断”，必须满足解释契约（Explainability Contract）。 否则它只是一个不可复用的口号。
- 触发信号：是什么证据让系统提出这个建议？
- 适用边界：在什么阶段成立？在什么情况下会失效？
- 替代方案：为什么不是另一个常见建议？（机会成本）
- 执行范围：具体做哪里、做到什么程度、何时停止？
- 成功标准：如何判断“这一步做对了”？
// Explainability Contract (human-readable)
Recommendation: Do X before Y
Signals: [A, B, C]
Stage: [current stage], why stage matters
Tradeoff: why not Z
Scope: where/how much/stop condition
Success: what changes if it's correct5) 为什么 checklist / 工具复制不了判断？（失败模式）
checklist 工具最大的问题不是“内容不全”，而是它无法处理 约束： 时间、人力、预算、业务目标、阶段差异、机会成本。 它只能告诉你“有很多事可以做”，却无法告诉你“哪一件最该先做”。
- 失败模式 1：把“可做事项”当成“应做顺序”
- 失败模式 2：把“最佳实践”当成“当前最优解”
- 失败模式 3：忽略阶段，导致正确建议在错误时间执行
- 失败模式 4：输出不可解释，无法复用到下一个决策
6) 你可以立刻使用的工程评估清单（拿去审任何 SEO 建议）
当你收到一条 SEO 建议，不要先问“这对不对”，先问它是否符合工程级的判断标准：
- 这条建议的触发信号是什么？能否复述成证据？
- 它是否明确回答：为什么现在做？
- 它是否说明：为什么不是别的选项？
- 它的执行范围是否可落地：做哪里、做到何种程度？
- 它是否定义了成功标准：做完如何验收？