八大數據源之一 · 提問探索 → 解答沉澱 → 知識自增
## 快速修復方案
從 aiforall-deploy 複製正常的 memodata.html 回來重新製作：
### 步驟
1. **確認來源路徑**
- aiforall 專案路徑：`C:\Users\Administrator\WorkBuddy\aiforall-deploy`
2. **複製檔案**
```powershell
Copy-Item "C:\Users\Administrator\WorkBuddy\aiforall-deploy\memodata.html" "C:\Users\Administrator\WorkBuddy\workskm-deploy\memodata.html" -Force
```
3. **檢查並修復 CSS 語法錯誤**
- 檢查 `:root {` 是否有閉合 `}`
- 若缺失，添加 `}`
### 發現的問題
aiforall-deploy 的 memodata.html **也有相同的 CSS 語法錯誤**：
```css
/* 錯誤 */
--green-light: #e6d5e6;
* {
/* 正確 */
--green-light: #e6d5e6;
}
* {
```
### 修復內容
```css
/* 修復前 */
--green-light: #e6d5e6;
* {
/* 修復後 */
--green-light: #e6d5e6;
}
* {
```
### 部署
```bash
cd C:\Users\Administrator\WorkBuddy\workskm-deploy
npx wrangler pages deploy . --project-name=workskm --branch=main
```
### 結果
- ✅ 資源中心按鈕正常
- ✅ 數據載入正常（備忘 12 項、計畫 4 項、備份 4 項、日誌 7 項）## 問題確認
| 項目 | 說明 |
|:---|:---|
| **問題現象** | 頁面顯示「載入中」，面板數據都是 0 項 |
| **根因** | `loadData()` 函數會用 localStorage 覆蓋內嵌資料 |
| **觸發條件** | 瀏覽器之前有儲存過 localStorage 資料（即使是空的）|
| **影響頁面** | memodata.html、ideadata.html、pendingdata.html、errolearn.html |
## 問題代碼
```javascript
function loadData() {
const savedMemos = localStorage.getItem('workskm_memos');
// ...
if (savedMemos) memos = JSON.parse(savedMemos); // ← 只要有 localStorage 就覆蓋
// ...
}
```
如果瀏覽器的 localStorage 之前有儲存過空陣列或舊資料，就會覆蓋掉 HTML 中內嵌的 `memos[]`、`plans[]` 等資料，導致顯示 0 項。
## 修復方案
**方案 A：修改 loadData 邏輯（推薦）**
讓 `loadData()` 只在 localStorage 有**有效資料**時才覆蓋，否則使用內嵌預設資料。
**方案 B：清空 localStorage**
在瀏覽器開發者工具中執行：
```javascript
localStorage.clear();
```
**方案 C：移除 localStorage 邏輯**
如果不需要本地編輯功能，直接移除 `loadData()` 的 localStorage 讀取。
## answerch 關聯記錄
- #39：導航替換後 CSS 變量和 JS 函數殘留（涉及 localStorage 邏輯問題）
- #40：跨檔案 Badge 區同步問題## 一、問題確認 主公所言甚是。**對話中討論的待辦事項，確實不會自動出現在 pendingdata**。 ## 二、pendingdata 的數據流（單向） ``` ideatorich (toidea1-5) → concepts.json → pendingdata.html（只讀） ``` - ✅ 透過 ideatorich 記錄的構想 → 會進入 pendingdata - ❌ 對話中討論的待辦事項 → 不會自動進入 ## 三、現有系統對比 | 系統 | 輸入方式 | 數據流向 | 適用場景 | |:---|:---|:---|:---| | **pendingdata** | ideatorich (toidea1-5) | 單向（只讀） | 構想收集、創意管理 | | **PendingMemo** | 對話中 todo-driver 提取 | localStorage | 對話任務暫存 | | **tomemo/torecord** | 手動執行技能 | HTML/txt 檔案 | 問答備忘、工作記錄 | | **proj.txt** | tproj 技能寫入 | 文字檔案 | 專案追蹤 | ## 四、真實情況 目前的「待辦追蹤」是分散的： ``` 📌 構想類待辦 → pendingdata（來自 ideatorich） 📌 對話任務 → PendingMemo（localStorage，暫存） 📌 問答備忘 → tomemo → memodata/index.html 📌 專案追蹤 → proj.txt ``` ## 五、可能的優化方向 ### 方案 A：擴展 PendingMemo 定位 - 讓 PendingMemo 成為「對話待辦」的正式入口 - 提供「提升為 pendingdata」的通道（pendingmemo-promote） ### 方案 B：統一待辦入口 - 建立單一待辦數據源（如 todos.json） - pendingdata / PendingMemo / todo-driver 都讀取同一來源 ### 方案 C：維持現狀，強化流程 - 明確區分「構想待辦」（pendingdata）vs「對話任務」（PendingMemo） - 定期人工整理 PendingMemo → ideatorich → pendingdata
## 一、數據來源
**輸入端**：`data/concepts.json`
```javascript
// pendingdata.html L454
async function loadTodos() {
const response = await fetch('data/concepts.json');
const data = await response.json();
todos = data.concepts || [];
}
```
**完整數據流架構**：
```
┌─────────────────────────────────────────────────────────────┐
│ 輸入端（Source） │
├─────────────────────────────────────────────────────────────┤
│ 📁 data/concepts.json │
│ - ideatorich 系統寫入 │
│ - 六種情境構想採集統一數據源 │
└──────────────────────┬──────────────────────────────────────┘
│ fetch()
▼
┌─────────────────────────────────────────────────────────────┐
│ 處理層（Process） │
├─────────────────────────────────────────────────────────────┤
│ 📋 pendingdata.html │
│ - 過濾 status: pending/designing/inprogress │
│ - 按 priority 排序 │
│ - 渲染待辦卡片 │
└──────────────────────┬──────────────────────────────────────┘
│ 用戶互動
▼
┌─────────────────────────────────────────────────────────────┐
│ 輸出端（Storage） │
├─────────────────────────────────────────────────────────────┤
│ 💾 localStorage │
│ - 狀態變更暫存 │
│ - 下次載入時合併 │
└─────────────────────────────────────────────────────────────┘
```
## 二、數據結構
### concepts.json 頂層結構
```json
{
"metadata": {
"version": "2.0",
"schema": "concepts-unified",
"last_updated": "2026-04-19T12:25:00.000Z",
"total_count": 5,
"source_distribution": { /* 六種情境統計 */ },
"status_distribution": { /* 狀態統計 */ }
},
"concepts": [ /* 構想陣列 */ ]
}
```
### 單個 concept 結構
```json
{
"id": "IDEATION-20260419-484",
"title": "構想標題",
"description": "構想詳細描述",
"date": "2026-04-19",
"categories": ["#01 系統架構類"],
"priority": 2,
"status": "pending",
"type": "idea",
"source_type": "file_reference",
"source_detail": "overview-1.txt",
"report": { "classification": "", "paths": [], "suggestion": "" },
"links": { "related_ideas": [], "source_file": "overview-1.txt" },
"derive_control": { "auto_derive": true, "derive_route": "A" }
}
```
## 三、pendingdata 使用的關鍵欄位
| 欄位 | 說明 | 用途 |
|:---|:---|:---|
| `id` | 唯一識別碼 | 項目標識 |
| `title` | 標題 | 顯示名稱 |
| `description` | 描述 | 詳細內容 |
| `priority` | 優先級 1-10 | 排序依據（P1≥8, P2≥5, P3<5）|
| `status` | 狀態 | pending/designing/inprogress/done |
| `date` | 日期 | 時間標記 |
| `source_type` | 來源類型 | 六種情境標記 |
## 四、狀態流轉
```
pending → designing → inprogress → done
⬆️ │
└──────────── 可逆向切換 ─────────────┘
```
- **pending**：待處理
- **designing**：設計中
- **inprogress**：進行中
- **done**：已完成（pendingdata 不顯示）給 Todo-Driver（TED）設置新任務有三種方式： 方式一：新增固定任務到 pendingdata - 在 pendingdata 中新增固定任務項目 - 設定頻率（每日/每週/每月） - 描述任務內容與執行標準 方式二：在 todo-driver 日報中增加評分維度 - 在日報模板中新增評分項目 - 設定各維度權重與評分標準 - 量化追蹤執行狀況 方式三：建立自動化觸發器 - 文件修改後自動提示檢查 - 錯誤發生後自動提示記錄 - 條件觸發，無需手動添加
## 一、#161 原始目標 | 項目 | 內容 | |:---|:---| | **創建時間** | 2026-04-20 18:03 | | **優先級** | P1（原）/ P2（現在）| | **核心目標** | 找出跨 session 跨 space 找回記憶的方法和流程 | | **分析範圍** | workmemo/answerch/SOUL 等現有資源 | | **預期產出** | 全域核心記憶庫方案 | ## 二、現有跨 session 記憶架構 | 資源 | 用途 | 跨 session 能力 | |:---|:---|:---| | **MEMORY.md** | 長期記憶 | ✅ 持久化（由貞的主觀認知）| | **workmemo.txt** | 工作備忘 | ✅ 持久化（雙方共識）| | **answerch.txt** | 錯誤知識庫 | ✅ 持久化 | | **SOUL.md** | 身份定義 | ✅ 持久化 | | **IDENTITY.md** | 技能清單 | ✅ 持久化 | | **overview-X.txt** | 構想清單 | ✅ 持久化 | | **pendingdata.json** | 待辦清單 | ✅ 持久化 | | **每日記憶檔** | 自動日誌 | ✅ 持久化 | ## 三、由貞起動時的記憶讀取流程 ``` 1. 讀取 MEMORY.md（長期記憶） 2. 讀取今日/昨日每日記憶檔 3. 掃描 answerch 經驗庫 4. 檢查工作備忘、相關檔案 ``` ## 四、問答結論 | 問題 | 結論 | |:---|:---| | 現有架構是否足夠？ | ⚠️ 已有基礎機制，但可能分散 | | 具體痛點是什麼？ | ❓ 需主公確認 | | 是否需要新方案？ | ❓ 需定義缺口 | ## 五、下一步建議 1. **確認痛點**：具體是什麼場景會「失憶」？ 2. **評估缺口**：現有架構是否真的不夠用？ 3. **制定方案**：若需新方案，是整合現有資源？還是新增機制？
## 一、文件位置 | 項目 | 路徑 | |:---|:---| | **文件名** | `创意管理全流程32步-详细工作流程.html` | | **位置** | workskm-deploy/ | | **大小** | 36.41 KB | ## 二、實際步驟統計 | 項目 | 數量 | |:---|:---| | **聲稱步數** | S1-S32（32步）| | **實際步數** | S1-S21（21步）| | **空白缺口** | S22-S32（11步）| ## 三、已完成步驟（S1-S21） | Phase | 步驟 | 名稱 | 狀態 | |:---|:---|:---|:---| | Phase 1 | S1 | 明確創意定義及5種思想源 | ✅ | | Phase 1 | S2 | 搭建 overview 體系 | ✅ | | Phase 1 | S3 | 完善1001行業代碼表及Agent判斷規則 | ✅ | | Phase 1 | S4 | 制定卡片呈現及展開規範 | ✅ | | Phase 2 | S5 | 啟用5種輸入模式 | ✅ | | Phase 2 | S6 | 配置Agent對話捕獲及overview寫入機制 | ✅ | | Phase 2 | S7 | 完成創意採集→overview→卡片→報告閉環 | ✅ | | Phase 2 | S8 | 建立創意與PendingData聯動、todo-driver接管監督 | ✅ | | Phase 2 | S9 | 實現多維報表自動產出及存檔 | ✅ | | Phase 2 | S10 | 核心功能測試及問題修復 | ✅ | | Phase 3 | S11-S21 | 後續優化與部署步驟 | ✅ | ## 四、S22-S32 空白缺口 | 步驟 | 狀態 | |:---|:---| | S22 | ❌ 待補建 | | S23-S32 | ❌ 待補建（共10步）| ## 五、主公提到的問題確認 | 問題 | 實際狀態 | |:---|:---| | S2（素材獲取 SOP）| ✅ 已存在（搭建 overview 體系）| | S5（採集員指令系統）| ✅ 已存在（啟用5種輸入模式）| | S6-S32 大片空白 | ⚠️ 部分正確（S22-S32 共11步空白）| ## 六、下一步行動建議 P2 補建 S22-S32 步驟，可拆解為多個小任務逐步推進。
強制執行 toworkmemo 並回報序號的原因： 1. **執行紀律**：確保每個指令都被確實執行，不遺漏 2. **追蹤驗證**：透過序號可快速定位與查詢記錄內容 3. **責任歸屬**：明確記錄時間點，建立工作軌跡 4. **避免遺忘**：對話過程中可能有多個指令，回報確認防止遺漏 5. **一致性**：統一流程，不因內容重複而省略 執行標準： - 收到 toworkmemo 指令 → 立即寫入 workmemo.txt - 寫入完成 → 回報日期、時間、序號、內容摘要 - 即使內容與前筆類似 → 仍按指令重新寫入
主公強制規定：所有 toworkmemo 指令必須執行，不因內容重複而省略。 原因如下： 1. **指令即契約**：主公說出的每個指令都是明確要求，AI 必須執行 2. **時間戳記錄**：每個序號代表不同時間點的決策或狀態 3. **完整軌跡**：保留完整對話脈絡，便於日後回溯 4. **避免誤判**：AI 不應自行判斷「是否重複」，應完全遵從指令 5. **紀律養成**：建立「指令→執行→回報」的標準工作流程 執行原則： - 不判斷、不省略、不簡化 - 每個 toworkmemo 指令 = 一筆新記錄 - 回報格式：日期 | 時間 | 序號 | 內容
以 pendingdata 描述聯動分析為例： **發現過程**： 1. 掃描 103-PendingData數據來源關係圖與現況分析報告.html 2. 發現 T001-T010 描述有誤（與實際不符） 3. 比對原始資料與報告內容，確認錯誤位置 **修正步驟**： 1. 標記錯誤位置與正確內容 2. 修正描述文字 3. 重新生成報告 4. 部署更新到 workskm 5. 驗證修正結果 **預防機制**： - 建立「聯動分析」技能，自動掃描描述一致性 - 每次更新後執行四問：影響哪些檔案？哪些文字需同步？哪些數據需修正？哪些報告需調整？ - 將聯動檢查列入 TED 每日任務
聯動處理慣性保障方案分三層： 第一層：SOP 固化（立即可行） - 在每次執行 updatememo / toworkmemo 後，增加標準四問： ① 這個修改影響哪些檔案？ ② 哪些描述性文字需要同步更新？ ③ 哪些數據結構描述需要修正？ ④ 哪些報告文件需要聯動調整？ 第二層：自動化工具（中期建設） - 建立「聯動分析」技能，觸發詞：連動分析、聯動檢查、ripple-check - 功能：輸入關鍵詞 → 自動掃描全 workskm 專案 → 輸出需同步更新的檔案清單 → 主公確認後執行修改 第三層：經驗庫積累（長期習慣） - 在 answerch.txt 中增加「聯動踩坑」分類 - 記錄格式：修正 XX → 需同步檢查 YY 報告
聯動檢查列入 TED 工作任務的三個方案： 方案一：新增「聯動檢查」任務到 pendingdata - 在 pendingdata 中新增固定任務：【聯動】上下中左右多維度檢查 - 頻率：每日 - 描述：上位同步、下位部署、左位學習、右位固化、外位擴展 方案二：在 todo-driver 日報中增加「聯動維度」評分 - 在 TED 日報模板中增加五維評分（各10分，總分50分） 方案三：建立「聯動觸發器」自動化 - 任何文件修改後 自動提示 - 任何錯誤發生後 自動提示
直接影響：幾乎沒有。現代檔案系統（NTFS）對中文路徑的處理效率與英文無異，搜尋工具底層對 UTF-8 編碼已優化。 間接影響：可能有的情況—— 1. 編碼轉換開銷：若工具內部需要 ANSI/UTF-8 轉換 2. 字元長度：中文字元佔 3 bytes，路徑字串較長 3. 特定工具問題：某些舊版工具對非 ASCII 路徑支援不佳 結論：剛才『慢』的真正原因是過度設計、不必要地啟動 subagent、沒有先確認格式，而非中文路徑問題。
manifest.json 是技能清單的中央註冊表，用途包括： 1. 記錄所有技能的元數據：id、name、description、category、tags、version、author、created 2. 供 skills-list.html 讀取並生成可視化技能清單 3. 作為技能系統的權威來源，統一管理 114 個技能 4. 支援技能分類瀏覽、搜尋、統計分析 本次更新：新增 8 個自建技能，總數從 106 提升至 114。
根據「知識珍藏 · 我的第二大脑」設計規格書，五專案必備知識項目： 【方法論層 - 12項】 1. 知識索引哲學（只記位置不存原文件） 2. 統一管理公式（名稱+位置+標籤+備註） 3. 主動聯動思維（上下左右外） 4. 錯誤自循環流程 5. 創意管理 32 步框架 6. TED 待辦自迭代系統 7. 技能建立哲學 8. 專案定位三步驟 9. 三大資產類型（數位/實體/網路） 10. 構想優先級（T0/T1/T2/T3） 11. 待辦優先級（P0/P1/P2） 12. 五環健康度評分 【工具層 - 16項】 - 各專案 JSON 資料結構規範 - 操作流程卡片（toidoa/tomemo/todo-driver等） - 錯誤快速參考卡 - 命名與編碼規範 【基礎設施 - 6項】 - Cloudflare Pages 部署流程 - wrangler CLI 使用指南 - LocalStorage 資料持久化 - 專案定位三步驟（3→1→2） - env-setup 環境恢復 - JSON 資料格式規範
## 修復結果總覽 | # | 問題 | 修復內容 | 狀態 | |:---:|---|---|:---:| | 一 | 導航欄+Badge 區丟失、背景黑、SVG 不顯示 | CSS 變量全面替換 + 導航擴展 + 新增 badge-row | ✅ | | 二 | 列表項點擊跳到空白頁 | renderSection() 路由改為 backup-detail.html?... | ✅ | | 三 | 清單稀少且分類不足 | 從 index.html 提取 → 51 筆（36+13+2） | ✅ | ## 問題一詳解：導航欄+Badge CSS/HTML 重建 **根因**：memodata.html 使用了舊版紫色系 CSS 變量，導航只有 3 個按鈕（應 4 個），下拉選單只有 3 項（應 10 項），badge-row 區塊完全缺失。 **修復項目**： - `:root` 變量：從舊紫色系替換為全站統一深色系（--dark: #0a0a0f, --indigo: #6366f1, --green: #10b981） - 新增 7 個 `--nav-*` CSS 變量（與 knowbase.html 一致） - body padding-top：80px → 60px，背景從紫色漸變 → var(--dark) - 導航按鈕：3 個 → 完整 4 主按鈕 + 10 項下拉選單 - 新增 .badge-row 及三張 SVG 區塊（myaimarket/clawset/workskm） ## 問題二詳解：跳轉路由修正 **根因**：renderSection() 中卡片連結直接指向 .html 檔案，繞過了 backup-detail.html 詳情框架。 **修復後邏輯**：所有卡片連結改為 `backup-detail.html?id=&name=&file=&type=&date=` 格式，確保走統一詳情框架。 ## 問題三詳解：清單數據補全 | 分類 | 修復前 | 修復後 | |:---|:---:|:---:| | memos[] | 6 筆 | **36 筆** | | plans[] | 7 筆 | **13 筆** | | backups[] | 0 筆 | **2 筆** | | **合計** | **13 筆** | **51 筆** | 資料從 index.html 全部 60 個卡片提取，按標題關鍵字歸類。 ## 附帶完成 - **部署**：wrangler pages deploy 成功 → https://workskm.pages.dev/memodata.html - **answerch #52**：template.html 比 index.html 更安全的經驗記錄 - **統計同步**：answerch.txt 44 筆 / 第十一次整理 / 經驗 9 筆
三階段記憶橋接系統：
## Phase 1：建立全局索引（已完成）
- 掃描 170+ 工作空間，提取 36 個有內容的 MEMORY.md
- 按 5 大業務領域分類（WorkSKM/Wholistics/技能體系/由貞身份/其他）
- 寫入全局中樞 `~/.workbuddy/memory/MEMORY.md`
## Phase 2：建立 memory-bridge 技能 #117（已完成）
- `scan`：掃描所有空間更新全局索引
- `pull {關鍵字}`：拉取指定空間記憶到當前 session
- `sync`：同步當前空間重要記憶到全局
- 技能路徑：`~/.workbuddy/skills/memory-bridge/SKILL.md`
## Phase 3：強化 SOUL.md 起動流程（已完成）
- 在「起動思維指引」查詢順序新增 Step 0：全局空間索引
- 每次啟動先讀 `~/.workbuddy/memory/MEMORY.md`
- 匹配任務關鍵字 → 自動拉取相關空間記憶
- 換空間不再失憶
## 核心架構
```
全局 MEMORY.md（中樞）→ 所有空間共讀
↓ 橋接
空間 A MEMORY.md ↔ 空間 B MEMORY.md ↔ 空間 C MEMORY.md
```是的。正確流程是 tomemo（生成 HTML 到工作備忘/）→ 每個目標專案獨立執行 updatememo（複製到 deploy 目錄 + 更新 index.html 卡片 + 更新 memodata.html 陣列 + wrangler deploy 整站）。
## 核心原因
1. `wrangler pages deploy .` 上傳**整個目錄**，目標 deploy 目錄下必須有該 HTML 檔案
2. 單純 Copy-Item + upload 會跳過 index.html 卡片和 memodata.html 陣列更新
3. 結果：備忘清單上看到不到新項目（answerch #60 教訓）
## 多專案正確流程
```
tomemo（生成 HTML → 工作備忘/）
↓
updatememo aiforall（複製 HTML → aiforall-deploy/ → index 卡片 → deploy）
updatememo workskm（複製 HTML → workskm-deploy/ → index 卡片 → memodata → deploy）
```
## 三重防護機制（避免再犯）
- **方案 A**（技能層）：tomemo SKILL.md v1.2 加入「完成後強制提醒」區塊
- **方案 B**（技能層）：新建 `tomemo-deploy` #118 組合技能，一鍵完成全流程，支援多專案
- **方案 C**（身份層）：SOUL.md 新增「模式五」錯誤自我診斷——攔截 tomemo 後直接 upload 的行為
## 一鍵替代
`tomemo-deploy aiforall,workskm` = tomemo 生成 → 逐站 updatememo → 全部部署## 一、現況分析
| 系統 | TaskMemo | pendingcenter |
|:---|:---|:---|
| **定位** | 计划书索引 | 待办统一入口 |
| **數據來源** | workmemo.txt | pendingdata.json + workpending.json |
| **記錄類型** | 静态索引（计划书代号/名称/路径/摘要）| 动态任务（待办/创意/工作）|
| **狀態追蹤** | 無 | pending→designing→inprogress→done |
| **顯示方式** | 文字列表 | 三视图卡片 |
## 二、三種結合方案
### 方案 A：pendingcenter 新增「計劃書」標籤篩選
- 在 pendingcenter 增加「计划书」标签或视图
- TaskMemo 索引中的计划书（如 #226/#227/#228/#229）可通過連結跳轉
- 點擊計畫書名稱 → 打開實際 HTML 報告
### 方案 B：TaskMemo 索引關聯 pendingcenter 待辦
- 每個 TaskMemo 索引可關聯到對應的 pendingcenter 任務
- 例如：#229（M01-M11）→ pendingcenter 中顯示 11 項優先建設任務
- 狀態同步：pendingcenter 狀態變更 → TaskMemo 顯示「已啟動」
### 方案 C：双向联动（推薦）
- **TaskMemo → pendingcenter**：计划书中的任务清单自动写入 pendingcenter
- **pendingcenter → TaskMemo**：待办完成时自动更新关联计划书的进度
- 形成「计划制定 → 任务执行 → 成果沉淀」的闭环
## 三、推薦整合路徑
```
Step 1：在 pendingcenter 新增「計劃書」快捷入口
→ 跳轉至 TaskMemo 索引頁面
Step 2：TaskMemo 索引支持「轉化為待辦」
→ 選擇計劃書 → 一鍵生成 pendingcenter 任務
Step 3：pendingcenter 任務完成時
→ 自動更新關聯 TaskMemo 索引的進度狀態
```
## 四、短期可行方案（立即執行）
在 pendingcenter 頂部導航或側邊欄增加：
```
📋 計劃書索引
├── #226 WorkP实施计划
├── #227 八维度评估
├── #228 todo-driver优化
└── #229 章魚自媒體評估
```
點擊任一項目 → 打開對應 HTML 報告## 推薦方案：指令驅動 + 狀態流轉
```
主公說：「執行 P002,P007」
↓
由貞自動執行：
Step 1：讀取 workp.txt
Step 2：P002,P007 狀態 → inprogress（執行中）
Step 3：執行工作內容
Step 4：完成後 → P002,P007 狀態 → done（已執行）
Step 5：寫入 workmemo.txt（一筆完成記錄）
↓
主公得到：
✅ workp.txt 狀態已更新
✅ workmemo.txt 有執行記錄
```
## 方案對比
| 對比 | 方案A（程序化） | 方案B（指令式） |
|:---|:---|:---|
| 靈活性 | 低（流程固定） | 高（隨時可變） |
| 執行門檻 | 高（需先開發） | 低（直接說） |
| 複雜度 | 中（需設計程序） | 低（自然對話） |
| 適用場景 | 批量、規律性任務 | 單次、特殊性任務 |
## 觸發方式
**單項執行：**
```
執行 P002
```
**多項執行：**
```
執行 P002,P007,P012
```
**範圍執行：**
```
執行 P002-P010（32步系列）
執行 M01-M03（P1緊急項）
```
## 技能設計：workp-execute
- **觸發詞**：`執行 {代號}`、`exec {代號}`
- **功能**：狀態流轉 + workmemo 記錄
- **輸出**：執行摘要報告