# Vibe Coding 團隊協作技巧

> 和其他人一起用 Vibe Coding 做專案



你好，我是魚皮。

在實際工作中，很多專案是團隊協作完成的。

你可能會想：用 AI 開發還需要團隊協作嗎？每個人自己用 AI 不就行了？

其實不然。團隊協作中有很多問題需要解決，比如不同人用 AI 生成的程式碼不一致（A 用 React，B 用 Vue）、A 改了程式碼 B 不知道、大家都在改同一個檔案導致衝突等等……

在 Vibe Coding 團隊協作中，除了傳統的團隊協作方法，還可以利用 AI 開發工具的特性來提升效率。本文我就來分享一些團隊使用 Vibe Coding 的最佳實踐。




## 一、程式碼規範和風格

團隊協作的第一步是統一程式碼規範。



### 為什麼需要統一規範？

如果每個人用 AI 生成的程式碼風格都不一樣，專案會變得很混亂。比如 A 用 React Class 元件，B 用函式元件；A 用 CSS Modules，B 用 Tailwind；A 的變數名是 camelCase，B 的是 snake_case……

這樣的程式碼很難維護，也很難協作。所以，團隊需要統一的程式碼規範。




### 建立程式碼規範文件

可以建立一個 `CODE_STYLE.md` 文件，明確規定下面的內容。

1）技術棧規範：

- 前端框架：React 19 + TypeScript
- 狀態管理：Zustand
- 樣式方案：Tailwind CSS
- 路由方案：React Router v6

2）程式碼風格規範：

- 元件：函式式元件 + Hooks
- 命名：元件用 PascalCase，函式用 camelCase，常數用 UPPER_SNAKE_CASE
- 檔案組織：一個元件一個檔案，檔案名和元件名一致
- 導入順序：React → 第三方函式庫 → 專案內部模組

3）註解規範：

- 複雜邏輯必須加註解
- 註解要說明 "為什麼" 而不只是 "是什麼"
- 使用 JSDoc 格式為函式添加文件

建議把這個文件放在專案根目錄，讓所有人都能看到。



### 使用 Linter 和 Formatter

光有文件還不夠，很多人明明有文件就是不看，需要用工具來強制執行。

