一句话结论：AI 可见度不是一个岗位，是四类天然分属不同团队的活——定义与测量、内容与信源生产、站点与实体地基、异常处置。把它们塞进一个「GEO 专员」，最后必然退化成只剩发稿。可执行的做法是：整件事设一个唯一的 A（最终担责人，通常是市场/品牌负责人），四类活各派 R，用一张 RACI 表把边界写死；并且测量侧背的数必须是「口径不变」，不能是「提及率提升」——定义分母的人不能同时被分母考核。下面给出 12 行的分工表、各角色该背和不该背的数、月度节奏，以及最常没人认领的那一格。
这篇写给谁：已经决定要做 AI 可见度、但卡在「这事挂谁头上、用什么数考核」的甲方内部——通常是市场/品牌负责人，或者被老板问到「所以这个数是谁的 KPI」的那个人。
不是招聘文。本文不讨论该招几个人、给什么薪资编制，也不转述任何招聘稿里的薪资数字。它讨论的是你现有的这几个团队怎么分。
和另外两篇的分界线：代运营公司怎么交 GEO 月报 讲机构对外怎么交付，本文讲甲方内部怎么分工，两篇互为镜像；GEO 服务商怎么选、怎么验收 讲外部怎么验，本文讲内部谁来验。
一、中文侧只有「招什么人」的答案，没有「现有的人怎么分」的答案
这不是一个冷门问题，但它在中文互联网上确实还没有企业侧的答案。
搜「AI 可见度 谁负责 / GEO 岗位职责 / 市场部 KPI」，返回的头部清一色是招聘侧内容：知乎《2026 年，你要招的第一个岗位：GEO 优化专员（附详细岗位 JD）》、知乎《GEO 优化专员（AI 大模型搜索结果方向）岗位 JD》、CSDN《生成式引擎优化（GEO）岗位技能需求分析》、阿里云开发者社区《GEO 岗位数据分析：20 份 JD 拆解与 AI 搜索优化师能力模型解析》、电鸭社区的 GEO 运营专员招聘帖。再往下，中文结果凑不满一页，SERP 直接掉到英文的 KPI 稿（HubSpot《Generative engine optimization KPIs that actually matter for marketing teams》、Similarweb《GEO KPIs: How To Measure The Right GEO Metrics》）。
换个问法更能说明问题。 我们在 2026-09-09 检索「GEO 负责人 企业设立 谁来负责 市场部 公关部 分工」，返回的整页是通用的《市场部主要岗位设置及工作职责》、《品牌部与市场部，职能都有啥区别？》这类前 AI 时代的部门职责文——搜索引擎找不到与 GEO 相关的分工内容，只能退回到最接近的通用词条。
再看那些 JD 写了什么。多份公开 JD 把 GEO 优化专员的核心职责写成「全网多渠道发稿布局：在自媒体、新闻源、行业论坛、博客等平台发布内容，形成跨平台信息矩阵」（知乎 JD 原文、艾奇在线转载版）。这是把 GEO 直接等同于内容代发。
这就是问题所在：
- 谁来定义提及率的分母？ JD 里没有。
- 谁来跑基线、谁保证跨周期口径不变？ JD 里没有。
- 官网上的产品参数和天猫店对不上，算谁的？ JD 里没有。
- AI 说了你公司一句错的，谁在 24 小时内知道？ JD 里没有。
一家公司真正卡住的，不是招不到人，是不知道这件事该挂在谁头上、用什么数考核。 没人负责的事，不会有人去测它，更不会有人在第二个月替它辩护预算。
二、先拆活，再谈岗位：它其实是四类活
把「AI 可见度」当成一个岗位，是所有分工失败的起点。它至少是四类活，每一类需要的能力、汇报对象、和交付物都不同：
| # | 这类活 | 具体做什么 | 天然属于谁 | 做不好的直接后果 |
|---|---|---|---|---|
| ① | 定义与测量 | 提问集设计与冻结、分母定义、基线、采样规则、工具选型 | 市场/品牌负责人（或数据分析） | 数字不可比，所有后续讨论失效 |
| ② | 内容与信源生产 | 可被引用的内容、第三方信源布局、竞品差距选题 | 内容 / PR / SEO | 引擎没料可引，答案里只有竞品 |
| ③ | 站点与实体地基 | 官网结构化事实、实体信息一致性、爬虫可访问性 | SEO / 官网 + 技术运维 | AI 拿到互相打架的事实，索性跳过你 |
| ④ | 异常处置 | 错误信息纠错、负面处置、品牌词被劫持 | 公关 / 品牌 | 发现时已经传播了两周 |
为什么塞进一个人就会退化成发稿：这四类活里，只有 ② 的门槛最低、最容易外包、最容易被立刻看到「我干了活」。① 是脑力活且短期没有可见产出，③ 要跨部门推动，④ 平时是零、出事是一百。所以一个人扛四类活时，压力会自动把他推向 ②——这不是执行力问题，是任务分配结构的必然结果。
一条容易被忽略的前提：在拆分工之前，先确认你们测的是对的那个面。同一个引擎的 API 面、网页面、手机 App 面，答案与引用来源不是同一套（拆解见豆包的 API、网页、App 引用不是同一套）。分工表可以重写，测错了面的一整年数据不能。该测哪几个引擎见该测哪几个 AI 引擎才够。
三、RACI 分工表（可以直接抄走的那张）
先对齐四个字母（这套记法出自项目管理，不是我们发明的）：
- R = Responsible（执行）：真正动手干这件事的人，可以有多个。
- A = Accountable（担责）：最终对结果负责、有权拍板的人，每行有且只有一个。
- C = Consulted（咨询）：动手前必须问过、其意见会改变做法的人。
- I = Informed（知会）：结果出来后要被告知，但不参与决策的人。
「每行只有一个 A」是这张表唯一的硬规则。 一行两个 A 等于没有 A——出事时两边都能指向对方，而且都站得住。
| # | 具体活儿 | 市场/品牌负责人 | SEO / 官网 | 内容团队 | 公关 | 技术运维 | 法务 / 合规 | 交付物 |
|---|---|---|---|---|---|---|---|---|
| 1 | 提问集设计与冻结 | A·R | C | C | C | – | – | 提问集清单 + 冻结日期 |
| 2 | 提及/推荐的判定口径与分母定义 | A·R | C | I | I | – | – | 一页口径文档 |
| 3 | 基线采集与采样规则 | A·R | I | I | I | – | – | 基线快照（原始答案留档） |
| 4 | 工具选型与续费决策 | A | C | I | I | C | C | 记分卡 + 合同条款 |
| 5 | 可被引用的内容生产 | C | C | A·R | R | – | C | 内容排期 + 上线清单 |
| 6 | 第三方信源布局（媒体/知乎/公众号） | C | I | R | A·R | – | C | 信源矩阵表 |
| 7 | 竞品对照与差距选题 | A | C | R | C | – | – | 月度差距清单 |
| 8 | 官网结构化事实（参数/价格/资质） | C | A·R | R | I | C | C | 事实源单一出处 |
| 9 | 实体地基（工商/百科/地图/资质） | C | A·R | C | R | – | C | 实体信息核对表 |
| 10 | 爬虫可访问性（robots / UA 放行 / 日志） | A | R | – | – | R | – | 放行清单 + 月度日志核对 |
| 11 | 错误信息纠错 | C | R | R | A·R | – | C | 纠错工单 + 复测记录 |
| 12 | 负面 / 品牌词被劫持处置 | I | C | C | A·R | – | C | 分级响应记录 |
读这张表的三个要点：
- A 高度集中在三个人身上——市场/品牌负责人（5 行）、SEO/官网（2 行）、公关（3 行）。这是有意的：A 太分散，等于没有人对整件事负责；A 全归一个人，第 ③ 类活推不动。
- 法务只出现在 C，不出现在 A/R。资质表述、行业禁用语、工商信息的对外口径必须过一遍法务，但这件事不该由法务推动，否则会变成纯风控。
- 第 10 行是唯一 R 在技术侧的行，也是最容易出事的一行——下一节展开。
三个动作的展开链接
上表里最需要方法而不是分工的三行，已有专文：
- 第 1、3 行（提问集与基线）：题目怎么配比、写多少条、每条跑几次才算数，见GEO 监测的提问集怎么设计；拿到第一批数字之后怎么判断高低，见提及率 18% 算高还是低。
- 第 11、12 行（处置）：错误信息按引擎分信源怎么改，见AI 把我公司信息说错了怎么改；负面怎么定级与处置，见AI 答案里出现品牌负面怎么办；搜品牌词却推竞品的排查顺序，见搜我的品牌名，AI 却在推竞品。
- 第 10 行（爬虫）：国内 AI 爬虫的 UA 与验证清单，见怎么从服务器日志确认豆包、元宝真的抓过你的站。
四、各背哪个数：这一节比分工表更容易出事
分工表解决「谁干」，KPI 解决「怎么算干好了」。后者定错，前者写得再细也会被绕过。
| 角色 | 该背的数 | 明确不该背的数 | 为什么 |
|---|---|---|---|
| 市场/品牌负责人（A） | 整体提及率 / 推荐率 / 声量份额的趋势，分引擎看 | — | 他是唯一该对结果负责的人 |
| 测量侧（定义提问集与分母的人） | 口径不变：提问集变更留痕率、分母定义文档完整度、采样规则跨周期一致、原始记录可导出复核 | ⛔ 提及率高低 | 分母在他手里，考核他分母就是请他改分母 |
| 内容团队 | 可被引用的信源产出量：新增被 AI 引用的 URL 数、被引来源的站点多样性 | ⛔ 发稿条数 | 发稿数与被引用无因果，且极易刷 |
| SEO / 官网 | 结构化事实一致性：事实源单一出处覆盖率、官网与第三方渠道的参数冲突数（越低越好）、AI 爬虫可访问率 | ⛔ 自然搜索排名 | 那是另一件事的 KPI，会挤走这件事 |
| 公关（处置侧） | 响应时长：从异常出现到被发现的小时数、从发现到处置动作落地的小时数、复测确认闭环率 | ⛔ 负面出现次数 | 考核出现次数 = 鼓励瞒报 |
| 技术运维 | AI 爬虫放行清单的执行准确率（变更后仍可访问） | ⛔ 任何可见度指标 | 他既不控内容也不控口径 |
为什么「测量侧不背提及率」是这一节的核心
提及率的定义是：
提及率 = 被提及的采样次数 ÷（提问条数 × 采样次数）分母的三个组成部分，全部握在定义提问集的那个人手里。 如果他同时被「提及率提升」考核，最省力的路径不是做优化，而是：
- 把品牌词在提问集里的比例调高（问「XX 品牌怎么样」，任何品牌的提及率都接近满分）；
- 把跑不动的品类词、对比词悄悄换掉；
- 把每条题的采样次数调小（分辨率一降，噪音就能被读成上涨）。
这三步每一步都合规、都能给出正当理由，但结果是读数系统性变好而生意没变。这类失真事后极难追责，因为你手上没有「口径没变」的证据。
所以正确的做法是把裁判和运动员分开：测量侧的 KPI 全部是过程性的、可核对的——提问集变更有没有留痕、分母定义有没有写在文档里、原始记录（完整答案文本 + 引用来源 URL + 时间戳 + 引擎与取数面标记）能不能随时导出复核。这四项做到，提及率才是一个可以被讨论的数；做不到，它只是一张图。
⚠️ 一个高价值的小动作：留一组不告诉内容和外包团队的对照题，照常监测。如果投放词和对照题一起涨，涨的是行业热度，不是这笔钱的效果。这组题的所有权必须在 A 手里。
五、最常没人认领的那一格：站点与实体地基
分工表里最容易出现「双 A 或零 A」的是第 8、9 行。原因很具体：它横跨两个部门之间的空隙。
- 内容侧看它：这是技术活（结构化数据、robots、日志、schema），不归我。
- 技术侧看它：这是内容活（产品参数、资质、公司简介文案），不归我。
- 而工商信息、百科词条、地图 POI 这类实体信息，在很多公司干脆挂在行政或法务名下，几年不动一次。
于是就出现了这个结果：AI 拿到的关于你公司的基础事实是互相打架的。 公司主体名（全称 vs 简称 vs 曾用名）、成立年份、业务范围、注册资本、产品参数、价格区间、门店地址——官网一个版本、天猫店一个版本、公众号简介一个版本、工商信息又一个版本。引擎面对冲突事实时只有两种做法：选一个说（可能选错），或者整个跳过你（更常见）。
这一层现在正在被主动喂进 AI，不再是「顺带被抓到」。一个可核对的锚点：企查查在 2023 年 7 月发布了商查大模型「知彼阿尔法」（新华网江苏频道报道、新浪科技报道），并已上线面向智能体的企查查智能体数据平台，其公开表述正是要解决大模型在企业信息上「实体混淆、信息编造、解读过时」这类问题。换句话说，工商数据方已经把自己接成了 AI 的事实源——你的实体信息准不准，不再只影响做尽调的人。
建议的归属：第 8、9 行的 A 明确挂在 SEO / 官网负责人头上（他是唯一同时懂结构化和内容的角色），法务列为 C（工商与资质表述必须由他们确认），公关在第 9 行做 R（百科、媒体资料库这类需要外部沟通的动作）。
一份可以直接跑的实体地基核对表
| 检查项 | 对齐到哪个版本 | 谁执行 | 频率 |
|---|---|---|---|
| 公司全称 / 简称 / 曾用名 | 工商登记为准，官网页脚与「关于我们」同步 | SEO | 季度 |
| 成立年份、注册资本、业务范围 | 工商登记为准 | SEO（法务确认） | 季度 |
| 百科词条的基础字段 | 与官网一致，冲突处优先改官网还是词条要先定 | 公关 | 季度 |
| 产品名 / 型号 / 核心参数 | 单一事实源：定一个主站页面，其余渠道引用它 | SEO + 内容 | 每次改版 |
| 价格与套餐结构 | 官网定价页为准 | 内容 | 每次调价 |
| 门店 / 办公地址、电话（地图 POI） | 工商 + 实际经营地一致 | 行政（SEO 复核） | 半年 |
| 资质、许可、认证的表述 | 证书原件为准，表述由法务定 | 法务 | 每次新增 |
⚠️ 这张表的重点不是「填满」，是「定死单一事实源」。同一个参数有两个权威出处，冲突就一定会回来。纠错的具体做法（分引擎该改哪个信源）见AI 把我公司信息说错了怎么改。
顺带说第 10 行：运维 ban 掉 AI 爬虫，责任在 A 不在运维
运维看到一个陌生 UA 高频抓站、按旧规则把它拦掉，这是完全正确的运维行为。问题在于没有任何人告诉他：这批 UA 现在和品牌能不能进 AI 答案直接相关。
所以第 10 行的设计是 R 在运维、A 在市场负责人、C 在 SEO——由 A 负责把「AI 爬虫放行清单」写进运维的变更检查项，而不是指望运维自己知道。UA 清单与验证方法（含「UA 可伪造、白名单应以 IP 段为准」这个安全前提）见怎么从服务器日志确认豆包、元宝真的抓过你的站。
这张 RACI 表真正防的，就是这种情况：每个人都按自己的岗位做对了事，合起来的结果是错的。
六、月度节奏：谁在什么时候看哪张表
分工表定「谁」，节奏表定「什么时候」。没有节奏，RACI 会在第二个月自然失效。
| 频率 | 谁 | 看什么 | 触发什么动作 |
|---|---|---|---|
| 每周 | 公关（处置侧） | 异常清单：新出现的错误描述、负面、品牌词被劫持 | 分级，超过阈值当天启动处置 |
| 每周 | 内容团队 | 本周新增的被引来源 URL；竞品新增被引来源 | 下周选题从差距里出 |
| 每月 | 市场负责人（A） | 分引擎的提及率 / 推荐率 / 声量份额，与上期、与基线两列对比 | 判断是波动还是趋势 |
| 每月 | 市场负责人（A） | 口径核对：提问集有没有被改过、采样规则有没有变 | 改过就必须新旧并行一期 |
| 每季 | SEO / 官网 | 实体地基核对表 + 爬虫日志 | 冲突项归零 |
| 每季 | A + 老板 | 投入产出：AI 引荐流量与其转化质量 | 续费 / 扩量决策 |
两条落地经验：
- 月度会上第一个议题必须是「口径有没有变」，不是「数字涨了没」。 顺序反过来，会议会立刻退化成解释数字，而没人再关心数字可不可比。
- 季度那一行需要一个前置动作：把 AI 引擎带来的流量识别出来，否则「值不值」这个问题永远只能靠感觉答。做法见豆包、元宝、夸克带来的流量怎么统计。
七、三种常见组织的落法
同一张表，规模不同落法不同。表不变，人可以重。
① 10–30 人的创业公司（1 个市场同学 + 半个技术） 12 行活可能只落在 3 个人头上，这是正常的。唯一不能重的是一处：第 1–3 行的 A 不能和第 5–6 行的 A 是同一个人——自己出考卷、自己判卷，这份数据对内对外都没有说服力。如果实在只有一个人，就把「口径」这件事外置：提问集、分母、采样规则写进一份老板随时能看的文档，原始记录保持可导出。
② 有成熟 SEO 团队的品牌方 最大的风险不是没人干，是SEO 顺手把这件事全接了，然后用 SEO 的思路做（盯排名、盯收录、盯外链）。这会漏掉第 ④ 类（处置）和第 6 行（第三方信源），而这两块在中国引擎里权重很高——元宝依赖微信生态内容（见微信公众号内容怎么进腾讯元宝的答案），这不是 SEO 团队的传统战场。建议：SEO 拿第 8–10 行的 A，第 1–4 行的 A 留在市场负责人手里。
③ 外资品牌的中国分公司 分工表要多一列：总部。典型冲突是——总部买了一套只覆盖 ChatGPT / Perplexity / Gemini 的全球工具，中国区的真实战场（豆包、元宝、百度 AI 的 App 面）一格数据都没有。这时候中国区要争的不是预算，是第 1–3 行的 A：提问集、分母、采样规则必须允许中国区自己定义一套并行的，否则汇报进全球看板的数字对中国生意毫无指示意义。覆盖差异见海外 AI 可见度工具在中国的盲区，测法见如何监测品牌在国内 AI 搜索里的可见度。
八、四个典型失败模式
| 失败模式 | 表面现象 | 真正的缺口 | 修法 |
|---|---|---|---|
| 挂在实习生头上 | 每周交一份截图 PPT，三个月后没人看 | 有 R 没有 A——没人有权推动跨部门动作 | A 必须是能调动内容与技术的人 |
| 测量和内容是同一个人 | 数字一路走高，但询盘没变 | 分母被改过，且无留痕 | 拆开；至少把口径文档外置 |
| 公关最后一个知道 | 负面已传播两周才被发现 | 第 12 行没有 R，或异常没进公关的周会 | 处置侧接入每周异常清单 |
| 谁都不背，续费时被砍 | 「这个东西到底证明了什么？」答不上来 | 缺第 6 节季度那一行 | 上线第一天就把基线和引荐流量口径立起来 |
第二行值得多说一句。它的隐蔽之处在于：当事人往往没有恶意——他只是在「让数字好看」和「让数字准确」之间，被 KPI 推向了前者。这是设计问题，不是人品问题。
九、权限模型会决定分工能不能落地
一个经常在落地时才被发现的约束：你的监测工具的权限粒度，会直接限制这张 RACI 表能不能实现。
多数工具的团队成员是按账号邀请的——成员一旦加入，就能访问该账号下的全部工作区。以我们自己为例，GeoEcho 的成员权限就是账号级。这在这篇的语境下有两个直接后果：
- 好的一面：一个品牌方内部团队，市场、内容、SEO、公关同处一个账号，看到的是同一份数据、同一套口径——这正是 RACI 表想要的效果。统一口径的最低成本实现方式，就是让所有角色看同一个后台。
- 要注意的一面：如果你同时在管多个品牌 / 多个事业部，并且不希望 A 事业部的人看到 B 事业部的数据，就要在采购时把这一条问清楚（对应记分卡里的维度 2 与权限粒度）。给外部人员（外包内容团队、代理商）看数的正确方式，通常不是给账号席位，而是只读分享链接。
顺带一提：如果你还在纠结自己写脚本还是买工具，那道题的答案会直接改掉这张表里第 3、4 行的工作量——见自己写脚本监测 AI 提及，还是买工具。
常见问题（FAQ）
AI 可见度该挂在市场部、SEO 还是公关头上？ 都不完整。它是四类活：定义与测量、内容与信源生产、站点与实体地基、异常处置。设一个唯一的 A（通常是市场/品牌负责人），四类活各派 R，用 RACI 表把边界写死。塞进一个「GEO 专员」，最后只会剩下发稿。
为什么测量的人不该背「提及率提升」？ 因为分母在他手里。提高品牌词比例、换掉难题、调小采样次数，三步都合规、都能解释，但读数会系统性变好而生意没变。测量侧该背的是「口径不变」：变更留痕、分母定义成文、采样规则跨周期一致、原始记录可导出复核。
RACI 表里为什么强调「每行只有一个 A」？ 一行两个 A 等于没有 A——出事时两边都能指向对方且都成立。最典型的双 A 事故是「官网结构化事实」：市场觉得归运维、运维觉得归内容，于是产品参数在官网、天猫店、公众号上是三个版本。
10 个人的公司也要搞这套吗？ 要，但表不变、人可以重，12 行可能只落在 3 个人头上。唯一不能重的是：定义与测量的 A，不能和内容生产的 A 是同一个人。实在只有一个人，就把口径文档外置、保留原始记录可导出，让老板或第三方能随时抽查。
「站点与实体地基」为什么老没人认领？ 因为它横跨内容与技术之间的空隙，而工商、百科、地图 POI 这类实体信息常年挂在行政或法务名下不动。建议明确挂在 SEO / 官网负责人头上，法务列为 C。
运维把 AI 爬虫 ban 了算谁的责任？ 算 A 的，不算运维的。运维按旧规则拦陌生高频 UA 是正确的运维行为，缺口在于没人把「AI 爬虫放行清单」写进他的变更检查项。所以那一行 R 在运维、A 在市场负责人、C 在 SEO。
这张表和代运营那套是什么关系？ 互为镜像：本文是甲方内部分工，那篇是机构对外交付。外包之后这张表不作废，而是塌缩成两行——外包方拿走内容生产的 R，你必须留住定义与测量的 A。
结语：先有归属，才有数字
这件事的顺序常常被搞反。多数公司是先买工具、先看数字，然后才发现没人对这些数字负责——于是第三个月，看板还在，但没人打开。
没人负责的事，不会有人去测它，更不会有人在预算会上替它辩护。 所以这篇没有讲任何优化技巧，只讲了三件事：把一个岗位拆成四类活、给每行点一个唯一的 A、以及别让定义分母的人被分母考核。
这三件事不需要预算，一个下午能做完。做完之后再去看数字，数字才开始有意义。
闻响 GeoEcho 做的是这张表里第 1–4 行的工具：国内（豆包 / DeepSeek / Kimi / 元宝 / 通义 / 百度 AI）与海外（ChatGPT / Perplexity / Gemini）在同一套提问集与采样规则下呈现，按引擎、按取数面分开标清口径，提及率、推荐率与被引来源 URL 逐条可查、可导出——也就是让「口径不变」这件事有据可查。输入域名可以先跑一份免费快照，不用约销售，把结果直接拿去当你那张表的第一份基线。想先补概念，见GEO 完全指南与GEO 术语表；想先手动摸一遍再定分工，见怎么免费自查品牌在 AI 里有没有被提到。
本文给出的分工表与 KPI 是我们的建议默认值，不是行业标准，请按你公司的实际部门设置调整。文中引用的招聘 JD 与检索结论核对日期为 2026-09-09，仅用于说明中文侧内容现状，不代表我们认同其职责定义；本文不讨论薪资、编制或招聘数量。企查查相关信息引自公开报道与其官方页面，请以其官网当日页面为准。
信息来源：知乎《2026 年，你要招的第一个岗位：GEO 优化专员（附详细岗位 JD）》、知乎《GEO 优化专员（AI 大模型搜索结果方向）岗位 JD》、艾奇在线转载版、CSDN《生成式引擎优化（GEO）岗位技能需求分析》、阿里云开发者社区《GEO 岗位数据分析：20 份 JD 拆解》、电鸭社区 GEO 运营专员招聘帖、HubSpot《Generative engine optimization KPIs that actually matter for marketing teams》、Similarweb《GEO KPIs: How To Measure The Right GEO Metrics》、新华网江苏频道《企查查发布商查大模型「知彼阿尔法」》、新浪科技《企查查全球首发商查大模型「知彼阿尔法」》、企查查智能体数据平台。
常见问题
AI 可见度这件事，到底该挂在市场部、SEO 还是公关头上？
都不完整，因为它不是一个岗位、是四类活：① 定义与测量（提问集、分母、基线、采样规则）；② 内容与信源生产；③ 站点与实体地基（官网结构化事实、工商/百科/地图等实体信息、爬虫可访问性）；④ 异常处置（错误信息、负面、品牌词被竞品劫持）。这四类天然分属不同团队，硬塞进一个「GEO 专员」，最后只会剩下第 ② 类里最容易执行的那一半——发稿。正确做法是给整件事设一个唯一的 A（最终担责人，通常是市场/品牌负责人），四类活各自派 R（执行人），用一张 RACI 表把边界写死。
为什么测量的人不该背「提及率提升」这个指标？
因为分母在他手里。提及率 =被提及的采样次数 ÷（提问条数 × 采样次数），定义提问集和分母的人如果同时被这个数考核，最省力的提升路径不是做优化，是把品牌词的比例调高、把难题换掉、把采样次数改小——每一步都合规、都能解释，但读数会系统性变好而生意没变。测量侧该背的是「口径不变」：提问集变更留痕、分母定义写在文档里、采样规则跨周期一致、原始记录可导出复核。把裁判和运动员分开，是这张表里最不能省的一条。
RACI 表里为什么强调「每行只能有一个 A」？
A 是最终担责人（Accountable），R 是执行人（Responsible），C 是必须被咨询的人（Consulted），I 是只需被知会的人（Informed）。一行出现两个 A，等于没有 A——出事时两边都能指向对方，且都成立。AI 可见度里最典型的双 A 事故是「官网结构化事实」：市场觉得官网归运维、运维觉得内容归市场，于是产品参数在官网、天猫店、公众号上是三个版本，AI 抓到哪一版全看运气。这一格必须硬点一个名字。
10 个人的公司也要搞 RACI 吗？
要，但表不变、人可以重。小公司的正确做法不是砍掉行，是让一个人同时占多行的 R——12 行活可能只落在 3 个人头上。唯一不能重的是一处：**定义与测量的 A，不能和内容生产的 A 是同一个人**，否则就是自己给自己出考卷、自己判卷。如果实在只有一个人，就把「口径」这一件事外置——把提问集、分母、采样规则写进一份任何人都能复核的文档，并保留原始记录导出，让老板或第三方能随时抽查。
「站点与实体地基」为什么老是没人认领？
因为它横跨两个部门的空隙：内容侧觉得那是技术活（结构化数据、robots、日志），技术侧觉得那是内容活（产品参数、资质、简介文案），而工商信息、百科、地图 POI 这类实体信息在很多公司干脆挂在行政或法务名下、几年不动。结果是 AI 拿到的公司主体名、成立年份、业务范围、产品参数互相打架，引擎要么选一个说、要么整个跳过你。这一格建议明确挂在 SEO / 官网负责人头上，实体信息部分把法务列为 C（工商与资质表述必须由他们确认）。
运维把 AI 爬虫 ban 了算谁的责任？
算 A 的责任，不算运维的。运维按旧规则处理陌生高频 UA 是完全正确的运维行为——问题出在没人告诉他哪些 UA 现在与品牌可见度直接相关。所以 RACI 表里「爬虫可访问性」这一行的 R 是运维、A 是市场/品牌负责人、C 是 SEO：由 A 保证这条规则被写进运维的变更清单，而不是指望运维自己知道。这也是为什么这张表值得写下来——它真正防的是「每个人都按自己的岗位做对了事，合起来结果是错的」。
这张表和代运营公司交月报那套是什么关系？
互为镜像。本文是甲方内部怎么分工，[代运营公司怎么交 GEO 月报](/zh/blog/geo-reporting-for-agencies-white-label/) 是机构对外怎么交付。如果你把 GEO 外包了，这张表并不作废，而是塌缩成两行：外包方拿走「内容与信源生产」的 R，你必须自己留住「定义与测量」的 A——提问集、分母、基线、原始记录留在你手里。施工方不出验收报告，这是采购常识，不是不信任。