Workflow thực tế trong Claude Dispatch: Code & Phát triển

Đánh giá code từ khi đào tạo

Tóm tắt nhanh: Trong bài học 3, chúng ta đã lập bản đồ những gì Dispatch có thể truy cập - toàn bộ hệ thống file của bạn, hướng dẫn Global và (một số) connector. Bây giờ, hãy sử dụng quyền truy cập đó cho công việc phát triển thực tế.

Sáng thứ Bảy. Bạn đang trên tàu đến thăm gia đình. Điện thoại của bạn rung lên - một đồng nghiệp đã đẩy một yêu cầu PR và cần được phê duyệt trước khi triển khai vào thứ Hai. Các thay đổi liên quan đến mô-đun xác thực. Thông thường bạn sẽ cần laptop của mình cho việc này.

Với Claude Dispatch, bạn không cần.

Điều cần lưu ý về quy trình làm việc của nhà phát triển trên Dispatch là: Chúng hoạt động tốt một cách đáng ngạc nhiên đối với các tác vụ đọc nhiều và hoạt động kém hiệu quả một cách bất ngờ với những tác vụ yêu cầu ghi nhiều. Mấu chốt là phải biết cái nào là cái nào và cấu trúc các tác vụ của bạn cho phù hợp.

Workflow 1: Đánh giá Pull Request (PR)

Đánh giá PR là điểm mạnh của Dispatch đối với các nhà phát triển. Nó chủ yếu là đọc, phân tích và cung cấp phản hồi - chính xác là những gì Dispatch xử lý tốt.

Bước 1: Xem tóm tắt

Hãy xem PR mới nhất trong ~/projects/my-app. Cho tôi biết những file nào đã thay đổi,
có bao nhiêu dòng được thêm/xóa và tóm tắt bằng một đoạn văn
về những gì PR này thực hiện.

Đây là thao tác đọc. Nó sẽ thành công trong hầu hết mọi trường hợp.

Bước 2: Đi sâu vào chi tiết

Dựa trên bản tóm tắt, hãy hỏi về các file quan trọng nhất:

Cho tôi xem những thay đổi trong src/auth/login.ts từ PR mới nhất.
Tập ​​trung vào các thay đổi liên quan đến bảo mật.

Bước 3: Kiểm tra các dấu hiệu đáng ngờ

Trong các file được thay đổi bởi PR này, có bất kỳ:
- Thông tin đăng nhập hoặc API key được hardcode
- Truy vấn SQL không có tham số hóa
- Thiếu xử lý lỗi trong các hàm bất đồng bộ
- Các câu lệnh Console.log cần được xóa

Bước 4: Đưa ra phản hồi

Dựa trên đánh giá của bạn, hãy viết phản hồi về PR. Hãy cụ thể về số dòng
và đề xuất sửa lỗi code khi thích hợp. Định dạng theo kiểu bình luận của GitHub.

Hãy chú ý đến mô hình: 4 bước đơn giản, tập trung. Không phải một mệnh lệnh lớn kiểu "xem xét PR này và cho tôi phản hồi". Mỗi bước đều thành công độc lập, và nếu bước 3 thất bại, bạn vẫn có kết quả từ bước 1 và 2.

Kiểm tra nhanh: Bạn có thể mô tả quy trình xem xét PR của riêng mình trong 3-5 bước đơn giản không? Nếu mỗi bước là một thao tác đọc hoặc phân tích duy nhất, nó sẽ hoạt động tốt trong Dispatch. Nếu bất kỳ bước nào yêu cầu các thao tác phức tạp với nhiều file, hãy để dành bước đó cho công việc của bạn.

Workflow 2: Tìm kiếm codebase

Bạn đang ở một hội nghị. Ai đó đề cập đến một mẫu thiết kế mà bạn nghĩ rằng mình đã triển khai tháng trước nhưng không nhớ ở đâu. Hãy lấy điện thoại ra:

Tìm kiếm trong codebase ~/projects/api-server của tôi các file triển khai
mẫu thử lại với độ trễ theo cấp số nhân. Cho tôi xem đường dẫn file và
các code snippet liên quan.

Hoặc cụ thể hơn:

Tìm tất cả các file trong ~/projects/api-server/src nhập lớp
RateLimiter. Liệt kê từng file và chỉ ra cách chúng được sử dụng.

