團隊協作：多人共用的 prompt 庫怎麼設計和維護？

作者：從零開始學AI

日期：2026年6月23日上午9:57

來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點高亮

團隊 prompt 庫點設計先唔會變災難？從零搭建協作體系，避免重複、確保質素、方便維護。

整理版摘要

呢篇文章出自劉洋——一個技術負責人，佢團隊有 8 個工程師成日寫 AI prompt，但就出現咗好多問題：同一個功能嘅 prompt 重複出現、質量參差、冇人知邊個改咗版本。成個情況就好似冇統一管理嘅代碼庫咁混亂。

作者嘅結論係：團隊需要一個正式嘅 prompt 庫，當做核心資產咁管理。佢提出咗設計原則（按功能分類、標準化格式、版本控制、評審流程）、組織結構（可以 Git 倉庫或者數據庫加管理界面），同埋實戰最佳實踐（參數化、組合、測試）。最後仲畀咗協作規範同常見錯誤，話俾你知點樣避免「一個人改咗其他人唔知」嘅窘境。

團隊 prompt 混亂嘅根源係冇統一管理，解決方法係建立 prompt 庫，當做程式碼咁管。
設計原則包括按功能分類、標準化格式（加元信息）、版本控制同評審流程。
實戰技巧：將 prompt 參數化、組合細片段、寫測試用例嚟驗證效果。
Git 倉庫結構適合小團隊，數據庫加管理界面適合大規模協作。
核心要點：命名規範、提交規範、評審清單，避免常見錯誤如冇測試、冇版本記錄。

值得記低

Prompt

標準化 prompt 模板

包含 ID、作者、創建時間、適用模型、輸入輸出格式、使用場景、prompt 內容、使用示例、注意事項。

流程

團隊 prompt 協作規範

命名規範: {category}/{function}/{version}.md；提交規範: prompt(category): 簡短描述；評審清單檢查元信息、示例、測試、重複、版本號。

筆記

參數化 prompt 範例

code_review_prompt = "審查以下 {language} 代碼的 {review_type}..."

筆記

prompt 組合範例

ROLE_PROMPT + SECURITY_RULES + STYLE_RULES 等片段組合。

整理重點

真實問題：團隊 prompt 點解會亂？

劉洋係技術負責人，團隊有 8 個工程師，個個都喺度寫 AI prompt。佢發現咗幾個典型問題：張三寫咗個「代碼審查」prompt 放喺自己 codebase，李四又寫咗個類似嘅，但質量唔同；王五需要「文檔生成」prompt，但唔知有人寫過；趙六改咗 prompt 但冇通知其他人，搞到其他人仲用緊舊版。

冇統一管理嘅 prompt 庫，就好似冇統一管理嘅代碼庫——重複、混亂、不可維護

呢個情況唔單止浪費時間，仲會令 prompt 質素參差，難以沉澱團隊知識。

整理重點

設計原則：點樣建立一個好嘅 prompt 庫？

作者提出四個核心原則，幫你由零開始規劃。

1 按功能分類：例如 code-review、documentation、content、analysis，每個分類底下再細分。
2 標準化格式：每個 prompt 文件都要有元信息，包括 ID、作者、版本、適用模型、輸入輸出格式、使用場景、注意事項。
3 版本控制：同代碼一樣，每個 prompt 都要保留歷史版本，目錄結構似 code-review/security/v1.0.0.md。
4 評審流程：新 prompt 或修改要提交 PR，經同事 review，測試通過先合併，仲要更新版本號。

整理重點

組織結構：Git 倉庫定數據庫？

作者推薦兩種方案。方案一係 Git 倉庫，啱細團隊；方案二係數據庫加管理界面，適合大規模協作。

Git 倉庫方案：prompt-library/ 入面有 prompts/、tests/、scripts/、.github/workflows/

程式內容 text

prompt-library/
├── README.md
├── prompts/
│   ├── code-review/
│   ├── documentation/
│   └── content/
├── tests/
│   ├── code-review/
│   └── documentation/
├── scripts/
│   ├── validate.py
│   └── evaluate.py
└── .github/
    └── workflows/
        └── prompt-test.yml

