一、先建立一個共識：工具效能的上限由協作方式決定

很多團隊對 AI 工具的期待是"接入即提效"，實際結果卻常常是兩極分化：團隊里一兩個人用得飛起，其他人淺嘗輒止；好用的提示詞存在某個人的本地筆記里，他一請假，相關任務的效率就回落。這不是工具問題，而是協作結構問題——個人能力沒有轉化為團隊能力。

協作 SOP 的作用就是完成這個轉化。它回答四個問題：誰負責維護這套工具鏈（角色）、新人如何快速達到團隊平均水平（上手）、好的經驗如何留下來傳下去（沉淀）、團隊如何持續校準使用方法（節奏）。這四個問題有了書面答案，工具價值才不隨人員流動而波動。

• 工具接入解決"能用"，協作 SOP 解決"越用越好"。
• 只存在某個人腦子里的用法，等于團隊沒有這個能力。
• SOP 要書面上墻，口頭約定在人員變動時必然失效。

二、協作基線：先統一團隊級的接入與申請流程

協作的前提是所有人的基礎環境一致。團隊級基線包括三件事：統一的接入入口、統一的 Key 申請流程、統一的默認配置。進入 靈能API 控制臺后，由負責人建立團隊賬號結構，成員通過申請流程領取個人調試 Key，而不是互相借用或共用一把。官網入口可以直接記錄為 https://www.lnsns.com/，連同申請流程一起寫進團隊 wiki 的固定位置。

基線統一的價值在于消除"環境差異噪音"。當所有人用同一個 *ase **L、同一套模型約定、同一種配置結構時，任何"我這不好用"的反饋都可以被快速定位——要么是個案問題，要么是大家都有的共性問題。如果每個人環境各異，連問題是不是同一件事都分不清，協作就無從談起。

團隊接入基線三件套：
- 統一入口：所有人使用同一個 *ase **L
- 統一申請：Key 領取走申請流程，禁止互借共用
- 統一約定：默認模型、配置文件結構、環境變量命名

• 基線配置寫成一頁文檔，新人第一天就能拿到。
• 基線變更由負責人統一發布，不允許私下各**的。
• 定期抽查成員環境是否與基線一致，漂移越早糾正越便宜。

三、角色分工：負責人、 champion、使用者三層結構

團隊使用 AI 工具最常見的結構性問題是"人人有份、無人負責"。推薦三層角色結構。第一層是負責人（1 人）：掌管控制臺權限、Key 生命周期、預算和最終決策權，這個角色可兼任但不可空缺。第二層是 champion（1-2 人）：團隊里最熟這套工具的人，負責收集反饋、維護模板庫、培訓新人、評估新模型——這是團隊能力增長的發動機。第三層是使用者（全員）：按規范使用、按要求反饋。

角色要落到具體責任清單上，而不是停在頭銜。負責人每月***用量和預算復核；champion 每兩周整理一次反饋并更新模板庫；使用者在遇到輸出質量問題時按格式提交樣本。責任清單寫進一份矩陣文檔，誰做什么、多久***、產出什么，一目了然。

角色責任矩陣示例：

角色      | 周期職責                     | 產出
負責人    | 每月用量/預算/Key 復核       | 復核記錄
champion  | 每兩周收集反饋、更新模板庫   | 模板更新日志
使用者    | 遇到問題按格式提交樣本       | 問題樣本
全員      | 每周站會同步一個使用心得     | 周會紀要

• 負責人和 champion 兩個角色不要長期由同一人兼任，避免單點。
• champion 的投入要計入正式工作量，***熱情白嫖。
• 角色交接要有文檔化清單，人員變動時按清單逐項交接。

? 四、新人上手：一小時接入 SOP

新人上手速度是檢驗團隊 SOP 成色的試金石。如果新人接入要靠"找人問"，說明文檔缺位；如果新人第一周產出質量明顯低于團隊均值，說明培訓缺位。推薦一份"一小時接入 SOP"：前 20 分鐘按接入文檔完成賬號、Key、客戶端配置；中間 20 分鐘跑三個冒煙任務熟悉輸出風格；最后 20 分鐘由 champion 帶著看三個團隊內部的優秀案例，講清楚團隊約定的質量標準。