![](https://pic.yupi.icu/1/image-20260105172241747.png)

ESLint 是程式碼檢查工具，能自動發現程式碼中的問題和不規範的地方。

Prettier 是程式碼格式化工具，能自動統一程式碼格式，比如縮進、換行、引號等。

雙劍合璧，專治爛程式碼！

如果你不理解這些工具，沒關係，可以直接讓 AI 幫你安裝和配置：

```markdown
請幫我配置 ESLint 和 Prettier，確保團隊程式碼風格一致。
```

AI 會幫你在專案根目錄建立 `.eslintrc.json` 程式碼檢查配置文件：

```json
{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "rules": {
    "react/react-in-jsx-scope": "off",
    "@typescript-eslint/no-explicit-any": "error",
    "no-console": "warn"
  }
}
```

建立 `.prettierrc` 程式碼格式化配置文件：

```json
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100
}
```

並且在 `package.json` 中添加腳本：

```json
{
  "scripts": {
    "lint": "eslint . --ext .ts,.tsx",
    "lint:fix": "eslint . --ext .ts,.tsx --fix",
    "format": "prettier --write \"src/**/*.{ts,tsx}\""
  }
}
```

這樣，大家提交程式碼前執行 `npm run lint:fix && npm run format`，程式碼就會自動符合規範。




### 統一 AI 配置

如果團隊都用 Cursor，可以在專案中添加 `.cursorrules` 檔案，統一 AI 的行為：

```
專案：【專案名稱】

技術棧：
- React 18 + TypeScript
- Tailwind CSS
- Zustand

程式碼規範：
- 使用函式式元件
- 所有元件必須有 TypeScript 類型定義
- 樣式只用 Tailwind CSS
- 不使用 any 類型

請所有團隊成員都遵循這些規範。
```

這樣，不同人用 AI 生成的程式碼風格會更一致。

如果團隊使用 Claude 或其他 AI 工具，也可以透過類似的方式統一規範。比如在每次對話開始時，先讓 AI 讀取專案的規範文件，或者在系統提示詞中加入團隊的程式碼規範。不同工具的具體做法可能不同，建議查看 AI 工具的官方文件。



## 二、AI 編程工具的團隊協作功能

現代 AI 編程工具提供了專門的團隊協作功能，能大大提升團隊效率。



### Cursor 團隊版

Cursor 提供了專門的 [團隊版](https://cursor.com/cn/docs/account/teams)，包含下面這些功能：

1）團隊管理和權限控制

可以建立團隊，邀請成員，設定不同的角色和權限。管理員可以控制誰能存取哪些功能，查看團隊的使用情況和帳單。

2）共享配置文件

透過共享規則檔案，團隊可以統一 AI 的行為規範。所有成員使用的 AI 都會遵循相同的程式碼規範、技術棧要求和輸出格式，確保生成的程式碼風格一致。

3）使用分析和監控

團隊管理員可以查看團隊的 AI 使用情況，包括哪些成員使用最多、使用了哪些模型、花費了多少成本等。這能幫助優化團隊的 AI 使用策略。

![](https://pic.yupi.icu/1/cursor-dashboard.jpeg)



### Claude 共享能力

Claude 提供了 [Projects 功能](https://www.anthropic.com/news/projects)，特別適合團隊協作：

1）專案級別的知識庫

可以為每個專案建立獨立的知識庫，上傳專案相關的文件、程式碼、規範等。團隊成員在這個專案中使用 Claude 時，AI 會自動參考這些知識，保持上下文一致。

![](https://pic.yupi.icu/1/claudeprojectknowledge.png)

2）自訂指令

可以為每個專案設定自訂指令，比如 “使用正式的語氣”、“從資料分析師的角度回答” 等。團隊成員使用時，AI 會自動遵循這些指令。

3）對話分享

Claude Team 使用者可以將優秀的對話分享到團隊的活動流中。其他成員可以看到別人是如何使用 AI 的，學習不同的提問技巧和解決方案，提升整個團隊的 AI 使用水平。

![](https://pic.yupi.icu/1/claudeshare.jpeg)

4）團隊共享 `CLAUDE.md` 檔案

即使不使用 Projects 功能，也可以把 `CLAUDE.md` 檔案用 Git 來管理，實現團隊成員的共同分享和維護。

每當發現 Claude 做錯了什麼，就將它添加到 `CLAUDE.md` 中，這樣 Claude 下次就知道不要這樣做了。這個檔案會逐漸沉澱團隊的開發經驗和規範，成為團隊的共享知識庫。




## 三、文件驅動開發

好的文件是團隊協作的基礎。




### 專案文件的重要性

在團隊中，文件比個人開發時更重要。因為你寫的程式碼不只是給自己看的，還要給其他人看。好的文件能讓團隊成員快速了解專案，減少溝通成本。

必備的文件包括：

- README.md：專案概述和使用說明
- CONTRIBUTING.md：如何參與開發
- CODE_STYLE.md：程式碼規範
- API.md：API 接口文件
- CHANGELOG.md：版本更新記錄



### README.md 的內容

README.md 是專案的門面，就像一本書的封面和目錄。它是新成員加入專案時第一個看的檔案，也是其他開發者了解你專案的窗口。一個好的 README 能讓人快速理解專案、快速上手開發。

一個好的 README.md 應該包含：

- 專案簡介：這個專案是做什麼的，解決什麼問題
- 快速開始：如何安裝依賴、配置環境、執行專案
- 技術棧：用了哪些技術、為什麼選擇這些技術
- 目錄結構：主要資料夾的作用
- 開發規範：程式碼風格、提交規範等
- 常見問題：新人容易遇到的問題和解決方案




### API 文件

如果專案有後端 API，要寫清楚每個接口的用法。可以用 Swagger、Postman 等工具或者 AI 來生成 API 文件，也可以手寫 Markdown 文件。

每個接口要說明：

- 請求方法和路徑
- 請求參數（類型、是否必填、說明）
- 響應格式
- 錯誤碼說明
- 使用示例




### 讓 AI 幫你寫文件

寫文件很枯燥，但 AI 可以幫你。

如果你使用 Cursor、Claude Code 等 AI 編程工具，工具會自動讀取專案結構作為上下文，你甚至不用自己貼程式碼，直接說：

```markdown
請為這個專案生成 API 文件
```

AI 就能根據程式碼自動生成。

如果使用其他 AI 工具，可以手動貼程式碼：

```markdown
請為這個 API 接口生成文件：
【貼上你的程式碼】

文件應該包括：接口說明、請求參數、響應格式、使用示例
```

AI 會生成一份基礎的文件，你再根據實際情況調整。




## 四、Git 協作流程

Git 是一個版本控制系統，也是團隊協作的核心工具。就像給程式碼拍照存檔，可以隨時回到之前的任何版本。它能記錄誰在什麼時候改了什麼程式碼，團隊成員可以同時開發不同功能，最後再合併到一起。

💡 如果你想系統學習並掌握 Git，可以閱讀 [魚皮的 Git & GitHub 學習路線](https://www.codefather.cn/course/1789189862986850306/section/1789190804671012866)。



### 分支管理策略

分支就像是程式碼的平行世界。你可以在自己的分支裡隨便改程式碼，不會影響別人。改好了再合併到主分支，就像把你的工作成果搬到正式版本裡。

團隊開發要利用好分支功能，常見的分支策略是：

- main 分支：穩定的生產程式碼，只接受經過測試的程式碼
- develop 分支：開發分支，日常開發在這裡進行
- feature 分支：每個新功能開一個分支，比如 `feature/user-login`、`feature/post-editor`
- bugfix 分支：修復 bug 時開的分支，比如 `bugfix/login-error`

工作流程是：

1. 從 develop 分支建立 feature 分支
2. 在 feature 分支上開發，開發完成後提交 Pull Request
3. 經過審查後合併到 develop
4. 定期將 develop 合併到 main

![](https://pic.yupi.icu/1/gitcooperate%E5%A4%A7.jpeg)




### 提交規範

統一的提交資訊能讓團隊更容易追蹤變更。建議使用 [Conventional Commits 規範](https://www.conventionalcommits.org/zh-hans/v1.0.0/)，這是一種標準化的提交資訊格式，讓每次提交的目的一目了然。

比如：

```
feat: 添加用戶登錄功能
fix: 修復導航欄在移動端的顯示問題
docs: 更新 API 文件
style: 格式化程式碼
refactor: 重構用戶服務
test: 添加登錄功能的測試
chore: 更新依賴包
```

類型 + 冒號 + 空格 + 簡短描述，大家一看就知道這次提交做了什麼。

現在很多 AI 編程工具都支援生成提交資訊，更容易遵循規範。

![](https://pic.yupi.icu/1/image-20260105172920015.png)



### Pull Request 流程

Pull Request（簡稱 PR）是一種程式碼合併請求。當你在自己的分支上完成開發後，不要直接合併到主分支，而是建立一個 PR，讓其他人審查你的程式碼。審查通過後，才能合併。這就像提交作業讓老師批改，批改通過了才算完成。

具體流程是這樣的：

- 建立 PR：在 GitHub 上建立 PR，寫清楚這次改動做了什麼，為什麼要這樣改。
- 程式碼審查：至少一個其他成員審查程式碼，檢查功能、程式碼質量、是否符合規範。
- 討論和修改：如果有問題，在 PR 中討論，提交者根據反饋修改。
- 合併程式碼：審查通過後，合併到目標分支。

這個流程雖然多了一步，但能大大提高程式碼質量。

![](https://pic.yupi.icu/1/image-20260105173137083.png)



### 解決衝突

多人協作時，程式碼衝突是常見問題。當兩個人修改了同一個檔案的同一部分，Git 會提示衝突。

解決衝突的步驟是：首先拉取最新程式碼 `git pull origin develop`，Git 會標記出衝突的地方。然後手動編輯檔案，決定保留哪部分程式碼。解決完衝突後，要測試確保功能正常，最後提交解決後的程式碼。

為了減少衝突，建議：

1. 經常拉取最新程式碼，不要長時間不同步
2. 功能開發完就及時合併，不要拖太久
3. 如果要修改公共檔案，提前和團隊溝通




## 五、程式碼審查流程

程式碼審查（Code Review）是保證團隊程式碼質量的關鍵。




### 為什麼要做程式碼審查？

程式碼審查有很多好處。

首先，能在程式碼上線前就發現潛在的 Bug，避免問題流入生產環境。其次，能統一程式碼風格，讓專案程式碼保持一致，不會出現每個人寫的程式碼風格都不一樣的情況。

更重要的是，程式碼審查是一個很好的學習機會。審查者能看到別人的程式碼思路，被審查者能得到改進建議，雙方都能學到東西。而且，知道程式碼會被審查，寫的時候自然就會更認真，這能從源頭提高程式碼質量。




### 審查的重點

審查程式碼時，重點關注這些方面：

1. 功能正確性：程式碼是否正確實現了需求？有沒有遺漏的邊界情況？
2. 程式碼質量：程式碼是否清晰易懂？有沒有重複程式碼？命名是否規範？
3. 性能問題：有沒有明顯的性能問題？資料結構選擇是否合理？
4. 安全問題：有沒有安全漏洞？用戶輸入是否驗證？
5. 測試覆蓋：是否有足夠的測試？測試是否覆蓋了主要場景？



### 審查的技巧

審查時要注意方法。不要只說 “這裡不對”，要說清楚為什麼不對、應該怎麼改。要用建議的語氣，而不是命令的語氣。比如 “我建議這裡用 useMemo 優化性能” 而不是 “這裡必須用 useMemo”。當然，團隊如果有硬性要求除外。

如果有多個問題，分清主次。先指出重要的問題（比如 bug、安全漏洞），再提改進建議（比如命名、註解）。

審查不是一次性的，可以多輪討論。第一輪指出主要問題，修改後再審查，確認沒問題再合併。




### 讓 AI 輔助審查

可以讓 AI 幫你做初步審查：

```markdown
請審查這段程式碼，從功能、性能、安全、程式碼質量等角度分析：
【貼上程式碼】
```

AI 會給你一份詳細的審查報告。但要注意，AI 的審查不能完全替代人工審查，最終還是要人來把關。



#### 使用 Cursor 的 BugBot

Cursor 提供了一個專門的程式碼審查工具叫 [BugBot](https://cursor.com/cn/bugbot)，它能自動掃描你的程式碼，找出潛在的 Bug、性能問題和安全漏洞，並且快速修復。

你可以在 Cursor 中直接使用這個功能，讓 AI 幫你做初步的程式碼審查。

![](https://pic.yupi.icu/1/image-20260105173323498.png)



#### Claude Code 自動化程式碼審查

如果使用 Claude Code，可以在程式碼審查的 Pull Request 中標記 `@.claude`，這樣 Claude 會自動把審查建議添加到 `CLAUDE.md` 檔案中。再利用 GitHub Action 實現自動化更新，這樣文件會逐漸沉澱團隊的程式碼質量標準和常見問題。

這也是 Claude Code 創始人推薦的做法，讓程式碼審查的經驗自動累積下來。



#### 多個 AI 交叉驗證

為了更保險，可以讓多個不同的 AI 審查同一段程式碼。比如先讓 Claude 審查一遍，再讓 GPT 審查一遍，對比它們的建議。

不同的 AI 可能會發現不同的問題，交叉驗證能提高審查的全面性。






## 六、團隊協作最佳實踐

基於我的經驗，這裡總結一些團隊協作的最佳實踐。

💡 這部分主要是給團隊負責人或管理者看的。如果你不是團隊管理者，只是團隊成員，這部分可以直接跳過，或者了解一下就好。




### 定期同步

團隊要定期開會同步進度，比如每天的站會（5 ~ 10 分鐘），每週的週會（30 ~ 60 分鐘）。

站會主要說三件事：昨天做了什麼、今天計劃做什麼、遇到了什麼問題。

週會可以深入討論技術方案、分享經驗、規劃下週工作。

除了會議，還可以用工具同步。比如用 Jira 等工具管理任務，用企微、飛書、Slack 等工具日常溝通，用 Notion、語雀等工具共享文件。



### 結對編程

對於複雜的功能，可以嘗試結對編程。兩個人一起開發，一個人寫程式碼（Driver），一個人審查和提建議（Navigator），這樣不僅能提高程式碼質量，也能促進知識分享。

說實話，我很少見到有公司真的這麼做，因為成本太高了。

不過仔細想想，在 Vibe Coding 中，和 AI 一起開發，不就是一種結對編程嗎？

AI 是你的編程搭