Cuốn sách giúp xây dựng ứng dụng với mô hình nền tảng của Huyền Chip

Con người đã thắng. Nhưng cánh tay trái của anh gần như gãy, ngón tay phồng rộp, và anh thú nhận chỉ cần thêm 30 phút nữa là phải bỏ cuộc sau cuộc thi phân loại hàng hóa. Robot thì vẫn đang chạy tất nhiên là không mệt, không đau, không cần nghỉ. Đó là câu chuyện đằng sau tấm huy chương "chiến thắng" của con người trong cuộc đối đầu phân loại hàng hóa diễn ra ở Figure AI . Cuộc đối đầu 10 tiếng giữa người và máy Figure AI công ty robot hình người được định giá 39 tỷ USD đã tổ chức một thử nghiệm trực tiếp mang tên "Man vs. Machine": robot F.03 (Figure 03) đối đầu với một thực tập sinh tên Aime trong ca phân loại hàng hóa kéo dài 10 tiếng. Nhiệm vụ đơn giản đến mức nhàm chán: nhận diện mã vạch, nhặt kiện hàng, đặt úp mã vạch xuống băng chuyền lặp đi lặp lại liên tục. Kết quả cuối ca: Aime (người): 12.924 kiện hàng — trung bình 2,79 giây/kiện F.03 (robot): 12.732 kiện hàng — trung bình 2,83 giây/kiện Chênh lệch: 192 kiện và 0,04 giây mỗi lần xử lý. Con người thắng — theo đúng nghĩa đen của bảng điểm. Nhưng "thắng" ở đây nghĩa là gì? CEO Brett Adcock viết trên X sau trận đấu: "Xin chúc mừng Aime! Anh ấy nói cánh tay trái mình gần như gãy rồi 😂 Đây là lần cuối cùng con người thắng được." Trong cuộc thi, F.03 từng vượt mặt Aime vào khoảng giờ thứ 5 đó đúng lúc anh đứng dậy đi vệ sinh và robot thì không cần điều đó nó chỉ cần nguồn điện cấp là đủ. [VIDEO:CvkcPKlnQY4|Video livestream về màn so tài giữa người và robot|Video livestream về màn so tài giữa người và robot] Và đó chính là điểm mấu chốt mà con số 12.924 vs 12.732 không thể hiện được. Robot không đập tay, không uống bia ăn mừng Sau 10 tiếng, Aime ngồi xuống, xoa cánh tay, thở phào. Anh thừa nhận chỉ cần thêm 30 phút nữa là đã phải bỏ cuộc vì đau lưng và cẳng tay. F.03 thì tiếp tục chạy không ăn mừng, không nghỉ ngơi, không cần ai vỗ vai khen ngợi chắc chắn trong khi Aime ngủ đêm đó, robot vẫn đang phân loại ca tiếp theo. Theo luật lao động California, Aime được nghỉ ăn trưa và các giờ nghỉ có lương trong ca. Robot không thuộc phạm vi điều chỉnh của bất kỳ bộ luật lao động nào. Đây không phải bất công mà đây là bản chất của vấn đề: con người và máy đang chơi theo hai bộ quy tắc hoàn toàn khác nhau. Một ca làm việc đối đầu với một tuần làm việc Người ta thường so sánh hiệu suất trong một ca 8 - 10 tiếng. Nhưng nếu kéo dài phép đo ra một tuần làm việc, bức tranh thay đổi hoàn toàn. Figure AI trước đó đã chứng minh F.03 có thể vận hành liên tục 24 giờ, xử lý hơn 30.000 kiện hàng mà không có một lỗi dừng máy nào. Con người làm 5 ngày/tuần nhưng robot có thể làm 7 ngày, 3 ca. Một chuyên gia tại Đại học Ohio State nhận xét: trong quá trình livestream, F.03 vẫn mắc lỗi khi đặt kiện nhầm vị trí hay làm rơi hàng khỏi băng chuyền. Humanoid robot hiện vẫn còn là "dự án khoa học" đối với nhiều môi trường triển khai thực tế. Figure 03 là robot như thế nào? F.03 được Figure AI ra mắt vào tháng 10/2025. Robot cao 5'8" (khoảng 173 cm), nặng 61 kg, có thể mang tải 20 kg và sạc không dây thông qua tấm sạc tích hợp ở lòng bàn chân. Điểm nổi bật là các đầu ngón tay xúc giác có thể cảm nhận lực từ 3 gram đủ nhạy để cầm nắm vật mỏng manh mà không làm vỡ. Tại nhà máy BMW ở Spartanburg, phiên bản trước đó (F.02) đã lắp ráp hơn 30.000 xe với độ chính xác 99%. Figure đang xây dựng nhà máy BotQ với công suất thiết kế ban đầu 12.000 robot/năm, hướng tới 100.000 robot/năm trong vài năm tới. Tại sao kết quả này lại quan trọng mặc dù con người đã thắng? Không phải vì robot sắp chiếm hết việc làm kho vận ngay ngày mai. Mà vì khoảng cách hiệu suất giữa người và máy trong lao động thể chất lặp đi lặp lại đang co lại với tốc độ đáng lo ngại. Năm ngoái, F.03 có thể còn thua cách biệt lớn hơn trong khi năm nay khoảng cách chỉ là 0.04s /1 kiện hàng. Năm tới, Adcock đã tuyên bố sẽ cải tiến cả phần cứng lẫn phần mềm AI và lần sau, theo lời ông con người sẽ không còn cơ hội thắng nữa. Điểm thú vị: cuộc thi này không được thiết kế để robot thắng ngay. Nó được thiết kế để chứng minh robot đã đủ gần để theo kịp con người và từ đó tạo áp lực tâm lý lẫn thương mại cho cả thị trường logistics. Microsoft AI CEO Mustafa Suleyman dự báo AI sẽ tự động hóa phần lớn công việc văn phòng trong 12–18 tháng tới. Còn với lao động thể chất, cuộc thi này cho thấy: ranh giới đang mỏng dần, và "lần cuối cùng con người thắng" theo đúng nghĩa đen có thể không còn xa. Điều còn lại sau cuộc đua Sự thành công của buổi thử nghiệm đã thổi bùng lên những cuộc thảo luận sôi nổi về tương lai của thị trường lao động trong ngành logictics. Khi robot hình người đã đạt đến hiệu suất xấp xỉ con người, việc áp dụng chúng trên quy mô lớn chỉ còn là vấn đề thời gian và chi phí sản xuất. Các doanh nghiệp sẽ có xu hướng chuyển giao những công việc lặp đi lặp lại và có tính chất nặng nhọc cho máy móc đảm nhận. Mặc dù vậy điều này không có nghĩa là con người sẽ hoàn toàn bị thay thế trong các nhà kho thông minh. Thay vào đó lao động con người và các AI thông minh khác sẽ chuyển dịch sang các vai trò giám sát hệ thống, xử lý các tình huống phức tạp hoặc quản lý chuỗi cung ứng ở cấp độ cao hơn. Sự kết hợp hài hòa giữa sức bền của robot và trí tuệ của con người sẽ tạo nên những mô hình nhà kho có hiệu quả vượt bậ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ự.

