Gemini app vượt 750 triệu người dùng hàng tháng: Google đang thách thức OpenAI

Nhận việc xong rồi ngồi nhìn màn hình cả tiếng không biết bắt đầu từ đâu đây là điều này xảy ra với người dùng Antigravity không kém gì người làm việc thông thường. Vấn đề không phải bạn kém hay lười mà là não bạn không sợ việc khó, nó sợ việc không rõ ràng và khi bạn giao cho AI một yêu cầu mơ hồ thì kết quả Antigravity tạo ra cũng sẽ mơ hồ không kém. Tại sao giao việc cho Antigravity mà vẫn ra kết quả tệ? Antigravity là agent thực sự vì nó có thể lên kế hoạch, viết code, chạy lệnh và tự kiểm tra kết quả. Nhưng đây chính xác là lý do khiến nhiều người thất vọng lần đầu dùng, họ bắt tay ngay giao cho Antigravity một việc cực lớn và mơ hồ, agent chạy 30 phút theo hướng sai quota tiêu hao hết mà kết quả không dùng được. Các nhà khoa học nhận thức gọi trạng thái đóng băng trước việc lớn là quá tải nhận thức - cognitive overload. Não không biết xử lý từ đâu nên chọn cách an toàn nhất là không làm gì cả và vòng lặp quen thuộc trông như thế này: Não sợ làm sai → đóng băng Không bắt đầu được → hạn chót đến gần Càng sợ hơn → lại đóng băng tiếp Với Antigravity, quá tải nhận thức của người dùng trực tiếp tạo ra prompt tệ, và prompt tệ tạo ra agent chạy sai hướng tất nhiên vòng lặp này tốn token và thời gian hơn bất kỳ lỗi kỹ thuật nào. Có ba cách tiếp cận để phá vỡ vòng lặp đó, tùy vào mức độ bạn đã hiểu yêu cầu và đã thiết lập quy trình đến đâu. Ba cách tiếp cận việc hiệu quả với Antigravity Cách 1: Tải source code của người đã có kinh nghiệm Đây là cách nhanh nhất để bắt đầu mà không mất thời gian thiết lập từ đầu, đặc biệt phù hợp khi bạn chưa biết quy trình của mình nên trông như thế nào. Antigravity hoạt động tốt nhất khi có đủ ngữ cảnh về dự án dó là khi nó có thể nhìn thấy các rules, workflow, skills và thư mục bộ nhớ ghi lại kiến thức cũ. Thay vì tự xây dựng tất cả, bạn sao chép source code của người đã thiết lập đầy đủ, tải về và để agent đọc toàn bộ cấu hình có sẵn và điều tất nhiên là phải được người đó đồng ý hoặc đã public . Lưu ý: Rất nhiều người đã tận dụng điều này để phát tán mã độc vậy nên chỉ cài những source code từ chính thức từ Anthropic, Google, xAI, OpenAI,... hay những người có uy tín. Khi bạn sao chép kho code của người đã thiết lập đầy đủ, tải về và để agent đọc toàn bộ cấu hình có sẵn, bạn nhận được hai lợi ích cùng lúc: Agent hiểu ngay phong cách viết skills, workflow, nền tảng kỹ thuật và các rules của dự án từ ngày đầu mà không cần bạn giải thích lại. Bạn học được cách người có kinh nghiệm thiết lập quy trình — từ cách tổ chức thư mục bộ nhớ đến cách viết quy tắc cho agent mà không cần tự mày mò từ đầu. Tuy nhiên khi bạn không hiểu các ý đồ của người viết thì hoàn toàn không thể sử dụng hết chức năng của source code này giống như một mặc một chiếc áo quá rộng vậy. Cách 2: Tự giải quyết từng bước nhỏ trước khi giao việc lớn Đây là cách tiết kiệm hạn mức nhất và cũng là bài học mình học được sau nhiều lần lãng phí vì giao việc quá to ngay từ đầu. Bộ khung 4C — Làm rõ (Clarify), Tách nhỏ (Chunk), Tham khảo (Consult), Cam kết (Commit) vốn dùng để giải quyết việc của con người, nhưng áp dụng vào Antigravity lại cực kỳ hiệu quả vì lý do đơn giản: bạn càng rõ ràng trước khi giao việc, agent càng ít phải đoán. Bước làm rõ: Trước khi gõ bất cứ thứ gì vào Antigravity, hãy tự trả lời 4 câu hỏi sau: Kết quả cuối cùng trông như thế nào? Ai sẽ dùng cái này? Hạn chót thật sự là khi nào? Thế nào là hoàn thành tốt việc này? Năm phút ngồi trả lời sẽ thay đổi hoàn toàn chất lượng câu lệnh. Thay vì "xây cho mình một hệ thống đăng nhập", bạn sẽ viết được "xây hệ thống đăng nhập bằng Google OAuth cho ứng dụng Next.js, lưu phiên làm việc vào Firestore, chuyển hướng về trang chính sau khi đăng nhập thành công, chạy thử trên máy và chụp ảnh màn hình để mình xem". Bước tách nhỏ: Dựa trên hiệu ứng Zeigarnik một khi bạn bắt đầu dù chỉ một bước nhỏ, não tự động muốn hoàn thành những bước tiếp theo. Hãy hỏi agent "chia task thành các bước nhỏ nhất để bắt đầu ?" và đi qua từng bước một. Dành khoảng thời gian nhất định để tìm hiểu cấu trúc, kiểm tra xem agent hiểu đúng yêu cầu chưa trước khi để nó chạy việc lớn. Nhưng hãy nhớ là chỉ giành một khoảng thời gian nhất định thôi nhé vì chỉ khi thực hiện thì nhiều vấn đề mới thực sự lộ ra chúng ta mới tìm ra cách giải quyết. Ở bước này chúng ta có thể sử dụng luôn chế độ Fast Mode cho agent thực hiện luôn mà không cần phải tạo khung sườn hay suy nghĩ sâu hoặc thậm chí nếu không có gì đặc biệt thì Gemini Flash hoàn toàn có thể đảm nhiệm tốt phần này cực kì tiết kiệm token cho Gemini Pro và Claude Opus. Bước tham khảo: Đừng tự làm khó bản thân khi đã có người đi trước. Tương tự như cách 1 tải mã nguồn người khác về dùng, bước này là chủ động tìm và đọc cách họ tiếp cận vấn đề xem họ chia việc ra sao, viết câu lệnh như thế nào, thiết lập quy trình ra sao rồi chắt lọc những phương pháp phù hợp để áp dụng vào việc của mình. Bạn không cần sao chép nguyên xi, chỉ cần học từ cấu trúc tư duy của họ. Điều này đặc biệt có giá trị với những loại việc bạn chưa từng giao cho agent bao giờ vì người đã làm trước thường đã tìm ra cả những điểm dễ đi sai mà bạn chưa biết. Bước cam kết: Thay vì cố lên kế hoạch hoàn hảo cho toàn bộ việc trước khi bắt đầu hãy chỉ cam kết 10 đến 15 phút đầu tiên để tìm hiểu. Hỏi agent một câu nhỏ, xem nó phản hồi thế nào và lúc nào cũng thêm câu prompt “Nếu vấn đề không rõ hoàn toàn có thể hỏi lại không được tự ý quyết định”. Chắc chắn sẽ có những thiếu sót nhưng chúng ta sẽ cảm thấy được chúng ta đã đi được một quãng đường xa với Antigravity với task thay vì ngồi viết prompt hoàn hảo hàng giờ mà chưa làm được gì chắc chắn sẽ rất chán. Cách 3: Giao việc lớn ngay khi đã có quy trình thiết lập sẵn Cách này chỉ hoạt động khi bạn đã qua hai cách trên — đã có quy trình rõ ràng, bộ nhớ ngữ cảnh skills, và agent đã quen với các rules, workflow. Đây có thể coi là bước cam kết trong bộ khung 4C: thay vì lo lắng về toàn bộ việc, bạn cần hướng agent vào một kết quả cụ thể và để agent tự xử lý phần còn lại. Lúc này, chế độ Plan Mode là lựa chọn tốt hơn chế độ Fast Mode vì agent phải tạo kế hoạch thực hiện chi tiết trước khi thực hiện task, từ đó bạn có thể xem lại kế hoạch đó để lại ghi chú nếu cần điều chỉnh rồi mới để agent chạy. Cách này kết hợp tốc độ của agent với tầm nhìn chiến lược của bạn vì quy trình đã có sẵn nên bước làm rõ nên được tích hợp vào các rules, workflow, skills để agent không cần bạn giải thích lại ngữ cảnh mỗi lần. Đặc biệt đây là cách cực kì ưa thích đối với các Pro khi mà họ dùng Claude để lên kế hoạch cực xịn rồi sau đó họ đưa vào cho GLM để thực thi taks để tiết kiệm token. Chúng ta nên chọn cách nào cho công việc của chúng ta Ba cách này sử dụng trong Antigravity không loại trừ nhau mà theo thứ tự từ ít đến nhiều ngữ cảnh: Việc mơ hồ, chưa biết bắt đầu từ đâu: Sao chép source code người khác hoặc dùng bộ khung 4C để làm rõ trước. Việc đã hiểu nhưng lớn và phức tạp: Đi qua từng bước nhỏ, dùng Flash cho bước đơn giản và dành Pro cho bước cần suy nghĩ sâu. Việc đã có quy trình rõ ràng: Giao thẳng với chế độ Plan Mode, để agent tự xử lý trong khi bạn làm việc khác. Điểm chung của cả ba cách là bạn phải làm một việc trước khi mở Antigravity: suy nghĩ. Không phải suy nghĩ dài — chỉ cần 5 đến 10 phút ngồi làm rõ yêu cầu trước khi giao cho agent. Khoảng thời gian đó tiết kiệm nhiều hạn mức hơn bất kỳ kỹ thuật tối ưu prompt nào khác.

