{/* Trang này được tạo tự động từ SKILL.md của kỹ năng bởi website/scripts/generate-skill-docs.py. Chỉnh sửa nguồn SKILL.md, không phải trang này. */}

Quy tắc Một Ba Một

Khung ra quyết định có cấu trúc dành cho các đề xuất kỹ thuật và phân tích đánh đổi. Khi người dùng phải đối mặt với sự lựa chọn giữa nhiều cách tiếp cận (quyết định kiến trúc, lựa chọn công cụ, chiến lược tái cấu trúc, đường dẫn di chuyển), kỹ năng này tạo ra định dạng 1-3-1: một tuyên bố vấn đề rõ ràng, ba tùy chọn riêng biệt với ưu/nhược điểm và một đề xuất cụ thể với định nghĩa về kế hoạch thực hiện và thực hiện. Sử dụng khi người dùng yêu cầu "1-3-1", nói "cho tôi các lựa chọn" hoặc cần trợ giúp để lựa chọn giữa các phương pháp cạnh tranh.

Siêu dữ liệu kỹ năng


Nguồn	Tùy chọn — cài đặt với
`Hermes skills install official/communication/one-three-one-rule
`
Đường dẫn

optional-skills/communication/one-three-one-rule ` | | Phiên bản |

communication

, `decision-making

