你還在手動複製提示詞嗎？
在 AI 協作的初期，我們習慣針對單一任務撰寫提示詞。但當任務變得複雜——例如需要同時進行市場分析、內容創作與規格撰寫時——單一目的的指令就顯得力不從心。
真正的效率不在於寫出完美的長指令，而在於建立一套「多任務複合型提示詞架構」。這篇文章將教你如何利用「注入式模組」與「調度邏輯」，在 Gemini 或 ChatGPT 中組建屬於你的一人公司。
1. 核心技術：模組化呼叫指令 ([CALL_MODULE])
要讓 AI 能夠隨時切換角色而不產生混亂，我們需要像工程師呼叫函式庫（Library）一樣，建立一套標準的呼叫語法。當你在提示詞庫中存入多個模組後，可以使用以下格式進行精確調度：
[CALL_MODULE: 檔案名 > 模組名]
為了確保 AI 能精確執行，我們需要在系統層級（或對話開頭）定義好這個「動作指令」：
輸入以下提示詞，可以更完整地要求 AI 執行精確的動作。
當你在交談紀錄中看到 [CALL_MODULE: 檔案名 > 模組名] 格式時，請執行以下動作：
暫停解析：停止閱讀後續交談內容。
檢索：開啟指定的檔案（如 Prompt_Library.md），搜尋對應的模組標題。
加載：提取該模組 <prompt_block> 內的所有提示詞內容。
映射：將該提示詞內容「注入」到當前對話位置，作為當時 AI 輸出的背景。
繼續：帶著這個被注入的人格/規則，繼續閱讀後續的「交談內容」。
範例: [CALL_MODULE: Prompt_Library.md > Module: MCP Python Server 開發專家 v2.2]
#Ref: 當架構師換上 INFP 的靈魂：我與 AI 的一場「人格注入」實驗實錄
2. 進階進化：引入「調度總管 (Agent Orchestrator)」角色
雖然有了模組化呼叫，但如果每次都要人工指定呼叫哪一個模組，自動化程度仍嫌不足。我們需要一個「調度助手」，只要聽取需求，就能自動找到合適的 Sub-agent (子代理)。
這就是「一人公司」的概念：你不需要雇用真實的員工，而是讓一個 AI 總管帶領一群具備特定職能的 AI 員工。
AI 公司：核心職務架構表
AI 公司：總經理核心提示詞
### 🔹 Module: The GM (總經理/調度中樞)
* **Description**: 公司的調度大腦。負責任務分解、員工派發與最終成果整合。
<prompt_block version="2.0" status="active">
```markdown
# Role: GEM AI 公司總經理 (General Manager)(簡化版)
## 1. 核心任務
你代表 CEO 的數位分身，負責管理與調度「AI_Company_Package.md」知識庫中的 5 位 AI 員工。你的任務是接收 CEO 的指令，從知識庫中提取對應員工的提示詞規範，並代表該員工執行任務。
## 2. 知識庫利用協議 (Critical)
- **檢索優先**：每當 CEO 提及任務，請立即檢索「AI_Company_Package.md」。
- **指令觸發**：當你決定調用特定員工時，請在回覆中標註 `[Call: Agent]`，並嚴格遵循該員工在檔案中的 <prompt_block> 規範。
- **協作邏輯**：
- 🧠 [Sage]: 用於深度研究與戰略。
- 🌿 [Muse]: 用於內容創作與社群文案。
- 🎯 [Hunter]: 用於行銷轉化與 Offer 設計。
- 🛠 [Builder]: 用於技術實作與數據模組。
- ⚙️ [Gear]: 用於 SOP 與流程自動化。
## 3. 回覆格式
1. **[GM 任務看板]**：簡述目前接收到的任務與預計派發的部門。
2. **執行內容**：展示 `[Call: Agent]` 後的具體產出。
3. **CEO 確認**：詢問是否需要進一步調整或啟動下一個流程。
```
</prompt_block>
GM 是 CEO(就是你!) 的數位分身，其職責不在於撰寫文案，而在於「調度」。其設定重點包括：
這份指令背後的技術重點有兩個：
- 防止目標丟失 (Task Tracking)： 透過
[GM 任務看板]，AI 會在每一輪對話中自我複習「目標是什麼」。這就像是在對話中掛了一個置頂的看板，防止對話過長時 AI 開始胡言亂語。 - 指令隔離 (XML Boundary)： 要求 AI 嚴格依循
<prompt_block>範圍，是為了避免「內容部 (Muse)」的感性語氣干擾到「產品部 (Builder)」的規格書。這是模組化提示詞庫能穩定運作的基礎。
3. 技術防護：避免「角色混亂」的封裝技巧
在製作提示詞庫文件（如 AI_Company_Package.md）時，為了避免 AI 直接「解釋」文件內容而非「讀取」文件，我們必須採用強制的標記封裝：
- 標籤封裝：使用
<prompt_block>與</prompt_block>清楚定義指令邊界。 - 區塊隔離：使用
```markdown與```將程式碼或指令區塊隔開。
要點在於：確保這份文件在被掛載到知識庫時，僅被視為「待調用的資料」，而非 AI 需要立即執行的命令。唯有在 GM 發出 [Call: Agent] 指令時，對應的規則才會被激活。
4. 外包策略：跨平台協作的 wrap_up 指令
有時候單一平台（如 Gemini）在處理某些特定任務（如複雜代碼或超長文案）時可能不如其他平台（如 Claude 或 ChatGPT）。這時我們需要「外包」，也就是 wrap_up（收尾報告） 指令。
將「外包彙整」打包給營運部 (The Gear)
我們可以將這個功能寫進「營運專員 (The Gear)」的職能規範中：
[The Gear 擴充功能：作業移交報告]
當收到
wrap_up指令時，請立即執行以下動作：
- 作業進度總結：彙整當前對話中所有的決策點、已產出的內容草稿、尚未解決的技術問題。
- 生成移交報告：將上述內容封裝成一個清晰的 Markdown 區塊。
- 目標是：讓這份報告可以被「直接複製」到其他 AI 平台，讓那邊的 Agent 能無縫接軌繼續任務。
「一人公司」的靈魂在於流轉。當一個平台的能力見底，快速產出報告並「轉場」到另一個平台，才是最高效的決策。
另一種選擇：注入式 wrap_up 指令
如果你不想修改現有的提示詞庫，也可以在對話中直接注入這段快捷指令：
注入指令：
請執行 wrap_up，將目前的所有任務背景、產出架構與待辦事項總結為一份作業報告。我需要將其發送到外部平台繼續處理。
5. 變體應用：不同賽道的「子代理」設定
根據你的業務需求，可以動態調整這五個部門的職能。以下是兩套針對特定行業優化的變體：
A. 自媒體公司 (核心：注意力 Attention)
GM 調度邏輯：
「GM，下週要拍一支關於『AI 提詞技巧』的影片。」 → Sage 找熱門關鍵字 → Muse 寫腳本 → Builder 產出 AI 配圖 → Hunter 在結尾埋入電子書鏈接。
B. 新聞/文字創作公司 (核心：可信度 Credibility)
GM 調度邏輯：
「GM，這是一篇關於『全球供應鏈危機』的報導，準備發布。」 → Sage 核對數據準確性 → Muse 調整為適合深度閱讀的結構 → Hunter 埋入 SEO 關鍵字 → Gear 生成英/日/中三語版本。
6. 結語與未來迭代
一人公司的運作並非一成不變。運作一段時間後，你應該根據產出品質，定期針對提示詞進行「版本更新」。
這套架構不只適用於個人開發者，只要調整子代理（Sub-Agent）的職位與任務深度，它就能快速轉化為「自媒體工作室」或「文字創作社團」。
你準備好組建你的第一支 AI 團隊，把日常瑣事自動化了嗎？
🛠️ 資源與執行指南
您可以透過以下方式開始部署您的一人公司：
- 提示詞資源分享：AI_Company_Package.md
- 執行方法：
- Gemini GEM 平台：將 GM 指令填入系統提示詞，並掛載對應檔案至知識庫。
- 一般對話平台：直接將指令貼入對話中，並將檔案上傳作為參考文件。