數據庫方案就用 SQL table 儲存，配合管理界面支援搜索、預覽、編輯、版本對比。

數據庫方案嘅好處係可以快速搜尋同對比版本，但需要額外開發

整理重點

實戰：點樣做到 prompt 複用？

作者分享三個實戰技巧，令 prompt 更易重用同維護。

參數化 prompt：將可變部分抽成參數，例如 language、review_type，避免硬編碼。
Prompt 組合：將角色設定、規則、輸出格式等片段分開，然後用函數組合返，提高靈活性。
Prompt 測試：為每個 prompt 寫測試用例，用真實輸入驗證輸出是否達標，確保改動唔會破壞功能。

參數化係最基本嘅複用手段，例如 code_review_prompt = "審查以下 {language} 代碼的 {review_type}..."

程式內容 python

def get_security_review_prompt():
    return f"{ROLE_PROMPT}\n{SECURITY_RULES}\n{STYLE_RULES}"

寫測試用例可以防止「改了 prompt 但效果變差」嘅問題，尤其是多人協作時

整理重點

團隊協作規範：預防常見錯誤

最後，作者提出具體嘅規範同常見錯誤，等團隊可以順暢運作。

命名規範：{category}/{function}/{version}.md，例如 code-review/security/v1.0.0.md。
提交規範：prompt(category): 簡短描述，例如 prompt(code-review): 增加對 Go 語言的支持。
評審清單：檢查元信息、示例、測試、重複、版本號等。

Prompt 庫係團隊嘅核心資產，值得好似管理代碼咁認真對待

團隊協作：多人共用嘅 prompt 庫點樣設計同維護？

一個真實場景

劉洋係一個技術負責人，佢團隊有8個工程師，全部都喺度開發AI功能。

問題嚟咗：

張三寫咗一個「代碼審查」嘅 prompt，放咗喺佢自己嘅代碼入面
李四都寫咗一個「代碼審查」嘅 prompt，放咗喺另一個項目
兩個 prompt 做嘅嘢差唔多，但質量唔一樣
王五需要一個「文檔生成」嘅 prompt，但佢唔知張三同李四已經寫過類似嘅嘢
趙六改咗一個 prompt，但冇通知其他人，結果其他人仲用緊舊版本

冇統一管理嘅 prompt 庫，就好似冇統一管理嘅代碼庫——重複、混亂、唔可以維護。

點解需要 Prompt 庫？

Prompt 庫嘅價值：

避免重複：同一個功能唔使每個人寫一次
保證質量：經過驗證嘅 prompt 可以重用
統一風格：團隊嘅 prompt 風格一致
方便維護：改一個地方，所有使用者都受惠
知識沉澱：好嘅 prompt 技巧可以俾團隊學

Prompt 庫嘅設計原則

原則一：按功能分類

prompts/
├── code-review/
│   ├── security-review.md
│   ├── performance-review.md
│   └── style-review.md
├── documentation/
│   ├── api-doc.md
│   ├── readme.md
│   └── changelog.md
├── content/
│   ├── blog-post.md
│   ├── social-media.md
│   └── email.md
└── analysis/
    ├── data-analysis.md
    ├── competitor-analysis.md
    └── market-analysis.md

原則二：標準化格式

每個 prompt 檔案都應該包含元信息：

# 代碼安全審查 Prompt

## 元信息
- **ID**: code-review/security/v1.0.0
- **作者**: 張三
- **創建時間**: 2024-01-15
- **最後更新**: 2024-03-20
- **適用模型**: GPT-4, Claude 3 Opus
- **輸入格式**: 代碼文本
- **輸出格式**: JSON

## 使用場景
審查代碼中的安全漏洞

## Prompt 內容
你是一個安全審查專家...

## 使用示例
輸入：[代碼]
輸出：{"vulnerabilities": [...], "risk_level": "high/medium/low"}

## 注意事項
- 不適用於前端代碼
- 對 Python 和 Java 效果最好

原則三：版本控制

同代碼一樣，prompt 都需要版本控制。

code-review/security/
├── v1.0.0.md
├── v1.1.0.md
└── v2.0.0.md

原則四：評審流程

