Triển khai ba quy trình sản xuất thực tế

Đây là bài học mà bạn sẽ triển khai sản phẩm thực tế!

7 bài học về lý thuyết và ví dụ. Giờ là lúc bắt tay vào việc. Đến cuối bài học này, bạn sẽ có ba routine chạy trong tài khoản của riêng mình, mỗi routine thực hiện công việc thực tế trên code hoặc dữ liệu thực của bạn.

Không phải bản demo. Không phải ví dụ prompt. Mà là các routine sản xuất thực tế mà bạn sẽ giữ lại.

Một câu chuyện cảnh báo

Đây là một bài đăng thực tế từ ngày 14 tháng 4, ngày mà tính năng Routines được ra mắt. Một lập trình viên đã thiết lập một routine chạy qua đêm để phân tích codebase của mình. Họ đi ngủ. Khi thức dậy, routine đã được kích hoạt, rơi vào vòng lặp vô hạn của việc mở rộng ngữ cảnh và vượt quá toàn bộ hạn mức sử dụng hàng ngày. Thông báo anh ấy nhận được khi thức dậy:

Thức dậy. Kiểm tra email. Tự động hóa thất bại. Đã đạt giới hạn sử dụng, reset lúc 7 giờ tối.

Điều này đã xảy ra với nhiều người trong 24 giờ đầu tiên. Điểm chung: Không giới hạn số từ, không xử lý trạng thái ban đầu và không chạy thử nghiệm trước khi kích hoạt.

Đừng trở thành người như vậy. Mọi thứ trong bài học này đều được thiết kế để tránh kết quả đó.

Routine 1: Phát hiện sự thay đổi tài liệu (đã lên lịch)

Mục tiêu: Mỗi tuần một lần, quét code và tài liệu của bạn để tìm những nơi mà code đã thay đổi nhưng tài liệu thì không. Đăng một báo cáo ngắn lên Slack hoặc nhóm trò chuyện của bạn.

Cấu hình

• Trigger: Lịch trình - mỗi thứ Hai lúc 9 giờ sáng
• Connector: GitHub (đọc kho lưu trữ của bạn), Slack (đăng báo cáo)
• Các connector khác: TẮT

Prompt

Bạn là người phát hiện sự sai lệch tài liệu cho dự án của chúng tôi.

Mỗi thứ Hai, hãy kiểm tra xem tài liệu của chúng ta có bị lệch so với code hay không.

Hãy làm như sau:
1. Lấy danh sách các file đã thay đổi trong 7 ngày qua trên nhánh chính.
2. Đối với mỗi file đã thay đổi, hãy kiểm tra xem có file tài liệu tương ứng nào đề cập đến API public, hành vi hoặc cấu hình của nó hay không.
3. Đánh dấu bất kỳ trường hợp nào mà code đã thay đổi nhưng tài liệu thì không.

Định dạng đầu ra:

## Báo cáo sai lệch tài liệu ({ngày})

### Sai lệch được tìm thấy: {số lượng}

{Đối với mỗi trường hợp sai lệch:}
- **File:** `{đường dẫn}`
- **Tài liệu bị ảnh hưởng:** `{đường dẫn tài liệu}` (hoặc "không tìm thấy tài liệu phù hợp")
- **Tóm tắt thay đổi:** {một câu}
- **Hành động cần thiết:** {một câu}

Nếu không có sai lệch, chỉ xuất ra: "Tài liệu đã đồng bộ. Không cần hành động."

Giới hạn cứng:
- Tối đa 10 trường hợp sai lệch được báo cáo
- Không bao giờ vượt quá 400 từ
- Không có bình luận, không có lời mở đầu - bắt đầu trực tiếp với tiêu đề báo cáo

Đăng toàn bộ báo cáo lên kênh Slack #engineering.

Danh sách kiểm tra chạy thử

Trước khi kích hoạt lịch trình:

1. Nhấp vào Run now
2. Xác minh tin nhắn Slack đã được nhận
3. Xác minh định dạng báo cáo khớp với mẫu
4. Xác minh số lượng từ dưới 400
5. Kiểm tra lịch sử chạy để xem số lượng token và thời lượng

Nếu bất kỳ bước nào trong số đó thất bại, hãy sửa prompt và chạy thử lại. Không để lịch trình được kích hoạt cho đến khi quá trình chạy thử thành công.

Routine 2: Bot đánh giá PR (GitHub event)

