Cách thiết lập Claude Code Routines để tự động hóa mọi quy trình làm việc (Khóa học đầy đủ)

@eng_khairallah1
TIẾNG ANH2 tháng trước · 13 thg 5, 2026
386K
299
43
45
698

TL;DR

Hướng dẫn toàn diện này giải thích về Claude Code Routines của Anthropic, một tính năng tự động hóa dựa trên đám mây giúp vận hành các tác nhân AI bền bỉ. Tìm hiểu cách thiết lập trình kích hoạt, viết các câu lệnh (prompt) chuẩn xác và xây dựng một hệ thống các quy trình làm việc tự động.

Có một tính năng mà Anthropic đã phát hành, và hầu như không ai đang nói về nó.

Hãy đánh dấu & Lưu lại bài viết này nhé :)

Nó có tên là Claude Code Routines.

Và đây có thể là tính năng quan trọng nhất mà Anthropic đã ra mắt trong năm nay.

Đây là lý do tại sao.

Cho đến nay, mọi tác vụ tự động hóa của Claude Code đều yêu cầu laptop của bạn phải mở. Bạn có thể dùng /loop để kiểm tra các thay đổi. Bạn có thể dùng /schedule để thiết lập các tác vụ định kỳ. Nhưng ngay khi bạn đóng terminal hoặc tắt laptop, mọi thứ đều dừng lại.

Routines khắc phục hoàn toàn điều đó.

Routine là một tác vụ tự động hóa của Claude Code mà bạn cấu hình một lần — một prompt, một repo, một bộ kết nối — và sau đó nó chạy trên cơ sở hạ tầng đám mây của Anthropic. Theo một lịch trình. Từ một lệnh gọi API. Hoặc được kích hoạt bởi một sự kiện GitHub.

Laptop của bạn có thể tắt. Terminal của bạn có thể đóng. Routine vẫn chạy.

Đây là sự chuyển đổi từ "công cụ AI bạn sử dụng" sang "hệ thống AI làm việc cho bạn."

Đây là cách chính xác để thiết lập một routine, ngay cả khi bạn chưa từng sử dụng Claude Code trước đây.

Tại Sao Routines Lại Khác Biệt So Với Mọi Thứ Khác

Claude Code đã có tính năng lập lịch. Vậy điều gì đã thay đổi?

Sự khác biệt nằm ở cơ sở hạ tầng.

Các lệnh /schedule và /loop cũ chạy bên trong phiên Claude Code cục bộ của bạn. Chúng phụ thuộc vào việc máy tính của bạn đang bật, terminal của bạn đang mở và kết nối internet của bạn ổn định. Nếu bất kỳ điều nào trong số đó bị lỗi, quá trình tự động hóa sẽ chết.

Routines chạy trên đám mây của Anthropic. Chúng là các tác nhân tự động liên tục, tồn tại qua các lần khởi động lại, đóng terminal và chạy qua đêm. Chúng có quyền truy cập trực tiếp vào repos và các kết nối của bạn — Slack, Linear, Google Drive, GitHub — mà bạn không cần phải quản lý bất kỳ điều gì.

Hãy nghĩ về hệ thống cũ như một lời nhắc trên điện thoại của bạn. Nó kêu, nhưng bạn vẫn phải làm công việc đó.

Routines giống như một nhân viên làm công việc đó trong khi bạn ngủ và gửi cho bạn một bản tóm tắt khi bạn thức dậy.

Bước 1: Quyết Định Xem Nên Tự Động Hóa Việc Gì

Các routine tốt nhất sẽ tự động hóa các tác vụ có đặc điểm:

Lặp lại — chúng xảy ra theo một lịch trình có thể dự đoán được (hàng ngày, hàng tuần hoặc được kích hoạt bởi một sự kiện).

Được xác định rõ ràng — bạn có thể mô tả chính xác "hoàn thành" trông như thế nào mà không có sự mơ hồ.

Ít cần phán đoán — tác vụ không yêu cầu tư duy sáng tạo hoặc ra quyết định độc đáo của bạn. Nó yêu cầu thực thi.

Dưới đây là các mẫu hình mà những người dùng đầu tiên đang chạy ngay bây giờ:

Quản lý backlog — mỗi đêm lúc nửa đêm, routine kéo các issue mới từ Linear, phân loại chúng theo loại và mức độ nghiêm trọng, gán nhãn và đăng một bản tóm tắt lên kênh Slack. Trưởng nhóm kỹ thuật thức dậy với một bảng sạch sẽ, có tổ chức.

