公司該不該自己養一套 AI Skill？決策標準與最容易低估的維護成本
☰ 目錄 table-of-contents.md
公司買了 AI 訂閱，十個人都在用，用了半年之後你會發現一件事：同樣的工具，產出品質差很多。有人交出來的東西可以直接用，有人交出來的還要花時間改到能看。追下去通常不是能力差距，是每個人跟 AI 交代事情的方式不一樣，而那些交代方式沒有被寫下來過。
這時候會浮出一個問題：要不要花力氣把公司的做事方法整理成 Skill，變成大家共用的東西。這篇不談技術，談這個決定該怎麼做，包含我們認為最容易被低估的那一項成本。
問題不在模型，在規矩沒有共用
同一個模型、同一個訂閱方案，產出差異來自輸入的差異。資深的人會下意識補上一堆條件：格式要怎樣、哪些東西不能寫、遇到不確定的地方要先問。新人不知道有這些條件，於是拿到的東西就是模型的預設值。
這件事跟 AI 其實沒什麼關係，它是老問題的新版本。以前是新人寫的文件跟老鳥寫的不一樣，現在是新人指揮 AI 產出的東西跟老鳥指揮的不一樣。差別在於，這次那些隱性知識有地方可以放了。
三種做法，成本結構完全不同
| 不做 | 個人各自累積 | 公司統一維護 | |
|---|---|---|---|
| 初期投入 | 零 | 低，各自摸索 | 中，要有人整理 |
| 品質一致性 | 看個人 | 還是看個人 | 可控 |
| 人離職的影響 | 無差別 | 那套方法跟著走 | 留在公司 |
| 持續成本 | 零 | 零（但重複踩雷） | 要有人維護 |
| 適合的規模 | 一到兩人 | 三到五人 | 五人以上或流動率高 |
中間那欄是多數公司現在的狀態，而且它有個容易被忽略的問題：每個人都在各自踩同一批雷。一個人花兩小時搞清楚某個工具的坑，隔壁同事下個月會再花兩小時搞清楚同一個坑。人一多，這筆重複支出比想像中大。
判斷要不要做的三個問題
與其看公司規模，不如看這三件事的答案。
第一，有沒有一件事是三個人以上會重複做的。如果公司裡的工作高度分化，每個人做的事都不一樣，那共用 Skill 的效益會很有限，比較適合各自累積。反過來說，如果有一批人在做結構類似的工作（客服回覆、報表整理、文件產出、程式碼審查），那就有共用的基礎。
第二，做錯的代價高不高。如果產出只是內部參考，錯了改一下就好，那不寫 Skill 也還好。如果產出會對外、會進到正式環境、或牽涉法遵，那把判斷標準固定下來的價值就很高，因為它擋掉的是「某個人那天剛好沒想到」。
第三，人員流動高不高。這題的答案最直接影響投報。流動率高的團隊，每次交接都在重新傳授同一批隱性知識，而 Skill 正好是這類知識的容器。這個角度我們在把同事的經驗煉成技能包裡談得比較細。
最容易被低估的那一項：維護
導入的討論通常集中在「要花多久建起來」，但真正決定成敗的是建好之後有沒有人管。
Skill 會過時，而且過時的方式很安靜。我們自己就踩過：一份分析用的 Skill 裡寫著某個當時正確的判斷依據，三個月後那個前提已經改變，但沒有人回去更新，於是它繼續用很有把握的語氣給出已經不成立的建議。這種錯誤讀起來完全合理，不會有任何警訊，只有知道實情的人才會發現不對。
所以評估的時候，維護成本不能算零。實務上的估法是：每一份在用的 Skill，每季至少要有人花時間確認一次裡面的前提還成不成立。這件事沒有人做，那套東西的可信度會隨時間遞減，而它造成的損失比沒有 Skill 更大，因為大家會相信它。
誰來維護，是組織問題不是技術問題
這是我們看過最多失敗的地方。Skill 通常是某個熱心的同事做起來的，大家用得很開心，但沒有人被正式指派要維護它。那個同事換部門或離職之後，這套東西就進入無人管理狀態，繼續被使用，也繼續老化。
比較能撐住的做法是把維護責任綁在流程上而不是綁在人身上：誰負責那個業務流程，誰就負責對應的 Skill。這樣人換了責任還在。另外一個實務建議是每份 Skill 的開頭寫清楚「最後確認日期」與「負責的流程」，這兩行字的成本極低，但它讓過時這件事變得看得見。
技術上的兩個限制會影響你的選擇
有兩件事在決定導入方式之前該知道，因為它們會直接影響可行性。
第一，不同介面之間不會自動同步。網頁版、API、以及開發工具環境是三套獨立的東西，同一份 Skill 要在哪裡用就得在哪裡放一份。
第二，也是對企業影響比較大的：網頁版的自訂 Skill 是綁在個人帳號的，官方文件明講管理員無法統一派發，也無法集中管理誰裝了什麼。這代表如果你的目標是「讓全公司照同一套規矩做事」，只靠網頁版做不到，得走開發工具的專案目錄（跟著版控走）或 API 的工作區共用。這件事在評估階段就要想清楚，不然會建到一半才發現佈署不下去。
好消息是投入不會被綁死
2025 年底這套格式被開放成公開標準之後，主流的 AI 開發工具陸續採用了同一份規格。實際的意義是你花時間整理出來的流程知識，不會因為之後換工具就報廢，換一個環境放進去就能繼續用。
對評估導入的人來說，這降低了決策風險。你賭的不是某一家廠商會不會活下去，是「把公司的做事方法寫下來」這件事本身有沒有價值，而後者的答案跟 AI 其實沒什麼關係。
如果決定要做，建議的順序
不要從建制度開始，從一件事開始。挑一個目前最多人重複做、而且做錯有感的工作，把它寫成第一份 Skill，讓三五個人實際用一個月。這一個月要收集的不是滿意度，是它判斷錯的地方，那些才是要補進去的內容。
跑順了再擴散到第二個流程。多數失敗的導入案例都是一開始鋪太大，同時開五六個流程，結果每一個都只做到一半。至於整體的落地節奏，可以參考把流程交給 AI 代理人：監督者角色與安全落地裡談的階段劃分。
費用的部分，如果是自己內部整理，主要成本是人的時間；如果要外部協助把流程盤出來並建成可維護的結構，依整合深度與流程數量落在幾萬到幾十萬不等。這件事的投報高低，關鍵不在建了幾份，在有沒有真的被用起來。
我們自己也在做 AI 產品：Ocean Bot 業務助理、玄燈命理 DestineAI、PiMe AI 形象照，以及陪跑者 PACER 這個 AI 原生官網，都收在作品案例裡，可以看看落地之後實際長什麼樣。
如果你們已經在用 AI 但品質參差，或是想把公司的做事方法沉澱下來卻不確定從哪個流程切入、之後誰維護，這正是我們AI 自動化開發實際在做的事。跟我們聊聊你們現在最多人重複做的是哪一件。
延伸閱讀
RoamerHost 幫你把開源 AI 與自動化工具一鍵代管：獨立 Docker、自動 SSL、24/7 監控，60 秒上線。省下租機器、裝環境、顧維運的力氣，訂閱就能開始用。
▶立即免費註冊常見問題
公司規模多大才值得自己養 Skill？
導入最容易被低估的成本是什麼？
誰應該負責維護？
能不能由管理員統一派發給全公司？
投入之後會不會被特定廠商綁死？
這個主題的完整脈絡、選型比較與導入建議，都整理在指南裡。
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。