如果你同時用Claude Code、Codex和Cursor寫代碼，有個數(shù)字會讓你血壓飆升：同一個零停機部署的Rails遷移技巧，平均要重復(fù)教4.7次。

這不是估算。OpenSite AI團隊統(tǒng)計了內(nèi)部開發(fā)者的實際交互日志——每切換一次AI工具，上下文就清零一次。你剛調(diào)好的pgvector HNSW索引參數(shù)，換個窗口就得從頭解釋。

多智能體技能漂移（multi-agent skill sprawl）是個被低估的慢性病。單個工具越聰明，跨工具遷移的沉沒成本就越高。Codex的auto-deepening功能會自動分析你的工作歷史并優(yōu)化技能，但如果優(yōu)化結(jié)果鎖死在~/.codex/skills/目錄里，對其他工具就是透明的。

OpenSite今天開源的opensite-skills，本質(zhì)上是個Git倉庫+自動化同步層。他們用了一套" embarrassingly simple"的本地方案，和一套相當(dāng)臟的云端hack。

本地：符號鏈接（symlink）的一擊必殺

./setup.sh腳本跑一遍，檢測你裝了哪些智能體——Claude Code（~/.claude）、Codex（~/.codex）、Cursor（~/.cursor）、GitHub Copilot——然后在各平臺的技能目錄和中央倉庫之間建符號鏈接。

沒有文件拷貝，沒有配置維護。改一處，全局實時生效。Codex深化技能后寫回~/.codex/skills/，實際落筆就是這個Git倉庫。提交、推送，改進就流向所有工具。

這套設(shè)計的狡猾之處在于：它把Git變成了技能的狀態(tài)管理器。版本回滾、分支實驗、團隊協(xié)作，全部復(fù)用現(xiàn)有基礎(chǔ)設(shè)施。

云端：繞過Cloudflare的臟活

真正的麻煩是Claude Desktop和Perplexity Computer。兩者都通過云UI管理技能，沒有REST API，且UI被Cloudflare保護——標(biāo)準(zhǔn)無頭自動化在第一請求就被攔截。

OpenSite的解法是用Playwright驅(qū)動的瀏覽器自動化，配合undetected-chromedriver和 residential proxy輪換。不是優(yōu)雅方案，但能把技能文件推送到這些平臺的云端存儲。

GitHub Actions工作流每小時檢查一次倉庫變更，自動同步到所有已配置的云端平臺。本地提交→云端生效的延遲控制在分鐘級。

技能文件格式上，他們做了務(wù)實的妥協(xié)。Claude Code用CLAUDE.md，Codex用codex.md，Cursor用.cursor/rules——opensite-skills同時維護這三種變體，通過模板引擎從單一源生成。不是追求大一統(tǒng)，而是承認生態(tài)分裂的現(xiàn)實。

項目還內(nèi)置了技能驗證層：YAML frontmatter定義觸發(fā)條件（文件擴展名、路徑模式、git狀態(tài)），本地測試框架模擬各智能體的解析行為，防止同步上去的技能在目標(biāo)平臺報錯。

開源協(xié)議是MIT。OpenSite的算盤很清楚：工具鏈碎片化是所有人的痛點，但基礎(chǔ)設(shè)施層需要事實標(biāo)準(zhǔn)。他們賭的是——誰先成為那個"默認的中央倉庫"，誰就能定義下一代智能體技能的交互范式。

GitHub倉庫地址：github.com/opensite-ai/opensite-skills。安裝說明就三行命令，但文檔里埋了個有趣的細節(jié)——他們建議把私有技能放在單獨子模塊，避免敏感模式意外進公開倉庫。

這套方案最狠的假設(shè)是：開發(fā)者會同時用多個AI工具，且這個局面短期內(nèi)不會收斂。如果某家智能體廠商明天開放原生API同步，OpenSite的云端hack會立刻顯得笨拙。但在那之前，這可能是跨平臺技能管理最務(wù)實的補丁。

最后留個數(shù)字：OpenSite團隊內(nèi)部運行這套系統(tǒng)87天后，Codex的auto-deepening產(chǎn)出的技能改進，有94%被成功同步到了Claude Code的上下文里——而在之前，這個數(shù)字是0。