Phát hiện sai lệch tài liệu — mỗi thứ Sáu, routine quét các pull request đã được merge trong tuần qua, xác định bất kỳ PR nào đã thay đổi API hoặc giao diện, đối chiếu chúng với tài liệu và mở các PR cập nhật cho các tài liệu hiện đã lỗi thời.

Xác minh triển khai — được kích hoạt bởi một webhook sau mỗi lần triển khai, routine chạy các bài kiểm tra khói (smoke tests) trên bản build mới, quét nhật ký lỗi để tìm hồi quy, tương quan bất kỳ vấn đề nào với các thay đổi mã gần đây và đăng phán quyết go/no-go lên kênh phát hành.

Đánh giá mã hàng ngày — mỗi sáng lúc 9 giờ, routine chọn PR mở lâu nhất, xem xét nó về các vấn đề bảo mật, lỗi logic và vi phạm phong cách, đồng thời đăng các bình luận nội tuyến.

Những người thiết lập ba hoặc bốn routine như thế này đang hoạt động ở một cấp độ hoàn toàn khác so với những người vẫn đang sử dụng Claude như một công cụ trò chuyện.

Bước 2: Tạo Routine Đầu Tiên Của Bạn

Có hai cách để tạo một routine.

Từ giao diện web: Truy cập claude.ai/code/routines và nhấp vào "New routine." Thao tác này cung cấp cho bạn các tùy chọn cấu hình đầy đủ — trình kích hoạt theo lịch, trình kích hoạt API và trình kích hoạt sự kiện GitHub.

Từ CLI: Nếu bạn đã sử dụng Claude Code trong terminal, hãy nhập /schedule theo sau là một mô tả. Ví dụ:

/schedule daily PR review at 9am

CLI chỉ tạo các trình kích hoạt dựa trên lịch. Đối với các trình kích hoạt API và GitHub, bạn cần giao diện web.

Khi bạn tạo một routine, bạn cấu hình bốn thứ:

Prompt — đây là phần quan trọng nhất. Vì routine chạy tự động, prompt cần phải hoàn toàn khép kín. Mọi thứ tác nhân cần biết phải có trong prompt. Không có "ngữ cảnh từ cuộc trò chuyện trước đó." Mỗi lần chạy đều bắt đầu từ đầu.

Repository — cơ sở mã nào mà routine sẽ làm việc cùng. Nó có toàn quyền truy cập đọc và có thể push lên các nhánh có tiền tố là claude/ theo mặc định.

Các kết nối — các dịch vụ bên ngoài nào mà routine có thể truy cập. Slack để đăng cập nhật. Linear để đọc và quản lý issue. Google Drive để đọc và ghi tài liệu. GitHub để theo dõi các sự kiện và mở PR.

Trình kích hoạt — thời điểm và cách thức routine chạy. Theo lịch (hàng giờ, hàng đêm, hàng tuần), được kích hoạt bằng API (bạn gọi nó theo chương trình) hoặc được kích hoạt bằng GitHub (nó kích hoạt khi một sự kiện cụ thể xảy ra trong repo của bạn).

Bước 3: Viết Một Prompt "Bất Khả Chiến Bại"

Đây là nơi hầu hết mọi người thất bại.

Một routine chạy mà không có bạn theo dõi. Nếu prompt mơ hồ, tác nhân sẽ diễn giải nó khác nhau mỗi lần và bạn sẽ nhận được kết quả không nhất quán.

Các prompt routine tốt nhất tuân theo cấu trúc này:

Định nghĩa vai trò: "Bạn là một senior code reviewer chuyên về bảo mật và hiệu suất."

Định nghĩa nhiệm vụ: "Hãy xem xét pull request mở lâu nhất trong repository này."

Quy trình từng bước: "Đầu tiên, hãy đọc mô tả PR. Sau đó, checkout nhánh đó. Đọc các tệp đã thay đổi. Phân tích các lỗ hổng bảo mật, lỗi logic và vấn đề hiệu suất. Viết bình luận nội tuyến cho từng vấn đề được tìm thấy."

Đặc tả đầu ra: "Đăng một bình luận tóm tắt trên PR với: tổng số vấn đề được tìm thấy (theo mức độ nghiêm trọng), một đoạn đánh giá tổng thể và phán quyết rõ ràng là approve/request-changes."

