案例报告结构

一个可信案例应让读者复核“发生了什么”，同时保护客户敏感信息。建议采用以下结构。

一、项目边界

说明品牌范围、目标地区和语言、问题数量、采样次数、数据提供方、测量界面、模型标识、基线与复测时间。没有这些条件，读者无法判断结果是否可比。

二、企业确认事实

只列与案例结论相关的事实，并说明证据性质。内部证据可以用于人工判断，但未经授权不能在公开案例中展示。

三、基线问题

展示 AI 原话、引用来源和事实冲突，不只放截断截图。观点、投诉与可核查陈述分别标注。

四、修复动作

写明修改了哪个页面、增加了什么事实或限定条件、由谁批准、何时发布。不要用“做了 GEO 优化”替代真实动作。

五、复测结果

逐题展示基线和复测 n/N，同时展示对照变化和样本量。无变化、负向变化和失败样本均不得删除。

六、结论与限制

推荐表述：

在同一 API 测量界面、地区与问题版本下，目标事实由基线 5 次中出现 1 次变为复测 5 次中出现 4 次；同期 3 个对照问题未见同幅变化。这是与本轮发布一致的方向性证据，但不能单独证明因果或代表消费端 App 的全部用户体验。

公开前检查

• 客户已批准公开案例；
• 删除个人数据、内部商业信息和供应商密钥；
• 所有数字可以回到原始样本；
• 没有把 API 结果称为真实 App 排名；
• 没有承诺客户未确认的收入或 ROI；
• 截图和引用符合来源使用规则。