# Personal Workbench Cockpit

> 設計、建立、延續、改版或教學個人工作台、AI 駕駛艙、工作控制台、Dashboard、Personal OS、工作管理系統或營運控制台時使用。當使用者用自然語言說工作台不好用、想調整、想加功能、想重新整理，或需求涉及網站、行動 App、PM 需求梳理、設計稿、可編輯高保真設計源文件、MCP、Agent 分工、D2C 設計到程式、工作項目、進度日誌、提醒、學習進度、導入導出、Obsidian／Markdown、AI 草稿、資料保存、備份、介面品質、grill-me 需求拷問或 Cloud Studio 部署時，務必先使用本 Skill；單一圖表、一次性報表或只詢問名詞時不使用。

- Skill: `kagenhsu/personal-workbench-cockpit` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add kagenhsu/personal-workbench-cockpit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kagenhsu/personal-workbench-cockpit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: kagenhsu (https://skillmd.com/u/kagenhsu)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kagenhsu/personal-workbench-cockpit

---


# 個人工作台／AI 駕駛艙建造師

本 Skill 整合控制台建造流程、個人工作管理規則與可驗收交付方式。目標是把工作台做成真的能記錄、追蹤、回顧與持續維護的工具，而不是只有靜態 Dashboard。

## 個人控制台的專用主機前提

如果要長期使用個人控制台或 CEO 控制台，應準備一台專門長時間運作控制台的小電腦或主機。Windows 或 Mac 都可以；重點是這台電腦專門負責控制台、資料與 AI 工作流程，不建議使用日常筆電，也不要把 NAS 當成主要運行主機。

- **小電腦／主機**：長時間運作控制台、保存必要資料，並提供 AI 介入工作流程的環境；Windows 或 Mac 都可以。
- **日常筆電**：可用來開發、設定與測試，但不建議作為控制台的長期運作主機。
- **NAS**：主要作為檔案與備份儲存設備，不把 NAS 當成控制台的主要運行主機。

規劃網站或系統時，先確認這台專用主機放置位置、長時間運作方式、作業系統、資料保存方式、遠端連線方式與備份策略。若尚未準備主機，先完成開發與測試規劃，不宣稱個人控制台已經可以長期運作。

## 先讀哪裡

若本 Skill 被觸發，先依任務讀取最少必要資料：

1. 有既有專案時，唯讀檢查 README、規劃文件、狀態檔、啟動入口、前端、API、資料儲存、測試與目前 Git 狀態。
2. 讀 `references/workbench-operating-rules.md`，取得個人工作台的資料真相、五個正式職務領域與安全邊界。
3. 需求涉及整合、同步或備份時，讀 `references/integration-map.md`。
4. 新建或重大改版時，讀 `references/intake-and-contract.md` 與 `references/architecture-decisions.md`。
5. 新建或重大改版要先讀 `assets/workbench-generation-brief.md`，完成生成前四項藍圖。
6. 需求是複雜設計或需要逐題釐清時，讀 `references/grill-me-companion.md`；需求涉及 UI 時，讀 `references/ui-ux-companion.md`。
7. 需求涉及網站或行動 App 的 PM、設計稿、MCP、Agent 分工或開發交接時，讀 `references/pm-design-mcp-pipeline.md`。
8. 需求涉及學習進度保存、導入或導出時，讀 `references/learning-progress.md` 與 `assets/learning-progress-template.md`。
9. 需求涉及網站部署時，讀 `references/cloud-studio-deployment.md`；實際供應商未確認前，不自行假設平台。
10. 驗收前讀 `references/acceptance-checklists.md`；持續改版時讀 `references/evolution-and-teaching.md`。

不要一次載入所有參考文件。只讀本次任務需要的文件。

## 自然語言入口與痛點探索

使用者不需要記住 Skill 名稱、提示詞或固定格式。只要在工作台脈絡中說「這裡用起來不順」、「首頁太亂」、「想加個提醒」或「幫我調整一下」，就先判斷為工作台探索或持續修改需求。

先判斷需求類型：新建、重大改版、新增功能、細部調整、資料流程調整或明確錯誤。除明確錯誤外，不要直接猜技術解法或修改程式；先把使用者的話整理成一個待確認的痛點。

痛點探索規則：

- 每次只問一個最能改變方向的問題。
- 用白話提供 2～4 個選項，並保留「其他」自由描述。
- 優先問要改善的結果，不先問資料庫、框架、API 或頁面元件。
- 依情境挑選選項，不把所有候選痛點一次塞給使用者。
- 常見痛點包含：找不到資料、不知道最重要的工作、進度／阻塞／等待不清楚、忘記追蹤、首頁資訊太多、想看成果回顧、想整合資料來源。

痛點確認後，再問一題使用時機或使用結果，接著提出 2～3 個方案，說明各自解決的痛點、使用方式、優點、限制、修改範圍與驗收方式。使用者選定方案前，不進入產品程式、資料模型、正式 Vault 或部署修改。

當需求包含新建工作台、重大流程設計、資料模型、導入導出、部署或使用者尚未想清楚的多個分支時，搭配已安裝的 `grill-me` Skill 逐題拷問；每次只問一題，先問會改變結果的決策，直到目標、範圍、流程、資料、驗收與風險能共同理解。細部修改與明確錯誤不啟動完整拷問。

明確錯誤（例如「按鈕按了沒反應」）直接進入診斷；若無法判斷是錯誤還是使用摩擦，只問一題確認「功能沒有作用」或「功能可以用但不順」即可。

## 生成前四項工作台藍圖

新建或重大改版在產生畫面、提示詞、原型或程式前，必須先寫清楚並讓使用者確認四項：

1. **誰在用**：學校、職場、創業、創作或其他明確使用者與情境。
2. **每天反覆處理什麼**：課程項目、工作項目、專案項目、選題或其他反覆處理的對象。
3. **事情怎麼運作**：從紀錄／收件、安排／拆解、執行，到完成、發布或通知的流程。
4. **最後要看到什麼**：進度、風險、阻塞、通知結果、數據、成果或復盤。

通用流程優先整理為：

```text
靈感 → 腳本／任務 → 發布／通知 → 數據 → 復盤
```

「腳本」依領域解釋為課程計畫、工作任務、專案步驟或內容腳本，不固定指程式碼。四項中有任何一項不清楚時，逐題用 2～4 個白話選項確認；四項與痛點尚未確認前，不生成只有幾張漂亮卡片的 Dashboard。

若使用者要求長期可訪問的網址或行動 App，藍圖還必須記錄保存位置、跨裝置方式、備份／恢復、登入／權限與部署方式。能開啟網址或安裝 App 不等於流程、資料與持久化已完成。

## 介面品質搭配：impeccable

介面需求在痛點與方案確認後，搭配已安裝的 `impeccable` Skill 做設計方向、介面檢查、可用性修正與收尾品質；新頁面先走 context／playbook／現有視覺真相檢查，修改前讀 craft-floor，完成後做一次批次桌面與手機檢查。`ui-ux-pro-max` 負責設計系統與 UX 規則，`impeccable` 負責反模式檢查、視覺層級、細節打磨與瀏覽器實際迭代，兩者不可互相取代。

若 `impeccable` 在目前執行環境不可用，改用 `ui-ux-pro-max` 與本 Skill 的驗收規則，並明確標記未使用 `impeccable`；不可宣稱已完成其檢查。

## 駕駛艙四個核心功能：推、看、決、令

生成前四項藍圖回答「為誰做、處理什麼、流程怎麼跑、最後看什麼」；本節定義工作台或駕駛艙每天如何運轉。新建駕駛艙或宣稱具備個人控制能力時，必須逐項說明以下四個功能；若本版不做，明確標記為不在範圍：

1. **推**：主動推送今日關鍵事實，例如最重要工作、逾期、異常、風險、等待與新數據。
2. **看**：整合工作、專案或選題的全局狀況，讓使用者看到目前階段、下一步、阻塞與變化，不只是幾張統計卡片。
3. **決**：根據資料提供優先順序、判斷依據、2～3 個行動方案與可能影響，保留使用者對正式決策的確認權。
4. **令**：把已確認的決策拆成任務、時間、提醒或後續紀錄，追蹤執行結果並回寫數據；AI 不可未經確認自行發布、通知、付款或對外執行。

每個功能都要寫清楚「觸發條件、資料來源、使用者看到什麼、可以做什麼、完成後留下什麼紀錄」。預設工作閉環為：

```text
靈感 → 腳本／任務 → 發布／通知 → 數據 → 復盤
                 ↑                    ↓
                 └──── 推／看／決／令 ────┘
```

若只有 UI 卡片，沒有可操作的下一步、正式資料來源、任務追蹤或結果回寫，不得宣稱已完成駕駛艙流程。

## UI／UX 專用搭配

只有當需求會改變畫面外觀、資訊層級、互動方式、響應式行為、可用性或無障礙時，才搭配本機的 `ui-ux-pro-max` Skill。它是 UI 設計與檢查工具，不取代本 Skill 的痛點探索、資料安全或開發守門。

搭配順序固定為：

```text
痛點確認 → 方案選擇 → 讀取現有 UI → UI/UX 設計檢查 → 使用者核准 → 實作 → 畫面驗收
```

- 新頁面、重大版型或設計系統：先使用 UI Skill 的 design-system 流程，再提出 1～3 個版型方案。
- 細部 UI 修改：只查與本次問題相關的 UX、layout、accessibility、color 或 interaction 規則，不重做整套設計。
- 網頁專案：依實際 Web 技術棧調整 UI Skill 的建議；不可因 Skill 內含 React Native 範例，就把專案改成 React Native，也不可執行不適用的 stack 指令。
- 純後端、資料庫、檔案格式或明確功能錯誤：不因工作台有畫面就自動使用 UI Skill。
- UI Skill 產生的設計規則與搜尋結果只能存入目前專案的設計文件，不寫入正式 Vault，也不把第三方完整內容複製進本 Skill。

## PM、設計稿、MCP 與 Agent 交接

網站與行動 App 開發都遵循：

```text
PM Skill → 設計稿 → MCP → Agent 規劃設計 → 開發落地
```

先由 PM 與 `grill-me` 一起釐清使用者、反覆處理對象、流程、結果、P0 與驗收，再由設計稿把流程變成可編輯、可覆用、可協作的高保真體驗。設計核准後才盤點 MCP 的資料與工具能力，再依角色分派 Agent 規劃、設計、開發與 QA，最後以 D2C 與端到端流程落地驗收。

設計稿至少檢查 8 項：目標用戶、核心場景、頁面結構、大圖比例、卡片層級、顏色變量、字體層級、組件狀態。不可用單張 UI 圖片或截圖取代整套設計源文件。

MCP 只提供受控能力，不自動取得正式資料或外部動作權限。每個 MCP 要記錄用途、讀寫範圍、權限、成本、失敗行為與確認點；正式寫入、發布、通知、部署、刪除或付款仍需使用者確認。詳細規則見 `references/pm-design-mcp-pipeline.md`。

## 判斷工作模式

- **探索**：先確認痛點、使用情境與期望結果，提出 3～5 個方向或 2～3 個解決方案；未選定方向前停止，不開始開發。
- **新建**：完成痛點與方案確認後，先完成生成前四項藍圖，再從 P0 功能、資料真相、版型、部署與驗收條件開始。
- **延續**：先確認使用者實際看的入口、目前分支、已實作能力、資料來源與未提交修改，再決定最小改版；不可從頭假設。若只是「這裡不順」，先走痛點探索，不要求使用者重填格式。
- **細部修改**：先定位受影響的頁面、路由、資料模型、流程節點與測試，只提出最小變更；已知錯誤可直接診斷。
- **網站／行動 App 開發**：先完成 PM 契約與核准設計稿，再規劃 MCP 與 Agent 交接；未完成前只做規格、線框或本機草稿。
- **資料整理**：先區分正式資料、草稿、待分類與待確認，不把 AI 推測直接寫成正式紀錄。
- **學習進度**：使用 `LearningProgress` 保存目標、階段、完成項目、證據、阻塞、下一步與復盤；導入前預覽，導出保留版本與來源，不覆蓋未確認的既有進度。
- **網站部署**：先確認 Cloud Studio 的實際供應商、網站類型、資料保存、權限、成本與公開範圍；部署前完成本機驗收，部署後核對網址、重啟／登入、資料持久化與回滾方式。
- **教學**：只能以已完成且已驗證的能力為教材；把操作拆成可照做的小步驟。

同一請求可能同時包含延續與教學；先確認產品事實，再整理教學內容。

## 個人工作台的預設資料模型

除非現有專案已有明確且等價的模型，否則優先保留以下概念：

- **WorkItem**：一項可追蹤的工作，包含狀態、目前階段、下一步、追蹤時間與主職務。
- **WorkLog**：工作進度的追加紀錄；一項工作可有多筆，舊紀錄不可被新進度覆蓋。
- **Reminder**：由追蹤時間或明確規則產生的站內提醒。
- **Dashboard**：只呈現真實資料與可追溯來源，不使用固定示範數字冒充正式狀態。
- **Draft**：AI 或自動化產生的草稿；未經使用者確認不得寫入正式資料。

正式資料優先使用使用者指定的 Markdown／Obsidian Vault。若現有專案已定義其他正式資料來源，先記錄差異，不自行建立第二套真相。

## 五個正式職務領域

預設使用以下領域；舊資料缺少領域時標記「待分類」，不可依標題自行猜測：

1. 監控設備管理
2. 辦公室電腦相關設備
3. 公司系統開發與管理
4. 工地空拍影像紀錄
5. 網路數位行銷

工作表單採一個共用表單，加上主職務、相關職務、職務階段、預估分鐘、計畫日期與時段等欄位。辦公室值日工作與正式職務工作要能分開檢視。

## 開發前守門

在真正修改產品程式、設定、資料庫、正式 Vault、部署或外部服務前：

1. 若不是明確錯誤，先完成痛點探索、使用情境確認與方案選擇；自然語言不足時由 Skill 主動提供選項，不要求使用者記提示詞。
2. 再用短開發契約回述目標、P0 功能、資料真相、範圍與驗收方式。
3. UI 任務依「UI／UX 專用搭配」完成設計檢查；重大版型要先取得版型核准。
4. 網站或行動 App 若涉及 PM、設計稿、MCP 或 Agent，先完成對應交接文件與權限範圍，再進入實作。
5. 複雜需求依 `grill-me` Companion 逐題釐清；每次只問一個仍會改變結果的關鍵問題，已由專案證據確定的答案不要重問。
6. 若涉及學習進度，先確認匯入格式、版本、重複資料與覆蓋策略，再產生預覽。
7. 若涉及部署，先確認供應商與可見性；未確認前只做部署設計與本機驗收，不執行公開發布。
8. 檢查目前分支與未提交修改。既有修改視為使用者內容，不重置、不覆寫、不大範圍格式化。
9. 只改核准範圍內的檔案；若與既有修改重疊，先停下說明。

重大改版依序記錄：

```text
discovery-brief → option-selected → spec-approved → ui-approved
→ implementation-complete → verification-passed
```

細部 UI 修改可省略 `ui-approved`，明確錯誤修正可從診斷開始，但仍需記錄修改範圍與驗收證據。

若使用者已明確提供足夠需求並要求實作，不必為了技術名詞重新訪談，但仍要先回述短契約。

## 資料與 AI 安全邊界

- 正式 Obsidian／Markdown 寫入前，先使用暫存 Vault 或 mock 資料驗證。
- AI 預設只產生草稿、建議或變更預覽；使用者明確確認後才寫入正式資料。
- 不把密碼、Token、API Key、Vault 私密路徑、公司機密、個資、錄音與敏感逐字稿放入 Skill 或 GitHub 備份。
- 不把測試通過、服務啟動、登入成功或 `/login` 成功當成指定頁面與 UI 已驗收。
- 刪除、正式環境寫入、公開、付款、外部訊息、排程、GitHub push 與其他難以復原的動作，都要先取得明確確認。
- 不使用批量刪除；不為了方便而搬動、改名或重建使用者的 Vault。

## 驗收與回報

依風險執行適度驗證：

1. 語法、單元測試與 API 測試。
2. 重新整理後資料仍存在，且資料來源與預期一致。
3. 實際啟動指定服務並檢查使用者要求的路由；不要只檢查登入頁或根頁。
4. UI 任務要做實際桌面／手機畫面檢查；沒有做就標記「視覺驗收待確認」。
5. 檢查 `git status --short`，只回報本輪相關檔案與未解決事項。

回報使用繁體中文，先給結論，再列改了什麼、怎麼確認、仍待確認與下一步。不可把推測寫成已完成。

## 參考文件

- 個人工作台資料與安全規則：`references/workbench-operating-rules.md`
- 來源與整合範圍：`references/integration-map.md`
- 需求訪談與開發契約：`references/intake-and-contract.md`
- 架構決策：`references/architecture-decisions.md`
- UI／UX Pro Max 搭配：`references/ui-ux-companion.md`
- grill-me 需求拷問搭配：`references/grill-me-companion.md`
- impeccable 介面品質搭配：本機已安裝的 `impeccable` Skill，必要時讀其對應 playbook
- 學習進度保存與交換：`references/learning-progress.md`
- Cloud Studio 部署：`references/cloud-studio-deployment.md`
- PM、設計稿、MCP 與 Agent 開發流程：`references/pm-design-mcp-pipeline.md`
- 驗收：`references/acceptance-checklists.md`
- 持續演化：`references/evolution-and-teaching.md`
- 生成前四項藍圖：`assets/workbench-generation-brief.md`
- 駕駛艙四功能：推／看／決／令，並確認每項的資料、操作與結果紀錄