一人公司的目標或許顯得遙遠，但核心在於將自己的日常工作化為「產線一條龍」。透過將工作 SOP 轉化為提示詞，AI 才能真正複製並執行你的專業。
實戰案例：從作家助手到程式開發
以我日常使用的工具為例：- Vocus 作家助手：這是一套結合了作家助手、內容審查員與封面製圖師的完整作業流程。
- Gemini Coder：結合了 Coder 助手、Python 結對程式設計專家、MCP Server 開發專家與 Google API Builder。這樣做的好處是轉換任務時不需要手動保存進度，即可直接移轉到另一個 Gem 代理上。
技術挑戰：知識庫的限制
這種做法也有其侷限。我為這些 Gem 代理掛載了大量知識庫，但受限於 Gem 代理的知識庫檔案數量上限，無法全部掛載。當多個功能結合在一起時，代理的表現有時反而不如單獨運作時那麼「聰明」。特別是針對 MCP 與 Skill 這類新技術，模型原生訓練資料較少，必須外掛知識庫才能跟上最新進度。
<圖例：各個 Gem 代理對應的知識庫範例>
GitHub程式庫 The official Python SDK for Model Context Protocol; GitHub程式庫 FastMCP: The fast, Pythonic way to build MCP; NotebookLM資料庫 MCP 協定規範與 FastMCP 開發指南
Agent_Skill_Guideline.md; GitHub程式庫 Public repository for Agent Skills; GitHub程式庫 claude-code-templates: CLI tool for configuring and monitoring Claude Code; GitHub程式庫 superpowers: An agentic skills framework & software development methodology that works.; GitHub程式庫 anthropic-sdk-python; Core_Tech_Doc.md; Google_Antigravity_Dev_Reference.md
機密保護與本地部署的現實挑戰
當你將個人事業或私密事務交付給 AI 處理時，首要挑戰就是機密保護。本地部署 LLM 是一個解法，但在一般個人電腦上運行並不總是合用。
原因在於效能瓶頸。以我的配備為例：64G DRAM（分配 32G 給 VRAM）、4T SSD，運行本地 LLM 依舊緩慢。觀察工作管理員，GPU 負載僅 10%，但透過 GPU-Z 診斷發現溫度已飆升至 90°C。這顯示效能是被散熱不足給拖累的。除非是特別打造的系統，否則很難流暢執行本地 LLM。
解決方案：混合調度系統 為了變通，我規劃了一個「混合調度系統」：與機密相關的事務在本地執行，其餘則交給線上大模型。
系統架構：
這是一個基於 Python 的 AI 一人公司混合調度系統。系統會自動讀取 AI_Company_MultiDomain.md 規範，並根據職務設定切換至 Ollama（本地）或 Gemini API（線上）。
模型呼叫範例碼：
OLLAMA_URL = "http://localhost:11434/api/generate"
def call_local_model(model_name, prompt, system_prompt=""):
payload = {
"model": model_name,
"prompt": prompt,
"system": system_prompt,
"stream": False,
"format": "json" # 強制要求輸出 JSON
}
response = requests.post(OLLAMA_URL, json=payload)
return response.json()['response']
---
GEMINI_API_KEY = "" # 系統將於執行時注入
GEMINI_URL = f"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-preview-09-2025:generateContent?key={GEMINI_API_KEY}"
def call_online_model(model_name, prompt, system_prompt=""):
payload = {
"model": model_name,
"prompt": prompt,
"system": system_prompt,
"tools": "google_search"
"stream": False,
"format": "json" # 強制要求輸出 JSON
}
response = requests.post(GEMINI_URL, json=payload)
return response.json()['response']
Prompt 管理策略： 程式中的 prompt 與 system_prompt 分別代表對話內容與角色定義。為了管理方便，建議不要將字串全部塞在主程式中，可以採取獨立存放的做法：
- 獨立字串檔 (prompts.py)：方便集中管理。
# prompts.py (獨立存放字串，方便管理)
ROLE_PROMPTS = {
"GM": """# Role: The GM (總經理)
你是一人公司的決策中樞。負責接收 CEO 的模糊指令並將其拆解為任務...""",
"Sage": """# Role: The Sage (策略顧問)
你負責深度研究與 R³-C-A 邏輯分析...""",
"Muse": """# Role: The Muse (媒體經理)
你擅長內容降維與多平台改寫，品牌色彩為 #9F5BBA..."""
}
然後在主程式調用
from prompts import ROLE_PROMPTS
selected_role = "Muse"
system_message = ROLE_PROMPTS[selected_role]
# 隨後將 system_message 帶入 API 呼叫中
- 獨立 Markdown 檔案：將角色定義存於
data/目錄下，易於維護與升級。
最終討論出的檔案結構：
gem-ai-company/
├── backend/ # FastAPI 後端核心
│ ├── app/
│ │ ├── init.py
│ │ ├── main.py # 應用程式進入點
│ │ ├── api/ # API 路由 (Endpoint)
│ │ │ ├── init.py
│ │ │ ├── v1/
│ │ │ │ ├── chat.py # 處理對話與調度邏輯
│ │ │ │ └── domain.py # 處理領域切換與加載
│ │ ├── core/ # 核心業務邏輯 (公司大腦)
│ │ │ ├── init.py
│ │ │ ├── dispatcher.py # 職務路由與模型分配器
│ │ │ ├── loader.py # Markdown Prompt 提取器
│ │ │ └── config.py # 環境變數與設定 (Pydantic Settings)
│ │ ├── services/ # 外部服務整合
│ │ │ ├── init.py
│ │ │ ├── ollama_svc.py # 本地模型通訊
│ │ │ ├── gemini_svc.py # 線上模型通訊
│ │ │ └── firebase_svc.py # 資料庫與 Auth 整合
│ │ └── models/ # Pydantic 資料模型 (Schemas)
│ │ ├── init.py
│ │ ├── request.py
│ │ └── response.py
│ ├── tests/ # 單元測試與集成測試
│ ├── requirements.txt # 後端依賴項目
│ └── .env # 環境變數 (金鑰、URL)
│
├── frontend/ # React 前端應用 (Vite 構建)
│ ├── src/
│ │ ├── assets/ # 圖片、Logo
│ │ ├── components/ # 共用 UI 組件 (Chat, Sidebar)
│ │ ├── hooks/ # 自定義 Hook (useChat, useDomain)
│ │ ├── services/ # 呼叫後端 API 的封裝
│ │ ├── store/ # 全域狀態管理 (Zustand 或 Context)
│ │ ├── App.jsx # 主介面
│ │ └── main.jsx
│ ├── tailwind.config.js # 色彩規範設定 (#9F5BBA 等)
│ └── package.json
│
├── data/ # 知識庫與領域文件 (唯讀資料層)
│ ├── core/
│ │ └── AI_Company_MultiDomain.md
│ ├── domains/
│ │ ├── Domain_SelfMedia_Creator_v1.2.md
│ │ ├── Domain_Software_AIApp_v1.0.md
│ │ └── Domain_Quality_Consultant_v1.1.md
│ └── common/
│ ├── Guideline.md
│ └── SRS.md
│
├── docker-compose.yml # 容器化部署設定
└── README.md
為什麼需要這麼複雜的結構？ 這是為了降低與 AI 討論時的「認知落差」。在進行程式設計討論時，如果沒有實體的檔案結構與資料參考，AI 往往會憑據其沙盒中的代碼進行推論，導致產出與想像完全不同。將結構落實上傳到參考資料中，才能確保 AI 知道我們具體討論出了什麼，讓開發落到實處。
檔案結構看起來很複雜，但一開始其實沒有那麼多組件，以上是經過不斷討論、持續增加後的最終結果。
核心組件：PromptLoader
由於是多領域的實作，系統還需要一個 loader.py 來動態加載不同職務與領域的專長：
class PromptLoader:
"""
負責解析 AI 一人公司的 Markdown 知識庫。
校準後的路徑處理邏輯，確保在 backend 目錄下執行時能找到 data 資料夾。
"""
def __init__(self, data_root: str = "../data"):
# 取得目前檔案的絕對路徑，並指向 ../../../data (假設在 backend/app/core)
base_dir = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
self.data_root = os.path.join(base_dir, "data")
self.role_map = {
"GM": ["總經理", "The GM", "GM"],
"Sage": ["The Sage", "Sage", "策略師", "戰略顧問", "事實核查官"],
"Muse": ["The Muse", "Muse", "敘事師", "媒體經理", "主編"],
"Hunter": ["The Hunter", "Hunter", "行銷總監", "商業官"],
"Builder": ["The Builder", "Builder", "產品工程師", "架構師"],
"Gear": ["The Gear", "Gear", "營運專員", "SOP"]
}
self.active_prompts: Dict[str, str] = {}
self.current_domain = "Core"
def switch_domain(self, keyword: str):
"""切換領域並覆蓋 Prompt"""
domain_mapping = {
"品質": "Domain_Quality_Consultant_v1.1.md",
"軟體": "Domain_Software_AIApp_v1.0.md",
"自媒體": "Domain_SelfMedia_Creator_v1.2.md",
"教育": "Domain_DigitalEducation_v1.2.md",
"寫作": "Domain_Writing_News_v1.2.md",
}
#這些不是程式的全部，只是用來作為範例的片段。
加上介面設計 App.jsx 以及 API 工具（手腳）與工作流（專業知識），這就成為了完整的 AI Agent。
有點眼熟？像 OpenClaw？ 雖然聽起來像，但開源應用需要考量的防弊措施與各種情況下的設定與插件遠比這複雜得多。就像最近公開的 microGPT，核心程式只有 200 行，這僅僅是為了展示它的核心概念而已。
程式範例: main.py loader.py app.jsx
結語：提示詞即應用，你的投入並非徒勞
AI Agent 運作的靈魂仍然是提示詞，而且是具備高度穩定性的「成品級提示詞」。
所謂成品級，是指將提示詞開發到足以支撐完整工作流程。這需要的不僅是指令，還包含掛載專業知識庫（Semantic Skill）的能力。當你能理清自己的 SOP 並將其數位化，你就已經跨過了 AI 應用的最高門檻。
程式控制與工作流可以降低大模型的「幻覺」，但操作模型的根本始終是提示詞。你在提示詞工程上的每一分鑽研，都是在為未來的全自動化產線打下基石。
技術提醒： 當提示詞超過 5,000 字元時，模型容易產生幻覺或目標失焦。對於架構級提示詞，應採用前述的「職務調度方式」，以降低單次運行的負擔。
問卷調查：希望後續文章著重在？
- 繼續深挖提示詞工程（Prompt Engineering）：但再寫下去的深度不會超出 AI 一人公司，只是應用範圍擴展。
- 探索開發平台與工具應用（如 n8n, Google Opal...）：將 AI 實體化並與自動化流程接軌。這類較偏硬核開發的內容，不知道大家是否有興趣跟著看下去？
希望後續文章著重在？
<本文部分內容由 AI 協助生成，經人工編輯/發佈>
本地部署小型 LLM 推薦（2026 最新版）
1. 極致輕量級（VRAM 4GB 左右）
Phi-4-mini (3.8B)：微軟最新一代輕量旗艦，在數理推理與指令遵循上大幅超越前代 Phi-3-mini，是資源有限時最聰明的選擇，4GB VRAM 即可流暢運行。
Gemma 3 (1B / 4B)：Google 2025 年發布，架構全面升級，4B 版本在同級別中多語言理解與指令跟隨能力突出，適合快速原型與低延遲對話。
Qwen 3 (1.7B / 4B)：阿里 2025 年最新開源系列，中英文雙語能力在 4B 以下模型中仍屬頂尖，且支援 Thinking Mode，推理品質媲美更大規模模型。 >>> Qwen 3 (1.7B) 這我真的推薦，中文語意理解遠超過其他同級模型，其他模型要比它大超過兩三級，才有它同等的水準。 唯一的缺點是它的用字還是偏大陸用語，需要時時矯正。
2. 效能與資源平衡的黃金級別（VRAM 8GB 左右）
Llama 3.3 (8B)：Meta 於 2025 年底發布，延續 3.1 優秀架構並大幅優化指令遵循與工具呼叫能力，是目前 8B 級別通用能力最強的選擇，為個人 AI 助理核心首選。
Mistral Small 3.1 (22B 量化 / 7B)：Mistral 2025 年新版，7B 版本推理速度依然極快，量化後的 22B 版本在 8–12GB VRAM 機器上也可運行，性價比極高。
Qwen 3 (8B)：繼承 Qwen 2.5 強大中文優勢，並加入原生 Thinking Chain 推理，在多語言與複雜邏輯任務上表現明顯優於同級競品。
3. 高階效能與進階推理（VRAM 16GB 左右）
Gemma 3 (27B)：Google 2025 年旗艦開源模型，具備多模態（文字＋圖像）能力，在 STEM 推理與程式碼任務上表現接近 GPT-4o 等級，量化後 16GB 可運行。
Qwen 3 (30B MoE)：採用混合專家架構，活躍參數僅約 3B，但整體推理品質接近 72B 全量模型，是 16GB 硬體上效能/資源比最優秀的選擇之一。
DeepSeek-R2-lite：DeepSeek 2025 年推出的輕量推理模型，在數學、科學與邏輯推理任務上表現極為突出，開源且商業友善。
4. 專項領域特化模型
程式碼與數理邏輯：推薦 Qwen 2.5-Coder (7B) 或 DeepSeek-Coder-V2-Lite (16B 量化)。前者在程式碼補全與除錯上超越 CodeLlama，後者在數學解題上表現尤其出色。
AI 代理與工具呼叫：推薦 Llama 3.3 Hermes (8B)（NousResearch 微調版）或 Qwen 3 (8B)，兩者均可穩定輸出結構化 JSON 指令，原生支援 Function Calling，適合 API 串接與 Agent 框架（如 LangChain、AutoGen）。
💡 部署工具建議： Ollama 依然是最推薦的本地部署工具，2025 年已支援 Qwen 3、Gemma 3、Llama 3.3 等最新模型，一行指令即可運行（如 ollama run qwen3:8b）。若需要更完整的 WebUI 與 RAG 整合，可搭配 Open WebUI；追求更高推理效能則可考慮 llama.cpp 搭配最新 GGUF 量化格式，在 CPU+GPU 混合環境下也能獲得不錯的速度。
