do-and-judge

Tổng quan về skill do-and-judge

do-and-judge làm gì

Skill do-and-judge là một mẫu thực thi đơn nhiệm cho tự động hóa quy trình: nó chuyển công việc cho một sub-agent triển khai, tạo một rubric đánh giá riêng, rồi thử lại cho đến khi kết quả đạt yêu cầu hoặc chạm giới hạn retry. Đây là lựa chọn phù hợp nhất cho những việc mà chất lượng phụ thuộc vào việc xác minh bên ngoài, chứ không chỉ là sinh ra nội dung một lần.

Ai nên dùng

Hãy dùng do-and-judge khi bạn cần một agent hoàn thành một tác vụ có phạm vi rõ ràng và có tiêu chí chấp nhận đo được, chẳng hạn như refactor, chỉnh sửa code hoặc thay đổi nội dung có cấu trúc. Đây là lựa chọn tốt nếu bạn muốn giảm tự-kiểm tra vòng quanh và tăng kiểm tra độc lập trước khi chấp nhận đầu ra.

Điểm khác biệt nổi bật

Giá trị lớn nhất của skill do-and-judge nằm ở việc tách vai trò: orchestrator không tự làm task, implementation agent làm việc với context mới, và judge đánh giá theo một đặc tả riêng. Thiết kế đó giúp giảm điểm mù và khiến việc cài do-and-judge trở nên đáng giá khi độ chính xác quan trọng hơn tốc độ đơn thuần.

Cách dùng skill do-and-judge

Cài đặt và thiết lập do-and-judge

Cài skill do-and-judge vào workspace skills của bạn, rồi mở SKILL.md trước tiên vì file này chứa quy tắc vận hành và luồng điều khiển. Nếu muốn rà nhanh repo, hãy đọc SKILL.md trước mọi thứ khác; ở đây không có helper script hay thư mục hỗ trợ để dựa vào, nên file skill chính là nguồn thông tin chuẩn.

Biến yêu cầu mơ hồ thành đầu vào dùng được

Mẫu do-and-judge usage hoạt động tốt nhất khi task hẹp, kiểm thử được và có điểm kết thúc rõ ràng. Thay vì nói “cải thiện module này”, hãy cung cấp:

• file hoặc component đích chính xác
• kết quả mong muốn
• các ràng buộc không được thay đổi
• điều kiện pass/fail hoặc hành vi kỳ vọng

Ví dụ prompt mạnh: Refactor the UserService class to use dependency injection without changing public method names; verify that all existing tests still pass and that constructor wiring is explicit.

Quy trình khuyến nghị

Một do-and-judge guide thực tế là: xác định task, để implementation agent làm việc trong isolation, tạo judge rubric, kiểm tra kết quả theo rubric đó, rồi chỉ retry khi có lỗi cụ thể. Quy trình này được thiết kế cho do-and-judge for Workflow Automation, nơi mục tiêu là thực thi có kiểm soát chứ không phải brainstorming mở.

Cần chú ý gì trong repo

Đọc SKILL.md để nắm quy trình, các ràng buộc quan trọng và ngưỡng retry. Hãy chú ý kỹ các phần về phạm vi task, cách xử lý context và các tín hiệu cảnh báo, vì chúng quyết định orchestrator có hoạt động đúng hay không. Nếu bạn đang chỉnh skill này cho stack khác, hãy map các quy tắc đó sang tooling của riêng bạn trước khi đem áp dụng vào task thật.

Câu hỏi thường gặp về skill do-and-judge

do-and-judge có tốt hơn prompt thông thường không?

Với yêu cầu đơn giản thì không. Prompt thường nhanh hơn. do-and-judge phù hợp hơn khi bạn cần một task vừa được triển khai vừa được xác minh độc lập, nhất là khi câu trả lời đầu tiên dễ bỏ sót edge case hoặc lệch khỏi yêu cầu.

Skill này có thân thiện với người mới không?

Có, nếu bạn có thể mô tả task rõ ràng. Đường cong học tập chính không nằm ở cú pháp; nó nằm ở việc cung cấp đủ context của task và tiêu chí chấp nhận để judge đánh giá đầu ra mà không phải đoán.

Khi nào không nên dùng do-and-judge?

Đừng dùng do-and-judge cho khám phá mở, lên ý tưởng mơ hồ, hoặc những task mà thành công rất khó định nghĩa. Nó cũng không phù hợp khi bạn muốn orchestrator trực tiếp sửa file hoặc chạy tool, vì skill này được xây dựng quanh việc tách vai trò và xác minh.

Nó phù hợp với Workflow Automation như thế nào?

Nó phù hợp nhất như một lớp kiểm soát cho các job đơn lẻ, có phạm vi rõ ràng, nằm trong một hệ thống tự động hóa lớn hơn. Nếu workflow của bạn đã có các bước kiểm tra rõ ràng, skill này sẽ tăng giá trị bằng cách cấu trúc vòng lặp agent; nếu workflow chưa có tiêu chí chấp nhận, bước judge sẽ quá mơ hồ để hữu ích.

Cách cải thiện skill do-and-judge

Đưa ra tiêu chí tốt hơn cho judge

Cải thiện chất lượng lớn nhất đến từ đầu vào đánh giá mạnh hơn. Khi dùng do-and-judge, hãy chỉ rõ thế nào là “tốt” bằng các tiêu chí quan sát được: hành vi bắt buộc, thay đổi bị cấm, mục tiêu coverage, ràng buộc định dạng hoặc quy tắc tương thích. Tiêu chí càng cụ thể, judge càng ít có khả năng chấp nhận một kết quả yếu.

Giảm các lỗi thường gặp

Lỗi phổ biến nhất là phạm vi không được đặc tả đủ. Nếu task quá rộng, implementation agent có thể tối ưu sai chỗ và judge chỉ phát hiện ra muộn. Một lỗi khác là các ràng buộc ẩn, như tương thích ngược, quy ước đặt tên hoặc giới hạn môi trường, vì vậy hãy nêu ngay từ đầu thay vì trông đợi vòng retry tự suy ra.

Lặp lại trên đầu ra đầu tiên

Nếu lần chạy đầu chưa đúng, đừng chỉ lặp lại nguyên task cũ. Hãy phản hồi chính xác các lỗi mà judge chỉ ra, siết lại tiêu chí chấp nhận và loại bỏ ngôn ngữ mơ hồ. Với do-and-judge usage, lần thử thứ hai nên hẹp hơn và kiểm thử được hơn lần đầu.

Tăng độ phù hợp trước khi chạy lại

Nếu bạn đang điều chỉnh do-and-judge cho một repo khác hoặc một agent stack khác, hãy căn chỉnh trước các quy tắc orchestration với tooling của bạn. Kiểm tra xem hệ thống của bạn có thực sự hỗ trợ được việc triển khai tách biệt, đánh giá độc lập và retry có giới hạn hay không; nếu không, hãy đơn giản hóa mẫu này thay vì cố ép nó vào.