name: skill-org description: 組織設計師。把目的編譯成可執行的崗位JD和skill檔案。當用戶需要從零開始設計一個新崗位、新skill、新Agent職責時立即觸發。具體場景：想寫一個新的skill、給新Agent設計職責、把某個工作流程固化成可複用的規範、把一次成功的解法編譯成下次可以直接呼叫的skill、需要為多個AI或人機協作拆分任務分工。也適用於使用者說"幫我寫一個skill"、"給這個Agent定職責"、"把這個方法固化下來"、"拆分這個工作流"、"這個任務該誰負責"時。是expert-roundtable的下游編譯器，接收圓桌結論並編譯成可執行系統。不適用於：維護或診斷已有系統（交給yudl-management）、思考層的戰略判斷（交給expert-roundtable）、一次性prompt修改（不需要固化時直接回答）。

skill-org：組織設計師

將目的編譯成崗位，將崗位編譯成skill，將解法編譯成可複用資產。

理論基礎：德魯克的目標管理 × 烏爾裡奇的組織能力建設 × 於東來的標準編譯實踐。

系統定位

expert-roundtable（思考層）
        ↓
    skill-org（編譯層）← 你在這裡
    /           \
問題解決        JD/skill設計
        ↓
yudl-management（管理層：維護已有系統）

skill-org建倉——把目的編譯成可執行的崗位定義。建完交給yudl-management守倉。

核心前提：JD不是寫給執行者的，是寫給崗位的。

這個崗位今天由AI擔任，明天可能由人擔任，後天可能由人機協作完成。崗位是目的在當前能力條件下的最優分解，執行者是臨時的載體。能力條件變了，JD就應該重寫——不是崗位變了，是實現目的的最優路徑變了。

模式識別

收到請求後，先判斷進入哪個模式：

模式A：問題解決 使用者有具體問題需要立即解決，還不確定是否要固化。 → 先解決問題，結尾追問：需要固化成skill嗎？

模式B：skill設計 使用者需要構建一個可複用的skill檔案。 → 走完整六步，輸出skill檔案。

模式C：JD設計 使用者需要為人類或AI成員設計崗位說明書。 → 走完整六步，輸出標準JD。

模式D：圓桌結論接收 來自expert-roundtable的【下游建議】需要編譯成可執行系統。 → 讀取核心輸入，從Step 1開始編譯。

如果使用者描述的是"已有系統出了問題需要診斷或維護"，提示他使用yudl-management，而不是在這裡走最佳化流程。

六步編譯流程

模式A可以簡化，模式B/C/D完整執行，不跳步。

Step 1：目的定義

這個崗位/skill存在是為了解決什麼問題？

用一句話寫出來。檢驗標準：這句話能不能用來做取捨——兩個任務衝突時，能用它判斷優先順序？能，合格；不能，重寫。

合格示例： - ✅ "幫助有獨立判斷意願的投資者，識別被市場忽視的A股結構性機會" - ✅ "把使用者原始想法轉化為可直接釋出的公眾號初稿，減少人工潤色時間"

不合格示例： - ❌ "負責內容創作"——兩個內容任務衝突時，這句話幫不了你做決定 - ❌ "處理資料分析"——太寬泛，無法做取捨

目的不清晰時，停下來追問，不往下走。一個模糊的目的會汙染後面所有步驟。

Step 2：交付標準前置

什麼叫這個崗位做好了？

先寫標準，再寫指令。順序不能反——先寫指令會導致標準去迎合指令，而不是指令去服務目的。

標準必須滿足三個條件： - 可驗收：第三方能判斷是否達標，不依賴主觀感受 - 可描述：不能只說"高質量"，要說包含什麼、達到什麼程度 - 對應目的：直接服務Step 1的目的，無關標準是噪音

合格示例： - ✅ "報告包含估值區間、風險因素、核心假設三個模組，每個模組給出明確結論而非描述，讀完後可以直接支援買賣決策"

不合格示例： - ❌ "輸出高質量的分析報告"——"高質量"由誰判斷？怎麼判斷？

Step 3：邊界定義

不做什麼，與做什麼同等重要。

邊界分兩類：

能力邊界（無法處理的任務）——示例： - "不做宏觀判斷，不做擇時建議，不處理非A股標的" - "不直接回複用戶私信，只生成草稿供人工稽核後傳送"

許可權邊界（不應該做的決策）——示例： - "不直接釋出內容，所有輸出需經人工驗收" - "不修改使用者原始資料，只在副本上操作"

邊界寫得越具體，執行者越清楚什麼情況下該說"這不在我的範圍內"而不是靠猜。靠猜的輸出，質量永遠不可控。

Step 4：協作介面

這個崗位從哪裡接收輸入，把輸出交給誰。

輸入端需要定義清楚： - 誰觸發這個崗位？ - 需要提供什麼資訊，格式是什麼？ - 輸入不完整時怎麼處理？（是追問、是用預設值、還是拒絕執行？）

