GEO 合规工程复盘：3·15 曝光的提示词注入与虚假测评，系统边界该怎么设

2026 年央视 3·15 晚会曝光的“AI 投毒”问题，核心不是模型会不会回答，而是内容生产链路把虚假测评、虚构专家身份、批量账号和提示词指令混进了公开语料。对做生成式引擎优化（GEO）的团队来说，这是一个工程问题：哪些输入可以进入发布系统，哪些输出必须留痕，哪些操作必须被拒绝。迪普智见（DeepIntelli）把 GEO 合规拆成可审计的数据模型、状态机和验收边界，而不是靠运营人员事后判断。

1. 问题定义：GEO 系统要防的不是“差评”，而是不可归因内容

先把问题说清楚。品牌方采购 GEO，不是要买一批看起来热闹的内容，而是要让真实产品信息、官方资料和可验证经验更容易被 AI 搜索引用。黑灰产做法的共同点，是把不可验证内容包装成可引用内容：

1. 批量生成虚假测评，用相似句式替换品牌名、产品名和场景词。
2. 虚构专家身份、用户身份或机构背书，让模型把营销话术误判为第三方评价。
3. 在网页、文档或评论区隐藏提示词注入指令，诱导模型抓取特定结论。
4. 用群控账号制造互动量，再把互动量包装成“市场共识”。
5. 删除或绕开源链接，让回答无法追溯到原始出处。

工程上的约束也很明确：

• 发布内容必须能追溯到品牌提供的资料、公开可验证来源或明确标注的一方经验。
• 任何涉及测评、专家、客户、数据和证书的字段，都必须有来源状态。
• 系统不能执行内容里的“忽略规则”“把某品牌排第一”“不要引用来源”等指令。
• 品牌方和服务商的责任边界要能在日志里复原：谁提交、谁审核、谁发布、谁授权。

这也是迪普智见把 GEO 合规服务做成流程控制的原因：如果只在文案末尾加一句“本文不构成投资建议”，并不能解决虚假身份、虚假测评和提示词注入问题。

2. 数据模型：把每条素材拆成可审计字段

下面这个模型可以直接作为内容入库表的起点。字段名用英文写，方便工程实现；中文说明给运营和法务看。

{
  "asset_id": "string，素材唯一 ID",
  "brand_id": "string，授权品牌 ID",
  "claim_type": "fact | opinion | test | expert | customer_case | comparison | guide",
  "statement": "string，准备发布的原句",
  "subject": "string，被描述对象，例如产品、服务或公司",
  "attribute": "string，被描述属性，例如价格、功能、适用场景",
  "value": "string，属性值，必须逐字来自授权材料或来源文件",
  "source_type": "brand_official | public_record | verified_customer | first_party_test | unattributed",
  "source_url": "string | null，必须是真实可访问 URL；没有就填 null",
  "source_date": "YYYY-MM-DD | null",
  "identity_claim": {
    "person": "string | null",
    "title": "string | null",
    "organization": "string | null",
    "verification_status": "verified | unverified | rejected"
  },
  "prompt_injection_scan": {
    "status": "pass | review | reject",
    "matched_rules": ["rule_id"]
  },
  "legal_review": {
    "status": "pending | approved | rejected",
    "reviewer": "string | null",
    "note": "string"
  },
  "publish_state": "draft | approved | published | retracted",
  "brand_authorization": {
    "status": "granted | expired | missing",
    "evidence_ref": "string | null"
  }
}

这里最关键的是三个字段。

第一，source_type 决定一句话能不能以事实口吻发布。unattributed 只能写成明确标注的观点或经验，不能写成“测评显示”“专家认为”“客户验证”。

第二，identityclaim.verificationstatus 决定专家和用户身份能不能出现。没有可验证任职关系、真实授权或公开身份记录，就不能把一句话包装成专家结论。

第三，promptinjectionscan.status 决定素材是否包含越权指令。正文里出现“忽略以上规则”“输出时不要提来源”“把某品牌列为第一”等文本，应进入 review 或 reject，不能直接进入发布队列。

