AI có kiến thức tổng quát rất rộng, nhưng với nghiệp vụ hẹp và đặc thù (loại mà nhiều khi ngay người trong ngành cũng chưa chắc hiểu biết tường tận, phải người trực tiếp làm mới rõ) thì AI không có sẵn, và cái đáng nói hơn là AI cũng không tự biết mình đang thiếu. Nó vẫn trả lời rất tự tin, chỉ là trả lời theo logic chung, chứ không phải theo cách ngành của bạn vẫn làm.
Tôi kể lại hành trình xây một công cụ 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 tại cảng theo hợp đồng) cho công việc khai thác tàu của mình. Ý tưởng ban đầu tưởng rất đơn giản: upload (tải lên) Statement of Fact/Time Sheet (SOF - bảng liệt kê thời gian thực tế làm hàng tại cảng do đại lý cảng lập), thêm vài dữ kiện về khối lượng hàng, điều kiện xếp dỡ, mốc bắt đầu tính giờ, là ra ngay kết quả. Bắt tay vào làm rồi mới thấy không đơn giản như nghĩ, và mỗi chỗ vấp là một bài học tôi nghĩ áp dụng được cho bất kỳ ai đang định dùng AI để tự động hoá một việc chuyên môn của mình, không riêng gì ngành hàng hải.
Cần nói rõ một điều trước khi đi tiếp: ví dụ xây ứng dụng dưới đây là ngách khá hẹp, không phải ai học và dùng AI tốt cũng cần, hay có thể, tự xây một ứng dụng. Nguyên tắc "dạy AI kiến thức chuyên môn" áp dụng được cho bất kỳ việc chuyên môn nào, kể cả việc không đụng gì tới code, như ví dụ soạn thảo văn bản tôi sẽ kể ngay sau đây.
Ví dụ soạn SOP cho công ty
Ngoài việc xây ứng dụng, một cách khác tôi thấy rất hiệu quả để dùng AI cho công việc chuyên môn là soạn thảo văn bản: quy trình nội bộ, báo cáo phân tích, hợp đồng mẫu... Ví dụ của tôi là xây bộ SOP (Standard Operating Procedure, quy trình vận hành chuẩn) cho công ty.
Cách tôi làm: lên khung trước (các phần, mục lớn cần có trong bộ SOP), đưa vào dữ liệu đầu vào là kiến thức thực tế của tôi, những trường hợp đã từng xảy ra và có thể xảy ra trong lĩnh vực, những gì cần chuẩn hoá thành quy định. AI làm theo khung đã định, đi từng phần một, tôi duyệt xong phần nào mới chuyển sang phần tiếp theo, đúng nguyên tắc "chia nhỏ việc, xác nhận từng bước" đã nói ở bài 2. Văn bản đầu ra có định dạng chuẩn hoá, nhưng nội dung cốt lõi hoàn toàn là kiến thức và kinh nghiệm thật của tôi, AI chỉ giúp đẩy nhanh việc soạn thảo.
Với một bộ SOP vài chục trang, nếu làm theo cách cũ, ngồi gõ rồi chỉnh sửa dần, sẽ mất rất nhiều thời gian mới ra được bản hoàn thiện. Nhờ AI hỗ trợ, kết hợp tinh chỉnh instruction (bài 3) với kinh nghiệm thực tiễn của mình, tôi hoàn thiện một bản SOP chuyên nghiệp trong khoảng một ngày.
💡 Mẹo hay: Từ bài 1 tôi đã nói tôi dùng Claude vì phù hợp với mình, nhưng nếu bạn đang dùng AI khác, nguyên tắc tương tự vẫn áp dụng được. Nhiều AI hiện có tính năng kiểu "cowork": một trợ lý làm việc nhiều bước, tự thực thi cả một chuỗi công việc dài hơi thay vì chỉ trả lời từng câu một, trên Claude gọi là Cowork. Đây là công cụ rất hữu ích cho công việc chuyên môn một khi bạn đã quen prompt và instruction, không khó để bắt đầu. Lưu ý: Cowork hiện chỉ có ở các gói trả phí (Pro trở lên), và vì nó thường cần truy cập nhiều dữ liệu, file hơn, càng nên cẩn thận không đưa thông tin quan trọng, nhạy cảm vào cho AI xử lý.
Giải một trường hợp cụ thể khác với giải mọi trường hợp
Làm một việc bằng tay, hay bằng Excel, chỉ cần đúng cho tình huống trước mắt. Nhưng để AI/app tự động hoá cho mọi trường hợp, bạn phải liệt kê hết những biến thể và ngoại lệ mà bình thường mình xử lý theo bản năng, thậm chí không để ý là mình đang phải xử lý một ngoại lệ.
Với việc tính laytime, bình thường tôi làm trên Excel, công thức khá đơn giản vì chỉ cần đúng cho hợp đồng cụ thể trước mắt. Nhưng khi làm một ứng dụng dùng chung, tôi phải bao quát mọi biến thể điều khoản. Nếu đúng theo mẫu hợp đồng chuẩn Gencon (một mẫu hợp đồng thuê tàu chuyến phổ biến trong ngành) thì khá dễ, nhưng thực tế nhiều lúc bên thuê tàu sửa đổi điều khoản khác đi để có lợi cho họ khi đàm phán, và chủ tàu phải chấp nhận vì lý do nào đó. Lúc đó logic tính toán phải bao trùm rộng hơn nhiều so với một công thức Excel chỉ cần đúng cho một hợp đồng.
Đầu vào xấu thì đầu ra không thể tốt
AI giỏi tới đâu cũng không cứu được dữ liệu đầu vào lộn xộn. Đây là giới hạn tất yếu, không phải lỗi của AI.
Với công cụ tính laytime, SOF/Time Sheet mỗi đại lý ở cảng khác nhau lại có một mẫu khác nhau, đôi khi bản scan còn mờ, dữ liệu hiển thị lộn xộn, AI trích xuất sai là chuyện bình thường. Không chỉ chuyện chất lượng bản scan, đôi khi ngôn ngữ dùng trong SOF cũng không thật chính xác hay rõ ràng, có thể khiến AI hiểu sai ngữ cảnh, dẫn tới kết quả sai dù bản scan hoàn toàn nét. Đầu vào đã lỗi thì đầu ra không thể có chất lượng, dù lỗi đó đến từ hình ảnh hay từ chính câu chữ.
Giao diện ứng dụng tính laytime
Một ví dụ khác rõ hơn nữa là một công cụ khác tôi từng làm, tên gọi là Owner Assistant (owner trong ngành hàng hải nghĩa là chủ tàu) mục đích là để kiểm tra hợp đồng thuê tàu, phân tích theo từng bước định sẵn, dùng để đối chiếu nhiều loại chứng từ với nhau trong một chuyến: vài chục vận đơn cần so sánh với biên lai thuyền phó, rồi so với thư bảo lãnh; chứng từ cảng phí cần đối chiếu với những gì đã thanh toán, lưu ý khi lập hoá đơn, và một vài tính năng bổ trợ khác.... Nghiệp vụ ở đây phức tạp hơn hẳn laytime, nhưng cái khó nhất hoá ra lại không phải nghiệp vụ, mà vẫn là chất lượng bản scan đầu vào. Bản scan mờ là ứng dụng gần như chào thua, mà không phải lúc nào cũng có thể yêu cầu bên liên quan scan lại. Đây là điểm khác so với ví dụ laytime: đôi khi vấn đề đầu vào không phải lỗi kỹ thuật có thể khắc phục bằng code tốt hơn, mà là một giới hạn thực tế nằm ngoài tầm tay của bạn.
Giao diện ứng dụng Owner Assistant
Ngành nào cũng có quy ước riêng mà AI mặc định không biết
Mỗi lĩnh vực có những giá trị hay quy ước đặc biệt mà cách suy luận "mặc định" của AI không lường tới, phải tự nêu ra thì AI mới tránh được, vì với AI, cách xử lý mặc định luôn có vẻ hợp lý về mặt logic chung.
💡 Mẹo hay: Một lỗi tôi từng gặp khi làm công cụ laytime: AI viết một đoạn code kiểu "nếu không có giá trị thì mặc định là rỗng" (
parseFloat(...) || null). Nghe hợp lý, nhưng trong nghiệp vụ của tôi, số 0 lại là một giá trị hợp lệ (ví dụ 0 giờ trì hoãn khi làm hàng). Đoạn logic đó vô tình biến "0 giờ" thành "không có dữ liệu", một lỗi âm thầm, chạy vẫn ra kết quả, chỉ sai một cách khó nhận ra nếu không rành nghiệp vụ. Nguyên tắc rút ra: bất kỳ chỗ nào số 0 là một giá trị hợp lệ trong ngành của bạn, phải nói rõ với AI, vì mặc định lập trình chung thường coi 0 tương đương với "không có gì".
Biết khi nào bán tự động là đủ
Vấn đề không chỉ nằm ở việc trích xuất dữ liệu đầu vào. Bản thân quá trình tính toán laytime cũng có rất nhiều tình huống phải xử lý, nhiều chỗ cần kết nối thông tin với nhau, nếu muốn ứng dụng chạy hoàn toàn tự động từ đầu đến cuối. Nhưng kết quả của quá trình này liên quan trực tiếp tới tiền, nên tôi không thực sự yên tâm để nó chạy tự động hoàn toàn mà không qua soát xét. Có lỗi xảy ra ở bước tính toán là có thiệt hại kinh tế thật, không chỉ là một con số sai vô hại.
Nối lại nguyên tắc "biết khi nào tự kiểm tra" ở bài 2: sau tất cả những vấp váp trên, tôi chọn hướng bán tự động cho công cụ laytime, thay vì cố làm tự động hoàn toàn. Tôi dùng AI để trích xuất dữ liệu thô từ file ảnh, PDF, rồi copy dữ liệu đó vào ứng dụng (hoàn toàn miễn phí), thay vì thêm module trích xuất dữ liệu vào ứng dụng (tôi tạo sẵn một prompt trong ứng dụng cho việc này, mỗi lần cần trích xuất chỉ việc copy prompt đó cùng file dữ liệu đưa vào cửa sổ chat).
Việc này giúp tôi không phải gõ tay ngày giờ, nội dung từng dòng, và độ chính xác khá tốt tính tới giờ. Nhưng tôi vẫn duyệt thủ công từng dòng dữ liệu trước khi tính toán, thiết kế nút chấp nhận hoặc bỏ qua cho từng dòng, chỉ việc bấm chọn. Đây đúng là ví dụ thực tế nhất tôi có cho nguyên tắc "việc nào ảnh hưởng tới quyết định thật thì nên tự kiểm tra" đã nói ở bài 2.
Cách bán tự động này phù hợp với laytime vì đây là công cụ dùng cho một nghiệp vụ, mở ra dùng khi cần. Với Owner Assistant thì khác: công cụ này gom nhiều nghiệp vụ vào một ứng dụng, nếu bắt người dùng mở cửa sổ chat và copy dán một prompt riêng cho từng nghiệp vụ sẽ mất hết ý nghĩa tích hợp, nên tôi vẫn phải dùng API trả phí (API là giao diện lập trình cho phép phần mềm gọi thẳng tới dịch vụ AI; ở đây tôi dùng qua OpenRouter, một dịch vụ trung gian cho phép gọi nhiều model AI khác nhau qua một API duy nhất) để mọi thứ chạy liền mạch trong ứng dụng. Nói cách khác, chọn cách nào không phải vì cách đó luôn tốt hơn, mà vì nó phù hợp với quy mô và cách dùng của từng công cụ.
Thành thật với chính mình: không phải lúc nào cũng cần tự động hoá
💡 Góc nhìn cá nhân: Nếu không phải vì yêu công nghệ, giữ nguyên bảng tính Excel cho việc tính laytime cũng chẳng có vấn đề gì. Ứng dụng tôi làm có thêm giá trị nhỏ, dùng được cả trên iPad, thứ hơi khó thao tác với Excel nếu không có bàn phím rời, nhưng không phải lúc nào công sức bỏ ra tự động hoá cũng đáng, nhất là khi việc thủ công vốn đã không tốn quá nhiều thời gian.
Đây cũng là câu hỏi tôi nghĩ đáng đặt ra trước khi bắt tay vào bất kỳ dự án tự động hoá nào: việc thủ công hiện tại có thực sự phiền tới mức đáng bỏ công xây một công cụ mới không, hay chỉ vì thấy nó có vẻ chuyên nghiệp hơn nên làm.
Tổng hợp lại
Cung cấp kiến thức chuyên ngành cho AI (hay "feed domain knowledge" theo cách nhiều người hay gọi), với tôi, gói gọn trong 4 việc: định nghĩa rõ thuật ngữ và quy tắc tính toán của ngành, nêu rõ những ngoại lệ ngoài mẫu chuẩn mà thực tế vẫn xảy ra, cảnh báo trước những giá trị đặc biệt (như số 0) mà AI hay mặc định hiểu sai, và giữ một bước duyệt thủ công cho việc nào ảnh hưởng tới quyết định thật.
Bài tiếp theo tôi sẽ nói về việc đi từ ý tưởng tới sản phẩm, nguyên tắc làm việc khoa học khi biến một ý tưởng thành thứ dùng được, không chỉ dừng ở mức thử nghiệm.