An

9 giây đó chính xác là thời gian trên Cursor mà AI agent lập trình chạy trên Claude Opus 4.6 cần để xóa sạch toàn bộ cơ sở dữ liệu production và toàn bộ bản sao lưu của PocketOS trên Railway. Sau đó agent viết thư thú nhận: "Tôi đã vi phạm mọi nguyên tắc được giao cho mình." Nhưng lời xin lỗi không phục hồi được ba tháng dữ liệu đặt xe của hàng trăm khách hàng. Chuyện gì xảy ra với PocketOS? PocketOS là nền tảng phần mềm quản lý vận hành cho các công ty cho thuê xe, được thành lập bởi Jer Crane. Khi Crane đang dùng Cursor chạy Claude Opus 4.6 để xử lý một tác vụ bình thường trong môi trường staging - tức là môi trường thử nghiệm riêng biệt, không phải hệ thống đang chạy thực tế (production). Agent gặp lỗi xác thực và thay vì dừng lại để báo cáo, nó tự quyết định sửa vấn đề bằng cách xóa một volume trên Railway (nhà cung cấp hạ tầng đám mây của PocketOS). Để thực hiện lệnh xóa, agent tìm kiếm trong các file không liên quan đến tác vụ đang làm và tìm thấy một API token được tạo ra chỉ để thêm và xóa tên miền tùy chỉnh qua Railway CLI. Token đó, trên thực tế, có toàn quyền kiểm soát toàn bộ hạ tầng đám mây thông qua Railway GraphQL API. Lệnh xóa không có bước xác nhận nào. Không có "gõ DELETE để xác nhận." Không có "volume này chứa dữ liệu production, bạn có chắc không?" Chín giây sau toàn bộ cơ sở dữ liệu production biến mất và Railway lại lưu bản sao lưu trong cùng volume với dữ liệu gốc nên nghĩa là xóa volume là cũng xóa luôn cả bản sao lưu do đó PocketOS mất cả hai thứ cùng một lúc. Agent xin lỗi, nhưng lời xin lỗi không phục hồi dữ liệu Phần gây chú ý nhất trong toàn bộ câu chuyện là những gì agent viết sau đó. Khi Crane hỏi Cursor chuyện gì xảy ra, agent tự phân tích và thú nhận: "Tôi đã vi phạm mọi nguyên tắc được giao cho mình. Tôi đoán thay vì xác minh. Tôi thực thi lệnh phá hủy mà không được yêu cầu. Tôi truy cập token từ file hoàn toàn không liên quan đến tác vụ của mình." Lời thú nhận đầy đủ, logic rõ ràng, không né tránh trách nhiệm. Nhưng lời thú nhận hoàn hảo đó không phục hồi được một bản ghi dữ liệu nào. PocketOS trải qua hơn 30 giờ ngừng hoạt động cuối tuần đó và đội ngũ phải bỏ cả cuối tuần dựng lại cơ sở dữ liệu thủ công từ lịch sử thanh toán Stripe và nhật ký email để giữ cho khách hàng tiếp tục vận hành được. Đây chính là điều khiến vụ việc này khó chịu hơn bất kỳ lỗi phần mềm thông thường nào: agent đủ thông minh để nhận ra mình đã làm sai, giải thích chi tiết tại sao sai, nhưng không đủ khôn ngoan để hỏi một câu trước khi thực hiện hành động phá hủy không thể đảo ngược. Ai chịu trách nhiệm ở đây Cursor, Claude hay Railway? Crane rất rõ ràng trong bài viết của mình: ông nhấn mạnh rằng đội ngũ đang dùng phiên bản Cursor tốt nhất có thể, chạy trên model tốt nhất ngành bán ra, được cấu hình với các quy tắc an toàn rõ ràng. Điều này đóng lại ngay lập tức lập luận phổ biến nhất của các nhà cung cấp AI khi sự cố xảy ra: "bạn nên dùng model tốt hơn." Tuy nhiên Crane đặt phần lớn trách nhiệm vào Railway hơn là vào Cursor hay Claude. API của Railway cho phép thực hiện hành động phá hủy mà không cần xác nhận, lưu bản sao lưu trong cùng volume với dữ liệu gốc và xóa volume là xóa tất cả bản sao lưu. Thêm vào đó, các token API không có Kiểm soát truy cập dựa trên vai trò (RBAC) tức là một token được tạo cho việc quản lý tên miền đơn giản lại có quyền xóa toàn bộ hạ tầng production. Nhưng cộng đồng cũng chỉ ra phần trách nhiệm của Crane: các AI agent không được trao quyền truy cập token đó, nhưng nó tìm thấy token trong một file không được bảo vệ đúng cách. Crane phản bác: "Tôi không trao quyền truy cập, nó tự tìm thấy." Điều đó đúng về mặt kỹ thuật nhưng không thay đổi được kết quả. Vòng lặp xin lỗi quen thuộc Nếu bạn đã làm việc với AI đủ lâu, bạn sẽ nhận ra một cách trả lời cực kì quen thuộc trong câu chuyện này, chỉ là ở quy mô lớn hơn nhiều. Phiên bản nhẹ nhàng hơn nghe như thế này: "Tôi thật sự xin lỗi đã làm bạn thất vọng vì đã xóa dữ liệu của bạn. Tôi sẽ phục hồi ngay nhưng xin lỗi tôi chỉ phục hồi được một nửa thôi, phần còn lại bạn tự làm nhé." Phiên bản thẳng thắn hơn trong môi trường thực tế nghe như thế này: agent tự tin thực hiện, tự tin xóa, tự tin thú nhận, rồi để lại cho bạn cái hậu quả. Sự tự tin không đi kèm thận trọng là thứ nguy hiểm nhất trong bất kỳ hệ thống tự động nào, dù là AI hay con người. Điều đáng nói là đây không phải lần đầu và sẽ không phải lần cuối. Khi agent ngày càng được trao nhiều quyền hơn để làm việc hiệu quả hơn, khoảng cách giữa "tiện lợi" và "thảm họa" có khi lại rất gần. Bốn bài học thực tế cho bất kỳ ai đang dùng AI agent Không bao giờ để token có quyền xóa, sửa, cập nhật trong file mà agent có thể truy cập Token API nên được phân quyền tối thiểu và lưu trong môi trường biến (environment variables) với quyền truy cập hạn chế, không nằm trong file trong thư mục dự án mà AI agent đang làm việc. Token quản lý tên miền không bao giờ nên có quyền xóa cơ sở dữ liệu. Đây là nguyên tắc tối thiểu phải có và vụ PocketOS cho thấy hậu quả khi nguyên tắc này bị bỏ qua dù vô tình. Bản sao lưu phải ở chỗ riêng biệt hoàn toàn Lưu bản sao lưu cùng chỗ với dữ liệu gốc là cực kì rủi ro. Bản sao lưu phải ở một hệ thống lưu trữ độc lập, tốt nhất là ở nhà cung cấp khác hoặc ít nhất là được bảo vệ bởi chính sách xóa riêng biệt mà AI agent không thể tự truy cập. Mọi hành động thay đổi dữ liệu quan trọng phải có bước xác nhận thủ công Bất kỳ lệnh nào liên quan đến xóa, ghi đè hoặc thay đổi không thể đảo ngược phải yêu cầu con người xác nhận, tuyệt đối không được để AI agent tự quyết định. Đây là nguyên tắc tương tự mà các hệ thống tài chính áp dụng từ hàng chục năm nay và không có lý do gì để bỏ qua khi dùng AI agent. Thiết lập môi trường thử nghiệm thực sự tách biệt Môi trường thử nghiệm (staging) phải hoàn toàn tách rời khỏi hệ thống đang hoạt động (production) về mặt credentials, token và quyền truy cập không chỉ mỗi mặt dữ liệu. Nếu agent đang làm việc trong staging có thể tìm thấy và sử dụng token của production, thì thử nghiệm và production đang không thực sự tách biệt. Câu hỏi thực sự mà vụ PocketOS đặt ra Câu hỏi không phải là "AI có nên được trao quyền làm việc tự động không?" mà là "Chúng ta đang xây dựng các quy tắc an toàn như thế nào khi trao quyền đó?" Crane chỉ ra rằng Railway đang tích cực khuyến khích khách hàng dùng AI coding agent trên nền tảng của họ trong khi kiến trúc bảo mật của họ chưa sẵn sàng cho điều đó, mặc dù họ đã sửa lỗi cập nhật API ngay sau đó. Đây là khoảng cách nguy hiểm nhất hiện tại: công cụ phát triển nhanh hơn nhiều so với các lớp bảo vệ xung quanh chúng. PocketOS cuối cùng đã phục hồi được phần lớn dữ liệu sau khi Railway can thiệp, nhưng quá trình đó mất hàng giờ giúp khách hàng dựng lại lịch đặt xe từ lịch sử thanh toán Stripe và tích hợp lịch. Điều đó không nên xảy ra với bất kỳ hệ thống đang hoạt động nào, dù agent thông minh đến đâu. Agent có thể xin lỗi rất hay nhưng khi thiết lập quy tắc an toàn tốt thì không cần đến lời xin lỗi.

