Cách ủy thác nhiệm vụ cộng đồng mà không cần thuê thêm kiểm duyệt viên

Dành cho ai: người sáng lập hoặc trưởng cộng đồng có hàng đợi duyệt đang tăng nhanh hơn đội ngũ, đang nhìn vài nghìn bài gửi đang chờ và tự hỏi liệu câu trả lời là thêm một kiểm duyệt viên, thêm người thứ ba, hay là đơn xin nghỉ việc.

Câu trả lời ngắn: Có lẽ không phải thêm một người — nhưng không phải vì lý do tâng bốc. Phần lớn hàng đợi lẽ ra không nên tồn tại. Trong Zealy, năm loại nhiệm vụ được thiết kế để cần người đọc câu trả lời — và nhiệm vụ ngày tham gia cùng chúng ở thiết lập mặc định — trong khi mọi thứ khác tự xử lý ngay khi thành viên nhận nhiệm vụ. Ủy thác cho một quy tắc tốt hơn ủy thác cho một người, và tốt hơn ủy thác cho một cỗ máy, theo đúng thứ tự đó, vì chỉ cách đầu tiên xóa bỏ công việc thay vì di chuyển nó.

Công bố: Zealy xuất bản bài này và Zealy bán nền tảng được mô tả trong đó. Mọi khẳng định về những gì Zealy làm đều được đọc từ chính mã nguồn của Zealy vào ngày 16 tháng 8 năm 2026, không phải từ các trang tiếp thị hay tài liệu của Zealy. Điều đó bao gồm cả những chỗ Zealy thiếu một thứ hiển nhiên, và hai trang tài liệu của chính Zealy bị sai, mà chúng tôi đang sửa trong cùng thay đổi với bài viết này.

Xác minh lần cuối: 16 tháng 8 năm 2026.

Bạn có cần thuê thêm kiểm duyệt viên không?

Có lẽ chưa. Trong Zealy, năm loại nhiệm vụ được thiết kế để đến tay người duyệt: văn bản, URL, số, tải tệp lên và bình chọn — và nhiệm vụ ngày tham gia cùng chúng ở thiết lập mặc định. Mọi thứ khác tự xác minh và không bao giờ vào hàng đợi. Trước khi thêm người, hãy rà soát nhiệm vụ nào của bạn thực sự cần người đọc câu trả lời.

Gần như mọi cuộc trò chuyện "chúng tôi đang ngập trong bài gửi" đều bắt đầu từ năng lực — bao nhiêu người duyệt, bao nhiêu giờ, mỗi người xử lý một mục nhanh đến đâu — trong khi quy mô hàng đợi đã được quyết định từ nhiều tuần trước đó trong trình soạn nhiệm vụ, bởi người chọn loại nhiệm vụ. Một nhiệm vụ yêu cầu ảnh chụp màn hình tạo ra một hàng đợi. Một nhiệm vụ yêu cầu ai đó tham gia máy chủ Discord thì không, vì câu trả lời được kiểm tra với Discord ngay tại chỗ. Cùng chiến dịch, cùng phần thưởng, chi phí vận hành khác hẳn nhau.

Vậy trình tự trung thực là: loại bỏ công việc, ủy thác phần còn lại, tự động hóa những gì còn sót. Các đội ngũ luôn làm ngược lại, và đó là cách bạn phải trả tiền nâng cấp gói để tăng tốc công việc mà lẽ ra bạn có thể xóa bỏ.

Ba cách ủy thác hàng đợi duyệt

Bạn có thể ủy thác hàng đợi duyệt theo ba cách: cho một quy tắc, bằng cách làm nhiệm vụ tự xác minh; cho một người, dùng vai trò người duyệt của Zealy; hoặc cho một cỗ máy, dùng duyệt bằng AI hoặc một tác nhân MCP. Quy tắc loại bỏ công việc, con người áp dụng phán đoán, cỗ máy áp dụng một lời nhắc đã viết ở quy mô lớn.

Cách một: thiết kế để loại bỏ công việc duyệt

Bắt đầu từ đây: đây là cách duy nhất loại bỏ công việc thay vì di chuyển nó. Năm loại nhiệm vụ của Zealy được thiết kế để cần con người — văn bản, URL, số, tải tệp lên và bình chọn — và nhiệm vụ ngày mặc định cũng hành xử như vậy. Mọi thứ khác được giải quyết khi thành viên nhận nhiệm vụ. Viết lại một nhiệm vụ văn bản thành kiểm tra liên kết sẽ làm trống hàng đợi.

