跳到主要内容

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. 针对不稳定的端点模拟进行简单的压力测试，以验证负载下的表现。