Kỹ thuật debug “con vịt cao su” (rubber duck) hiệu quả vì việc giải thích suy nghĩ của mình cho một thứ không thể phản bác buộc bạn tự nhận ra lỗ hổng. VS Code 1.135, ra mắt trong chu kỳ phát hành tháng 8/2026, lấy ý tưởng đó và cho con vịt một ý kiến riêng. Lệnh mới /rubber-duck trong phiên Copilot Agent Host gọi một model AI thứ hai — cố tình khác với model đang điều khiển phiên làm việc của bạn — để phản biện kế hoạch, code, hoặc test của agent chính và chỉ ra những gì bị bỏ sót. Đây không còn là debug con vịt cao su nữa. Đây là review đối kháng, được tích hợp sẵn trong editor, gọi ra khi cần.

Những Gì Đã Ra Mắt

VS Code 1.135 giới thiệu Agent Host Protocol, và ba tính năng được xây trên nền đó:

  • /rubber-duck — lệnh thử nghiệm giao kế hoạch, diff, hoặc bộ test hiện tại cho một model khác để phản biện. Nếu phiên chính của bạn đang chạy Claude, con vịt có thể chạy GPT hoặc Gemini, và ngược lại — điểm mấu chốt là một model thực sự khác, không phải cùng model tự hỏi lại chính mình.
  • Tiếp tục phiên từ ứng dụng khác — phiên agent bắt đầu ở ứng dụng khác (ví dụ chạy Claude Code CLI) giờ xuất hiện trong danh sách Sessions của VS Code, và bạn có thể tiếp tục giữa chừng mà không mất ngữ cảnh.
  • Kết nối phiên đa cửa sổ — Agent Host cho phép nhiều cửa sổ VS Code cùng kết nối vào một phiên agent đang chạy, để bạn có thể theo dõi (hoặc điều khiển) một agent chạy dài từ nhiều nơi.
# trong một phiên Copilot Agent Host đang hoạt động trên VS Code
/rubber-duck

# model phản biện nhận: kế hoạch hiện tại, diff đến thời điểm này, kết quả test
# nó trả lời bằng một phản biện có cấu trúc — không phải viết lại, mà là đánh giá

Điểm khác biệt quan trọng: /rubber-duck không giao quyền điều khiển cho model thứ hai. Nó vẫn chỉ là người phản biện. Agent chính vẫn dẫn dắt; con vịt chỉ được một lượt chính thức để nói “bạn đã xem xét X chưa” trước khi bạn chốt kế hoạch.

Vì Sao Cần Model Khác, Không Phải Cùng Model Hỏi Lại Chính Nó

Tự phản biện từ một model duy nhất có một điểm yếu đã biết: chính bộ trọng số tạo ra điểm mù đó thường cũng là bộ trọng số đánh giá xem điểm mù đó có tồn tại hay không. Yêu cầu Claude review kế hoạch của chính Claude bắt được lỗi bề mặt — một edge case bị bỏ sót trong logic rõ ràng sai — nhưng yếu hơn nhiều trong việc phát hiện kiểu thiên lệch hệ thống khi cả cách tiếp cận vấn đề của model đã hơi lệch. Một model có cấu trúc khác biệt, được huấn luyện khác, thường bất đồng ở những chỗ hữu ích hơn.

Điều này giống với những gì các tổ chức kỹ thuật tốt đã làm với review của con người: bạn không muốn tác giả PR tự review PR của mình, và bạn nhận được nhiều giá trị hơn từ một reviewer suy nghĩ khác về vấn đề so với người sẽ viết y hệt. VS Code chỉ tự động hóa bước “tìm người tiếp cận khác” đó và biến nó thành một lệnh slash thay vì một tin nhắn Slack.

Nó Thực Sự Hữu Ích Ở Đâu

Review kế hoạch trước khi có code. Gọi /rubber-duck cho một kế hoạch triển khai đề xuất — trước khi agent chính viết một dòng nào — là thời điểm có đòn bẩy cao nhất để dùng lệnh này. Bắt được “cách tiếp cận này không xử lý được ghi đồng thời” ở giai đoạn kế hoạch chỉ tốn một vòng phản biện. Bắt được nó sau 200 dòng code đã sinh ra thì tốn một lần viết lại.

Lỗ hổng độ phủ test. Chỉ con vịt vào một bộ test đã sinh ra và yêu cầu nó tìm nhánh chưa được test khai thác đúng một điểm mạnh cụ thể: một model thứ hai không có “đầu tư” vào lựa chọn viết test của model đầu tiên sẽ dễ nhận ra “không có test cho trường hợp input rỗng” hơn model vừa viết test đó và, một cách ngầm định, tin rằng chúng đã đủ.

