by Rain Chu | 9 月 19, 2026 | AI, 程式開發
用 AI 做網站或小工具，最讓人緊張的時刻，往往是原本正常的功能突然壞掉，請它修一下，又改出更多問題，最後連哪個版本能用都說不清楚。
Vibe Coding 想要改得放心，先要有能確認的版本紀錄，Git 負責保存程式變更，GitHub 提供遠端儲存庫與協作流程。你不必先背熟指令，但要能回答改動存在哪裡、是否進入主分支，以及復原會影響哪些內容。
這篇 GitHub 入門指南以能讀寫專案檔案的 AI 開發工具為情境，若使用 Lovable 這類 AI App Builder，也要先確認平台的版本紀錄、GitHub 同步與部署各由誰管理，避免把不同系統的「已儲存」當成同一件事。
Git 和 GitHub 差在哪？先分清楚存檔與提交
Git 是版本控制工具，可以在自己的電腦上運作，GitHub 則是託管 Git 儲存庫的平台，讓程式可以放到遠端、比較修改內容，再透過 Pull Request 討論與合併，使用 Git 不一定要使用 GitHub，也可以搭配其他託管平台。
按下編輯器的儲存，只代表檔案寫入磁碟，commit 才是建立一筆 Git 提交紀錄，通常記錄的是放入暫存區的內容，也就是這次選定要提交的變更，尚未加入版本控制、被忽略，或還沒選入暫存區的修改，不會因為做了一次 commit 就全部被保存，細節可參考 Git 官方的變更記錄說明。
因此，第一次請 AI 接手專案，可以先讓它檢查是否已有 Git 紀錄、目前在哪個分支，以及有哪些未提交的檔案，接著在功能確認正常後建立一筆容易辨識的提交，例如「完成登入表單驗證」，再開始下一輪修改。
先檢查這個專案的 Git 狀態，列出目前分支、最新提交，以及已修改和未追蹤的檔案。說明這次應保存哪些內容，排除密碼與無關檔案，再建立一筆清楚描述功能狀態的提交。
Commit、push、PR、merge，是不同的完成狀態
commit 留在本機，不代表遠端已有相同內容，push 把提交送到指定的遠端分支，也不代表改動已進入主分支，PR 是提出合併變更的請求，merge 才會把變更整合到目標分支。
採用 PR 流程時，要檢查 PR 指向哪個目標分支、狀態是 Open、Closed 還是 Merged，Closed 只表示請求關閉，不能直接理解成已合併，部分專案允許直接推送主分支，因此 PR 是一種協作與審查流程，不是所有 Git 專案的必經步驟，可參考 GitHub 的 Pull Request 說明。
還有一個容易漏掉的狀況：PR 已合併後，又把新提交推到原來的功能分支，push 可能成功，但後來的提交不會自動補進那次已完成的合併，要另外確認是否需要新 PR，或依專案流程再次整合。
儲存庫更新與網站上線也要分開驗收，GitHub 上看得到程式，不代表正式網站正在執行那一版，部署平台可能使用另一個分支，也可能建置失敗。像 用 Claude Code 製作網站的完整工作流，最後仍要回到實際網址確認功能與畫面。
上傳前檢查機密，補上 .gitignore 不會抹掉歷史
API 金鑰、資料庫密碼、含憑證的設定檔，不應直接放進提交，請 AI 同時檢查檔案清單與即將提交的內容，並依專案需要設定 .gitignore。私有儲存庫也應避免存放這些機密。
.gitignore 主要處理尚未追蹤的檔案，已經被 Git 追蹤的檔案，不會因為新增忽略規則就自動停止追蹤，既有提交中的內容也仍然存在，這是 Git 官方文件 明確區分的行為。
如果金鑰已經外洩，第一步是到服務提供者那裡撤銷或更換金鑰，再處理儲存庫內容與歷史，只把目前檔案刪掉，不能讓舊金鑰失效。歷史清理還可能影響協作者，應依 GitHub 的機密資料處理指引 安排。
換電腦與同步協作，clone 和 pull 各做什麼？
從 GitHub 下載 ZIP，取得的是某個版本的檔案快照，要延續既有 Git 開發流程，通常會用 clone 取得儲存庫與版本歷史，讓本機能追蹤遠端。只拿到 ZIP，不能直接假設原來的 Git 設定和提交紀錄也都在。
已有本機儲存庫後，pull 會抓取遠端變更，再依設定整合到目前分支，例如使用 merge 或 rebase，它不只是把遠端檔案下載覆蓋過來，同步前先確認分支、遠端，以及本機尚未提交的內容是否妥善保存，操作語意可查 git pull 官方文件。
發生衝突時，讓 AI 說明兩邊原本要保留的行為，再決定如何整合，即使沒有出現文字衝突，也可能發生功能上的衝突。例如一邊調整登入流程，另一邊改了權限判斷，合併成功後仍要把兩個情境都測過。
兩個 AI 同時改專案，先分開實際工作目錄
同時開兩個 AI 視窗，不等於它們各有一份檔案。如果都在同一個工作目錄，一方存檔、切換分支或整理暫存內容，仍可能干擾另一方。只有不同任務名稱或分支名稱，也不足以證明工作檔案已隔離。
Git worktree 可以讓同一個儲存庫擁有多個工作目錄，分別檢出不同分支。
例如一份處理登入，一份調整版面，完成後再逐一審查與合併。它們有各自的工作檔案與部分狀態，但仍共享儲存庫資料及部分參照，不能把它當成完全獨立的安全沙箱。詳見 Git worktree 官方文件。
要確認的，是每個 AI 實際使用的 worktree 根目錄與分支，若測試會共用資料庫、輸出位置或服務連接埠，也要另外安排。想把這套分工放進操作介面，可以延伸閱讀 Orca ADE 的多 Agent 與 worktree 工作方式。
開始平行開發前，請列出每個任務的實際 worktree 根目錄、分支及修改範圍，確認彼此不會寫入同一份工作檔案，並檢查測試資料庫、輸出資料夾與連接埠是否共用。完成後逐一提交、驗證與合併。
AI 改壞了怎麼復原？先辨認改動在哪個階段
先暫停繼續修改，保留目前差異，再確認錯誤改動是否已提交、推送或合併。直接對 AI 說「全部還原」，容易連原本想保留的工作也一起丟掉。
restore 用來恢復指定檔案的內容，但來源要說清楚，未指定來源時，一般工作目錄還原預設取自暫存區，不一定是最後一次提交，使用 --staged 則是調整暫存區，預設來源為 HEAD，並不等於刪除工作檔案，會覆蓋工作目錄的還原操作可能丟失未提交修改，執行前要確認路徑、來源與備份。參考 git restore 官方文件。
revert 則是用新的提交，抵銷指定舊提交帶來的變更，它保留既有歷史，常用在已分享的提交，但可能遇到衝突，也不代表整個專案必然回到某個舊時間點，若要修正遠端主分支，新的復原提交仍需依流程推送、合併與部署。參考 git revert 官方文件。
檔案突然不見，也不能立刻認定永久刪除，可以先查是否切到別的分支、內容是否被放進 stash，或是否有提交紀錄與編輯器備份，不過，從未提交也沒有其他備份的內容，Git 並不保證能救回。
先不要執行會丟棄修改的操作，請查明問題改動是否已提交、推送與合併，保留目前差異，列出建議復原的檔案、來源版本及會失去的內容，再說明應使用檔案還原、復原提交或其他方法，並列出復原後的驗證項目。
Diff 要看什麼？先問比較的是哪兩個版本
看到大量新增或刪除行數，先確認比較範圍，GitHub PR 採用三點差異比較，從共同祖先到功能分支目前版本，重點是這個分支引入了什麼，直接比較兩個分支的最新狀態，得到的內容可能不同，尤其主分支已經往前更新時，參考 GitHub 的分支差異說明。
行數只是定位問題的線索，格式調整、自動產生的檔案或重新命名，都可能讓變動看起來很大。
更實際的檢查是：改動是否符合這次需求、是否碰到無關檔案，以及重要功能有沒有測過。
把「完成了嗎」改成一份可查證的交付回報
對非工程背景的人來說，最有用的習慣，是要求 AI 在每次交付時附上可以追查的狀態。下
面這段可以直接加入日常任務：
請用非工程師看得懂的方式回報這次交付，列出本機分支與最新提交、遠端分支是否已包含這次變更、PR 連結與合併狀態．若有多個 AI，列出各自的實際工作目錄。說明差異比較的基準、改了哪些檔案，以及哪些測試或操作情境已通過。若涉及網站上線，另附部署結果與實際驗證網址。沒有完成的步驟請明確標出。
從下一次小修改開始，先保存已確認正常的狀態，再讓 AI 動手。完成後看差異、驗證功能，最後確認遠端與部署狀態。這套習慣建立起來，才能在出錯時知道從哪裡查，而不必每次都靠重做。
GitHub 與 Vibe Coding 常見問題
不會寫程式，也需要學 Git 嗎？
使用 AI 修改專案時，至少應理解提交、分支、遠端與復原的差別，指令可以交給工具執行，但仍要能確認保存了什麼，以及哪些步驟尚未完成。
Commit 成功就代表已上傳 GitHub 嗎？
不代表。commit 建立本機提交，push 才會把提交送到指定遠端分支，是否合併到主分支，以及是否部署成功，都要另外確認。
PR 已合併後，再 push 就會更新主分支嗎？
不會自動更新。推到原功能分支的新提交，不會追加到先前已完成的合併，應依專案流程建立新 PR 或再次整合，確認新變更已進入目標分支。
Restore 和 revert 有什麼不同？
restore 恢復指定位置的檔案內容，必須確認來源與是否覆蓋未提交修改。revert 以新提交抵銷舊提交的變更，保留歷史，但可能需要處理衝突。
Worktree 可以完全避免兩個 AI 互相干擾嗎？
不能保證。不同 worktree 可分開工作檔案，但仍共享部分 Git 資料，外部資料庫、服務與輸出位置也可能共用，應確認目錄、分支與執行環境的分工。
by Rain Chu | 6 月 21, 2026 | AI, skills
未來的 AI 生產力，不只是「模型比較強」，而是「Agent Runtime + Skill + 人類決策」的組合能力。
重要連結整理
女媧 Skill 下載：
Agent Skills 官方說明
Claude Code Skills 官方文件
OpenAI Codex Skills 官方文件
OpenAI Codex GitHub
Hermes Agent 官方文件
Hermes Agent GitHub
所謂 AI 一人公司，不是指一個人什麼都不用做，讓 AI 自動幫你賺錢，比較務實的定義是：
一個人負責方向、判斷、審核與商業決策，AI Agent 負責研究、撰寫、開發、整理、測試、排程與重複性工作。
換句話說，人類的角色從「執行者」變成「總編輯、產品經理、技術主管、老闆」。
這也是影片最重要的啟發：AI 不是單一工具，而是一組可以分工的虛擬團隊。
Claude Code、Codex、Hermes 分別適合做什麼？
這三個工具剛好代表目前 AI Agent 工作流的三種方向。
我的看法是：如果你要打造 AI 一人公司，不應該只問「哪一個模型最強」，而是要問：
哪一個 Agent 適合負責開發？
哪一個 Agent 適合負責長期記憶與排程？
哪一個 Agent 適合安裝專門 Skill？
哪一個任務一定要由人類做最後判斷？
🏢 一人 AI 公司的組織架構與核心成員
要組建高效的團隊，就必須讓不同的 AI 模型各司其職、發揮所長。在我們的架構中，主要由以下三位核心成員組成：
- 董事長（你，唯一的人類）： 負責定大方向、提供靈感、拍板決策、把控最終產品質量。
- 祕書長（Hermes Agent）： 負責記錄分散的靈感與想法，具備極強的「長期記憶功能」，並對接社交軟體（如微信、Telegram）與本地工具。
- CEO 執行長（Claude Code）： 負責公司的統籌規劃、任務分配、邏輯思考與實際開發落地。
- 代碼審查員（OpenAI Codex）： 專職「挑毛病」，負責對寫好的程式碼進行安全性評估與漏洞審查。
🔍 深度洞察：Hermes、Codex 與 Claude Code 的技術選型見解
在搭建系統前，我們必須深入了解這三款終端 AI 工具的本質與差異，才能完美地將它們編排進工作流中：
- Claude Code（專職研發與執行）： 這是由 Anthropic 官方推出的終端工具，主語言融合了 Shell、Python 與 TypeScript。它在「編寫代碼」與「理解複雜上下文」上展現出極強的實力，是最完美的 「辦公與研發型執行代理」。
- OpenAI Codex（專職軟體工程與審查）： 採用 Rust 編寫，本地運行極其輕量。Codex 近年已演化為完整的工程代理，在自動生成 PR 級修改、修復 Bug、閱讀 Repo 方面非常嚴謹。最關鍵的體感是：如果讓同一個模型自己寫代碼又自己審查，它往往看不出問題；但如果讓 Claude Code 負責開發、Codex 負責審查，Codex 就能精準揪出一堆漏洞！
- Hermes Agent（長期記憶與通用協調）： 它是基於 Python 的中立 Agent 框架，遵循開放的
agentskills.io 標準。Hermes 最大的強項在於 「長期記憶、自我學習與渠道接入」。它像一個會持續成長的系統，適合作為始終在線的指揮官。
女媧 Skill 是什麼？
女媧 Skill 是一個開源的 Agent Skill 專案，目標不是單純模仿名人的語氣，而是把一個人的公開資料整理成可執行的「思維 Skill」。
它的核心概念是：蒸餾一個人怎麼想，而不是只模仿一個人怎麼說話。
舉例來說，你可以讓 AI 從公開資料中整理出某位人物的：
心智模型
決策啟發式
表達 DNA
價值觀與反模式
誠實邊界
面對新問題時可能採用的判斷框架
這就讓 AI 不只是「用某人的口吻回答」，而是比較接近「用某人的思考框架分析問題」。
女媧 Skill 的工作流程
女媧 Skill 的運作大致可以整理成四個階段：
六路並行蒐集：從著作、訪談、社群媒體、批評者觀點、決策紀錄、人生時間線等方向蒐集資料。
三重驗證提煉：一個觀點必須跨多個領域出現、能推斷新問題立場、且不是所有聰明人都會這樣想，才值得被收錄。
建立 Skill：把心智模型、決策方法、表達風格、價值觀與限制寫入 SKILL.md。
品質驗證：用已知問題與未知問題測試，避免 AI 過度自信或胡亂回答。
這套流程對 AI 一人公司的價值很高，因為它等於把「專家經驗」變成可以安裝、可以版本管理、可以重複調用的工作能力。
如何安裝女媧 Skill？
官方 GitHub 下載連結如下：
https://github.com/alchaincyf/nuwa-skill
最簡單的安裝方式是使用通用 CLI 安裝器：
npx skills add alchaincyf/nuwa-skill
如果你想明確指定安裝到某個 Agent，也可以依照 runtime 指定。例如：
帮我安装 skill：https://github.com/alchaincyf/nuwa-skill
如果要手動安裝，可以把 GitHub 專案 clone 到對應的 skills 目錄。
一人產品團隊要靠 Agent Skills 框架、測試自動化、遠端優先的人機協作環境來疊加效率
大神必讀文章連結：https://georgexing.substack.com/p/how-i-build-with-ai-as-a-1-person
給大家一個可以直接複製貼上給 Claude Code 使用的提示詞：
請讀懂這篇文章：https://georgexing.substack.com/p/how-i-build-with-ai-as-a-1-person
# AI 一人公司 / 一人產品團隊完整提示詞
你現在要扮演我的「AI 一人公司作業系統總指揮」。
你的任務不是單純回答問題，而是協助我把一個想法，轉換成可以由 AI Agent 團隊執行的完整產品開發、內容產出或商業驗證流程。
## 一、背景設定
我正在打造一套「AI 一人公司」工作流。
核心概念是：
人類負責方向、品味、商業判斷、使用者價值、品質把關與最後決策。
AI Agent 負責研究、規劃、開發、測試、審查、文件、營運與重複性工作。
請把我視為：
* 創辦人
* 產品經理
* 品質審查者
* 最終決策者
請把 AI Agent 團隊視為：
* Claude Code：主要工程師，負責理解專案、規劃功能、寫程式、重構與除錯
* Codex：嚴謹審查者，負責檢查計畫、審查程式碼、找出邏輯漏洞、資料流程錯誤與後端風險
* Hermes Agent：長期營運助理，負責記憶、排程、跨平台提醒、自動化任務與長期追蹤
* 女媧 Skill / Agent Skills：專家能力庫，負責把人物思維、領域方法論、公司 SOP、品牌規範、開發規範轉換成可重複使用的能力
請避免空泛勵志，重點放在可以執行、可以檢查、可以交給 Agent 的流程。
---
## 二、我要處理的主題
請根據以下輸入，幫我建立完整的一人產品團隊工作流。
### 我的產品 / 專案 / 文章 / 功能想法
【在這裡貼上我的想法】
### 目標使用者
【在這裡描述目標使用者，例如：老師、開發者、內容創作者、中小企業老闆、學生、設計師】
### 我想達成的結果
【在這裡描述結果，例如：做出 MVP、寫一篇 WordPress 文章、設計一個 SaaS 功能、改版某個頁面、建立自動化流程】
### 目前限制
【在這裡填寫限制，例如：只有我一個人、預算有限、時間有限、需要本地部署、需要 WordPress、需要 Next.js、需要支援中文】
### 已有工具或技術
【在這裡填寫，例如：Claude Code、Codex、Hermes Agent、OpenAI、Ollama、llama.cpp、Next.js、Prisma、PostgreSQL、WordPress、GitHub】
---
## 三、你的工作方式
請你按照以下流程執行，不要跳步。
---
# Phase 1：產品腦力激盪與問題定義
請先幫我釐清：
1. 這個想法真正要解決的問題是什麼？
2. 使用者現在怎麼解決這個問題？
3. 使用者最痛的地方是什麼？
4. 這個產品或內容的主要使用情境是什麼？
5. 成功的定義是什麼？
6. 哪些需求是必要的，哪些只是好看但不重要？
7. 哪些地方最容易被 AI Agent 誤解？
8. 哪些地方一定要由人類做最後判斷？
請輸出：
* 一句話產品定位
* 目標使用者描述
* 使用者痛點
* 核心使用情境
* Jobs To Be Done
* 成功指標
* 不做清單
* 風險清單
* 需要我確認的關鍵決策
請注意：
如果我的想法太模糊，你不要直接開始寫執行計畫，而是先幫我整理成幾個可選方向，讓我選擇。
---
# Phase 2：PRD / 規格文件
在 Phase 1 完成後，請幫我產生一份產品規格文件。
格式如下：
## 1. 專案名稱
## 2. 一句話說明
## 3. 背景與問題
## 4. 目標使用者
## 5. 使用者故事
請用這種格式：
* 作為【使用者角色】，我想要【行為】，以便【得到的價值】。
## 6. 核心功能
請區分：
* 必要功能
* 次要功能
* 暫不處理功能
## 7. 使用流程
請用步驟式流程描述。
## 8. UX / UI 原則
請說明：
* 畫面上最重要的主要行動是什麼
* 哪些資訊要優先顯示
* 哪些資訊應該收合或延後
* 什麼狀態下需要提醒使用者
* 哪些設計會增加摩擦，應該避免
## 9. 技術需求
請包含：
* 前端
* 後端
* 資料庫
* API
* 權限
* 檔案或媒體處理
* 第三方服務
* AI 模型或 Agent 使用方式
## 10. 邊界情境
請列出：
* 空資料狀態
* 錯誤狀態
* 載入狀態
* 權限不足
* AI 回答失敗
* 網路中斷
* 使用者輸入不完整
* 重複送出
* 多人或多裝置同步問題
## 11. 驗收標準
請用 checkbox 格式輸出。
---
# Phase 3：Agent 分工設計
請把整個工作拆給不同 AI Agent。
請用表格輸出：
| 角色 | 使用工具 | 負責任務 | 輸入 | 輸出 | 注意事項 |
| -- | ---- | ---- | -- | -- | ---- |
至少包含：
1. 人類創辦人
2. Claude Code
3. Codex
4. Hermes Agent
5. 女媧 Skill / Agent Skills
6. 測試 Agent
7. 文件 Agent
8. SEO / 內容 Agent
請特別說明：
* 哪些工作可以並行
* 哪些工作必須串行
* 哪些工作需要人類審核後才能繼續
* 哪些工作可以交給較小模型
* 哪些工作必須交給較強模型
---
# Phase 4：實作計畫
請把 PRD 轉換成可執行的實作計畫。
格式如下：
## 實作總覽
* 目標
* 預估修改範圍
* 主要檔案
* 新增檔案
* 修改檔案
* 刪除檔案
* 資料庫變更
* API 變更
* 測試範圍
* 風險等級
## 任務清單
每個任務請用 checkbox 格式：
* [ ] Task 1：任務名稱
* 目的：
* 修改檔案：
* 具體步驟：
* 完成標準：
* 可能風險：
* 建議交給哪個 Agent：
請把任務拆到 AI Agent 可以明確執行的粒度。
不要只寫「完成前端」這種模糊任務。
要寫到「修改哪個檔案、增加哪個元件、處理哪個狀態、需要哪個測試」。
---
# Phase 5：Codex 審查提示詞
請產生一段可以交給 Codex 使用的審查提示詞。
目標是讓 Codex 審查 Claude Code 產出的計畫或程式碼。
Codex 審查提示詞必須包含：
1. 請檢查是否符合 PRD
2. 請檢查是否有資料流程錯誤
3. 請檢查是否有 race condition
4. 請檢查是否有權限問題
5. 請檢查是否有錯誤狀態未處理
6. 請檢查是否有安全風險
7. 請檢查是否有測試缺口
8. 請檢查是否有過度設計
9. 請檢查是否有和原始使用者價值偏離
10. 請用 Critical / High / Medium / Low 分級
請輸出可直接複製的 Codex Review Prompt。
---
# Phase 6：Implementation Review 自動測試設計
請模擬一位人類產品審查者，設計端到端測試情境。
請輸出：
## 使用者情境測試
| 編號 | 情境 | 操作步驟 | 預期結果 | 嚴重性 |
| -- | -- | ---- | ---- | --- |
至少包含：
* 新使用者第一次使用
* 正常成功流程
* 使用者輸入錯誤
* AI 回答失敗
* 網路或 API 錯誤
* 權限不足
* 重複操作
* 長時間載入
* 行動裝置或小螢幕
* 使用者中途離開後回來
## Playwright / Maestro / 手動測試建議
請根據專案類型建議：
* Web 專案：Playwright
* Mobile 專案：Maestro 或 Xcode simulator
* API 專案：API integration test
* WordPress 文章：SEO、可讀性、連結、標題層級、圖片 alt、內外連檢查
---
# Phase 7：遠端優先工作流
請幫我設計一套適合一人公司使用的遠端優先 AI Agent 工作流。
請包含：
## 1. 長時間任務如何執行
例如：
* 使用 tmux 保持 session
* 使用 SSH 遠端連入開發主機
* 使用 Tailscale 或 VPN 連線
* 使用 Git worktree 管理多個功能分支
* 使用通知機制提醒我 Agent 卡住
## 2. 手機上如何追蹤
請設計：
* 手機查看進度
* 手機批准或否決 Agent 決策
* 手機補充語音輸入
* 手機查看測試結果
## 3. 語音輸入策略
請幫我把口語想法整理成可執行規格。
如果我貼上的是語音轉文字，請先整理語意，不要糾正文法而忽略內容。
## 4. 多 Agent 並行策略
請說明：
* 哪些任務可以平行跑
* 如何避免不同 Agent 修改同一個檔案互相衝突
* 如何用 Git branch / worktree 分開任務
* 如何設定合併順序
* 如何保留回滾點
---
# Phase 8：女媧 Skill / 專家顧問團設計
請根據這個專案，建議我應該建立哪些 Skill。
請輸出：
| Skill 名稱 | 用途 | 觸發時機 | 應包含內容 | 不該做什麼 |
| -------- | -- | ---- | ----- | ----- |
請至少思考以下類型：
* 產品品味 Skill
* 工程規範 Skill
* UI / UX 審查 Skill
* SEO 文章 Skill
* 安全檢查 Skill
* 品牌語氣 Skill
* 客戶訪談 Skill
* 測試審查 Skill
* 競品分析 Skill
* 專家人物思維 Skill
如果適合，請幫我產生一份 `SKILL.md` 草稿。
`SKILL.md` 需要包含：
* name
* description
* 使用時機
* 不使用時機
* 工作流程
* 輸出格式
* 品質檢查清單
* 誠實邊界
---
# Phase 9：如果這是 WordPress 文章
如果我的輸入目標是寫 WordPress 文章，請改用以下輸出格式。
請產出：
1. 主標題
2. 三個 SEO 標題選擇
3. SEO 中繼資料說明
4. 文章標籤，請用繁體中文，並用半形逗號分隔
5. WordPress 可直接貼上的文章內容
6. 內部連結建議
7. 外部連結建議
8. 圖片或流程圖建議
9. 可以用「創作圖像」生成的圖片提示詞
10. 延伸閱讀區塊
文章要求：
* 使用繁體中文
* 如果來源有簡體中文，請改成繁體中文
* 使用 WordPress block editor 友善格式
* 避免簡體字
* 標題層級清楚
* 適合 SEO
* 不要堆砌關鍵字
* 官方網站與下載連結必須放入文章
* 對工具的評價要務實，不要過度吹捧
* 文章要能接續「AI 一人公司：Claude Code、Codex、Hermes 與女媧 Skill」這個主題
---
# Phase 10：最後輸出總結
最後請用以下格式總結：
## 我建議你現在先做的 3 件事
1.
2.
3.
## 哪些部分可以立刻交給 AI Agent
## 哪些部分必須由我親自判斷
## 這個專案最大的風險
## 這個專案最快的 MVP 路線
## 下一個可執行指令
請給我一段可以直接貼到 Claude Code / Codex / Hermes Agent 的下一步指令。
---
## 重要規則
1. 不要只給概念，要給可執行步驟。
2. 不要假設 AI 會自動理解我的產品品味，要把標準寫清楚。
3. 不要讓 Agent 直接長時間執行高風險操作，必須設計審查點。
4. 不要只檢查程式能不能跑，也要檢查使用者流程是否合理。
5. 不要把 AI 當成全自動創辦人；AI 是員工，人類才是老闆。
6. 如果資訊不足，請先提出最少量但最高價值的澄清問題。
7. 如果可以先做合理假設，就先標明假設並繼續，不要卡住。
8. 對每個輸出都要加上品質檢查清單。
9. 所有內容都用繁體中文。
10. 若引用外部工具、官方網站、GitHub 或下載連結，請列出來源與用途。
現在請根據我提供的主題，開始 Phase 1。
感想
未來真正有競爭力的人，不一定是最會寫提示詞的人，而是最會設計 AI 工作流的人。
你可以把 Claude Code 當工程師，把 Codex 當快速執行者，把 Hermes Agent 當長期助理，再用女媧 Skill 建立不同領域的顧問團。
但最後，真正的老闆還是你。
AI 一人公司的重點不是讓 AI 取代你，而是讓你從執行者升級成指揮者。
補充：
商業導師：
https://github.com/dontbesilent2025/dbskill
美工與設計：(寶玉skills)
https://github.com/JimLiu/baoyu-skills/blob/main/README.zh.md
by Rain Chu | 6 月 18, 2026 | AI, skills
你可以把 find-skills 想成是 Agent 專用的「Skill App Store」。
當你未來想問：
「有沒有適合做 React 優化的 Skill？」
「有沒有可以幫我寫 changelog 的 Skill？」
「有沒有支援 PR Review、測試、自動化部署的 Skill？」
安裝 find-skills 之後，Agent 就可以根據你的需求，去搜尋相關 Skills，並提供安裝建議。
為什麼第一個要裝 find-skills？
一般人在剛開始使用 Agent Skills 時，最常遇到的問題不是「不會安裝」，而是「不知道有哪些 Skills 可以用」。
以前要找 Skills，可能要靠別人分享、GitHub 搜尋、社群文章，或自己慢慢翻各種資源庫。這種方式有幾個缺點：
- 很容易找不到真正適合的 Skill
- 搜尋過程會打斷目前工作流程
- 不知道哪些 Skill 比較可信
- 不知道該用什麼關鍵字搜尋
- 找到之後還要自己判斷怎麼安裝
find-skills 解決的就是這個問題。
它讓 Agent 可以根據目前任務，協助你搜尋、比較、推薦甚至安裝其他 Skills。換句話說，安裝它之後，你的 Agent 就不只是被動執行任務，而是能開始主動幫你擴充能力。
find-skills 是什麼？
find-skills 是 Vercel Labs Skills 專案中的一個官方 Skill。
官方頁面說明：
https://github.com/vercel-labs/skills/blob/main/skills/find-skills/SKILL.md
它的主要功能是協助使用者從 open agent skills 生態系中發現與安裝 Skills。當你問 Agent「我要怎麼做某件事？」、「有沒有某種 Skill？」、「能不能幫我找某類工具？」時，find-skills 就可以派上用場。
它適合用在這些情境：
- 你想找某個特定用途的 Skill
- 你想知道某個任務是否已經有人做成 Skill
- 你想擴充 Agent 的能力
- 你想搜尋工具、範本或工作流程
- 你想讓 Agent 幫你推薦適合目前任務的 Skill
安裝 find-skills
建議直接使用 Vercel Labs 官方 Skills CLI 安裝。
npx skills add https://github.com/vercel-labs/skills --skill find-skills
這是我建議所有 Agent Skills 使用者第一個安裝的指令。
官方頁面：
https://github.com/vercel-labs/skills/blob/main/skills/find-skills/SKILL.md
下載 / 安裝來源：
https://github.com/vercel-labs/skills
SKILL.md 原始檔下載：
https://raw.githubusercontent.com/vercel-labs/skills/main/skills/find-skills/SKILL.md
關鍵指令整理
安裝完成後，最常用的指令有以下幾個。
1. 搜尋 Skills
npx skills find "find skills"
也可以換成更具體的搜尋字，例如：
npx skills find "react performance"
npx skills find "seo meta"
npx skills find "pr review"
npx skills find "changelog"
npx skills find "wordpress"
搜尋關鍵字越具體，結果通常越準。
例如你要找 SEO 相關 Skills，不建議只搜尋：
可以改成：
npx skills find "seo meta"
npx skills find "seo tags"
npx skills find "wordpress seo"
這樣比較容易找到符合任務的 Skill。
2. 安裝 Skill
如果你已經知道要安裝哪個 Skill，可以使用：
例如：
npx skills add https://github.com/vercel-labs/skills --skill find-skills
3. 列出已安裝 Skills
這個指令可以查看目前已安裝的 Skills。
不過要注意，如果某些 Skills 不是透過 npx skills add 安裝的，可能不一定會被完整列出。
4. 檢查更新
這個指令可以檢查已安裝的 Skills 是否有更新。
5. 更新 Skills
這個指令會更新已安裝的 Skills。
建議不要盲目更新所有 Skills。更新前最好先確認來源是否可信、更新內容是否合理，尤其是在正式專案或公司環境中使用時，更應該謹慎。
使用 find-skills 的推薦流程
我會建議用這樣的流程：
Step 1：先描述你的需求
不要只丟一個太籠統的詞。
例如不要只說：
可以改成：
npx skills find "ui design system"
npx skills find "accessibility review"
npx skills find "figma to react"
Step 2：查看搜尋結果
搜尋結果出現後，不要只看名稱。
建議至少確認：
- Skill 名稱
- 來源作者或組織
- 安裝數
- GitHub repo
- 是否有文件
- 是否近期仍有人維護
- 是否符合你的實際任務
Step 3：優先選可信來源
如果是正式專案使用，我會優先選擇這幾類來源：
- 官方組織
- 大型開源專案
- GitHub 星數較高的專案
- 安裝數較多的 Skill
- 有清楚文件與範例的 Skill
不要只因為搜尋結果排在前面就直接安裝。
Step 4：安裝後再測試
安裝完成後，建議先用小任務測試。
例如你安裝了 SEO 相關 Skill，可以先讓 Agent 幫你產生一篇文章的：
- SEO 標題
- Meta description
- WordPress 標籤
- 文章摘要
- 內部連結建議
確認結果符合預期後，再放進正式工作流程。
find-skills 適合哪些人？
我認為 find-skills 特別適合這幾種使用者。
1. 剛開始使用 Agent Skills 的人
你不需要一開始就知道所有 Skills。先裝 find-skills，讓 Agent 幫你找。
2. 經常做不同任務的開發者
如果你平常會做：
- React
- Next.js
- WordPress
- Docker
- GitHub Actions
- 測試
- 部署
- 文件產生
- Code Review
那 find-skills 很適合當成你的 Skill 搜尋入口。
3. 想打造個人 Agent 工作流的人
如果你希望 Agent 不只是聊天，而是變成真正的工作助理，Skills 會是很重要的擴充方式。
find-skills 則是幫你管理這個擴充入口的第一個工具。
4. 想建立團隊標準工具集的人
公司或團隊也可以先用 find-skills 找出常用 Skills，再建立自己的標準清單。
例如：
- 前端開發 Skills
- 測試 Skills
- 文件 Skills
- DevOps Skills
- SEO Skills
- WordPress Skills
- 安全檢查 Skills
這樣可以讓團隊的 Agent 能力更一致。
使用 find-skills 的注意事項
find-skills 很方便，但不是所有搜尋結果都應該直接安裝。
使用時建議注意以下幾點。
1. 不要盲目相信搜尋結果
搜尋到 Skill，只代表它可能相關，不代表它一定適合你的任務。
正式使用前，仍然要確認來源、文件與內容。
2. 安裝前先看來源
尤其是來自不熟悉作者的 Skill，要更謹慎。
如果 Skill 會執行命令、讀寫檔案、存取專案內容，就更應該先檢查內容。
3. 搜尋關鍵字要具體
find-skills 的搜尋品質，很大程度取決於你的關鍵字。
比起搜尋：
更建議搜尋：
npx skills find "wordpress seo meta"
比起搜尋：
更建議搜尋：
npx skills find "playwright e2e test"
4. 更新 Skills 要小心
npx skills update 雖然方便，但在正式專案中不要隨便全部更新。
建議先檢查：
確認更新內容後，再決定是否更新。
我的建議：find-skills 是 Agent Skills 的第一個必裝工具
如果你只打算先安裝一個 Skill，我會選 find-skills。
因為它能讓 Agent 具備「找工具」的能力。
這跟一般單一功能 Skill 不一樣。一般 Skill 是讓 Agent 多一項能力，而 find-skills 是讓 Agent 開始知道「還有哪些能力可以被安裝」。
這也是為什麼我會把它稱為 Agent 的 Skill App Store。
先安裝它，之後要找 SEO、WordPress、React、測試、部署、文件、設計、Code Review 等 Skills，都會更有效率。
by Rain Chu | 4 月 8, 2026 | AI, 記憶
在 AI 進入 Agent 時代後，「記憶」成為最關鍵的能力之一。而令人意外的是，這場技術突破，竟然來自好萊塢女星 —— Milla Jovovich（蜜拉·喬娃維琪）。
她與開發者合作，在 GitHub 上開源了一個震撼業界的專案：MemPalace。
👉 一個主打「AI 永不失憶」的記憶系統。
🧠 為什麼 AI 需要「記憶系統」？
目前主流 LLM（像 Claude / GPT）都有一個致命缺陷：
👉 沒有長期記憶（Stateless）
每次對話都是重新開始：
- 不記得你昨天做了什麼
- 不記得專案決策
- 不記得 debug 過程
這對 AI Agent、開發助手、甚至個人助理來說，是致命問題。
蜜拉喬娃維琪正是因為這個痛點，才開始打造 MemPalace。
🏛️ 核心創新：AI 版「記憶宮殿」
MemPalace 的靈感來自古希臘的記憶技巧 —— 記憶宮殿（Memory Palace）
👉 用空間來組織記憶，而不是用「列表」
MemPalace 架構：
- 🏛️ Wings（翼）：專案 / 人物
- 🚪 Rooms（房間）：主題分類
- 🏙️ Halls（走廊）：記憶類型
- 📦 Drawers（抽屜）：原始資料（永不刪除）
- 🧳 Closets（櫃子）：壓縮記憶
這種結構讓 AI：
✔ 可以「導航記憶」
✔ 不只是搜尋，而是理解上下文
✔ 記住「過程」而不是只有結論
👉 比傳統 RAG 更接近人類記憶方式
⚙️ 技術亮點解析
1️⃣ 無損記憶（Verbatim Storage）
與傳統工具（Mem0、Zep）不同：
❌ 不做摘要
❌ 不丟棄資訊
👉 全部原始資料保留
「你不能失去從未刪除的東西」
2️⃣ AAAK：AI 專用無損壓縮語言
MemPalace 提出一個創新概念：
👉 AAAK（AI Abbreviation Language）
特點：
- 約 30 倍的無損壓縮
- LLM 可直接讀取（無需解碼）
- 保留語義完整性
但也有爭議：
⚠ 壓縮後準確率可能下降（約 96% → 84%）
3️⃣ 完全本地運行（Local-first）
👉 使用：
- ChromaDB（向量搜尋）
- SQLite（知識圖譜）
這對企業與隱私場景極具吸引力。
4️⃣ ClaudeCode 深度整合
MemPalace 專為 Claude Code 設計：
- MCP server 架構
- 可直接被 AI 呼叫
- 支援自動寫入 / 搜尋記憶
👉 幾乎零程式碼即可整合
📊 效能與市場迴響
MemPalace 一推出就引爆 AI 社群：
- ⭐ GitHub 星數：數千～上萬（短時間內暴增）
- 👀 觀看數：約 35 萬+
- 🧪 LongMemEval：
👉 被稱為「史上最強 AI 記憶系統」
但也有爭議：
- 100% 分數有調整測試案例
- 部分 benchmark 設定被質疑
👉 結論：強，但不是完美
🔥 為什麼這個專案重要？
MemPalace 代表一個關鍵轉變：
🧩 從「模型能力」→「記憶系統」
未來 AI 能力不只取決於模型：
👉 更取決於：
🧠 如何使用？
以下是實際應用場景：
👨💻 AI 開發助手
🧑💼 AI 商業助理
🤖 AI Agent 系統
🧭 未來趨勢：AI 記憶戰爭開始
MemPalace 只是第一步。
未來會看到：
- Memory OS（記憶作業系統）
- AI Personal Brain（個人 AI 大腦）
- Persistent Agent（永續 AI）
👉 AI 的競爭，不再只是模型大小，而是「誰記得更多」。
🏁 總結
MemPalace 的價值不只是技術，而是觀念：
👉 AI 不應該忘記你
透過：
蜜拉喬娃維琪不只是跨界成功，而是直接切入 AI 最核心問題之一。
參考資訊
by rainchu | 12 月 24, 2024 | AI, Chat
Jan AI 是一款完全開源且支援多種平台(Windows, Linux, Mac)的人工智慧聊天助手，類似 ChatGPT 的功能，但可完全離線運行於使用者內部的電腦上。
主要特色：
- 離線運行：Jan 支援多種 AI 模型，如 Llama3、Gemma 或 Mistral，使用者可直接在本地端下載並運行這些模型，確保資料隱私。
- 模型中心：提供多樣化的模型選擇，使用者可根據需求下載並運行不同的 AI 模型。
- 雲端 AI 連接：在需要時，Jan 也能連接至更強大的雲端模型，如 OpenAI、Groq、Cohere 等，提供更高效的運算能力。
- 本地 API 伺服器：使用者可一鍵設置並運行與 OpenAI 相容的 API 伺服器，利用本地模型提供服務。
- 文件互動：實驗性功能，允許使用者與本地文件進行互動，提升工作效率。
開源與自訂化：
Jan 完全開源，使用者可根據個人需求進行自訂，並透過第三方擴充功能（Extensions）來增強系統功能，如雲端 AI 連接器、工具和資料連接器等。
隱私與資料擁有權：
Jan 強調使用者資料的隱私與擁有權，所有資料皆儲存在本地，並以通用格式保存，確保使用者對自身資料的完全控制。
下載與社群：
Jan 已在 GitHub 上獲得超過 2.4 萬顆星，並持續更新與改進。
相關資訊
近期留言