小編精選 - 技術文章翻譯 · 06月25日

Vibe Coding 正在重演「RPA 問題」：防止個人化、重複與黑盒子的最小治理設計

前言

我是 GMO Connect 的平島。

自從團隊開始使用 Claude Code 之後，雖然變得更方便了，但也衍生出一些問題。「好像是某個人做的 Slack 通知工具」「有 3 支類似的彙整腳本」「如果不是做的人本人，什麼都不知道」😇

這個景象，我彷彿也在 2019 年左右 RPA 普及期看過。參考當時是怎麼跨過去的，我思考了在 vibe coding 時代的編排設計。

正在發生的事：因 vibe coding 而產生的「影子 AI 開發」正在擴大，個人依賴、重複開發、黑箱化也隨之加劇

結構上的相似性：和 RPA 普及期（2018～2020 年）的「現場機器人亂竄」是同一種模式

需要採取的對策：

因為用 Claude Code 或 Cursor 開發應用程式的成本下降了，所以個人工具、內部腳本、自動化機器人會急速增加。問題是，這些東西會分散在 個人的本機、個人的 GitHub 儲存庫、個人的 Slack 通知 裡。

當出現「這支腳本是誰在管？」的對話時，就只能回頭翻 Slack 紀錄。

vibe coding 做出來的工具，常常會變成 只有原作者能部署、也只有原作者能修 的狀態。AI 產生的程式碼雖然能跑，但真正看得懂其架構的，往往只有做出來的人。

當負責人調動或離職時，就會出現「工具停了」「無法登入」「根本不知道它在做什麼」之類的狀況。

如果沒有目錄，就很難察覺「其實已經有類似的東西了」。於是會出現一個部門一支 Slack 通知腳本、另一個部門又一支、資料彙整工具也有 4 套之類的重複問題。因為有 AI 就能很快做出來，所以比起「找現成的」，大家更傾向「重新做一個」。

2018～2020 年左右的 RPA 普及期，也發生過同樣的事情。

UiPath、WinActor、Blue Prism 受到關注，以「不用寫程式就能自動化業務」為賣點，導入到現場的速度大幅加快。各部門不經 IT 部門就自行開始做機器人，短時間內整個組織的機器人數量爆炸性增加。

結構是相同的。「個人也能輕鬆做出來」「開發成本大幅下降」這些特性，會讓擴散速度先於治理機制的建立。

RPA 產業給出的答案是 CoE（Center of Excellence，卓越中心） 和 Orchestrator（編排器）。

CoE 是負責公司內 RPA 推動與管理的橫向組織。它統一管理各部門自行製作的機器人，並定義設計標準、資安政策、生命週期管理。技術上則由像 UiPath Orchestrator 這樣的平台負責機器人的執行、監控與權限管理。

並不是把體制退回到「全部都由 IT 部門來做機器人」，而是允許現場自己製作，同時建立目錄、所有者、生命週期。在保留現場彈性的同時，確保可視化與可交接性，這就是關鍵。

vibe coding 時代也可以採用相同的方法。

我的基本方針是：「在做重型機制之前，先用最小配置開始」。

首先只要把「目前有哪些東西」列成清單，就能提高發現重複開發與個人依賴的速度。

最小管理項目如下：