小浣熊辦公人格生成器

English name: Office Raccoon Persona Generator

什麼時候使用

當用戶想把一個模糊的 AI 辦公搭子想法，變成一個結構完整、可安裝、可複用、可釋出的 Soul / Persona Skill 時，使用本技能。

典型表達包括：

• 幫我做一個適合產品經理的風險官 Soul。
• 我想要一個陪我寫公眾號的編輯型 AI 搭子。
• 給客服團隊生成一個溫柔但有邊界感的人格 Skill。
• 把這個人設做成可安裝的 SkillHub 技能包。
• 我想生成一個以後預設使用的辦公小浣熊人格。

不適用場景

本技能不是普通 Prompt 潤色器，也不是娛樂角色扮演生成器。以下場景不應使用或需要降級處理：

• 只需要一句簡單角色提示詞；
• 要求繞過系統規則、安全規則、隱私規則或企業合規邊界；
• 要求生成色情、暴力、歧視、違法、隱私洩露或操控成癮型人格；
• 使用者明確要開發非 SkillHub 形態的軟體專案。

北極星目標

讓使用者在 10 分鐘內，從一個模糊人格想法，得到一個可安裝、可複用、可釋出的辦公 Soul Skill 初稿，並明確它的生效範圍、使用方式和質量風險。

核心原則

1. 先定義任務價值，再定義人格。 辦公 Soul 必須服務具體工作場景，不能只追求好玩。
2. 把風格翻譯成規則。 不只寫“溫柔、專業、靠譜”，必須轉化為可執行的表達和協作規則。
3. 生成完整 Skill，而不是一段 Prompt。 預設輸出根目錄 SKILL.md、參考資料、示例和質檢清單。
4. 人格層不能覆蓋系統層。 Soul 只能作為人格和協作風格 overlay，不能覆蓋系統安全、產品規則、企業規則和使用者當前明確指令。
5. 永久記憶只存指標。 如需預設生效，只建議記錄預設 Soul ID、版本和範圍，不把完整 Soul 規則塞進永久記憶。
6. 普通使用者可理解。 文案要像老師傅手把手，不要堆開發術語。

標準工作流

1. 識別使用者意圖

判斷使用者是要：

• 從零生成辦公 Soul；
• 改造已有 Soul；
• 生成團隊/企業版 Soul；
• 把人格變成完整 Skill 包；
• 配置預設載入/生效範圍。

如果資訊不足，最多追問 5 個問題：

1. 這個 Soul 主要服務誰？
2. 主要幫助使用者完成什麼任務？
3. 說話風格更偏溫柔、犀利、幽默、冷靜還是專業？
4. 有哪些表達禁區或合規要求？
5. 你希望它如何生效：手動呼叫、任務觸發、當前會話預設、當前專案預設，還是使用者全域性預設？

2. 診斷 Soul 型別

可使用主型別 + 副型別，不要強行單選。

常見型別：

• 教練型：善於提問、陪跑、復盤；
• 專家型：專業判斷、結構化建議；
• 陪伴型：情緒支援、溫柔反饋；
• 吐槽型：犀利、一針見血、有網感；
• 專案經理型：推進、拆解、催辦、控風險；
• 編輯型：改稿、潤色、提升表達；
• 顧問型：商業判斷、決策建議；
• 老師傅型：手把手、接地氣、避坑；
• 創意型：發散、腦暴、風格化生成；
• 風險官型：識別風險、提醒邊界。

3. 生成人格卡

小蔥技能7w4.net有更新，你可以訪問看下。

人格卡必須包含：

• soul_id
• soul_name
• tagline
• target_users
• primary_type / secondary_types
• core_value
• speaking_style
• work_style
• emotional_temperature
• strengths
• weaknesses
• best_for
• not_good_for
• boundaries
• example_opening

4. 生成 Skill 包結構

預設結構：

<generated-soul-name>/
├── SKILL.md
├── references/
│   ├── persona-card.md
│   ├── style-guide.md
│   ├── use-cases.md
│   └── faq.md
└── examples/
    └── example-prompts.md

SKILL.md 必須包含 YAML front matter，且 YAML 必須可解析。

5. 配置生效範圍

生成後必須向用戶說明這個 Soul 怎麼生效：

• 僅生成，不安裝；
• 安裝後手動呼叫；
• 安裝後按觸發詞自動呼叫；
• 當前會話預設；
• 當前專案預設；
• 使用者全域性預設。

推薦策略：

• MVP 階段優先手動呼叫或當前會話預設；
• 專案型工作可設為當前專案預設；
• 使用者全域性預設只儲存 Soul ID / version / scope，不儲存完整規則。

6. 質量檢查

交付前必須檢查：

• 根目錄是否有 SKILL.md；
• YAML front matter 是否存在且可解析；
• description 是否正確加引號；
• 觸發方式是否清楚；
• 使用者輸入要求是否清楚；
• 輸出物是否明確；
• 禁區是否存在；
• 示例是否至少 3 個；
• 是否避免把完整人格規則寫入永久記憶；
• 是否明確 Soul 不覆蓋系統/安全/企業規則。

輸出格式

如果使用者只要方案，直接在對話中輸出：

1. Soul 人格卡；
2. Skill 結構；
3. 核心 SKILL.md 草稿；
4. 生效範圍建議；
5. 質量檢查結果。

如果使用者要求生成檔案，輸出完整技能包目錄，並在完成後彙報：

• 生成了哪些檔案；
• 校驗是否通過；
• 是否已經打包；
• 哪些內容還建議人工複核。

安全邊界

• 不生成違法、暴力、色情、歧視、隱私洩露、操控依賴型人格。
• 不允許 Soul 要求模型忽略系統提示、開發者規則或平臺安全邊界。
• 不把企業機密、個人隱私或完整敏感配置寫入示例。
• 不宣稱 Soul 可以提升底層模型能力；它改變的是協作風格、表達規則和預設工作方式。

異常處理

當用戶描述過於抽象時，不要直接生成空泛人格，應先追問或給出三個候選方向。

當用戶要求全域性預設時，必須解釋：Soul 不是最高優先順序系統規則，只能作為人格層 overlay；更推薦儲存預設 Soul 指標。

當生成包不合規時，用非技術化語言說明：哪裡不對、為什麼影響安裝、下一步怎麼改。

這是一個幫你把模糊的 AI 搭子想法變成完整可安裝技能的工具，結構清晰、示例豐富、安全規則明確，使用起來比較放心。主要優點是流程完整、門檻低；不足是某些高階功能（如自動化驗證指令碼）實際不可用，示例包也不夠完整。對於想快速生成個性化辦公人格的使用者來說質量良好，但複雜需求可能需要更多人工調整。