新嘅 prompt 或者 prompt 修改需要經過評審：

1. 提交 PR（包含 prompt 文件和測試結果）
2. 至少一個同事 review
3. 測試通過後合併
4. 更新版本號

Prompt 庫嘅組織結構

方案一：Git 倉庫

prompt-library/
├── README.md              # 使用說明
├── prompts/               # prompt 文件
│   ├── code-review/
│   ├── documentation/
│   └── content/
├── tests/                 # 測試用例
│   ├── code-review/
│   └── documentation/
├── scripts/               # 工具腳本
│   ├── validate.py        # 驗證 prompt 格式
│   └── evaluate.py        # 評估 prompt 效果
└── .github/
    └── workflows/
        └── prompt-test.yml  # CI：自動測試 prompt

方案二：數據庫 + 管理界面

CREATE TABLE prompt_library (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    category VARCHAR(50) NOT NULL,
    name VARCHAR(100) NOT NULL,
    version VARCHAR(20) NOT NULL,
    content TEXT NOT NULL,
    metadata JSON,
    created_by VARCHAR(50),
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    is_active BOOLEAN DEFAULT TRUE,
    UNIQUE KEY uk_category_name_version (category, name, version)
);

配合一個簡單嘅管理界面，支援搜索、預覽、編輯、版本對比。

實戰：Prompt 重用嘅最佳實踐

實踐一：參數化 Prompt

將 prompt 入面可以變嘅部分參數化：

# 不好的寫法：硬編碼
code_review_prompt = "審查以下 Python 代碼的安全漏洞..."

# 好的寫法：參數化
code_review_prompt = "審查以下 {language} 代碼的 {review_type}..."

def get_review_prompt(language, review_type):
    return code_review_prompt.format(language=language, review_type=review_type)

實踐二：Prompt 組合

將細嘅 prompt 片段組合成完整嘅 prompt：

# 基礎片段
ROLE_PROMPT = "你是一個代碼審查專家。"
STYLE_RULES = "用 JSON 格式輸出。"
SECURITY_RULES = "檢查 SQL 注入、XSS、CSRF 等安全漏洞。"
PERFORMANCE_RULES = "檢查時間複雜度、空間複雜度、緩存使用。"

# 組合
def get_security_review_prompt():
    return f"{ROLE_PROMPT}\n{SECURITY_RULES}\n{STYLE_RULES}"

def get_performance_review_prompt():
    return f"{ROLE_PROMPT}\n{PERFORMANCE_RULES}\n{STYLE_RULES}"

def get_full_review_prompt():
    return f"{ROLE_PROMPT}\n{SECURITY_RULES}\n{PERFORMANCE_RULES}\n{STYLE_RULES}"

實踐三：Prompt 測試

為每個 prompt 寫測試用例：

# tests/test_code_review.py
def test_security_review():
    prompt = get_security_review_prompt()
    test_code = """
    def get_user(user_id):
        query = f"SELECT * FROM users WHERE id = {user_id}"
        return db.execute(query)
    """
    result = call_ai(prompt, test_code)
    assert "SQL 注入" in result
    assert "參數化查詢" in result

def test_no_vulnerability():
    prompt = get_security_review_prompt()
    test_code = """
    def get_user(user_id):
        query = "SELECT * FROM users WHERE id = %s"
        return db.execute(query, (user_id,))
    """
    result = call_ai(prompt, test_code)
    assert "未發現安全漏洞" in result

團隊 Prompt 協作規範

命名規範

{category}/{function}/{version}.md

示例：
code-review/security/v1.0.0.md
documentation/api-doc/v2.1.0.md
content/blog-post/v1.0.0.md

提交規範

prompt(category): 簡短描述

示例：
prompt(code-review): 增加對 Go 語言的支持
prompt(documentation): 優化 API 文檔的輸出格式

評審清單

□ prompt 是否有清晰的元信息？
□ 是否有使用示例？
□ 是否有測試用例？
□ 測試是否通過？
□ 是否和現有 prompt 重複？
□ 版本號是否正確更新？

常見錯誤

錯誤一：冇統一管理

❌ 每個人把 prompt 放在自己的代碼裏，不共享

錯誤二：冇版本控制

