Khi Workflow AI Thất Bại Trong Marketing: Điều Gì Thực Sự Xảy Ra

Tôi sẽ kể cho bạn về lần hệ thống review sprint của Prova bị hỏng theo một cách cụ thể và đáng xấu hổ, vì tôi nghĩ nó hữu ích hơn danh sách các chế độ thất bại trừu tượng.

Sprint review trong Prova là cốt lõi của cách chương trình hoạt động. Người học nộp bài — spec workflow, prototype đang hoạt động — và người review AI đánh giá nó theo tiêu chí cho sprint đó. Người review đưa ra phản hồi có cấu trúc. Người học chỉnh sửa hoặc vượt qua. Đây là sự khác biệt giữa "tôi đọc về điều này" và "tôi xây thứ gì đó được đánh giá."

Đây là điều đã xảy ra trong một phiên bản đầu: người review AI đang nhận ngữ cảnh không nhất quán về sprint người dùng hiện đang thực hiện. Hệ thống đang truyền thông tin sprint vào review prompt, nhưng dữ liệu đôi khi cũ — một giá trị được cache từ phiên trước, hoặc phiên mà người dùng đã điều hướng giữa các sprint mà không có trạng thái cập nhật đúng cách.

Kết quả là người review thỉnh thoảng đánh giá bài nộp theo tiêu chí sprint sai. Người dùng nộp work cho Sprint 3 sẽ nhận phản hồi được hiệu chỉnh cho Sprint 1 — nơi tiêu chí đơn giản hơn và bài nộp mong đợi kém phát triển hơn. Phản hồi nghe có vẻ tự tin. Nó mạch lạc. Nó đang đánh giá sai thứ.

Người dùng nhận được tín hiệu mâu thuẫn. Một số vượt qua dễ dàng với bài nộp nên đòi hỏi nhiều công việc hơn. Một số nhận phản hồi chỉ ra các yếu tố thiếu đúng cho sprint khác. Phần tệ nhất là phản hồi nghe có vẻ có thẩm quyền trong cả hai trường hợp.

Tôi không phát hiện ra ngay vì các review không hiển nhiên là bị hỏng — chúng sai một cách tinh tế. Ngôn ngữ trôi chảy. Cấu trúc đúng. Tiêu chí đang được áp dụng chỉ là cho sprint khác.

Điều thực sự gây ra nó là gì

Không phải model. Là ngữ cảnh.

Người review AI được cho bất kỳ thông tin sprint nào có trong prompt tại thời điểm gọi. Khi thông tin đó không chính xác — cũ, định tuyến sai, hoặc bị ghi đè bởi bug phiên — người review làm việc với những gì nó có. Nó không có cách nào biết ngữ cảnh sai, vì không có gì trong prompt bảo nó xác nhận sprint ID so với trạng thái hiện tại của người dùng.

Hệ thống tin tưởng đầu vào mà không xác minh nó. Đầu vào đôi khi sai. Đầu ra luôn sai một cách tự tin theo cùng hướng với đầu vào.

Đây là cách phổ biến nhất workflow AI thất bại trong marketing, không chỉ trong những gì tôi xây: dữ liệu đầu vào không nhất quán chảy vào đầu ra nghe tự tin với không có review giữa chúng.

Tại sao cách sửa không phải là model tốt hơn

Khi loại thất bại này xảy ra, bản năng là nhìn vào AI. Có lẽ model không đủ thông minh. Có lẽ công cụ khác sẽ phát hiện ra.

Nó sẽ không. Model không thể xác minh ngữ cảnh không được cung cấp. Model có năng lực hơn sẽ tạo ra câu trả lời sai trôi chảy hơn, thực sự khó phát hiện hơn.

Cách sửa thực sự nằm trong thiết kế workflow: ngữ cảnh nào mỗi lần gọi prompt này đòi hỏi, và làm thế nào để đảm bảo ngữ cảnh đó luôn hiện tại và chính xác?

