Chia nhỏ nhiệm vụ phức tạp

Giao cho Claude một việc lớn trong một lần thường cho kết quả không đều: chỗ làm kỹ, chỗ làm qua loa. Cách sửa là chia nhỏ. Nhưng chia thế nào thì tuỳ loại việc.

Bài này giúp bạn trả lời: khi nào nên chia thành các bước cố định từ trước, khi nào nên để agent tự quyết bước tiếp theo dựa vào những gì nó vừa tìm thấy?

Ví dụ xuyên suốt: phần mềm đặt lịch khám của một phòng khám

Một nhóm phát triển phần mềm đặt lịch khám cho chuỗi phòng khám nha khoa. Họ dùng Claude cho hai việc:

1. Review pull request: tuần này có một pull request sửa 18 file để thêm tính năng đặt lịch nhắc tái khám.
2. Viết test cho phần code cũ: phần quản lý hồ sơ bệnh nhân viết từ 5 năm trước, gần như không có test. Trưởng nhóm giao: "Thêm test đầy đủ cho phần này."

Hai việc này cần hai cách chia khác nhau.

Hai cách chia việc

Bài viết Building effective agents của Anthropic mô tả prompt chaining là chia việc thành chuỗi bước, mỗi lần gọi model xử lý kết quả của lần trước. Cách này hợp khi việc chia được gọn thành các bước cố định, và đổi thêm chút thời gian lấy độ chính xác cao hơn, vì mỗi bước là một việc dễ hơn.

Còn khi không đoán trước được cần những bước nào, bài viết đó gợi ý mô hình orchestrator-workers: một model tự chia việc tuỳ theo đầu vào, giao cho các model khác, rồi gom kết quả. Ví dụ họ đưa ra chính là sửa code: số file cần sửa và cách sửa mỗi file phụ thuộc vào từng yêu cầu.

Review pull request nhiều file

Nhóm thử đưa cả 18 file cho Claude review trong một lần. Kết quả: vài file được nhận xét rất kỹ, nhiều file chỉ được một câu chung chung, một lỗi rõ ràng bị bỏ sót. Tệ hơn, Claude chê một cách viết ở file này nhưng lại khen đúng cách viết đó ở file khác.

Nguyên nhân là sự chú ý bị dàn mỏng ra quá nhiều file cùng lúc. Tiếng Anh gọi là attention dilution.

Cách sửa là chia thành hai loại lượt review:

1. Lượt cục bộ (per-file local analysis pass): mỗi file một lượt, chỉ tìm lỗi trong file đó. Nhờ vậy file nào cũng được xem kỹ như nhau.
2. Lượt liên kết (cross-file integration pass): sau khi xong mọi file, chạy thêm một lượt riêng xem dữ liệu đi qua các file, chỗ các file gọi nhau. Lượt này bắt những lỗi chỉ thấy khi nhìn nhiều file cùng lúc, ví dụ file A đổi tên một trường mà file B vẫn dùng tên cũ.
3. Gộp nhận xét của hai loại lượt thành bản review cuối.

Việc mở: viết test cho code cũ

"Thêm test đầy đủ" là một việc mở. Không ai biết trước phần code cũ có bao nhiêu module, module nào phụ thuộc module nào, chỗ nào hay hỏng nhất. Lập sẵn danh sách "bước 1, bước 2, bước 3" lúc này là đoán mò.

Cách làm hợp lý là chia dần theo những gì phát hiện được:

1. Vẽ bản đồ: xem cấu trúc thư mục, các module chính, chỗ nào gọi chỗ nào.
2. Tìm chỗ quan trọng: phần nào dùng nhiều nhất, phần nào lỗi thì hậu quả lớn nhất, ví dụ phần lưu lịch sử điều trị.
3. Lập kế hoạch có thứ tự ưu tiên: viết test cho chỗ quan trọng trước.
4. Sửa kế hoạch khi phát hiện thêm: viết test module A mới thấy nó phụ thuộc module B chưa có test, thì đưa B lên trước.

Đề thi gọi kiểu kế hoạch này là adaptive investigation plan: kế hoạch tự sinh ra việc mới dựa trên những gì tìm thấy ở mỗi bước.