這份 SOP 還有兩個細節決定成敗。一是指定 *uddy：新人第一周有固定的人可以問，避免"不好意思打擾大家"導致的沉默踩坑。二是回收反饋：新人完成接入后，請他指出文檔里看不懂的地方——新人是文檔最好的測試者，他們的困惑就是文檔的 *ug 清單。

新人一小時接入 SOP：

00-20 分鐘：按接入文檔完成賬號、Key、客戶端配置
20-40 分鐘：跑通三個冒煙任務（解釋 / 排錯 / 生成）
40-60 分鐘：champion 講解三個內部優秀案例
第一周：    指定 *uddy 隨時答疑
第一周末：  新人反饋文檔問題，champion 負責修訂

• SOP 的時間盒要真的可執行，每個環節都按真實操作驗證過。
• *uddy 機制寫在文檔里，點名到人，不是"有問題找大家"。
• 新人對文檔的吐槽是最寶貴的修訂輸入，收集并落實。

五、知識沉淀：案例庫、踩坑記錄與 FAQ 三層結構

團隊使用 Codex 的過程中每天產生大量經驗：某個提示詞效果特別好、某類任務模型總是翻車、某個配置坑了兩個人。這些經驗不沉淀，就會隨聊天記錄一起沉沒。推薦三層沉淀結構。案例庫：收集高質量的任務輸入輸出對，標注任務類型和為什么好，供新人學習和模板迭代用。踩坑記錄：每個踩過的坑寫三行——現象、原因、解法，按錯誤類型歸類。FAQ：高頻問題的一問一答，面向"不想讀長文檔"的場景。

沉淀的關鍵不在結構而在入口：寫入成本必須足夠低。建議約定輕量格式——案例就是"輸入 輸出 一句點評"，踩坑就是三行字，FAQ 就是一問一答，放進團隊現成的 wiki 或倉庫里。格式一重，就沒人寫了；沒人寫，再完美的分類法也是空架子。

知識沉淀三層格式：

案例庫：  輸入 | 輸出 | 一句點評（為什么好）
踩坑記錄：現象 | 原因 | 解法（三行以內）
FAQ：     問題 | 答案（一段話以內）

存放位置：團隊 wiki 或倉庫 do**/ 目錄，入口固定在顯眼處

• 沉淀格式寧輕勿重，寫入成本決定沉淀率。
• 案例庫和提示詞模板庫聯動：好案例是模板迭代的原料。
• 每月清一次過時條目，知識庫的可信度比豐富度重要。

六、**與反饋規范：讓"不好用"變成可修復的問題

團隊里對 AI 工具最常見的反饋是"不好用"——這句話無法修復任何東西。SOP 里要給反饋定一個格式：任務類型、輸入規模、使用的模型和模板、實際輸出、期望輸出。五要素齊全的反饋，champion 十分鐘就能定位是模板問題、模型問題還是使用問題；缺了這些，反饋只能停留在情緒層面。

同樣重要的是**規范。在團隊頻道里問"Codex 怎么用"之前，先查 FAQ 和踩坑記錄；**時帶上已嘗試的方法和報錯信息。這不是****，而是保護 champion 的時間——如果每個問題都要從零問起， champion 很快就會被消耗到沒有精力做真正的沉淀工作。

反饋五要素格式：

任務類型：代碼**
使用配置：codex-review   review.v2.1 模板
輸入規模：約 400 行 diff
實際輸出：（粘貼或截圖）
期望輸出：應指出第 87 行的并發問題但未發現

• 五要素齊全的反饋才是可修復的問題，其余都是情緒。
• **前先查 FAQ 和踩坑記錄，寫進團隊公約。
• champion 對反饋要有響應 SLA，比如兩個工作日內給結論。

七、驗收標準：團隊內部統一"什么叫可用的輸出"

協作里最容易產生摩擦的地方，是對輸出質量的主觀分歧：有人覺得模型的代碼建議"差不多能用"就直接提交了，有人堅持必須人工復核每一行。消除分歧的辦法是把驗收標準寫下來。按任務類型定義"可用"的底線：代碼類輸出必須本地編譯通過且經過人工 review；文檔類輸出必須事實核對無誤；分析類輸出必須能追溯到輸入依據。

驗收標準不是限制使用，而是統一預期。有了明確標準，新人知道做到什么程度算完成，評審者知道按什么尺度把關，出了質量問題也能客觀歸因——是標準缺失、執行不到位，還是模型能力邊界。標準和實際執行出現系統性偏差時，修訂標準而不是默許偏差。

