/opsx:explore 指令詳解

指令用途

/opsx:explore 是進入「探索模式 (Explore Mode)」的專屬指令。它的核心哲學是 「只思考，不實作 (For thinking, not implementing)」。

與其他著重於修改程式碼的指令不同，探索模式旨在建立一個無壓力的討論空間，讓開發者與 AI 助手共同探討模糊的想法、診斷複雜的系統問題、釐清混亂的需求，或評估不同的技術架構方案。

核心思維立場 (The Stance)

當你啟用 /opsx:explore 時，AI 助手會切換為「思考夥伴」的身份，並遵循以下原則：

• 發散而不霸道：主動提供多個潛在的設計方向，供你挑選感興趣的 thread（對話線索）深入討論，而不是直接幫你做決定。
• 結合實際代碼：雖然不改程式碼，但會搜尋現有的程式庫 (Codebase)，以確保所有技術討論皆具備可行性。
• 視覺化呈現：大量使用 ASCII 圖表、狀態圖或數據流向圖來輔助說明複雜架構。
• 絕不越界寫代碼：在探索模式下，AI 絕對不會去修改你的產品程式碼。如果需要實作，必須先退出探索模式並建立變更計畫。

實戰對話範例

以下是三個不同探索情境下的對話範例：

範例一：技術方案評估（Stripe vs LINE Pay 串接）

• You:

  /opsx:explore "我們專案要整合金流，在評估 Stripe 跟 LINE Pay，幫我想想。"
  

• AI:

  好的，我們來探索專案的金流整合方案。以下為兩者的分析對照：

  評估維度	Stripe	LINE Pay (台灣地區)
  整合難易度	極高 (SDK 完善、API 設計優秀)	中等 (需要處理 Signature 與特定跳轉)
  主要客群	國際化、歐美市場	台灣本土主流使用者
  測試便利性	提供極為強大的 sandbox 與測試卡號	需申請商家後取得測試環境金鑰

  技術影響分析： 配合我們現有的 Node.js 後端，若選 Stripe，我們可以直接使用官方的 stripe SDK；若選 LINE Pay，則需要自行封裝 HTTP Client 來處理雜湊與簽章。

  您傾向優先考慮「開發速度與開發者體驗」，還是「本土消費者的支付便利性」呢？

範例二：診斷系統痛點（購物車狀態不同步）

• You:

  /opsx:explore "使用者反應在分頁 A 把商品加入購物車，回到分頁 B 購物車數量沒更新。我該怎麼查？"
  

• AI:

  這是一個典型的跨標籤頁狀態同步問題。在我們目前的專案架構中，狀態流向如下：

  [分頁 A] ──(加入商品)──> [Redux State] (僅存於分頁 A 記憶體)
    │
    └─(API 請求)─────> [資料庫] (後端更新成功)
  
  [分頁 B] ───────────────> 讀取的依舊是分頁 B 本地的 [Redux State] (未更新)
  

  我們有三種解決策略：

  1. Broadcast Channel API：當分頁 A 變更時，向所有同源分頁廣播更新事件。
  2. LocalStorage Event Listener：利用 storage 事件，在 localStorage 改變時觸發 React 重新取得最新購物車狀態。
  3. Short Polling / WebSockets：由後端推播或定期輪詢。

  我可以幫您檢查目前專案中是否有已封裝好的 LocalStorage 監聽工具，我們來看一下程式碼？

範例三：在探索模式下要求寫 Code（AI 拒絕實作）

• You:

  /opsx:explore "好，那我決定用 LocalStorage 的方案。幫我寫一個 useCartSync 的 custom hook 來實作它。"
  

• AI:

  在探索模式下，我無法直接為您修改程式碼。我們目前僅處於討論階段。

  如果您決定要實作此 Hook，請先退出探索模式並建立一個新的變更計畫 (Change)。 您可以使用以下指令來建立提案：

  /opsx:propose "建立 useCartSync 跨分頁狀態同步 Hook"
  

  建立後，我們就可以在該計畫下使用 /opsx:apply 進行安全且有規格對照的實作。