Quy trình AI của bạn đang chạy ngay bây giờ.
Bạn chỉ không biết rằng nó đã ngừng hoạt động từ ba ngày trước.
Nó vẫn đang kích hoạt. Vẫn đang đốt API credits. Vẫn đang gửi đầu ra mà không ai đọc. Agent mà bạn đã dành hai cuối tuần để xây dựng đang tạo ra rác với giá 0,40 đô la mỗi đống rác — và bạn sẽ không phát hiện ra cho đến khi một khách hàng chụp màn hình và gửi cho bạn vào một ngày thứ Ba.
Đây không phải là xui xẻo. Đây là kết quả mặc định.
Hãy lưu lại cái này. Bạn sẽ đọc nó hai lần.
Nghĩa địa 30 ngày
Mỗi tuần, hàng trăm nhà sáng lập xây dựng các quy trình AI và đăng chúng lên Twitter.
Bản demo trông sạch sẽ. Thread nhận được lượt thích. Các câu trả lời nói "đây là tương lai."
Ba mươi ngày sau, quy trình đã chết.
Không phải bị xóa. Không phải bị thay thế. Chết và vẫn đang chạy. Vẫn tính phí thẻ. Không tạo ra gì hữu ích. Nhà sáng lập đã chuyển đi. Agent không nhận được thông báo.
90% các quy trình AI được xây dựng ngày hôm nay sẽ không tồn tại qua tháng đầu tiên trong sản xuất. Không phải vì các mô hình kém. Không phải vì các ý tưởng sai. Mà vì những người xây dựng đã mắc ba sai lầm đảm bảo thất bại — và không ai nói cho họ biết những sai lầm đó là gì trước khi họ tung ra.
Đây là bài viết đó.
Tại sao chúng chết
Đây là giải phẫu của một cái chết quy trình. Nó luôn là cùng một chuỗi.
Ngày 1: Bạn xây dựng nó. Nó hoạt động hoàn hảo trong bản demo. Bạn cảm thấy như mình đã mở khóa một điều gì đó.
Ngày 3: Nó vẫn hoạt động. Bạn ngừng kiểm tra nó cẩn thận.
Ngày 9: Một cái gì đó thay đổi. Một định dạng phản hồi API thay đổi nhẹ. Một nguồn mà nó đang đọc đi sau tường đăng nhập. Mô hình diễn giải một trường hợp ngoại lệ khác với ngày đầu tiên. Đầu ra lặng lẽ suy giảm. Không ai nhận thấy.
Ngày 14: Quy trình hiện đang tạo ra đầu ra về mặt kỹ thuật là một phản hồi nhưng về bản chất là vô dụng. Nó vẫn đang chạy. Bạn vẫn đang trả tiền cho nó.
Ngày 23: Một khách hàng hoặc đồng nghiệp đề cập rằng có điều gì đó không ổn. Bạn điều tra. Bạn tìm thấy 12 ngày đầu ra hỏng mà bạn nghĩ đã được xử lý.
Ngày 30: Bạn tiêu diệt nó. Bạn tự nhủ AI chưa sẵn sàng. Bạn chuyển đi.
Mô hình không làm bạn thất vọng. Bản dựng đã làm mô hình thất vọng.
3 quy tắc phân biệt 10% với phần còn lại
Những nhà sáng lập có quy trình sống sót 30 ngày, 90 ngày, một năm — họ không thông minh hơn. Họ không có prompt tốt hơn. Họ xây dựng với ba quy tắc mà mọi người khác bỏ qua.
Quy tắc 1 — Không có mô tả công việc, không có agent
Hầu hết mọi người xây dựng agent chỉ với một vibe.
"Giúp tôi với nội dung." "Theo dõi đối thủ cạnh tranh." "Xử lý email khách hàng."
Đó không phải là mô tả công việc. Đó là một điều ước. Và những điều ước không tồn tại qua cuối tuần.
Một mô tả công việc có năm phần:
Nó theo dõi cái gì. Kích hoạt hoặc lịch trình cụ thể. "Mỗi thứ Hai lúc 7 giờ sáng" hoặc "mỗi khi một GitHub issue mới được mở với nhãn 'bug'" hoặc "mỗi khi một email đến từ một tên miền không có trong danh sách liên hệ của tôi." Không phải "thỉnh thoảng" hoặc "khi phù hợp."
Nó đọc cái gì. Các nguồn chính xác. Không phải "kiểm tra internet." "Kéo từ ba RSS feed này, cơ sở Airtable này, và 7 ngày qua của kênh Slack này." Cụ thể. Có giới hạn. Không mơ hồ.
Nó tạo ra cái gì. Định dạng đầu ra chính xác. Không phải "một bản tóm tắt." "Một bản tin ba phần: phát hiện chính trong một câu, ba gạch đầu dòng hỗ trợ với một nguồn mỗi cái, một hành động được đề xuất. Dưới 300 từ. Trong Google Doc này."
Nó không làm gì. Các rào cản. "Không bao giờ gửi email bên ngoài mà không có sự chấp thuận của con người." "Không bao giờ sửa đổi cơ sở dữ liệu sản xuất." "Không bao giờ đăng trực tiếp. Luôn lưu vào bản nháp." Những điều bạn cho là hiển nhiên sẽ là những điều làm bạn cháy.
Làm thế nào bạn biết nó đã hoạt động. Điều kiện thành công. "Nếu bản tin trống, hãy gửi cho tôi một tin nhắn Slack nói không tìm thấy cập nhật liên quan. Không gửi một bản tin trống."
Vibe không tồn tại qua cuối tuần. Mô tả công việc thì có.
Mọi quy trình bạn xây dựng từ hôm nay trở đi bắt đầu bằng một mô tả công việc. Không phải một prompt. Một mô tả công việc.
Quy tắc 2 — Lỗi thầm lặng là lỗi duy nhất giết chết bạn
Lỗi ồn ào thì ổn. Lỗi ồn ào gửi một lỗi. Chúng dừng quy trình. Chúng đánh thức bạn. Bạn sửa chúng.
Lỗi thầm lặng là những lỗi giết chết doanh nghiệp.
Một lỗi thầm lặng trông giống như thành công. Quy trình chạy. Đầu ra đến. Định dạng đúng. Nội dung sai — một chút, rồi nhiều hơn, rồi hoàn toàn — và vì nó trông đúng, không ai kiểm tra nó.
Đây là cách lỗi thầm lặng xảy ra trong thực tế:
Agent nội dung của bạn viết 30 bài. Bạn thiết lập để nó tự động lên lịch những bài đạt điểm trên 80 theo tiêu chí nội bộ của bạn. Tiêu chí được hiệu chỉnh dựa trên 20 bài đầu tiên của bạn. Vào ngày 15, mô hình bắt đầu diễn giải tiêu chí của bạn khác đi. Các bài đạt điểm 82 giờ đây là tầm thường theo tiêu chuẩn thực tế của bạn. Chúng vẫn được đăng. Tương tác của bạn giảm. Bạn đổ lỗi cho thuật toán.
Agent nghiên cứu của bạn gửi một bản tin hàng tuần. Vào ngày 11, một trong những nguồn mà nó đang đọc thay đổi cấu trúc URL. Agent không thể tìm nạp nó một cách thầm lặng. Nó lấp đầy khoảng trống bằng dữ liệu cũ được lưu trong bộ nhớ đệm và không báo hiệu khoảng trống đó. Bạn đọc một bản tin dựa trên thông tin cũ và đưa ra quyết định dựa trên nó.
Agent phân loại hộp thư đến của bạn soạn thảo câu trả lời. Vào ngày 8, nó bắt đầu phân loại một loại email nhất định là ưu tiên thấp vì tên người gửi khớp với một mẫu trong quá trình đào tạo của nó. Bạn bỏ lỡ ba email quan trọng từ một khách hàng mới tình cờ có cùng họ với một bản tin bạn chưa bao giờ đọc.
Trong mọi trường hợp: quy trình đã chạy. Không có lỗi nào được đưa ra. Bạn vẫn mất.
Giải pháp là xác minh đầu ra bắt buộc. Mỗi agent cần ba thứ:
Đầu ra canary. Một trường trong mỗi đầu ra dễ xác minh và khó giả mạo. Dấu thời gian của nguồn gần nhất mà nó đã đọc. Số lượng mục nó đã xử lý. Điểm tin cậy. Một thứ bạn có thể nhìn lướt qua trong hai giây và biết agent thực sự đã làm việc.
Cảnh báo lỗi thầm lặng. Nếu agent không tạo ra gì, hoặc tạo ra thứ gì đó dưới ngưỡng, nó không gửi một đầu ra trống. Nó gửi cho bạn một cảnh báo. "Không tìm thấy kết quả trong chu kỳ này — đây là những gì tôi đã kiểm tra và tại sao tôi có thể không tìm thấy gì." Không có gì luôn hữu ích hơn một kết quả trống thuyết phục.
Kiểm tra điểm hàng tuần. Chọn một đầu ra mỗi tuần cho mỗi agent. Đọc nó đầy đủ. So sánh nó với những gì bạn sẽ tự viết. Việc này mất bốn phút. Nó bắt kịp sự trôi trước khi sự trôi trở thành thất bại.
Agent không thất bại một cách ồn ào. Hãy xây dựng cho những hỏng hóc thầm lặng.
Quy tắc 3 — Máy tính xách tay của bạn không phải là hạ tầng
Đây là nơi 90% người xây dựng chết.
Họ xây dựng cục bộ. Bản demo hoạt động. Họ đăng thread Twitter. Ai đó hỏi liệu nó có đang chạy trong sản xuất không. Họ nói có. Điều họ muốn nói là: nó đang chạy trên MacBook của họ, hiện đang mở, trên bàn làm việc của họ, trong căn hộ của họ, kết nối với WiFi gia đình của họ, và sẽ ngừng hoạt động khi họ đóng nắp để đi sân bay vào thứ Năm.
Máy tính xách tay của bạn không phải là hạ tầng. Nó là một môi trường phát triển tình cờ đang chạy một thứ gì đó quan trọng ngay bây giờ.
Đây là những gì xảy ra với các agent được lưu trữ trên laptop:
MacOS đẩy một bản cập nhật lúc 4 giờ sáng. Máy khởi động lại. Agent dừng lại. Không ai biết cho đến thứ Hai.
Bạn đóng nắp trên chuyến bay. Sáu giờ quy trình bị bỏ lỡ. Agent phân loại hộp thư đến đã không phân loại. Agent săn lỗi đã không săn. Agent báo cáo hàng ngày không gửi gì.
WiFi nhà bạn bị mất kết nối trong hai mươi phút. Agent thử lại. Thất bại. Tiếp tục. Không ghi lại gì. Cửa sổ mà nó được cho là bắt đã mất.
Bạn đi nghỉ. Laptop ở nhà. Mọi thứ ở nhà cùng với nó.
Hạ tầng thực sự chạy khi bạn không theo dõi. Nó chạy khi bạn đang ngủ, trên máy bay, trong bữa tối, không thể liên lạc được vào cuối tuần. Nó không cần bạn giữ nắp mở.
Quy tắc rất đơn giản: nếu quy trình cần chạy nhiều hơn một lần và bạn không thể để nó bỏ lỡ một chu kỳ, nó không sống trên laptop của bạn.
Ba lựa chọn hạ tầng thực sự hiệu quả:
Một VPS với trình quản lý tiến trình. Một máy chủ 12 đô la/tháng chạy PM2 hoặc Supervisor. Agent của bạn chạy như một quy trình được quản lý. Nếu nó sập, PM2 tự động khởi động lại nó. Nếu máy chủ khởi động lại, PM2 khởi động nó khi khởi động. Rẻ. Đáng tin cậy. Không hào nhoáng. Hiệu quả.
Một nền tảng agent được quản lý. Được xây dựng chuyên dụng cho việc này. Xử lý các lần khởi động lại, giám sát, cảnh báo. Tốn kém hơn VPS. Tiết kiệm cho bạn những cuối tuần bạn sẽ dành để gỡ lỗi tại sao quy trình chết. Đáng giá một khi các agent của bạn đang tạo ra giá trị thực.
Serverless với trình lập lịch. AWS Lambda hoặc Google Cloud Functions được kích hoạt bởi EventBridge hoặc Cloud Scheduler. Không có hạ tầng nào để quản lý. Bạn trả tiền mỗi lần thực thi. Mở rộng quy mô về không khi không chạy. Lựa chọn tốt nhất cho các agent chạy theo lịch trình cố định thay vì liên tục.
Không có cái nào phức tạp. Tất cả đều yêu cầu mười lăm phút thiết lập. Mọi cái trong số chúng đều sẽ cứu bạn khỏi bản cập nhật macOS lúc 4 giờ sáng giết chết các agent và buổi sáng thứ Hai của bạn.
Đóng laptop lại. Các agent nên tiếp tục chạy.
Quy trình làm việc sống sót
Đây là quy trình làm việc 90 ngày trông như thế nào khi cả ba quy tắc được áp dụng.
Mô tả công việc: Mỗi thứ Hai lúc 7 giờ sáng, đọc các bài đăng trong 7 ngày qua từ 5 tài khoản đối thủ cạnh tranh này và 3 bản tin ngành này. Trích xuất bất kỳ thông báo sản phẩm nào, thay đổi giá, hoặc nội dung hoạt động trên 500 lượt tương tác. So sánh với bản tin tuần trước. Gắn cờ bất kỳ điều gì mới. Xuất ra một bản tin ba phần: điều gì đã thay đổi, điều gì đang thu hút sự chú ý, lỗ hổng nào họ để lại. Nếu không tìm thấy thay đổi, gửi cảnh báo: "tuần yên tĩnh — đây là những gì đã được kiểm tra." Chuyển đến trang Notion này và gửi thông báo Slack.
Đầu ra canary: Mỗi bản tin bao gồm: "Nguồn được kiểm tra: 8. Mục đã xử lý: [N]. Dấu thời gian mục gần nhất: [dấu thời gian]." Nếu N bằng 0 hoặc dấu thời gian cũ hơn 8 ngày, nó gửi cảnh báo thay vì bản tin.
Hạ tầng: Chạy trên một VPS 12 đô la/tháng. PM2 quản lý quy trình. Nếu nó sập, nó khởi động lại trong 30 giây. Đánh giá log hàng tuần mất 3 phút mỗi thứ Sáu.
Kiểm tra điểm: Mỗi thứ Sáu, một bản tin được đọc đầy đủ. Mất 4 phút. Đã bắt kịp sự trôi hai lần trong sáu tháng.
Quy trình đó đã chạy được sáu tháng. Nó đã bỏ lỡ hai chu kỳ — cả hai lần nó đều gửi cảnh báo giải thích tại sao. Nó chưa bao giờ thất bại một cách thầm lặng.
Đó là sự khác biệt giữa một quy trình sống sót và một quy trình chết vào ngày thứ chín.
Sự thật khó chịu
Hầu hết mọi người sẽ đọc cái này, gật đầu, và xây dựng agent tiếp theo giống như cách họ đã xây dựng cái trước.
Một prompt. Một bản demo. Một thread Twitter. Ba mươi ngày im lặng. Một quy trình chết không ai chính thức tiêu diệt.
Ba quy tắc không phức tạp. Một mô tả công việc mất hai mươi phút để viết. Xác minh đầu ra chỉ cần một trường và một điều kiện. Hạ tầng mất mười lăm phút để thiết lập.
Khoảng cách không phải là kiến thức. Khoảng cách là liệu bạn có làm điều đó trước khi tung ra hay sau khi quy trình thất bại.
Mọi agent bạn xây dựng mà không có mô tả công việc là một agent bạn sẽ xây dựng lại. Mọi agent không có xác minh đầu ra là một agent sẽ thất bại một cách thầm lặng. Mọi agent trên laptop của bạn là một agent sẽ chết vào lần tiếp theo bạn đóng nắp.
Xây dựng chúng đúng một lần. Chúng chạy mãi mãi.
Theo dõi @sairahul1 để biết thêm các playbook hoàn chỉnh về xây dựng quy trình AI sống sót khi tiếp xúc với thế giới thực.
Tóm tắt
90% các quy trình AI chết trong 30 ngày. Luôn là ba lý do giống nhau.
Quy tắc 1 — Không có mô tả công việc, không có agent. Vibe không tồn tại qua cuối tuần. Xác định nó theo dõi cái gì, đọc cái gì, tạo ra cái gì, tránh cái gì, và làm thế nào bạn biết nó đã hoạt động. Trước khi bạn viết một prompt duy nhất.
Quy tắc 2 — Lỗi thầm lặng là lỗi duy nhất giết chết bạn. Lỗi ồn ào thì ổn. Lỗi thầm lặng trông giống như thành công cho đến khi một khách hàng tìm thấy chúng. Xây dựng một đầu ra canary, một cảnh báo lỗi thầm lặng, và kiểm tra điểm hàng tuần vào mỗi agent.
Quy tắc 3 — Máy tính xách tay của bạn không phải là hạ tầng. Nó chạy khi nắp mở. Agent thực sự chạy khi bạn đang ngủ, trên máy bay, không thể liên lạc được vào cuối tuần. VPS, nền tảng được quản lý, hoặc serverless. Chọn một cái. Thiết lập nó trước khi bạn tung ra.
Các agent sống sót không thông minh hơn. Chúng được xây dựng đúng.
