南山企业做 GEO 的内容标准

南山企业要制定 GEO 内容标准，先要解决一个协作问题：谁来判断内容是否合格？如果只由文案岗位凭感觉决定，容易出现结构完整但信息不可用、或关键词齐全但事实不清的情况。较为稳妥的做法是把标准拆成几个角色共同检查的条目，让业务、内容、技术三方在发布前各看一遍。

业务角色先确认信息能否支撑判断

业务或产品岗位负责回答：这篇内容要解决读者的哪个具体问题？文中给出的条件、步骤、适用范围是否与实际服务能力一致？例如写“支持批量导入”，要核对当前版本是否确实支持，而不是把计划中的功能写成现有能力。业务角色不需要润色文字，但要标出模糊表述和未经确认的承诺。

内容角色检查结构与可读性

内容岗位关注段落是否按问题展开，小标题是否指向具体动作，例子是否与主题相关。一个可操作的检查方法是：把每段首句抽出来连读，看能否还原文章的主要脉络；如果首句都是“随着……”“众所周知……”，说明信息密度不足。内容角色还要确认文中没有重复同一结论，避免用不同措辞反复说同一件事。

技术角色核对边界与风险表述

涉及系统配置、权限、数据迁移的内容，技术角色要检查是否写清了前提条件和失败后的排查方向。比如提到“开启某功能”，应说明在哪个管理界面、需要什么权限、改动后如何验证。对于不确定的产品能力，统一写成“核对是否支持”，而不是直接断言。技术角色不负责改写全文，只标注需要修正的句子。

三方共用一份发布前检查表

检查表可以按文章类型设置不同条目。方法类文章重点看步骤是否可执行、条件是否写明；对比类文章重点看比较维度是否一致、数据来源是否交代；问题排查类文章重点看现象、原因、验证动作是否对应。每个条目只记录“通过、需修改、不适用”三种状态，并写明修改责任人。这样标准不是挂在墙上的原则，而是每次发布前实际走一遍的流程。

积累素材时按角色分工记录

日常积累可以由不同角色分别贡献：业务侧记录读者常问的问题和实际处理条件，内容侧整理已发布文章中反复出现的模糊表述，技术侧汇总需要核查的产品能力清单。这些记录按主题归档，写新内容时先查已有记录，避免每次从零开始，也减少同一问题在不同文章里给出不一致答案的情况。

旧内容维护要明确触发条件

旧内容不是定期全部重写，而是设定触发复查的条件：产品功能有变更、读者反馈某段看不懂、文中引用的条件已不适用、同一主题出现了新的常见问题。触发后由原负责角色确认修改范围，涉及技术表述的交给技术角色复核，改完在文末记录更新日期和修改要点。没有触发条件的文章可以暂时不动，避免为了更新而更新，反而引入新的不准确表述。