项目交付后又改了配置，官网案例还能只写初版方案吗

一个项目已经写成官网案例，几个月后客户又调整了工况，设备随之更换部件并修改参数。运营人员如果直接把案例里的初版方案改成最终配置，读者会误以为这些条件从交付当天就存在；若完全不更新，销售又可能拿旧方案回答新客户。案例需要保留项目过程，而不是只展示某个时点的漂亮结果。

初次交付与后续变更要分开记录

整理案例时先确定基准版本。初次报价单、确认图纸、产品ID、正式型号、交付清单与验收记录共同说明项目最初采用了什么方案。页面可以写当时的业务条件、选型理由和验收边界，但不能把后来新增的功能提前放进去。若客户名称、产线信息或图纸细节不适合公开，脱敏后仍要保留行业、工况范围和版本关系。

后续配置变化应作为更新记录追加，至少写清变更日期、触发原因、涉及部件、图纸版本和复验范围。例如环境温度改变后更换密封材料，页面只能说明材料调整与适用条件，不能扩写成原方案存在缺陷。销售聊天记录可以帮助定位客户问题，最终事实仍要由变更单、售后工单或检测记录确认。

页面上要让读者区分“初版交付状态”和“当前运行状态”。可以在正文中设置明确的更新时间点，并保留原发布日期；正文不必公开客户内部编号，却应说明哪些参数已经失效、哪些结论仍适用。已有案例证据怎样组织，可参考客户案例的过程与验收依据。更新不是把旧段落覆盖掉，而是让读者看懂方案为什么变化。

公开内容要与销售正在使用的资料一致

案例更新后，应同步检查关联产品页、下载手册和FAQ。若新配置只适用于特定批次，产品页不能把它写成所有型号的标准能力；若变更已经成为正式选配项，则要由产品资料负责人建立新的字段或附件版本。案例链接应指向当前有效的产品记录，同时保留旧型号与新部件之间的真实关系，不能为了方便统一跳到产品栏目首页。

销售使用案例时，也要知道他转发的是哪个版本。案例后台可保存更新摘要、审核人和引用资料，公开页只展示对采购有用的变化。报价时若引用案例中的配置，应把客户工况、数量、交付批次和对应图纸重新确认，不能把其他项目的最终方案直接复制。产品变更的生效批次如何说明，可对照产品变更通知与生效批次。

后台还应给每条更新设置明确状态。售后正在观察的调整只能标为“验证中”，技术审核通过并进入正式选配资料后，才可以写入当前方案。被撤回的改动不应从记录中消失，要注明撤回日期和原因，防止旧截图、旧报价或销售收藏链接继续传播。多语言案例也要共用同一变更编号，翻译可以晚些发布，事实状态不能各写一套。

复验结果不能只写“运行正常”。应说明检查对象和边界，例如更换部件后复核了哪些尺寸、负载或连接条件，哪些长期表现仍需继续观察。现场照片要对应变更后的真实位置，图片命名可包含项目内部ID、拍摄阶段和版本，但公开文件名应移除客户敏感信息。检测报告若只覆盖单台设备，也不能被写成整个系列的普遍结论。

上线前，运营、技术和销售应各自完成一次核对。运营检查标题、时间线、内链和图片；技术核对型号、图纸与检测条件；销售确认案例没有把可选配置写成标准承诺。公开后从搜索结果进入页面，再沿相关产品和询盘入口走一遍，确认客户看到的当前状态与销售收到的来源记录一致。这样的案例既保留初次交付事实，也能反映项目后续发生的真实变化。