Bài 10: Thiết kế workflow nhiều bước với điểm duyệt
Thiết kế quy trình nhiều bước có điểm duyệt và kiểm soát lỗi: bắt đầu từ kết quả, phân vai Chat/Work/Codex và chạy lại có kiểm soát.
Anh Tuấn ở phòng kinh doanh quen giao việc kiểu nối tiếp: nhờ Work tổng hợp file doanh thu, dán kết quả vào phần nhận xét, rồi copy sang slide gửi sếp mỗi sáng thứ Hai. Một tuần nọ file gốc thiếu dòng doanh thu chi nhánh Đà Nẵng, AI vẫn tổng hợp trơn tru ra số 173 triệu thay vì con số đúng là 203 triệu, không ai dừng lại kiểm tra, slide sai lệch đã gửi đi trước khi phát hiện ra vào thứ Ba.
Chuyện xảy ra không phải vì AI kém, mà vì chuỗi việc anh Tuấn ghép nối không có điểm nào bắt buộc dừng lại kiểm tra trước khi đi tiếp. Đây chính là khác biệt giữa một dãy việc nối nhau và một quy trình có kiểm soát thật sự — nội dung bạn sẽ học trong bài này.
Sau bài này bạn sẽ làm được
- Viết rõ kết quả cuối cùng và ranh giới trước khi nghĩ tới công cụ nào sẽ dùng.
- Đi ngược từ sản phẩm cuối để liệt kê từng bước phụ thuộc, kèm đầu vào, đầu ra, người chịu trách nhiệm và bằng chứng hoàn thành.
- Gán đúng từng giai đoạn cho
Chat,Work,Codex, và chỉ thêmSkill,App,Scheduled Taskkhi thật cần. - Theo dõi tiến độ bằng 6 trạng thái rõ ràng, đặt điểm duyệt bắt buộc và giới hạn số lần thử lại.
Một chuỗi việc nối nhau chưa phải là quy trình tốt
Nhiều người nghĩ có "quy trình" nghĩa là các bước đã xếp theo thứ tự A rồi B rồi C. Thực ra thứ tự chỉ là phần dễ nhất. Một quy trình đáng gọi là tốt cần thêm ba thứ: mỗi bước biết rõ nó phụ thuộc vào bước nào trước đó, có ít nhất một điểm bạn dừng lại kiểm tra, và có cách xử lý khi một bước ra kết quả sai hoặc không ra kết quả gì. Thiếu ba thứ này, chuỗi việc của anh Tuấn vẫn chạy tốt — cho tới ngày dữ liệu đầu vào có vấn đề, và lỗi đó trôi thẳng tới slide gửi sếp mà không ai chặn lại.
Bắt đầu từ kết quả cuối và ranh giới, đừng bắt đầu từ công cụ
Sai lầm phổ biến khi dựng workflow là mở Work lên trước, rồi vừa gõ vừa nghĩ tiếp theo làm gì. Cách làm ngược lại hiệu quả hơn nhiều: viết thẳng kết quả cuối cùng bạn cần cầm trong tay, càng cụ thể càng tốt. Với báo cáo tuần phòng kinh doanh, kết quả cuối là "slide 5 trang, số liệu khớp 100% với file doanh thu gốc, gửi trước 9h sáng thứ Hai". Kèm theo đó là ranh giới: AI được tổng hợp số liệu, viết nhận xét, dựng khung slide; AI không được tự gửi email, không được tự sửa file doanh thu gốc, không được thêm nhận định không có trong số liệu. Có kết quả và ranh giới rõ, bạn mới quay lại chọn công cụ nào phù hợp.
Prompt mẫu cho phần giao kết quả và ranh giới:
Kết quả cuối cần có: slide 5 trang báo cáo doanh thu tuần, số liệu khớp với file doanh thu.xlsx tôi đính kèm.
Bạn được: tổng hợp số liệu theo chi nhánh, viết nhận xét ngắn, dựng khung slide.
Bạn không được: tự gửi file cho ai, tự đổi số trong file gốc, thêm nhận định không có trong số liệu.
Nếu thiếu dữ liệu chi nhánh nào, báo cho tôi trước khi tổng hợp, không tự đoán số.Đi ngược từ sản phẩm cuối để tìm từng bước phụ thuộc
Khi đã có kết quả cuối, bạn đi ngược lại bằng câu hỏi "để có được thứ này, ngay trước đó cần gì?". Cứ hỏi tiếp như vậy tới khi chạm vào dữ liệu thô hoặc một việc chỉ con người mới quyết được. Với báo cáo tuần, chuỗi ngược ra như sau: đóng gói slide gửi đi, trước đó là kiểm tra chéo số liệu, trước đó là dựng slide, trước đó là viết báo cáo văn bản, trước đó là lập kế hoạch tổng hợp, và trước tất cả là kiểm kê dữ liệu đầu vào từ các chi nhánh. Với mỗi bước, bạn ghi rõ bốn thứ: đầu vào (file hoặc kết quả của bước trước), đầu ra (thứ bước sau cần dùng), ai chịu trách nhiệm (AI soạn hay bạn tự quyết), và bằng chứng để biết đã xong. Ví dụ bước kiểm kê dữ liệu chỉ coi là xong khi bạn có đủ số liệu từ mọi chi nhánh, không thiếu chi nhánh nào, không phải khi AI báo "đã xong".
Gán đúng người cho đúng việc: Chat, Work, Codex và khi nào thêm công cụ khác
Bạn nhớ lại cách phân biệt ba không gian ở Bài 1 để gán cho từng giai đoạn. Kiểm kê dữ liệu và lập kế hoạch tổng hợp là việc nhiều bước, nhiều file, nên giao cho Work. Một câu hỏi đơn lẻ, ví dụ giải thích nhanh vì sao doanh thu món bún bò giảm trong tuần, hỏi ngay trong Chat là đủ. Nếu báo cáo của bạn nằm trên một trang nội bộ cần sửa mã nguồn, đó là việc của Codex. Bạn chỉ thêm Skill khi cách làm này sẽ lặp lại nhiều tuần liên tiếp, để không phải giao lại từng chi tiết mỗi lần như đã học ở Bài 9. Bạn chỉ thêm Scheduled Task khi bước kiểm kê dữ liệu có thể tự chạy đúng giờ mỗi sáng thứ Hai. Bạn chỉ thêm App khi có một tích hợp thật sự cần thiết, như đọc trực tiếp file lưu trên hệ thống nội bộ công ty. Thêm công cụ khi chưa cần chỉ làm workflow rối hơn, không nhanh hơn.
Bước nối tiếp, bước song song và 6 trạng thái theo dõi
Không phải bước nào cũng phải chờ bước trước xong mới bắt đầu. Kiểm kê dữ liệu chắc chắn phải xong trước khi lập kế hoạch tổng hợp — đây là bước tuần tự. Nhưng trong lúc AI viết phần nhận xét văn bản, bạn có thể giao song song việc dựng khung slide trống chưa cần số liệu cuối cùng — đây là bước song song, làm cùng lúc để tiết kiệm thời gian chờ. Để không mất dấu việc nào đang ở đâu, bạn theo dõi mỗi bước bằng 6 trạng thái: CHƯA CHẠY khi chưa giao, ĐANG CHẠY khi AI đang xử lý, CẦN DUYỆT khi AI đã xong phần của mình và đang chờ bạn xem, ĐẠT khi bạn đã kiểm và số liệu khớp, LỖI khi kết quả sai hoặc thiếu và cần sửa, DỪNG khi bạn chủ động ngắt vì phát hiện vấn đề ở bước trước đó. Trạng thái ĐẠT chỉ được gắn khi có bằng chứng cụ thể, ví dụ tổng doanh thu trong báo cáo cộng đúng 203 triệu như file gốc, không phải vì đọc lướt thấy có vẻ hợp lý.
Điểm duyệt bắt buộc và giới hạn số lần thử lại
Một workflow đáng tin cần ít nhất hai điểm duyệt bạn không bỏ qua. Điểm duyệt thứ nhất đặt trước khi AI bắt đầu tính toán: bạn xem kế hoạch tổng hợp có đủ chi nhánh, đúng công thức chưa, sai ở bước này sửa còn rẻ. Điểm duyệt thứ hai đặt trước khi tạo ra thứ phụ thuộc vào báo cáo, cụ thể là trước khi dựng slide: bạn kiểm số liệu trong báo cáo văn bản có khớp file gốc chưa, vì slide sai sẽ mang lỗi đi thẳng tới sếp giống chuyện của anh Tuấn. Song song với điểm duyệt, bạn đặt giới hạn chạy lại: tối đa bao nhiêu lần AI được thử lại nếu số liệu không khớp, ví dụ 2 lần, chờ tối đa bao lâu cho một bước, ví dụ 10 phút, và điều kiện dừng nếu vẫn báo LỖI sau đó. Khi hết giới hạn, chuyển trạng thái sang DỪNG và báo cho bạn, không để AI tự lặp lại vô hạn với hy vọng lần sau sẽ đúng.
Lỗi thường gặp
- Ghép nhiều bước liên tiếp nhưng không ghi rõ đầu vào và đầu ra của từng bước. Cách xử lý: quay lại đi ngược từ kết quả cuối, viết đủ 4 mục cho mỗi bước trước khi giao AI.
- Chỉ có một điểm duyệt ở cuối cùng, sau khi mọi thứ đã làm xong hết. Cách xử lý: thêm điểm duyệt trước khi AI bắt đầu tính toán, sửa lỗi sớm luôn rẻ hơn sửa ở cuối.
- Để AI tự thử lại không giới hạn mỗi khi gặp lỗi, tốn thời gian và chi phí. Cách xử lý: đặt số lần thử tối đa và thời gian chờ ngay từ lúc giao việc.
- Gắn trạng thái
ĐẠTchỉ vì thấy kết quả có vẻ ổn. Cách xử lý: luôn đòi bằng chứng cụ thể như số liệu khớp file gốc, không dựa vào cảm giác.
Checklist trước khi làm
- Đã viết rõ kết quả cuối cùng và ranh giới AI được làm, không được làm.
- Đã đi ngược từ kết quả cuối, ghi đầu vào, đầu ra, người chịu trách nhiệm, bằng chứng hoàn thành cho từng bước.
- Đã gán đúng từng giai đoạn cho
Chat,Work, hoặcCodex, chỉ thêm công cụ khác khi thật cần. - Đã đánh dấu rõ bước nào tuần tự phải chờ, bước nào làm song song được.
- Đã đặt ít nhất hai điểm duyệt bắt buộc và giới hạn số lần thử lại trước khi bắt đầu.
Một workflow có phụ thuộc rõ, điểm duyệt đúng chỗ, và giới hạn thử lại sẽ cho bạn biết chính xác việc đang ở đâu, thay vì chỉ hy vọng mọi thứ trôi qua suôn sẻ như chuỗi việc từng khiến anh Tuấn gửi nhầm số cho sếp. Bài tiếp theo sẽ đưa bạn sang Codex, dành riêng cho người không biết lập trình nhưng vẫn cần AI đọc và sửa đúng tệp kỹ thuật.