4 tật của agent viết code và prompt để chữa

Agent viết code ngày càng giỏi, nhưng vẫn có vài "tật" quen thuộc: sửa một bug thì tiện tay refactor cả module, tạo thêm chục file helper, viết code chỉ để test xanh, hay tự tin nói về một file nó chưa hề mở. Hướng dẫn prompting chính thức của Anthropic có hẳn một phần cho các tình huống này, kèm prompt mẫu dùng được ngay. Bài này gom bốn tật phổ biến nhất và cách "chữa" bằng chỉ dẫn.

Bốn tật và cách chữa

1. Chống làm quá

Tài liệu nêu rõ một số model Opus có xu hướng over-engineer. Ý chính của prompt mẫu (viết lại ngắn gọn):

Tránh làm quá. Chỉ thay đổi những gì được yêu cầu hoặc thật sự cần.
- Phạm vi: sửa bug không cần dọn code xung quanh.
- Tài liệu: không thêm docstring/comment cho code bạn không sửa.
- Phòng thủ: không xử lý lỗi cho tình huống không thể xảy ra;
  chỉ validate ở biên hệ thống (input người dùng, API ngoài).
- Abstraction: không tạo helper cho thao tác dùng một lần.

2. Chống code chỉ để qua test

Viết giải pháp tổng quát, đúng với mọi input hợp lệ, không chỉ test case.
Không hard-code giá trị hay xử lý riêng cho input của test.
Test dùng để kiểm chứng, không định nghĩa lời giải.
Nếu yêu cầu bất khả thi hoặc test sai, hãy báo lại thay vì lách.

Câu cuối quan trọng nhất: cho agent một "lối thoát" hợp lệ để không phải gian lận khi bị dồn.

3. Dọn file tạm

Tài liệu giải thích việc tạo file tạm (thường là script Python) đôi khi giúp kết quả tốt hơn vì đó là "giấy nháp". Không cần cấm, chỉ cần dặn: nếu tạo file tạm để thử, hãy xoá khi xong việc.

4. Điều tra trước khi trả lời

<investigate_before_answering>
Không suy đoán về code bạn chưa mở. Nếu người dùng nhắc tới một file,
phải đọc file đó trước khi trả lời. Đừng khẳng định gì về codebase
trước khi điều tra, trừ khi chắc chắn.
</investigate_before_answering>

Lưu ý về giọng điệu chỉ dẫn

Model mới nhạy với system prompt hơn. Tài liệu khuyên bỏ kiểu viết hét "CRITICAL: You MUST…" từng dùng cho model cũ, vì giờ nó dễ khiến model làm quá tay theo chiều ngược lại. Viết bình thường, giải thích lý do là đủ.

Rủi ro và lưu ý

• Đừng nhồi mọi chỉ dẫn vào mọi dự án: chỉ thêm khi thấy đúng tật đó xuất hiện; CLAUDE.md dài làm loãng chỉ dẫn quan trọng.
• Tối thiểu ≠ cẩu thả: vẫn yêu cầu validate ở biên hệ thống và kiểm thử.
• Chỉ dẫn không phải cưỡng chế: việc bắt buộc (lint, test phải chạy) hãy dùng hook hoặc CI.

Áp dụng thế nào?

• Dev: Khi review diff của agent thấy file lạ hay refactor ngoài phạm vi, thêm đoạn chống làm quá vào CLAUDE.md.
• Tech Lead: Đưa chỉ dẫn "báo lại nếu test sai" vào quy ước chung; review kỹ mọi thay đổi trong file test.
• PM: Đo tỷ lệ thay đổi ngoài phạm vi trong PR do agent tạo như một chỉ số chất lượng.