真实客户案例如何展示项目范围而不泄露客户信息？关键不是把客户名删掉，而是先确认哪些事实获准公开，再用经过核准的交付范围和可见证据说明团队做了什么。案例的可信度来自边界清楚、证据可核对，而不是堆砌未经许可的截图或漂亮数字。本文给已有真实项目、准备写案例的团队一套编辑流程；表格为虚构示范，不代表 AIRSANG 的客户项目。
先列清单：什么能实名、什么要匿名、什么不能公开
写作前让项目负责人拿出合同约定、沟通记录和客户已批准的展示范围，建立逐项公开清单。把“客户名称可以写”与“所有后台截图都可以放”分开判断：同意展示 Logo，不等于同意公开报价、订单或转化数据；同意引用一句评价，也不等于同意在网站上放客户联系人姓名。没有明确批准的项目细节先归入待确认，不能凭口头印象推定授权。
把素材分成三个层级
可实名展示：客户明确批准的名称、网站 URL、项目类别、页面截图与文字描述，且批准记录能对应到当前版本。可匿名展示：客户允许概括的行业、业务目标、页面类型与实施步骤，但不出现可反查身份的细节。不可公开：未经批准的合同金额、后台账号、订单与访客信息、未发布产品、实际交易额或策略文件。即使一项信息本身看似普通，也要检查它与其他线索叠加后是否能识别客户。
运营团队可以在清单中为每项素材记录“原始文件、拟公开版本、批准人、批准日期、适用渠道和撤回方式”。这样，写作者知道哪些材料可以进入网页，设计师知道哪张图必须重做，发布人员也能在上线前核对最终 URL。Content Marketing Institute 关于邀请客户参与案例的建议也强调先建立正式的客户参与和许可流程；这属于编辑实践建议，不能替代双方合同的具体约定。
用交付范围矩阵证明工作，而不是暗示业绩
潜在客户读案例，首先想知道服务方究竟负责了哪些页面、内容或功能。范围说明应从需求出发，接到交付模块，再接到获准展示的证据。例如“重做首页”过于笼统；“梳理首页信息结构、制作首屏与行业应用模块、完成移动端适配”更能说明投入和边界。但这些动词必须和真实项目记录一致，不能把合作方做的开发工作算到自己名下。
以下是虚构的教学示范表，只解释写法，不对应任何 AIRSANG 客户、订单或实际业绩。真正发布客户案例时，应逐格替换为已核实且获准公开的项目事实。
| 客户需求（虚构） | 项目范围与交付（虚构） | 可以核对的证据形式 | 公开前确认 |
|---|---|---|---|
| 访客看不清主营业务 | 梳理首页层级、制作业务入口与行动按钮 | 经批准的首页模块图或公开页面 | 页面版本及图片范围获准 |
| 产品分类难以浏览 | 规划目录层级和产品页信息字段 | 去敏的页面结构图或公开产品页 | 不含未上市产品及内部 SKU |
| 手机浏览需要改善 | 调整导航、模块间距与表单布局 | 经批准的桌面及手机页面对照 | 截屏无个人信息或后台路径 |
矩阵右侧的许可栏不能省略：能拿出工作文件，不代表有权把文件公开。若结果指标涉及询盘、订单、收入或转化率，另建“数据来源—统计区间—归因限制—客户批准”记录。没有可靠测量或批准，就只描述交付，不把“可能改善体验”写成“带来增长”。公开页面展示的也只是可见结果，并不能单独证明后台数据或合同范围。你可以查看已公开的 Phonix Audio 网站设计案例，观察页面如何呈现项目；本文不据此推断其未公开的合同、指标或许可。
截图、文件和链接：删除名字之后还要检查什么
案例图片最容易漏出信息。展示网站设计过程时，画面边缘可能带着编辑器账号、浏览器书签、后台路径、邮件通知、客户地址、订单编号和追踪参数。发布前从原始项目资产导出一个专门用于宣传的版本，不要直接把内部会议截图或后台录屏拖进媒体库。负责人员逐张检查桌面尺寸、手机裁切尺寸、缩略图和可点击大图，确认遮盖区域在任何呈现方式下都不会重新露出。
检查不只在可见画面。图片与文档可能带有元数据、文件名、隐藏图层或备注；链接可能带有查询参数和可访问的旧版本。即使把姓名换成“某客户”，小众产品、精确地区和上线日期组合起来也可能让身份被反推出。英国 ICO 的匿名化说明强调能否识别个人取决于信息与可用线索的关系。这里引用的是通用风险判断思路，并非对中国法规或某一合同的法律结论。
风险高的画面改成明确标注的示意图
如果界面包含大量真实订单、客户名单或账户信息，逐格打码既费力也容易遗漏。更稳妥的编辑选择是重绘一个“教学示意，非真实客户后台”的流程图，解释你做的导航结构、表单路径或页面组件。示意图不能照着客户真实后台重现敏感布局，也不能塞入虚构的询盘数当成果。正文文字必须明说它只是方法演示；读者需要看到真实项目证据时，优先提供已经获准公开的网站页面或客户确认过的视觉稿。
没有实名许可时，案例还能怎么写
没有实名授权，不等于必须把项目写得空泛。若客户允许匿名叙述，可以用“某 B2B 工业设备品牌”这样的概括称呼，写清业务情境、已核实的页面范围、交付动作和项目边界。避免再叠加罕见产品型号、城市、精确日期、独特企业规模等线索。标题也不要写成容易被搜索反查的组合。写完让没参与项目的人读一遍，看看能否凭这些线索猜出客户；若能，就继续泛化或删去细节。
匿名案例仍需要真实基础：项目确实发生，工作范围有内部记录，公开措辞获得相应批准。不要把两个客户项目拼成一个“真实案例”，也不要用示意图冒充实际交付。如果客户只批准展示某个通用方法、没有批准任何可核对的项目事实，适合把文章定位为工作方法或教程，而不是标作真实客户案例。若团队还在决定案例与教程的内容节奏，可参考平台教程和客户案例的写作顺序；那篇讨论的是排期，本文只讨论已有项目的公开边界。
审批不是一句“可以发”：让文字、图片和 URL 对上版本
准备发布时，写作者、项目负责人和客户指定联系人应按同一份预览稿核对：客户名称是否出现、页面清单是否准确、图片是哪一版、数据是否有来源、外链会跳到哪里。最好把批准记录关联到文章版本和具体图片文件，而不是只保留一句脱离上下文的“同意发布”。如果后来换了截图或新增指标，应重新确认变化部分。内部还需指定一个联系人接收更正或撤回请求，并记录修改时间和页面地址。
上线后由未参与编辑的人用未登录浏览器打开公开 URL，检查页面、图片原文件、社交分享预览、搜索摘要与手机布局。若发现敏感资料，应优先删除公开内容或做访问控制，再考虑搜索结果处理。Google Search Central 关于控制共享内容的说明指出，noindex 只是影响搜索收录，知道链接的人仍可能访问页面；它不能替代保密措施。对已经外泄的内容，还要检查缓存、附件及第三方复制，但不能承诺一定能全部撤回。
给案例写作者的发布前六问
- 项目名称、范围、交付日期与实际记录一致吗？
- 每个客户名称、Logo、页面和指标都有对应的公开批准吗？
- 匿名线索组合起来会不会重新指向客户或个人？
- 图片原文件、附件、参数和移动端裁切都查过了吗？
- 示意图和虚构表格是否清楚标注，且没有冒充真实成果？
- 发布后谁负责复查、改正和处理撤回？
结论：可信的项目范围，来自可确认的公开边界
真实客户案例要同时回答两件事：团队到底做了什么，以及这些信息为什么可以公开。先建立三层公开清单，再用需求、交付和证据矩阵写出项目范围；对截图、文件与链接做逐项复查，最后让客户对文字和图片的具体版本确认。没有许可的数据宁可不写，没有来源的业绩不要补写。这样写出的案例可能少一些刺激性数字，却更容易让潜在客户理解服务范围，也给客户保留应有的控制权。
如果你今天就要开始，可先用上面的虚构矩阵改成一页内部工作表，填入自己已有项目的真实记录，然后交由项目负责人和客户指定联系人决定哪些内容能进入公开网页。审批之前，它仍是一份内部稿，而不是可发布的客户案例。