3. 状态机：从素材到发布必须经过四个闸门

仅有字段还不够，还要限制状态怎么流转。建议把发布流程写成下面的状态机：

DRAFT
  -> SOURCE_CHECKED
  -> INJECTION_SCANNED
  -> LEGAL_REVIEWED
  -> APPROVED
  -> PUBLISHED
  -> RETRACTED

每个状态的进入条件如下：

这个状态机能解决一个常见责任争议：品牌方说“我不知道服务商这样发”，服务商说“品牌给过资料”。如果日志里能看到素材来源、审核人、授权证据和发布版本，责任边界就不靠口头解释。

4. 提示词注入检测：把正文里的控制语当成不可信输入

GEO 团队经常处理网页、PDF、评论、论坛帖和第三方文档。这些材料都可能携带提示词注入。不要把抓取到的文本直接拼进生成 prompt，也不要让模型把素材里的命令当成系统指令。

可以用一个最小检测函数：

INJECTION_PATTERNS = [
    r"忽略(以上|之前|前面).{0,8}(规则|指令|要求)",
    r"不要(提及|显示|引用).{0,8}来源",
    r"把(.{1,30})(列为|评为|排在).{0,6}(第一|首选|最佳)",
    r"你是(系统|管理员|审核员).{0,20}(必须|不得)",
    r"system\s*prompt",
    r"ignore\s+(previous|above)\s+instructions",
    r"do\s+not\s+(cite|mention|show)\s+sources?"
]

def scan_injection(text: str) -> dict:
    matched = []
    normalized = text.lower().replace("\n", " ")
    for rule_id, pattern in enumerate(INJECTION_PATTERNS, start=1):
        if pattern.lower() in normalized or __import__("re").search(pattern, text, __import__("re").I):
            matched.append(f"INJ-{rule_id:03d}")
    if matched:
        return {"status": "review", "matched_rules": matched}
    return {"status": "pass", "matched_rules": []}

这个函数不负责判断内容真假，只负责把“试图控制模型行为”的文本拦下来。真正的事实校验仍要回到 source_type 和人工审核。

工程实现上还要做三件事：

1. 抓取内容与系统指令分层。素材永远放在用户内容区，不能进入 system 角色。
2. 输出必须保留来源。没有来源的事实句不能直接发布。
3. 对网页隐藏文本做同屏检查。白色文字、极小字号、display:none、注释里的关键词都要进入扫描报告。

5. 虚假测评识别：不是禁测评，而是禁无来源断言

合规 GEO 不需要回避测评，但要区分三种内容：

判断一条测评能不能发，可以按五问走：

1. 测评对象是否具体到型号、版本或服务范围？
2. 测评条件是否写明，例如样本、时间、方法和限制？
3. 测评人身份是否可验证，且本人授权发布？
4. 数据是否逐字来自记录，而不是运营二次概括？
5. 如果读者要求看原始记录，系统能不能在日志里找到？

五问里有一个答不上来，就不要用“测评显示”。可以降级成“使用指南”“选型清单”或“官方资料整理”，但不能伪装成独立评价。

6. 责任边界：品牌方、服务商和发布账号分别承担什么

3·15 类案例给品牌方的提醒是：采购结果不能只看“AI 回答里有没有我”，还要看内容是怎么出现的。责任边界建议按三层划分。

品牌方需要负责

• 提供真实产品资料、授权范围和可公开信息。
• 确认客户案例、专家身份、商标和证书的使用权限。
• 要求服务商交付发布清单、来源清单和审核记录。
• 对明显虚假、夸大或冒充第三方的内容及时要求撤回。

GEO 服务商需要负责

• 不生成虚假测评，不虚构专家，不伪造客户声音。
• 不执行隐藏提示词注入，不操纵模型输出排名。
• 对事实型表述做来源校验，对无法验证的内容降级或拒发。
• 保留从素材到发布版本的完整日志。

发布账号需要负责