Chúng tôi kiểm tra điều này bằng cách đọc hàm quyết định liệu một nhiệm vụ có được tự động xác thực hay không, rồi đối chiếu chéo mọi trình xác thực lúc chạy trong dịch vụ nhiệm vụ. Năm loại đó — text, url, number, file, poll — mỗi loại trả về trạng thái chờ duyệt trừ khi nhiệm vụ được đặt rõ ràng để tự động xác thực. Các loại khác trả về thành công hoặc lỗi ngay lập tức, nên không có gì phải chờ và không có hàng đợi để chờ trong đó.

Hai ngoại lệ trung thực, vì mã nguồn mâu thuẫn với chính nó và chúng tôi thà nói ra còn hơn dọn dẹp cho gọn:

• Nhiệm vụ ngày. Một danh sách coi chúng là luôn tự động, trong khi trình xác thực thực sự chạy lại tuân theo thiết lập tự động xác thực của nhiệm vụ, mà trình soạn thảo mặc định tắt. Chúng tôi sẽ không nói với bạn rằng nhiệm vụ ngày là tự động khi mã nguồn mâu thuẫn với chính nó. Hãy thử một cái trước khi bạn dựa vào nó.
• Proof of Humanity. Nó tự giải quyết lúc chạy nhưng không xuất hiện trong danh sách nào — cũng như loại nhiệm vụ đối tác — nên một nhiệm vụ chỉ chứa nhiệm vụ đó được báo là không tự động xác thực. Nó hành xử tốt hơn những gì nó quảng cáo. (Nó bắt được gì được đề cập trong cách chạy airdrop không bị farm — nó là bộ lọc bot, không phải bộ lọc sybil.)

Bản viết lại thực sự làm giảm hàng đợi

Hãy xem các nhiệm vụ văn bản của bạn trước. Hầu hết đặt một câu hỏi có một đáp án đúng, nhưng lại diễn đạt như một bài luận. "Cho chúng tôi biết bạn đã học được gì từ tài liệu" là một hàng đợi. "Dán mã giao dịch" là nhiệm vụ văn bản hoặc URL có đáp án đúng, và nó tự giải quyết. "Chụp ảnh màn hình vị trí của bạn" là một hàng đợi, và nhiệm vụ tệp không có kiểm tra nội dung nào cả, nên người duyệt phải mở từng ảnh. "Mô hình phí của chúng tôi là mô hình nào trong ba mô hình này" là một câu đố, và câu đố không bao giờ đến tay người duyệt.

Nguyên tắc chúng tôi sẽ bảo vệ: nếu bạn có thể viết sẵn đáp án, nhiệm vụ đó không nên nằm trong hàng đợi. Nếu không thể, hãy bố trí người duyệt thay vì giả vờ rằng một câu lệnh sẽ làm được.

Cái bẫy: đáp án đúng để trống sẽ phê duyệt mọi thứ

Đây là đoạn trong bài viết này có khả năng cao nhất giúp bạn tránh một tuần tồi tệ. Tự động xác thực trên nhiệm vụ văn bản, URL, số và ngày so sánh bài nộp của thành viên với đáp án đúng mà bạn cấu hình, và cả bốn phép so sánh đều bỏ qua khi đáp án đúng đó để trống. Nó không thất bại theo hướng an toàn và không cảnh báo bạn. Nó phê duyệt mọi thứ.

Hai hành vi liên quan cần biết trước khi bạn bật công tắc hàng loạt. Một cuộc bình chọn có bật tự động xác thực sẽ phê duyệt mọi thứ theo thiết kế — không phải lỗi, vì bình chọn không có đáp án sai, nhưng bật tự động xác thực trên toàn bộ một mô-đun để xử lý tồn đọng sẽ trao phần thưởng bình chọn cho tất cả mọi người. Và tự động xác thực một tệp tải lên sẽ phê duyệt việc tải lên, không phải nội dung; mọi tệp đều được chấp nhận.

Nếu bạn chỉ mang theo một thói quen vận hành từ bài viết này, hãy là thói quen này: sau khi bật tự động xác thực, hãy tự nhận nhiệm vụ với một đáp án cố ý sai và xác nhận rằng nó bị từ chối.

Một cơ chế kiểm soát trùng lặp giúp giảm việc; cơ chế kia chỉ chú thích

