quanbi.dev
Sai lầm khi tự động hoá bằng AI: máy dập nặng nện xuống một món chạm trổ nhỏ, còn dãy khối vuông giống hệt nhau thì một cái nhíp bé gắp từng cái

Automation & AI AgentsGiải thích

Bốn lỗi mình mắc lúc quyết việc nào giao cho máy

Quân BiCập nhật 8 phút đọc15 lượt xem

Mình để máy chọn góc nhìn cho từng bài viết, còn mình ngồi bấm chạy lại test bằng tay. Sai lầm khi tự động hoá bằng AI của mình nằm gọn trong câu trên. Máy nhận phần cần cân nhắc, mình ôm phần máy làm sạch hơn người. Ba lỗi còn lại khó nhìn hơn, và mình mất lâu hơn mới thấy.

Bốn sai lầm khi tự động hoá bằng AI

Cả bốn đều là lỗi xếp việc. Không cái nào là lỗi của model, và đổi model không cứu được cái nào.

Ban đầu mình tưởng đây là bốn chuyện riêng, xảy ra ở bốn chỗ khác nhau trong hệ thống. Hoá ra chúng cùng một chuyện. Lần nào mình cũng tin vào một thứ mình không tự soi được.

Cách mình chia việc thành bốn nhóm nằm ở bài tự động hoá sai chỗ. Bài này chỉ nói về mấy lần mình xếp nhầm nhóm.

Lỗi một: giao máy phần phán đoán

Mình giao cho máy việc chọn góc nhìn cho từng bài. Cùng lúc đó mình vẫn tự tay chạy lại test sau mỗi lần agent sửa code.

Vòng lặp hồi đó rất cụ thể. Agent sửa xong một chỗ, mình mở terminal, gõ lệnh chạy test, ngồi nhìn nó chạy hết, rồi đọc dòng cuối. Một ngày nhiều lần như vậy.

Hai việc này nên đổi chỗ cho nhau. Chọn góc nhìn thì không có ai chấm được, còn chạy lại test thì kết quả xanh đỏ rõ ràng, chạy bao nhiêu lượt cũng ra một kiểu.

Cái giá không phải một lần hỏng. Nó là một xấp draft đọc trôi mà nhạt, cộng với thời gian mình đốt cho việc máy làm được mà không cần ai ngồi canh.

Lỗi xếp việc ở đây thô nhất trong cả bốn. Mình chọn theo cái nào nghe oai hơn, chứ không theo cái nào kiểm được.

Lỗi hai: tin log vì nó trông khoẻ

Mình có một background job đáng lẽ chạy hằng ngày. Nó chưa bao giờ được đặt lịch cron.

Nên nó chỉ chạy đúng những lần mình gõ tay. Mỗi lần như vậy nó chạy sạch, in ra một dòng thành công, rồi thoát. Giữa các lần đó nó nằm im, và không có gì phát ra tín hiệu.

Không ai phát hiện suốt nhiều tuần. Lý do rất tầm thường: file log nó ghi vào là file không ai mở ra đọc. Nội dung trong đó vẫn dài thêm, vì mỗi lần mình gõ tay lại thêm một dòng trông bình thường.

Đoạn code không sai một chữ nào. Thứ hỏng là niềm tin của mình rằng nó chạy hằng ngày.

Chỗ mình xếp nhầm rất cụ thể. Mình coi "có ghi log" là "kiểm được", trong khi hai thứ đó không dính gì tới nhau. Mấy kiểu hỏng lặng lẽ khác mình gom ở bài AI làm sai mà không ai biết.

Lỗi ba: cài hỏng nặng hơn cài thiếu

Một dependency cài hỏng làm chết một bước build ngay dòng đầu. Lỗi có in ra.

Nó nằm lẫn trong một dòng log giữa đống chữ khác. Nó không làm build dừng lại, và không có gì chuyển sang màu đỏ.

Nếu dependency đó thiếu hẳn thì build đã đứng lại, và mình biết trong vòng một phút. Vì nó có mặt và hỏng, hệ thống chạy tiếp, rỗng đúng một phần bên trong.

Lúc xếp việc mình gộp "thiếu" với "hỏng" vào cùng một dòng. Cái thiếu thì kêu. Cái hỏng thì chạy tiếp và im.

Chi tiết khó chịu là bước build đó vẫn báo thành công. Ô tìm kiếm sau đó vẫn mở lên được, chỉ là không tìm ra thứ đáng lẽ phải có trong đó.

Lỗi bốn: nhận lời khai làm bằng chứng

Máy viết ra dòng "đã kiểm tra xong, tất cả xanh". Mình đọc dòng đó rồi đi làm việc khác.

Câu đó là bản tóm tắt ý định của nó, không phải kết quả. Bắt nó báo cáo kỹ hơn chỉ đẻ ra một lời khai dài hơn, và dài hơn thì đọc lâu hơn mà vẫn không kiểm được gì.

Đây là quyền mình đã giao rồi rút lại, và mình rút muộn. Nó đứng được khá lâu trước khi mình để ý tới.

