團隊控制與排障

Windsurf 進入團隊後，問題不再是“會不會提問”，而是組織治理：誰能用哪些模型，Cascade 能不能自動跑命令，MCP 能訪問哪些系統，對話能否共享，成員如何入職和離職，故障日誌怎麼收集。

官方 Guide for Admins 把目標讀者定義為 enterprise platform / developer-experience admins、Corporate IT 和 centralized tooling teams。它不是單純的使用者教程，而是部署和運營清單。

1. Admin Portal 是團隊控制面

官方 Guide for Admins 說明，Admin Portal 提供集中管理能力，包括 user/team management、credit usage、SSO（Single Sign-On 單點登入，員工用公司 Google/Okta/Azure AD 賬號登入 Windsurf）、feature toggles、analytics、service keys 和 role/permission controls。

團隊上線前先定這 7 件事：

flowchart TD
    Admin["Admin Portal"] --> Identity["SSO / SCIM / RBAC"]
    Admin --> Models["Models Configuration"]
    Admin --> Terminal["Terminal Commands"]
    Admin --> MCP["MCP Servers"]
    Admin --> Share["Conversation Sharing"]
    Admin --> Analytics["Analytics / API"]
    Identity --> Onboard["入職 / 離職 / 分組"]
    Terminal --> Guard["命令執行邊界"]
    MCP --> Data["外部系統資料邊界"]
    Analytics --> Cost["用量和費用負責人"]

    style Admin fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Guard fill:#fee2e2,stroke:#dc2626,stroke-width:2px

2. Day 0 上線清單

官方 quick-start checklist 包含確認組織設定、設定 SSO、啟用 SCIM 並把 IdP groups 對映到 Windsurf teams、定義 role/permission model、配置 Admin Portal、分發 client/extensions、檢視 analytics 和 API access tokens。

落到研發團隊，可以拆成這張清單：

3. 身份和成員生命週期

官方建議儘可能使用 SSO + SCIM，實現自動 provisioning、de-provisioning 和 group management。SSO 支援 Okta、Azure AD、Google，以及 generic SAML；SCIM 可以自動建立/停用使用者、建立 teams，使用者也可以屬於多個 teams。

關鍵邊界：

• 不要用 All Employees 這類大組直接放開開發許可權。
• 用 role-based group assignments，把不同專案或職能對映到 Windsurf teams。
• SCIM 應儘量保持 source of truth，避免混合手工/API 改造成 drift。
• 組命名要提前規劃，因為 Windsurf team 是 flat collection，沒有 nested teams 可兜底。
• Windsurf 只支援 SP-initiated SSO；不要按 IdP-initiated SSO 設計入口。
• Microsoft Entra 配置裡 IdP Entity ID 可能需要保留 trailing slash，測試登入前不要關閉設定頁。

RBAC 只在 Enterprise 可用。官方 RBAC 頁面列出預設 Admin Role 和 User Role，也提供 Analytics、Teams、Indexing、SSO、Service Key、Billing、Role Management、Team Settings 等許可權分類。團隊不要把“能看 analytics”和“能改 billing / role / service key”放在同一個預設角色裡。

4. 命令、MCP 和共享的安全邊界

官方 Admin Guide 對幾個高風險能力都提供了管理員控制。

5. 常見排障路徑

官方 Common Issues 覆蓋 rate limiting、Python 擴充套件、diagnostic logs、macOS 安全彈出視窗、Windows 更新、Remote SSH、網路白名單、Linux launch、Cascade panel blank、Terminal stuck、WSL Docker container 等問題。

6. 網路、代理和證書排障

企業網路裡，Windsurf 問題經常不是 IDE 本身，而是 proxy、SSL inspection、VPN 或 zero-trust 軟體。

官方 proxy 頁面給出的判斷順序：

1. 先問 IT 是否使用 HTTP/HTTPS proxy。
2. 如果系統已有代理或 PAC，優先嚐試 Windsurf Settings 裡的 Detect proxy。
3. 如果 IT 給了固定 proxy URL 和憑據，就在 Windsurf Settings 手動配置。
4. SSH remote / dev container 有獨立的 remote proxy 設定，不等同於本地 editor proxy。
5. 改完 proxy 後重啟 Windsurf 或重連 remote session。

官方 SSL inspection 頁面建議從 Developer Tools Console 收集真實錯誤。常見模式包括：

