Hầu hết các quy trình tự động hóa đều chết theo cùng một cách. Ai đó xây dựng một thứ gì đó thông minh, chạy nó một lần trong cửa sổ chat, đóng laptop lại để đi ăn tối, và toàn bộ mọi thứ tan biến. Kịch bản chưa bao giờ là mắt xích yếu. Cái laptop mới là vấn đề. Nó phải mở, cắm sạc, thức, để công việc tiếp tục - và laptop được thiết kế để làm ngược lại điều đó.
Một chiếc Mac mini không gặp vấn đề đó. Nó có giá khoảng $599 ở phiên bản cơ bản, tiêu thụ ít điện hơn một chiếc đèn bàn, không tạo ra tiếng ồn đáng kể, và có chính xác một mô tả công việc: luôn bật. Đặc điểm đơn lẻ đó là toàn bộ lý do tại sao nó trở thành cỗ máy mà mọi người âm thầm giao phó các quy trình làm việc với Claude của họ.
Bài viết này sẽ hướng dẫn qua ba quy trình làm việc đó - một hộp thư đến tự phân loại, các pull request được xem xét qua đêm, và một lịch trình đưa cho bạn một bản tóm tắt thay vì chỉ một tiêu đề cuộc họp - tất cả đều chạy trên một chiếc mini đặt ở đâu đó trong nhà, thực hiện công việc mà không ai phải nhớ để khởi động.
Tại sao không chỉ dùng chat Claude cho việc này?
Bạn đã có thể dán một email vào Claude và yêu cầu nó viết thư trả lời. Bạn đã có thể dán một đoạn diff và yêu cầu xem xét. Không có gì trong bài viết này yêu cầu một khả năng chưa tồn tại trong cửa sổ chat.
Điều thay đổi là ai nhấn nút thực hiện.
Trong chat, bạn là người kích hoạt, mỗi lần. Bạn mở tab, bạn dán nội dung, bạn đọc câu trả lời, bạn sao chép nó đi đâu đó. Khoảnh khắc bạn ngừng làm điều đó, quy trình dừng lại. Đó là một công cụ chỉ di chuyển khi tay bạn đặt trên nó.
Trên mini, người kích hoạt là một chiếc đồng hồ, hoặc một webhook, hoặc một tệp tin mới xuất hiện trong một thư mục. Claude thực hiện công việc, kiểm tra đầu ra của chính nó dựa trên một quy tắc bạn đã viết trước, và hoặc gửi nó hoặc thử lại - mà không cần ai mở laptop. Đó là toàn bộ sự khác biệt giữa "một mô hình tôi sử dụng" và "một hệ thống tự chạy."
Thực sự có gì trên bàn làm việc
Ba lớp, và không có lớp nào là xa lạ:
Cỗ máy. Một Mac mini chạy các tác vụ launchd (người anh em họ cư xử tốt hơn của cron trên macOS) kích hoạt các tập lệnh Python theo lịch trình hoặc khi có thay đổi tệp tin. Bất kỳ chiếc PC nhỏ luôn bật nào cũng làm được công việc tương tự - mini chỉ tình cờ là yên tĩnh, rẻ để chạy, và đủ nhỏ để biến mất sau màn hình.
Bộ nhớ. Các thư mục đơn giản và tệp tin markdown, cộng với bất cứ thứ gì quy trình làm việc chạm trực tiếp - một hộp thư đến qua IMAP, một kho lưu trữ GitHub được sao chép cục bộ, một lịch được đồng bộ với nguồn cấp .ics. Không có gì tồn tại bên trong ứng dụng của người khác. Nếu mini biến mất vào ngày mai, mọi tệp tin nó tạo ra vẫn sẽ mở bình thường trên bất kỳ máy tính nào.
Lý luận. Claude, được gọi qua API. Sonnet xử lý bất cứ thứ gì yêu cầu phán đoán thực sự - quyết định xem một pull request có an toàn để hợp nhất không, viết một câu trả lời nghe giống như bạn. Haiku xử lý những thứ rẻ tiền, khối lượng lớn - phân loại, gắn nhãn, kiểm tra có/không. Việc phân chia công việc theo cách này là lý do chính khiến hóa đơn hàng tháng vẫn dưới giá của một gói cà phê.
Bây giờ là các quy trình làm việc thực tế.
Quy trình một: hộp thư đến không còn tiếng ồn khi bạn kiểm tra nó
Hầu hết các hộp thư đến không đầy những quyết định khó khăn. Chúng chứa đầy những thứ hoàn toàn không cần bạn - một bản tin, một xác nhận lịch, một nhà cung cấp hỏi một câu bạn đã trả lời năm mươi lần. Phần khó không phải là trả lời chúng. Mà là hai mươi giây tập trung mà mỗi cái đánh cắp trước khi bạn thậm chí quyết định làm gì với nó.
1CHẠY LÚC: mỗi 15 phút, các ngày trong tuần2THEO DÕI: thư mới trong hộp thư đến chính34CÁC BƯỚC:5 1. Lấy 10 tin nhắn cuối cùng trong cùng một chuỗi để có ngữ cảnh6 2. Claude phân loại tin nhắn mới:7 - thông thường (xác nhận, bản tin, trả lời tự động)8 - cần trả lời (một câu hỏi thực sự, một yêu cầu)9 - cần quyết định của con người (tiền bạc, xung đột, bất cứ điều gì mơ hồ)10 3. Thông thường -> tự động lưu trữ, ghi lại trong bản tổng kết hàng ngày11 Cần trả lời -> Claude viết phản hồi bằng giọng văn của tôi, lưu vào Bản nháp,12 không bao giờ được gửi nếu tôi chưa mở ra xem13 Cần con người -> để nguyên, đánh dấu, không thử viết phản hồi1415KIỂM TRA: phân loại phải kèm theo một dòng lý do. Nếu Claude16 không thể đưa ra lý do tham chiếu đến nội dung tin nhắn thực tế,17 mục đó sẽ tự động rơi vào "cần con người" theo mặc định.18DỪNG: mọi tin nhắn trong lô đã được phân loại, hoặc 3 lần thử lại19 trên bất kỳ tin nhắn nào trước khi nó được gắn cờ trực tiếp cho tôi
Quy tắc quan trọng ở đây là phương án dự phòng. Bất cứ điều gì Claude không thể tự tin phân loại sẽ không bị đoán mò - nó sẽ rơi vào lòng bạn y hệt như cách nó vẫn làm. Quy trình làm việc không cố gắng thay thế phán đoán trong 10% khó khăn. Nó cố gắng ngừng đánh cắp sự chú ý của bạn vào 90% dễ dàng.
Quy trình hai: pull request được xem xét sơ bộ trước khi bạn thức dậy
Đánh giá mã có một chế độ hỏng hóc kỳ lạ: đánh giá quan trọng nhất - đánh giá trên PR được tạo lúc 11 giờ tối - là đánh giá có khả năng cao nhất bị thực hiện vội vàng khi đang nửa tỉnh nửa mê, hoặc tệ hơn, bị hợp nhất với một câu "tôi sẽ xem sau" không bao giờ xảy ra.
1CHẠY LÚC: khi có mỗi pull request mới, thông qua một webhook GitHub23CÁC BƯỚC:4 1. Lấy diff và issue liên quan, nếu có5 2. Claude xem xét dựa trên một tiêu chí cố định:6 - có khớp với phạm vi thực tế của issue liên quan không?7 - có thay đổi nào liên quan đến xác thực, thanh toán hoặc di chuyển không? (gắn cờ, không phán xét)8 - mức độ bao phủ kiểm thử trên các dòng đã thay đổi - có hay thiếu?9 - đặt tên và cấu trúc có nhất quán với phần còn lại của tệp tin không?10 3. Bình luận được đăng trực tiếp trên PR, chấm điểm 1-5 cho mỗi mục tiêu chí,11 với hai điểm yếu nhất được chỉ ra rõ ràng1213KIỂM TRA: bình luận chỉ được đăng nếu nó trích dẫn số dòng cụ thể.14 Một đánh giá không có tham chiếu dòng sẽ bị loại bỏ và thử lại -15 phản hồi mơ hồ không đáng để gửi đi.16DỪNG: bình luận đã được đăng, hoặc sau 2 lần thử lại, PR sẽ được để yên17 với một ghi chú rằng đánh giá tự động không thể hoàn thành
Không có gì ở đây hợp nhất bất cứ thứ gì. Nó là một đôi mắt thứ hai không bao giờ mệt mỏi, ngồi trên PR của bạn trước khi đôi mắt thứ nhất thực sự của bạn làm việc. Việc chấm điểm dựa trên một tiêu chí cố định là điều giữ cho nó hữu ích - một mô hình được yêu cầu "xem xét mã này" một cách tự do có xu hướng hoặc khen ngợi mọi thứ hoặc soi mói một cách ngẫu nhiên. Một mô hình được chấm điểm dựa trên bốn câu hỏi cố định sẽ tạo ra cùng một loại phản hồi mỗi lần, chính xác là điều làm cho nó đáng đọc lúc 8 giờ sáng.
Quy trình ba: cuộc họp đi kèm với một bản tóm tắt, không chỉ là một tiêu đề
Một lời mời lịch cho bạn biết khi nào và ở đâu. Nó hầu như không bao giờ cho bạn biết bạn thực sự cần nhớ gì trước khi bước vào - chuỗi email cuối cùng với người đó, mục còn dang dở từ cuộc họp trước, con số mà ai đó sắp hỏi.
1CHẠY LÚC: 45 phút trước mỗi sự kiện lịch có từ 2 người tham dự trở lên23CÁC BƯỚC:4 1. Lấy chuỗi email cuối cùng và bất kỳ tài liệu chia sẻ nào được liên kết5 với tên người tham dự hoặc tiêu đề sự kiện6 2. Claude viết một bản tóm tắt một trang:7 - những gì đã được thống nhất lần trước, nếu có8 - một câu hỏi mở đáng để đưa ra9 - bất kỳ số hoặc ngày nào được đề cập trong trao đổi cuối cùng10 3. Được gửi dưới dạng thông báo đẩy 30 phút trước sự kiện1112KIỂM TRA: bản tóm tắt phải tham chiếu một tin nhắn hoặc tài liệu trước đó thực tế.13 Không tìm thấy ngữ cảnh trước đó -> thông báo nói14 "không tìm thấy lịch sử," không phải là một bản tóm tắt bịa đặt.15DỪNG: đã gửi, hoặc bỏ qua hoàn toàn nếu người tham dự là mới
Kiểm tra cuối cùng đó là điều đáng để suy ngẫm. Sẽ rất dễ dàng để Claude viết một bản tóm tắt nghe có vẻ hợp lý từ hư vô khi nó không thể tìm thấy ngữ cảnh thực tế - và một bản giả có vẻ hợp lý còn tệ hơn là không có bản tóm tắt nào, bởi vì bạn sẽ tin tưởng nó. Buộc phải có một thông báo trung thực "không tìm thấy gì" là điều làm cho những bản tóm tắt thực sự đến có giá trị để đọc.
Hai quy tắc mà mọi thứ trên đều phụ thuộc vào
Bỏ qua các chi tiết cụ thể và mọi quy trình ở đây đều dựa trên cùng hai rào cản.
Một quy tắc có thể kiểm tra, không phải là một cảm giác. "Phân loại email này" là một cảm giác. "Phân loại email này, và nếu bạn không thể trích dẫn câu biện minh cho nhãn, hãy mặc định về danh mục an toàn" là một quy tắc. Sự khác biệt là liệu Claude có đang tự chấm điểm công việc của mình dựa trên một điều gì đó cụ thể, hay chỉ đơn giản là tạo ra một thứ nghe có vẻ đã hoàn thành.
Một điều kiện dừng thực sự. Mọi quy trình trên đều có giới hạn cứng về số lần thử lại và một phương án dự phòng được xác định cho những gì xảy ra khi nó không thể thực hiện công việc một cách sạch sẽ. Nếu không có điều đó, một email bị định dạng sai hoặc một PR với diff bị lỗi sẽ sẵn sàng đốt các cuộc gọi API trong một vòng lặp thử lại suốt cả đêm, và hóa đơn sẽ xuất hiện trước khi báo cáo lỗi.
Hãy làm đúng hai điều đó và nhiệm vụ cụ thể hầu như không còn quan trọng - hộp thư đến, mã nguồn, lịch trình, hay bất cứ thứ gì khác.
Hãy thử nghiệm bằng tay trước khi xây dựng nó
Không có điều nào yêu cầu bạn phải chạm vào terminal để bắt đầu. Bạn có thể chạy cùng một hình thức trong một cuộc trò chuyện Claude bình thường và xem liệu nó có thực sự hữu ích với bạn trước khi tự động hóa bất cứ thứ gì không:
1Bạn sẽ làm việc qua nhiệm vụ này theo từng lượt, kiểm tra đầu ra2của chính mình trước khi gọi nó là hoàn thành.34NHIỆM VỤ:5[điều bạn muốn được xử lý]67QUY TẮC LƯỢT:8- Làm công việc.9- Kiểm tra nó dựa trên: [điều kiện cụ thể, có thể kiểm tra]10- Nếu nó không vượt qua kiểm tra, hãy nói những gì sai và làm lại chỉ phần đó.11- Nếu nó vượt qua, hãy nói "xong" và dừng lại.12- Không bao giờ hỏi tôi một câu làm rõ - hãy đưa ra giả định hợp lý nhất,13 nêu rõ nó trong một dòng, và tiếp tục.1415Bắt đầu.
Đó là toàn bộ cơ chế ở dạng thu nhỏ. Không mini, không webhook, không lịch trình - chỉ Claude tự kiểm tra công việc của mình dựa trên một quy tắc thay vì dừng lại ở bản nháp có vẻ hợp lý đầu tiên. Nếu bạn chạy thử bằng tay ba hoặc bốn lần trên cùng một loại nhiệm vụ và liên tục quay lại với nó, đó là tín hiệu cho thấy nó đáng được đặt trên một cỗ máy không cần bạn nhớ để chạy nó.
Thứ tự giữ cho mọi thứ không bị hỏng lúc 2 giờ sáng
Không ai chạy những thứ này một cách đáng tin cậy lại bắt đầu bằng cách viết tác vụ cron. Thứ tự thực sự bền vững là:
- Chạy thử bằng tay trong chat cho đến khi đầu ra luôn đúng.
- Biến chính xác prompt đó thành một tập lệnh - không thay đổi logic.
- Thêm bước kiểm tra và giới hạn thử lại trước bất cứ thứ gì khác.
- Chỉ sau đó mới kết nối nó với một lịch trình hoặc một webhook.
Bỏ qua thẳng đến bước bốn và bạn sẽ biết "không có điều kiện dừng" có giá như thế nào một cách cay đắng, thường là trong một buổi sáng đầy những bình luận PR trùng lặp hoặc hàng trăm bản nháp giống hệt nhau nằm trong thư mục Đã gửi của bạn.
Thứ này thực sự mang lại cho bạn điều gì
Không có điều nào làm cho Claude thông minh hơn. Nó tạo ra sự khác biệt giữa một thứ bạn sử dụng và một thứ hoạt động cho dù bạn có đang chú ý hay không. Cái mini không phải là phần thú vị - nó chỉ là cách rẻ nhất, yên tĩnh nhất để cung cấp cho một quy trình làm việc một cỗ máy không bao giờ phải mở lại.
Hãy bắt đầu với phiên bản thủ công trong bài viết này. Nếu bạn thấy mình chạy nó nhiều hơn một vài lần bằng tay, đó là cái đáng để đặt trên một chiếc hộp luôn bật sau khi bạn đã đi ngủ.
Cảm ơn bạn đã đọc bài viết này
Người sáng tạo: @0xclayn**
Lưu bài viết này