Xử lý lỗi: "Nếu không có PR nào đang mở, hãy đăng lên #engineering trong Slack với nội dung 'Không có PR mở nào để xem xét hôm nay.' Nếu một PR có hơn 50 tệp đã thay đổi, hãy bỏ qua nó và đăng rằng nó cần được xem xét thủ công."

Các ràng buộc: "Không bao giờ chấp thuận một PR có vấn đề ở mức độ Nghiêm trọng (Critical). Không bao giờ sửa đổi bất kỳ mã nào trực tiếp — chỉ bình luận. Tối đa ba bình luận nội tuyến trên mỗi tệp để tránh nhiễu."

Prompt của bạn càng chính xác, routine của bạn càng đáng tin cậy.

Bước 4: Hiểu Các Giới Hạn

Routines rất mạnh mẽ nhưng chúng có những ràng buộc bạn cần biết.

Giới hạn số lần chạy hàng ngày: Trong giai đoạn xem trước nghiên cứu, mỗi tài khoản có 15 lần chạy routine mỗi ngày. Nếu bạn cần nhiều hơn, hãy bật tính năng sử dụng thêm trong cài đặt tổ chức của bạn — các lần chạy bổ sung sẽ được tính theo mức sử dụng.

Mức tiêu thụ token: Routines sử dụng cùng một giới hạn đăng ký với các phiên Claude Code tương tác. Một routine phức tạp đọc nhiều tệp và thực hiện nhiều lệnh gọi API sẽ sử dụng nhiều token hơn đáng kể so với một routine đơn giản.

Bảo mật nhánh: Theo mặc định, Claude chỉ có thể push lên các nhánh có tiền tố là claude/. Đây là một biện pháp an toàn — một routine được viết kém không thể vô tình push lên nhánh main. Không tắt tính năng này trừ khi bạn có các quy trình xem xét mạnh mẽ ở phía sau.

Giới hạn sự kiện GitHub: Các routine được kích hoạt bằng GitHub có giới hạn hàng giờ cho mỗi routine và mỗi tài khoản trong giai đoạn xem trước. Nếu repo của bạn rất năng động, hãy lọc các sự kiện nào kích hoạt routine để tránh lãng phí các lần chạy vào nhiễu.

Phụ thuộc vào lịch trình: Các routine theo lịch chạy vào thời gian đã chỉ định, nhưng có thể có sự khác biệt trong thời gian cao điểm. Đừng xây dựng các quy trình làm việc phụ thuộc vào thời gian chính xác đến từng giây.

Bước 5: Xây Dựng Một Stack Routine

Một routine rất hữu ích. Một stack routine là một hệ thống.

Đây là những gì một stack routine hoàn chỉnh trông như thế nào đối với một nhóm kỹ thuật nhỏ:

Buổi sáng (9 giờ sáng) — Đánh giá PR hàng ngàyClaude xem xét tất cả các PR đang mở, đăng bình luận nội tuyến và gửi một bản tóm tắt lên Slack với danh sách ưu tiên những gì cần chú ý hôm nay.

Sau triển khai (webhook) — Xác minh triển khaiMỗi khi một bản triển khai đến môi trường staging, Claude chạy bộ kiểm thử, quét nhật ký để tìm lỗi và đăng phán quyết go/no-go lên kênh phát hành trong vòng vài phút.

Hàng đêm (2 giờ sáng) — Phân loại backlogClaude xử lý tất cả các issue mới được gửi trong ngày hôm đó, thêm nhãn, gán điểm ưu tiên và tạo một tài liệu tóm tắt buổi sáng.

Hàng tuần (Thứ Sáu, 5 giờ chiều) — Kiểm tra tài liệuClaude quét các PR đã được merge trong tuần, xác định các tài liệu cần cập nhật và mở các PR nháp cho từng tài liệu đó.

Hàng tuần (Thứ Hai, 8 giờ sáng) — Báo cáo nợ kỹ thuậtClaude quét cơ sở mã để tìm các bình luận TODO, các phụ thuộc đã lỗi thời và các lỗ hổng trong phạm vi kiểm thử. Tạo ra một danh sách các mục nợ kỹ thuật được xếp hạng với ước tính nỗ lực.

Mỗi routine mất 10-15 phút để thiết lập. Stack routine mất một buổi chiều. Thời gian tiết kiệm được sẽ nhân lên mỗi tuần.

Bước 6: Theo Dõi và Cải Thiện

