Claudecode bản desktop mới: Thay đổi gì trong cách chia và theo dõi tác vụ?

Bạn giao cho Claudecode sửa một màn hình. Trong lúc làm, nó phát hiện phần hướng dẫn cũng cần cập nhật và một nhánh xử lý chưa có kiểm thử. Nếu dồn tất cả vào một cuộc trò chuyện, việc theo dõi từng phần sẽ khó hơn. Nếu mở nhiều cuộc trò chuyện rời rạc, bạn lại phải tự gom kết quả.

Bản cập nhật desktop được công bố ngày 14/10/2026 theo UTC, tức ngày 15/10 theo giờ Việt Nam, tập trung vào chính luồng công việc này: đề xuất tác vụ tiếp theo, phiên lồng nhau, trạng thái rõ hơn và môi trường làm việc có thể lưu lại.

Một thành viên nhóm phát triển gọi thay đổi này là “gần như v2”. Đây là nhận xét về mức độ thay đổi, không phải tên phiên bản chính thức. Trong bài này, mình đi vào từng phần của luồng làm việc mới, thay vì coi câu nói đó là lời hứa về tốc độ.

Hình minh họa được tạo bằng image2, không phải ảnh chụp giao diện thực tế.

1. Trước khi giao việc, chọn đúng nơi chạy

Màn hình tạo phiên mới giúp truy cập các thư mục gần đây thuận tiện hơn. Những môi trường thường dùng, chẳng hạn tổ hợp thư mục, máy chủ SSH hoặc môi trường cloud, cũng có thể được lưu để chọn lại.

Một “phiên” ở đây là cuộc làm việc với Claudecode quanh một tác vụ. “Môi trường” là nơi tác vụ đó chạy và truy cập dự án. Hai khái niệm liên quan với nhau nhưng không thay thế cho nhau: mở đúng cuộc trò chuyện chưa đủ nếu bạn chọn nhầm thư mục dự án.

Với dự án Git, worktree cho phép dùng một thư mục làm việc riêng. Nhờ vậy, hai phiên có thể chỉnh sửa ở hai bản làm việc khác nhau, giảm việc trực tiếp ghi vào cùng các tệp.

Tuy nhiên, tách thư mục không có nghĩa là mọi thay đổi đều ghép được ngay. Nếu hai tác vụ hiểu khác nhau về dữ liệu trả về của một hàm, bạn vẫn phải xử lý sự khác biệt đó khi tích hợp. Mình sẽ kiểm tra vị trí làm việc trước khi giao các tác vụ có quyền sửa mã, thay vì mặc định rằng “phiên riêng” luôn đồng nghĩa với “tệp riêng”.

2. Tách việc phát sinh khỏi việc đã thống nhất

Claudecode có thể đưa ra đề xuất cho các tác vụ tiếp theo. Khi chọn một đề xuất, bạn có thể mở phần việc đó trong một phiên mới, còn cuộc trò chuyện hiện tại tiếp tục.

Một việc phát sinh có thể được tách ra thay vì kéo dài cuộc trò chuyện hiện tại.

Ví dụ, sửa xong thông báo lỗi đăng nhập có thể làm lộ ra đoạn tài liệu mô tả thông báo cũ. Cập nhật tài liệu là một tác vụ tiếp theo hợp lý. Nhưng nó vẫn là phần việc cần được chọn: không phải mọi gợi ý đều phải làm ngay trong lần sửa này.

Đó là điểm mình muốn phân biệt với phiên lồng nhau. Khi yêu cầu Claude chia một công việc thành các phần có thể chạy song song, những phiên lồng nhau có thể thực hiện từng phần và báo cáo kết quả về cuộc trò chuyện chính.

Nói cách khác, đề xuất giúp bạn quyết định có làm thêm việc gì; phiên lồng nhau giúp tổ chức các phần đã được giao và thu kết quả về. Nếu chỉ quan tâm đến việc mở thêm cửa sổ, bạn sẽ bỏ qua phần hữu ích nhất của cơ chế này.

Với người đồng thời dùng CLI, hướng dẫn kết nối Claudecode của Crazyrouter giải thích cấu hình API ở phía công cụ dòng lệnh. Cấu hình đó cần được phân biệt với môi trường desktop vừa nói đến; không nên suy ra rằng làm theo hướng dẫn CLI sẽ tự mở được mọi tính năng trong ứng dụng desktop.

3. Viết yêu cầu để các phiên không giẫm chân nhau

Giả sử bạn đã thống nhất cách màn hình đăng nhập xử lý ba trường hợp: sai mật khẩu, mất kết nối và lỗi máy chủ. Lúc này, việc kiểm tra các ca còn thiếu và rà soát câu chữ có thể tách riêng.

Một yêu cầu minh họa có thể viết như sau:

Kiểm tra các ca kiểm thử còn thiếu và nội dung thông báo lỗi bằng hai tác vụ riêng. Giữ nguyên cấu trúc dữ liệu lỗi đã thống nhất. Với mỗi vấn đề, báo lại tệp liên quan, lý do cần sửa và đề xuất thay đổi trong cuộc trò chuyện này.

Đây là ví dụ cách giao việc, không phải nhật ký chạy thử. Nó nêu ba điều mà người nhận việc cần biết: phạm vi được kiểm tra, phần không được tự thay đổi và dạng kết quả cần trả về.

Nếu chưa quyết định cấu trúc dữ liệu lỗi mà đã cho nhiều phiên tự thiết kế, kết quả dễ đi theo nhiều hướng. Khi đó, nên chốt giao diện chung trước. Chạy song song phù hợp hơn khi các phần việc có thể được đánh giá riêng mà không phải liên tục chờ quyết định của nhau.

4. Dùng trạng thái để chọn việc cần xem trước

Thanh bên được cập nhật để giúp phân biệt các phiên đang chạy, cần bạn xử lý hoặc đã hoàn thành. Trong phiên, danh sách tác vụ thể hiện tiến độ theo kế hoạch; thẻ tóm tắt giúp nắm những gì đã diễn ra khi cần quay lại.

Trạng thái là điểm bắt đầu để tìm phiên cần chú ý, không phải kết luận về chất lượng mã.

Sau một khoảng nghỉ, mình sẽ mở phiên cần quyết định trước, đọc tóm tắt rồi xem phần thay đổi liên quan. Cách này tận dụng được giao diện mới mà vẫn giữ bước kiểm tra kết quả.

Chẳng hạn, nếu bản tóm tắt nói đã bổ sung kiểm thử, hãy xem kiểm thử đó kiểm tra trường hợp nào. Nếu nhiệm vụ chỉ cho phép sửa câu chữ mà diff có thay đổi xử lý lỗi, cần làm rõ lý do. Nhãn “hoàn thành” cho biết phiên đã kết thúc một phần việc; nó không tự xác nhận rằng phạm vi và yêu cầu đều được đáp ứng.

5. Hỏi thêm bằng /btw, nhưng đổi yêu cầu ở phiên chính

Trong khi tác vụ chạy, bạn có thể muốn hỏi: “Vì sao cần thử lại yêu cầu này?” Lệnh /btw mở một cuộc trò chuyện bên cạnh để hỏi mà công việc chính vẫn tiếp tục. Phím tắt là Cmd + ; trên macOS hoặc Ctrl + ; trên Windows.

Cuộc trò chuyện phụ có thể dùng ngữ cảnh của phiên chính đến thời điểm đó.

Tính năng này đã tồn tại trước bản cập nhật tháng 10. Việc nó xuất hiện trong phần trình diễn không có nghĩa là nó vừa được bổ sung lần đầu.

Điểm cần nhớ là ngữ cảnh đi theo một chiều. Cuộc trò chuyện phụ đọc được nội dung chính đến thời điểm mở, nhưng các câu hỏi và câu trả lời của nó không được ghi ngược vào phiên chính.

Vì vậy, hỏi để hiểu một lựa chọn kỹ thuật thì phù hợp. Nếu sau khi đọc giải thích bạn muốn đổi cách triển khai, hãy đưa yêu cầu mới vào cuộc trò chuyện chính. Nếu không, tác vụ đang chạy chưa nhận được quyết định đó.

Cuộc trò chuyện phụ cũng không được lưu xuống đĩa và không thể khôi phục sau khi đóng ứng dụng. Những nội dung cần giữ lại phải được chép sang ghi chú hoặc nơi lưu trữ phù hợp.

6. Bắt đầu từ một tác vụ nhỏ sau khi cập nhật

Hãy cập nhật ứng dụng desktop và mở một phiên mới. Trong phiên desktop chạy cục bộ, /status giúp xem phiên bản Claudecode đang được dùng. Bản CLI cài riêng trong terminal và bản đi kèm ứng dụng được cập nhật độc lập; cập nhật CLI không đồng nghĩa với cập nhật desktop.

Để tìm hiểu luồng mới, một nhiệm vụ chính và một phần việc độc lập là đủ. Quan sát tác vụ mới xuất hiện ở đâu, khi nào nó cần phản hồi và kết quả quay về chỗ nào. Sau đó mới tăng độ phức tạp nếu cách tổ chức này phù hợp với dự án.

Điều đáng đánh giá ở bản cập nhật này là khả năng theo dõi và thu kết quả khi công việc được chia ra. Chưa có số liệu thực đo thì không nên kết luận tốc độ tăng gấp đôi hay chi phí token giảm. Với mình, câu hỏi hữu ích hơn là: sau khi các phiên làm xong, bạn có hiểu rõ thay đổi nào cần kiểm tra và quyết định nào vẫn còn chờ không?