TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Replit 代理技能更新：對話變可重用流程，入庫前由人把關
Replit 在 10 月 23 日官方週報宣布，Agent 可從對話建議建立或更新工作區技能，經使用者審閱同意後保存進技能庫。本文從官方文件整理技能結構、方案權限矩陣、Private／Required／Available 分享政策，以及聊天與素材分享的存取邊界。
用 AI 摘要這篇文章：
10 月 23 日，Replit 在官方週報裡宣布了一項位置很微妙的更新：Agent 現在可以從對話中建議「把這段流程做成技能」，也能建議改善既有的技能，而在它保存進工作區技能庫之前，會先經過使用者審閱與同意。同一份週報還一起推出了聊天分享與單一素材分享，等於把團隊知識「怎麼寫入、怎麼分發、過程讓誰看到」三件事一次交代。
判斷先講：這次更新真正該看的地方，不在「代理會寫技能」。技能資料夾、上傳、請代理起草這些入口本來就存在，差異化在把關的位置被明確畫出來了：寫入權交給代理，入庫權留給人，分發交給分享政策。而且官方文件在同一時間把三個「不保證」寫得相當直白：引導不等於強制、可見性不等於控制權、唯讀不等於隔離。這三句話比新功能本身更該在導入前細讀。
適用範圍先說清楚：工作區技能管理是付費方案功能，Enterprise 工作區只有管理員能管，Core 與 Pro 則是任何成員都能管；共同指示（custom instructions）這一層要 Pro 以上才有，Core 沒有。Replit 是雲端服務，官方文件沒有列出地區限制。以下內容以 10 月 27 日當下的官方文件與週報為準。
技能是資料夾和一份 SKILL.md，不是聊天的備份
官方文件對技能的定義很樸素：一個資料夾，裡面放一份 SKILL.md，寫著 Agent 處理特定任務時要遵守的指示，再加上想讓它參考的輔助檔案。範圍分兩層：專案層技能放在專案的 /.agents/skills 目錄，跟著檔案一起進版本控制；工作區層技能集中在 Workspace Settings 管理，符合存取條件的成員都能使用，不必每個專案各放一份。
載入機制是這套設計裡最需要花時間理解的一段：Agent 在每則對話都會讀取所有已安裝技能的名稱與描述，但只有在判斷與當前任務相關時，才會把全文載入。所以名稱說明「它是什麼」，描述要讓 Agent 知道「什麼時候該用」，官方還特別提醒描述要寫清楚何時用、何時不用。描述寫壞了，技能裡的程序再好也等於不存在。
官方自己在文件裡踩了煞車：技能要省著用，數量太多或範圍重疊會稀釋 Agent 的焦點，讓它更難挑對。對「把所有流程都做成技能」的衝動，這是很實用的一句提醒。使用時也不必每次手動挑選：工作區技能會出現在每個專案聊天輸入框旁的加號選單頂端，成員可以點選，也可以輸入斜線加上技能名稱直接呼叫；平常則交給 Agent 根據描述自行判斷要不要載入。
除了自行建立，Replit 也內建一批預載技能，從選單選了就用，不需要安裝；夥伴技能則是服務廠商出版的技能包，教 Agent 按照自家產品的慣例做事。這套結構遵循 Agent Skills 開放規格，技能並非 Replit 的私有格式，同一份技能可以在相容的代理工具之間搬移；官方文件也示範了用 rulesync 指令，把其他 AI 編碼工具的技能設定轉進 Replit 統一維護。把領域知識做成可分發的技能包這件事，其他生態也在同步發生，例如Unity 官方就曾在兩天內先後上架 Claude Code 與 Codex 的目錄。
代理建議、人來點頭：入庫的那道閘門
週報對新流程的描述翻成白話是：把對話與專案裡有用的流程，變成可重複使用的工作區技能；Agent 可以建議新技能或對既有技能提出改善，使用者審閱並同意之後，才會保存進工作區的技能庫。建議出現，不代表代理取得了替團隊改規則的權力，入庫前的最後一關仍然是人。
有個時間差要攤開來看：技能說明頁的文件更新時間還停在 10 月 14 日，也就是說，「建議、同意、入庫」這道新流程目前只存在於週報的一句話裡。現行文件列的建立方式仍是三種：上傳既有的技能資料夾、在表單裡直接寫、請 Agent 起草後再修改；就連請 Agent 把技能打包成 zip 下載、再手動上傳到工作區設定的舊路徑，也還完整留在文件上。同意流程的介面位置、按下之後的實際行為，官方尚未寫成獨立的說明文件。
權限那端倒是寫得很清楚，下表是官方文件的原意：
| 功能 | 適用方案 | 誰能管理 |
|---|---|---|
| 共同指示 | Pro 與 Enterprise | Enterprise：管理員；Pro：任何工作區成員 |
| 技能 | 所有付費方案 | Enterprise：管理員；Core 與 Pro：任何工作區成員 |
這張表裡藏著一個不太對稱的設計：Core 工作區上，任何成員都能建立、編輯、刪除技能，但整個工作區沒有共同指示這一層可用。Core 團隊可以累積「做某類工作的方法」，卻缺少「全工作區永遠生效的規則」。無論哪種方案，工作區裡每個成員都能使用已經建立的技能。
官方對共同指示的描述也很有分寸：Agent 被引導去遵循這些指示，但嚴格要求不保證一定被執行；內容越短越具體，被遵循的可靠度越高。這句誠實話同樣適合用來理解技能的 Required 狀態，下一節會講。
Private、Required、Available：政策管的是可見性
技能建立時預設是 Private，只有建立者與工作區管理員可以使用。要開放給其他成員，需要設定工作區成員的存取政策，選項有三個：
- Required：永遠開啟，成員不能自行關閉。
- Available：可選，預設關閉，成員自行開啟後才會生效。
- No access：對成員隱藏。
這三個狀態決定的是成員看得到、用不用得到；至於 Agent 是否一定照做，政策本身並沒有承諾。把技能設成 Required，意義是成員不能把這份技能關掉，僅此而已；代理能不能實際修改或發布什麼，仍然由對應工具與外部服務的權限決定。真正的安全邊界要放在系統權限那一層，技能與指示都是引導，官方文件在這一點上沒有含糊。
操作細節上有個容易搞混的差別：技能的分享政策選完立即生效，沒有另外的確認按鈕；聊天分享的權限變更則要按下 Save 才會保存。兩種介面契約不一樣，改錯方向時補救方式也不同。另外技能內容修改之後，只會適用於未來的對話，不會回頭改寫正在進行中的對話，維護者需要知道同事的對話是何時開始的，才能理解對方套用的是哪一輪設定。
要把「團隊該記住的東西」分層，官方給了一組清楚的三角：記憶（Memories）由 Replit 在使用者監督下寫入，性質是情境證據，不能當成可執行的指示，而且預設私人；共同指示放長期規則；技能放特定任務的程序。明確的請求與共同指示，優先權都高於記憶。同一件事不需要複製到三層裡。
分享聊天，拿到的是會持續更新的唯讀存取
同一份週報推出的聊天分享，性質比「丟一個連結給同事」更持久：它是持續的唯讀存取，包含之後陸續出現的訊息與素材，不是固定時間點的快照。如果 Routine（Replit 的排程自動化）把結果貼進聊天，觀看者也看得到那些結果；但看得到結果，不代表取得管理那項 Routine 的權限。
邊界條件有兩條：接收者必須有 Replit 帳號，而且必須屬於建立該聊天的原始工作區；把連結轉給工作區外的人，不會邀請對方加入，也不會自動賦予閱讀權限。複製連結這個動作本身，不會建立任何額外權限。
官方文件裡寫得最直白的一段，是針對開發網址的警告：開發網址打開的是正在運作的開發伺服器，不是隔離的唯讀預覽。視伺服器功能而定，它可能提供程式碼、秘密、已連接服務的存取，甚至是能改動資料的操作。分享面板上寫著 Can view，不代表連結背後的每個動作都被限制成觀看。伺服器內容與可用性會隨著開發持續變動，官方還補了一句：分享開發網址不能取代正式發布應用程式。
分享對象的控制是兩層的：工作區整體存取（Everyone in workspace 可設成 Can view 或 No access），加上個別成員或群組的指定。只想分享給特定同事時，官方建議把工作區整體維持 No access，再逐一加入指定對象並給予 Can view，確認清單無誤後按 Save。
單獨分享素材之前，先把存取路徑數清楚
素材可以單獨分享：一份報告、一張圖片，不必連整段對話一起開放。觀看者會看到這份素材的後續更新，拿到的內容會跟著源頭走。只想交付成果時，這通常比分享整段聊天更接近目的。
撤回的時候才是考驗。如果某人的存取是從聊天繼承來的，面板上會標示 Shared via conversation，此時取消素材本身的直接分享，移除不了那條繼承路徑，必須回到聊天的權限設定去處理。No access 也不是對某個人的全面封鎖：刪掉某人的個別授權，他透過群組或工作區整體取得的存取仍然有效。而收回存取之後，對方已經下載或自行保存的副本，不會跟著消失。
所以撤權時要把三條路徑逐條檢查：素材的直接分享、從聊天繼承的存取、群組與工作區層級的授權。只看一個開關，通常會漏掉另外兩條。
目錄裡的技能有審查，GitHub 匯入的沒有
技能的來源大致有三種：Replit 目錄的內建與夥伴技能、自行建立、從公開 GitHub 儲存庫匯入。官方對安全態度的表述很明白：目錄裡的技能經過安全審查，外部來源匯入的沒有；技能就是 Agent 會遵循的指示，外部技能安裝前務必先人工審過內容。
GitHub 匯入另有幾個硬限制：預覽只檢查檔案結構，不會載入技能的指示與描述；單次匯入上限是 50 個技能、3,500 個檔案或 200 MiB；私有儲存庫不支援。入口之間的性質差別也順手弄清楚：從聊天的 Use a skill 選目錄技能，只對當則訊息生效，什麼都不會裝進專案；從專案編輯器的 Skills 面板安裝，才會放進 /.agents/skills 並跨對話保留；命令列也可以用 npx skills 指令安裝。
名詞邊界也在這裡釐清：技能是一份「怎麼做事」的指示；要連接外部工具或服務，那是整合（Integrations）與 MCP 的職責，兩者不該混為一談。跨開發環境同步代理工具設定的做法，最近在別的團隊也看得到，例如Adyen 開源的 Agent Marketplace 就用設定檔加鎖定檔，讓同一套 AI 工具設定同步到八種開發環境。
同一份週報裡的其他更新，與還沒寫清楚的三件事
10 月 23 日這份週報還列了三項更新。Monitoring Agent 這項上週率先發布的自動值班功能也收錄在這份週報裡，讓 Agent 用應用程式的日誌與指標調查生產環境問題、嘗試並驗證修復，TechMoon 先前已完整拆解過它的三段權限階梯與自動修復、自動重新發布兩個開關的差別。Stripe Atlas 的公司設立服務透過 Replit 辦理有八折。額度用盡的保護措施則讓符合資格的儲值客戶，在零額度時、在超支上限內保住已發布的應用程式：付費 Agent 暫停、免費模式仍可用、停權前會先收到警告信，新儲值的額度會先償還超支。
回到技能這件事，官方還沒寫清楚的部分有三處，導入前建議在工作區裡實際確認：
- 同意流程的介面位置與細節：目前只有週報一句話，技能說明文件還沒跟上。
- 代理建議功能是否隨方案層級開放：文件只寫了技能管理的方案限制，沒有單獨說明這道新流程。
- 目錄技能的安全審查標準：官方只說有審查，沒有列出審查項目。
給考慮導入的團隊一句收斂的判斷：這套更新的價值在把關位置，讓代理提議、讓人決定入庫、讓政策決定誰看得到；而它最誠實的部分，是官方自己把三個「不保證」寫進了文件。會先讀懂這三個不保證的團隊，才真正適合把團隊的工作方法交給這套系統管理。
