Entity Optimizer

核心用法

Entity Optimizer 是一套面向搜索引擎与AI系统的实体身份审计与构建协议，专注于解决「AI认不认识你」这一GEO（生成引擎优化）核心命题。实体——人、组织、产品、概念——是Google知识图谱与LLM回答生成的决策基础。

三步工作流：
1. 实体发现：审计品牌在Google知识面板、Wikidata、Wikipedia、Schema.org的结构化存在状态
2. 信号审计：评估6大类47项信号（结构化数据、知识库、NAP+E一致性、内容信号、第三方提及、AI特定信号），每项标注Pass/Fail/Partial
3. 报告与行动计划：生成优化报告，包含关键问题诊断、TOP5优先级动作、及CORE-EEAT/CITE交叉引用

独特能力：

• 内置零依赖工具 kg.py，无需API密钥即可查询Wikidata QID与sameAs关系
• 提供「AI实体解析测试」框架——通过向ChatGPT/Claude/Perplexity/Google AI Overview提问，验证AI系统能否准确识别并引用实体
• 自动生成符合下游技能（geo-content-optimizer、serp-markup-builder）消费标准的canonical实体档案

显著优点

• 协议级严谨性：Apache-2.0开源，定义清晰的Skill Contract与Handoff格式，确保跨会话、跨技能协作可追溯
• GDPR合规内建：针对欧盟/EEA/UK个人实体，强制要求确认法律依据（同意、合法利益、合同等）后才写入档案
• 信号体系完整：47项可审计信号覆盖从Schema.org到新闻提及的全链路，而非仅关注单一平台
• 零工具降级运行：无API访问时自动切换为用户输入模式，标记待手动验证项，流程不中断

潜在局限

• 非实时搜索依赖：Claude本身无法直接查询Google知识图谱或执行实时网络搜索，「AI实体解析测试」需用户手动执行或提供观察结果
• 个人数据敏感：人物实体优化涉及GDPR/CCPA/PIPEDA/LGPD等多法域合规，虽内置提示但非法律建议，复杂场景需人工法务审核
• 效果验证周期长：知识面板创建/更新、Wikidata收录通常需数周至数月，无法提供即时反馈循环
• 工具链依赖：完整功能需 kg.py、pageviews.py、gdelt.py 等本地脚本支持，纯Markdown环境功能受限

适合人群

• 品牌SEO/GEO负责人：需建立品牌实体权威性以获得AI引用
• 创始人/公众人物：希望被AI系统识别为领域专家，解决「AI不认识我」问题
• 内容 strategist：负责About页面、创始人传记、产品Schema策略
• 多品牌集团：需规范化实体档案管理，避免子公司/产品实体混淆

常规风险

• 知识图谱错误固化风险：Wikidata/Wikipedia信息错误可能被AI系统放大，需持续监控sameAs指向
• 实体消歧失败：与同名实体（如同名人物、通用词品牌）竞争时，可能需长期SEO投入才能建立canonical身份
• 过度依赖单一知识源：若Wikidata/Wikipedia收录标准不符（如企业知名度不足），替代路径（CrunchBase、行业目录）权威性较弱
• AI系统黑箱性：即使实体信号完备，LLM是否引用仍取决于训练数据与检索机制，无法保证

核心用法

Entity Optimizer 是一套完整的实体身份审计与优化协议，专为搜索引擎与AI系统的双重认知设计。该技能通过六大信号类别（47项具体信号）对实体进行全方位诊断，包括结构化数据信号、知识库信号、NAP+E一致性信号、内容型实体信号、第三方实体信号以及AI专用信号。

使用流程分为三步：首先进行实体发现，通过Knowledge Graph API、Wikidata查询和AI分辨率测试建立当前状态基线；其次执行信号审计，对6大类别逐条评分（Pass/Fail/Partial）并生成差距分析；最后输出优化报告，包含优先级行动路线图与持续监控建议。特别值得一提的是其零依赖本地辅助脚本kg.py，可在无需API密钥的情况下解析Wikidata实体关联与sameAs链接。

显著优点

双引擎协同优化：突破传统SEO局限，同步优化Google知识图谱与AI系统（ChatGPT、Claude、Perplexity等）的实体识别能力，实现"被搜索到"与"被AI引用"的双重目标。

标准化输出体系：严格遵循memory/entities/存储规范与Entity-GEO Handoff Schema标准，确保下游技能（如geo-content-optimizer、serp-markup-builder）能无缝衔接，避免数据孤岛。

隐私合规前置：在处理个人实体时强制触发GDPR Art 6合规检查，要求用户确认法律基础后再写入档案，并内置gdpr-purges.md查重机制防止违规重建。

无工具依赖弹性：提供完整的"有工具/无工具"双路径方案，即使缺少专业SEO工具或AI监控接口，仍可通过用户访谈与公开数据源完成核心审计。

潜在局限

个人开发者维护：来源可信度为T3级别（个人GitHub账号），虽Apache-2.0开源且版本规范，但非企业/基金会背书，长期维护稳定性需关注。

实时性依赖外部数据：AI分辨率测试、Knowledge Graph状态等关键诊断项依赖外部平台状态，Claude本身无法直接查询，需用户配合提供或标记为"用户自运行"。

垂直行业深度有限：作为通用型协议，对医疗、金融等强监管行业的实体认证特殊要求（如医师执照、金融牌照）未做专门适配。

GDELT调用频率限制：全球新闻提及监控功能要求调用间隔≥5秒，大规模批量审计时效率受限。

适合目标群体

• 数字营销团队：负责品牌知识面板建设、AI Overview引用优化的SEO/GEO专业人员
• 创始人IP打造：科技创业者、行业专家需要建立可验证的数字身份与权威背书
• B2B SaaS企业：产品实体与品牌实体需要区分管理、避免AI混淆的科技公司
• 内容策略顾问：为客户制定"可被AI引用"的内容基础设施规划

常规使用风险

性能风险：大规模实体审计时，若启用GDELT新闻监控与Wikipedia页面浏览量追踪，可能因外部API响应延迟导致整体流程变慢。

数据新鲜度风险：Wikidata与Knowledge Graph的更新存在滞后，技能输出的"当前状态"可能已非实时，建议标注数据时间戳并定期复测。

合规误用风险：虽内置GDPR提示，但最终法律判断依赖用户自行确认，若用户误判个人实体 residency 状态或法律基础，可能导致合规违规。

下游依赖风险：Entity-GEO Handoff Schema字段缺失会导致消费者技能降级至DONE_WITH_CONCERNS状态，需严格遵循Profile schema要求。

知识图谱门槛风险：Wikidata条目创建需满足知名度准则（notability），新创品牌可能因不符合收录标准而无法建立知识图谱入口。