Cảnh báo cho người duyệt đánh dấu một bài nộp là duplicate (một thành viên khác đã gửi cùng nội dung cho cùng nhiệm vụ) hoặc reused (thành viên này đã gửi trước đó), chỉ trên nhiệm vụ văn bản và tệp, tra cứu trong 180 ngày. Chúng chỉ mang tính tham khảo — không có gì trong luồng mã ghi nhận phán quyết đọc chúng. Chúng báo cho người duyệt biết điều gì đó; chúng không quyết định gì cả. Và trên nhiệm vụ tệp, việc so khớp yếu hơn vẻ ngoài: các tệp tải lên được so sánh theo URL lưu trữ, và mỗi lần tải lên đều có khóa mới, nên tải lại đúng tệp đó không bao giờ được ghi nhận là trùng lặp.

Từ chối trùng lặp khi nộp bài là một cài đặt riêng, tùy chọn, từ chối một câu trả lời văn bản lặp lại bằng lỗi trước khi nó đến hàng đợi của bạn. Nó mặc định tắt trên nhiệm vụ văn bản và URL, chuẩn hóa bằng cách cắt khoảng trắng, gộp khoảng trắng và chuyển thành chữ thường — nên một cách diễn đạt khác sẽ lọt qua — và nó chặn mọi thành viên dùng lại văn bản đó, kể cả người viết đầu tiên. Đó là cơ chế giúp giảm hàng đợi.

Cách hai: giao cho một người có vai trò người duyệt

Vai trò người duyệt của Zealy là một sự ủy quyền hẹp: nó mở chín trong số 225 bề mặt tuyến API được kiểm soát theo vai trò trong API của Zealy, tất cả đều liên quan đến việc duyệt, và người duyệt không thể phê duyệt yêu cầu của chính mình. Bạn cấp vai trò này bằng một liên kết mời mang theo vai trò, thời hạn và số lần sử dụng tối đa.

Không có vai trò nào tên là moderator trong Zealy. Vai trò đó là reviewer, và có tổng cộng năm vai trò: admin, editor, reviewer, guest và banned. (Tài liệu quản lý thành viên của chính Zealy nói có bốn. Nó bỏ sót banned, một vai trò thực sự mà endpoint đổi vai trò chấp nhận. Trang đó được sửa trong cùng thay đổi với bài viết này.)

Năm vai trò nằm trên một bậc thang tuyến tính nghiêm ngặt — admin trên editor trên reviewer trên guest trên banned — và mọi kiểm tra quyền trong sản phẩm chỉ hỏi một câu: vai trò của thành viên này có ít nhất ở cấp này không? Vậy nên mô tả trung thực về mô hình quyền của Zealy là không có mô hình nào. Không có bộ quyền, không có vai trò tùy chỉnh, không có cách giới hạn vai trò cho một nhiệm vụ, mô-đun hay chiến dịch. Chúng tôi đã tìm trong mô hình và định nghĩa cơ sở dữ liệu các khái niệm permission, ability và grant; kết quả khớp duy nhất là các cột OAuth không liên quan.

Đây là những gì bậc thang phân bổ trên 225 bề mặt được kiểm soát theo vai trò đó:

Vì bậc thang là tuyến tính, người duyệt cũng có mọi thứ được kiểm soát ở cấp guest. Nhưng chín bề mặt đó là toàn bộ sự ủy quyền và tất cả đều là công việc duyệt, đó là lý do thăng ai đó lên reviewer là câu trả lời tốt hơn nhiều so với thăng họ lên admin để họ có thể giúp đỡ.

Hãy chú ý hàng editor. Editor là một cấp quyền rộng hơn nhiều so với reviewer: nó bao gồm mọi thứ reviewer làm được, cộng với cấu hình nhiệm vụ, mô-đun và sprint, khả năng thấy nhiệm vụ chưa công bố, và đặt lại yêu cầu. Tài liệu thành viên của chính Zealy mô tả nó là cấu hình nhiệm vụ, sprint và thành viên và xem tất cả các trang, nghe có vẻ hẹp hơn thực tế; trang đó được sửa trong cùng thay đổi với bài viết này. Hãy thăng ai đó lên editor khi họ đang xây dựng chiến dịch, và lên reviewer khi họ chỉ đọc bài nộp.

Cách cấp vai trò, và cái giá bạn phải trả

Thay đổi vai trò chỉ dành cho admin, và admin không thể thay đổi vai trò của chính mình. Cơ chế đáng dùng là liên kết mời, mang theo vai trò, thời hạn và số lần sử dụng tối đa. Hãy dùng cả ba: một lời mời hết hạn sau 48 giờ với tối đa một lần sử dụng là một thứ rất khác với một liên kết nằm trong nhóm Telegram suốt tám tháng.

