Skill Ops：以 AI 代理為前提來設計營運

截至 2026 年 10 月，我在營運 19 款 App。 每個月推出 6 次以上的改善版本，並上架 4 款新 App。

一個人營運這麼多 App，靠手動營運當然撐不住。 必須把心力全部放在做決策上。

在和 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 為前提來設計營運。