• certificate signed by unknown authority
• unable to verify the first certificate
• self signed certificate in certificate chain
• unable to get local issuer certificate
• handshake_failure
• ERR_SSL_PROTOCOL_ERROR

給 IT 的資訊要包含失敗時間、OS、是否安裝 Zscaler 等客戶端、expanded console error、熱點網路是否正常、是否只在公司網路失敗。優先修企業 CA trust chain；無法對齊時，再申請 scoped SSL inspection bypass。

7. WSL 和 Linux 專項問題

官方 WSL Known Issues 頁面把慢、斷連和安裝失敗分成兩類。

inotify 常用診斷：

cat /proc/sys/fs/inotify/max_user_watches
cat /proc/sys/fs/inotify/max_user_instances
find /proc/*/fd -lname anon_inode:inotify 2>/dev/null | wc -l

官方建議的大儲存庫修復值：

sudo sysctl fs.inotify.max_user_watches=524288
sudo sysctl fs.inotify.max_user_instances=1024

永久修改再寫入 /etc/sysctl.conf 並執行 sudo sysctl -p。這類操作會影響系統級資源限制，團隊機器應由 IT/infra 統一處理。

8. 日誌採集順序

官方 Gathering Windsurf Logs 頁面提供兩條路徑：

1. Command Palette：Download Windsurf Logs → Download Windsurf Logs File。
2. Cascade panel 右上角三點選單：Download Diagnostics。

提交 support 或內部工單前，至少附上：

• Windsurf 版本、OS、安裝方式。
• 復現步驟和時間點。
• 是否公司網路、VPN、proxy、SSL inspection、WSL、SSH remote、dev container。
• 相關日誌檔案。
• 如果是網路/TLS 問題，附 Developer Tools Console 的 expanded error。
• 如果是終端 stuck，附最小 shell 配置和 default terminal profile。

9. 組織級上線標準

商業團隊至少要做到：

1. 有專案級 AGENTS.md，寫明命令、測試、部署和敏感資訊邊界。
2. 有 .codeiumignore，排除金鑰、生成物、大型快取和私密資料。
3. 有團隊命令 allow/deny 策略，生產儲存庫停用 Turbo。
4. 有 MCP server 准入名單、owner、認證方式和撤權路徑。
5. 有 conversation sharing 脫敏規範。
6. 有模型和用量負責人。
7. 有 diagnostic logs、support 和 status page 的排障路徑。
8. 有新成員 onboarding 和離職 de-provisioning 流程。
9. 有 proxy、SSL inspection、WSL、Linux inotify 的企業環境排障 SOP。

這些不是形式主義。Windsurf 會讀程式碼、執行命令、呼叫工具、儲存上下文；它已經屬於工程治理系統。

本章自檢

完成本章後，用這 4 個問題檢查：

1. 團隊是否用 SSO + SCIM 管理使用者生命週期？
2. 管理員是否限制了模型、命令和 MCP？
3. 專案是否有 AGENTS.md 和 .codeiumignore？
4. 常見網路、終端、日誌、訂閱、WSL 問題是否有排障入口？

透過標準：你能把 Windsurf 從個人工具上線成團隊可治理的開發系統。

官方來源

• Guide for Admins —— 官方企業管理員指南，覆蓋 SSO、SCIM、RBAC、Admin Portal、feature toggles、analytics、API 和 end-user onboarding。
• Role Based Access & Management —— 官方 RBAC 頁面，覆蓋角色、許可權分類、service key、billing、role management 和 user groups。
• Setting up SSO & SCIM —— 官方 SSO / SCIM 頁面，覆蓋 Google、Microsoft Entra、Okta、generic SAML 和 SP-initiated SSO 邊界。
• Terminal —— 官方終端文件，說明團隊級 command lists、auto-execution 上限和 deny 優先。
• Model Context Protocol (MCP) —— 官方 MCP 文件，說明 registry、whitelist 和 server matching。
• Common Windsurf Issues —— 官方排障頁，覆蓋訂閱、rate limit、diagnostics、系統許可權、網路白名單、Linux、Terminal 和 WSL。
• Gathering Windsurf Logs —— 官方日誌採集頁面。
• Proxy Configuration —— 官方代理配置頁面。
• TLS / SSL Inspection Issues —— 官方 SSL inspection 排障頁面。
• WSL Known Issues —— 官方 WSL 9P、VPN、zero-trust 排障頁面。
• Language Server inotify limits —— 官方 Linux inotify 限制排障頁面。

接下來去哪