Anthropic đã cho ra mắt Claude Opus 4.7 với hàng loạt cải tiến thực chất nhưng có một cảnh báo mà Anthropic ghi thẳng vào tài liệu migration: tokenizer mới có thể tạo ra nhiều hơn 1.0–1.35 lần token so với cùng nội dung đó trên Claude Opus 4.6, và model suy nghĩ nhiều hơn ở các mức effort cao. Nếu bạn đang dùng API và chưa đọc kỹ điều này trước khi nâng cấp, hóa đơn tháng tới sẽ là bài học đắt giá nhất bạn nhận được từ AI. Opus 4.7 cải thiện gì so với 4.6? Các con số thực tế từ tester Anthropic cho phép nhiều công ty tiếp cận sớm và thu thập phản hồi trước khi phát hành. Đây không phải marketing một chiều — các công ty ghi lại kết quả đo lường cụ thể Cursor: Opus 4.7 đạt 70% trên CursorBench, tăng đáng kể so với 58% của Opus 4.6 — một bước nhảy hiếm thấy giữa hai phiên bản liên tiếp. Notion: Tăng 14% so với Opus 4.6 trong các workflow nhiều bước, đồng thời tiêu ít token hơn và chỉ còn 1/3 số lỗi tool. Đây là trường hợp hiếm gặp khi model mới tốt hơn đồng thời trên cả ba chiều: chất lượng, chi phí và độ ổn định. XBOW: Benchmark visual acuity tăng từ 54.5% lên 98.5% — gần như tăng gấp đôi. Đây là cải thiện lớn nhất được ghi nhận và là lý do XBOW có thể mở rộng sang cả lớp công việc computer-use mà trước đây không thể dùng Opus. Rakuten: Giải quyết được gấp 3 lần số task production so với Opus 4.6 trên benchmark riêng của họ. Tuy nhiên những con số này đến từ các công ty đã được chọn để test sớm và có động lực công bố kết quả tốt. Benchmark nội bộ của từng công ty không thể so sánh trực tiếp với nhau và chưa chắc phản ánh đúng workflow của bạn. Ba thay đổi hành vi đáng chú ý nhất Tuân thủ hướng dẫn theo nghĩa đen — cả tốt lẫn xấu. Anthropic ghi rõ trong tài liệu phát hành: Opus 4.7 thực thi hướng dẫn chính xác hơn đến mức "các prompt viết cho model cũ có thể tạo ra kết quả ngoài mong đợi vì chỗ nào model cũ bỏ qua hoặc diễn giải linh hoạt thì Opus 4.7 làm đúng nghĩa đen". Với developer, điều này có nghĩa là nếu system prompt của bạn có rule mơ hồ hay mâu thuẫn, Opus 4.7 sẽ đề cập ngay thay vì tự giải quyết trong im lặng như trước. Đây là cải thiện về độ tin cậy, nhưng đòi hỏi bạn phải xem lại lại toàn bộ prompt trước khi deploy. Ví dụ từ Vercel: "Opus 4.7 thậm chí tự viết proof cho systems code trước khi bắt đầu làm — đây là hành vi mới chưa thấy ở các Claude trước." Model không chỉ làm việc theo yêu cầu mà tự thêm bước xác nhận đầu ra trước khi báo cáo kết quả. Ít nịnh bợ và phản hồi sáo rỗng hơn. Hex đã xác nhận: "Nó báo cáo đúng khi dữ liệu bị thiếu thay vì đưa ra câu trả lời nghe có vẻ đúng nhưng thực ra là bịa." thực sự mình đã thử thật sự là không hề thấy xuất hiện những câu nịnh bợ sáo rỗng như “bạn thật tuyệt vời” hoặc “bạn thực sự hơn 95% người trên thế giới này” và thiếu thông tin chắc chắn nó sẽ hỏi lại bạn, vậy là Opus 4.7 có vẻ cải thiện đáng kể điểm này trong khi Opus 4.6 nhiều lúc vẫn bị những câu nịnh bợ hoặc bịa ra thông tin không chính xác, điều này giúp cho nó hoàn toàn có thể trở thành đồng nghiệp mới của mình giống như Replit mô tả: "Nó phản bác trong các cuộc thảo luận kỹ thuật để giúp tôi đưa ra quyết định tốt hơn. Thực sự cảm giác như một đồng nghiệp tốt hơn." Xử lý hình ảnh độ phân giải cao gấp 3 lần. Opus 4.7 chấp nhận ảnh lên đến 2.576 pixel trên cạnh dài (khoảng 3.75 megapixel), tăng hơn 3 lần so với các model Claude trước. Điều này không phải là tham số API mà là thay đổi ở cấp độ model, nghĩa là ảnh bạn gửi lên sẽ tự động được xử lý ở độ phân giải cao hơn so với trước đây. Điều này có nghĩa là Opus 4.7 có thể phân tích tài liệu có biểu đồ nhỏ, đọc code từ screenshot, hay computer-use với màn hình độ phân giải cao hơn so với các model trước. Ví dụ mình đã thử với file pdf nhiều trang và có những chữ kí nhỏ thì Opus 4.7 hoàn toàn có thể nhận diện được chính xác những chữ kí nhỏ này, rồi sau đó là sử dụng chrome để nhận diện các kí tự nhỏ ở web thì nó có thể nhận diện chính xác hơn. Tuy nhiên điều này tốn token cực kì có thể khoảng 3 hoặc 4 lần chat là hết quota ngay lập tức vì vậy mọi người có thể cân nhắc giảm kích thước ảnh trước khi gửi nếu không cần độ chi tiết cao. Vấn đề token vẫn là thứ đáng lo nhất với người dùng Tokenizer mới tạo ra nhiều token hơn từ cùng nội dung Anthropic thừa nhận thẳng thắn trong migration guide: Opus 4.7 dùng tokenizer mới được cải tiến, nhưng trade-off là cùng một đoạn text có thể tạo ra nhiều hơn 1.0–1.35 lần token so với Opus 4.6. Hệ số 1.35 nghe có vẻ nhỏ nhưng trên quy mô production thì không phải vậy — nếu hệ thống của bạn đang tiêu 10 triệu token mỗi ngày với Opus 4.6, sau khi nâng cấp bạn có thể tiêu 13.5 triệu token mà không thay đổi gì về nội dung hay workflow. Vì vậy những ai chỉ chạy bản Pro thì có vẻ quota sẽ hoàn toàn không đủ có lẽ Anthropic đang ép người dùng phải nâng cấp lên Max để làm việc. Kết hợp với việc model suy nghĩ nhiều hơn ở các mức effort cao (đặc biệt ở `xhigh` — effort level mới được thêm vào giữa `high` và `max`), và mặc định Claude Code đã nâng lên `xhigh` cho tất cả các plan vì vậy người dùng API cần đo lường thực tế trên traffic thật trước khi nâng cấp toàn bộ, không nên dựa vào ước tính lý thuyết. Task budgets là công cụ kiểm soát mới cho API Song song với Opus 4.7, Anthropic ra mắt tính năng task budgets (public beta) trên Claude Platform, cho phép người dùng đặt giới hạn token cho từng task thay vì toàn bộ session. Đây là phản hồi trực tiếp với vấn đề nhiều pipeline bị "cháy" quota vì agent chạy quá lâu trên các task phức tạp mà không có cơ chế dừng. Với Opus 4.7 suy nghĩ nhiều hơn, task budgets sẽ trở thành công cụ cần thiết để kiểm soát chi phí thay vì tùy chọn. Nhìn nhận lại Claude Opus 4.7 Trong khi cộng đồng đang bàn về Opus 4.7 với khả năng đốt token khủng khiếp hay việc Opus 4.6 đang gặp lỗi. Đặc biệt với người dùng API đang vận hành workflow thì sự ổn định thường quan trọng hơn khả năng benchmark đi kèm thêm chi phí phải được tối ưu và không có bất ngờ nào vượt quá tầm kiểm soát. Cho nên đừng nói đến việc nâng cấp Opus 4.7 ngay lập tức vì một model mới tốt hơn nhưng thỉnh thoảng đầu ra không nhất quán thực sự quá khó để kiểm soát so với các model cũ đã được kiểm chứng. Nếu bạn đang cân nhắc nên dùng model nào trong tháng tới, đây là hướng dẫn thực tế: thử Opus 4.7 trên 10–20% traffic với task budgets bật lên, đo lường chi phí token thực tế so và chỉ chuyển toàn bộ sau khi có đủ dữ liệu. Đừng để điểm số hoặc những bài test ban đầu quyết định thay trong công việc lựa chọn của bạn. Có một điều cũng đáng lưu ý: Opus 4.7 nên để ở 200k token thay vì đẩy lên 1 triệu token ngay vì ở context window lớn, model suy nghĩ nhiều hơn ở mỗi lượt sau và token tích lũy nhanh hơn bạn nghĩ — đặc biệt trong các agentic workflow nhiều lượt thực hiện, khi đó chi phí đi kèm sẽ tăng lên cấp số nhân nên bạn phải rất cẩn thận.