Bạn gõ một câu lệnh, AI tự lên kế hoạch, mở terminal, viết code, mở trình duyệt web kiểm tra rồi báo lại kết quả, Antigravity làm tất cả trong khi bạn đang uống cà phê. Đó không phải viễn cảnh tương lai, đó là cách Google Antigravity hoạt động và nó vừa thay đổi hoàn toàn cách mình tiếp cận việc xây dựng sản phẩm và quy trình tự động. Google Antigravity là gì? Antigravity là IDE thế hệ mới do Google ra mắt cuối tháng 11 năm 2025 cùng lúc với Gemini 3, được xây dựng trên nền VS Code nhưng với kiến trúc hoàn toàn khác: thay vì AI ngồi ở sidebar gợi ý từng dòng code, AI trong Antigravity làm việc như một agent thực sự một khi đã được cấp quyền thì chúng ta có thể giao task và Antigravity tự hoàn thành task đó để cho ra kết quả rất giống với Manus và Flowith nhưng ở đây Antigravity thiên về màn hình làm việc với code hơn. Điểm khác biệt lớn nhất so với Cursor hay GitHub Copilot là Antigravity không hỏi bạn từng bước mà hoạt động bất đồng bộ đó là khi bạn giao task, agent chạy ngầm trong nền trong khi bạn làm việc khác rồi quay lại xem kết quả. Antigravity hoàn thành một feature Next.js + Supabase điển hình trong 42 giây so với 68 giây của Cursor, và độ chính xác khi refactor đạt 94% so với 78% của Cursor. Antigravity đã có phần mềm hỗ trợ macOS, Windows và Linux nên mọi người không lo về vấn dề phần mềm mà chỉ nên lo về chi phí gọi API. Ngoài sử dụng Gemini 3 và Gemini 3 pro mặc định, Antigravity còn hỗ trợ Claude Sonnet, Claude Opus và GPT-OSS thật tốt khi không bị khoá vào nền tảng của Google khi mà Claude Sonnet, Claude Opus đang dẫn đầu thị trường. Các tính năng tiêu biểu của Antigravity IDE Chỉnh sửa trực tiếp với sự hỗ trợ của AIVới giao diện quen thuộc như VS Code, nơi các lập trình viên có thể chỉnh sửa code tay hoặc nhờ AI hỗ trợ từng đoạn cụ thể. Phù hợp khi bạn muốn kiểm soát từng bước hoặc xử lý những đoạn code cần sự chú ý cao. Điều phối agent chạy song song Đây là điểm khác biệt thực sự của Antigravity thực sự với "mission control" bạn không cần viết code ở đây mà điều phối nhiều agent chạy song song. Ví dụ một agent đang refactor module A, agent khác đang viết test cho module B, agent thứ ba đang debug lỗi UI trên trình duyệt web. Bạn theo dõi tiến độ, để lại comment như trên Google Docs và agent tự điều chỉnh mà không cần dừng lại chờ. Truy cập và điều khiển trình duyệt web Đây là tính năng mình thấy ấn tượng nhất khi mới dùng khi mà Antigravity có thể mở trình duyệt web như Chrome, Firefox,... khi được cấp quyền từ đó nó có thể điều hướng trang web, điền form và kiểm tra giao diện hoàn toàn tự động. Tuy nhiên cần lưu ý rằng Antigravity hoạt động giống hệt như Puppeteer nên chỉ tương tác được với các tác vụ trên trình duyệt và khi cần có thể xử lý ảnh và chụp ảnh màn hình và tất nhiên chưa hoạt động được với những trang web đã cài đặt chặn bot truy cập. Logic của Antigravity rất rõ ràng Đây là tính năng mình thích nhất khi làm việc với Antigravity đó là thay vì đổ raw code ra màn hình, agent tạo ra các deliverable có thể đọc được như task list, implementation plan, screenshot màn hình app đang chạy để bạn kiểm tra logic của agent cả trước và sau khi hoàn thành task, điều này giúp bạn luôn nắm được agent đang làm gì để đánh giá. Antigravity đang được dùng để làm những gì trong thực tế? Nhiều người nghe đến Antigravity và nghĩ ngay đây là công cụ dành riêng cho lập trình viên chuyên nghiệp. Thực tế thì không phải vậy vì phạm vi ứng dụng rộng hơn nhiều so với vẻ ngoài kỹ thuật của nó. Xây dựng và triển khai website Đây là use case phổ biến nhất. Bạn mô tả trang web muốn xây — stack kỹ thuật, tính năng, phong cách thiết kế — agent tự viết code, tự kiểm tra trên browser và tự sửa lỗi. Kết hợp với Google Stitch qua MCP, bạn có thể đi từ thiết kế UI đến sản phẩm chạy thực sự mà không cần chuyển qua lại giữa nhiều công cụ. Ví dụ prompt dùng trong Antigravity: "Xây cho mình một landing page bằng Next.js và Tailwind CSS cho sản phẩm SaaS quản lý công việc nhóm. Có section hero, bảng giá 3 gói và form đăng ký email. Deploy lên localhost và chụp screenshot kết quả." Tự động hóa quy trình lặp lại Một trong những điểm mạnh thực tế nhất. Bạn có thể nhờ Antigravity tự động crawl dữ liệu từ nhiều nguồn, tổng hợp và gửi báo cáo theo lịch, hoặc tự động điền form và thực hiện các thao tác lặp đi lặp lại trên trình duyệt — những việc trước đây cần viết script riêng hoặc dùng công cụ automation phức tạp. Ví dụ prompt: "Mỗi sáng 8 giờ, vào trang thống kê của website mình tại [URL], lấy số liệu pageview và top 5 bài viết và xem thông tin 5 bài viết của trang fanpage Facebook của mình ở trang [URL], tổng hợp thành file markdown và lưu vào thư mục /reports/daily." Lưu ý: Facebook hoàn toàn không thích bot truy cập vào trang của họ cho nên hãy làm sao để bot thao tác gần như con người trên trình duyệt để không bị dính lỗi checkpoint của Facebook có thể dẫn đến khóa tài khoản. Xây dựng hệ thống AI agent Đây là use case mà Antigravity thực sự vượt trội so với các công cụ khác. Thay vì chỉ viết một đoạn code đơn lẻ, bạn có thể mô tả cả một pipeline — ví dụ "tạo hệ thống phân tích review sản phẩm từ nhiều nguồn, phân loại sentiment và tự động tag vào database" — rồi để Antigravity thiết kế kiến trúc agent, phân chia nhiệm vụ và triển khai từng bước. Ví dụ prompt: "Tạo một hệ thống gồm 3 agent: agent 1 crawl review sản phẩm từ Shopee và Lazada mỗi ngày, agent 2 phân tích sentiment và phân loại theo chủ đề, agent 3 tổng hợp thành báo cáo tuần và lưu vào Google Sheets." Refactor và cải thiện codebase có sẵn Nếu bạn có một dự án cũ cần nâng cấp, Antigravity đặc biệt hữu ích khi cần refactor quy mô lớn có thể thay đổi toàn bộ cấu trúc file, cập nhật dependencies, viết test coverage cho code chưa có test. Agent đọc toàn bộ codebase, hiểu ngữ cảnh và thực hiện thay đổi nhất quán trên nhiều file cùng lúc thay vì sửa từng chỗ một. Ví dụ prompt: "Đọc toàn bộ codebase trong thư mục /src, đóng vai chuyên gia bảo mật xem có dính lỗi SQL injection, các lỗ hổng owasp không đề xuất chỉnh sửa sao cho vẫn giữ nguyên logic và đảm bảo không có lỗi sau khi refactor." Nghiên cứu và tổng hợp thông tin từ web Vì Antigravity có thể điều khiển trình duyệt, bạn có thể dùng nó để tự động truy cập nhiều trang web, trích xuất thông tin theo cấu trúc bạn định sẵn và tổng hợp lại thành báo cáo hoặc database — phù hợp với các tác vụ research cần thu thập dữ liệu từ nhiều nguồn mà làm thủ công sẽ rất tốn thời gian. Ví dụ prompt: "Vào 10 trang web tin tức AI này [danh sách URL] và các trang fanpage [danh sách URL] tìm các bài đăng trong 7 ngày qua, trích xuất tiêu đề, tóm tắt 2 câu và link gốc, lưu vào file CSV theo thứ tự mới nhất trước." Các câu hỏi thường gặp khi sử dụng Antigravity Antigravity có miễn phí không? Có cả gói miễn phí và trả phí. Gói miễn phí có quota reset theo tuần với rate limit hạn chế, đủ để thử nghiệm và làm project nhỏ. Gói Pro/Ultra có quota reset mỗi 5 giờ và được ưu tiên cao nhất rất phù hợp nếu bạn dùng Antigravity hàng ngày cho công việc thực tế. Antigravity có làm được việc với file Word, Excel, PDF không? Antigravity cài Puppeteer nên hoạt động chủ yếu qua trình duyệt web và chưa thể tác động trực tiếp vào các loại file như Word, Excel hay PDF. Nếu cần xử lý những file này, bạn phải thêm vào workflow và mention trong phần cấu hình để agent biết cách tiếp cận đúng. AI không phản hồi hoặc bị treo phải làm gì?Đây là lỗi khá phổ biến, đặc biệt vào giờ cao điểm khi nhiều người dùng đồng thời. Trong hầu hết trường hợp, chỉ cần restart lại Antigravity là được hoàn toàn không cần lo mất dữ liệu hay phải thiết lập lại từ đầu. Ngoài ra, nên dùng git và commit thường xuyên trước khi giao task lớn để tránh mất code nếu agent bỏ dở giữa chừng. Antigravity thực sự là công cụ quá mạnh mẽ vì sao chúng ta không thử ngay. Người dùng có thể tải về tại antigravity.google/download và bắt đầu với một project nhỏ — không phải để thử tính năng mà để hiểu tư duy làm việc mới này trước khi đưa vào dự án thực tế.