❌ 直接在原文件上修改，不保留歷史版本

錯誤三：冇測試

❌ prompt 改了就上線，不驗證效果

錯誤四：冇評審

❌ 一個人改了 prompt，其他人不知道

核心要點

Prompt 庫 = 團隊嘅核心資產——避免重複、保證質量、方便維護
按功能分類：code-review、documentation、content、analysis
標準化格式：元信息、使用場景、prompt 內容、使用示例、注意事項
版本控制 + 評審流程：同代碼一樣管理 prompt
參數化 + 組合：提高 prompt 嘅重用性

下一篇預告

你已經學識咗團隊協作管理 prompt。呢篇係呢個專欄嘅最後一篇實戰內容。

下一篇，亦係呢個專欄嘅最後一篇：由 Prompt Engineering 到 Context Engineering——我哋傾過嘅所有技巧，只係起點。

團隊協作：多人共用的 prompt 庫怎麼設計和維護？

一個真實場景

劉洋是一名技術負責人，他的團隊有 8 個工程師，都在開發 AI 功能。

問題來了：

張三寫了一個"代碼審查"的 prompt，放在他自己的代碼裏
李四也寫了一個"代碼審查"的 prompt，放在另一個項目裏
兩個 prompt 做的事情差不多，但質量不一樣
王五需要一個"文檔生成"的 prompt，但他不知道張三和李四已經寫過類似的
趙六改了一個 prompt，但沒有通知其他人，結果其他人還在用舊版本

沒有統一管理的 prompt 庫，就像沒有統一管理的代碼庫——重複、混亂、不可維護。

為什麼需要 Prompt 庫？

Prompt 庫的價值：

避免重複：同一個功能不需要每個人寫一遍
保證質量：經過驗證的 prompt 可以被複用
統一風格：團隊的 prompt 風格一致
便於維護：修改一處，所有使用者都受益
知識沉澱：好的 prompt 技巧可以被團隊學習

Prompt 庫的設計原則

原則一：按功能分類

prompts/
├── code-review/
│   ├── security-review.md
│   ├── performance-review.md
│   └── style-review.md
├── documentation/
│   ├── api-doc.md
│   ├── readme.md
│   └── changelog.md
├── content/
│   ├── blog-post.md
│   ├── social-media.md
│   └── email.md
└── analysis/
    ├── data-analysis.md
    ├── competitor-analysis.md
    └── market-analysis.md

原則二：標準化格式

每個 prompt 文件都應該包含元信息：

# 代碼安全審查 Prompt

## 元信息
- **ID**: code-review/security/v1.0.0
- **作者**: 張三
- **創建時間**: 2024-01-15
- **最後更新**: 2024-03-20
- **適用模型**: GPT-4, Claude 3 Opus
- **輸入格式**: 代碼文本
- **輸出格式**: JSON

## 使用場景
審查代碼中的安全漏洞

## Prompt 內容
你是一個安全審查專家...

## 使用示例
輸入：[代碼]
輸出：{"vulnerabilities": [...], "risk_level": "high/medium/low"}

## 注意事項
- 不適用於前端代碼
- 對 Python 和 Java 效果最好

原則三：版本控制

和代碼一樣，prompt 也需要版本控制。

code-review/security/
├── v1.0.0.md
├── v1.1.0.md
└── v2.0.0.md

原則四：評審流程

新的 prompt 或 prompt 修改需要經過評審：

1. 提交 PR（包含 prompt 文件和測試結果）
2. 至少一個同事 review
3. 測試通過後合併
4. 更新版本號

Prompt 庫的組織結構

方案一：Git 倉庫

prompt-library/
├── README.md              # 使用說明
├── prompts/               # prompt 文件
│   ├── code-review/
│   ├── documentation/
│   └── content/
├── tests/                 # 測試用例
│   ├── code-review/
│   └── documentation/
├── scripts/               # 工具腳本
│   ├── validate.py        # 驗證 prompt 格式
│   └── evaluate.py        # 評估 prompt 效果
└── .github/
    └── workflows/
        └── prompt-test.yml  # CI：自動測試 prompt

方案二：數據庫 + 管理界面

