Một trong những lý do phổ biến nhất khiến mã AI gợi ý không chạy là nó viết cho một phiên bản thư viện khác với bản bạn đang dùng. Mô hình học từ mã viết qua nhiều năm, nhiều phiên bản trộn lẫn, và có điểm cắt kiến thức. Thư viện ra bản mới sau thời điểm đó thì nó không biết, còn thư viện đã đổi cách dùng thì nó có thể nhớ lẫn cả bản cũ lẫn bản mới.
Bài này giúp bạn nhận ra lỗi do phiên bản, xác định đúng bản đang chạy, đọc tệp khoá phiên bản và ghi chú thay đổi của thư viện, xử lý xung đột khi hai thư viện đòi hai bản khác nhau, và đưa thông tin phiên bản cho AI để câu trả lời khớp với dự án của bạn.
Dấu hiệu nhận ra lỗi do phiên bản
Có vài kiểu lỗi gần như luôn liên quan tới phiên bản. Thông báo kiểu thuộc tính hay phương thức không tồn tại trên một đối tượng của thư viện, trong khi tài liệu trên mạng vẫn dùng đúng tên đó. Tham số được báo là không hợp lệ hoặc bị thừa. Cảnh báo về cách dùng đã bị bỏ, thường in ra trước khi lỗi thật xảy ra ở bản sau. Mã chạy được trên máy đồng nghiệp nhưng không chạy trên máy bạn dù cùng một commit.
Khi dùng AI, có thêm một dấu hiệu riêng: AI đưa ra cách gọi hàm mà bạn tìm trong tài liệu chính thức của bản hiện hành không thấy, hoặc thấy ghi rõ là đã bị bỏ. Đây không hẳn là AI bịa từ hư không. Nhiều khi đó là cách dùng đúng của một bản cũ, hoặc của một thư viện khác cùng mục đích. Kết quả với bạn thì như nhau: mã không chạy.
Ví dụ giả định: một nhóm ở Bắc Ninh nâng thư viện xử lý ngày giờ lên bản chính mới, nhờ AI sửa các chỗ báo lỗi. AI sửa theo cách dùng của bản trước nữa, vì đó là cách xuất hiện nhiều nhất trong dữ liệu nó học. Lỗi đổi chỗ chứ không hết. Chỉ khi dán đoạn ghi chú thay đổi của bản mới vào cuộc trò chuyện, câu trả lời mới khớp.
Xác định đúng phiên bản đang chạy
Trước khi hỏi bất cứ ai, biết chắc bản đang chạy là gì. Bản ghi trong tệp khai báo phụ thuộc chỉ là khoảng cho phép, bản cài thật có thể khác. Các lệnh dưới đây là lệnh chuẩn của từng công cụ.
- Python: pip show kèm tên gói cho biết bản đã cài; trong mã có thể dùng importlib.metadata.version kèm tên gói. Nhớ kiểm đúng môi trường ảo đang dùng, vì máy có thể có nhiều bản Python.
- Node.js: npm ls kèm tên gói cho biết bản đã cài và gói nào kéo nó vào, kể cả khi có nhiều bản cùng tồn tại trong cây phụ thuộc.
- PHP: composer show kèm tên gói cho biết bản đã cài cùng các phụ thuộc của nó.
- Phiên bản ngôn ngữ: python3 --version, node --version, php -v. Với web, kiểm bản mà máy chủ web dùng, có thể khác bản dòng lệnh.
- Tệp khoá phiên bản: package-lock.json, composer.lock, tệp khoá của công cụ quản lý gói Python. Đây là nơi ghi bản chính xác đã cài cho mọi gói, kể cả gói gián tiếp.
Khi hỏi AI, ghi phiên bản thành một dòng ở đầu câu hỏi, ví dụ “Python 3.12, thư viện X bản 2.3.1”. Thêm câu “nếu cách dùng khác giữa các bản, trả lời theo đúng bản này và nói rõ chỗ khác” sẽ giảm đáng kể số lần nhận về mã của bản cũ.
Đọc số phiên bản theo quy ước ba phần
Phần lớn thư viện phổ biến đánh số theo quy ước phiên bản ngữ nghĩa, gọi tắt là semver, gồm ba số chính, phụ, vá. Hiểu quy ước này giúp đoán trước nâng cấp nào an toàn, nâng cấp nào cần đọc kỹ.
| Thay đổi | Ví dụ | Ý nghĩa theo quy ước | Nên làm gì |
|---|---|---|---|
| Số vá | 2.3.1 lên 2.3.4 | Sửa lỗi, không đổi cách dùng | Thường nâng được ngay, vẫn chạy kiểm thử |
| Số phụ | 2.3 lên 2.5 | Thêm tính năng, giữ tương thích ngược | Đọc lướt ghi chú thay đổi, chạy kiểm thử |
| Số chính | 2.x lên 3.0 | Có thay đổi phá vỡ tương thích | Đọc hướng dẫn chuyển đổi, nâng trên nhánh riêng |
| Bản 0.x | 0.8 lên 0.9 | Chưa ổn định, số phụ cũng có thể phá vỡ | Đối xử như nâng số chính |
Quy ước là cam kết của người viết thư viện, không phải luật. Một số thư viện không theo, một số lỡ tay phá vỡ tương thích ở bản vá. Vì vậy, dù nâng bản nhỏ nào cũng nên có kiểm thử chạy lại.
Ký hiệu trong tệp khai báo cũng cần đọc đúng. Trong npm và Composer, dấu mũ trước số phiên bản cho phép nâng số phụ và số vá, dấu ngã khi ghi đủ ba số thường chỉ cho phép nâng số vá; quy tắc chi tiết khác nhau đôi chút giữa các công cụ nên đọc tài liệu của công cụ mình dùng. Đây là lý do hai người cài cùng một tệp khai báo vào hai thời điểm có thể ra hai bản khác nhau nếu không dùng tệp khoá.
Xung đột phụ thuộc: khi hai thư viện đòi hai bản khác nhau
Hiểu vì sao xung đột. Thư viện A cần thư viện C bản 1, thư viện B cần C bản 2. Một số hệ sinh thái như npm cho phép cài nhiều bản song song trong cây phụ thuộc, nên ít khi báo lỗi ngay nhưng có thể sinh lỗi lạ khi hai bản cùng chạy. Pip và Composer thường chỉ giữ một bản cho mỗi gói, nên báo xung đột ngay lúc cài.
Đọc thông báo xung đột trước khi hỏi. Trình quản lý gói thường nói rõ gói nào đòi bản nào. Dán nguyên thông báo đó cho AI kèm tệp khai báo phụ thuộc, hỏi nó vẽ lại cây ai cần ai bằng chữ trước khi đề xuất cách giải.
Ưu tiên nâng gói cũ hơn là ép bản. Cách giải bền vững thường là nâng thư viện A lên bản mới hơn đã hỗ trợ C bản 2. Ép buộc một bản bằng cờ bỏ qua kiểm tra phụ thuộc giải quyết được lúc cài nhưng để lại lỗi khi chạy.
Cẩn thận với gói AI gợi ý thêm vào. Khi gỡ xung đột, AI có thể gợi ý cài thêm một gói trung gian. Kiểm gói đó có thật, đúng tên, đang được duy trì, trên trang chính thức của kho gói trước khi cài. Kẻ xấu từng đăng gói trùng hoặc gần trùng tên với gói mà AI hay gợi ý nhầm.
Nâng cấp thư viện an toàn cùng AI
Nâng cấp là lúc lỗi phiên bản xuất hiện nhiều nhất. Quy trình dưới giúp bạn nâng từng bước, có đường lùi, và dùng AI ở đúng chỗ nó mạnh.
- Tạo nhánh git riêng cho việc nâng cấp, đảm bảo bộ kiểm thử đang qua hết trước khi bắt đầu.
- Đọc ghi chú thay đổi và hướng dẫn chuyển đổi chính thức của thư viện, đánh dấu các mục liên quan tới chỗ dự án đang dùng.
- Nâng một thư viện mỗi lần, nhất là với thay đổi số chính. Nâng nhiều thư viện một lúc thì lỗi sinh ra không biết của ai.
- Chạy kiểm thử, gom các lỗi lại. Dán cho AI cả lỗi lẫn đoạn hướng dẫn chuyển đổi liên quan, yêu cầu nó sửa theo đúng hướng dẫn đó.
- Tìm toàn dự án những chỗ dùng hàm đã đổi, vì kiểm thử có thể không phủ hết. AI giúp liệt kê các mẫu cần tìm.
- Chạy thử ứng dụng bằng tay ở các luồng chính, rồi mới gộp nhánh.
Bước thứ tư là nơi AI tiết kiệm nhiều công nhất: sửa hàng chục chỗ theo cùng một quy tắc chuyển đổi là việc lặp lại mà nó làm nhanh và khá đều tay. Điều kiện là bạn đưa cho nó đúng quy tắc từ tài liệu chính thức, thay vì để nó tự nhớ.
Chặn lỗi phiên bản ngay khi nhờ AI viết mã mới
Phần lớn lỗi phiên bản không sinh ra lúc nâng cấp mà sinh ra lúc viết tính năng mới: bạn nhờ AI viết một đoạn gọi thư viện, nó viết theo cách dùng nó quen, đoạn đó lọt vào dự án và chỉ hỏng khi chạy tới nhánh ít dùng. Chặn từ đầu rẻ hơn gỡ về sau nhiều.
Trước khi nhờ viết, đưa cho AI phiên bản của thư viện sẽ dùng và, nếu được, một đoạn mã sẵn có trong dự án đang gọi đúng thư viện đó. Mô hình bắt chước rất tốt cách viết có sẵn trước mặt, nên một ví dụ thật từ dự án thường hiệu quả hơn mọi lời dặn. Với thư viện ra đời hoặc đổi lớn gần đây, dán thêm đoạn tài liệu chính thức của hàm cần dùng.
Sau khi nhận mã, kiểm nhanh từng lời gọi tới thư viện bên ngoài: tên hàm, tên tham số, kiểu giá trị trả về có khớp tài liệu của đúng bản đó không. Trình soạn thảo có gợi ý kiểu và kiểm tra tĩnh sẽ gạch chân phần lớn chỗ sai ngay khi dán vào, nên bật các công cụ đó trong dự án là một hàng rào miễn phí.
Giữ phiên bản ổn định để bớt lỗi về sau
Luôn commit tệp khoá phiên bản vào kho mã của ứng dụng. Khi triển khai, cài theo tệp khoá thay vì theo tệp khai báo, ví dụ npm ci thay vì npm install. Như vậy máy chủ, máy đồng nghiệp và máy bạn chạy đúng cùng một bộ thư viện, và lỗi kiểu chạy trên máy này không chạy trên máy kia giảm hẳn.
Đặt lịch nâng cấp định kỳ thay vì để thư viện cũ đi vài năm rồi nâng một lúc. Nâng nhỏ và thường xuyên thì mỗi lần ít thay đổi, dễ gỡ. Nhiều kho mã có công cụ tự mở yêu cầu nâng phiên bản khi có bản mới, kèm ghi chú thay đổi, giúp nhóm nhỏ không phải tự theo dõi.
Cuối cùng, ghi phiên bản các thư viện chính vào tệp hướng dẫn dự án mà trợ lý AI đọc ở đầu phiên làm việc. Một dòng ngắn như “dự án dùng khung X bản 4, không dùng cách viết của bản 3” giúp tránh được cả loạt gợi ý sai mà không cần nhắc lại mỗi lần hỏi.
Câu hỏi thường gặp
Vì sao AI gợi ý hàm mà thư viện không có?
Thường vì nó nhớ cách dùng của một bản cũ hơn, một bản mới chưa phát hành lúc nó học, hoặc của một thư viện khác cùng mục đích. Ghi rõ phiên bản trong câu hỏi và đối chiếu với tài liệu chính thức của đúng bản đó trước khi dùng.
Có nên luôn dùng bản mới nhất của thư viện không?
Không nhất thiết. Bản mới có sửa lỗi và vá bảo mật, nhưng cũng có thể có thay đổi phá vỡ tương thích. Nên giữ phiên bản ổn định bằng tệp khoá và nâng cấp có kế hoạch, ưu tiên nâng sớm các bản vá bảo mật.
Tệp khoá phiên bản có cần đưa vào git không?
Với ứng dụng thì nên đưa vào, để mọi người và máy chủ cài đúng cùng bộ thư viện. Với thư viện viết để người khác dùng lại, cách làm tuỳ hệ sinh thái và quy ước của nhóm, nên đọc hướng dẫn của công cụ quản lý gói.
Có nên dùng cờ ép cài để vượt qua xung đột phụ thuộc không?
Chỉ nên dùng tạm thời khi hiểu rõ hậu quả. Cờ ép cài bỏ qua kiểm tra, nên lỗi có thể xuất hiện lúc chạy thay vì lúc cài, khó gỡ hơn. Cách bền vững là nâng thư viện gây xung đột lên bản tương thích.
Làm sao biết một gói AI gợi ý có thật và đáng tin?
Tìm gói trên trang chính thức của kho gói, kiểm tên viết đúng từng ký tự, số lượt tải, ngày cập nhật gần nhất, kho mã nguồn và người duy trì. Gói mới tạo, ít người dùng, tên gần giống gói nổi tiếng là dấu hiệu đáng ngờ.
Nâng phiên bản ngôn ngữ, ví dụ PHP hay Python, có khác nâng thư viện không?
Nguyên tắc giống nhau nhưng phạm vi rộng hơn, vì mọi thư viện đều phải tương thích với bản ngôn ngữ mới. Kiểm từng thư viện chính đã hỗ trợ bản mới chưa, chạy kiểm thử trên bản mới trong môi trường riêng, rồi mới đổi trên máy chủ.