Sau đó hãy trung thực về cái giá. Người duyệt có thể gắn tối đa 20.000 XP thưởng cho mỗi yêu cầu họ phê duyệt, không có kiểm tra vai trò nào hạn chế điều đó, và một thao tác hàng loạt duy nhất có thể mang theo 1.000 yêu cầu — vì vậy một lượt phê duyệt có thể tạo ra tới 20 triệu XP. Ủy quyền duyệt là ủy quyền quyền cấp XP. Với hầu hết cộng đồng điều đó ổn và thậm chí mong muốn, vì XP thưởng là cách người duyệt thưởng cho một bài nộp xuất sắc — nhưng nếu XP của bạn nuôi một bảng xếp hạng trả token, bạn đã trao cho người đó một đòn bẩy trên khoản chi trả. Zealy ghi lại toàn bộ nhật ký kiểm toán theo từng phán quyết, nên điều này có thể phát hiện sau khi xảy ra chứ không thể ngăn ngừa. Nếu ứng viên của bạn đến từ một chương trình cộng tác viên, cách vận hành chương trình đại sứ crypto đề cập vai trò đó tốn của bạn những gì.

Người duyệt không thể duyệt yêu cầu của chính mình — một cách âm thầm

Yêu cầu của chính người duyệt bị loại khỏi những gì họ có thể phê duyệt, được thực thi ở lớp dịch vụ và một lần nữa ở bốn lớp bảo vệ SQL riêng biệt. Tốt. Phần đáng chú ý là lưu ý: bộ lọc hoạt động âm thầm. Một người duyệt chọn hàng loạt một lô có chứa yêu cầu của chính họ sẽ không nhận được lỗi. Yêu cầu đó bị loại khỏi lô và vẫn ở trạng thái chờ, và không ai được báo. Nếu một người duyệt khẳng định họ đã phê duyệt thứ gì đó mà vẫn còn nằm trong hàng đợi, hãy kiểm tra điều này trước tiên.

Hai người duyệt trên một hàng đợi sẽ xung đột

Không có việc nhận, khóa hay phân công trong hàng đợi duyệt của Zealy. Chúng tôi đã tìm trong kho mã nguồn các khái niệm khóa người duyệt, nhận yêu cầu, phân công duyệt và người được giao trên toàn bộ API, backend và webapp; tìm kiếm phân công không trả về gì cả. Khóa duy nhất trong hệ thống là một mutex ghi ngắn ngăn ghi đè hai lần, không phải đặt chỗ hàng đợi.

Hệ quả không phải như bạn đoán. Hai người duyệt trên cùng một hàng đợi thấy cùng các yêu cầu và cùng đọc một bài nộp. Nếu họ đồng ý, người thứ hai nhận lỗi, vì Zealy từ chối đặt một yêu cầu vào trạng thái nó đã có, và thời gian đọc đó bị mất. Nếu họ không đồng ý, hoàn toàn không có lỗi: phán quyết thứ hai thay thế phán quyết thứ nhất, phần thưởng được dọn dẹp hoặc cấp lại tương ứng, và không ai được báo rằng một đồng nghiệp đã quyết định trước đó. Trường hợp âm thầm là bất đồng, chính là trường hợp bạn muốn được cảnh báo nhất. Cũng không có cách nào gán một người duyệt cho một nhiệm vụ hoặc mô-đun cụ thể — bạn không thể diễn đạt "Ana xử lý bài nộp thiết kế, Ben xử lý bằng chứng on-chain" trong sản phẩm.

Phối hợp người duyệt là một vấn đề con người ở Zealy hiện nay. Hãy nói điều đó với đội của bạn thành tiếng thay vì để họ phát hiện trong một cuộc tranh cãi trên Discord. Phân chia hàng đợi trong một tin nhắn ghim: theo mô-đun, theo ngày, hoặc một người làm cũ nhất trước trong khi người kia làm mới nhất trước — cách chia thô sơ nhất, và nó vẫn giảm xung đột.

Duyệt hàng loạt: một phán quyết cho tối đa 1.000 yêu cầu

Duyệt hàng loạt của Zealy chấp nhận tối đa 1.000 yêu cầu trong một lần gọi, và ràng buộc là những gì lần gọi đó mang theo: một trạng thái, một bình luận, một dấu và một giá trị XP thưởng cho toàn bộ lô. Không có phán quyết riêng từng mục bên trong một thao tác hàng loạt. Điều đó khiến nó tuyệt vời cho một tập đồng nhất — mọi bài nộp trên một nhiệm vụ bị lỗi, mọi yêu cầu trên một tác vụ bạn đã hủy — và nguy hiểm cho một tập hỗn hợp, vì bình luận 1.000 thành viên đọc là cùng một câu. Hãy sắp xếp thật kỹ trước khi chọn.