Markdown đã là chuẩn mặc định khi làm việc với AI suốt nhiều năm nhưng một kỹ sư đến từ Claude Code tại Anthropic vừa đặt ra câu hỏi đáng suy nghĩ: liệu thói quen đó có thực sự là lựa chọn tốt nhất? Bài viết ngắn của Thariq Shihipar thu hơn 15.000 lượt thích trên X chỉ trong vài ngày, và lý do thuyết phục hơn bạn nghĩ. Markdown ra đời từ thời AI còn nghèo token Nhìn lại thời GPT-4 với cửa sổ ngữ cảnh chỉ 8.192 token, Markdown là lựa chọn hoàn toàn hợp lý trong khi đó HTML cồng kềnh hơn, tốn tài nguyên hơn và trong bối cảnh hạn chế đó, sự tối giản của Markdown là một ưu điểm thực sự chỉ để tiết kiệm. Vì vậy Markdown trở thành chuẩn ngầm định, và thói quen đó theo chúng ta đến tận bây giờ.Ngay cả khi Anthropic tạo ra khái niệm Skill trên Claude họ cũng đã lấy Markdown làm tiêu chuẩn với file SKILL.md, những ai hay làm việc với skill chắc chắn hiểu rõ điều mặc định này. Tuy nhiên, các mô hình AI hiện tại đã vận hành ở quy mô hoàn toàn khác. Nhiều mô hình đang hỗ trợ cửa sổ ngữ cảnh từ 200.000 đến 1 triệu token, và chi phí xử lý không còn là rào cản đáng lo (theo lời của Thariq Shihipar) và anh ấy lập luận rằng đây chính là thời điểm để xem lại mặc định đó. HTML làm được gì mà Markdown không thể? Lý do cốt lõi Thariq đưa ra khá đơn giản: một số loại thông tin vốn có tính không gian nhưng Markdown buộc chúng phải trở thành văn bản tuyến tính. Khi bạn so sánh ba hướng tiếp cận kỹ thuật thì bạn cần nhìn chúng cạnh nhau, không phải đọc lần lượt rồi cố giữ trong đầu. Khi bạn xem lại một đoạn code bạn cần thấy cấu trúc thay đổi tất nhiên không phải một bức tường chữ. HTML giải quyết đúng vấn đề đó vì vậy Thariq đã liệt kê 9 nhóm tình huống cụ thể mà HTML vượt trội hơn Markdown: Khám phá và lên kế hoạch: So sánh nhiều hướng tiếp cận cạnh nhau thay vì đọc tuần tự, rồi chuyển thành kế hoạch triển khai có sơ đồ luồng và mốc thời gian. Xem lại mã nguồn và hiểu cấu trúc dự án: Phần thay đổi được chú thích trực tiếp bằng màu sắc theo mức độ nghiêm trọng, sơ đồ mô-đun dạng hộp và mũi tên — thay vì văn bản thuần túy. Thiết kế giao diện: Bảng màu hiển thị thực tế có thể sao chép ngay, các biến thể thành phần giao diện được dựng trực tiếp thay vì mô tả bằng chữ. Tạo nguyên mẫu nhanh: Bảng điều chỉnh hiệu ứng chuyển động có thanh kéo thông số, màn hình có thể nhấp thực sự, đây là thứ Markdown không thể biểu đạt. Sơ đồ và hình minh họa: Đồ họa véc-tơ nội tuyến cho phép vẽ lưu đồ thực sự, không phải ký tự ASCII ghép lại. Bộ trình chiếu: Vài thẻ <section> và 20 dòng mã JavaScript là một bộ slide điều hướng bằng phím mũi tên mà không cần phần mềm chuyên dụng hay bước xuất file. Nghiên cứu và học tập: Tài liệu có phần thu gọn, tab mã, bảng chú giải thuật ngữ — thay vì đổ toàn bộ nội dung theo một chiều dọc. Báo cáo định kỳ: Bản tóm tắt trạng thái hàng tuần với biểu đồ nhỏ và màu sắc phân biệt tiến độ khiến người đọc thực sự đọc, không chỉ lướt qua. Giao diện chỉnh sửa tùy chỉnh: Bảng phân loại nhiệm vụ kéo thả, trình chỉnh cờ tính năng có cảnh báo phụ thuộc đây là công cụ thực sự, không phải văn bản đọc rồi thôi. Thariq đã tập hợp 20 file minh họa tất cả các nhóm này tại thariqs.github.io/html-effectiveness mỗi file mở thẳng trên trình duyệt, không cần cài đặt gì thêm. Dùng HTML với AI như thế nào trong thực tế? Cách áp dụng không phức tạp mà chỉ cần thay đổi cách bạn viết prompt. Thay vì để mô hình tự chọn định dạng đầu ra, hãy chỉ định rõ HTML khi nội dung cần được xem xét, tương tác, hoặc chia sẻ với người khác. Ví dụ câu lệnh Thariq gợi ý để xem lại một đoạn mã: Giúp tôi xem xét PR này bằng cách tạo một tài liệu HTML mô tả nó. Tôi không quen lắm với logic streaming/backpressure nên hãy tập trung vào phần đó. Hiển thị diff thực tế với các chú thích lề nội tuyến, mã màu các phát hiện theo mức độ nghiêm trọng và bất cứ thứ gì khác cần thiết để diễn đạt khái niệm một cách rõ ràng. Tương tự, bạn có thể yêu cầu AI tạo kế hoạch triển khai dưới dạng HTML với mốc thời gian và sơ đồ luồng dữ liệu, hoặc bản báo cáo trạng thái hàng tuần với biểu đồ nhỏ và màu sắc phân biệt tiến độ. Simon Willison tác giả blog kỹ thuật nổi tiếng cũng đã thừa nhận bài viết này khiến ông nhìn lại thói quen dùng Markdown từ thời GPT-4 cho đến tận thời điểm hiện tại. Khi các mô hình AI hiện đại có thể nhúng đồ họa véc-tơ, tiện ích tương tác và điều hướng nội trang, Markdown không còn là lựa chọn mặc định hiển nhiên nữa. Markdown vẫn còn chỗ đứng tất nhiên không phải ở mọi nơi Thariq không nói luôn luôn sử dụng HTML mà anh ấy phân biệt khá rõ: Markdown phù hợp cho trò chuyện thông thường, đoạn mã ngắn, câu trả lời vài dòng, và bất cứ thứ gì thuần văn bản trong khi đó HTML phát huy sức mạnh khi đầu ra cần bố cục không gian, màu sắc, khả năng tương tác, hoặc cấu trúc phức tạp đó là khi nội dung đủ nhiều chiều để Markdown bắt đầu làm phẳng thông tin thay vì truyền tải nó. Cộng đồng đã phản ứng khá nhanh: một skil mang tên html-artifacts đã xuất hiện trên GitHub, giúp AI tự nhận biết khi nào nên tạo file HTML thay vì Markdown bao gồm 9 nhóm tình huống từ bài viết gốc của Thariq hoàn toàn có thể sử dụng với bất cứ model nào hỗ trợ đọc skill. Đặc biệt skill này phần loại trừ rõ ràng cho câu trả lời ngắn và đầu ra chỉ có mã code. Mọi người có thể tham khảo tại github.com/dogum/html-artifacts. Trong bài Thariq không nhắc đến JSON nhưng đây cũng là định dạng hay sử dụng với AI đặc biệt đối với những ai hay dùng n8n, Make hay Zapier. Mặc dù vậy mỗi định dạng mang đến một màu sắc riêng trong những tình huống riêng. Markdown, HTML và JSON phân chia sử dụng như thế nào Cuộc tranh luận thực ra không chỉ là Markdown hay HTML. JSON cũng là định dạng phổ biến khi làm việc với AI, đặc biệt trong các luồng xử lý dữ liệu và tích hợp hệ thống. Ba định dạng này phục vụ ba mục đích khác nhau, và hiểu rõ ranh giới đó giúp bạn chọn đúng công cụ cho từng tình huống. Markdown tốt nhất cho văn bản đọc trực tiếp trong chat: ghi chú, giải thích ngắn, đoạn mã, tài liệu đơn giản. Nhanh, nhẹ, không cần mở thêm gì. HTML tốt nhất khi đầu ra cần được nhìn, tương tác hoặc chia sẻ: báo cáo có bố cục, sơ đồ, bảng so sánh, bộ trình chiếu, giao diện tùy chỉnh. Mở bằng trình duyệt là xong. JSON tốt nhất khi đầu ra cần được máy đọc tiếp: lưu trữ dữ liệu có cấu trúc, truyền giữa các hệ thống, hoặc làm đầu vào cho bước xử lý tiếp theo. Con người đọc được nhưng không phải để đọc. Nói cách khác, JSON không cạnh tranh với HTML hay Markdown về mặt trình bày mà nó phục vụ một mục đích hoàn toàn khác. Vấn đề thực sự nằm ở chỗ nhiều người dùng AI mặc định nhận đầu ra dưới dạng Markdown ngay cả khi họ cần HTML để xem, hoặc cần JSON để xử lý tiếp. Chỉ cần chỉ định rõ trong câu lệnh, AI sẽ điều chỉnh theo. Quy tắc chọn nhanh: Đầu ra để đọc trong chat → Markdown. Đầu ra để xem trên trình duyệt → HTML. Đầu ra để máy xử lý tiếp → JSON. Điều này có làm thay đổi gì với người dùng AI thông thường? Nếu bạn dùng AI chủ yếu để hỏi đáp hoặc viết lách, thay đổi này ít tác động hơn. Nhưng nếu bạn đang dùng AI để làm nhiều việc hơn như phân tích dữ liệu, lên kế hoạch dự án, xem lại tài liệu, tổng hợp nghiên cứu, hay tạo báo cáo cho đồng nghiệp đây là điều chỉnh nhỏ trong cách prompt nhưng tạo ra khoảng cách rõ rệt về chất lượng đầu ra, dù bạn đang dùng công cụ AI nào. Bạn nên thử một lần: lần tới khi cần AI so sánh các lựa chọn hoặc tóm tắt một tài liệu phức tạp, thêm vào cuối câu lệnh "tạo dưới dạng file HTML ". Mở file đó trên trình duyệt và so sánh với cách bạn vẫn làm với Markdown hay JSON thì kết quả thường nói lên tất cả.

