Skill Ops：以 AI 智能体为前提来设计运营

截至 2026 年 10 月，我在运营 19 款应用。 每个月发布 6 次以上的改进版本，并上线 4 款新应用。

一个人运营这么多应用，靠手工运营当然转不过来。 必须把精力全部放在做决策上。

在和 AI 对话时，冒出了“skill ops”这个词。 用 Google 搜索几乎找不到，看来是碰巧造出来的新词。我非常喜欢这个说法。

Skill ops。

就是以 skill 为前提的运营。 比如在以前的公司，是人辛辛苦苦地搭建数据平台，再由人来收集和分析数据。 一个人做这些事，运营根本转不起来。

只把 Firebase 和 Google Analytics 的基础搭好，分析工作交给 AI。

• 数据分析，一句“分析一下”就搞定
• 日志分析，也一句“看一下”就搞定

针对得出的结论，判断“要做什么”并下达指示，才是人的工作。

我在运营 Tenkaichi 和 Buzz Spot 这两个网站。 因为还处在上线初期，内容自然很少。如果没人发帖，在内容充实起来之前，只能我自己发。

话虽如此，如果所有文章都自己写，运营就转不过来。

• “调查一下这家店，整理成内容”
• “乐平和两面宿傩，谁更强？”

像这样向 AI 提问，就能全自动地一直做到发布内容。 SEO 也一并处理。sitemap.xml 的更新、Search Console 的索引提交，也都用 skill ops 来跑。

skill ops 的经验在企业级开发中同样适用。 比如过去发生故障时，我们是按下面的步骤排查的：

1. 在 CloudWatch 或 Elasticsearch 里查看日志。
2. 排查产生这条日志的代码。
3. 如果不在自己团队的负责范围内，就在 Slack 上联系对方团队排查。
4. 在本地环境里反复试错，修复问题。

现在可以把 backend、frontend、infra 的仓库都放在本地，从查日志到查仓库，全部交给 AI。 当然，让 Claude Code 查看生产环境的全部日志存在安全问题，需要限定在开发环境，或者只提供摘录。即便如此，以 AI 智能体为前提的运营，在企业里也完全用得上。

不如说，我预计今后如果不以 AI 智能体为前提来设计所有工作，在生产效率上就会越来越“难受”。 人努力一下也能做到，但会觉得“麻烦”。这是因为我们已经知道了 AI 有多方便。

为了让人专注于决策，最好从一开始就以 AI 为前提来设计运营。