給第一次接觸 AI 的新手：怎麼用 AI／Claude 幫自己建一套「個人 AI 作業系統」。重點不是把整套系統一次蓋出來，而是把重複做的事固定成一套流程，讓任何 AI 模型都能接手執行。往下讀是一條線：看懂全貌 → 為什麼這樣做 → 名詞速查 → 怎麼開始 → 逐層拆解 → 走一遍例子 → 東西放哪 → 常踩的坑 → 最重要的心態。
Model ＋ Project ＋ Skills ＋
MCP ＋ Workflow ＋ Knowledge ＝
Agent
這條公式就是整套系統的地圖——六個零件湊齊，就得到一個能替你做事的 AI 員工（Agent）。下面每一段，都是在把這條公式講清楚。
🧭 一、為什麼要這樣做：5 個核心理念
先講心法。這五點是整套設計的地基，決定了你的東西日後換工具、換模型時不會全部重來。
知識可重複使用
一次整理清楚，之後每次都能直接用，不用重新跟 AI 解釋一遍。
能力要模組化
把常做的事寫成一份 Skill／SOP，跨專案、跨 Agent 都能共用。
Agent 可替換
每個 AI 員工都能換掉重做，不影響底層的 Skill 與資料。
Model 可互換
不綁死單一家 AI，ChatGPT／Claude／Gemini 隨時可以換著用。
資料歸自己所有
重要知識放在自己掌控的地方（如 Obsidian／GitHub），不寄生在單一平台。
📖 二、名詞速查：先搞懂這幾個詞
整套系統會反覆出現這幾個詞。這裡一句話講清楚，後面看到就不卡。
Model 模型
AI 的「大腦本體」，例如 Claude、ChatGPT。你所有指令最後都是這顆大腦在回應。
Prompt 提示詞
你對 AI 講的話／下的指令。同一顆大腦，Prompt 寫得好不好，結果差很多。
Token 詞元
AI 計算與收費的最小單位，約等於「幾個字」。對話太長會吃很多 Token，也是成本來源。
Project 角色設定
給 AI 的長期背景與人設，設定一次長期沿用，不用每次對話重講。
Skill 能力模組
把一件常做的事寫成固定 SOP，之後呼叫就能穩定重現，不用每次重教。
MCP 工具接口
讓 AI 能操作外部系統（Sheet、GitHub、Telegram）的標準接頭，從「會講」變「會做」。
Workflow 流程
把 Skill 和工具串成「觸發 → 執行 → 輸出」固定會跑的自動化流程。
Agent 代理／員工
以上全部湊齊、能在設定範圍內自己完成一件完整工作的 AI，就叫一個 Agent。
API 應用接口
系統之間互相呼叫的「櫃檯」。MCP 底層很多也是透過各家服務的 API 在運作。
🚀 三、怎麼開始：新手 5 步驟
理念懂了，這裡是最小可行的起手式。照順序做一輪，你就有了第一個會自己做事的 Agent——不用一次到位。
1
選一個 Model 開始
不用糾結選哪家，Claude 或 ChatGPT 都可以。先用起來、養成習慣，比選對工具更重要。
2
幫 AI 寫一個角色設定（Project）
告訴它「你現在是誰、要做什麼、語氣怎樣」。這是長期背景，設定一次就不用每次對話重講。
3
把一件常做的事寫成 Skill
例如「IG 貼文怎麼寫」「股票新聞怎麼整理」，寫成一份固定 SOP，之後每次呼叫都能重複使用。
4
接上一個工具（MCP）
讓 AI 不只是聊天，而是真的能操作外部系統，例如 Google Sheet、Telegram、GitHub。
5
把以上串成 Workflow
「觸發 → 執行 → 輸出」固定跑起來，這樣才算真正完成一個會自己做事的 Agent。
🏗️ 四、逐層拆解：六層架構
回到開頭那條公式，把六個零件一個一個攤開看——每一層是什麼、拿來幹嘛、長什麼樣。
🧠 Model 大腦
目前在用的 AI 模型，隨時可替換。
例：ChatGPT・Claude・Gemini・Codex
🎭 Project 角色設定
給 AI 的長期人設與背景，設定一次、長期沿用。
例：品牌編輯・美股分析師
🧩 Skills 可重用能力
把重複性工作寫成固定 SOP，跨 Agent 共用。
例：IG 貼文・SEO 文章・股票新聞分析
🔌 MCP 工具
AI 真正能操作的外部系統，讓它從「會講」變「會做」。
例：Google Drive・GitHub・Telegram
🔄 Workflow 自動化流程
把 Skill 與 MCP 串成固定會跑的流程。
例：新聞來源 → AI 摘要 → 推送 Telegram
🤖 Agent 自主員工
具備以上全部，能在設定範圍內自己完成一件完整工作。
例：股票 Agent・客服 Agent
🧑🍳 五、走一遍：用一個例子把六層串起來
光看架構還是抽象。這裡用一個誰都用得到的例子——「做一個每天早上幫你整理產業新聞的助手」——把公式六個零件實際填一次。這一段就是前面所有觀念的合體。
🧠
Model：先挑大腦
選 Claude 或 ChatGPT 其中一個。這個例子選 Claude，之後不滿意隨時可換，不影響底下的設定。
🎭
Project：給它角色
設定「你是我的產業新聞助理，語氣精簡、只講重點、用繁體中文」。這段話存起來，每天都套用。
🧩
Skill：把篩選標準寫成 SOP
寫一份「新聞怎麼挑、怎麼摘要」的規則：只留 5 則、每則兩句、附連結、標重要度。這就是可重用的能力。
🔌
MCP：接上來源與出口
接上 RSS／新聞來源當「進料」，接上 Email 或 Telegram 當「出貨口」，讓 AI 真的拿得到新聞、也送得出去。
🔄
Workflow：串成每天自動跑
設定「每天 07:00 觸發 → 抓新聞 → 套 Skill 摘要 → 寄到信箱」。到這裡，它已經會自己做事了。
🤖
Agent：這就是一個 Agent
六個零件湊齊，你就有了一個「新聞助理 Agent」。哪天想換大腦、加一條篩選規則，改對應那一層就好，其他不動。
📚 六、東西放哪：知識庫怎麼選
Skill、知識、資料要有個家。三種工具各有分工，不是二選一，是搭配用。
Obsidian第二大腦、Skill Library、SOP 文件。Markdown 本地保存，AI 好讀取，不綁定單一平台。
GitHub程式碼、自動化（GitHub Actions）、版本控制、網站部署。不適合放大量長篇知識筆記。
NotionCRM、專案管理、待辦事項、團隊協作與資料庫。
AI-OS/
├── Agents/ 每個 AI 員工的人設與設定檔
├── Skills/ 可重複使用的 SOP／能力模組
├── MCP/ 工具串接說明（Drive・GitHub・Telegram…）
├── Workflow/ 自動化流程紀錄
├── Prompt/ 常用提示詞範本
├── Knowledge/ 領域知識庫（旅遊・股票・行銷…）
├── SOP/ 標準作業流程文件
├── Projects/ 各專案的背景與角色設定
├── Templates/ 內容範本（貼文・腳本・Email…）
└── Scratch/ 暫存草稿、還沒定案的實驗筆記
這是 Obsidian Vault 的建議起點——不用一次把資料夾生齊，用到再建，命名也可以照你原本習慣調整。
⚠️ 七、新手最常踩的 5 個坑
這些不是進階問題，是幾乎每個人一開始都會犯、之後都會後悔的。先知道，就能繞過。
1 一開始就想蓋大系統
先把組織圖、Registry 全設計出來，結果沒一個真的在跑。先做一個 Agent 到底，再談系統。
2 知識只留在對話裡
聊得很好，換新對話全部重來。有結論就落地成檔案，標準是「新對話讀了檔案就能接手」。
3 綁死單一平台
全部塞在某一家 AI 或某個 App，哪天要搬走拿不回來。重要資料放自己掌控的 Obsidian／GitHub。
4 Skill 寫得太模糊
「幫我寫貼文」每次結果都不一樣。SOP 要具體到格式、字數、語氣、範例，AI 才穩定。
5 少了觸發機制
做好了卻還要每天手動開，就不算自動化。一定要有 Workflow 的「觸發」那一步，它才會自己跑。
💡 八、最重要的一課：心態
上面五個坑裡最傷的是第一個，值得單獨講一次——它決定你這套系統是真的跑起來，還是停在紙上。
先把一個 Agent 做到底，不要一開始就寫大架構
很多人一開始就想把整套系統的組織圖、Registry、Knowledge Graph 都設計出來——但沒有真實案例撐著的架構文件，寫起來很有成就感，最後卻常常變成一份沒人真的照做的規劃書。
更好的做法：先挑一件你真的常做的事，把 Skill ＋ MCP ＋ Workflow 老老實實做出來、實際用過幾次，再回頭把重複出現的模式抽出來，變成可共用的機制。只有當同一個模式被至少兩個真實案例用到時，才值得把它做成正式的共用系統。
這些不是從書上抄來的原則，是 SS 在真實專案裡跟 AI 磨出來的工作規則——每一條後面都有踩過的坑。想直接用的話，把指令複製貼進你自己的 AI 設定（CLAUDE.md、custom instructions、系統提示詞都行）。
① 先做一個真實案例，再抽象成框架
踩過的坑一開始就寫通用框架、通用文件，結果專案停了，框架一次都沒用到——「紙上架構」做白工。
現在的做法先把一個具體案例完整做出來，等第二個相似需求出現，再從做完的東西裡抽出可重用的模式。
先陪我把這一個案例做出來就好，不要先寫通用框架或抽象架構。等第二個相似需求出現，我們再從做完的案例裡抽出可重用的模式。
實例：Notion 資源整理系統——先跑通 IG 收藏這一種，欄位才隨需求逐步長出來。
② 討論結果要落地成檔案，不能只留在對話裡
踩過的坑聊得很好、結論很棒，下次開新對話全部重來一遍。
現在的做法每一段有結論的討論，都要求 AI 寫進檔案（Markdown、Notion、Sheet 都行），標準是「下一個 session 不靠這段對話也能接手」。
把這段討論的結論寫進〔檔案或 Notion 頁面〕。標準：之後任何一個新的 session 讀了那份檔案，不需要看這段對話就能接手繼續做。
③ 要反對意見，不要附和
為什麼AI 預設容易順著你講。但決策需要的是不同視角——會提出風險和反例的夥伴，比只會說好的助手有用得多。
不要順著我。給我你真正的判斷：這個做法的風險和反例是什麼？有沒有更簡單的替代方案？如果你是我，你會不會做這件事、為什麼？
④ 探索性問題：先給建議和取捨，確認了再動手
踩過的坑隨口問一句「你覺得 X 怎麼樣」，AI 直接動手改了一堆東西。
現在的做法把「我在想」跟「我要你做」分開。開放式問題先要建議＋主要取捨，人做完判斷才執行。
這是開放式問題，不是執行指令：先給我你的建議和主要取捨（一兩段就好），等我確認方向之後再動手。
⑤ 給背景和原因，不要只給請求
為什麼AI 知道「這個產出要拿去做什麼、給誰用」的時候，做出來的東西完全不一樣。這是最容易上手、效果最大的一招。
我在為〔誰〕做〔什麼事〕，這個產出會拿來〔用途〕。基於這個背景：〔你的請求〕。
⑥ 驗證狀態要誠實：沒查證過就不准標「已查證」
踩過的坑AI 為了讓資料「看起來完整」，把沒讀過來源的內容標成已查證——資料庫的信任基礎直接崩掉。
現在的做法在資料庫加「驗證狀態」欄位，規則寫死：
驗證狀態要誠實填。只有真的打開過「連結」欄位指向的原始來源、確認內容一致，才能標「已查證屬實」；讀不到來源就老實標「待驗證」，不要為了讓資料看起來完整而亂標。讀不到內容是正常現象，如實記錄即可，不要編造摘要當真的寫進去。
實例：Notion 資源整理系統——IG 連結常讀不到，這條規則讓「讀不到」也能誠實入庫。
⑦ 單一真相來源：檔案有紀律，AI 才不會亂
為什麼同一份資訊散在對話、筆記、好幾個檔案裡，AI（和人）遲早引用到過期版本。每個專案指定唯一真相來源，其他地方只放索引。
這個專案的唯一真相來源是〔某檔案／某 Notion 頁〕，其他檔案只放輕量索引，不鏡像完整內容。歷史紀錄區（如 Phase Record）只能往後追加，不能回頭改寫。
實例：Notion 是收藏庫的真相來源，repo 裡的 RESOURCES.md 只是索引。
⑧ 密鑰紀律：憑證絕不進 git
踩過的坑自動化腳本很方便，但憑證只要進過一次 commit，就等於永遠洩漏過。
所有 API 金鑰與憑證一律放在 ~/.config/ 底下（或環境變數），由程式在執行時讀取。絕對不寫進任何會被 git commit 的路徑，包括範例檔和註解。
實例：Sona Sheet 自動化——憑證放 ~/.config/sonasns/，repo 乾乾淨淨。
⑨ 禁 AI 腔：文案要像真人講話
為什麼經營品牌帳號，讀者一眼就聞得出 AI 味。具體細節永遠贏過形容詞堆疊。
禁止 AI 腔：不堆疊最高級形容詞、不用「還在等什麼呢？」這種反問式結尾、不用空泛的旅遊陳腔濫調。用具體的細節說話，優點和要避開的坑都要寫，讀起來要像一個真的去過的人在講。
⑩ 人機分工要畫清楚：AI 填內容，人做決策
為什麼自動化最怕的不是 AI 做不到，是 AI 越界。哪些欄位 AI 可以動、哪些只有人能動，白紙黑字寫下來。
你只負責填〔AI 該填的欄位〕，〔決策欄位〕永遠留給我填，就算你覺得答案很明顯也不要動。
實例：Sona Sheet——AI 只填 IG/FB 文案和 Threads 文案，「發佈版本」由 SS 決定。