Mỗi lần chạy routine đều tạo ra một nhật ký. Hãy xem xét nó.

Tìm kiếm các mẫu hình:

  • Routine có liên tục tạo ra đầu ra tốt không? Nếu không, phần nào của prompt bị mơ hồ?
  • Nó có mất quá nhiều thời gian cho một số lần chạy nhất định không? Bạn có thể cần thu hẹp phạm vi.
  • Nó có gặp lỗi không? Thêm xử lý lỗi rõ ràng vào prompt.
  • Nó có tạo ra quá nhiều nhiễu không? Thắt chặt các ràng buộc.

Tính năng "Dreaming" mới — được công bố tại Code with Claude vào ngày 6 tháng 5 — đưa điều này đi xa hơn nữa. Khi Dreaming được bật, Claude xem xét các phiên routine trong quá khứ của chính nó giữa các lần chạy, xác định các mẫu hình về những gì hiệu quả và những gì không, và tự cải thiện cách tiếp cận của nó cho lần tiếp theo.

Các routine của bạn thực sự trở nên thông minh hơn khi chúng chạy nhiều hơn.

Đối Tượng Nào Phù Hợp (Và Đối Tượng Nào Không Phù Hợp)

Routines được xây dựng cho các nhà phát triển và các nhà vận hành có thiên hướng kỹ thuật, những người:

  • Đã sử dụng Claude Code hoặc sẵn sàng học
  • Có các tác vụ lặp đi lặp lại trong quy trình làm việc của họ tuân theo các mẫu hình rõ ràng
  • Muốn tự động hóa chi phí vận hành đang ngốn hàng giờ mỗi tuần
  • Làm việc với các cơ sở mã được lưu trữ trên GitHub

Nếu bạn là người dùng phi kỹ thuật đang tìm kiếm tự động hóa AI, Claude Cowork với các tác vụ theo lịch là một điểm khởi đầu tốt hơn. Routines là công cụ dành cho người dùng chuyên sâu.

Nhưng nếu bạn là một nhà phát triển, một trưởng nhóm kỹ thuật, một kỹ sư DevOps hoặc một nhà sáng lập kỹ thuật — routines sẽ giúp bạn tiết kiệm nhiều thời gian hơn bất kỳ tính năng nào khác mà Anthropic đã ra mắt.

Routines so với GitHub Actions: Sự Khác Biệt Là Gì

Nhiều nhà phát triển sẽ hỏi: tại sao phải trả tiền cho các routine của Claude trong khi GitHub Actions miễn phí?

Câu trả lời là GitHub Action là một tập lệnh. Bạn viết mọi bước. Bạn xác định mọi điều kiện. Bạn tự xử lý mọi trường hợp ngoại lệ. Nó làm chính xác những gì bạn đã lập trình và không hơn thế.

Một Claude routine là một tác nhân. Bạn đưa cho nó một mục tiêu. Nó quyết định cách đạt được mục tiêu đó. Nó thích ứng với các tình huống bất ngờ. Nó suy luận về các vấn đề. Nó xác minh công việc của chính nó.

Một GitHub Action chạy một trình linter và cho bạn biết cái gì đã thất bại. Một Claude routine đọc lỗi, hiểu tại sao nó thất bại, đề xuất một bản sửa lỗi và mở một pull request với bản sửa lỗi đó.

Đó là một loại hoàn toàn khác. Các tập lệnh tuân theo các quy tắc. Các tác nhân giải quyết vấn đề.

Đối với tự động hóa đơn giản — chạy kiểm thử, kiểm tra định dạng, đăng thông báo — GitHub Actions là đủ. Đối với bất cứ điều gì yêu cầu phán đoán, phân tích hoặc thích ứng, routines ở một đẳng cấp khác.

Năm Công Thức Routine Phổ Biến Bạn Có Thể Sao Chép Ngay Hôm Nay

Dưới đây là năm cấu hình routine bạn có thể thiết lập trong giờ tới:

Công thức 1: Bot Họp Đứng Hàng NgàyLịch: Hàng ngày lúc 8:30 sáng Prompt: "Kiểm tra kho lưu trữ GitHub để tìm tất cả các commit đã được push ngày hôm qua. Kiểm tra Linear để tìm các issue mới và đã cập nhật. Kiểm tra Slack #engineering để tìm bất kỳ tin nhắn nào đề cập đến các blocker. Tổng hợp một bản tóm tắt họp đứng với ba phần: những gì đã làm, những gì đang tiến hành và những gì đang bị chặn. Đăng bản tóm tắt lên #daily-standup trong Slack."