, `proposals

, trade-offs |

Tham khảo: đầy đủ SKILL.md

thông tin

Sau đây là định nghĩa kỹ năng đầy đủ mà Hermes tải khi kỹ năng này được kích hoạt. Đây là những gì tác nhân coi là hướng dẫn khi kỹ năng được kích hoạt.

Quy tắc giao tiếp #1-3-1

Định dạng ra quyết định có cấu trúc dành cho trường hợp một nhiệm vụ có nhiều cách tiếp cận khả thi và người dùng cần đề xuất rõ ràng. Tạo ra một khung vấn đề ngắn gọn, ba lựa chọn có sự đánh đổi và một kế hoạch khả thi cho lộ trình được đề xuất.

Khi nào nên sử dụng

Người dùng yêu cầu phản hồi "1-3-1" một cách rõ ràng.
Người dùng nói "cho tôi lựa chọn" hoặc "lựa chọn của tôi là gì" đối với quyết định kỹ thuật.
Một nhiệm vụ có nhiều cách tiếp cận khả thi với những đánh đổi có ý nghĩa (kiến trúc, công cụ, chiến lược di chuyển).
Người dùng cần một đề xuất mà họ có thể chuyển tiếp cho một nhóm hoặc các bên liên quan.

KHÔNG sử dụng cho các câu hỏi đơn giản có một câu trả lời rõ ràng, các phiên gỡ lỗi hoặc các nhiệm vụ mà người dùng đã quyết định cách tiếp cận.

Thủ tục

Vấn đề (một câu)
- Trình bày quyết định cốt lõi hoặc kết quả mong muốn trong một câu ngắn gọn.
- Tập trung vào cái gì chứ không phải như thế nào — không có chi tiết triển khai, tên công cụ hoặc công nghệ cụ thể.
- Giữ chặt nhé. Nếu bạn cần "và", bạn đang mô tả hai vấn đề.
Tùy chọn (chính xác là ba)
- Trình bày ba cách tiếp cận riêng biệt, khả thi được dán nhãn A, B, C.
- Mỗi tùy chọn đều có mô tả ngắn gọn, ưu và nhược điểm.
- Các lựa chọn nên thể hiện những chiến lược thực sự khác nhau, chứ không phải những biến thể nhỏ của cùng một cách tiếp cận.
Đề xuất (một lựa chọn)
- Nêu rõ tùy chọn nào bạn đề xuất và tại sao, dựa trên bối cảnh và mức độ ưu tiên của người dùng.
- Hãy thẳng thắn - đây là phán đoán chuyên môn của bạn, không phải hàng rào.
Định nghĩa Hoàn thành
- Liệt kê các tiêu chí thành công cụ thể cho phương án được đề xuất.
- Đây là những kết quả cụ thể, có thể kiểm chứng được - không phải những nguyện vọng mơ hồ.
- Nếu người dùng chọn phương án khác thì sửa lại phần này cho phù hợp.
Kế hoạch thực hiện
- Các bước cụ thể để thực hiện phương án được đề xuất.
- Bao gồm các lệnh, công cụ hoặc hành động cụ thể nếu có.
- Nếu người dùng chọn phương án khác thì sửa lại phần này cho phù hợp.

Xác minh

Câu trả lời có đúng một câu Vấn đề.
Câu trả lời có đúng ba Phương án (A, B, C) với ưu và nhược điểm cho mỗi phương án.
Phản hồi có một Khuyến nghị duy nhất chọn một phương án có lý luận.
Định nghĩa về Hoàn thành và Kế hoạch thực hiện phù hợp với phương án được đề xuất.
Nếu người dùng chọn một tùy chọn khác, Khuyến nghị, DoD và Kế hoạch triển khai sẽ được cập nhật tương ứng.

Ví dụ

Người dùng: "Hãy cho tôi 1-3-1 để thêm logic thử lại vào ứng dụng khách API của chúng tôi."

Đại lý:

Vấn đề: Lệnh gọi API đến các dịch vụ bên ngoài không liên tục khi tải và cần xử lý thử lại một cách nhẹ nhàng.

Tùy chọn:

Tùy chọn A: Độ trễ theo cấp số nhân với độ biến động trong tiện ích dùng chung. Ưu điểm: Mẫu đơn giản, dễ hiểu; triển khai duy nhất được chia sẻ trên tất cả người gọi. Nhược điểm: Không ngắt mạch; người gọi vẫn chặn trong khi thử lại.
Tùy chọn B: Thử lại thư viện (độ bền) làm công cụ trang trí cho mỗi lệnh gọi điểm cuối. Ưu điểm: Có thể định cấu hình cho mỗi điểm cuối; hỗ trợ tích hợp cho bộ ngắt mạch và giới hạn tốc độ. Nhược điểm: Thêm phụ thuộc; mẫu trang trí có thể che khuất luồng điều khiển.- Tùy chọn C: Thử lại không đồng bộ dựa trên hàng đợi với việc xử lý thư chết. Ưu điểm: Không chặn; các cuộc gọi thất bại được theo dõi và có thể phát lại; quy mô tốt. Nhược điểm: Tăng độ phức tạp đáng kể; yêu cầu một chương trình phụ trợ hàng đợi; quá mức cần thiết cho các dịch vụ có khối lượng thấp.

Đề xuất: Tùy chọn A. Khối lượng cuộc gọi không phù hợp với cơ sở hạ tầng hàng đợi và tiện ích dùng chung với độ trễ lũy thừa + jitter bao trùm chế độ lỗi một cách rõ ràng mà không cần phụ thuộc mới.

Định nghĩa của Hoàn thành:

Tiện ích API_retry() xử lý các lỗi HTTP nhất thời (429, 502, 503, 504).
Thử lại tối đa 3 lần với độ trễ và jitter theo cấp số nhân.
Tất cả các lệnh gọi API bên ngoài đều định tuyến thông qua tiện ích thử lại.
Ghi lại mỗi lần thử lại với điểm cuối và số lần thử.
Các thử nghiệm bao gồm các trường hợp thử lại kiệt sức, thành công ngay lập tức và các tình huống nhất thời rồi thành công.

Kế hoạch thực hiện:

Tạo utils/API_retry.py với số lần thử tối đa có thể định cấu hình, độ trễ cơ sở và mã trạng thái có thể thử lại.
Thêm jitter bằng random.uniform(0, base_delay) để ngăn chặn sấm sét bầy đàn.
Kết hợp các lệnh gọi API hiện có trong API_CLIent.py bằng tiện ích thử lại.
Thêm các bài kiểm tra đơn vị mô phỏng các phản hồi HTTP cho từng trường hợp thử lại.
Xác minh tình trạng dưới tải bằng một bài kiểm tra sức chịu đựng đơn giản dựa trên mô hình điểm cuối không ổn định.

Siêu dữ liệu kỹ năng​

Tham khảo: đầy đủ SKILL.md​

Khi nào nên sử dụng​

Thủ tục​

Xác minh​

Ví dụ​