Mục tiêu: Khi một PR được mở đối với nhánh chính có nhãn cần đánh giá, Claude sẽ đăng một bình luận đánh giá có cấu trúc. Một phiên cho mỗi PR, vì vậy các commit tiếp theo sẽ dựa trên phản hồi trước đó.

Cấu hình

• Trigger: GitHub event — Pull request → đã mở + đồng bộ hóa
• Repository: kho lưu trữ của bạn
• Base branch filter: main
• Label filter: needs-review
• Author exclude: dependabot[bot], renovate[bot]
• Paths: chỉ các đường dẫn code của bạn (bỏ qua tài liệu, lockfile)
• Session: cùng một phiên cho mỗi PR
• Connectors: chỉ GitHub

Prompt

Sử dụng Prompt đánh giá PR từ Bài học 3. Sao chép chính xác vào biểu mẫu routine. Nguyên tắc lọc + quy tắc rõ ràng "không đẩy lên main" + giới hạn phát hiện là những gì làm cho routine này an toàn.

Kiểm tra thử

1. Mở một PR thử nghiệm nhỏ với main có nhãn needs-review
2. Quan sát routine được thực thi - xác nhận trong vòng 1-2 phút
3. Xác minh nhận xét đánh giá khớp với định dạng
4. Thêm một commit mới vào PR; xác minh đánh giá tiếp theo có phù hợp với ngữ cảnh
5. Xóa nhãn needs-review và thêm một commit mới; xác minh routine KHÔNG được thực thi

Nếu nó được thực thi mà không có nhãn, bộ lọc của bạn không hoạt động. Đừng tiếp tục cho đến khi nó hoạt động đúng.

Routine 3: Tự chọn

Hãy chọn một routine phù hợp với công việc thực tế bạn đang làm. Dưới đây là 5 điểm khởi đầu mạnh mẽ, tất cả đều dựa trên phần "Ví dụ sử dụng" trong tài liệu hướng dẫn ra mắt:

Tùy chọn A: Sentry / Phân loại lỗi

• Trigger: API (Sentry hoặc hệ thống cảnh báo của bạn gửi sự kiện POST đến URL thường xuyên)
• Connectors: GitHub (để kiểm tra xem có bản vá lỗi nào không), Linear (để tạo phiếu yêu cầu)
• Prompt: Phân loại lỗi, mức độ nghiêm trọng, kiểm tra xem có vấn đề liên quan nào không, tạo phiếu yêu cầu mới nếu không, liên kết lại với sự kiện lỗi

Tùy chọn C: Trình quét bảo mật

• Trigger: Lên lịch hàng tuần HOẶC đẩy lên GitHub đối với package.json / requirements.txt / go.mod / Cargo.toml
• Connectors: GitHub
• Prompt: Kiểm tra các dependency để tìm những CVE đã biết, gắn cờ bất kỳ phát hiện nào có mức độ nghiêm trọng cao/nghiêm trọng, mở PR với các đề xuất nâng cấp

Tùy chọn D: Trình phân tích nhật ký sự cố

• Trigger: API (hệ thống giám sát của bạn kích hoạt khi ngưỡng cảnh báo bị vượt quá)
• Connectors: GitHub (để liên kết đến các commit gần đây), Slack (để đăng tóm tắt)
• Prompt: Đọc đoạn trích nhật ký, xác định nguyên nhân có thể xảy ra, liệt kê 3 commit gần đây đáng ngờ nhất. Đăng lên kênh sự cố Slack

Tùy chọn E: Trả lời tự động hỗ trợ khách hàng (Chỉ bản nháp)

• Trigger: API (nền tảng hỗ trợ của bạn gửi yêu cầu mới)
• Connectors: Hệ thống hỗ trợ (chỉ đọc + tạo bản nháp - KHÔNG BAO GIỜ gửi)
• Prompt: Phân loại yêu cầu, tìm bài viết KB liên quan, soạn thảo câu trả lời, lưu dưới dạng bản nháp để người thật xem xét

Tùy chọn F: Kiểm tra di chuyển cơ sở dữ liệu