Andrej Karpathy — đồng sáng lập OpenAI, cựu giám đốc AI tại Tesla và người đặt ra thuật ngữ "vibe coding" — đã chia sẻ trên X cách ông đang dùng AI, và câu trả lời không phải là viết code nhanh hơn mà là xây một hệ thống kiến thức cho bộ não thứ hai có khả năng tự duy trì, tự liên kết và tự cập nhật — đó là LLM Wiki. Wiki nghiên cứu của anh ấy viết về một chủ đề đã đạt 100 bài viết và 400.000 từ và điều đáng chú ý là toàn bộ do AI viết mà không cần ông gõ một chữ nào. Vấn đề với cách chúng ta đang dùng AI để tổ chức kiến thức RAG có tích lũy kiến thức theo thời gian như bộ não chúng ta không Hầu hết công cụ AI hiện tại xử lý tài liệu theo mô hình RAG — bạn tải lên tài liệu, đặt câu hỏi, hệ thống tìm đoạn văn bản liên quan rồi AI tổng hợp câu trả lời. NotebookLM của Google, ChatGPT với file upload, và hầu hết các quy trình AI đều dùng cách này vì nó rất đơn giản và dễ triển khai. Tuy nhiên Karpathy chỉ ra vấn đề cốt lõi mà ít người chú ý: RAG không tích lũy kiến thức. Mỗi lần bạn hỏi, hệ thống bắt đầu lại từ đầu — đọc lại tài liệu, tìm đoạn liên quan, ghép câu trả lời — rồi hỏi lại câu đó hôm sau thì nó lặp lại toàn bộ quá trình như chưa từng xảy ra. Tài liệu từ tháng 3 và tài liệu từ tháng 10 không tự kết nối với nhau tất nhiên là không có gì tích lũy và không có gì học được từ lần trước hoàn toàn không giống như cách bộ não chúng ta hoạt động. Karpathy mô tả sự thay đổi trong tư duy của mình bằng một câu rất ngắn nhưng nói lên nhiều thứ: phần lớn lượng token ông tiêu tốn gần đây không còn đi vào việc thao tác code mà đi vào việc thao tác kiến thức. LLM Wiki hoạt động như thế nào? LLM Wiki không phải phải phần mềm mà đây là một kiến trúc tư duy Obsidian Ý tưởng của Karpathy không phải là một phần mềm hay thư viện mới mà anh ấy công bố nó dưới dạng "idea file" để tạo ra kiến trúc giống với Obsidian — Anh ấy đã tạo ra file GitHub Gist được thiết kế để copy-paste trực tiếp vào một AI agent như Claude Code hoặc OpenAI Codex, rồi để agent tự xây hệ thống theo kiến trúc đó kết hợp với người dùng. Điều này có nghĩa là bạn không cài gì cả, mà thay vào đó bạn mô tả kiến trúc cho AI rồi AI tự triển khai nó cho bạn. Ba lớp kiến trúc cốt lõi của Wiki Hệ thống được tổ chức theo ba lớp rõ ràng và mỗi lớp có vai trò không thể thay thế cho nhau: Thư mục nguồn thô (raw/): Nơi bạn thả bất cứ tài liệu nào vào — PDF, bài báo, transcript, ghi chú, đoạn tweet — và AI đọc nhưng không bao giờ sửa thư mục này. Nguyên tắc thiết kế ở đây rất quan trọng: thu thập trước, tổ chức sau, tức là bạn không cần phải phân loại hay chuẩn bị tài liệu trước khi đưa vào. Wiki (wiki/): Thư mục chứa toàn bộ các file markdown do AI tạo và duy trì, và đây là nơi kiến thức được biên dịch, liên kết và tổng hợp. Mỗi tài liệu trong raw/ được AI đọc và tích hợp vào wiki — cập nhật các trang liên quan, ghi chú mâu thuẫn, tạo backlink sang các khái niệm liên quan. File cấu hình (CLAUDE.md hoặc tương đương): Bộ quy tắc nói cho AI biết cách tổ chức wiki, format bài viết, xử lý mâu thuẫn và duy trì nhất quán xuyên suốt toàn bộ hệ thống. Karpathy mô tả mối quan hệ giữa các thành phần bằng một câu rất hình ảnh: "Obsidian là IDE. LLM là lập trình viên. Wiki là codebase." Bạn không tự viết wiki mà thay vào đó bạn đặt câu hỏi, khám phá, trong khi AI làm phần việc tẻ nhạt là duy trì và cập nhật cơ sở dữ liệu. Vòng lặp tự duy trì là điểm khác biệt thực sự Ba thao tác chạy liên tục không cần can thiệp Điều làm LLM Wiki khác với các công cụ ghi chú AI thông thường là vòng lặp hoạt động tích cực sau khi Wiki đã được xây dựng và AI không chỉ tóm tắt tài liệu một lần rồi thôi mà nó chạy ba thao tác liên tục: Ingest (thu thập): Khi bạn thả một tài liệu mới vào thư mục nguồn, AI đọc nó, trích xuất thông tin quan trọng và tích hợp vào wiki — cập nhật các trang đã có, tạo trang mới nếu cần, đồng thời ghi chú chỗ nào thông tin mới mâu thuẫn với cái cũ thay vì xóa đi một cách tùy tiện. Query (truy vấn): Bạn hỏi bằng ngôn ngữ tự nhiên và vì wiki đã được biên dịch và cấu trúc sẵn nên AI trả lời với độ chính xác cao và có thể trích dẫn đến từng trang cụ thể, thay vì ghép câu trả lời từ các đoạn rải rác như RAG thông thường. Lint (kiểm tra chất lượng): AI định kỳ quét toàn bộ wiki để phát hiện link bị hỏng, trang cô lập không được liên kết với phần còn lại, thông tin mâu thuẫn giữa các trang, và lỗ hổng kiến thức chưa được bao phủ. Karpathy gọi đây là "CI/CD cho knowledge base" — tức là hệ thống tự kiểm tra chất lượng của chính mình. Karpathy giải thích lý do hệ thống này bền vững hơn wiki truyền thống do con người duy trì bằng một nhận xét đơn giản nhưng rất chính xác: "Con người bỏ cuộc với wiki vì gánh nặng bảo trì tăng nhanh hơn giá trị nó mang lại. LLM không chán, không quên cập nhật tài liệu đối chiếu và có thể chỉnh 15 file trong một lần chạy." Tại sao không cần RAG ở quy mô cá nhân? Context window đã đủ lớn để thay thế vector database Lập luận gây tranh cãi nhất trong đề xuất của Karpathy là tuyên bố RAG không cần thiết ở quy mô cá nhân, và logic của anh ấy như sau: một bộ não thứ hai toàn diện — dù bao phủ toàn bộ lĩnh vực nghiên cứu của bạn — thường chỉ khoảng 500.000 đến 2 triệu token sau khi biên dịch thành markdown. Với các model có context window dài hiện tại, toàn bộ Wiki đó có thể đưa vào context trong một lần truy vấn mà không cần hệ thống tìm kiếm vector phức tạp nào. Karpathy báo cáo rằng ở quy mô khoảng 100 bài viết và 400.000 từ, hệ thống xử lý câu hỏi phức tạp tốt mà không cần vector database hay RAG infrastructure nào, vì AI tự xây và duy trì các file index và tóm tắt rồi điều hướng qua toàn bộ tập hợp văn bản hiệu quả nhờ cấu trúc tự xây đó. Tuy nhiên cần lưu ý một điểm quan trọng: giới hạn này có thực. Khi wiki vượt qua một ngưỡng nhất định có thể là vài triệu token thì context window bắt đầu trở thành nút thắt cổ chai thực sự, và lúc đó các công cụ tìm kiếm như qmd (hybrid BM25/vector search cho markdown) sẽ cần được tích hợp thêm để duy trì hiệu suất. Cách bắt đầu thực tế trong 15 phút Các bước đầu tiên để có wiki đầu tiên như thế nào Karpathy thiết kế hệ thống này để bất kỳ ai có Claude Code hoặc công cụ AI agent tương đương đều có thể triển khai ngay mà không cần kiến thức kỹ thuật chuyên sâu. Quy trình cơ bản gồm bốn bước: Tạo một vault Obsidian mới — đây chỉ là một thư mục trên máy tính, nơi toàn bộ file markdown sẽ được lưu và Obsidian chỉ là giao diện để bạn đọc và điều hướng. Tạo hai thư mục con: raw/ để chứa tài liệu nguồn và wiki/ để AI viết và duy trì — hai thư mục này là tất cả những gì bạn cần thiết lập thủ công. Copy GitHub Gist của Karpathy tại Github và paste vào Claude Code hoặc AI agent bạn đang dùng, vì Gist được viết như một bộ hướng dẫn cho agent và để agent tự xây phần chi tiết cùng bạn thay vì bạn phải làm tất cả. Thả vài tài liệu đầu tiên vào raw/ và để agent bắt đầu biên dịch wiki — từ đây mọi thứ sẽ tự chạy. Cả hệ thống chạy hoàn toàn trên máy local với chỉ hai phụ thuộc là Obsidian để xem và điều hướng, và một AI agent để viết và duy trì. Điều này có nghĩa là không có vendor lock-in, không có dữ liệu gửi lên cloud nếu bạn dùng model local, và không có phí thuê bao nào ngoài chi phí gọi API của model bạn chọn. LLM Wiki so với MemPalace, Mem0 và Zep Bốn triết lý khác nhau cho cùng một vấn đề Cùng thời điểm LLM Wiki của Karpathy được chú ý, cộng đồng AI cũng đang thảo luận về MemPalace là một hệ thống bộ nhớ mã nguồn mở do diễn viên Milla Jovovich và kỹ sư Ben Sigman xây dựng, đạt 96.6% trên benchmark LongMemEval. Cả bốn hệ thống LLM Wiki, MemPalace, Mem0 và Zep đều giải quyết vấn đề AI không nhớ ngữ cảnh giữa các session, nhưng theo bốn triết lý rất khác nhau và phù hợp với bốn nhu cầu khác nhau. Cách dễ nhất để hình dung sự khác biệt là qua một tình huống cụ thể: bạn đã có 6 tháng hội thoại với AI về một dự án nghiên cứu — mọi quyết định, mọi lý luận, mọi phương án bị loại bỏ. Mở session mới và hỏi lại "Tại sao lúc đó mình chọn hướng A thay vì B?" — mỗi hệ thống sẽ trả lời theo cách hoàn toàn khác nhau. Mem0 hoạt động như người thư ký ghi tóm tắt cuộc họp, nghĩa là nó dùng AI để đọc hội thoại, trích xuất các "facts" quan trọng như sở thích và quyết định đã đưa ra, rồi lưu vào vector database. Khi bạn hỏi lại, nó tìm fact gần nhất với câu hỏi và trả về — nhanh, dễ tích hợp và phù hợp với chatbot thương mại, nhưng lý do đằng sau quyết định cùng chuỗi lập luận dẫn đến kết quả thường đã biến mất vì AI đã tự quyết định thứ đó không quan trọng. Zep tinh vi hơn một bước với knowledge graph có yếu tố thời gian, tức là nó không chỉ nhớ "bạn thích X" mà nhớ "tháng 1 bạn nghĩ X, tháng 3 bạn đổi sang Y vì lý do Z". Điểm mạnh là hiểu được sự thay đổi theo thời gian và phù hợp cho ứng dụng cần track tiến trình người dùng, tuy nhiên Zep vẫn dùng AI để quyết định thông tin nào được đưa vào graph nên vẫn có nguy cơ mất context quan trọng — đặc biệt là những lý luận phức tạp mà AI đánh giá là không cần thiết. MemPalace theo triết lý ngược hoàn toàn: "lưu tất cả, rồi làm cho nó tìm được". Thay vì để AI quyết định cái gì đáng nhớ, MemPalace lưu nguyên văn toàn bộ hội thoại vào ChromaDB rồi tổ chức theo cấu trúc phân cấp lấy cảm hứng từ kỹ thuật ký ức cung điện của người Hy Lạp cổ: Wing → Hall → Room → Closet → Drawer. Không có gì bị lọc bỏ nhưng mọi thứ đều có địa chỉ rõ ràng để tìm lại, và hệ thống chạy hoàn toàn trên máy local mà không gửi dữ liệu ra ngoài. LLM Wiki của Karpathy giải quyết bài toán khác hẳn so với ba hệ thống trên. Thay vì nhớ hội thoại, nó biên dịch tài liệu thành kiến thức có cấu trúc — bạn không đưa vào lịch sử chat mà đưa vào bài báo, transcript, ghi chú nghiên cứu, rồi AI xây một wiki markdown có liên kết, tóm tắt và có thể truy vấn. Mỗi tài liệu mới không chỉ được lưu mà được tích hợp vào kiến thức đã có, tạo ra kết nối mới giữa các khái niệm và làm giàu thêm những gì đã biết. Bảng so sánh để chọn đúng công cụ cho đúng nhu cầu table { width: 100%; border-collapse: collapse; margin: 20px 0; font-family: Arial, sans-serif; } th, td { border: 1px solid #ddd; padding: 12px; text-align: left; } th { background-color: #f4f4f4; font-weight: bold; } tr:nth-child(even) { background-color: #fafafa; } tr:hover { background-color: #f1f1f1; } Tiêu chí LLM Wiki MemPalace Mem0 Zep Nguồn dữ liệu Tài liệu nghiên cứu, bài báo, transcript Lịch sử hội thoại với AI Lịch sử hội thoại Lịch sử hội thoại Cách lưu trữ Markdown có cấu trúc, AI biên dịch Nguyên văn toàn bộ, phân cấp không gian Facts được trích xuất bởi AI Knowledge graph có thời gian AI có lọc thông tin? Có — AI quyết định cách tổ chức Không — lưu tất cả Có — AI chọn facts quan trọng Có — AI chọn entities và relations Chạy local? Có — chỉ cần Obsidian + model Có — ChromaDB + SQLite trên máy Không — cloud service Không — cloud service Phù hợp nhất với Nghiên cứu, học tập, tổng hợp tài liệu Nhớ ngữ cảnh AI theo thời gian dài Chatbot, ứng dụng thương mại App cần track tiến trình người dùng Điểm yếu Không nhớ hội thoại, cần setup ban đầu Tốn dung lượng, chưa có UI trực quan Mất lý luận phức tạp Phụ thuộc cloud, vẫn có thể mất context Điểm quan trọng nhất cần nhớ khi chọn: LLM Wiki và MemPalace giải quyết hai vấn đề khác nhau và hoàn toàn có thể dùng song song thay vì phải chọn một. MemPalace nhớ lịch sử các cuộc trò chuyện của bạn với AI — tức là nó biết bạn đã nói gì, đã quyết định gì và đã thay đổi quan điểm như thế nào. LLM Wiki thì tổ chức kiến thức từ thế giới bên ngoài đó có thể là bài báo bạn đọc, video bạn xem, tài liệu bạn thu thập. Kết hợp cả hai cho phép AI vừa hiểu bạn là ai vừa hiểu lĩnh vực bạn đang nghiên cứu và cả 2 kết hợp mới thành bộ não thứ hai đầy đủ hơn. Insight đáng suy nghĩ nhất từ LLM Wiki Phần đông chúng ta đang dùng AI như một công cụ tạo ra câu trả lời nhất thời — mỗi session bắt đầu từ đầu và không có gì tích lũy. LLM Wiki của Karpathy gợi ý một hướng khác: dùng AI như một bộ biên dịch kiến thức, nơi mỗi tài liệu mới không chỉ được lưu trữ mà được tích hợp vào một cấu trúc đã có, tạo ra kết nối mới và làm giàu những gì đã biết. Nếu bạn đang nghiên cứu một lĩnh vực cụ thể — AI, công nghệ, tài chính hay bất kỳ thứ gì — đây là thứ đáng thử ngay hôm nay: tạo một thư mục, thả vào đó 5 bài viết bạn đã đọc gần đây, và để Claude Code bắt đầu xây wiki đầu tiên. Sau một tuần thêm tài liệu đều đặn, bạn sẽ thấy sự khác biệt giữa một kho lưu trữ và một cơ sở kiến thức thực sự. Nếu bạn đang nghiên cứu một lĩnh vực cụ thể — AI, công nghệ, tài chính, bất kỳ thứ gì — đây là thứ đáng thử ngay hôm nay: tạo một thư mục, thả vào đó 5 bài viết bạn đã đọc gần đây, và để Claude Code bắt đầu xây wiki đầu tiên. Sau một tuần thêm tài liệu đều đặn, bạn sẽ thấy sự khác biệt giữa một kho lưu trữ và một cơ sở kiến thức thực sự.