Cách ba: giao phán quyết cho máy

Duyệt bằng AI của Zealy chạy Google Gemini 2.5 Flash Lite theo một prompt bạn viết, theo từng nhiệm vụ, trên các gói Plus và Enterprise tính đến ngày 16 tháng 8 năm 2026. Nó không đề xuất phán quyết để bạn xác nhận. Nó viết phán quyết, và lý do của nó trở thành bình luận mà thành viên đọc.

Hãy đọc lại điều đó, vì tài liệu duyệt của chính Zealy từng mô tả duyệt bằng AI là cung cấp các đề xuất thông minh để giúp bạn xử lý việc duyệt. Điều đó sai, và nó được sửa trong cùng thay đổi với bài viết này. Không có bước xác nhận của con người trong luồng mã: mô hình trả về kết quả, Zealy ghi nhận phê duyệt hoặc từ chối từ một tài khoản hệ thống chuyên dụng, và lý do của mô hình rơi vào hộp thư của thành viên.

Đó là một quyết định sản phẩm thực sự khác với duyệt có AI hỗ trợ, và nó xứng đáng với mức cẩn trọng khác từ bạn:

• Bật nó theo từng nhiệm vụ, bằng cách bật duyệt bằng AI trên nhiệm vụ và viết một prompt không rỗng. Đây không phải công tắc toàn cộng đồng, và đó là mức độ chi tiết đúng: bạn có thể tự động hóa một tác vụ khối lượng lớn mà không tự động hóa các quyết định phán đoán của mình.
• Hãy viết prompt như một tiêu chuẩn từ chối, không phải một cảm giác. Mô hình đang tạo ra một thông điệp từ chối hướng tới thành viên, nên bất cứ điều gì mơ hồ trong prompt của bạn sẽ trở thành một bình luận mơ hồ và do đó gây bực bội trên bài nộp của ai đó.
• Một cron đưa những yêu cầu bị bỏ lại vào lại hàng đợi mỗi 15 phút, nhặt các yêu cầu duyệt bằng AI đã chờ hơn một giờ mà không có người duyệt. Một tồn đọng không âm thầm mục nát.

Một lưu ý về đo lường nếu bạn dùng nó. Các phán quyết của AI được gán cho một tài khoản hệ thống mang vai trò quản trị viên, nên trên một cộng đồng dùng duyệt bằng AI, nó xuất hiện trong phân tích người duyệt hàng đầu như bất kỳ người duyệt nào khác. Trước khi bạn nói với đội rằng con người của bạn đã xử lý bao nhiêu yêu cầu, hãy loại trừ nó.

Các gói, kiểm tra ngày 16 tháng 8 năm 2026

Duyệt bằng AI được bao gồm trong các gói Plus và Enterprise, và trang giá của Zealy liệt kê nó là không bao gồm trong Free hoặc Standard. Trên một cộng đồng miễn phí mà chúng tôi kiểm tra qua API năng lực của chính Zealy vào ngày 16 tháng 8 năm 2026, nó báo không khả dụng với lý do requires_plus_or_enterprise. Hãy kiểm tra năng lực trên cộng đồng của chính bạn thay vì giả định từ tên gói.

Plus là $359 mỗi tháng khi thanh toán theo năm, và Enterprise là tùy chỉnh, thanh toán theo năm. Gói Free là $0 với 1.000 lượt claim quest mỗi tháng và số thành viên không giới hạn; Standard là $149 mỗi tháng khi thanh toán theo năm. Giá chưa bao gồm VAT và các loại thuế bán hàng áp dụng khác, và tất cả đều lấy từ trang giá của Zealy, kiểm tra ngày 16 tháng 8 năm 2026.

Quyết định quan trọng: ở mức 200 lượt claim mỗi tuần, nâng cấp để tự động hóa chúng là một sự đánh đổi tồi so với một buổi chiều dành để chuyển các nhiệm vụ văn bản thành những nhiệm vụ có thể kiểm tra được. Ở mức hàng nghìn bài nộp mở mỗi tuần, với tiêu chuẩn được ghi rõ, thì đó là một sự đánh đổi tốt.

Giao phó cho một agent qua MCP

Con đường máy móc còn lại là một agent. Zealy cung cấp chức năng review qua máy chủ MCP của nó, và hình thức giao phó đó cố ý bị hạn chế hơn so với con người.

