title: “One Three One Rule — Structured decision-making framework for technical proposals and trade-off analysis” sidebar_label: “One Three One Rule” description: “Structured decision-making framework for technical proposals and trade-off analysis”

{/* 本页面由 website/scripts/generate-skill-docs.py 根据该技能的 SKILL.md 文件自动生成。请直接编辑源文件 SKILL.md，而非此页面。 */}

1-3-1 规则

一种用于技术方案制定与权衡分析的结构化决策框架。当用户需要在多种方案（架构决策、工具选择、重构策略、迁移路径等）之间做出选择时，该技能会以 1-3-1 的格式输出内容：一个明确的问题的描述，三个带有优缺点的不同选项，以及一项包含完成标准与实施计划的明确建议。适用于用户要求提供“1-3-1”格式的内容、请求列出可选方案，或需要在多种竞争性方案中做出选择时。

技能元数据

参考：完整 SKILL.md 文件

:::info 以下是当触发该技能时 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 文件，设置可配置的最大重试次数、基础延迟时间以及可重试的 HTTP 状态码。
2. 使用 random.uniform(0, base_delay) 实现抖动机制，以避免大量请求同时发起导致的冲突。
3. 在 api_client.py 中用该重试工具封装现有的 API 调用逻辑。
4. 为每种重试场景编写单元测试，使用模拟的 HTTP 响应进行测试。
5. 通过针对不稳定接口的简单压力测试，验证在高负载条件下的运行情况。