AI 没有取代运营，而是让优秀的运营更有价值

你已经准备好测试一项 WooCommerce 扩展更新。AI 帮你梳理发布说明，你也已经打开了一份测试计划草案。这时，一位同事问你这次更新是否会影响某些自定义结账规则。你知道有几个客户网站存在这类规则，但具体是哪些呢？

你在 Slack 上询问。熟悉这些网站的开发者一直在开会，要到午餐时间才有空，因此你趁等待期间先处理了另一个工单。

另一家代理机构使用相同的 AI 工具，但其开发者能在每个网站的备注中找到结账例外情况。还有一笔测试订单可以用来验证，旁边写明了预期折扣。他们可以立即开始检查。

随着 AI 缩短你准备变更所花费的时间，这些日常细节对你能完成多少工作的影响也越来越大。我们将探讨如何让团队更容易利用网站知识，并为开发者提供评估 AI 建议所需的证据。我们还将介绍如何判断这些改进是否为整个客户组合节省了时间。

工作开始积压的地方

借助 AI，你用二十分钟完成了一个补丁，然后提交审核。你的技术负责人需要检查同一项自定义设置是否也运行在某位客户的另一个网站上，但要等到周四才能处理。你继续工作。等他们打开第一个工单时，你已经有另外四个补丁在等着他们。

你可以从工单时间戳中看出这个问题。编写只需几分钟，等待却要花费数天。再购买一份 AI 订阅并不会缩短这段延迟。

在 Atlassian 的 2025 年开发者体验研究中，50% 的开发者表示每周至少花费十小时处理非编码工作，主要原因是组织效率低下。该调查覆盖六个国家的 3,500 名开发者和管理者。查找信息是浪费时间的主要来源之一。这些是受访者报告的体验，而非实测的工时记录，但它们为代理机构提供了一个值得调查的切入点。

你团队中的某个人可能会在每次审核时花上一部分时间寻找代码仓库链接，或提醒同事哪些网站共享某项自定义设置。即便是已经准备好立即进行测试的人，也可能不得不等待对方提供访问权限。

将这些详细信息保存在网站记录中，并确保负责相关工作的开发者拥有所需权限，可以避免这种情况。同事应该能够找到现有的测试说明并立即开始工作。技术负责人仍然可以在变更表现异常时介入，而不必每次都还要回答“代码在哪里？”

你的团队所维护的网站知识会变得更有价值

一家批发商店的自定义定价端点需要几秒钟才能响应。被问及如何加速时，AI 助手建议将响应缓存十分钟。这样一来，网站就不必在每次请求时都重新计算价格。

不过，每位客户都有协议价。如果把保存的响应返回给了错误的账户，采购人员就可能看到另一家公司的定价。编写该端点的开发者知道它为何要绕过共享缓存。六个月后接手性能工单的人，可能只会看到一个让网站运行更快的优化机会，却没有意识到这项变更会暴露什么风险。

当然，端点旁边的注释可以写得很直白。例如：“每个批发账户都有各自的协议价。请勿将此响应放入共享缓存。”这样就足够了。

在站点记录中，指引同事查看代码，并找出两个定价不同的测试账户。变更后，他们可以使用每个账户登录，并将显示的价格与买家应获得的价格进行比较。

这样，你的同事就有理由质疑拟议中的 WordPress 缓存变更。当你让 AI 助手审查替代方案时，这也为它提供了更有用的上下文。

想想你在将站点移交给同事时会提到什么：

• “采购部门将在周一的会议上使用这份报告。在此之前必须准备好。”
• “导入中的日期使用供应商所在的时区。”
• “我们正在等待这个插件问题解决后再移除临时解决方案。”请附上问题链接。

当插件更新解决了问题时，你应记录下来并添加日期。旧说明可以保留，AI 摘要也不应继续推荐你的站点已不需要的临时解决方案。

使用你所在机构批准的 AI 工具，并从粘贴给它的任何内容中移除凭据。客户详情通常也可以排除；只有当问题需要时才包含。答案中应附上相关代码或设置的链接，以便下一位开发者检查它是否与站点上的内容一致。

良好的诊断信息能让开发者更快判断 AI 的建议

“结账有时感觉很慢”会留下大量猜测空间。AI 助手可以立即列出一组看似合理的原因。有用的诊断信息则能让你开始逐一排除这些原因。

小订单都能顺利通过。但如果在购物车中放入十二种不同的产品，重新计算总价却需要六秒。应用程序性能监控跟踪指向自定义折扣函数。对于购物车中的每一行，它都会再次访问数据库，检索同一买家的订单历史。