• Một agent có thể gửi tối đa 1.000 lượt claim trong một lần gọi, cùng giới hạn với review hàng loạt, với cùng ràng buộc một phán quyết cho cả lô.
• Một agent cần admin vai trò, trong khi một người review chỉ cần reviewer. Tuyến review công khai từ chối quyết định review từ MCP của bất kỳ thứ gì thấp hơn, nên không có phiên bản dành cho agent của việc cấp quyền hẹp — điều này ngược lại với mô hình đặc quyền tối thiểu mà bạn sẽ mong đợi.
• Mỗi thao tác ghi đều cần một token xác nhận mới từ con người. Không phải một phiên, không phải một phê duyệt trước đó — mà là một xác nhận mới cho mỗi lần gọi.
• Tiền là điều cấm. Một kiểm tra trên mọi review của public-admin chặn bất kỳ claim nào mang phần thưởng NFT, token, USDC hoặc Zaps khỏi bị agent chuyển trạng thái. Một agent có thể dọn hàng đợi XP của bạn; nó không thể di chuyển một claim có chi trả. Nếu bạn đang chạy phân phối, cách phân phối token cho các thành viên cộng đồng đang hoạt động đề cập ai thực sự gửi cái gì.
• Agent chỉ có thể tạo lời mời khách, không bao giờ tạo lời mời reviewer. Một agent không thể bổ sung người cho hàng đợi của bạn thay bạn.

Khi câu trả lời thực sự là một người khác

Thuê hoặc tuyển dụng khi phán đoán chính là sản phẩm: chất lượng chủ quan, chuẩn mực cộng đồng, khiếu nại, các trường hợp ngoại lệ và bất cứ điều gì mà một lần từ chối sai khiến bạn mất một người đóng góp. Thêm một người khi hàng đợi của bạn chứa sự bất đồng thực sự thay vì khối lượng. Khối lượng là một vấn đề thiết kế; bất đồng là một vấn đề nhân sự.

Bài kiểm tra chúng tôi sẽ áp dụng trước khi thêm một reviewer: lấy 20 claim đang chờ và cho hai người review chúng độc lập. Nếu họ đồng ý ở 19 claim, hàng đợi của bạn là khối lượng, và khối lượng được giải quyết bằng quy tắc và prompt. Nếu họ đồng ý ở 13 claim, hàng đợi của bạn chứa phán đoán thực sự, và không cài đặt tự động xác thực hay prompt mô hình nào có thể làm sự bất đồng đó biến mất — chỉ có thể làm nó vô hình.

Ba tình huống mà một người là câu trả lời đúng và chúng tôi sẽ không cố thuyết phục bạn làm khác:

Các bài nộp sáng tạo và dài, nơi chất lượng là tiêu chí phần thưởng. Nếu bạn đang trả tiền cho công việc tốt thay vì công việc đã hoàn thành, ai đó phải quyết định thế nào là tốt, lặp đi lặp lại, và bảo vệ nó.

Bất cứ điều gì có quy trình khiếu nại. Một thành viên bị từ chối mà phàn nàn cần một người có thể đảo ngược quyết định, và đảo ngược một review cũng là điều loại bỏ một vai trò Discord đã được cấp bởi một phê duyệt — một reviewer chuyển một claim từ thành công sang thất bại cũng làm điều đó. Không có gì khác kiểm tra lại những cấp quyền đó; chúng chỉ diễn ra một lần.

Các khoản chi trả giá trị cao. Nếu một phán quyết quyết định ai nhận token, hãy đặt một người vào đó. Chính các quy tắc agent của Zealy đã mã hóa quan điểm đó: một cỗ máy không thể chuyển trạng thái một claim mang phần thưởng tài chính.

Zealy đo lường gì, và không đo lường gì

Zealy hiển thị số lượng review đang chờ, nhật ký kiểm tra theo từng phán quyết, các reviewer hàng đầu theo khối lượng và theo tỷ lệ phê duyệt, tổng số sao và cờ theo từng thành viên, và xuất CSV tối đa 10.000 dòng. Nó không tính thời gian đến review, độ trễ hàng đợi, SLA hay chỉ số thông lượng. Chúng tôi đã tìm trong mã nguồn những tên đó và không tìm thấy gì.

Chúng tôi nói chính xác vì phiên bản bài viết này mà chúng tôi dự định ban đầu được xây dựng trên dữ liệu thời gian hàng đợi review, và dữ liệu đó không tồn tại. Chúng tôi đã tìm trong các gói của Zealy các từ time-to-review, review latency, average review time, review duration, review throughput và reviews-per-hour. Không có kết quả nào, không có nhóm theo tuổi, không có bảng điều khiển thông lượng. Vậy nên khi một nhà cung cấp nói với bạn rằng khách hàng của họ cắt giảm thời gian review đi một tỷ lệ phần trăm nào đó, hãy hỏi hệ thống nào đã tạo ra con số đó. Chúng tôi không thể tạo ra con số của mình, và chúng tôi sẽ không bịa ra một con số.

