Phần lớn người mới dùng AI vẫn ở giai đoạn "hỏi đáp": hỏi một câu, nhận một câu trả lời, xong. Cách này ổn khi bạn chỉ cần tra thông tin. Nhưng khi bắt đầu giao việc cho AI (viết một đoạn văn hoàn chỉnh, xử lý một file dữ liệu, xây một tính năng), cách nghĩ "hỏi đáp" không còn đủ. Giao việc cần ngữ cảnh, cần ràng buộc, và cần bạn tham gia kiểm soát suốt quá trình, không phải hỏi xong rồi ngồi chờ kết quả.
Bài này viết về 3 nguyên tắc tôi rút ra sau nhiều lần vấp: đặt task (việc bạn giao cho AI làm) rõ ràng, chia nhỏ việc, và biết khi nào cần tự kiểm tra thay vì tin tuyệt đối. Ba nguyên tắc này sẽ lặp lại xuyên suốt series.
Lúc mới tiếp xúc với prompt (câu lệnh/yêu cầu bạn gõ cho AI), tôi thấy khá khó hiểu. Có nhiều trang cung cấp prompt mẫu, có cả bản thương mại, nhưng lúc đó tôi thấy không hợp với mình. Tôi từng ngồi viết hẳn một quy trình xây prompt hiệu quả, rồi cũng quên nó đi. Sau này làm việc nhiều hơn với AI, tôi tự biết viết prompt phù hợp với mình từ lúc nào không hay. Nói vậy để bạn yên tâm: không cần thuộc lòng công thức nào trước, cứ thực hành dần theo mấy nguyên tắc dưới đây, cách viết phù hợp với bạn sẽ tự hình thành.
Đặt task rõ ràng, có tiêu chí "xong"
Một task rõ ràng thường có đủ 4 phần: bối cảnh (đang làm gì, cho ai), ràng buộc (giới hạn về độ dài, định dạng, những thứ không được đụng tới), mục tiêu cuối cùng, và tiêu chí để biết khi nào coi là xong. Phần hay bị bỏ quên nhất là tiêu chí "xong". Thiếu nó, cả bạn lẫn AI cứ sửa qua sửa lại không có điểm dừng, vì không ai biết thế nào là đủ.
Ví dụ của tôi là ứng dụng nhỏ tên "Sổ tay checklist". Ý tưởng xuất phát từ một chuyến du lịch: dù chuẩn bị khá kỹ, lên đường rồi mới nhận ra vẫn quên vài thứ đồ. Về nhà, tôi làm một ứng dụng hiển thị danh mục cần chuẩn bị cho từng loại chuyến đi, chỉ cần bấm chọn là biết đã chuẩn bị gì, còn thiếu gì. Xong bản đó, tôi lại thấy đơn giản quá, đã gọi là sổ tay thì phải làm được nhiều hơn. Thế là tôi thêm module theo dõi sức khoẻ (tính BMI, lịch sử khám chữa bệnh, tiêm vắc xin...), rồi thêm lịch học và học phí cho từng con. Tới lúc cần refactor, ứng dụng đã hơn 8.000 dòng code, và chính AI cũng nói việc refactor lúc này rủi ro hơn lợi ích vì code đã quá nhiều, không được bố trí khoa học.
Đây chính là hậu quả của việc không có tiêu chí "xong" ngay từ đầu. Mỗi lần thấy ứng dụng còn đơn giản, tôi lại thêm một chức năng mới, không có điểm dừng nào được đặt ra trước, và không ai, kể cả tôi, biết khi nào ứng dụng mới thực sự là đủ.
Nguyên tắc chung tôi rút ra: dành thêm vài phút suy nghĩ thấu đáo về task trước khi giao, kể cả xác định trước phạm vi dừng lại ở đâu, dù có vẻ chậm hơn, vẫn đáng hơn nhiều so với việc cứ giao vội, thêm dần theo cảm hứng, để rồi một ngày nhìn lại mới thấy sản phẩm đã phình to ngoài kiểm soát.
💡 Mẹo hay: Nếu thấy cách người khác đã làm, một ứng dụng, một văn bản, hay cả cách trình bày một bài đăng, là đủ tốt, cứ nói thẳng với AI kiểu "làm theo cách app A đã làm" hoặc "viết theo phong cách như B". Đỡ phải mô tả lại từ đầu. Đây chỉ là tham khảo, phần cốt lõi vẫn nên là ý của bạn.
Chia nhỏ việc, xác nhận từng bước trước khi đi tiếp
Giao một việc lớn trong một lần rất dễ khiến AI lạc hướng giữa chừng: sai một chỗ ở bước đầu, kéo theo sai cả chuỗi phía sau, mà bạn chỉ phát hiện khi nhìn kết quả cuối cùng. Sửa lại lúc đó thường tốn công hơn nhiều so với chia nhỏ ngay từ đầu.
Cách tôi làm bây giờ: chia task lớn thành từng bước nhỏ, mỗi bước xong thì xác nhận trước khi giao bước tiếp. Ví dụ là app "Bài tập về nhà" tôi làm để chuyển giao bài tập từ giáo viên và bố mẹ cho các con, không bị trôi tin như gửi qua ứng dụng chat, kèm thêm thời khoá biểu, thông báo. Thay vì giao nguyên một yêu cầu lớn, tôi chia thành 6 giai đoạn nhỏ, mỗi giai đoạn xác nhận hoạt động tốt rồi mới làm tiếp: nền tảng (đăng nhập, phân quyền), tính năng cốt lõi (giao bài, cập nhật trạng thái), giao tiếp (chat, bình luận), thống kê và lịch, thông báo khi có bài mới, rồi mới tới các tiện ích bổ sung.
Mỗi giai đoạn ở trên thực ra còn được chia nhỏ hơn nữa. Riêng phần thông báo đã mất nhiều vòng chỉnh sửa vì iOS có giới hạn riêng khác Android. Nếu gộp chung mọi thứ từ đầu, một lỗi nhỏ ở phần thông báo có thể ảnh hưởng lan sang cả luồng đăng nhập hoặc dữ liệu bài tập. Chia nhỏ và xác nhận từng bước giúp lỗi nằm gọn trong phạm vi của nó, sửa ở đâu biết chắc chỉ ảnh hưởng ở đó.
Có một chỗ tôi (và chắc nhiều người khác) hay bị trượt lại đúng kiểu "hỏi đáp" đã nói ở đầu bài: trong lúc sửa, dù đã có instruction (bộ hướng dẫn cố định cho AI, tôi sẽ nói kỹ ở bài 3) làm khung sườn chính, thực tế vẫn phát sinh rất nhiều vấn đề nhỏ lẻ ngoài dự tính. Lúc đó rất dễ quay về thói quen chat qua lại, gửi ảnh chụp màn hình, hỏi một câu chờ một câu trả lời. Cách này vừa rời rạc vừa tốn token (đơn vị AI dùng để tính lượng chữ xử lý, cũng là cơ sở tính phí), vì mỗi lượt chat đều phải kèm lại ngữ cảnh từ đầu.
Cách tôi tránh việc đó: mở sẵn một trình soạn thảo văn bản, liệt kê hết những vấn đề còn tồn đọng và những thứ muốn cải tiến theo kiểu gạch đầu dòng (dùng Alt + Enter để xuống dòng trong khung chat Claude mà không gửi tin nhắn, hoặc viết ở trình soạn thảo ngoài rồi copy từng phần vào cho AI xử lý). Điều đó giúp việc sửa có hệ thống hơn, và AI cũng xử lý hiệu quả hơn nhiều so với nhận từng mẩu thông tin rời rạc.
Nói rộng ra, đặt task rõ ràng và chia nhỏ việc luôn đi kèm lợi ích tiết kiệm token, không chỉ lúc sửa lỗi. Với bản trả phí, việc này ảnh hưởng trực tiếp tới chi phí. Với bản Free, nó giúp bạn làm được nhiều việc hơn trước khi chạm giới hạn sử dụng.
💡 Fun fact: Claude tính giới hạn sử dụng theo phiên, tự reset sau mỗi 5 tiếng kể từ tin nhắn đầu tiên (nhiều công cụ AI khác cũng vậy). Nhiều người không biết nên cứ nghĩ dùng hết là hết luôn trong ngày. Một điều nữa tôi để ý (chưa chắc đúng với mọi người, mọi thời điểm): dùng bản Free vào buổi sáng tới chiều theo giờ Việt Nam có vẻ được dùng lâu hơn hẳn buổi tối, có thể do khung giờ đó ít người dùng cùng lúc hơn.
Biết khi nào tự kiểm tra thay vì tin tuyệt đối
AI có thể sai, và nhiều khi sai rất tự tin. Nhưng không phải lúc nào cũng cần soát kỹ như nhau, việc đó tốn thời gian và mất luôn cái lợi của việc dùng AI. Tôi chia làm 3 nhóm hay cần lưu ý:
Số liệu, trích dẫn, tên riêng: luôn tự kiểm tra lại. Đây là nhóm dễ bị bịa nhất mà lại dễ qua mắt nhất, vì câu trả lời đọc rất tự nhiên. Tôi từng nhờ AI tìm thông tin từ vài nguồn trên mạng, có trang nó không truy cập được. Thay vì báo lại là không lấy được, nó suy đoán dựa trên dữ kiện liên quan khác, nghe hợp lý, nhưng khi tôi kiểm tra lại thì sai. Không có thói quen đối chiếu nguồn, rất dễ tin luôn kết quả suy đoán đó là sự thật.
Thông tin chuyên môn hẹp: đối chiếu cách làm thực tế của ngành. Cái nguy hiểm ở nhóm này không phải AI đưa số sai, mà là AI có thể đúng logic toán nhưng sai quy ước thực tế của ngành, nhìn qua vẫn thấy hợp lý. Tôi từng để AI hỗ trợ tính thời gian làm hàng (laytime: khoảng thời gian tàu được phép xếp/dỡ hàng theo hợp đồng). Cách AI tính không sai về số học, nhưng không theo đúng quy ước riêng của ngành tôi vẫn dùng hàng ngày. Nhóm này chỉ người có chuyên môn mới bắt lỗi được, AI tự nó không biết là mình đang sai.
Logic quan trọng: kiểm tra cẩn thận, không chỉ thấy chạy được là tin. Việc ảnh hưởng trực tiếp tới quyết định thật thì nên tự kiểm tra lại cách AI xử lý, không chỉ dừng ở "chạy thử ra kết quả đúng là được". Với ứng dụng, cần thời gian thử nghiệm thực tế, thử nhiều kiểu dữ liệu đầu vào mới yên tâm. Có lỗi trong app trò chơi tôi làm, phải chơi đi chơi lại nhiều lần mới lộ ra. Chỗ này bài 7 sẽ nói kỹ hơn, nhưng nêu trước một nguyên tắc nhỏ: trước khi nhận một bản sửa lỗi, nên hỏi AI nguyên nhân gốc, thay vì nhận patch (bản vá) ngay. Nhiều lần bản vá chỉ che triệu chứng bên ngoài, lỗi gốc vẫn còn đó.
Vài sai lầm thường gặp
- Prompt mơ hồ, thiếu bối cảnh và tiêu chí xong, khiến AI phải đoán mò thay mình.
- Giao nguyên một việc lớn trong một lần, đến lúc sai thì không biết sai từ đâu.
- Tin tuyệt đối vào kết quả, đặc biệt với số liệu và thông tin chuyên môn hẹp, mà không dành vài phút đối chiếu lại.
Nguyên tắc nền cho cả series
Ba nguyên tắc trên sẽ quay lại nhiều lần trong các bài sau. Bài 3 nói về cách biến "đặt task rõ ràng" thành một bộ hướng dẫn cố định. Bài 4 đi sâu hơn vào nguyên tắc "tự kiểm tra" trong công việc chuyên môn cụ thể.