现在你有一个具体问题：该函数能否只检索一次历史记录，并在同一次计算过程中重复使用？你可以在这一限制下请 AI 协助检查代码。

在暂存环境中更改后，重复十二种产品的测试并检查查询次数。验证更改数量后折扣是否仍保持正确。如果客户收到错误的总价，响应时间再短也没有意义。

如果团队里的其他人第二天早上接手结账问题的调查，他们有跟踪记录，但会知道你使用批发账户在暂存环境中运行了测试吗？你需要在工单中写明这一细节。对于 WordPress 错误日志，应提供对应的时间范围和时区，以便他们找到同一次测试的记录。

当 AI 协助调查时，这也很重要。Splunk 的《State of Observability 2025》调查了 1,855 名可观测性专业人士，其中 48% 将数据质量不佳列为 AI 准备就绪的主要障碍。无论跟踪记录看起来多详细，如果不说明是哪个账户触发了折扣规则，都会让助手可供参考的信息更少。

这也能改善你向客户发送的更新。你可以解释，大型购物车会反复加载相同的订单历史，并描述用于检查修正内容的测试。客户得到的是对延迟原因的说明，而不是又一消息称你正在尝试几种方法。

一致的环境能让改进在整个组合中发挥作用

只要你知道还能到哪里查找，一项性能修复就能节省多个站点上的工作量。

假设某个报表插件每十五分钟重新计算一次年度订单总额。客户只会为每周会议打开该报表。你确认重复重算会占用数据库时间后，便将调度频率调整为与客户使用报表的方式一致。

贵机构还在另外十一家门店安装了同一插件。如果有当前库存清单，就能识别这些门店并检查其设置；如果没有，就只能由有人逐个打开仪表板，或搜索发票中该插件的名称来查找。

当你管理多个 WordPress 站点时，“这个站点的自定义代码保存在哪里？”很快就会成为令人厌烦的问题。熟悉文件位置可以让同事少找一番，而各项设置始终使用相同名称的记录也有帮助。调度说明可以解决插件设置无法回答的问题，例如服务器是否触发 WordPress 定时任务。

“员工全天都会查看这份报表”应与站点说明中的刷新设置写在一起。照搬其他门店的每周调度安排，会让他们使用过时的数据。还要在该记录中注明已安装的插件版本。开发者可能浪费时间去寻找新版中才有、却未出现在这家门店任何设置里的调度控件。

AI 可以帮助比较导出的设置，或整理一份可能匹配的清单。应用更改前，应将这份清单与实际站点进行核对。仅凭插件名称相同，并不能证明客户使用该功能的方式相同。

在插件的设置说明中加入“客户多久使用一次这份报表？”。开发者为下一家门店安装插件时，可以在入驻过程中确定调度频率。客户只在周一上午打开的报表，几乎不需要整周每十五分钟重算一次。贵团队已经调查过一次这个问题；下一次安装就能从答案中受益。

将 AI 融入现有的审查流程

周二进行插件审查往往意味着要花大量时间查看变更日志。每个站点都需要有人将已安装的版本与新版本进行比较，并判断哪些变更值得重点关注。例如，采用自定义折扣规则的商店，需要特别留意任何会影响结账价格计算方式的变更。

这就给 AI 助手赋予了一项明确的任务。只需提供已安装的版本以及对折扣规则的说明，它就能筛选出可能影响计算的变更。摘要需要包含指向发布说明的链接，以便开发者结合上下文阅读相关条目。开发者仍会判断更新是否影响商店，但一开始就有了更少需要筛选整理的材料。

“检查我们的所有站点，并告诉我们哪些需要关注”会让它无从下手。它可能生成一份看似详尽的报告，却遗漏开发者所需的那一项兼容性细节。

先在几个你非常熟悉的站点上尝试范围更窄的任务。将输出与你自己的审查结果进行比较。它能否区分拟议的修复与已发布的修复？它会将缺失的版本号视为未知，还是用猜测来填补？

该脚本会将每个站点已安装的插件版本与可用版本进行比较。它还会标记缺失的配置导出。

当某个站点未能返回配置时，报告会显示：“审查未完成。此站点缺少配置导出。”这一条目会让该站点继续留在审查人员的待办事项列表中。空行很容易被误认为是通过检查的站点。

衡量你获得的能力提升

一个下午没有接连收到“到哪里能找到这个？”之类的消息，就能让你的技术负责人腾出时间完成客户工作。你完全可以在再接手一个客户之前看到这种好处。

你的项目和支持工单可以显示，你正努力缩短的延误是否确实有所减少。根据一直拖慢工作的因素，你可以追踪：

