跳到主要内容

One Three One Rule

技术提案与权衡分析的结构化决策框架。当用户需要在多种方案之间做出选择时（架构决策、工具选型、重构策略、迁移路径），本 skill 输出 1-3-1 格式：一句清晰的问题陈述、三个各有利弊的备选方案，以及一个附带完成定义和实施计划的具体建议。当用户要求"1-3-1"、说"给我几个选项"，或需要在竞争方案之间做出选择时使用。

Skill 元数据​

来源可选 — 通过 aigenlabs 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​

信息

以下是 AigenLabs 在触发本 skill 时加载的完整 skill 定义。这是 agent 在 skill 激活时所看到的指令内容。

1-3-1 沟通规则

结构化决策格式，适用于任务存在多个可行方案、用户需要明确建议的场景。输出简洁的问题框架、三个各有权衡的选项，以及推荐方案的可执行计划。

使用时机​

  • 用户明确要求"1-3-1"格式的回复。
  • 用户针对某个技术决策说"给我几个选项"或"我有哪些选择"。
  • 任务存在多个可行方案且权衡（trade-off）有实质意义（架构、工具选型、迁移策略）。
  • 用户需要一份可转发给团队或利益相关方的提案。

不适用于答案显而易见的简单问题、调试会话，或用户已确定方案的任务。

执行步骤​

  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 的简单压力测试，在负载下进行验证。