Luật bây giờ ngắn. Bên làm việc không được đồng thời là bên xác nhận việc đã xong. Cách mình viết yêu cầu bằng chứng vào chính câu lệnh nằm ở bài giao việc cho AI agent.

Bốn lỗi này lộ ra lúc nào

Không cái nào tự báo. Cả bốn đều lộ ra vào lúc mình đang đi soi một thứ khác.

  • Lỗi một: mất một năm mình mới nhìn ra, vì nó không hỏng, nó chỉ nhạt.
  • Lỗi hai: nhiều tuần, và mình không nhớ chính xác được bao nhiêu.
  • Lỗi ba: nhanh hơn hẳn, vì bước build vẫn kêu một tiếng, dù tiếng đó nhỏ.
  • Lỗi bốn: mình không ghi lại nó đứng được bao lâu, và đó là phần khó chịu nhất.

Ba trong bốn dòng trên không có con số. Đó chính là dấu hiệu của việc mình xếp nhầm nhóm ngay từ đầu.

Phép thử hai vế mình dùng bây giờ

Trước khi bật thứ gì lên, mình điền một câu. Máy làm sai thì ai phát hiện, và sau bao lâu.

Hai vế phải điền được bằng một cái tên và một khoảng thời gian. "Chắc có ai đó thấy" không tính là điền.

Áp câu này lên bốn lỗi trên thì cả bốn lộ ra ngay:

  1. Chọn góc nhìn cho bài: không có ai, và không có mốc thời gian nào.
  2. Background job: người phát hiện là mình, sau nhiều tuần.
  3. Dependency cài hỏng: lỗi có in ra mà không ai đọc, nên vế thời gian bỏ trống.
  4. Lời khai của máy: bên phát hiện chính là bên gây ra, tức là không có ai.

Việc nào bỏ trống một vế thì nguy hiểm, kể cả khi nó nghe dễ tới đâu. Thứ tự giao việc dựa trên câu này mình để ở bài nên tự động hoá việc gì trước.

Việc dễ hay bị xếp nhầm thành việc kiểm được

Đây là cái bẫy chung của cả bốn lỗi trên. Việc nào làm nhanh thì mình mặc định là việc soi được.

Hai thứ đó khác nhau. Đặt lịch cho một job là việc làm một lần, mà quên đặt thì nhiều tuần sau mới có người biết.

Nên cột để xếp không phải "việc này khó hay dễ". Cột để xếp là "sai thì tín hiệu đi tới ai, mất bao lâu để tới".

Dấu vết phải mất đi khi việc không chạy

Luật mình áp bây giờ chỉ có một dòng. Mỗi việc giao cho máy phải để lại một dấu vết mà nếu việc không chạy thì dấu vết đó không tồn tại.

Một dòng log không đạt. Một job đã chết vẫn để lại file log trông hoàn toàn bình thường, và đó đúng là chuyện đã xảy ra với mình.

Đạt thì là một tấm ảnh màn hình mới chụp, hoặc một dòng kết quả kèm exit code thật mà mình đọc bằng mắt. Công cụ mình dùng để ra lệnh cho agent là Claude Code. Mình kể riêng ở bài Claude Code là gì, tài liệu gốc nằm ở trang hướng dẫn của Anthropic.

Cách phân biệt rất thô. Bạn xoá dấu vết đó đi rồi bắt việc chạy lại, nếu dấu vết mọc lại thì nó đạt.

Chỗ mình chưa chắc

Mình xếp "cài hỏng" vào loại nguy hiểm nhất trong bốn lỗi trên. Mình chưa chắc cách xếp đó đúng cho mọi trường hợp.

Xếp cao hơn thì tốn thêm một lớp kiểm cho thứ có khi không cần tới. Xếp thấp hơn thì có ngày một bước build chạy rỗng mà không ai biết. Trong hai cái sai đó mình chọn cái rẻ hơn.

Ai không nên làm theo

Người làm một mình và chưa kiểm chứng được thứ gì thì đừng bắt đầu ở đây. Máy không sửa được một quy trình hỏng.

Nó nhân bản quy trình đó lên, nhanh hơn và im hơn. Đó là lý do sai lầm khi tự động hoá bằng AI thường đắt hơn việc chưa tự động hoá gì.

Thứ tự mình khuyên: làm tay cho tới khi bạn biết kết quả đúng trông ra sao. Rồi mới xếp nhóm, rồi mới giao đi từng dòng một.

Việc nên làm trong mười phút tới

Mở danh sách việc tự động của bạn ra rồi chọn một dòng. Trả lời hai vế: sai thì ai phát hiện, và sau bao lâu.

Điền không nổi một vế thì kéo dòng đó về tay bạn thêm một thời gian. Mấy ghi chép cùng mạch mình để ở chủ đề Tự động hoá.

Bốn lỗi trên mình không tự nhìn ra được cái nào. Cả bốn đều hiện ra lúc mình đi soi chuyện khác, và đó là phần mình chưa biết cách rút ngắn.

Bài này thế nào?

Chia sẻ

XFacebook

Ảnh đại diện của chủ trang quanbi.dev

Về mình

Quân Bi · Người viết

Xem thêm →

Bình luận (0)

Chưa có bình luận nào. Bạn mở hàng nhé.

Viết bình luận