跳到主要內容

One Three One Rule（1-3-1 規則）

用於技術提案和權衡分析的結構化決策框架。當用戶面臨多種方法之間的選擇（架構決策、工具選擇、重構策略、遷移路徑）時，此技能會生成 1-3-1 格式的內容：一個清晰的問題陳述、三個具有優缺點的 distinct 選項，以及一個包含完成定義和實施計劃的具體建議。當用戶要求提供“1-3-1”、說“給我一些選項”或需要在競爭方法之間做出選擇時使用此技能。

技能元數據​

來源可選 — 使用 hermes skills install official/communication/one-three-one-rule 安裝
路徑optional-skills/communication/one-three-one-rule
版本1.0.0
作者Willard Moore
許可證MIT
標籤communication, decision-making, proposals, trade-offs

參考：完整 SKILL.md​

信息

以下是 Hermes 在觸發此技能時加載的完整技能定義。這是技能激活時代理看到的指令。

1-3-1 溝通規則

當任務存在多種可行方法且用戶需要明確建議時使用的結構化決策格式。生成簡潔的問題框架、三個帶有權衡分析的選項，以及針對推薦路徑的可執行計劃。

何時使用​

  • 用戶明確要求“1-3-1”回覆。
  • 用戶針對技術決策說“給我一些選項”或“我有哪些選擇”。
  • 任務存在多種具有顯著權衡的可行方法（架構、工具、遷移策略）。
  • 用戶需要一份可以轉發給團隊或利益相關者的提案。

不要將其用於只有一個明顯答案的簡單問題、調試會話，或用戶已決定採用某種方法的任務。

流程​

  1. 問題（一句話）

    • 用一句簡潔的話陳述核心決策或期望結果。
    • 關注做什麼，而不是怎麼做 — 不包含實施細節、工具名稱或具體技術。
    • 保持緊湊。如果你需要使用“和”，說明你在描述兩個問題。

  2. 選項（恰好三個）

    • 呈現三個標記為 A、B、C 的不同且可行的方法。
    • 每個選項包含簡要描述、優點和缺點。
    • 選項應代表真正不同的策略，而不是同一方法的細微變體。

  3. 建議（一個選項）

    • 根據用戶的上下文和優先級，說明你推薦哪個選項及原因。
    • 直接明瞭 — 這是你的專業判斷，而非模稜兩可的說法。

  4. 完成定義

    • 列出推薦選項的具體成功標準。
    • 這些是具體、可驗證的結果 — 而非模糊的願望。
    • 如果用戶選擇了其他選項，請修訂此部分以匹配。

  5. 實施計劃

    • 執行推薦選項的具體步驟。
    • 在適用的情況下包含具體命令、工具或操作。
    • 如果用戶選擇了其他選項，請修訂此部分以匹配。

驗證​

  • 回覆中恰好有一句“問題”陳述。
  • 回覆中恰好有三個選項（A、B、C），且每個選項都有優點和缺點。
  • 回覆中有一個單一的“建議”，選擇一個選項並給出理由。
  • “完成定義”和“實施計劃”與推薦的選項一致。
  • 如果用戶選擇不同的選項，“建議”、“完成定義”和“實施計劃”應相應更新。

示例​

用戶：“為給我們的 API 客戶端添加重試邏輯提供一個 1-3-1。”

代理：

問題： 外部服務的 API 調用在負載下間歇性失敗，需要優雅的重試處理。

選項：

  • 選項 A：在共享實用工具中使用帶抖動的指數退避。 優點：簡單、眾所周知的模式；所有調用者共享單一實現。 缺點：無熔斷機制；調用者在重試期間仍然阻塞。

  • 選項 B：將重試庫（tenacity）作為每個端點調用的裝飾器。 優點：每個端點可配置；內置支持熔斷器和速率限制。 缺點：增加依賴項；裝飾器模式可能掩蓋控制流。

  • 選項 C：基於隊列的異步重試，帶有死信處理。 優點：非阻塞；跟蹤失敗調用並可重放；擴展性好。 缺點：複雜性顯著增加；需要隊列後端；對於低流量服務來說過於複雜。

建議： 選項 A。調用量不足以證明需要隊列基礎設施，而帶有指數退避 + 抖動的共享實用工具可以在不引入新依賴的情況下乾淨地覆蓋故障模式。

完成定義：

  • api_retry() 實用工具處理瞬時 HTTP 錯誤（429, 502, 503, 504）。
  • 最多重試 3 次，採用指數退避和抖動。
  • 所有外部 API 調用都通過重試實用工具進行路由。
  • 記錄每次重試嘗試，包括端點和嘗試次數。
  • 測試涵蓋重試耗盡、立即成功以及瞬時失敗後成功的場景。

實施計劃：

  1. 創建 utils/api_retry.py，包含可配置的最大重試次數、基礎延遲和可重試的狀態碼。
  2. 使用 random.uniform(0, base_delay) 添加抖動，以防止驚群效應。
  3. 在 api_client.py 中使用重試工具包裝現有的 API 調用。
  4. 添加單元測試，模擬每種重試場景下的 HTTP 響應。
  5. 針對不穩定的端點模擬進行簡單的壓力測試，以驗證負載下的表現。