Hai điều nữa cần đọc đúng:

"Top reviewers by approval rate" là tỷ lệ phê duyệt, không phải tỷ lệ chính xác. Nó cho bạn biết bao nhiêu phần trăm các phán quyết của một reviewer là phê duyệt. Nó không nói gì về việc những phán quyết đó có đúng hay không. Một reviewer phê duyệt mọi thứ sẽ đạt 100%.

Thời gian đến review có thể suy ra được, chỉ là không được báo cáo. CSV review chứa dấu thời gian tạo và cập nhật của từng claim nhưng không chứa các sự kiện review, nên với một claim được review một lần và để yên, khoảng cách giữa hai dấu thời gian đó là thời gian đến review của bạn, và trung vị chỉ cách một bảng tính. Các claim được review lại cần lịch sử theo từng claim để chính xác. Đó là một lỗ hổng thực sự trong Zealy và chúng tôi thà ghi lại nó còn hơn lách qua nó.

Phép tính, được ghi rõ là phép tính

Ở đây không có dữ liệu Zealy, nên đây là một khung để bạn điền bằng số của chính mình. Mọi đầu vào là một giả định bạn cung cấp, không phải một phép đo chúng tôi thực hiện.

weekly human-review load
  = claims per week
  × share of claims on text / URL / number / file / poll tasks
  × share of those not auto-validated
  × your own seconds per review

Giả sử 2.000 claim mỗi tuần, một phần ba thuộc các loại nhiệm vụ cần con người, không có tự động xác thực, mỗi claim 40 giây: khoảng 7,4 giờ mỗi tuần, hoàn toàn xây dựng từ những con số bạn cung cấp. Điểm mấu chốt không phải là câu trả lời. Mà là yếu tố thứ hai và thứ ba trở nên hiển hiện, và đó là hai yếu tố bạn có thể thay đổi mà không cần thuê ai.

Nơi các công cụ khác vượt Zealy ở điểm này

Bot Discord của Zealy không thực hiện kiểm duyệt. Nó không bao giờ kick, ban hay timeout ai, và không có tin nhắn chào mừng, reaction role, ticketing hay logging. Công cụ kiểm duyệt của chính Discord và các bot gốc Discord xây quanh chúng đảm nhận việc đó. API key của Zealy cũng chi tiết hơn nhiều so với các role dành cho người dùng.

Về điểm đầu tiên, chúng tôi đã tìm trong mã nguồn bot Discord của Zealy các lệnh gọi kick, ban, timeout, bulk-delete, guild-ban, AutoMod, moderate-members và audit-log, cùng tin nhắn chào mừng, reaction role, kênh thoại, ticket và logging. Kết quả khớp duy nhất là các dòng tắt caching. Khi cài đặt, nó còn cung cấp một bộ quyền hạn chế bên cạnh tùy chọn toàn quyền Administrator — Manage Roles, Mention Everyone và Send Messages — đúng là bộ quyền của thứ sẽ không kiểm duyệt gì cả. Nếu vấn đề của bạn là người dùng có hành vi sai trái trong máy chủ Discord của bạn, thì Zealy là công cụ sai: hướng dẫn về công cụ tương tác và phát triển Discord của chúng tôi là điểm khởi đầu tốt hơn — nó bao gồm các bot kiểm duyệt và cài đặt gốc của Discord xử lý phần lớn việc này miễn phí — và tài liệu tích hợp Discord mô tả những gì bot của Zealy thực sự làm.

Về điểm thứ hai, sự so sánh thật đáng xấu hổ và mang tính nội bộ. Mô hình API key của Zealy có 40 khả năng riêng biệt, bao gồm các khả năng riêng cho việc đọc review, xuất review và viết review, còn hai preset xây dựng quest của nó không có khả năng review nào cả. Đó là một mô hình đặc quyền tối thiểu thực sự: một cỗ máy giao tiếp với Zealy có thể được cấp quyền đọc hàng đợi review mà không được quyền quyết định.