• 发布等待时间：一项已完成的变更需要闲置多久，才有人能够验证并发布？
• 调查时间：开发人员需要花多长时间来确定已报告问题的原因？
• 重新打开的工单：团队将修复标记为完成后，同一症状再次出现的频率有多高？
• 计划外支持工时：原定的项目时间中有多少被用于意外的维修？

例如，假设有六张相似的维护工单，每张都需要项目负责人查找配置详情。在你改进站点记录之后，审查接下来进来的六张工单。如果团队中的人能够处理其中五张而不受这种打断影响，而且修复仍然有效，就说明这些记录确实有所帮助。

当有人关闭一张工单，并把剩余的调查工作移交给同事时，团队仍需在该项修复上花费时间。如果不把五分钟的打断计入工时表，开发人员往往会低估自己的支持工时。无论是否记录，这些打断仍会打乱他们一天的工作。

连续数周的可比工单能为你判断是否有任何改善提供更可靠的依据。工单量在这里很重要。无论文档或 AI 工具是否发生变化，清闲的一周自然会为项目工作留出更多时间。

现在，你的负责人有两个下午可用于客户项目。支持工作繁忙的一周能让你看出是否可以依赖这段时间。如果他们能在不把一半工作推迟到下周的情况下完成既定工作，你就更有把握对另一个客户说“可以”。

团队熟悉的托管环境

“查看日志”这句话默认你的同事知道在哪里找到日志。如果每个客户使用的托管商都不同，他们可能会在处理支持工单的前半段时间里，在陌生的仪表板中寻找日志。熟悉的托管环境能让他们直接投入调查。

Kinsta 将这些任务整合到 MyKinsta 中。当某个商店变慢时，开发人员可以启用 Kinsta APM 进行一段调查，并检查涉及 PHP、数据库查询和外部请求的事务。他们也可以在仪表板中查看该站点可用的日志。

开发人员可以使用批发测试账户，在 WordPress 预发布站点上重现那个包含 12 件商品、加载缓慢的购物车。他们知道折扣应该是多少，因此可以在不触及实时订单的情况下检查修改后的计算结果。比较速度则需要更加谨慎。如果预发布环境使用了不同的缓存设置，或可用资源少于生产环境，那么测得的耗时就无法提供可靠的对比结果。

当同事代班处理支持工作时，“你能给我访问权限吗？”不应该成为你收到的第一条消息。MyKinsta 的用户管理功能让你能够提前授予他们预发布环境的访问权限，而生产环境访问权限则保留给实际部署修复的人。如果那位同事经常在你的各个客户站点之间工作，你可以为其分配公司级角色，而不必分别安排每个站点的访问权限。

当多家商店使用你的折扣扩展时，站点标签能让这些安装更容易找到。如果某个修复需要测试，你可以调出该组，然后查看每家商店的项目记录，了解其定价规则。不过，标签需要与站点上的实际情况保持一致。不再使用该扩展的商店不应继续出现在列表中。

优先投资的方向

“仍在等待预发布环境访问权限”这样的评论可能会在工单中停留半天，而结账修复却等着测试。如果最近的工单中反复出现这条评论，你就有一个需要解决的具体问题。负责这些商店的开发人员需要相应账户，以便他们无需等待账户所有者重新上线就能完成工作。

团队中有人尝试自己登录，比查看已分配权限的列表更能说明问题。他们可能能够进入仪表板，却仍无权访问所需环境。在工单之间发现这一点，可以让你有时间解决问题，而不必让客户干等。

“运行常规结账测试”这句话默认你的同事像编写折扣代码的人一样熟悉该商店。他们可能完全不知道哪个账户符合批发定价条件。将该账户参考信息放在折扣规则链接旁，可以避免他们等待作者回复。

“我已登录。购物车总额应该是多少？”下一张工单中出现这样的评论，就能看出团队成员仍需要哪些帮助。回答时，应将预期金额放在账户参考信息旁。否则，下周负责结账的人可能会问你同样的问题。再次如此。

让下一个站点更易于支持

回到这两家机构，两名开发人员都在十点前准备好了 AI 生成的测试草稿。掌握已记录在案的结账例外的团队可以直接使用草稿。另一支团队仍需要等会议中的人给出答复。

随着 AI 帮助团队准备更多工作内容，这些小优势会变得更有价值。它们让你可以利用额外交付成果，而不必把每个问题都发给同一个人。

选择一个反复出现的延误并将其消除。然后向下一位开发人员提供足够信息，使其能够利用这项修复。随着客户组合不断增长，Kinsta 的托管 WordPress 托管服务为你的团队提供了一个熟悉的场所，用于调查和测试变更。

这篇题为《AI 没有取代运营，而是让优秀的运营更有价值》的文章最初发布于 Kinsta®。