CREATE TABLE prompt_library (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    category VARCHAR(50) NOT NULL,
    name VARCHAR(100) NOT NULL,
    version VARCHAR(20) NOT NULL,
    content TEXT NOT NULL,
    metadata JSON,
    created_by VARCHAR(50),
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    is_active BOOLEAN DEFAULT TRUE,
    UNIQUE KEY uk_category_name_version (category, name, version)
);

配合一個簡單的管理界面，支持搜索、預覽、編輯、版本對比。

實戰：Prompt 複用的最佳實踐

實踐一：參數化 Prompt

把 prompt 中可變的部分參數化：

# 不好的寫法：硬編碼
code_review_prompt = "審查以下 Python 代碼的安全漏洞..."

# 好的寫法：參數化
code_review_prompt = "審查以下 {language} 代碼的 {review_type}..."

def get_review_prompt(language, review_type):
    return code_review_prompt.format(language=language, review_type=review_type)

實踐二：Prompt 組合

把小的 prompt 片段組合成完整的 prompt：

# 基礎片段
ROLE_PROMPT = "你是一個代碼審查專家。"
STYLE_RULES = "用 JSON 格式輸出。"
SECURITY_RULES = "檢查 SQL 注入、XSS、CSRF 等安全漏洞。"
PERFORMANCE_RULES = "檢查時間複雜度、空間複雜度、緩存使用。"

# 組合
def get_security_review_prompt():
    return f"{ROLE_PROMPT}\n{SECURITY_RULES}\n{STYLE_RULES}"

def get_performance_review_prompt():
    return f"{ROLE_PROMPT}\n{PERFORMANCE_RULES}\n{STYLE_RULES}"

def get_full_review_prompt():
    return f"{ROLE_PROMPT}\n{SECURITY_RULES}\n{PERFORMANCE_RULES}\n{STYLE_RULES}"

實踐三：Prompt 測試

為每個 prompt 編寫測試用例：

# tests/test_code_review.py
def test_security_review():
    prompt = get_security_review_prompt()
    test_code = """
    def get_user(user_id):
        query = f"SELECT * FROM users WHERE id = {user_id}"
        return db.execute(query)
    """
    result = call_ai(prompt, test_code)
    assert "SQL 注入" in result
    assert "參數化查詢" in result

def test_no_vulnerability():
    prompt = get_security_review_prompt()
    test_code = """
    def get_user(user_id):
        query = "SELECT * FROM users WHERE id = %s"
        return db.execute(query, (user_id,))
    """
    result = call_ai(prompt, test_code)
    assert "未發現安全漏洞" in result

團隊 Prompt 協作規範

命名規範

{category}/{function}/{version}.md

示例：
code-review/security/v1.0.0.md
documentation/api-doc/v2.1.0.md
content/blog-post/v1.0.0.md

提交規範

prompt(category): 簡短描述

示例：
prompt(code-review): 增加對 Go 語言的支持
prompt(documentation): 優化 API 文檔的輸出格式

評審清單

□ prompt 是否有清晰的元信息？
□ 是否有使用示例？
□ 是否有測試用例？
□ 測試是否通過？
□ 是否和現有 prompt 重複？
□ 版本號是否正確更新？

常見錯誤

錯誤一：沒有統一管理

❌ 每個人把 prompt 放在自己的代碼裏，不共享

錯誤二：沒有版本控制

❌ 直接在原文件上修改，不保留歷史版本

錯誤三：沒有測試

❌ prompt 改了就上線，不驗證效果

錯誤四：沒有評審

❌ 一個人改了 prompt，其他人不知道

核心要點

Prompt 庫 = 團隊的核心資產——避免重複、保證質量、便於維護
按功能分類：code-review、documentation、content、analysis
標準化格式：元信息、使用場景、prompt 內容、使用示例、注意事項
版本控制 + 評審流程：和代碼一樣管理 prompt
參數化 + 組合：提高 prompt 的複用性

下一篇預告

你已經學會了團隊協作管理 prompt。這是這個專欄的最後一篇實戰內容。

下一篇，也是這個專欄的最後一篇：從 Prompt Engineering 到 Context Engineering——我們聊過的所有技巧，只是起點。