---
title: "One Three One Rule — 技术提案与权衡分析的结构化决策框架"
sidebar_label: "One Three One Rule"
description: "技术提案与权衡分析的结构化决策框架"
---

{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

# One Three One Rule

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

## Skill 元数据

| | |
|---|---|
| 来源 | 可选 — 通过 `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 在触发本 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 的简单压力测试，在负载下进行验证。