• Trigger: Đẩy lên GitHub trên migrations/**
• Connectors: GitHub
• Prompt: Xem xét quá trình di chuyển để đảm bảo an toàn - thiếu các thao tác down, những thao tác không bất biến, khóa chặn trên các bảng lớn. Nhận xét về các phát hiện trên PR.

Chọn một tùy chọn và xây dựng nó

Cùng nguyên tắc như routine 1 và 2:

• Lọc mạnh tay
• Một prompt với truy vấn phạm vi, định dạng cố định, giới hạn cứng, xử lý trạng thái rỗng
• Chỉ những connector bạn thực sự cần
• Chạy thử trước khi kích hoạt lịch trình hoặc trigger

Sổ tay tuần đầu tiên

Bây giờ bạn đã có 3 routine đang chạy. Đây là những việc cần làm trong tuần 1:

Ngày 1 (hôm nay)

• Chạy thử từng routine
• Kích hoạt cả ba
• Kiểm tra lịch sử chạy vào buổi tối - có bao nhiêu lần chạy đã được thực hiện, có lỗi nào không

Ngày 2 - 3

• Xem xét chất lượng đầu ra của từng routine
• Điều chỉnh các prompt có đầu ra bất thường
• Siết chặt bộ lọc nếu có các lần chạy không mong muốn xảy ra

Ngày 4 - 5

• Kiểm tra mức sử dụng hạn ngạch - bạn có đang tuân thủ giới hạn hàng ngày không?
• Kiểm tra chi phí token - có routine nào đắt hơn nhiều so với dự kiến ​​không?
• Loại bỏ các connector không sử dụng nếu bạn vô tình để chúng được kích hoạt

Ngày 6 - 7

• Suy ngẫm: mỗi routine có thực sự giúp bạn tiết kiệm thời gian không?
• Loại bỏ bất kỳ routine nào không hiệu quả
• Tập trung vào routine mang lại thành công lớn nhất

Hầu hết các routine cần 3 - 5 lần lặp lại trong tuần đầu tiên trước khi chúng "hoàn thành". Đó không phải là thất bại - đó là định dạng tự nhiên của công việc. Hãy lên kế hoạch cho điều đó.

Những việc bạn có thể làm ngay bây giờ

Bạn có thể:

• Cấu hình bất kỳ loại trigger nào trong ba loại (lịch trình, sự kiện GitHub, API) một cách có kỷ luật
• Viết các prompt cấp độ sản xuất với những truy vấn có phạm vi, định dạng cố định, giới hạn cứng và xử lý trạng thái rỗng
• Giới hạn các MCP connector ở mức quyền OAuth tối thiểu
• Tránh các lỗi rò rỉ chi phí hàng đầu (prompt dài dòng, trigger không được lọc, danh sách connector phình to)
• Quyết định khi nào Routines là công cụ phù hợp so với GitHub Actions, Zapier hoặc cron
• Đưa các routine sản xuất vào hoạt động với workflow chạy thử + lặp lại

Bạn đã xây dựng ba routine thực tế đang chạy trong tài khoản của mình. Bạn đã học được kỷ luật phân biệt các routine có thể mở rộng với những routine vượt quá hạn mức của bạn.

Chứng chỉ của bạn được đính kèm với tài khoản của bạn. Ghim nó lên LinkedIn hoặc giữ kín - dù sao thì, giờ đây bạn đã biết điều mà hầu hết các kỹ sư không biết: Cách vận hành đám mây các AI agent của riêng bạn để thực hiện công việc thực tế.

Bước tiếp theo

Giờ đây khi Routines đã là một phần trong hệ thống của bạn, hãy tìm hiểu sâu hơn:

• Làm chủ Claude Code - khía cạnh tương tác của Claude Code, nơi bạn vẫn dành phần lớn thời gian lập trình
• Tìm hiểu sâu về AI Agent - điều phối đa agent, mô hình vượt ra ngoài các routine đơn lẻ
• Quy trình tự động hóa - kết nối Routines với phần còn lại của các công cụ của bạn để đạt được hiệu quả tích lũy

Hệ thống tự động hóa năm 2026 không phải là "Routines HOẶC GitHub Actions HAY Zapier." Mà là tất cả chúng, được lựa chọn dựa trên định dạng của từng công việc. Giờ đây bạn đã có khả năng phán đoán để thực hiện việc lựa chọn đó.

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

• Hãy triển khai ba routine thực tế, không phải ba routine hoàn hảo
• Chạy thử trước khi kích hoạt - luôn luôn làm như vậy
• Theo dõi lịch sử chạy trong ngày đầu tiên; lặp lại các prompt trong ngày thứ 2-3; chỉnh sửa trong ngày thứ 4-5
• Hầu hết các routine cần 3-5 lần lặp trước khi ổn định - hãy lên kế hoạch cho điều đó
• Bạn đã học được nguyên tắc cốt lõi: Lọc, định dạng, giới hạn, trạng thái ban đầu, phạm vi