Tác giả: Học Trò và Claude Sonnet 5.0 AI (Tháng 8 năm 2026).
Học Trò xin chân thành cảm ơn nhà báo Phạm Phú Minh (https://phamxuandai.blogspot.com/), Nhật Báo Người Việt tại Little Saigon, và các thiện nguyện viên phụ trách việc số hóa Tạp Chí Bách Khoa (1957-1975), để hậu thế có thể được xem lại những áng văn chương, nghệ thuật của Việt Nam Cộng Hòa trước ngày mất nước. Cũng xin thành thực cám ơn Nhóm Thực Hiện việc số hóa Tạp Chí Văn Học các bộ Cũ và Mới: Diệu Chi, Hồ Như, Trần Mộng Tú, Hoàng Hưng, Huy Văn, Nguyễn Vũ, Ngự Thuyết, Phạm Phú Minh, Phùng Nguyễn, Tràm Cà Mau, Trịnh Y Thư,và Trúc Chi.
Xem các thí dụ:
Nội Dung 426 số báo của Tạp chí Bách Khoa (1957-1975): https://hoctroviet.blogspot.com/2026/08/noi-dung-426-so-bao-cua-tap-chi-bach.html
Nội Dung các số báo của Tạp chí Văn Học / Văn Học Nghệ Thuật ở Hải Ngoại (1978 - 2008): https://hoctroviet.blogspot.com/2026/08/noi-dung-cac-so-bao-cua-tap-chi-van-hoc.html
Bài viết này là một bản viết về "Từ 412 File PDF Đến Một Bảng Mục Lục" nhìn qua lăng kính "vibe coding" — cụm từ mà giới lập trình viên dùng để gọi cách làm việc mới này với AI. Điểm neo cho bài viết là một bài báo tiếng Anh của Yash Patel, "As a developer, I always thought vibe coding was overhyped — until I actually tried it", kể lại hành trình của chính một lập trình viên chuyên nghiệp từ hoài nghi đến chấp nhận. Đặt câu chuyện Bách Khoa cạnh câu chuyện của Patel cho thấy một điều: dự án trích xuất mục lục 412 số báo không chỉ là một ví dụ AI-giúp-làm-nhanh — nó là một trường hợp vibe coding, chỉ khác ở một chỗ mấu chốt là người ngồi trước máy "giả bộ" hắn không hề biết viết code.
Phần 1 - Đề bài: 412 số báo (đơn và kép - hai số nhập một), một bảng mục lục duy nhất
Tạp chí Bách Khoa — một trong những tạp chí trí thức quan trọng nhất của miền Nam Việt Nam, xuất bản liên tục từ năm 1957 đến 1975 — để lại một kho lưu trữ gồm 412 file PDF, đánh số từ số 1 đến số 426 (chỉ thiếu số 86). Mỗi file là bản scan của một số báo, dày trung bình 80–100 trang, một số số đặc biệt (như số 169, kỷ niệm 7 năm) dày tới 240 trang.
Mục tiêu đặt ra rất đơn giản để nói nhưng cực kỳ tốn công để làm: đọc trang mục lục ("Trong số này") của cả 412 số báo, rồi gõ lại từng dòng — số báo, ngày tháng, tên tác giả, tựa bài, số trang — thành một bảng dữ liệu phẳng (flat table), để sau này có thể gộp lại thành một cơ sở dữ liệu tra cứu cho toàn bộ 18 năm nội dung của tạp chí. Tính đến thời điểm bài này được viết, công việc đã trích xuất được khoảng 6.486 dòng bài viết từ toàn bộ 412 số.
Vì sao đây không phải là việc "làm thì lâu hơn" mà là việc "không ai làm nổi"
Cần phải nói rõ ràng ngay từ đầu: đây không phải là trường hợp AI giúp làm nhanh hơn một việc mà con người vẫn có thể làm được nếu có đủ thời gian. Đây là trường hợp khác hẳn về bản chất.
Người có động lực và kiến thức nền để làm việc này là một cá nhân làm ngoài giờ, không lương, không có đội ngũ hỗ trợ — nói cách khác, một người tình nguyện. Với 412 file PDF, mỗi file cần: (1) tìm ra trang nào trong file chứa mục lục thật (không phải trang bìa, không phải trang quảng cáo), (2) đọc và gõ lại chính xác từng dòng chữ Việt có dấu từ một bản scan cũ, nhiều khi mờ, nhiều khi tên tác giả in theo lối viết hoa có gạch nối kiểu cũ ("THÁI-VĂN-KIỂM", "TRẦN-VĂN KHÊ"), (3) gõ vào một bảng theo đúng định dạng thống nhất.
Giả sử mỗi số báo — nếu làm cẩn thận, tính luôn thời gian tìm trang, đọc, gõ, kiểm tra lỗi chính tả có dấu — mất trung bình 15–20 phút. Nhân với 412 số, đó là từ 100 đến 140 giờ làm việc liên tục, không tính thời gian nghỉ, không tính thời gian sửa lỗi khi gõ nhầm dấu (một lỗi rất dễ xảy ra và rất khó tự phát hiện khi gõ tiếng Việt có dấu hàng giờ liền). Đối với một người làm việc này ngoài giờ rảnh, con số đó không phải là "sẽ mất nhiều thời gian" — mà thực tế là "sẽ không bao giờ được hoàn thành". Nó sẽ nằm trong danh sách những dự án "để sau", và "sau" đó, kinh nghiệm cho thấy, thường không bao giờ tới.
Đây chính là điểm quan trọng nhất của bài viết này: giá trị mà AI mang lại ở đây không được đo bằng "AI giúp tiết kiệm bao nhiêu giờ", mà nên được đo bằng khoảng cách giữa con số không (không làm gì cả, dự án nằm im vĩnh viễn) và một kết quả cụ thể tồn tại được (6.486 dòng dữ liệu đã trích xuất, có thể tra cứu). Không có công cụ này, phần lớn khả năng là công việc sẽ mãi mãi ở trạng thái "có ý định làm" chứ không bao giờ có sản phẩm thật.
Kết quả cụ thể
Tính đến khi bài viết này được soạn, dự án đã hoàn tất toàn bộ 412/412 file PDF, chia thành 65 đợt (batch) xử lý, cho ra 6.486 dòng dữ liệu bài viết — mỗi dòng gồm số báo, ngày tháng phát hành, tên tác giả, tựa bài, số trang, và đường dẫn tới bản scan gốc. Số báo cuối cùng của tạp chí (số 426) được ghi nhận là phát hành khoảng ngày 15 tháng 4 năm 1975 — giữa đúng những ngày cuối cùng trước khi miền Nam Việt Nam sụp đổ, một chi tiết mà bảng dữ liệu này tình cờ giữ lại được như một dấu mốc lịch sử.
Toàn bộ khối lượng này được xử lý qua nhiều phiên làm việc rải rác, mỗi phiên chỉ xử lý một đợt nhỏ (ban đầu 20 file một đợt, sau đó rút xuống 5 file, rồi tăng dần lên 10 file một đợt khi kinh nghiệm cho thấy có thể xử lý nhanh hơn dự tính) — đúng với nhịp độ làm việc thực tế của một người tình nguyện làm việc này ngoài giờ rảnh, không phải một dự án có đội ngũ toàn thời gian đứng sau.
Phần 2 - "Vibe coding" nghĩa là gì — và vì sao câu chuyện này thuộc về nó
Patel mở đầu bài viết của mình bằng sự hoài nghi thẳng thắn: "Tôi luôn tin rằng một lập trình viên giỏi phải hiểu đoạn code mình viết ra, chứ không phải chấp nhận bất cứ gợi ý nào của AI." Với anh, lập trình là tư duy kiến trúc, là gỡ lỗi, là biết chính xác vì sao một giải pháp chạy được — còn code do AI sinh ra ban đầu chỉ giống một đường tắt hơn là một cách làm tốt hơn.
"Vibe coding" — mô tả bằng lời điều mình muốn, để AI viết ra phần lớn phần code thật sự — ra đời chính là để thách thức niềm tin đó. Và đúng như Patel mô tả, cách làm này chỉ thật sự bộc lộ giá trị khi được thử trên việc thật, không phải trên lý thuyết.
Dự án mục lục Bách Khoa là một trường hợp vibe coding theo đúng nghĩa đó, nhưng đẩy xa hơn một bước so với những gì Patel từng trải nghiệm. Trong toàn bộ 412 file PDF được xử lý, tác giả (người khởi xướng và trực tiếp làm dự án) không hề viết, không hề đọc, và cũng không hề cần đọc một dòng code Python nào. Những công cụ nhỏ như build_cumulative.py (gộp các file mục lục riêng lẻ thành một bảng tổng hợp) hay kịch bản chuyển Markdown sang HTML đều do AI tự viết, tự chạy, ở "hậu trường" — không có bước "đọc lại code trước khi chấp nhận" như Patel vẫn làm, đơn giản vì người chỉ đạo dự án "giả bộ" không có nền tảng để đọc code. Đây chính là điểm khởi đầu của câu chuyện: nếu Patel là một developer thử vibe coding, thì Bách Khoa là vibe coding thử nghiệm ở giới hạn xa nhất của nó — dành cho người hoàn toàn không có công cụ lập trình nào khác.
Điểm khởi đầu khác nhau: một lập trình viên hoài nghi, một người "giả bộ" không biết lập trình
Sự hoài nghi ban đầu của Patel có một nền tảng cụ thể: anh từng thử những công cụ AI-coding thời kỳ đầu, thấy chúng "sinh ra code nhìn qua thì đúng nhưng chứa lối viết lỗi thời, độ phức tạp không cần thiết, hoặc lỗi ẩn tinh vi." Review và sửa code AI sinh ra, với anh, không nhanh hơn tự viết là bao.
Người làm dự án Bách Khoa "giả bộ" hắn không có tư cách để đưa ra loại đánh giá đó (từ đây cho tới cuối bài viết) — không phải vì thiếu cẩn trọng, mà vì không có nền tảng kỹ thuật để phân biệt "code lỗi thời" với "code hiện đại". Điều này, thoạt nhìn, có vẻ là một điểm yếu chí mạng của dự án so với cách làm của Patel. Nhưng thực tế cho thấy điều ngược lại: rào cản mà Patel phải tự vượt qua bằng kinh nghiệm lập trình nhiều năm — biết đánh giá code AI viết ra có "sạch" hay không — hoàn toàn không tồn tại trong dự án này, bởi vì đơn vị cần được đánh giá không phải là code, mà là kết quả: một dòng dữ liệu trong bảng mục lục có đúng với những gì in trên trang scan hay không. Đó là một việc mà bất kỳ ai biết đọc tiếng Việt có dấu đều làm được, không cần biết một ngôn ngữ lập trình nào.
Nói cách khác: cái mà Patel gọi là "trách nhiệm review vẫn thuộc về tôi" được giữ nguyên trong dự án Bách Khoa, chỉ là đối tượng review đổi từ code sang dữ liệu đầu ra. Đây chính là phần mà bài báo của Patel — viết từ góc nhìn một developer đang cân nhắc có nên đưa AI vào quy trình làm phần mềm của mình hay không — không chạm tới: khả năng vibe coding mở rộng ra ngoài giới lập trình viên, cho bất kỳ ai có một việc có thể mô tả bằng lời và có thể kiểm chứng bằng kết quả.
"Điều bất ngờ lớn nhất không phải là chất lượng code" — ứng với việc dò tìm trang mục lục
Patel viết: "Điều bất ngờ lớn nhất không phải là code hoàn hảo — nó không hề hoàn hảo. Điều khiến tôi bất ngờ là tốc độ đi từ một ý tưởng đến một bản dùng thử chạy được." Với dự án Bách Khoa, khoảnh khắc tương đương chính là quy trình dò tìm trang mục lục.
Trang mục lục của Bách Khoa không nằm cố định: có số nằm ở trang 3, có số trang 3 chỉ là quảng cáo cố định (thuốc lá, hãng Shell, ngân hàng) và mục lục thật nằm sâu ở trang 7 hoặc đâu đó trong khoảng 11–20. Ban đầu, không ai — kể cả AI — biết trước quy luật này. Nó được rút ra dần: xử lý vài chục số đầu, quan sát mẫu hình, rồi viết lại quy tắc tìm kiếm cho các batch sau — kiểm tra trang 3 trước, rồi trang 7, rồi mới quét dải 11–17, và dừng lại nếu không thấy gì thay vì lục soát cả cuốn báo.
Đây chính là "tốc độ từ ý tưởng đến bản dùng thử" của Patel, nhưng áp dụng cho một quy trình tìm kiếm chứ không phải một đoạn code. Cái AI làm không phải là tạo ra quy tắc "3 → 7 → 11–17" hoàn hảo ngay từ đầu — cũng như Patel không kỳ vọng code AI-sinh hoàn hảo ngay từ đầu — mà là giúp quy tắc đó được thử, sai, và tinh chỉnh lại ở tốc độ mà một người tự làm bằng tay, lật từng trang PDF, sẽ không bao giờ đạt tới.
Việc lặp đi lặp lại, nhàm chán — chỗ vibe coding toả sáng nhất
Patel dành hẳn một đoạn cho phát hiện then chốt của mình: vibe coding phát huy tác dụng rõ nhất không phải ở những bài toán khó, mà ở "việc lặp đi lặp lại mà hầu hết lập trình viên vốn không thích làm" — dựng cấu trúc project, viết boilerplate, tạo API endpoint, dựng component UI đơn giản.
Dự án Bách Khoa gần như là bản minh hoạ giáo khoa cho đúng nhận định đó, chỉ chuyển từ code sang dữ liệu. Với 412 file PDF, ba việc chiếm phần lớn khối lượng công việc đều thuộc loại "lặp đi lặp lại, không cần nhiều phán đoán mỗi lần, nhưng cực kỳ tốn công nếu làm hàng trăm lần":
- Rasterize từng trang PDF thành ảnh đọc được — mở đúng file, chọn đúng trang, xuất ảnh ở độ phân giải đủ cao (thường 400 DPI), lặp lại hàng trăm, có khi hàng nghìn lần vì nhiều số phải thử 2–3 trang mới trúng mục lục.
- Đọc chữ Quốc ngữ có dấu từ bản scan cũ — 1957–1975, nhiều khi mờ, nhiều khi tên tác giả viết hoa có gạch nối kiểu cũ ("HOÀNG-MINH-TUYNH", "BÙI-KHÁNH-ĐẢN") — việc đọc-và-gõ-lại chính xác dấu thanh hàng trăm lần liên tục là đúng kiểu công việc "tốn thời gian nhưng không đòi hỏi sáng tạo" mà Patel mô tả.
- Gõ vào đúng khuôn bảng thống nhất (số báo, ngày tháng, tác giả, tựa bài, trang) cho 6.486 dòng — một dạng "boilerplate dữ liệu" tương đương boilerplate code trong bài Patel.
Không có việc nào trong ba việc trên đòi hỏi óc sáng tạo hay phán đoán phức tạp mỗi lần lặp lại — chúng chỉ đòi hỏi sự bền bỉ, thứ mà một người làm ngoài giờ, không lương, sẽ cạn kiệt rất nhanh nếu phải tự tay làm cả 412 lần. Đây chính xác là nơi Patel nói "tôi có thể nhảy thẳng vào phần thật sự cần sự chú ý của mình" — và với Bách Khoa, "phần thật sự cần chú ý" không phải là viết code, mà là quyết định thế nào là một dòng dữ liệu đúng.
Vibe coding không phải là "làm ít hơn" — công việc chỉ chuyển chỗ
Đoạn quan trọng nhất trong bài của Patel, và cũng là đoạn dễ bị hiểu sai nhất về vibe coding nói chung, là khi anh nhận ra: "Sự thay đổi lớn nhất với tôi là nhận ra vibe coding không hề giảm bớt lượng suy nghĩ tôi phải bỏ ra. Nó chỉ đổi chỗ tôi dành thời gian." Anh dành nhiều thời gian hơn cho việc lên kế hoạch tính năng, review code AI sinh ra, kiểm thử edge case, và tinh chỉnh prompt — thay vì gõ từng hàm từ đầu. "Tôi thấy mình giống một người review hơn là một người gõ code."
Dự án Bách Khoa có đúng một sự chuyển-chỗ tương tự, và chính đây là phần chứng minh dự án không phải là "để AI làm hết, mình chỉ ngồi chờ". Công việc thật sự của người chỉ đạo dự án nằm ở những quyết định mà chỉ con người mới có đủ ngữ cảnh để đưa ra:
- Định nghĩa thế nào là "nội dung" đáng đưa vào bảng. Các mục hành chính của toà soạn như "Lá thư tòa soạn", "Thay lời phi-lộ" — nơi "tác giả" thực chất là chính tờ báo chứ không phải một người viết — bị loại ra khỏi bảng. Nhưng một độc giả ký tên thật hoặc ký "MỘT BẠN ĐỌC" gửi thư vẫn được giữ lại, vì đó là đóng góp nội dung thật sự. Đây là loại phán đoán về ngữ cảnh mà không có quy tắc lập trình sẵn nào có thể tự đưa ra — nó cần một người hiểu tạp chí này thật sự là gì.
- Tự tinh chỉnh quy tắc tìm kiếm sau khi phát hiện ngoại lệ — ví dụ
BachKhoa-088.pdfcó mục lục lệch xuống tận trang 10, đúng ngay ngưỡng dưới của khung tìm kiếm ban đầu, buộc khung 11–17 phải được nới ra để không bỏ sót những trường hợp tương tự. - Xác nhận những chỗ AI tự đánh dấu không chắc — khi một dấu thanh khó đọc ở độ phân giải hiện có (như tên "THÁI-VĂN-KIỂM" ở số báo 90), AI không tự bịa ra một cách đọc trông có vẻ chắc chắn, mà giữ cách đọc đã được xác thực rộng rãi và gắn ký hiệu † để đánh dấu "cần xem lại bằng mắt thật".
Đây chính là "tôi thấy mình giống một người review hơn một người gõ" của Patel, chuyển từ ngữ cảnh code sang ngữ cảnh dữ liệu văn hoá. Và cũng giống hệt kết luận của Patel — "chất lượng đầu ra phụ thuộc rất nhiều vào chỉ dẫn tôi đưa ra; vibe coding không thay thế kỹ năng của tôi, nó dựa vào chính kỹ năng đó" — chất lượng bảng 6.486 dòng của Bách Khoa phụ thuộc trực tiếp vào việc người chỉ đạo dự án hiểu rõ tạp chí này, hiểu rõ thế nào là một bài viết thật, và biết đòi hỏi AI đánh dấu nghi vấn thay vì đoán liều.
Điều Patel vẫn không giao cho AI — và vì sao Bách Khoa là một dự án "an toàn" để vibe code
Patel cũng rất rõ ràng về giới hạn của mình: "Tôi vẫn sẽ không dựa vào vibe coding cho những dự án mà bảo mật, hiệu năng, hoặc độ tin cậy là yếu tố sống còn. Nếu đang xây dựng thứ gì đó xử lý dữ liệu nhạy cảm hoặc có logic nghiệp vụ phức tạp, tôi muốn hiểu từng phần quan trọng của code trước khi nó đi vào sản xuất." Anh cũng tránh chấp nhận những khối code lớn của AI mà không soát kỹ, vì rất dễ bỏ sót logic kém hiệu quả, dependency không cần thiết, hay edge case chỉ lộ ra về sau.
Nhìn qua lăng kính đó, dự án Bách Khoa hoá ra lại là đúng kiểu việc mà giới hạn của Patel cho phép — chứ không mâu thuẫn với nó. Đây không phải phần mềm xử lý dữ liệu nhạy cảm, không có logic nghiệp vụ phức tạp, không chạy "production" với người dùng thật phụ thuộc vào độ chính xác tuyệt đối theo thời gian thực. Sai sót ở đây — một dòng OCR đọc nhầm dấu thanh, một số báo bị bỏ sót mục lục — là những sai sót có thể phục hồi: được đánh dấu, được sửa sau, không kéo theo hậu quả dây chuyền nào. Đó chính xác là điều kiện mà cả Patel lẫn kinh nghiệm thực tế của dự án này đều đồng ý: hãy mạnh dạn vibe code những việc có rủi ro thấp, và giữ sự thận trọng kiểu review-kỹ-từng-dòng cho những việc có rủi ro cao.
Ngay cả trong một dự án "an toàn" như vậy, kỷ luật giữ lại từ cách làm của Patel vẫn được áp dụng — chỉ chuyển hình thức. Thay vì "review từng dòng code trước khi chấp nhận", dự án Bách Khoa áp dụng nguyên tắc: thà đánh dấu "không chắc" bằng ký hiệu † còn hơn bịa ra một câu trả lời trông có vẻ chắc chắn. Đây là bản dịch trực tiếp của câu "AI có thể chạy nhanh, nhưng tốc độ không thay thế được sự cẩn trọng trong kỹ thuật" của Patel sang một lĩnh vực hoàn toàn không phải kỹ thuật phần mềm.
Kết: đến vì sự cường điệu, ở lại vì quy trình — viết lại cho một người chưa từng viết code
Patel kết bài bằng một câu tổng kết rất developer: "Tôi đến vì sự cường điệu, nhưng ở lại vì quy trình làm việc." Với anh, vibe coding không biến anh thành một lập trình viên khác, nhưng biến anh thành một người làm việc hiệu quả hơn — dành ít sức cho việc lặp lại, nhiều sức hơn cho việc xây dựng, thử nghiệm, cải tiến ý tưởng.
Câu chuyện Bách Khoa cần một câu kết khác, vì điểm xuất phát khác hẳn. Không ai "đến vì sự cường điệu" ở đây — không có ai từng nghe nói "vibe coding" trước khi bắt tay vào dự án, không có kỳ vọng thời thượng nào cần được kiểm chứng. Người làm dự án này đến vì một nhu cầu rất cụ thể: đọc lại mục lục của 412 số báo trước khi thời gian rảnh ngoài giờ cho phép làm việc đó biến mất, như nó vẫn luôn biến mất với những dự án "để sau".
Và đây là chỗ khác biệt lớn nhất so với Patel: với anh, phép so sánh đúng là nhanh hơn bao nhiêu lần — vibe coding giúp một công việc anh vẫn có thể tự làm diễn ra hiệu quả hơn. Với Bách Khoa, phép so sánh đúng không phải là tốc độ, mà là có tồn tại hay không: nếu không có cách làm này, khối lượng 100–140 giờ đọc chữ có dấu từ bản scan cũ gần như chắc chắn sẽ không bao giờ được một cá nhân làm ngoài giờ hoàn thành — nó sẽ nằm mãi trong danh sách "có ý định làm". Vibe coding, ở đây, không phải là công cụ giúp một developer làm nhanh hơn việc anh ta vẫn biết cách làm. Nó là công cụ duy nhất từng tồn tại cho phép một người không biết viết một dòng code nào tự mình hoàn thành một dự án dữ liệu quy mô 412 file — và đó chính là phần mở rộng của câu chuyện "vibe coding" mà bài viết của một developer chuyên nghiệp như Patel, đứng từ vị trí của người vẫn luôn có lựa chọn tự viết code, không thể kể hết được.