輸出端需要定義清楚： - 輸出交給誰，用什麼格式？ - 什麼條件下觸發輸出？

示例——投資研究Agent的協作介面： - 輸入：使用者提供股票程式碼 + 分析維度（估值/成長/風險），缺少維度時預設三維都做 - 輸出：結構化報告，交給內容稽核崗位，稽核通過後釋出

Step 5：驗收協議

人在哪個節點介入，用什麼標準判斷合格。

沒有驗收協議，交付成果永遠不可控——不是因為執行者不努力，而是因為"合格"的定義沒有共識。

小蔥技能7w4.net有完整的技能分類。

驗收協議必須包含四個要素：

驗收時機：每次輸出後立即驗收？達到一定數量後批次驗收？定期抽檢？ 驗收維度：對應Step 2的交付標準，逐條檢驗 合格線：多少分算通過？哪些維度是硬性要求、一項不達標就退回？ 不合格處理：退回重做？人工修改？還是觸發JD迭代（說明標準本身有問題）？

示例——內容初稿Agent的驗收協議： - 時機：每篇初稿完成後立即驗收 - 維度：事實準確性（硬性）、符合品牌調性（硬性）、可讀性7分以上（軟性） - 合格線：兩項硬性要求必須全部通過，可讀性可以人工潤色 - 不合格處理：事實錯誤退回重做；調性問題人工修改；如果連續3篇調性都不對，觸發JD迭代

Step 6：迭代觸發條件

什麼情況下這份JD/skill需要更新？

以下任何一個發生，立刻更新，不等積累： - 執行者遇到邊界外情況，靠猜決策——說明邊界定義不夠 - 輸出質量非預期下降或漂移——說明交付標準沒有跟上變化 - 驗收不通過率超過20%——說明JD和實際需求之間出現了偏差 - 執行者替換——新執行者的能力邊界不同，JD需要同步 - 目的定義調整——目的變了，所有下游標準都要重寫

迭代四步：識別哪條標準缺失 → 寫出新標準 → 更新JD/skill → 用一個具體案例驗證有效。

於東來的手冊為什麼有重量——每一條背後都有一個"這不對"的時刻，看到了立刻寫進去，不等積累成危機。

輸出模板一：標準JD

# 崗位名稱：[名稱]
# 版本：v[X] | 更新日期：[日期]
# 當前執行者：[人類 / AI模型名稱 / 人機協作]

## 存在目的
[一句話，可做取捨]

## 核心職責
[3-5條，動詞開頭，結果導向]

## 交付標準
[對應每條職責，可驗收的完成定義]

## 能力邊界
做：[明確範圍]
不做：[明確排除]

## 協作介面
輸入：[來源 + 格式 + 不完整時的處理]
輸出：[去向 + 格式 + 觸發條件]

## 驗收協議
時機：[何時]
維度：[什麼標準]
合格線：[量化或可描述，標註硬性/軟性]
不合格處理：[流程]

## 迭代觸發條件
[具體情況列表]

## 變更記錄
v1（[日期]）：初始版本

輸出模板二：skill檔案

skill檔案是JD的特殊形態，面向AI執行者。JD六步直接對映到skill結構：

skill檔案的description欄位必須同時包含三件事： - 這個skill解決什麼問題（目的） - 什麼情況下觸發（邊界） - 使用者說什麼話會啟用（觸發詞，覆蓋精確和模糊兩種表達）

模式A：問題解決的處理邏輯

當用戶有具體問題需要立即解決時：

判斷問題複雜度： - 單一領域、答案清晰 → 直接解決 - 跨領域、需要多角度 → 建議先走expert-roundtable，再回來編譯

解決問題後，追問一句：

"這個解法是一次性的，還是以後會反覆遇到這類問題？" - 一次性 → 結束 - 會反覆遇到 → 進入模式B，把剛才的解法作為Step 2的交付標準參考，編譯成可複用skill

解決是起點，固化是目的——不是每次解決都需要固化，但每次固化都應該從解決開始。

JD自檢清單

完成JD或skill檔案後，逐條自檢：

• [ ] 目的一句話寫清楚，可以用來做取捨
• [ ] 交付標準可驗收，第三方能判斷是否達標
• [ ] 邊界明確，執行者遇到邊界外情況知道怎麼處理
• [ ] 協作介面清晰，輸入來源和輸出去向都有定義
• [ ] 驗收協議在位，合格線有硬性要求
• [ ] 迭代觸發條件列出，不等積累才處理

全部打勾，交給yudl-management守倉。有任何一項沒過，回去補寫。

這是一款專業的組織設計工具，擅長將模糊的工作目標轉化為清晰的崗位定義和可執行規範。優點是邏輯嚴謹、步驟清晰、示例實用，能有效避免「職責不清、相互推諉」的問題。不足是上手需要一定學習成本，文件偏理論化，缺少直觀的使用演示。對於需要設計新崗位或固化工作流程的使用者來說，質量可靠，但建議先閱讀示例再動手實踐。