Công thức 2: Kiểm Toán Viên Phụ ThuộcLịch: Hàng tuần vào Thứ Hai lúc 6 giờ sáng Prompt: "Quét package.json và requirements.txt để tìm tất cả các phụ thuộc. Kiểm tra từng phụ thuộc để tìm các lỗ hổng đã biết bằng cách sử dụng web. Xác định bất kỳ phụ thuộc nào đã tụt hơn hai phiên bản chính so với phiên bản hiện tại. Tạo một báo cáo ưu tiên với xếp hạng mức độ nghiêm trọng và mở một GitHub issue nếu tìm thấy bất kỳ lỗ hổng Nghiêm trọng (Critical) nào."

Công thức 3: Trình Tạo ChangelogTrình kích hoạt: Sự kiện GitHub — thẻ phát hành mới được push Prompt: "Khi một thẻ phát hành mới được push, hãy đọc tất cả các commit kể từ thẻ trước đó. Phân loại từng commit là tính năng, sửa lỗi, cải tiến hoặc công việc vặt. Tạo một changelog đã được định dạng trong CHANGELOG.md và mở một PR."

Công thức 4: Giám Sát Phạm Vi Kiểm ThửLịch: Hàng đêm lúc 1 giờ sáng Prompt: "Chạy bộ kiểm thử. Tính toán tỷ lệ phần trăm phạm vi kiểm thử theo mô-đun. So sánh với các đường cơ sở phạm vi kiểm thử trong coverage-config.json. Nếu bất kỳ mô-đun nào giảm xuống dưới đường cơ sở của nó hơn 2%, hãy mở một GitHub issue với mô-đun cụ thể, phạm vi kiểm thử cũ, phạm vi kiểm thử mới và các commit có khả năng gây ra sự sụt giảm."

Công thức 5: Người Thực Thi Mô Tả PRTrình kích hoạt: Sự kiện GitHub — PR mới được mở Prompt: "Khi một PR mới được mở, hãy kiểm tra xem mô tả có đáp ứng các yêu cầu mẫu của chúng tôi không: phải bao gồm phần Tóm tắt, phần Kiểm thử và phần Ảnh chụp màn hình nếu có thay đổi về giao diện người dùng. Nếu bất kỳ phần nào bị thiếu, hãy đăng một bình luận lịch sự yêu cầu tác giả cập nhật mô tả trước khi xem xét."

Mỗi công thức mất ít hơn 10 phút để cấu hình. Cùng nhau, chúng giúp một nhóm tiết kiệm hàng chục giờ mỗi tháng.

Kết Luận

Cách cũ: thức dậy, mở terminal, bắt đầu phiên Claude Code, nhập lệnh, chờ kết quả, chuyển sang tác vụ tiếp theo. Lặp lại vào ngày mai.

Cách mới: cấu hình routines một lần, để chúng chạy trên đám mây của Anthropic, thức dậy với kết quả.

Đây không phải là một cải tiến lý thuyết. Mọi người đã và đang chạy các stack routine xử lý toàn bộ quy trình vận hành của họ qua đêm.

Khoảng cách giữa "người sử dụng Claude như một chatbot" và "người có Claude làm việc tự động suốt ngày đêm" đang ngày càng lớn hơn mỗi tuần.

Routines là cách để bạn vượt qua ranh giới đó.

Hầu hết mọi người sẽ đọc bài viết này và nghĩ "Tôi nên thiết lập thứ đó vào một lúc nào đó." Những người thực sự tạo routine đầu tiên của họ ngay hôm nay sẽ có một hệ thống chạy vào tuần tới, giúp họ tiết kiệm hàng giờ mỗi tháng.

Theo dõi tôi @eng_khairallah1 để biết thêm các phân tích và quy trình làm việc về AI. Tôi đăng nội dung như thế này thường xuyên — các công cụ, thiết lập và chiến lược thực sự hiệu quả.

hy vọng điều này hữu ích cho bạn, Khairallah ❤️

Save to YouMind

Use YouMind to read viral articles deeply

Save the source, ask focused questions, summarize the argument, and turn a viral article into reusable notes in one AI workspace.

Explore YouMind

Thêm pattern để giải mã

Bài viết viral gần đây

Khám phá thêm bài viết viral