产品线更名后，官网1450篇文章还写着旧产品名？WebFuture批量替换，9个工作日缩到30分钟

新产品发布会开完第二天，市场部打开自家官网，发现满屏还是那个刚刚作废的名字。

本文记录的是一则「批量替换」功能的实际应用场景：某软件企业完成产品线重构，原"启元云平台"更名为"启元数智平台"，官网与技术文档共 3200 篇，其中 1450 篇仍写着旧产品名，且旧名存在标准旧名、带版本号变体、英文缩写混写三种形态，合计 2040 处。人工逐篇修改预计需要 72.5 小时、约 9 个工作日；使用动易 WebFuture 内容管理系统的批量替换功能，可按站点、节点、内容模型与字段限定范围，用正则表达式把三种写法分别圈出、逐类预览匹配示例后分批替换，替换后自动清理缓存并输出完整日志，30 分钟完成全站统一。

产品线重构后的内部宣讲会，新产品名与品牌规范投在大屏上，与会人员逐条对照

产品线重构的收尾会议开在上周五。会上宣布，"启元云平台"正式更名为"启元数智平台"，从下一个版本开始，所有对外材料——宣传册、报价单、官网、技术文档——统一使用新名字。

会开得很顺利。新名字念起来更顺，也更贴合这次转型的方向。散会时大家还开玩笑说，这下总算不用再解释"云平台到底是不是做云的"了。

第二天上午，品牌专员林静收到销售转来的一条客户消息："你们官网写的是启元云平台，销售给我发的方案里叫启元数智平台——是两家公司吗？"

她愣了一下，点开官网首页。栏目名改了，导航改了，Banner 改了。再往下一篇文章点进去，正文第三段写着："启元云平台自 2019 年上线以来……"

一、改了门面，里面的房间还挂着旧门牌

这次更名，宣传口的人是做足了功课的：首页文案重写、产品页重做、公众号发了换名公告、销售物料当天全部下发新版。

但官网是一个装了十几年东西的柜子。首页是柜门，每天有人擦；柜子里却有几千篇历史文章——产品发布、技术博客、客户案例、行业观察，跨度从 2019 年一直到上个月。这些文章当年发布时，用的都是"启元云平台"。

林静在后台做了全文检索，结果比预想的严重：全站 3200 篇文章，1450 篇正文里出现过旧产品名。接近一半。

更麻烦的是，这些文章里的旧名字不都是作家档案。有几篇技术白皮书是客户会下载的，有几篇是问得最多的售前答疑——恰恰是这些最常被翻出来的文章，写着已经被作废的名字。

林静算了一下工作量：一篇一篇打开、找到旧名字、改掉、点保存。熟练的话一篇 3 分钟，1450 篇就是 72.5 小时，按一天八小时算，是 9 个工作日。市场部一共三个人，手上还压着新版本发布的内容。9 个工作日，没人拿得出来。

二、1450篇文章，2040处旧名称

这件事的全部数字

林静让技术同事帮忙，把所有命中旧名的位置导出来看了一遍，发现旧名字在系统里其实有三种不同的面孔：

第一种，标准旧名"启元云平台"，1450 处。最规矩的写法，也最容易认。

第二种，带版本号或旧品牌前缀的变体，380 处。比如"启元云平台V3.0""启元科技云平台""启元云平台 5.1 版"。这些是产品发布类文章留下的——当年发一版写一篇，版本号和品牌前缀跟着正文一起写进去了。

第三种，英文缩写混写，210 处。技术文档里最常见。有的写成 "QY Cloud"，有的连写 "QYCloud"，还有的带版本号 "QY Cloud 3.0"。

三类加起来，2040 处。

品牌规范下发第二天，品牌专员拿着手册逐条比对手上的文章——旧名字的写法比想象中多

三、三种写法，说明"查找替换"不够用

有人提议：不就是改个词吗，把"启元云平台"粘到后台的替换框里，一键换掉。

林静试了一篇，就发现问题了。

如果只替换"启元云平台"这五个字，带版本号的那 380 处会被整个跳过——因为"启元云平台V3.0"里，"启元云平台"后面紧跟着版本号，虽然能被命中，但替换后版本号会被挤压成"启元数智平台V3.0"，写法要不要保留版本号，得按规范来定。英文缩写那 210 处更是一处都碰不到。

