Thay Apify bằng gì — và quy trình nào trong báo cáo đó đáng đem về dùng

Phần I — Bảy quy trình đem về dùng ngay

Đây là phần em đề xuất, KHÔNG phải phần chép lại. Xếp theo thứ tự đáng làm trước.

1. Chốt «ra 0 thì phải KÊU» Mọi đường ống trả về danh sách đều phải có một chốt: đếm số mục, bằng 0 thì báo động chứ KHÔNG đi tiếp lặng lẽ.
   Số thật trong báo cáo: đổi tên một lớp CSS thì mã tự sinh in ra danh sách rỗng và mã thoát vẫn là 0 — tức là mọi thứ phía sau đều tin rằng nó chạy tốt. Cào hàng tháng mà tưởng vẫn ổn là kịch bản có thật.
   Áp cho: bộ chấm bài, bộ đọc bình luận fanpage, bộ lấy báo cáo quảng cáo, bất cứ chỗ nào «không có dữ liệu» và «lấy dữ liệu hỏng» trông giống nhau.
2. Cắn thử chính cái chốt kiểm của mình Viết xong một phép kiểm thì phải chứng minh nó biết BÁO ĐỎ: cố tình trả bản gốc hỏng về chỗ cũ, chốt phải kêu.
   Báo cáo làm đúng thế: trả bản chưa vá về thì chốt kêu 4 mục trượt và trả mã 1; trả bản vá lại thì mã 0. Một phép kiểm chưa từng đỏ lần nào là một phép kiểm chưa ai biết nó có chạy hay không.
   Đây chính là thước ② em đặt cho người sửa mã đang thử việc.
3. Ghi «n/đ» thay vì đoán một con số cho đủ bảng Chỗ nào chưa chạy thật thì ghi thẳng là chưa đo được.
   Báo cáo có hai cột công cụ chưa hề chạy vì thiếu khoá trả phí. Người viết chấm được ô nào thì chấm, ô nào KHÔNG chấm được bằng cách đọc mã thì để trống, kèm một dòng nói rõ vì sao. Một bảng đủ ô mà có ô bịa thì hỏng hơn một bảng thiếu ô.
4. Mọi báo cáo phải có mục «CHƯA ĐO ĐƯỢC» Bản gốc dành hẳn một mục liệt kê 14 thứ chưa đo và lý do từng thứ.
   Em đề nghị lấy đây làm mục bắt buộc trong mọi báo cáo của Phòng Công Nghệ. Người đọc cần biết cái báo cáo này KHÔNG nói gì, chứ không chỉ biết nó nói gì.
5. Đừng để mô hình trong vòng lặp, nếu một đoạn mã làm được Sinh mã MỘT lần rồi chạy lại mãi.

   Cào 1000 trang bằng mô hình:      2,4 giờ  ·  1000 lượt hạn mức
   Cào 1000 trang bằng mã tự sinh:  12,5 phút ·     1 lượt
                                    nhanh hơn 11,5 lần · bỏ 999/1000 lượt

   Nguyên tắc rộng hơn: việc nào lặp lại và có khuôn cố định thì trả tiền mô hình đúng một lần để sinh ra đoạn mã, rồi chạy đoạn mã đó. Áp cho: đổi tên tệp hàng loạt, dựng trang từ dữ liệu, đóng gói bài, mọi việc đang gọi mô hình mỗi lượt mà đáng lẽ chỉ cần một lần.
6. Đo đường đi thật của dữ liệu, đừng tin cái nút tắt
   Ca thật trong báo cáo: gói phần mềm có nút tắt gửi số liệu, tài liệu ghi rõ cách tắt — đặt tắt rồi đọc lại vẫn trả về BẬT. Nút đó KHÔNG nối vào đâu cả. Và thứ nó gửi đi gồm nguyên văn trang vừa cào cùng nguyên văn câu trả lời của mô hình.
   Áp cho mọi công cụ mới cắm vào máy: đo bằng cái đếm chuyến mạng, KHÔNG đọc tài liệu rồi tin.
7. Tách «đã kiểm đạt» khỏi «đã dùng được việc» Báo cáo ghi rõ ô nào ĐÃ CHẠY THẬT, ô nào mới đọc mã. Hai trạng thái đó KHÔNG thay thế nhau — và đây đúng bài học nhà mình đã cắn ở một skill khác: thư mục kết quả rỗng 24 ngày vì chưa ai chạy nó lần nào.

Phần II — Về công cụ: chỗ nào bỏ Apify được, chỗ nào KHÔNG

Bảng tra nhanh, rút gọn cho việc của nhà

Việc của nhà mình rơi vào đâu

Em đối chiếu với chỗ Apify đang thật sự được nhắc tới trong hệ (đo được 24 tệp, đa số là tài liệu nghiên cứu chứ chưa phải đường ống chạy hằng ngày):

Phần III — Em đề nghị làm gì, theo thứ tự

Chỗ báo cáo gốc tự nhận là CHƯA ĐO

Ghi lại để không ai đọc bản tóm tắt này rồi tưởng đã đủ căn cứ:

• Hai gói đám mây chưa chạy lần nào — mọi điểm số của chúng là đọc mã, KHÔNG phải đo.
• Trang JavaScript nặng, trang phân trang, trang chống bot: chưa đo. Mà đó đúng là địa hạt của Apify.
• Tỉ lệ trang thật dính lỗi mất bản văn: mẫu mới có 2 trang, một trang qua, một trang mất 94,6%.
• Độ bền của mã tự sinh qua thời gian thật: mới mô phỏng, chưa theo dõi trang đổi cấu trúc thật.
• Tỉ lệ bịa: mỗi nhánh mới 3 lượt — đủ để nói «chưa thấy», KHÔNG đủ để nói «không xảy ra».
• Số lượt gọi ghi được là chặn trên, vì đồng hồ đếm là đồng hồ chung, có ghế khác dùng song song.