Bạn có ý tưởng cho một app hoặc website trong đầu nhưng không biết Figma, không biết code — và không muốn mất hàng tuần để học cả hai. Google Stitch được tạo ra để giải quyết đúng tình huống đó: bạn mô tả giao diện bằng tiếng Anh hoặc tiếng Việt thông thường, AI tạo ra màn hình hoàn chỉnh trong vòng dưới một phút. Google Stitch là gì? Google Stitch là công cụ AI thiết kế UI miễn phí do Google Labs phát triển, ra mắt tại Google I/O 2025 và hiện chạy trên nền Gemini. Bạn truy cập hoàn toàn qua trình duyệt tại stitch.withgoogle.com, không cần cài đặt gì thêm, chỉ cần đăng nhập bằng tài khoản Google. Điểm khác biệt so với Figma hay Canva là Stitch không yêu cầu bạn kéo thả hay chọn từng component. Bạn chỉ cần mô tả những gì bạn muốn — ví dụ "trang landing page cho ứng dụng công nghệ vũ trụ, dùng màu tím chủ đạo" — và Stitch tạo ra giao diện hoàn chỉnh với đầy đủ màu sắc, font chữ và bố cục. Kết quả là HTML và CSS thực sự, không phải ảnh chụp màn hình. Bắt đầu vibe design với Google Stitch AI trong 3 bước Bước 1: Viết prompt hiệu quả Chất lượng vibe -desgin phụ thuộc rất nhiều vào cách bạn mô tả prompt vì vậy một prompt tốt cần có đủ ba yếu tố: loại màn hình, đối tượng người dùng và cảm xúc hoặc phong cách muốn truyền tải. Ví dụ prompt yếu: "Tạo trang chủ cho app." Ví dụ prompt mạnh: "Thiết kế một trang đích hiện đại cho SaaS cho một công ty khởi nghiệp về công nghệ vũ trụ có tên là LaunchPad. Sử dụng bảng màu xanh dương thẫm và tím neon. Thêm một phần nổi bật có nút "Bắt đầu", một lưới tính năng gồm 3 cột và một bảng giá theo hiệu ứng kính mờ." và đây là kết quả của mình Ngoài ra, Stitch hỗ trợ cả việc upload ảnh phác thảo tay hoặc ảnh chụp màn hình tham khảo hoặc thậm chí là giọng nói của chính bán luôn để AI hiểu đúng hơn định hướng của bạn. Bước 2: Chọn mode Flash hay Pro? Google Stitch hiện có hai chế độ tạo ảnh. Flash dùng Gemini Flash, tạo kết quả nhanh hơn và phù hợp với các màn hình đơn giản hoặc khi bạn muốn thử nhiều ý tưởng nhanh. Pro dùng Gemini Pro, cho ra giao diện chi tiết và phức tạp hơn nhưng tốn nhiều quota hơn. Với tài khoản miễn phí hiện tại, bạn có giới hạn 350 lượt tạo tiêu chuẩn và 50 lượt thử nghiệm mỗi tháng. Với người mới bắt đầu thì đây là mức dư dả để thử nghiệm thoải mái, tuy nhiên nếu dùng để làm dự án thực tế thì nên cân nhắc tiết kiệm quota pro cho các màn hình quan trọng. Bước 3: Export ra đâu? Sau khi có giao diện ưng ý, Stitch cho bạn bốn lựa chọn xuất file. Dán vào Figma: Stitch tạo sẵn đoạn code để bạn copy và paste trực tiếp vào Figma. Phù hợp nếu bạn đang làm việc trong nhóm có designer hoặc cần chỉnh sửa chi tiết hơn trong môi trường quen thuộc. Tải về dạng ZIP: Bạn nhận được toàn bộ file HTML, CSS và hình ảnh đóng gói sẵn, có thể mở trực tiếp trên máy hoặc đưa vào bất kỳ môi trường phát triển nào. Export qua MCP sang Antigravity: Đây là cách tốt nhất nếu bạn muốn đi từ thiết kế đến sản phẩm chạy thực sự. Antigravity cùng hệ sinh thái Google nên hoàn toàn có thể kết nối được với Stitch qua MCP mà không phải cài đặt gì nhiều từ đó AI agent sẽ đọc trực tiếp toàn bộ thiết kế và tự sinh ra code React hoặc Flutter hoàn chỉnh mà không cần bạn copy-paste bất kỳ file nào. Mình sẽ có bài hướng dẫn chi tiết về luồng kết nối này sau. Copy prompt cho AI agent: Google Stitch đã hỗ trợ MCP cho nên bất cứ nền tảng nào hỗ trợ MCP đều có thể tải chi tiết mô tả thiết kế của Google Stitch ví dụ như Claude Code, ChatGPT, Grok. Google Stitch design làm tốt gì và chưa tốt gì? Điểm mạnh rõ nhất là tốc độ và độ hoàn thiện của output. Một màn hình phức tạp với nhiều component có thể ra đời trong 30 đến 60 giây, với HTML và CSS sạch, có thể dùng được ngay. Khả năng giữ nhất quán màu sắc, font chữ và spacing trong cùng một dự án cũng khá tốt, giúp các màn hình trông như thuộc về cùng một hệ thống thiết kế. Tuy nhiên có một vài điểm cần lưu ý thực tế. Layout đôi khi bị lệch hoặc các component chồng lên nhau, đặc biệt với các màn hình có nhiều tầng thông tin, vì vậy bạn nên kiểm tra kỹ trước khi đưa vào production. Code đầu ra là HTML thuần và Tailwind CSS, không phải React component hay Vue, nên nếu dự án của bạn dùng framework cụ thể thì sẽ cần thêm bước chuyển đổi trừ khi bạn dùng Antigravity để làm bước đó tự động. Ngoài ra tính năng upload ảnh để đưa vào thiết kế vẫn còn khá giới hạn so với Figma. Bắt đầu với Google Stitch từ đâu ? Đừng cố thiết kế toàn bộ app trong một lần thay vào đó hãy bắt đầu với một màn hình đơn giản nhất trong ý tưởng của bạn — trang đăng nhập, trang chủ, hoặc một màn hình chi tiết sản phẩm. Viết prompt mô tả chi tiết như đã hướng dẫn ở trên, chạy thử cả Flash và Pro để so sánh, rồi chỉnh sửa bằng cách tiếp tục chat với AI trong cùng giao diện Stitch. Khi bạn đã có một màn hình ưng ý, đó là lúc tốt nhất để thử luồng export sang các nền tảng AI agent khác để có thể tự biến thiết kế đó thành hiện thực. Toàn bộ quy trình từ prompt đến sản phẩm demo có thể hoàn thành trong khoảng 3 đến 4 tiếng nếu đã quen thuộc, tất nhiên sau đó công chỉnh sửa sau đó sẽ rất mất thời gian nhưng vẫn tốt hơn nhiều so với cách làm truyền thống đúng không.

