开发者与 Agent
让文档、检测规则和修复任务共用一套问题定义
先说结论
如果教程叫“robots、noindex、canonical 各自控制什么”，检测器输出“index score 62”，工单又写“SEO 有问题”，团队就无法确认三者是否在说同一件事。
解决办法是建立一套稳定的问题模型，让：
文档解释规则 → 检测器产生问题实例 → 工单执行修复 → 复核关闭问题一、先区分规则和问题实例
**规则（Rule）**是长期定义：
ruleId: indexability.noindex-core-page
name: 核心页面被 noindex
condition: 核心公开页面存在 noindex 指令
severityDefault: high**问题实例（Issue）**是某次检查在某个对象上发现的事实：
issueId: ISSUE-2026-0104-001
ruleId: indexability.noindex-core-page
subject: https://example.com/pricing
observedAt: 2026-10-04T09:00:00Z
status: confirmed规则可以多年复用；问题实例必须带时间、对象和证据。
二、推荐的问题定义
ruleId: indexability.noindex-core-page
version: 1.2.0
title: 核心公开页面被 noindex
category: indexability
intent: 该页面应可被搜索系统索引
appliesWhen:
- 页面属于公开核心转化路径
check:
- 检查最终响应头 X-Robots-Tag
- 检查渲染后 HTML robots meta
passCondition:
- 两处均没有 noindex
failCondition:
- 任一有效指令包含 noindex
insufficientWhen:
- 页面无法访问或无法获得最终响应
severityDefault: high
recommendation:
- 先确认业务意图，再移除意外 noindex
verification:
- 重新抓取并检查响应头与渲染 HTML
references:
- https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag关键字段不是为了“格式漂亮”，而是为了避免自动化在模糊处自行补答案。
三、文档如何引用同一规则
文章正文可以面向普通读者解释：
noindex像“不要把这页放进搜索结果”的指令。它不是登录保护，也不阻止别人访问页面。
技术区则引用：
规则 ID：indexability.noindex-core-page
适用对象：应公开索引的产品、定价、文档页面
自动检查：响应头 + 渲染后 HTML这样读者、检测程序和开发工单都能定位到同一规则。
四、修复任务不要丢失证据链
## 修复任务
- Issue ID：ISSUE-2026-0104-001
- Rule ID：indexability.noindex-core-page@1.2.0
- 对象：https://example.com/pricing
- 证据：最终 HTML 包含 `<meta name="robots" content="noindex">`
- 业务意图：公开且应可索引
- 建议：移除布局模板中的意外 noindex
- 负责人：
- 变更链接：
- 发布时间：
- 复核条件：最终响应与渲染 HTML 均不再包含 noindex
- 复核结果：待验证“已改代码”不是关闭条件；问题必须在目标环境按原规则复核。
五、状态机要统一
observed → confirmed → planned → changed → verified → closed
↘ rejected
observed → insufficient_data建议状态：
| 状态 | 含义 |
|---|---|
observed | 有初步迹象，尚未完成确认 |
confirmed | 证据满足规则失败条件 |
planned | 已确认修复方案与负责人 |
changed | 已执行变更，尚未复核 |
verified | 按原规则复测通过 |
closed | 记录完整并正式关闭 |
rejected | 经业务或技术判断不修复，并记录原因 |
insufficient_data | 证据不足，不能判断 |
不要把 changed 自动等于 fixed。
六、版本为什么重要
以下变化都可能要求升级规则版本：
- 平台官方说明改变；
- 检测条件改变；
- 严重程度定义改变；
- 数据字段或时间口径改变；
- 复核方法改变。
报告至少保存 ruleId + version。否则半年后无法解释为何同一页面得到不同结论。
七、MCP 在这里负责什么，不负责什么
MCP 可以承载：
- 获取规则 Resource；
- 调用检测 Tool；
- 用 JSON Schema 约束参数；
- 返回结构化 Issue；
- 创建或更新任务。
MCP 不会自动解决：
- “核心页面”在业务上如何定义；
- Google 展示、第三方采样和收入是否同一指标；
- 某个问题严重程度应是多少；
- 一次变化是否构成因果。
协议可以统一传输格式，只有治理才能统一含义。
可直接复制的问题实例模板
## 问题实例
- Issue ID：
- Rule ID / Version：
- 标题：
- 对象：
- 观察时间：
- 状态：observed / confirmed / insufficient_data
- 严重程度：critical / high / medium / low
### 证据
| 来源 | 范围 | 事实 | 限制 |
|---|---|---|---|
| | | | |
### 影响
- 已确认影响：
- 可能影响：
- 不能确认的事项：
### 修复
- 建议动作：
- 负责人：
- 审批人：
- 变更链接：
### 复核
- 相同条件：
- 成功标准：
- 结果：待验证 / 通过 / 未通过 / 数据不足本篇行动清单
- 为每类问题分配稳定
ruleId； - 分开规则定义和问题实例；
- 统一证据、状态和严重程度字段；
- 文档、检测器和任务引用同一版本；
- 保留事实、推断和未知；
- 变更后按原条件复核；
- 规则调整时留下版本记录。
最后更新于