Quyết định kiến trúc có đánh đổi thực sự. Với bất cứ điều gì cần phán đoán thực sự — chiến lược vô hiệu hóa cache, thiết kế retry/backoff, cách tiếp cận migration schema — phản biện từ một model được huấn luyện khác đưa ra góc nhìn thay thế nhanh hơn việc hỏi lại cùng model “bạn chắc chứ?”, vốn thường tạo ra sự đồng ý lịch sự hơn là phản bác thực chất.

Nó Không Thay Thế Được Gì

/rubber-duck không phải là thứ thay thế cho review code của con người, và coi nó như vậy là sai lầm cần tránh trong team của bạn. Nó bắt được một loại lỗi khác với reviewer là con người — nó rất giỏi phát hiện “bạn đã xem xét edge case này chưa” nhưng yếu về mặt cấu trúc ở “điều này có khớp với cách team muốn tính năng này hoạt động không,” “điều này có nhất quán với ba nơi khác chúng ta đã giải quyết vấn đề tương tự không,” hay “điều này có đưa ra một giả định bảo mật mà mô hình đe dọa của chúng ta chưa bao phủ không.” Những câu hỏi đó cần ngữ cảnh mà model phản biện không có trừ khi bạn chủ động cung cấp, và ngay cả khi đó, một con người hiểu lịch sử codebase vẫn có phán đoán mà vòng phản biện này không thay thế được.

Kết nối phiên đa cửa sổ cũng có ranh giới tương tự: nó thực sự hữu ích cho một tech lead muốn quan sát một tác vụ agent chạy dài từ máy thứ hai mà không làm gián đoạn, nhưng nó không phải là tính năng quản trị. Bất kỳ ai có quyền truy cập phiên đó đều có thể điều khiển nó, vì vậy hãy đối xử với quyền truy cập phiên chia sẻ cẩn thận như bạn đối xử với credential production chia sẻ.

Cách Áp Dụng Thực Tế

  1. Mặc định dùng /rubber-duck ở bước review kế hoạch, không phải bước diff cuối cùng. Bắt được cách tiếp cận sai càng sớm, chi phí sửa càng thấp — điều này đúng dù người phản biện là con người hay model.
  2. Chọn model phản biện khác biệt có chủ đích với model điều khiển. Nếu team bạn chuẩn hóa dùng Claude cho agent chính, đừng mặc định con vịt cũng chạy một phiên Claude khác — toàn bộ giá trị của tính năng này phụ thuộc vào sự khác biệt kiến trúc, không chỉ là một cửa sổ ngữ cảnh mới.
  3. Đừng bỏ qua review của con người chỉ vì con vịt đã duyệt. Ghi lại những gì con vịt phát hiện và những gì nó bỏ sót trong vài tuần. Nhật ký đó cho bạn biết cụ thể nó tạo giá trị ở đâu trên codebase của bạn và reviewer con người vẫn đang làm công việc mà không vòng phản biện model-với-model nào thay thế được.
  4. Dùng tính năng tiếp tục phiên từ ứng dụng khác để bàn giao, không phải để chạy song song. Tiếp tục một phiên bắt đầu từ CLI trong VS Code để hoàn thành review là cách dùng tốt. Chạy cùng một phiên được điều khiển bởi hai người cùng lúc, kỳ vọng nó hoạt động dự đoán được, là tự chuốc lấy đúng kiểu race condition mà việc cô lập worktree được xây ra để ngăn chặn ngay từ đầu.

Mô Hình Đằng Sau Tính Năng

Đây là cùng một quỹ đạo mà công cụ multi-agent đã đi suốt năm nay: workflow một model đang nhường chỗ cho workflow đa model có cấu trúc, nơi các model khác nhau đóng vai trò khác nhau có chủ đích — người điều khiển và người phản biện, người tạo và người xác minh, người triển khai và người review. Điều thú vị không phải là một model thứ hai có thể bắt lỗi mà model đầu tiên mắc phải. Mà là các editor giờ đang tích hợp sẵn cơ chế điều phối cho mô hình đó như một tính năng có sẵn, thay vì để team tự nối các API call riêng lẻ và code kết dính tùy chỉnh. Hãy kỳ vọng phiên bản tiếp theo sẽ chính thức hóa vai trò sâu hơn — một người phản biện cũng chạy một phần test, hay một người phản biện tập trung vào bảo mật khác với người tập trung vào tính đúng đắn — thay vì dừng lại ở một lệnh /rubber-duck chung chung duy nhất.

Thuận Lương là Technical Lead với hơn 15 năm kinh nghiệm về .NET, kiến trúc cloud và hệ thống AI. Anh viết về những bài học thực tế từ việc xây dựng hệ thống production.

Xuất nội dung

Bình luận