Tìm kiếm codebase chỉ đơn thuần là đọc. Dispatch xử lý việc này một cách đáng tin cậy. Và nó thực sự hữu ích khi bạn không ở bàn làm việc và cần tham khảo nhanh một thứ gì đó.

Mẹo nhỏ cho các tác vụ tìm kiếm: Hãy cụ thể về thư mục. Tìm kiếm toàn bộ thư mục home của bạn sẽ chậm và có thể bị lỗi hết thời gian chờ. Hãy chỉ cho Claude thư mục dự án.

Workflow 3: Bản build và trạng thái CI/CD

Nếu dự án của bạn có hệ thống xây dựng mà Claude có thể kích hoạt thông qua các connector hoặc lệnh terminal:

Kiểm tra 3 lần chạy CI/CD gần nhất cho nhánh chính trong ~/projects/my-app.
Cho tôi xem trạng thái và bất kỳ lỗi nào.

Đối với các kho lưu trữ được kết nối với GitHub:

Trạng thái của các lần chạy Workflow GitHub Actions gần đây nhất
cho kho lưu trữ my-app là gì?

Một lời cảnh báo: Kích hoạt các bản build thông qua Dispatch hoạt động, nhưng bạn đang phụ thuộc vào cả độ tin cậy của Dispatch và độ tin cậy của CI/CD. Nếu có lỗi xảy ra, việc chẩn đoán nguyên nhân từ điện thoại sẽ khó hơn so với khi bạn đang ngồi ở máy tính. Hãy sử dụng Dispatch để kiểm tra trạng thái bản build (thao tác đọc) một cách tự tin hơn là để kích hoạt các bản build (thao tác ghi).

Nếu bạn kích hoạt một bản build:

Chạy lệnh `npm test` trong thư mục `~/projects/my-app` và cho tôi xem kết quả.

Lệnh này sẽ yêu cầu phê duyệt vì đây là lệnh terminal. Hãy phê duyệt, và bạn sẽ nhận được kết quả kiểm tra trên điện thoại của mình.

Workflow 4: Phân tích nhật ký

Có lỗi xảy ra trong môi trường sản xuất và bạn cần kiểm tra nhật ký. Bạn không ở gần máy tính. Đây là lúc Dispatch thực sự phát huy tác dụng:

Đọc 100 dòng cuối cùng của file `~/projects/my-app/logs/error.log`
và tóm tắt các loại lỗi phổ biến nhất. Có bất kỳ mẫu lỗi mới nào
trong giờ qua không?

Hoặc tìm kiếm cụ thể hơn:

Tìm kiếm trong thư mục ~/projects/my-app/logs/ bất kỳ nhật ký nào chứa từ khóa 
"timeout" hoặc "connection refused" từ hôm nay. Hãy cho tôi xem
timestamp và toàn bộ mục nhật ký.

Phân tích nhật ký tốn nhiều tài nguyên đọc, Claude giỏi tóm tắt và kết quả phù hợp gọn gàng trong phản hồi trò chuyện. Workflow này có tỷ lệ thành công cao và giá trị thực sự khi bạn khắc phục sự cố từ xa.

Workflow 5: Thay đổi code nhanh

Dispatch có thể xử lý các thay đổi code nhỏ, tập trung. Từ khóa là "nhỏ".

Tốt cho Dispatch:

Trong ~/projects/my-app/src/config.ts, hãy thay đổi giá trị API_TIMEOUT
từ 5000 thành 10000 mili giây

Thêm chú thích TODO phía trên hàm processPayment trong
~/projects/my-app/src/billing.ts với nội dung
"// TODO: Thêm logic thử lại cho các khoản thanh toán thất bại"

Không tốt cho Dispatch:

Tái cấu trúc toàn bộ mô-đun xác thực để sử dụng code thông báo JWT
thay vì cookie phiên. Cập nhật tất cả 15 file tham chiếu đến
hệ thống xác thực.

Ví dụ đầu tiên là các thao tác một file, một thay đổi. Chúng sẽ hoạt động. Ví dụ thứ hai là tái cấu trúc nhiều file - chính xác là loại tác vụ thường thất bại khoảng một nửa. Nếu việc tái cấu trúc thất bại ở file thứ 8 trong số 15, bạn có một codebase bị lỗi.

Nguyên tắc chung: Nếu thay đổi ảnh hưởng đến hơn 2-3 file, hãy để dành nó lại.

Workflow 6: Các thao tác Git

Các thao tác git cơ bản hoạt động tốt thông qua Dispatch:

Trạng thái git của ~/projects/my-app là gì? Cho tôi xem bất kỳ
thay đổi nào chưa được commit.

Cho tôi xem 5 commit gần nhất trên nhánh chính của
~/projects/my-app cùng với thông báo commit và các file đã thay đổi.

Những nhánh nào tồn tại trong ~/projects/my-app và nhánh nào
hiện đang được kiểm tra?

Các thao tác đọc Git rất đáng tin cậy. Các thao tác ghi Git (commit, merge, rebase) kích hoạt những cổng phê duyệt và đôi khi hoạt động - nhưng chúng thuộc loại "cần kiểm tra cẩn thận". Nếu bạn định commit từ Dispatch, hãy xem lại diff trước:

Cho tôi xem chính xác những gì sẽ được commit nếu tôi chạy git commit ngay bây giờ
trong ~/projects/my-app

Sau đó, chỉ khi thấy đúng:

Commit các thay đổi hiện tại trong ~/projects/my-app với thông báo
"Sửa cấu hình timeout cho API thanh toán"

Mẫu prompt "thân thiện với Dispatch"

Sau khi làm việc với Dispatch một thời gian, một mẫu sẽ xuất hiện. Các tác vụ hoạt động hiệu quả thường có những đặc điểm sau:

1. Tập ​​trung vào một việc duy nhất - chỉ làm một việc tại một thời điểm
2. Thể hiện nhiều thao tác đọc - tìm kiếm, tóm tắt, phân tích
3. Đường dẫn cụ thể - tham chiếu chính xác đến file hoặc thư mục
4. Tiêu chí thành công rõ ràng - bạn có thể xác minh kết quả
5. Độc lập - không phụ thuộc vào kết quả của lệnh trước đó trong cùng một thông báo

Template cho các tác vụ Dispatch dành cho nhà phát triển:

[Động từ hành động] [mục tiêu cụ thể] trong [đường dẫn chính xác].
[Những gì cần hiển thị / Những gì cần thay đổi].

Ví dụ:

• "Tìm kiếm [mẫu] trong [đường dẫn]. Hiển thị cho tôi [kết quả]."
• "Đọc [file] và cho tôi biết [câu hỏi]."
• "Thay đổi [giá trị] trong [file] thành [giá trị mới]."

Việc duy trì cấu trúc này giúp các tác vụ Dispatch của bạn trở nên dễ dự đoán và đáng tin cậy.

Bài tập: Xây dựng workflow phát triển của bạn

Lập sơ đồ workflow Dispatch của riêng bạn:

1. Liệt kê 5 tác vụ phát triển mà bạn thường làm có thể thực hiện thông qua Dispatch
2. Đối với mỗi tác vụ, hãy viết prompt cụ thể mà bạn sẽ gửi
3. Đánh dấu mỗi tác vụ là "đã đọc" (độ tin cậy cao) hoặc "đã ghi" (kiểm tra trước)
4. Đối với các tác vụ ghi, hãy viết prompt xác minh (ví dụ: "Cho tôi xem file sau khi thay đổi")

Hãy thử các prompt của bạn trong Dispatch trong tuần này. Ghi lại những prompt nào hoạt động và những prompt nào không. Dữ liệu đó sẽ trở thành hướng dẫn về độ tin cậy cá nhân của bạn.

Những điểm chính cần ghi nhớ

• Xem xét PR là điểm mạnh của Dispatch - hãy chia nhỏ nó thành 3-5 bước đọc/phân tích đơn giản
• Tìm kiếm codebase và phân tích nhật ký hoạt động đáng tin cậy vì chúng là các thao tác chỉ đọc
• Các thay đổi code nhỏ, chỉ trong một file hoạt động tốt; việc tái cấu trúc nhiều file không cần thiết (hãy để dành việc đó cho bàn làm việc của bạn)
• Việc đọc dữ liệu bằng Git đáng tin cậy, nhưng việc ghi dữ liệu bằng Git cần được kiểm tra cẩn thận
• Cấu trúc các prompt thành những tác vụ tập trung vào một đường dẫn cụ thể, và chú trọng vào việc đọc dữ liệu để đạt kết quả tốt nhất
• Độ tin cậy khoảng 50% của các tác vụ phức tạp có nghĩa là việc chia nhỏ mọi thứ thành những bước đơn giản không phải là tùy chọn - mà đó là chiến lược