反过来，如果图省事，拿"启元"这两个字去替换，风险更大——公司名、集团简称、其他产品线里都有"启元"，一换就是大面积误伤。技术文档里还有一处不该动的地方：部分文章需要保留历史版本名称，用来记录产品演进过程。

还有一条硬性约束来自品牌规范本身：新产品名在文中首次出现时必须使用全称，不能用简称草草带过。这意味着替换的目标文本必须写全、写准，不能像有些人图快那样统一改成两个字了事。

问题的难点从来不是"替换"这个动作，而是要一次覆盖三种写法、又要保证每一处都替换得准确无误。

四、分类圈出、逐类预览、分批替换

技术同事提醒她，后台的"批量替换"针对的正是这种情况。林静照着一路做下来，前后不到半小时。

第一步，先把范围限死。替换可以指定站点、节点、内容模型和字段。她只勾了官网站点的"文章正文"和"标题"两处，技术文档站点单独处理，附件里的 PDF 一概不动——那是已经发出去的版本，不在这次统一范围内。

第二步，用正则把三种写法分别圈出来。这是整个流程里最关键的一步。如果把三种写法混在一条规则里，很容易互相覆盖——比如先替换了标准旧名，带版本号的变体就被截断了一半，再想匹配就难了。所以她把规则拆成三条：第一条只圈标准旧名，第二条圈带版本号或品牌前缀的变体，第三条圈英文缩写（大小写都覆盖，加上"忽略大小写"，避免 QYCloud、qycloud 这类写法漏掉）。三条规则各管一段，互不干扰。

第三步，逐类查看匹配示例，确认命中范围。每一条规则都可以先跑一遍预览，把命中的内容一条条列出来。林静把三条规则挨个预览了一遍，重点核对了那些"疑似不该改"的位置：有一批文章是记录早期版本的技术方案，文中的旧名字属于历史事实的一部分，不能改；还有几处是客户名称里带"启元"两字的，得单独排除。她把这些位置逐条挑出来，剩下的命中结果与之前的统计完全对得上——1450 处、380 处、210 处，一处不多，一处不少。

第四步，按类别分批执行替换。确认无误后，三类规则分三次执行。中文的替换成"启元数智平台"，带版本号的保留版本号、只换名称部分，英文缩统一为规范里的英文写法。之所以分批而不是一次全上，是为了万一某一类出了问题，能立刻定位到是哪一条规则，而不是把 2040 处混在一起排查。替换完成后系统自动清理缓存——这一步容易被忽略，缓存不清的话，后台明明已经改好，前台页面显示的却还是旧名字。

第五步，导出完整日志，交市场部核对。哪篇文章改了、哪一类规则命中了它、改前改后分别是什么，日志里都有记录。这份东西当天就发到了市场部群里——按类核对一次，比逐篇翻一遍快得多。

五、名字换了，客户记得的却还是旧名字

整个过程做完，实际投入30分钟。原本估算的 72.5 小时、9 个工作日，压缩成了一个上午的核对工作。省下来的不是打字的时间，而是逐篇打开文章、翻找旧名、保存刷新的那一整套机械动作。

一周后，第一条客户反馈来了。之前那位问"是不是两家公司"的客户，在邮件末尾加了一句："新名字挺好记的。"

这类需求并不只出现在产品线重构。公司更名、集团并购后的品牌统一、部门撤并后的机构名称调整、政策文件里术语口径的更新，本质上是同一件事：一个名称变了，全站成百上千处都得跟着变。而这些位置不是集中存放的，它们散在多年前的文章里、旧的公告里、模板生成的文末里，谁也说不出到底有多少处、有多少种写法。

批量替换解决的就是这一步：先用规则把各种写法分别圈全，用预览确认每一处都该改、每一处都改得对，再分批次执行，最后留下可查的记录。它不改变内容本身，只是让"全站同一条信息保持一致"这件事，从九个工作日的体力活，变成半小时的核对工作。

改名是一次的事，改全站是成千上万次的事。