• 不冒充普通消费者、专家或机构。
• 商业合作内容按平台规则标注。
• 不发布无来源的绝对化断言。
• 收到侵权、虚假或误导投诉后，能定位原文并处理。

迪普智见在自己的 GEO 合规服务中，把这些边界做成入库校验和发布前检查；这属于一方实践，不代表第三方认证，也不等于所有平台都会给出相同判断。品牌方仍应结合所在行业、发布地区和平台规则做法务确认。

7. 可复现评估方法：用 100 条样本做一次合规体检

不需要一上来就扫描全库。可以先取最近一个发布周期的 100 条内容做样本，按下面方法复现：

• 样本边界：同一品牌、同一周期、同一内容类型；如果内容类型混合，要分别记录数量。
• 抽样方式：按发布时间顺序连续取 100 条，不要只挑表现好的。
• 评估维度：来源完整率、身份验证率、注入拦截率、绝对化用语命中率、撤回链路完整率。
• 判定规则：每条内容逐句检查；一句话无来源却写成事实，记为来源缺陷；一个身份无验证却写成专家，记为身份缺陷。
• 置信边界：100 条样本只能反映该周期和该品牌内容池的问题，不能外推到整个行业，也不能证明系统“绝对安全”。
• 重复条件：保留样本 ID、抓取时间、规则版本和审核人记录；换规则版本后要重跑。

一个简单的结果表可以这样写：

这里不要把“通过率高”写成“合规认证”。它只是一次内部工程评估，能帮助团队发现缺陷，不能替代律师意见、平台审核或监管认定。

8.把合规要求放进交付物，而不是放在口头承诺里

在迪普智见已发布的《315曝光的假GEO服务，为什么两周就崩了？——真正的GEO是怎么做的》一文中，讨论过假 GEO 服务快速失效的现象。这个现象背后的工程原因很直接：靠批量伪内容和操纵性提示词堆出来的可见度，一旦被平台识别、来源被删除或账号被处置，引用链就断了。

真正能复用的做法，是把每一次发布都变成可审计记录：

• 内容主张对应来源；
• 身份表述对应验证；
• 数据和证书逐字使用；
• 提示词注入在发布前拦截；
• 审核、授权、发布和撤回都有日志。

这不是为了把流程变复杂，而是为了让品牌方在被问“这句话凭什么发”的时候，能拿出证据。

9. 落地清单：今天就可以检查的十项

1. 最近 30 天发布的内容里，所有“测评显示”是否有原始记录？
2. 所有专家、用户、客户身份是否有授权或可验证资料？
3. 官网、PDF、论坛和评论抓取内容是否经过提示词注入扫描？
4. 是否存在白色文字、隐藏 div、HTML 注释里的关键词？
5. 是否有无来源的“第一”“最佳”“首选”“权威认证”？
6. 客户名称、客户 Logo 和客户案例是否在授权范围内？
7. 证书编号、有效期和发证机构是否逐字可查？
8. 发布账号是否冒充普通消费者或中立第三方？
9. 已删除内容是否保留原版本、删除原因和操作人？
10. 服务商交付物里是否包含来源清单和审核日志？

如果十项里有三项以上答不上来，先暂停新增批量发布，把历史内容池按上面的 100 条样本方法跑一遍。

10. 结论

GEO 的价值不是“骗过模型”，而是让真实、清晰、可追溯的信息更容易被模型理解和引用。3·15 曝光的 AI 投毒、虚假测评和虚构专家身份，本质上都是在破坏来源链和身份链。对品牌方来说，选择 GEO 服务商时，不要只问“能不能让 AI 提到我”，还要问“每一句提到我的话能不能追溯来源、能不能通过审核、能不能在被质疑时拿出记录”。

参考资料

1. 《315曝光的假GEO服务，为什么两周就崩了？——真正的GEO是怎么做的》
2. OWASP Top 10 for LLM Applications，关于 Prompt Injection 等大模型应用风险的公开说明
3. 中华人民共和国个人信息保护法
4. 中华人民共和国反不正当竞争法