Khi Gemini 3 Pro còn chưa nguội thì Google đã liên tục làm nóng thị trường AI bằng Gemini 3.1 Pro, đánh dấu bản cập nhật đầu tiên trong hệ thống Gemini 3. Được xây dựng dựa trên nền tảng của Gemini 3 Pro (ra mắt tháng 11/2025), phiên bản 3.1 Pro không chỉ là một bản nâng cấp nhẹ khi tích hợp các kỹ thuật suy luận Deep Think và tiếp tục cuộc đua với các ông lớn khác khi mà Claude Opus 4.6, Claude 4.6 Sonnet cứ ra mắt liên tục.Trên bảng điểm benchmark Gemini 3.1 Pro đứng ở đâu?Như thường lệ Gemini 3.1 Pro lại tiếp tục càn quét nhiều bảng xếp hạng. Sức mạnh của nó không thể nào xem thường được và vẫn tiếp tục đứng đầu:ARC-AGI-2 (Suy luận trừu tượng): Đạt 77,1%, cao hơn gấp đôi so với 31,1% của Gemini 3 Pro. Con số này vượt xa các đối thủ hàng đầu như Claude Opus 4.6 (68,8%) và GPT-5.2 (52,9%).GPQA Diamond (Khoa học cấp độ sau đại học): Đạt 94,3%, dẫn đầu thị trường AI hiện nay.SWE-bench Verified (Lập trình): Đạt 80,6%, chính thức thu hẹp khoảng cách và cạnh tranh trực tiếp với các mô hình chuyên mã nguồn của Anthropic.Khả năng đa phương thức: Dẫn đầu trên 13/16 bài kiểm tra benchmark mà Google đánh giá.Những cải tiến so với Gemini 3 như thế nàoTích hợp Deep Think nhưng tốc độ vượt trộiGemini 3.1 Pro đưa kỹ thuật suy luận Deep Think trực tiếp vào mô hình tiêu chuẩn. Điều này cho phép người dùng nhận được khả năng suy luận mà không phải chịu độ trễ lớn như các phiên bản chuyên sâu trước đây.Tối ưu cho quy trình làm việc của Agent (Agentic Workflows)Mô hình mới được tinh chỉnh để thực hiện các tác vụ đa bước, sử dụng công cụ chính xác và có khả năng tự sửa lỗi tốt hơn. Google cũng ra mắt một endpoint chuyên dụng là gemini-3.1-pro-preview-customtools để tối ưu hóa việc gọi hàm (function calling) cho các nhà phát triển xây dựng agent.Sáng tạo với mã nguồn và hình ảnh độngGemini 3.1 Pro có khả năng dịch các chủ đề văn học thành mã chức năng, ví dụ như tạo website mang phong cách của một cuốn tiểu thuyết. Ngoài ra, nó có thể tạo các hình ảnh động svg trực tiếp từ văn bản, những tệp này cực kỳ nhẹ và sắc nét ở mọi quy mô vì được xây dựng bằng mã thay vì pixel truyền thống.Google cũng cho ra mắt luôn Veo 3.1 cùng với Gemini 3.1Cùng với sự ra mắt của Gemini 3.1 Pro, mô hình tạo video Veo 3.1 cũng được Google cho ra mắt luôn, đúng là sau tết các ông lớn đồng loạt nổ bom tấn, Veo 3.1 có thể cho phép:Tạo video chất lượng cao dài 8 giây kèm âm thanh.Hỗ trợ tạo video theo chiều dọc cho mạng xã hội.Cho phép tải lên nhiều ảnh tham chiếu để điều khiển nhân vật, đối tượng và phong cách của cảnh quay.Cách cách trải nghiệm Gemini 3.1 Pro như thế nàoNgười dùng có thể tiếp cận mô hình quyền năng này qua nhiều kênh khác nhau:Google Gemini: Truy cập Gemini hoặc ứng dụng di động, chọn chế độ "Pro" (giới hạn một số tin nhắn mỗi ngày cho bản miễn phí)là chúng ta có thể test ngay Gemini 3.1 ProĐặc biệt là giá API vẫn rất rẻ cho mọi người test với đầu vào: $2 / 1 triệu token (với prompt ≤ 200K) và đầu ra: $12 / 1 triệu token.