把自有媒体的运营交给 AI 时由人判断的环节：来自自家媒体 2 篇文章的记录
原文更新于 · 中文译文
AI 推进的工作与人决定的事项
在 Rootpublish 的记录中，制作文章的大部分工序由 AI 推进。另一方面，批准文章使用的一手信息、决定是否发布文章，由运营者判断。
2026 年 9 月，rootpublish.com 自家媒体的 2 篇文章（文章 2 和文章 3）是在电脑上的 WordPress 中制作的。Claude Code 推进的工序如下：选定主题、撰写给 AI 的请求文本、生成稿件、用与生成不同的另一次调用进行核对、翻译成英语、中文和韩语并核对译文、推送到网站，以及发布后的确认。
文章 2 由运营者批准一手信息，并在未修改正文的情况下发布。文章 3 则是按照运营者的指示，由 Claude 在管理界面中按下了批准一手信息和发布的按钮。按下按钮的是 AI，但是否按下由运营者指示。
这次运营是在运营者能在同一台电脑上下达指示和批准的状态下进行的，并不是无人值守的定期运营。在 Rootpublish 中，AI 生成的结果同样会保存为待批准状态，由拥有发布权限的人确认正文和出处，再决定是否发布。
生成与核对所花的时间
在文章 3 中，根据包含 31 条已批准一手信息的委托生成 7 段稿件，花了约 1 分钟。用与生成不同的另一次调用将该稿件与一手信息进行核对，花了约 15 秒。
两者都是在电脑上通过现有的 Claude 订阅使用 Claude Code 的结果。每篇文章的费用没有计量，运营者阅读并批准稿件所花的时间也没有计量。无法根据这些数字估算人的工作时间能减少多少。
核对发现的夸大与修改方法
用与生成不同的另一次调用（Claude Opus）核对后，在文章 3 的稿件中发现了 1 处夸大。
按照 Rootpublish 的规格，发布后对同一页面观察 7 天、根据实测结果进行判断的，只有搜索改进功能。然而稿件把它写得好像是发布后普遍适用的方针。在导入 WordPress 之前，这句话被改成了写明对象和条件的句子。
文章 2 的核对没有发现问题。在此之前制作的 3 篇试运行文章中，核对发现了 2 处问题：一句没有依据地定义了自动更新的对象范围，另一句把检查的时间点误写成“发布时”。两处都在 WordPress 中修改后才发布。
文章 3 中发现的夸大，不是数字错误，而是扩大了功能对象和条件的写法。如何根据核对结果进行修改，需要与原始的一手信息对照阅读后再决定。
译文核对中看到的局限
检查译文时，用与翻译不同的另一次 Claude Opus 调用比较原文和译文，让它指出遗漏、添加、含义差异、用语和不自然之处。
在文章 3 的英语、中文和韩语译文中，10 条意见里采纳了 8 条。未采纳的 2 条，是把为核对而提取正文的处理所加的符号误认为译文错误的意见。在译文检查的整体中，由于使用去掉标签的正文进行核对，也反复出现了“编号列表的编号和链接的 URL 缺失”的错误意见。
是否采纳各条意见，由 Claude 对照原文决定，尚未经过人工或母语者的确认。有一条意见建议把韩语中表示“发布”的词从「공개」改为「발행」。由于用语需要与已发布的文章保持一致，我们决定等待母语者的判断。这说明，还留下了仅凭 AI 核对无法决定的判断。
发布操作中停下来的场面
文章 2 的发布重做了几次，原因有两个。第一，页面内的发布确认栏在按钮下方的屏幕外打开，被看漏了。第二，打开确认栏的浏览器窗口处于隐藏状态，发布的点击没有送达。作为对策，我们把确认栏改为在按钮的位置显示，并把焦点移到确认按钮上。
在此之前也有问题：在不显示浏览器确认对话框的界面中，按下「承認して公開」（批准并发布）有时没有任何反应。因此，我们把发布确认移到了页面内。
在这些记录中，发布确认栏的位置和窗口的显示状态，曾导致发布操作没有送达。发布操作是否真正完成，需要在界面上确认。
一边运营一边重做管理界面
2026 年 9 月 25 日这一天，我们更新了 3 次 Rootpublish 插件（0.1.14～0.1.16）。原因是在自家运营过程中，运营者提出了意见：不知道该做什么，也不知道策划和确认该从哪里开始。
中间的版本在每个界面上增加了说明，结果反而让界面变得更臃肿。最终，我们把管理界面的入口整合为「やること」（待办）、「記事」（文章）、「会社情報」（公司信息）、「設定」（设置）4 个，并在每个界面用 1 行说明何时、为何使用。
此外，我们把每篇文章的阶段（策划、委托 AI、确认稿件、发布、查看效果）和下一步操作整合到了 1 个列表中。草稿状态的一手信息，现在可以在界面内确认后一并批准。在自家运营中，“不知道下一步该做什么”的意见，成为了重做管理界面的契机。
发布后被 Google 收录的页面
2026 年 9 月 25 日，我们向 Search Console 提交了站点地图。9 月 27 日清晨确认时，站点地图中的 36 个页面里，有 29 个已被编入索引。
尚未收录的 7 个页面包括韩语版文章 4 篇、英语和中文的文章列表，以及日语文章 1 篇。Search Console 的搜索数据要延迟几天才汇总，因此还无法确认搜索中的展示次数和点击次数。
Google 说明，对于 AI Overviews 和 AI Mode，即使满足展示要求，也不保证一定会被抓取、编入索引和展示。Rootpublish 也不保证搜索排名或被 AI 引用。被编入索引，并不意味着取得了成果。
这些记录无法说明的事
这些记录只是自家媒体 2 篇文章及其译文的小样本。人的工作时间和每篇文章的费用都没有计量，搜索排名和被 AI 引用等成果也还不清楚。
因此，不能说把运营交给 AI 就会自动运转，也不能说工作时间会减少或搜索成果会提升。这些记录能说明的，只是存在 AI 能够推进的工序，以及在核对和发布的环节需要人的判断和对界面的修改。
决定由人判断的环节的步骤
以下是根据上述记录和 Rootpublish 编辑指南的建议整理的步骤方案，并不是通过实测确认了搜索排名改善的方法。
第一，写出从策划到发布后确认的工序，再把让 AI 推进的工作和由人判断的工作分开。在我们的记录中，批准一手信息和决定是否发布留给了人。
第二，确定作为文章依据的一手信息，只使用已批准的信息。编辑指南建议记录时间点、条件、出处和公开范围，不用推测填补未确认的项目。Rootpublish 不把确认前的信息和非公开的信息用作文章的依据，并按稿件的每个段落记录所参照信息的 ID 和版本。不过，版本检查并不保证文字与依据的含义一致。
第三，设置与生成分开的核对，并决定由谁决定是否采纳其意见。对于译文用语这类需要与已发布文章保持一致、或需要母语判断的内容，事先定好交给人判断的标准，就不容易犹豫。
第四，确定发布前的确认项目。编辑指南建议确认每个主张与依据的对应、数字与条件、公开范围，以及读者的下一步行动。我们记录中发现的夸大，也是扩大了功能对象和条件的写法。
第五，决定由谁按下发布按钮，以及如何确认发布已经完成。即使像文章 3 那样把操作交给 AI，是否按下的指示也应由人发出。
最后，决定发布后在什么时候确认什么，并记录确认的时间点。Google 建议，即使使用生成式 AI，也要重视准确性、质量和相关性，并指出不为用户增加价值的大量生成可能违反垃圾内容政策。这些步骤的前提是：与其增加文章数量，不如优先发布依据可以确认的文章。