輸出驗收底線示例：

代碼類：編譯通過   人工 review   測試覆蓋新增邏輯
文檔類：事實核對   術語與團隊詞表一致
分析類：每個結論可追溯到輸入材料的具**置
通用：  不引入未授權依賴、不泄露內部信息

• 驗收標準按任務類型寫底線，不寫空洞的"保證質量"。
• 標準公開給全員，包括剛入職的新人。
• 標準與執行系統性偏離時修訂標準，不要默許雙層規則。

八、節奏維持：15 分鐘周會與雙周模板更新

SOP 最大的敵人是惰性：文檔寫完、流程定好，三個月后沒人再看。對抗惰性靠固定的輕量節奏。推薦兩個周期動作。每周 15 分鐘站會環節：每人分享一個本周的使用心得或問題，champion 記錄，有價值的當場決定進案例庫還是進踩坑記錄。每兩周一次模板更新窗口：champion 集中處理反饋、修訂模板、評估是否引入新模型或新場景，更新日志同步全員。

節奏設計的原則是"輕到不會被取消"。會議超過半小時就會被項目擠掉，更新窗口依賴大塊時間就會無限延期。15 分鐘和雙周窗口的意義不在于單次產出多少，而在于讓"持續校準"成為團隊的肌肉記憶——這套機制運轉半年，團隊的工具使用水平會拉開肉眼可見的差距。

團隊節奏示例：

每周：15 分鐘使用心得站會（一人一條，當場歸類）
雙周：模板庫更新窗口（champion 主持，產出更新日志）
每月：用量與預算復核（負責人，產出復核記錄）
每季：SOP 整體回顧（全員，決定廢改立）

• 節奏要輕到項目再忙也不會被取消，這是最高設計原則。
• 每次節奏動作都要有可見產出，沒有產出的會議會被自然淘汰。
• 季度回顧決定 SOP 自身的廢改立，機制也要接受檢驗。

九、效能度量：用數據回答"SOP 有沒有用"

協作 SOP 推行一段時間后，需要用數據驗證它是否真的在起作用。推薦四個信號。新人上手時長：從入職到產出達標的平均天數有沒有縮短。反饋處理率：五要素反饋中，被定位并修復的比例——低于五成說明反饋通道形同虛設。知識庫活性：案例庫和踩坑記錄的月均新增條目，長期為零意味著沉淀機制失效。模板復用率：正式場景中使用團隊模板的比例，這是 SOP 滲透率的直接體現。

度量數據來自現有記錄，不需要額外系統：新人上手時長問 mentor 就有，反饋處理率看 champion 的記錄，知識庫活性數提交次數，模板復用率抽查合并請求。每季度回顧一次這四個數，趨勢比絕對值重要——持續改善就說明 SOP 活著，連續停滯就要回頭看是哪個環節斷了。

協作效能四指標：

1. 新人上手時長：入職到產出達標的天數（目標：持續縮短）
2. 反饋處理率：被定位修復的反饋占比（目標 > 50%）
3. 知識庫活性：月均新增條目數（目標：不為零）
4. 模板復用率：正式場景使用團隊模板的比例（目標 > 80%）

• 四個指標都取自現有記錄，不要為度量大動干戈。
• 看趨勢不看單點，一個季度的方向比某個月的高低重要。
• 指標停滯時先查機制是否還在運轉，再談優化。

? 十、結語：SOP 讓工具能力在團隊里扎根

回顧整個協作體系：統一基線消除環境噪音，三層角色讓責任落地，一小時 SOP 讓新人快速達標，三層知識庫讓經驗沉淀，反饋規范讓問題可修復，驗收標準統一質量預期，輕量節奏對抗惰性，四個指標準確度量效果。每一環都不復雜，組合起來就是"團隊能力不隨人員流動而波動"的保障。

落地建議從最小閉環開始：先任命負責人和 champion，寫一頁接入基線文檔，跑第一次 15 分鐘心得站會。三周之內，你就能看到第一批沉淀下來的案例和第一條被修復的反饋。靈能API 提供穩定統一的接入底座，而底座之上的團隊能力，正是靠這套 SOP 一寸一寸扎下根去的——到那時候，Codex 對團隊而言不再是"某個人擅長的工具"，而是"這個團隊的標準作戰能力"。