System-1P Builder
從產品服務策略羅盤的Handoff Pack載入 → 生成 N/V/C/A-bundle/Loop（含 Fit/Offset、Data Flow、知識資產沉澱、文化影子、慣性、資源爭奪與 V 漂移檢查）
System-1P 是什麼？這個 Builder 用來做什麼？
System-1P 用一套固定語法，把「任務／服務包草案」轉成可執行的商業系統模型，並在匯出前強制做證據與資料閉環檢核，避免只畫出看起來合理的線條。
展開：模型包含哪些東西（N / V / C / A-bundle / Loop）
- N（情境需求）：使用者情境、需求、成功定義。用來界定「你到底在解哪個問題」。
- V（價值承諾）：承諾（Promise）／交付（Delivery）／交換（Revenue）／成本骨架（Cost）。用來檢查模式是否自洽。
- C（組件）：滿足需求所依賴的能力與資產（可內建、採買、委外）。每個組件都要補上資產屬性、成功慣性、文化敏感度、可替代性，並用座標放進地圖。
- A-bundle（活動束）：一組互補活動，用來把 V 落地，並「抵銷」特定組件的成本/風險；同時用 Fit（L1/L2/L3）評估契合層次，並標註互補證據（E0/E1/E2）。
- Loop（迴路）：回饋機制（成長或效率）。每個 Loop 必須標註 Data Flow（事件→儲存→轉換→回灌點），並沉澱可累積的知識資產，說明可流轉到哪些組件（資產綜效）。
展開：你最後會得到什麼（輸出與用途）
- System-1P Model.json：結構化模型，可交付給團隊做後續落地、追蹤與版本管理。
- System-1P Report.md：可讀性報告（含硬規則檢核結果），可直接貼到 Notion / Wiki / 提案文件。
- 匯出前硬檢核：互補線證據比例、資料流完整性、文化影子、成功慣性、資源爭奪與 V 漂移風險（未通過會阻擋匯出）。
Step 0｜載入 Handoff Pack
若「自動載入」失敗（不同瀏覽器對 file:// 的儲存隔離規則不同），請使用「匯入 Handoff.json」或直接貼上 JSON。
尚未載入
草稿：未暫存
Step 1｜選定要建模的任務（N 卡候選池）
你可以同時建模多個任務，但需要選一個「主要任務」作為 V 卡與系統設計的主軸。
尚未載入任務。
Step 2｜N 卡（情境需求）
每個任務都至少寫出：情境（Context）、需求（Need）、成功定義（Success）。
Step 3｜V 卡（價值承諾）
會先從主要任務的 Sales Kit 嘗試自動解析並帶入；請人工修正成可執行版本。
Step 4｜C 卡（組件）
每個組件必填：資產屬性、成功慣性、文化敏感度、可替代性。你也可以用兩個滑桿標註「貼近使用者」與「商品化成熟度」以便畫在地圖上。
展開：C 卡欄位是什麼（必填欄位解釋）
- 資產屬性：此組件主要是「知識資產」（可沉澱、可複用，如規則庫/模型/方法論/語料）、「實體資產」（庫存/設備/場域/物流）、或混合。用來判斷能否產生跨領域的資產綜效。
- 成功慣性（Inertia）：過去成功是否造成「抗拒改變/難標準化/難委外/流程僵化」。慣性越高，向右（商品化、外包、標準化）的阻力越大，通常需要變革設計（模組化、治理、激勵、角色重分工）。
- 文化敏感度：此組件的效率是否高度依賴組織氣候（信任、心理安全、跨部門協作、紀律）。敏感度高者，必須搭配「文化影子對策」（規範/節奏/激勵/保護措施），否則數據與流程都會失真。
- 可替代性：市場上是否有成熟替代品、供應商多寡、切換成本與標準化程度。可替代性高者通常可向右移（採買/委外/平台化），釋放資源去投資左側差異化。
- 座標滑桿：貼近使用者（Y）＝越上越直接接觸使用者需求；商品化成熟度（X）＝越右越標準化/可替代。此座標用於對齊討論「投資 vs 商品化」與依賴順序，不取代實證。
| 組件 | 資產屬性 | 成功慣性 | 文化敏感度 | 可替代性 | 座標（可視度/成熟度） | 指標/資料源 | 操作 |
|---|
X=成熟度（右移/商品化），Y=貼近使用者可視度。此圖只協助討論，不取代實際驗證。
Step 5｜A-bundle（活動束：Fit + Cost Offset）
硬規則：每個活動都要連到 C 卡，並寫出「抵銷成本/風險」機制；每束必填 Fit（L1/L2/L3）與互補線證據（E0/E1/E2）。
展開：A-bundle 硬規則與名詞解釋（Offset / Fit / 證據）
- 活動必須連到 C 卡：活動不是「部門工作」，而是「對某個組件成本/風險產生影響的選擇」。每個活動都要指定它在支撐或改造哪個組件。
- 抵銷成本/風險（Cost Offset）：用一句因果句寫清楚：「此活動透過__機制__，使該組件的__成本/變異/風險__下降，表現在__指標__」。沒有 Offset 的活動不算策略活動。
- Fit（契合層次）：
- L1 一致性：活動與 V 的承諾一致，不自打臉。
- L2 相互增強：活動彼此讓效果更強（降摩擦/降變異/升轉換/升留存）。
- L3 最佳化：系統層級把管理成本壓低（模組化、平台化、資料閉環、自動化）。
- 互補線證據（E0/E1/E2）：
- E0 直覺：只有經驗推論，尚無資料。
- E1 可驗證設計：已定義指標/對照/時間盒，可被驗證。
- E2 已有數據：已有歷史資料、A/B、準實驗或流程採礦支持。
若同一稀缺資源被多束活動同時占用，互補可能在資源層面互相掐死。
Step 6｜Loop（Data Flow + 知識資產沉澱）
硬規則：每個 Loop 必須（1）標註 Data Flow（事件→儲存→轉換→回灌點），（2）產生可沉澱的知識資產，並說明可流轉到哪些組件（資產綜效）。
展開：Loop 硬規則與名詞解釋（Data Flow / 知識資產 / 資產綜效）
- Data Flow（資料流）：必須可追溯地寫出事件→儲存→轉換→回灌點：
- 事件：誰做了什麼（可觀測行為），用事件名與欄位描述。
- 儲存：資料存哪裡（log/DB/warehouse），權責與可取得性。
- 轉換：如何清洗、標籤、建模、產出指標/規則。
- 回灌點：回到哪個決策或流程（自動化規則、推薦、資源配置、介入門檻）。
- 可沉澱的知識資產：每轉一圈都要留下可累積、可治理、可重用的產物，例如：標籤語料庫、方法論模組、規則庫、分類法、模型、案例庫。
- 資產綜效（跨域流轉）：此資產能否被其它組件使用（提升其成本/品質/速度），因此必須寫明「可流轉到哪些 C 卡」。
Step 7｜檢核與匯出
匯出前會進行：互補線證據比例、資料流完整性、文化影子、成功慣性、資源爭奪與 V 漂移檢查。
展開：匯出前檢核項目是什麼（為何會擋匯出）
- 互補線證據比例：A-bundle 內互補關係若多數停留在 E0，代表仍是「假說圖」，不宜做重大資源重配置。
- 資料流完整性：每個 Loop 都必須填到「事件→儲存→轉換→回灌點」四段；缺任一段視為無法形成閉環。
- 文化影子（Culture Shadow）：對文化敏感度高的組件/活動束，必須補上氣候保護措施（規範、節奏、激勵、心理安全），否則資料與流程會失真。
- 成功慣性風險：慣性高的組件通常阻礙標準化/右移；需要在報告中明示變革策略（模組化、治理、角色調整）。
- 資源爭奪：多束活動若爭奪同一稀缺資源（教練時間、資料工程、主管注意力等），可能在資源層面互相掐死，必須裁切或重排節奏。
- V 漂移檢查：若核心組件正在快速商品化右移，V 的獨特性可能流失；必須填寫對策（新增左側差異化組件或重寫 V）。
尚未檢核
—