Trong Prova, cách sửa là thêm một khối ngữ cảnh có cấu trúc vào đầu mỗi review prompt bao gồm rõ ràng sprint ID, bộ tiêu chí hiện tại, và lịch sử nộp trước đó của người dùng cho sprint đó. Không lấy từ cache. Lấy mới tại thời điểm gọi. Prompt cũng bao gồm hướng dẫn rõ ràng: "Nếu sprint ID hoặc bộ tiêu chí bị thiếu hoặc được đánh dấu là không xác định, đừng tiến hành review — trả về lỗi yêu cầu ngữ cảnh đúng."

Dòng cuối đó là quan trọng. Nó cho người review một hành vi được xác định cho đầu vào không chắc chắn, thay vì mặc định thành đầu ra tự tin dựa trên dữ liệu xấu.

Pattern chung

Bốn thứ, theo thứ tự, gây ra thất bại workflow AI trong marketing:

1. Đầu vào không nhất quán. Workflow nhận các cấu trúc dữ liệu khác nhau vào các thời điểm khác nhau, và prompt không xử lý sự biến đổi. Model làm hết sức với bất cứ thứ gì nó nhận.
2. Không có review đầu ra trước khi ra ngoài. Ai đó tự động hóa bước tạo nhưng không phải bước review. Đầu ra tiếp cận khách hàng, báo cáo lãnh đạo, hoặc trang được xuất bản mà không có con người đọc nó.
3. Prompt drift. Prompt gốc hoạt động cho use case như nó được thiết kế. Sáu tháng sau, đầu vào thay đổi một chút, use case phát triển, nhưng prompt không thay đổi. Nó vẫn chạy. Nó không còn được hiệu chỉnh cho những gì nó nhận.
4. Không có tài liệu thất bại. Khi có sự cố, nó được sửa một cách lặng lẽ. Nhóm không ghi lại điều gì đã xảy ra, điều gì gây ra nó, hoặc cách sửa là gì. Ba tháng sau, người khác xây cùng lỗi vào workflow khác.

Cách xây checkpoint review hoạt động được

Checkpoint review không phải là người đọc mọi đầu ra — điều đó phá vỡ mục đích của tự động hóa. Đó là quy tắc quyết định được xác định cho đầu ra nào được review và điều gì xảy ra khi có gì đó thất bại.

Với bất kỳ workflow AI nào tạo ra đầu ra tiếp cận khách hàng hoặc lãnh đạo, xác định: đầu ra đáng ngờ trông như thế nào? Điều gì kích hoạt review của con người? Phương án dự phòng là gì nếu review thất bại? Những câu trả lời này thuộc về tài liệu thiết kế workflow trước khi hệ thống ra mắt.

Theo kinh nghiệm của tôi, checkpoint phát hiện thất bại khoảng hai lần nhiều hơn tần suất nó được kích hoạt bởi vấn đề thực sự. Hầu hết thời gian, đầu ra ổn. Nhưng checkpoint hiện diện là điều làm nhóm sẵn lòng tin tưởng workflow — vì họ biết chế độ thất bại được xử lý.

Điều này có nghĩa gì cho việc xây dựng

Bài Kiểm Tra Thực Tế Của AI Builder đề cập đến pattern rộng hơn về những gì khó hơn trông như thế nào khi bạn bắt đầu xây. Bài này về một cơ chế cụ thể: dữ liệu đầu vào không nhất quán chảy vào đầu ra AI nghe tự tin mà không có review giữa chúng.

Sự khó chịu khi viết điều này là mục đích. Tôi đã xây nó. Nó bị hỏng theo cách cụ thể và có thể đoán trước mà tôi đáng lẽ phải thiết kế xung quanh sớm hơn. Bài học đáng tin cậy hơn khi đến từ thất bại cụ thể hơn là cảnh báo giả thuyết.

Khi bạn thiết kế workflow AI đầu tiên cho marketing, checkpoint review không phải tùy chọn. Tích hợp nó từ đầu. Model sẽ tạo ra đầu ra tự tin bất kể nó nhận gì. Checkpoint là phần duy nhất của hệ thống biết sự khác biệt.

Cheers, Chandler