一三一法则
用于技术提案与权衡分析的结构化决策框架。当用户面临多种方法（架构决策、工具选择、重构策略、迁移路径）之间的选择时，此技能生成一个 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 |
| 标签 | 沟通, 决策, 提案, 权衡分析 |
参考：完整的 SKILL.md
信息
以下是 Hermes 在触发此技能时加载的完整技能定义。这是技能激活时智能体所看到的指令。
1-3-1 沟通法则
当任务有多种可行方法且用户需要清晰推荐时使用的结构化决策格式。它生成一个简洁的问题界定、三个附带权衡分析的方案，以及针对推荐路径的一个可执行计划。
使用时机
- 用户明确要求一个"1-3-1"响应。
- 用户针对技术决策说"给我些选项"或"我有哪些选择"。
- 一项任务存在多种具有重要权衡的可行方法（架构、工具、迁移策略）。
- 用户需要一份可以转发给团队或利益相关者的提案。
不要用于答案显而易见的简单问题、调试会话，或用户已决定采用某种方法的任务。
步骤
-
问题（一句话）
- 用一句简洁的话陈述核心决策或期望结果。
- 聚焦于 是什么，而非 怎么做 — 不涉及实现细节、工具名称或具体技术。
- 保持精炼。如果你需要"和"，那说明你在描述两个问题。
-
方案（恰好三个）
- 提出三个不同的、可行的方法，标记为 A、B、C。
- 每个方案都需要一个简短描述、优点和缺点。
- 方案应代表真正不同的策略，而非同一方法的微小变体。
-
建议（一个方案）
- 根据用户的上下文和优先级，说明你推荐哪个方案以及原因。
- 要直接 — 这是你的专业判断，而不是模棱两可。
-
完成标准
- 列出推荐方案的具体成功标准。
- 这些是具体、可验证的成果 — 而非模糊的愿望。
- 如果用户选择了其他方案，请相应修改此部分。
-
实施计划
- 执行推荐方案的具体步骤。
- 在适用时包括具体的命令、工具或操作。
- 如果用户选择了其他方案，请相应修改此部分。
验证要点
- 响应中恰好有一个问题陈述。
- 响应中恰好有三个方案（A、B、C），每个都有优点和缺点。
- 响应中有一个单一的推荐，基于理由选择了一个方案。
- 完成标准和实施计划与推荐的方案一致。
- 如果用户选择了不同的方案，推荐、完成标准和实施计划应相应更新。
示例
用户："为我们API客户端添加重试逻辑，给我一个 1-3-1 分析。"
智能体：
问题： 对外部服务的API调用在负载下间歇性失败，需要优雅的重试处理。
方案：
-
方案A：在共享工具中实现带有抖动的指数退避。 优点：简单、模式广为人知；单一实现供所有调用方共享。 缺点：无断路器；调用方在重试期间仍被阻塞。
-
方案B：使用重试库（tenacity）作为每个端点调用的装饰器。 优点：可按端点配置；内置对断路器和速率限制的支持。 缺点：增加了一个依赖；装饰器模式可能使控制流变得模糊。
-
方案C：基于队列的异步重试，带死信处理。 优点：非阻塞；失败调用被跟踪且可重放；扩展性好。 缺点：复杂性显著增加；需要队列后端；对于低流量服务属于过度设计。
建议： 方案A。调用量不足以支撑队列基础设施，带有指数退避和抖动的共享工具可以干净地处理故障模式，且无需引入新依赖。
完成标准：
api_retry()工具处理瞬态HTTP错误（429, 502, 503, 504）。- 最多重试3次，使用指数退避和抖动。
- 所有外部API调用均通过重试工具路由。
- 记录每次重试尝试，包含端点和尝试次数。
- 测试覆盖重试耗尽、立即成功以及瞬时失败后成功的情况。
实施计划：
- 创建
utils/api_retry.py，包含可配置的最大重试次数、基础延迟和可重试状态码。 - 使用
random.uniform(0, base_delay)添加抖动以防止惊群效应。 - 用重试工具包装
api_client.py中现有的API调用。 - 添加单元测试，为每种重试场景模拟HTTP响应。
- 通过一个模拟不稳定端点的简单压力测试，在负载下进行验证。