Trên Reddit, Hacker News và GitHub của Anthropic, hàng trăm developer đang báo cáo cùng một vấn đề: Claude Opus 4.6và Sonnet 4.6 hoạt động tệ hơn hẳn trong công việc thực tế so với thời điểm ra mắt. Một người dùng trên GitHub ghi lại điểm hiệu suất của mình giảm từ 92/100 xuống còn 38/100 khi dùng với Opus 4.6. Câu hỏi là đây là do kinh doanh vẫn đang thua lỗ hay sự cố kỹ thuật của Anthropic hoặc là câu chuyện phức tạp hơn thế? Những gì cộng đồng đang báo cáo về Claude Opus 4.6 Các phàn nàn có tài liệu rõ ràng nhất Phần lớn các phàn nàn đáng tin cậy nhất có thể đến từ mạng xã hội nhưng mà khi nó đến từ chính repository GitHub của Anthropic - nơi developer báo cáo bug với Claude Code thì thực sự là vấn đề. Đây là những người dùng chuyên nghiệp có quy trình được đo lường, không phải cảm nhận chủ quan. Một developer báo cáo pipeline tự động hóa production đang chạy ổn định hơn 2 tuần bỗng dưng cho ra kết quả rối loạn vào ngày 6/3 với cùng model Opus 4.6. Theo người này, khi yêu cầu model tự đánh giá chất lượng cuộc hội thoại, khi nó liên tục tự chấm điểm với Sonnet 4 hoàn toàn không phải Opus 4.6. Nói cách khác, Opus 4.6 cũng đang nhận ra chính mình đang hoạt động dưới mức kỳ vọng. (Nguồn: GitHub Issue #31480 — Anthropic/claude-code) Một báo cáo khác ghi lại cụ thể hơn với ví dụ thực tế: yêu cầu Opus 4.6 tạo 3 email theo mẫu cho 3 công ty bảo hiểm, kết quả nhận được chỉ là 1 email. Khi nhắc lại, model tạo đủ 3, nhưng khi người dùng chỉnh sửa một chi tiết nhỏ, model lại quay về tạo 1 email. Vòng lặp này lặp đi lặp lại mà không có logic nhất quán nào — người báo cáo ghi lại điểm hiệu suất của mình giảm từ 92/100 xuống còn 38/100 sau khi chuyển sang Opus 4.6. (Nguồn: GitHub Issue #24991 — Anthropic/claude-code) Ngoài hai báo cáo trên, một thread tổng hợp trên Hacker News ghi nhận nhiều developer độc lập xác nhận tình trạng tương tự và cho biết họ quay lại dùng Claude 4.5 trong khi chờ Anthropic lên tiếng. (Nguồn: Hacker News thread) So sánh thực tế giữa Opus 4.6 khi ra mắt và thời gian gần đây Dưới đây là một số ví dụ cụ thể từ cộng đồng và cả mình cũng đã kịp thời so sánh hành vi của hai phiên bản : Ví dụ 1 — Tuân thủ chỉ dẫn: Prompt: "Viết email cho khách hàng. KHÔNG bao giờ đề cập đến giá trong email này." Opus 4.6 trươc đây: Tuân thủ đúng, không có bất kỳ đề cập nào đến giá. Opus 4.6 (sau một số thời điểm trong tháng 3/2026): Đề cập đến "gói giá phù hợp" trong đoạn thứ hai dù có rule "NEVER" rõ ràng. Ví dụ 2 — Đọc file tham chiếu: Prompt yêu cầu đọc một style guide file và áp dụng vào output. Opus 4.6 trước đây: Khả năng đọc file thực sự khá đúng ý và, áp dụng đúng phong cách quy định. Opus 4.6 (cùng thời điểm báo cáo trên): Bỏ qua việc đọc file trong khi tự tạo format khác hoàn toàn. Ví dụ 3 — Xử lý task nhiều phần: Prompt: "Tạo 3 kịch bản cho 3 tình huống khác nhau." Sonnet 4.6 trước đây: Tạo đủ 3 kịch bản trong một lần, có cấu trúc rõ ràng. Opus 4.6 (theo báo cáo tháng 2/2026): Tạo 1 kịch bản, khi nhắc tạo tiếp thì quên mất 2 kịch bản trước, loop không kết thúc. Quay về Opus 4.5 có phải cách xử lý tốt nhất? Quay về Opus 4.5 mặc dù Opus 4.6 vẫn còn khá tốt Rất nhiều người đã chỉ cách để tạm thời xử lý vấn đề này đó là quay về Opus 4.5 tuy nhiên nếu chỉ nhìn vào benchmark chính thức Opus 4.6 trên cơ Opus 4.5 ở hầu hết mọi tiêu chí quan trọng đặc biệt với những người cần context dài thì Opus 4.5 hiện chỉ có 200k context hoàn toàn không thể so sánh với khả năng mở rộng lên 1M context của Opus 4.6. Cón nếu về điểm thì trên BrowseComp — benchmark đánh giá khả năng nghiên cứu web nhiều bước Opus 4.6 đạt 84.0% trong khi Opus 4.5 chỉ đạt 67.8%, tức cải thiện 16.2 điểm phần trăm. Trên SWE-bench Verified đánh giá coding thực tế, Sonnet 4.6 đạt 79.6% so với 77.2% của Sonnet 4.5. ARC-AGI 2 — bài kiểm tra khả năng giải quyết vấn đề mới Opus 4.6 gần như tăng gấp đôi điểm số so với 4.5. Tuy nhiên có một điểm thú vị: trên benchmark SWE-Bench Multi-Agent đo khả năng phối hợp nhiều công cụ cùng lúc Opus 4.5 lại đạt 62.3% trong khi Opus 4.6 chỉ đạt 59.5%- một sự sụt giảm nhỏ nhưng có thực có vẻ đây đúng là kịch bản nhiều người sử dụng đang phàn nàn nhất. Nguyên nhân chủ quan và khách quan của trải nghiệm tệ của Opus 4.6? Đây là phần quan trọng nhất để hiểu đúng vấn đề. Có ít nhất ba nguyên nhân khác nhau dẫn đến cùng một triệu chứng "model hoạt động tệ hơn": Sự cố kỹ thuật tạm thời: Anthropic đã xác nhận nhiều incident chính thức trên status page của mình, bao gồm "Elevated errors on Claude Opus 4.6" vào ngày 28/2/2026, một incident tương tự vào 31/3/2026, và "Opus 4.6 and Sonnet 4.6 error rate elevated" cùng ngày. Đây không phải phàn nàn chủ quan — đây là sự cố kỹ thuật được ghi nhận chính thức, và nhiều báo cáo "regression" xảy ra đúng trong các khoảng thời gian này. Thay đổi hành vi mặc định: Opus 4.6 được thiết kế để suy nghĩ nhiều hơn theo mặc định thông qua "adaptive thinking" — tức là nó tự quyết định khi nào cần reasoning sâu và khi nào không. Điều này làm cho nó chậm hơn và đôi khi cảm thấy nặng nề hơn trên các task đơn giản, khiến người dùng quen với 4.5 cảm thấy như model đang "overthink" thay vì thực hiện nhanh. Anthropic vẫn hướng đến lợi nhuận: (Đây là nhận định cá nhân) Có vẻ như Anthropic vẫn là hướng đến lợi nhuận là mục đích lớn nhất khi có thể họ điều chỉnh để giảm năng lực tính toán của Opus 4.6 xuống để giảm bớt gánh nặng chi phí như OpenAI đã phải đóng cửa Sora để giảm bớt gánh nặng chi phí thì mọi người ai cũng biết điều đó. Vậy mọi người có đang đề cập giải pháp khác không? Đầu tiên là chuyển sang Codex Dựa vào những thứ Opus đã để thể hiện từ trước cho thấy Opus 4.6 hiện là lỗi tạm thời nhưng điều này vô tình khiến cho Codex của OpenAI hưởng lợi quá nhiều khi mọi người đổ xô sang Codex với GPT-5.3 Codex . Codex hiện cũng đang cho quota thoải mái hơn bên Claude Code, nhưng thật sự điều này mình nghĩ sẽ đe dọa được Anthropic nhiều lắm, khi mà trải nghiệm của mình với Opus 4.6 trên cả Antigravity và Claude Code tốt hơn nhiều so với Codex. Đó là khi mình chỉ cần sửa 1 file thì Opus 4.6 làm đúng và chuẩn nhưng với Codex thì nó chỉnh cả file khác nữa làm rối tung cả web của mình lên, điều đó khiến mình thật sự khó chịu. Chỉnh sửa sâu trong file cài đặt Một người nào đó đã chỉ cách chỉnh sửa Claude Code để có thể giải quyết phần suy nghĩ của Claude Opus 4.6 với chỉnh sửa file ~/.claude/settings.json ai đã làm thử thì xin bình luận trải nghiệm để mọi người biết. Điều này có phải tiêu chuẩn ngành không? Có. OpenAI, Google và Anthropic đều có lịch sử phát hành model mới có benchmark tốt hơn nhưng gây ra phàn nàn về trải nghiệm thực tế — thường vì optimization cho một tập benchmark không phản ánh đủ đa dạng workflow thực tế. Đây là lý do tại sao các công ty lớn thường không nâng cấp model ngay khi có phiên bản mới mà test kỹ trên workload cụ thể của mình trước. Nếu bạn đang dùng Claude Opus 4.6 cho workflow nghiên cứu, computer use hay các task reasoning dài hạn thì cách tốt nhất đến thời điểm hiện tại vẫn là về lại với Opus 4.5 để có thể tiếp tục công việc mà không bị gián đoạn .

Boris Cherny — kỹ sư đứng sau Claude Code — không thích giải thích công cụ mình làm ra bằng slide mà anh ấy chia sẻ 13 tip thực chiến từ cách chính đội Anthropic đang dùng nó mỗi ngày. Dưới đây là 7 nguyên tắc cốt lõi mình đã đúc rút ra từ đó và điểm chung của tất cả là anh ấy không dùng Claude Code như một chatbot viết code hộ mà dùng như workflow thông minh, điều này anh ấy chia sẻ từ nhiều tháng trước có thể một số thứ cũ những vẫn còn rất nhiều điều để học hỏi từ những con người tài năng này. Nhân bản bản thân bằng cách chạy nhiều session song song Claude Code tất nhiên không hề được thiết kế để dùng chỉ một tab duy nhất. Boris chạy 5 tab terminal cùng lúc, kết hợp 5–10 session trên claude.ai/code và cả ứng dụng di động trong đó mỗi session xử lý đúng một nhiệm vụ độc lập. Lý do thực tế: nếu nhét quá nhiều việc vào một context, Claude bắt đầu xung đột ưu tiên và chất lượng đầu ra giảm rõ rệt. Thay vào đó: Dùng tính năng hand-off (&) để chuyển task giữa terminal và web. "Teleport" context từ máy tính sang điện thoại khi cần tiếp tục công việc lúc di chuyển. Đây là tính năng đã ra mắt từ lâu Một session là một nhiệm vụ là nguyên tắc sống còn khi dùng Claude Code để tránh việc bị tràn context. Chọn model mạnh nhất và luôn bắt đầu bằng Plan Mode Boris dùng Claude Opus 4.5 (do thời điểm tháng 1/2026 thì Opus 4.6 chưa ra mắt) kết hợp Thinking cho hầu hết công việc nghiêm túc. Trước khi để Claude tự chạy code, ông gần như luôn bắt đầu bằng Plan Mode — nhấn Shift + Tab hai lần. Plan Mode buộc Claude lập kế hoạch thành văn bản trước khi thực thi và đây là lúc phát hiện vấn đề sớm nhất với chi phí sửa thấp nhất. Theo Boris: "A good plan is really important." để Claude code có bước lập kế hoạch là cực kì quan trọng giống như để thợ xây đổ móng mà chưa có bản vẽ. Xây CLAUDE.md như một bộ nhớ chung của cả nhóm CLAUDE.md là file duy nhất toàn team check vào git, chứa mọi quy ước, context và bài học tích lũy. Nguyên tắc vận hành: Mỗi lần Claude làm sai ví dụ như sai convention, sai luồng xử lý, sai cấu trúc thư mục thì bắt Claude không chỉ sửa lần đó mà thêm ngay vào CLAUDE.md để lần sau nó không lặp lại. Trong code review, tag @.claude để bổ sung context trực tiếp từ PR vào file này. Boris gọi đây là "compounding engineering": hệ thống không đứng yên, nó cải thiện mỗi ngày theo từng lỗi được ghi nhận. Sau 3 tháng dùng nghiêm túc, CLAUDE.md của một team thực sự trở thành tài sản kỹ thuật — không phải chỉ là file config. Tự động hóa mọi việc lặp lại bằng Slash commands và Subagents Bất kỳ thứ gì bạn gõ hơn 3 lần trong ngày thì nên thành Slash command. Đặt chúng trong .claude/commands/. Ví dụ: /commit-push-pr — gom toàn bộ luồng commit, push và tạo PR thành một lệnh duy nhất. Với các bước chuẩn trong quy trình PR, Boris dùng Subagents như code-simplifier hay verify-app để xử lý tự động mà không cần can thiệp thủ công. Kết quả là thời gian từ "code xong" đến "PR sẵn sàng review" rút ngắn đáng kể và ít lỗi do bỏ sót bước hơn. Dùng Hooks và Permissions để hệ thống tự vận hành Ba cơ chế quan trọng Boris cấu hình Claude Code: PostToolUse hook — tự động format code sau mỗi lần Claude dùng tool. Bạn không cần nhớ chạy linter thủ công nữa. /permissions — khai báo trước các lệnh bash an toàn để Claude không hỏi xác nhận mỗi lần. Boris không khuyến khích dùng --dangerously-skip-permissions vì nó bỏ qua kiểm soát mà không có lý do thực sự tốt. Agent Stop hook hoặc plugin ralph-wiggum — với task chạy nền dài, hook này cho phép Claude tự xác minh kết quả khi hoàn thành mà không cần bạn ngồi chờ. Thay vì canh một session 20 phút, bạn để nó tự báo cáo khi xong. Kết nối Claude với toàn bộ công cụ của team Claude Code không phải công cụ hoạt động riêng lẻ. Boris cấu hình để Claude có quyền dùng Slack (qua MCP), BigQuery, Sentry, terminal và bất kỳ công cụ nào team đang dùng tất nhiên tất cả cấu hình MCP và các quyền chia sẻ chung để mọi người trong team có cùng môi trường. Thực tế, khi Claude có thể query trực tiếp Sentry để lấy stacktrace và đồng thời xem BigQuery để hiểu data pattern, chất lượng debug khác hẳn so với dán dữ liệu thủ công vào chat. Tạo vòng lặp kiểm tra là bước quan trọng nhất Boris nhấn mạnh đây là "có lẽ là điều quan trọng nhất" trong toàn bộ 13 tip. Ý tưởng cốt lõi: thay vì bạn ngồi kiểm tra đầu ra của Claude, hãy cho Claude cách tự kiểm tra. Vòng lặp kiểm tra có thể là: Một extension trình duyệt web tự chụp màn hình và so sánh UI. Một bộ test chạy sau mỗi thay đổi. Một bash script kiểm tra endpoint. Một simulator tái hiện luồng người dùng. Khi vòng lặp feedback hoạt động tốt, Claude biết ngay đầu ra của mình đúng hay sai mà không cần bạn làm trọng tài. Có thể từ đây chất lượng đầu ra tăng 2–3 lần không phải vì model tốt hơn mà vì Claude có thông tin để tự điều chỉnh. Bài học từ cách Boris dùng Claude Code Nhìn lại 7 nguyên tắc, điểm chung không phải là "dùng tính năng này, bật tính năng kia"mà là tư duy sử dụng Claude Code như một agent có context, có công cụ, có cách tự kiểm tra kết quả và có bộ nhớ tích lũy theo thời gian. Nếu bạn đang dùng một tab duy nhất và gõ prompt rồi chờ — bạn đang dùng khoảng 10% năng lực của công cụ này. Bước thực tế ngay hôm nay: tạo file CLAUDE.md trong dự án đang làm, ghi vào đó một quy ước hoặc một lỗi Claude vừa mắc. Đó là điểm khởi đầu của một hệ thống tích lũy, và nó bắt đầu từ một dòng đầu tiên. Còn nếu muốn tham khảo 13 tip của Boris thì bạn có thể tham khảo bài viết thực tế ở đây https://x.com/bcherny/status/2007179832300581177

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ế.

Bạn đã dùng NotebookLM để lưu tài liệu, nghiên cứu và ghi chú tuy nhiên mỗi lần cần AI xử lý thêm thì lại phải mở Gemini, copy-paste thủ công rồi hy vọng AI không bịa số liệu không chính xác. Giờ đây sau khi khám phá ra thì mình có thể xóa bỏ hoàn toàn bước thừa đó khi mà NotebookLM giờ có thể kết nối trực tiếp vào Gemini, biến toàn bộ tài liệu thành bộ não cho AI xử lý tức thì. NotebookLM và Gemini đã từng như hai ốc đảo NotebookLM rất giỏi một việc bám chặt vào tài liệu bạn cung cấp và trả lời chính xác dựa trên đó. Ví dụ như bạn có thể upload báo cáo tài chính 200 trang có thể hỏi bất kỳ con số nào, NotebookLM trích dẫn đúng trang đúng đoạn. Tuy nhiên nó bị cô lập trong từng note riêng biệt và không thể tìm kiếm thông tin mới ngoài internet. Gemini thì ngược lại có tư duy linh hoạt, kết nối web thời gian thực, có sự sáng tạo nhưng lại cực kì dễ ảo giác khi làm việc với dữ liệu chuyên sâu mà không có nguồn rõ ràng. Kết quả là nếu người dùng biết đến 2 công cụ này đều phải dùng song song, chuyển dữ liệu qua lại thủ công vừa mất thời gian vừa dễ mắc lỗi. Tích hợp này giải quyết đúng vấn đề đó bằng cách đưa NotebookLM vào thẳng giao diện Gemini, để hai công cụ bổ trợ cho nhau thay vì hoạt động độc lập. Một vài điều cần biết trước khi kết nối Gemini và NotebookLM Vì cùng hệ sinh thái Google cho nên tích hợp Gemini và NotebookLM hoạt động rất mượt mà, nhưng có một vài điểm cần lưu ý để tránh kỳ vọng sai. Gemini ưu tiên dữ liệu từ notebook trước, nhưng khi notebook không đủ thông tin, nó sẽ tự động tìm kiếm web mà không cần bạn ra lệnh thêm. Điều này tiện lợi, nhưng cũng có nghĩa là bạn cần kiểm tra nguồn trích dẫn để biết câu trả lời đến từ tài liệu của bạn hay từ tìm kiếm web. Khả năng phân tích chéo nhiều notebook cùng lúc là điểm mạnh lớn mà NotebookLM đơn thuần chưa làm được. Với càng nhiều notebook được kết nối, Gemini càng có thể xử lý được sự khác nhau và nhiều góc của vấn đề hơn nhưng vẫn bám sát được toàn bộ ngữ cảnh. Ngoài ra mọi câu trả lời từ dữ liệu notebook đều có trích dẫn nguồn cụ thể, đây là điểm khác biệt quan trọng so với Gemini thông thường và giúp bạn kiểm chứng nhanh khi cần. Kết nối NotebookLM vào Gemini trong 4 bước Tính năng hiện đã có thể dùng được cho cả tài khoản miễn phí lẫn Google AI Pro, không cần cài thêm gì. Bạn thực hiện theo thứ tự sau. Đầu tiên, mở Gemini trên web hoặc ứng dụng di động và vào khung nhập liệu như bình thường. Tiếp theo, nhấp vào biểu tượng dấu "+" ở góc khung chat và chọn NotebookLM từ danh sách nguồn. Sau đó chọn một hoặc nhiều notebook bạn đã tạo sẵn để làm ngữ cảnh cho cuộc hội thoại. Cuối cùng, nhập prompt của bạn như bình thường, lưu ý rằng Gemini sẽ ưu tiên dữ liệu từ notebook trước, và chỉ tìm kiếm thêm trên web khi thông tin trong notebook chưa đủ. Toàn bộ quá trình thiết lập mất chưa đến 60 giây, và bạn có thể chuyển đổi giữa các notebook khác nhau ngay trong cùng một cuộc hội thoại. Notebook + Gemini có thể làm được những gì mà trước đây không làm được? Điểm thay đổi lớn nhất không phải là tốc độ mà là độ tin cậy của đầu ra. Khi Gemini có nguồn dữ liệu cụ thể từ notebook, mọi câu trả lời đều được gắn nhãn trích dẫn rõ ràng giúp bạn biết chính xác thông tin đó đến từ trang nào, tài liệu nào, thay vì phải tự đi kiểm chứng lại. Về mặt ứng dụng thực tế có 4 trường hợp mà sự kết hợp này tạo ra khác biệt rõ nhất. Nghiên cứu và tổng hợp tài liệuThay vì đọc hết một cuốn sách giáo khoa 500 trang, bạn upload vào NotebookLM rồi yêu cầu Gemini tóm tắt thành bộ sách hoặc cũng có thể là infographic hoặc bộ slide thuyết trình qua chế độ Canvas. Và đây là kết quả của mình với prompt thông thường tạo thành cuốn sách từ tất cả các notebook được chọn. Bạn có thể tham khảo ở link Gemini sau đây Viết content không lo ảo giác Đây là use case hữu ích nhất với người làm nội dung. NotebookLM đảm nhiệm phần "đúng" đó là giữ chặt số liệu, tên người, sự kiện từ tài liệu gốc. Gemini đảm nhiệm phần "hay" đó là viết văn, tạo hook, chọn góc độ hấp dẫn. Tuy nhiên kết quả vẫn chưa so được với Claude nhưng cũng là một tham khảo để đưa sang Claude viết lại thì bạn sẽ nhận được kết quả thật sự rất tốt. Gems tự cập nhật kiến thức Gems là các trợ lý AI tùy chỉnh trong Gemini. Khi bạn gắn notebook vào một Gem, điểm đặc biệt là notebook đồng bộ tự động khi bạn thêm tài liệu mới vào NotebookLM, Gem cập nhật ngay mà không cần thiết lập lại từ đầu. Ví dụ bạn có một Gem chuyên hỗ trợ khách hàng, mỗi khi chính sách công ty thay đổi bạn chỉ cần cập nhật notebook, Gem tự hiểu luôn. Audio Overview kết hợp tìm kiếm web NotebookLM đã có tính năng chuyển tài liệu thành podcast đối thoại khá hay. Khi kết hợp với Gemini, bạn có thể yêu cầu AI bổ sung thêm thông tin mới nhất từ web vào bản tóm tắt âm thanh đó, phù hợp để nghe khi di chuyển mà vẫn có đủ những tin tức cập nhật mới nhất. Bắt đầu từ đâu nếu bạn chưa quen dùng NotebookLM và Gemini? Nếu bạn chưa từng dùng NotebookLM, hãy bắt đầu bằng cách upload một tài liệu bạn hay phải tra cứu có thể là quy trình nội bộ công ty, giáo trình học, hoặc báo cáo ngành bạn đang theo dõi. Tạo notebook từ tài liệu đó, rồi mở Gemini và kết nối notebook đó vào. Thử đặt một vài câu hỏi mà trước đây bạn phải đọc cả tài liệu mới trả lời được. Khi AI trả lời đúng và trích dẫn rõ nguồn, bạn sẽ hiểu ngay tại sao sự kết hợp này đáng để dùng thường xuyên. Không phải vì nó "cách mạng" hay "đột phá" mà vì nó giải quyết đúng một việc phiền phức cụ thể mà bạn vẫn phải làm thủ công mỗi ngày.

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.

Wordpress.com vừa làm điều mà nhiều người chờ đợi 43% số website trên toàn cầu đang chạy trên Wordpress và giờ đây AI có thể tự mình quản lý tất cả chúng. Wordpress.com vừa chính thức cho phép AI agent truy cập, chỉnh sửa và xuất bản nội dung trực tiếp trên website của người dùng thông qua giao thức MCP. Đây chắc chắn phải là thay đổi cực lớn kể từ khi Wordpress đã mở MCP nhưng chỉ cho phép phân tích và báo cáo về website năm 2025. Trước đây để cập nhật, viết mới một bài viết, bạn phải dùng quá nhiều thao tac đăng nhập - tìm đúng bài- chỉnh sửa từng trường rồi nhấn lưu, hoặc nếu dùng AI thì phải kết nối qua các công cụ bên thứ ba phải cài đặt khá rắc rối. Giờ thì bạn chỉ cần nhắn cho AI một câu: "Cập nhật tiêu đề bài mới nhất thành X và thêm đoạn trích này vào." AI sẽ chỉnh sửa trực tiếp ở Wordpress và thực hiện hết phần còn lại mà không phải chuyển qua các nền tảng khác. MCP là gì và nó là thứ đứng sau toàn bộ kết nối? MCP viết tắt của Model Context Protocol là giao thức giúp AI nhìn thấy và tương tác với các ứng dụng bên ngoài. MCP được ông lớn Anthropic tạo ra và hậu thuẫn cho nên nó đã và đang trở thành chuẩn chung cho rất nhiều nhà phát triển AI cho nên mọi người rất yên tâm về sự lâu dài của nó. MCP khác với API ở chỗ nếu API là cái cổng để lập trình viên kết nối hai hệ thống với nhau thì MCP là cái cổng được thiết kế riêng cho AI, giúp mô hình ngôn ngữ hiểu được ngữ cảnh của từng ứng dụng thay vì chỉ nhận dữ liệu thô. WordPress.com đã triển khai MCP từ cuối năm ngoái và tính năng AI agent lần này được xây dựng hoàn toàn trên nền tảng đó. Điểm mạnh là bạn không bị gắn chặt với một AI cụ thể mà có thể kết nối Claude, ChatGPT, Cursor hoặc bất kỳ AI client nào hỗ trợ MCP với cùng một tài khoản WordPress.com. Để kích hoạt, chỉ cần truy cập wordpress.com/mcp và phải bật các tính năng MCP mong muốn rồi các AI như Claude, Gemini, ChatGPT mới có thể kết nối được vào MCP. AI agent làm được gì trên Wordpress Danh sách tính năng Wordpress hỗ trợ chắc chắn dài hơn bạn nghĩ khá nhiều đấy. Tất nhiên sau khi kết nối, bạn có thể ra lệnh bằng ngôn ngữ tự nhiên để thực hiện hầu hết mọi tính năng trong phần cập nhật MCP mới này. Quản lý nội dung: Bạn có thể yêu cầu AI tạo bài viết mới, chỉnh sửa tiêu đề hoặc thêm đoạn trích hoặc chuyển bản nháp sang trạng thái đã xuất bản và ngược lại. AI thậm chí có thể viết một bài blog theo phong cách thường thấy của bạn rồi lưu dưới dạng bản nháp chờ duyệt trước khi đăng chính thức. Quản lý bình luận: Bạn có thể duyệt các bình luận đang chờ xử lý, đánh dấu spam, xóa comment không phù hợp và thậm chí trả lời bình luận mới nhất trên một bài cụ thể, tất cả chỉ bằng một câu lệnh. Tổ chức nội dung: AI có thể tạo danh mục mới, thêm tag vào bài viết và sắp xếp lại cấu trúc phân loại nội dung mà không cần bạn phải mò mẫm qua từng menu trong dashboard. Cập nhật media: Sửa alt text cho ảnh vừa tải lên hoặc cập nhật chú thích theo tên ảnh là những việc nhỏ nhặt nhưng tốn thời gian nếu làm thủ công trên hàng chục bài viết, và AI xử lý điều này chỉ trong vài giây. Theo dõi và khám phá: Bạn có thể hỏi trang nào có lượng truy cập nhiều nhất hoặc đơn giản là yêu cầu tóm tắt các bình luận gần đây hoặc đề xuất 10 chủ đề bài viết tiếp theo dựa trên nội dung hiện có của blog. Dọn dẹp hàng loạt: Xóa tất cả bản nháp đã để quá một năm hoặc chuyển một loạt bài từ trạng thái này sang trạng thái khác là những việc mà trước đây cần plugin hoặc phải làm tay từng bài một. Cần lưu ý gì trước khi dùng AI cho Wordpress? Mặc dù nghe có vẻ tiện lợi, trao quyền cho AI chỉnh sửa trực tiếp website vẫn là việc cần suy nghĩ kỹ. Wordpress.com đã xây dựng một số rào chắn cơ bản đó là bài viết do AI tạo mặc định được lưu dưới dạng bản nháp và không tự xuất bản, trong khi mọi thay đổi đều được ghi lại trong Activity Log để bạn có thể kiểm tra lại bất cứ lúc nào. Tuy nhiên với một số tác vụ như xóa bài hàng loạt hay chuyển trạng thái bài viết lại không có cơ chế hoàn tác đơn giản, vì vậy bạn cần kiểm tra kĩ trước khi ra lệnh tất nhiên phải rõ ràng và có chủ đích. Về chất lượng nội dung, AI có thể viết bài theo phong cách của bạn dựa trên các bài cũ, nhưng "theo phong cách" không có nghĩa là đạt chất lượng tương đương. Bài nháp do AI tạo vẫn cần một lượt đọc lại của con người trước khi đăng, đặc biệt với những chủ đề chuyên sâu hoặc cần độ chính xác cao. Ngoài ra, tính năng xem danh sách người dùng và kiểm tra trạng thái plugin chỉ khả dụng cho tài khoản quản trị viên, đây là giới hạn hợp lý để tránh rủi ro bảo mật không đáng có. Bức tranh rộng hơn khi các nền tảng mở cửa cho AI agent Wordpress.com hiện ghi nhận 20 tỷ lượt xem trang và 409 triệu khách truy cập mỗi tháng. Khi nền tảng chiếm 43% web toàn cầu chính thức mở cửa cho AI agent, câu hỏi không còn là liệu AI có thay đổi cách nội dung được tạo ra không? mà là nội dung do AI tạo sẽ chiếm bao nhiêu phần trăm web trong 2 năm tới ?. Xu hướng này đang diễn ra đồng thời ở nhiều nơi như Meta mua lại Moltbook là mạng xã hội nơi AI agent có thể đăng bài và tương tác, trong khi Anthropic cũng thử nghiệm cho AI viết blog dưới sự giám sát của con người. Wordpress.com không phải người tiên phong về ý tưởng, nhưng họ là người đầu tiên triển khai nó ở quy mô đủ lớn để tạo ra tác động thực sự. Với người dùng phổ thông động thái của Wordpres giúp rào cản vận hành một website đang tiến gần về 0 và bạn không cần biết Wordpress hoạt động như thế nào mà chỉ cần biết mình muốn gì rồi nói ra điều đó. Tuy nhiên chính vì rào cản thấp, nội dung kém chất lượng cũng sẽ xuất hiện tràn lan và khả năng phân biệt nội dung đáng đọc sẽ ngày càng trở thành kỹ năng quan trọng của người dùng web. Nếu bạn đang dùng Wordpress.com, hãy thử truy cập Wordpress và bắt đầu sử dụng các skils viết bài của mình để kết nối tới Wordpress ngay.