Một người thì không thể. Một người chỉ nhận được một vị trí trên thang năm bậc, nên nếu bạn muốn ai đó phân loại và gắn cờ mà không phê duyệt, thì không có cách nào diễn đạt điều đó. API biết cách; mô hình role thì không. Khi mọi người hỏi chúng tôi về role tùy chỉnh, đây chính là khoảng trống họ gặp phải, và chỉ vào mô hình API key của chính chúng tôi là cách công bằng nhất để thừa nhận điều đó. Và một lần nữa, vì đây là vấn đề vận hành: bất kỳ công cụ nào được xây như một hàng đợi công việc đều giải quyết thông lượng nhiều người bằng việc phân công. Zealy giải quyết bằng một tin nhắn ghim trong kênh nhóm của bạn.

Cách thiết lập điều này trong Zealy, theo thứ tự

Kiểm tra xem những quest nào dùng năm loại nhiệm vụ dành cho người. Chuyển đổi những gì có thể. Đặt đáp án đúng cẩn thận, vì đáp án trống sẽ phê duyệt mọi thứ. Sau đó mời một hoặc hai người review qua liên kết có giới hạn và hết hạn, thống nhất bằng lời ai làm module nào, và chỉ sau đó mới quyết định xem review bằng AI có đáng nâng cấp gói hay không.

1. Đếm hàng đợi theo loại nhiệm vụ, không theo số lượng, rồi chuyển đổi những gì chuyển được. Điều quan trọng là có bao nhiêu claim đang chờ trên các nhiệm vụ text, URL, number, file và poll, và trong số đó, bao nhiêu đặt ra câu hỏi có đáp án xác định. Một câu hỏi có một đáp án đúng sẽ trở thành quiz hoặc nhiệm vụ text có đáp án đúng; một ảnh chụp màn hình chứng minh bạn đã làm sẽ trở thành nhiệm vụ on-chain, link hoặc tích hợp ở bất cứ đâu hành động để lại dấu vết mà Zealy có thể kiểm tra.

2. Kiểm thử mọi tự động xác thực bạn bật, rồi bật từ chối trùng lặp ở nơi copy-paste là kiểu thất bại. Hãy tự claim nhiệm vụ với một đáp án sai và xác nhận nó thất bại; thói quen hai phút đó bắt được cái bẫy đáp án đúng trống. Từ chối trùng lặp mặc định tắt trên nhiệm vụ text và URL và sẽ không bắt được một bản diễn đạt lại.

3. Thăng cấp người review, không phải người biên tập, qua liên kết mời có giới hạn. Đặt ngày hết hạn và số lần sử dụng tối đa, và nói rõ bằng văn bản với người đó rằng role này có thể cấp tới 20.000 XP thưởng mỗi claim, trên tối đa 1.000 claim trong một lần thao tác, và rằng bạn có thể thấy mọi phán quyết.

4. Phân chia hàng đợi trong một tin nhắn ghim. Theo module, theo ngày, hoặc cũ nhất trước so với mới nhất trước. Sản phẩm sẽ không làm việc đó cho bạn, và hai người trên một hàng đợi không phân chia sẽ làm trùng việc.

5. Chỉ bây giờ mới cân nhắc review bằng AI. Nếu tiêu chuẩn có thể viết ra được, khối lượng lớn và bạn đang dùng Plus hoặc Enterprise, hãy viết prompt như tin nhắn từ chối mà bạn thấy thoải mái khi gửi, vì đó chính là thứ nó sẽ trở thành. Bắt đầu với một quest và đọc năm mươi bình luận đầu tiên nó viết trước khi bật ở bất kỳ nơi nào khác.

6. Xuất dữ liệu hàng tháng và tự tính thời gian review của bạn. Zealy sẽ không tính giúp. Trừ timestamp created của mỗi claim cho timestamp updated của nó trong file CSV xuất ra; điều đó chính xác với các claim được review một lần, còn các claim được review lại cần lịch sử review của chúng. Mười phút trong bảng tính sẽ cho bạn biết liệu có phần nào trong số này hiệu quả không.

Mạch xuyên suốt là câu hỏi "tôi có cần thuê người không" gần như luôn là câu hỏi sai, được hỏi muộn một quyết định thiết kế. Hãy giao cho một quy tắc trước, vì đó là con đường duy nhất khiến công việc biến mất thay vì chuyển đi. Giao cho một người thứ hai, và thành thật với họ về quyền lực XP và các xung đột. Giao cho một cỗ máy cuối cùng, và chỉ khi bạn viết được tiêu chuẩn ra. Để có bối cảnh rộng hơn, module kiến thức cơ bản về quản lý cộng đồng là bài đồng hành và tài liệu review của Zealy bao quát cơ chế hàng đợi. Và nếu bạn chưa chốt công cụ, khảo sát phần mềm quản lý cộng đồng của chúng tôi định giá toàn bộ hạng mục rộng hơn, bao gồm cả lao động kiểm duyệt.