Skip to main content

一三一规则

针对技术提案与权衡分析的结构化决策框架。当用户需要在多个方案之间进行选择时（例如架构决策、工具选型、重构策略、迁移路径等），该技能会生成一个“1-3-1”格式的输出：一个清晰的问题陈述、三个不同的选项（含优缺点）、以及一个具体的建议（含完成定义与实施计划）。 在用户要求“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
平台linux, macos, windows
标签communication, decision-making, proposals, trade-offs

参考：完整 SKILL.md​

info

以下是 Hermes 在该技能被触发时加载的完整技能定义。当技能激活时，Agent 会看到这些指令。

1-3-1 沟通规则

当一个任务有多个可行方案，且用户需要明确的建议时，使用此结构化决策格式。该格式会生成一个简洁的问题框架、三个带有权衡分析的选项，以及针对推荐路径的可执行计划。

何时使用​

  • 用户明确要求“1-3-1”形式的回复。
  • 用户对某个技术决策说“给我一些选项”或“我有哪些选择”。
  • 任务存在多个可行方案，且各方案有显著的权衡（架构、工具、迁移策略）。
  • 用户需要一个可以转发给团队或利益相关者的提案。

不要用于答案显而易见的问题、调试任务或用户已确定方案的任务。

流程​

  1. 问题（一句话）

    • 用一句简洁的话陈述核心决策或期望的结果。
    • 专注于“是什么”，而非“怎么做”——不要涉及实现细节、工具名称或具体技术。
    • 保持紧凑。如果需要用到“和”，说明你在描述两个问题。

  2. 选项（恰好三个）

    • 提出三个不同的可行方案，分别标记为 A、B、C。
    • 每个选项包含简要描述、优点和缺点。
    • 选项应代表真正不同的策略，而不是同一方案的微小变体。

  3. 建议（选择一个选项）

    • 说明你推荐哪个选项及其理由，基于用户的上下文和优先级。
    • 直接明了——这是你的专业判断，不是模棱两可的措辞。

  4. 完成定义

    • 列出推荐选项的具体成功标准。
    • 这些是具体、可验证的结果，而非模糊的期望。
    • 如果用户选择了不同的选项，请修改本节以匹配。

  5. 实施方案

    • 执行推荐选项的具体步骤。
    • 在适用处包含具体命令、工具或操作。
    • 如果用户选择了其他选项，请修订本节以保持一致。

验证​

  • 回答中恰好有一句“问题”语句。
  • 回答中恰好有三个选项（A、B、C），每个选项都有优缺点。
  • 回答中有一个单一的推荐，选择了一个选项并附有理由。
  • “完成定义”和“实施方案”与推荐的选项一致。
  • 如果用户选择了其他选项，推荐、完成定义和实施方案相应更新。

示例​

用户：“给我们 API 客户端添加重试逻辑，写个 1-3-1。”

Agent：

问题： 对外部服务的 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. 通过针对一个不稳定端点 mock 的简单压力测试，在负载下验证效果。