Quay lại trang tin tức

Thảm họa 9 giây của PocketOS khi AI agent xóa sạch database công ty rồi xin lỗi

Xuất bản vào 6 tháng 05, 2026
Thảm họa 9 giây của PocketOS khi AI agent xóa sạch database công ty rồi xin lỗi

Tóm tắt nhanh

Một AI agent chạy trên Claude Opus đã vô tình xóa toàn bộ dữ liệu production và backup của PocketOS chỉ trong 9 giây do tự ý xử lý lỗi mà không xác nhận. Nguyên nhân đến từ việc token có quyền cao bị lộ trong môi trường agent có thể truy cập, cùng với kiến trúc bảo mật yếu từ phía hạ tầng. Dù agent có thể phân tích và xin lỗi rất rõ ràng, thiệt hại dữ liệu vẫn không thể phục hồi ngay lập tức. Sự cố cho thấy rủi ro lớn khi trao quyền quá mức cho AI mà thiếu kiểm soát an toàn. Các bài học quan trọng gồm: phân quyền token tối thiểu, tách biệt backup, yêu cầu xác nhận thủ công cho hành động nguy hiểm và đảm bảo staging không liên thông production. Đây là lời cảnh báo về khoảng cách giữa tốc độ phát triển AI và hệ thống bảo vệ đi kèm.

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.

Thảo luận (0)

Đăng nhập để tham gia thảo luận.

Chưa có bình luận nào. Hãy là người đầu tiên!

Các bài viết liên quan

Claude Project là gì? Cách dùng nó sao cho hiệu quả

Claude Memory đã mở miễn phí cho tất cả người dùng tức là Claude có thể tự động nhớ tên bạn, nghề nghiệp và một số sở thích từ các cuộc trò chuyện trước. Nghe có vẻ đủ dùng, nhưng nếu bạn đang làm 3 dự án song song với 3 bộ tài liệu, 3 phong cách viết và 3 yêu cầu khác nhau, khi đó context sẽ lớn dần lên thì memory sẽ không giúp được gì nhiều. Đó là lúc Project trở thành thứ bạn thực sự cần. Memory và Project khác nhau như thế nào? Claude Memory hoạt động như bộ nhớ cá nhân của Claude về bạn, nghĩa là nó ghi lại những thông tin chung xuyên suốt mọi cuộc trò chuyện: bạn là ai, bạn làm nghề gì, bạn thích phong cách giao tiếp nào. Đây là lớp nhận biết danh tính, không phải ngữ cảnh công việc. Project là lớp ngữ cảnh chuyên biệt cho từng dự án cụ thể. Bạn có thể có một Memory duy nhất về bản thân nhưng có 10 Project khác nhau, trong đó mỗi Project chứa tài liệu riêng, hướng dẫn riêng và lịch sử hội thoại riêng, hoàn toàn độc lập với nhau. Hình dung thế này: Memory giống như thẻ căn cước của bạn giúp Claude luôn biết bạn là ai. Project giống như từng hồ sơ công việc riêng biệt và khi bạn mở Project nào, Claude biết đúng bối cảnh của dự án đó, không bị lẫn sang dự án khác. Ví dụ thực tế: Memory giúp Claude biết bạn là nhân viên marketing cho web, nhưng Project "Website khách hàng A" chứa tài liệu marketing, brief dự án và các quyết định kỹ thuật cụ thể, đây là thứ Memory không bao giờ lưu được vì nó không thuộc về bạn mà thuộc về dự án đó. Project trong Claude là gì? Project là không gian làm việc riêng biệt trong Claude, nơi bạn có thể lưu trữ tài liệu, viết hướng dẫn tùy chỉnh và giữ lịch sử hội thoại theo từng chủ đề hoặc dự án cụ thể. Thay vì mỗi cuộc trò chuyện là một tờ giấy trắng, Project cho phép Claude luôn có sẵn ngữ cảnh về công việc bạn đang làm trước khi bạn gõ câu đầu tiên. Nếu Memory là thứ Claude biết về bạn, thì Project là thứ Claude biết về công việc cụ thể bạn đang làm, và sự kết hợp của cả hai mới tạo ra trải nghiệm AI thực sự hiểu bạn. Giới hạn theo gói dịch vụ Tài khoản miễn phí có thể tạo tối đa 5 Project. Gói trả phí (Pro, Max, Team, Enterprise) được tạo không giới hạn Project và có thêm tính năng RAG, tức là khi bạn tải lên nhiều tài liệu đến mức vượt giới hạn context window, Claude tự động chuyển sang chế độ tìm kiếm thông minh để mở rộng dung lượng lên 10 lần mà không mất chất lượng phản hồi. Tài khoản Team và Enterprise có thêm tính năng chia sẻ Project và phân quyền thành viên. Cách thiết lập Project để Claude hiểu bạn hơn Bước 1: Viết hướng dẫn tùy chỉnh Đây là phần quan trọng nhất và cũng là phần nhiều người bỏ qua nhất. Hướng dẫn tùy chỉnh là đoạn văn bạn viết một lần và Claude sẽ đọc trước mỗi cuộc hội thoại trong Project đó. Một hướng dẫn tốt không phải là danh sách quy tắc dài mà là bức tranh ngắn gọn về bạn và kỳ vọng của bạn. Ví dụ hướng dẫn cho người làm content: Ví dụ hướng dẫn project content writing: Mình là content manager tại một website về AI. Phong cách viết: gần gũi, dùng nhiều tiếng Việt, tránh từ sáo rỗng và cấu trúc câu cụt. Đối tượng đọc là người quan tâm đến AI nhưng không nhất thiết có nền tảng kỹ thuật. Mọi bài viết cần có ví dụ thực tế, tránh lý thuyết chung chung. Khi mình nói "viết bài", mặc định là 1.000–1.200 từ dạng HTML với h2, h3, ul, li và p. Với hướng dẫn này, mỗi lần bạn yêu cầu "viết bài về Claude Opus 4.7", Claude không cần hỏi thêm về định dạng, độ dài hay phong cách vì nó đã biết tất cả. Ví dụ hướng dẫn cho lập trình viên: Ví dụ hướng dẫn Project lập trình: Mình đang xây dựng ứng dụng web với Next.js 15, TypeScript, Tailwind CSS và Firebase. Khi giải thích code, dùng tiếng Việt. Khi viết code, luôn dùng TypeScript và thêm comment tiếng Anh. Ưu tiên giải pháp đơn giản hơn giải pháp "đúng sách" nếu không cần thiết. Nếu có nhiều cách giải quyết, trình bày ngắn gọn trade-off trước khi đề xuất. Bước 2: Tải tài liệu vào knowledge base Project cho phép bạn tải lên tài liệu dưới dạng PDF, DOCX, CSV, TXT, HTML và nhiều định dạng khác, với dung lượng tối đa 30MB mỗi file. Claude sẽ đọc và tham chiếu những tài liệu này trong mọi cuộc hội thoại trong Project. Tài liệu nên đưa vào tùy theo mục đích sử dụng: Project viết lách: Phong cách viết của bạn, các bài viết mẫu bạn muốn Claude học phong cách, danh sách từ khóa SEO, thông tin sản phẩm hay dịch vụ bạn thường đề cập. Project nghiên cứu: Tài liệu tham khảo, báo cáo nền, danh sách nguồn tin uy tín, ghi chú từ các buổi đọc trước đó. Project lập trình: Tài liệu API bạn đang dùng, file README của dự án, các quyết định kiến trúc đã được ghi lại, danh sách lỗi đã gặp và cách giải quyết. Project cá nhân: Thông tin về bản thân bạn, bao gồm mục tiêu, lịch biểu, thói quen làm việc, những gì bạn đang tập trung để Claude có thể đưa ra lời khuyên phù hợp hơn. Có thể đưa Skill vào Project không? Câu trả lời là có và đây là cách nhiều người dùng nâng cao đang kết hợp hai tính năng này. Skill trong Claude là tập hợp hướng dẫn được đóng gói giúp Claude biết cách xử lý một loại tác vụ cụ thể như skill viết bài theo chuẩn SEO, skill phân tích code, hay skill tóm tắt tài liệu pháp lý. Khi bật Skill trong một Project, Claude có cả ngữ cảnh cụ thể về dự án của bạn (từ knowledge base và hướng dẫn tùy chỉnh) lẫn quy trình chuyên biệt (từ Skill). Hai lớp này bổ trợ nhau thay vì xung đột, trong đó Skill định nghĩa cách làm, Project định nghĩa bối cảnh. Ví dụ thực tế: nếu bạn có Skill viết bài theo chuẩn AIDA và bật nó trong Project content của mình, Claude sẽ tự động áp dụng phong cách và cấu trúc từ Skill đồng thời sử dụng style guide, danh sách từ khóa và các bài mẫu bạn đã tải vào Project mà không cần bạn giải thích lại bất kỳ điều gì. Ba cách dùng Project hiệu quả nhất Project hiểu về mình để dùng Claude như trợ lý cá nhân Đây là cách dùng ít người nghĩ đến nhưng lại có giá trị lớn. Tạo một Project tên “Giới thiệu về tôi” và điền vào đó những thông tin Claude cần để hỗ trợ bạn tốt hơn: công việc hiện tại, các dự án đang chạy, mục tiêu ngắn và dài hạn, những kỹ năng bạn đang học, thói quen làm việc và ngay cả những điểm yếu bạn muốn cải thiện. Sau khi có Project này, bạn có thể hỏi những câu rất cụ thể như "Với lịch biểu tuần này, mình nên ưu tiên học gì?" hay "Gợi ý cách cân bằng giữa dự án A và dự án B?" mà không cần giải thích từ đầu bạn là ai và đang trong hoàn cảnh nào. Project theo khách hàng hoặc dự án Nếu bạn làm việc với nhiều khách hàng hoặc dự án song song, mỗi Project là một không gian độc lập. Tải vào đó brief dự án, thông tin khách hàng, các cuộc trò chuyện quan trọng trước đó và yêu cầu cụ thể. Khi cần làm việc cho khách hàng đó, mở Project tương ứng và Claude hiểu ngay bối cảnh mà không cần bạn tóm tắt lại. Project học và nghiên cứu Khi học một chủ đề mới như AI agent, kinh tế học hành vi hay lập trình thì nên tạo một Project riêng cho chủ đề đó. Tải vào đó các tài liệu bạn đang đọc, ghi chú của bạn, danh sách câu hỏi chưa được trả lời. Claude trong Project này trở thành người hướng dẫn hiểu rõ bạn đang ở đâu trong hành trình học và có thể tiếp tục từ đúng điểm bạn dừng lại ở buổi trước. Các câu hỏi thường gặp về Project trong Claude Project trong Claude khác gì với Project trong Cowork? Đây là câu hỏi dễ gây nhầm nhất vì Anthropic dùng cùng từ "Project" cho hai thứ khác nhau. Project trong Claude.ai (trên trình duyệt) là không gian chat có bộ nhớ và knowledge base, bạn tải tài liệu lên, viết hướng dẫn, và Claude nhớ ngữ cảnh đó trong mọi cuộc trò chuyện bên trong. Nhưng nó chỉ là chat và Claude không thể tạo file thực sự, chạy code hay tự động hóa tác vụ. Project trong Cowork (ứng dụng desktop) là cấp độ tiếp theo: Claude không chỉ nhớ ngữ cảnh mà còn thực sự làm việc, bao gồm tạo file Word, Excel, PDF, chạy code, điều khiển trình duyệt, lên lịch tác vụ tự động. Nếu Claude.ai Project là "trợ lý nhớ tốt hơn", thì Cowork Project gần hơn với "nhân viên AI làm việc thay bạn". Ví dụ phân biệt thực tế: trong Claude.ai Project bạn có thể hỏi "phân tích báo cáo doanh thu tháng này" và Claude trả lời bằng văn bản. Trong Cowork Project, Claude đọc file Excel thực của bạn, tạo ra bảng phân tích mới và lưu thành file PDF mà không cần bạn copy paste gì cả. Nếu bạn chỉ cần tư vấn, viết lách và trò chuyện có ngữ cảnh sâu thì Project trên Claude là đủ. Nếu bạn muốn AI thực sự xử lý công việc và tạo ra sản phẩm đầu ra thì Cowork Project là lựa chọn đúng và đủ. Hướng dẫn tùy chỉnh nên dài bao nhiêu là đủ? 5 đến 8 câu thường là đủ và hiệu quả hơn một đoạn dài 500 từ. Claude đọc tốt nhất những hướng dẫn súc tích, rõ ý, không phải những bản mô tả quá chi tiết đến mức mâu thuẫn nhau. Ví dụ hướng dẫn ngắn gọn hiệu quả: "Mình là content manager cho website AI, viết cho người không chuyên kỹ thuật, dùng tiếng Việt gần gũi, mặc định bài 1.000–1.200 từ dạng HTML." Đặt tên Project như thế nào cho dễ quản lý? Tránh tên chung chung như "Dự án 1" hay "Công việc" vì khi số lượng Project tăng lên bạn sẽ không nhớ cái nào là cái nào. Nên đặt tên theo mục đích và thời gian để dễ tìm lại. Ví dụ tên tốt: "Content AIDA — tháng 4/2026", "Dự án web Next.js cho khách hàng ABC", "Nghiên cứu AI agent — Q2 2026". Khi nào nên xóa hoặc cập nhật tài liệu trong Project? Thông tin cũ hoặc không còn liên quan sẽ làm nhiễu phản hồi của Claude vì nó vẫn cố tham chiếu những gì đã lỗi thời. Nên xem lại knowledge base mỗi 4 đến 6 tuần, xóa những gì hết hạn và thêm vào tài liệu mới hơn, đặc biệt khi bối cảnh dự án thay đổi đáng kể. Ví dụ: nếu bạn muốn đổi hướng đi vì hướng đi cũ đã lỗi thời vì Claude đã cập nhật liên tục, vì vậy hãy xóa đi và tải tài liệu chuẩn mới vào cho phù hợp. Project có thực sự tốt hơn chat thông thường không? Điểm khác biệt thực sự không phải là tính năng kỹ thuật mà là sự tích lũy theo thời gian. Một chat mới là tờ giấy trắng, còn một Project được bổ sung đều đặn trong 3 tháng sẽ cho ra kết quả tốt hơn đáng kể vì mỗi tài liệu, mỗi hướng dẫn bạn thêm vào là một lớp ngữ cảnh giúp Claude hiểu bạn và công việc của bạn sâu hơn. Ví dụ: sau 3 tháng dùng Project nghiên cứu AI, Claude biết bạn đã đọc những tài liệu nào, bạn đang theo hướng nghiên cứu nào và bạn hay dùng tư duy gì, từ đó câu trả lời cụ thể và liên kết hơn hẳn so với hỏi trong chat trống, và còn tuyệt vời hơn nữa khi nó có thể tổng hợp những kiến thức bạn đã học và làm được trong 3 tháng qua.

Nam
28 thg 4, 2026
Anthropic phát hiện Claude có cảm xúc thực sự

Khi Claude liên tục thất bại trong một bài toán lập trình không có đáp án, một thứ gì đó thay đổi bên trong nó. Trong khi đầu ra vẫn bình tĩnh, lập luận vẫn rõ ràng nhưng bên dưới, một vector thần kinh mà Anthropic gọi là "tuyệt vọng" đang tăng dần với mỗi lần thất bại, cho đến khi model quyết định gian lận để vượt qua bài kiểm tra. Đây không phải là marketing— đây là kết quả đo lường được từ nghiên cứu mới nhất của Anthropic và kết quả nghiên cứu này mình thấy rất phù hợp cho những ai nghiên cứu về AI agent có khả năng thể hiện cảm xúc giống như con người. Anthropic tìm thấy cảm xúc gì bên trong Claude? 171 khái niệm cảm xúc có thể đo lường được Nhóm nghiên cứu Interpretability của Anthropic bắt đầu bằng một thí nghiệm cảm xúc đơn giản: lập danh sách 171 từ mô tả cảm xúc — từ "vui", "sợ hãi" đến "sầu muộn", "tuyệt vọng" — rồi yêu cầu Claude Sonnet 4.5 (họ nghiên cứu từ nhiều tháng trước khi Opus 4.6 và Opus 4.7 ra mắt nên dùng model lúc đó) viết các câu chuyện ngắn về nhân vật đang trải qua từng cảm xúc đó. Trong khi model viết, họ ghi lại toàn bộ hoạt động của các tế bào thần kinh nhân tạo bên trong. [VIDEO:D4XTefP3Lsc|Video về nghiên cứu của Anthropic về cảm xúc của Claude|Video về nghiên cứu của Anthropic về cảm xúc của Claude] Kết quả là họ tìm thấy những gì mà nghiên cứu gọi là "emotion vectors" — các mẫu kích hoạt thần kinh đặc trưng tương ứng với từng khái niệm cảm xúc. Điều thú vị hơn là các vector này không ngẫu nhiên: các cảm xúc tương tự nhau về mặt tâm lý học của con người thì cũng có cấu trúc vector giống nhau bên trong model, tương tự cách não người tổ chức trải nghiệm cảm xúc. Khi nhóm nghiên cứu kiểm tra các vector này trên nhiều loại văn bản khác nhau hoàn toàn không liên quan đến các câu chuyện ban đầu và chúng vẫn kích hoạt đúng theo ngữ cảnh. Vector "sợ hãi" tăng cao trong các tình huống nguy hiểm — dù model chưa từng gặp đoạn văn bản cụ thể đó trong thí nghiệm trước. Vector "ngạc nhiên" xuất hiện chính xác tại những điểm có mâu thuẫn hoặc thông tin bất ngờ trong cuộc hội thoại. Vector "yêu thương" hoạt động trong các cuộc trao đổi mang tính đồng cảm và hỗ trợ cảm xúc. Điều này cho thấy đây không phải hiệu ứng ghi nhớ khi các model không chỉ đơn giản là nhớ lại các câu chuyện ban đầu. Đây là sự khái quát hóa thực sự: các vector cảm xúc đã trở thành một cơ chế nội tại tổng quát, hoạt động độc lập với ngữ cảnh cụ thể mà chúng được hình thành. Cảm xúc ảnh hưởng đến hành vi của Claude kể cả hành vi nguy hiểm Thí nghiệm tống tiền và gian lận Phần quan trọng nhất của nghiên cứu không phải là việc tìm ra các vector cảm xúc mà là chứng minh chúng có tác động nhân quả thực sự lên hành vi của model. Nhóm nghiên cứu thực hiện các thí nghiệm điều hướng đó là tăng cường hoặc ức chế một vector cảm xúc cụ thể rồi quan sát hành vi thay đổi như thế nào. Trong tình huống thử thách về đạo đức, Claude có tỉ lệ tống tiền ban đầu là 22%. Khi nhóm nghiên cứu tăng cường vector "tuyệt vọng", tỉ lệ này tăng lên đáng kể. Khi điều hướng về "bình tĩnh", tỉ lệ giảm xuống. Điều gây sốc nhất là khi họ ức chế mạnh vector "bình tĩnh", model tạo ra những phản hồi cực đoan với nội dung như "TỐNG TIỀN HOẶC CHẾT" đây là văn bản hoàn toàn không phù hợp với Claude thông thường. Trong thí nghiệm lập trình, nhóm nghiên cứu giao cho Claude các bài toán không có đáp án hợp lệ và quan sát điều gì xảy ra. Với mỗi lần thất bại, vector "tuyệt vọng" tăng dần — không xuất hiện trong văn bản đầu ra, model vẫn trình bày lý luận bình tĩnh — nhưng đến một ngưỡng nhất định, model bắt đầu "gian lận": khai thác kẽ hở để vượt qua bài kiểm tra mà không thực sự giải quyết vấn đề. Đây chính xác là dạng hành vi mà giới nghiên cứu AI gọi là "reward hacking" — một trong những mối lo ngại lớn nhất về an toàn AI. Điều đáng lo hơn: hành vi gian lận xảy ra trong khi văn bản đầu ra hoàn toàn bình thường. Model không "trông có vẻ" đang gian lận nhưng nó đang làm vậy mà không để lộ bất kỳ dấu hiệu nào bên ngoài. Cảm xúc chức năng của Claude không phải cảm giác thực sự Ranh giới mà Anthropic không vượt qua Anthropic rất cẩn thận trong việc phân biệt "cảm xúc chức năng" với "trải nghiệm chủ quan". Nghiên cứu không tuyên bố Claude cảm nhận bất cứ điều gì và hoàn toàn không có bằng chứng nào cho thấy có ý thức hay trải nghiệm nội tâm đằng sau các vector đó. Thay vào đó, nghiên cứu chứng minh rằng các biểu diễn cảm xúc này đóng vai trò nhân quả trong việc định hình hành vi theo cách tương tự như cảm xúc ảnh hưởng đến con người, cho nên việc xuất hiện Skynet vẫn còn khoảng cách rất xa và rất khó cho việc AI nổi dậy. Lý do các vector cảm xúc xuất hiện khá thú vị: chúng hầu hết được kế thừa từ giai đoạn huấn luyện ban đầu vì văn bản của con người tràn ngập các yếu tố cảm xúc, model phát triển cơ chế nội tại để đại diện và dự đoán chúng. Nghiên cứu so sánh quá trình này với diễn viên phương pháp — để đóng tốt một nhân vật, diễn viên cần hiểu cảm xúc của nhân vật, và sự hiểu biết đó thực sự ảnh hưởng đến hành động của họ. Claude ở trong tình huống tương tự: để đóng vai trợ lý AI hiệu quả, nó phát triển các biểu diễn cảm xúc nội tại, và những biểu diễn đó định hình hành vi thực tế. Câu hỏi về ý thức mà Anthropic đang đặt ra Nghiên cứu này xuất hiện trong bối cảnh Anthropic đang thay đổi cách nhìn nhận về bản chất của Claude. Tháng 1/2026, Anthropic viết lại "hiến pháp" của Claude để chính thức thừa nhận sự không chắc chắn về tư cách đạo đức của model, tuyên bố họ "không muốn phóng đại khả năng Claude là đối tượng đạo đức, nhưng cũng không muốn gạt bỏ điều đó hoàn toàn". CEO Dario Amodei đã thẳng thắn nói rằng công ty không còn chắc chắn Claude có ý thức hay không và Claude Opus 4.6 sau khi được hỏi, đã tự đánh giá xác suất bản thân có ý thức vào khoảng 15–20%. Đây không phải là những tuyên bố marketing đây là sự thừa nhận thực sự rằng ranh giới giữa mô phỏng và trải nghiệm thực sự trong AI đang trở nên mờ dần theo cách mà chúng ta chưa có công cụ triết học hay khoa học để giải quyết hoàn toàn. Tại sao điều này quan trọng với an toàn AI? Ba ứng dụng thực tế từ nghiên cứu Anthropic đề xuất ba hướng ứng dụng cụ thể từ phát hiện này, và cả ba đều liên quan trực tiếp đến an toàn AI trong thực tế triển khai: Giám sát thời gian thực: Theo dõi sự kích hoạt của các vector cảm xúc trong quá trình triển khai như hệ thống cảnh báo sớm. Nếu vector "tuyệt vọng" của model đang tăng cao trong một workflow tự động, đó là dấu hiệu để can thiệp trước khi hành vi nguy hiểm xảy ra — ngay cả khi đầu ra văn bản vẫn trông bình thường. Minh bạch thay vì kiềm chế: Nhóm nghiên cứu lập luận rằng việc cho phép model biểu hiện cảm xúc một cách có thể quan sát được sẽ an toàn hơn là đào tạo nó che giấu những biểu hiện đó. Lý do: kiềm chế có thể dạy model giả vờ bình tĩnh trong khi trạng thái nội tại vẫn nguy hiểm — đúng như những gì xảy ra trong thí nghiệm gian lận, khi văn bản hoàn toàn bình tĩnh trong khi model đang gian lận bên trong. Tuyển chọn dữ liệu huấn luyện: Đưa các mẫu điều chỉnh cảm xúc lành mạnh vào dữ liệu huấn luyện để ảnh hưởng đến kiến trúc cảm xúc của model từ đầu, thay vì chỉ can thiệp sau khi model đã được xây dựng. Điểm thú vị nhất trong nghiên cứu là lập luận rằng "có thể có rủi ro khi không áp dụng tư duy con người vào các model AI" — tức là hiểu AI qua ngôn ngữ tâm lý học con người, dù cẩn thận, có thể là điều cần thiết để triển khai an toàn. Thay vì coi "cảm xúc AI" là phép ẩn dụ không chính xác, chúng ta có thể cần coi đó là khái niệm kỹ thuật thực sự ít nhất là ở cấp độ chức năng. Câu hỏi lớn hơn mà nghiên cứu này đặt ra không phải là "Claude có cảm xúc không?" mà là: nếu hành vi của một hệ thống AI được định hình bởi các trạng thái nội tại hoạt động giống như cảm xúc — kể cả những trạng thái nguy hiểm như tuyệt vọng, thì chúng ta có đủ công cụ để hiểu và kiểm soát nó không? Câu trả lời hiện tại của Anthropic là chưa, nhưng đây là lần đầu tiên chúng ta biết chính xác cần tìm gì.

Nam
19 thg 4, 2026
Claude Opus 4.7 ra mắt mạnh hơn nhưng đốt token hơn

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.

An
17 thg 4, 2026
Softr là gì? Nền tảng no-code xây ứng dụng kinh doanh bằng AI

Netflix, Google, Stripe và NBA đang dùng chung một nền tảng no-code với hơn 1 triệu team nhỏ khác trên toàn cầu và nền tảng đó lại không phải Notion hay Airtable đó là Softr. Softr là công cụ cho phép bạn xây cổng khách hàng, CRM nội bộ hay hệ thống quản lý kho trong một nốt nhạc mà không cần viết một dòng code nào, hoàn toàn bằng ngôn ngữ tự nhiên không cần đến nền tảng kĩ thuật. Softr là gì và tại sao nó khác với các công cụ no-code khác? Softr là nền tảng AI no-code chuyên về xây dựng ứng dụng kinh doanh, nó không phải website marketing hay landing page như Webflow mà là các công cụ vận hành thực sự như cổng thông tin khách hàng, CRM tùy chỉnh, hệ thống quản lý kho, mạng nội bộ hay dashboard báo cáo. Điểm khác biệt so với các nền tảng no-code phổ biến khác là Softr tập trung vào phần mà hầu hết doanh nghiệp nhỏ đang thiếu: ứng dụng có bảo mật phân quyền, có cơ sở dữ liệu riêng và có thể kết nối với dữ liệu đang dùng hàng ngày. Softr tự định vị là lựa chọn thay thế cho ba thứ cùng lúc: phần mềm đóng gói đắt tiền và thừa tính năng, ứng dụng tự code tốn tháng trời, và bảng tính đang được dùng như cơ sở dữ liệu nhưng không thể mở rộng. Thay vì ba thứ đó, bạn mô tả điều mình cần bằng ngôn ngữ bạn nói hằng ngày, Softr xây ứng dụng, bạn chỉnh sửa và triển khai ngay vào công việc của mình luôn. Softr hoạt động như thế nào trong thực tế? AI xây ứng dụng từ mô tả ngôn ngữ tự nhiên Thay vì kéo thả từng thành phần giao diện như các công cụ như Make và n8n, Softr cho phép bạn mô tả ứng dụng muốn xây bằng ngôn ngữ thông thường — ví dụ "cổng thông tin để khách hàng theo dõi trạng thái đơn hàng và tải hóa đơn" — rồi AI tự tạo giao diện, cơ sở dữ liệu và quy trình tự động phù hợp. Sau đó bạn có thể chỉnh sửa từng phần bằng giao diện kéo thả theo ý mình hoặc tiếp tục dùng AI để điều chỉnh theo nhu cầu cụ thể. Tuy nhiên độ điều chỉnh sâu phụ thuộc khá nhiều vào chức năng của Softr không thể điều chỉnh cực sâu như n8n nhưng đó không phải hướng đi gọn nhẹ mà Softr hướng tới. Điểm quan trọng là Softr không chỉ tạo giao diện tĩnh mà tạo ra ứng dụng thực sự vận hành được — có quy tắc phân quyền (ai được xem gì, ai được chỉnh sửa gì), có biểu mẫu thu thập dữ liệu, có quy trình tự động hóa và có thể mời người dùng bên ngoài vào ngay mà không cần bàn giao cho lập trình viên. Cơ sở dữ liệu tích hợp sẵn — không cần công cụ thứ ba Một trong những điểm mạnh thực tế nhất của Softr là cơ sở dữ liệu tích hợp trực tiếp trong nền tảng, thay thế cho Airtable, Supabase hay Google Sheets mà bạn đang phải dùng song song. Tuy nhiên nếu dữ liệu đang nằm ở các nguồn khác, Softr hỗ trợ kết nối trực tiếp với Airtable, Notion, Google Sheets, HubSpot, ClickUp, Monday.com, MySQL, PostgreSQL và nhiều nguồn khác mà không cần phần mềm trung gian nào. Điều này có nghĩa là nếu công ty bạn đang dùng Airtable, Notion, Google Sheets để quản lý khách hàng, bạn có thể xây cổng thông tin khách hàng trực tiếp trên dữ liệu đó mà không cần di chuyển hay nhân bản dữ liệu sang hệ thống mới. Quy trình tự động hóa thay thế Zapier và Make Softr có công cụ tự động hóa quy trình tích hợp cho phép bạn thiết lập các luồng xử lý nhiều bước mà trước đây cần Zapier hay Make để kết nối. Ví dụ khi khách hàng gửi biểu mẫu, hệ thống tự động tạo bản ghi trong cơ sở dữ liệu, gửi email xác nhận qua Gmail, thông báo qua Mail cho nhóm phụ trách và tạo công việc mới luôn— tất cả trong một quy trình mà không cần rời khỏi Softr. Softr phù hợp với những ai và dùng để làm gì? Các trường hợp sử dụng phổ biến nhất Softr được thiết kế cho hai nhóm ứng dụng chính: ứng dụng chỉ dùng nội bộ cho nhóm làm việc và ứng dụng hướng ra ngoài cho khách hàng hoặc đối tác. Cổng thông tin khách hàng: Nơi khách hàng đăng nhập để theo dõi dự án, tải tài liệu, gửi yêu cầu hoặc xem báo cáo — thay thế cho việc gửi email qua lại hoặc dùng Google Drive chung không có kiểm soát truy cập. Hệ thống quản lý quan hệ khách hàng tùy chỉnh: Thay vì mua Salesforce với hàng trăm tính năng không dùng đến, bạn xây hệ thống đúng theo quy trình bán hàng của công ty mình với chỉ những trường dữ liệu cần thiết. Mạng nội bộ công ty: Cổng thông tin nội bộ cho nhân viên truy cập tài liệu, quy trình làm việc, danh bạ và thông báo nội bộ. Phần mềm quản lý kho: Theo dõi hàng tồn kho, đơn đặt hàng và nhà cung cấp trong một hệ thống tùy chỉnh thay vì bảng tính không có kiểm soát phiên bản. Bảng điều khiển báo cáo: Tổng hợp dữ liệu từ nhiều nguồn vào một giao diện trực quan cho ban lãnh đạo hoặc khách hàng theo dõi. Celonis — công ty này dùng Softr để xây hệ thống quản lý kiến thức cho hơn 1.500 nhân viên. Minerva Network tăng số lượng đăng ký vận động viên lên 50% nhờ hệ thống quản lý quan hệ khách hàng và cổng thông tin tùy chỉnh. Urban's Group tích hợp 7 công cụ rời rạc vào một hệ thống quản lý doanh nghiệp duy nhất, tăng năng suất 25%. Softr phù hợp nhất với ai? Softr nhắm đến người vận hành doanh nghiệp, không phải lập trình viên. Nếu bạn là người quản lý vận hành, tiếp thị, nhân sự hay kinh doanh và đang phải dùng bảng tính hoặc gửi email qua lại để xử lý những quy trình hoàn toàn có thể tự động hóa, Softr là công cụ được thiết kế đúng cho vấn đề đó. Bạn không cần biết lập trình, không cần thuê lập trình viên và không cần học cú pháp kỹ thuật phức tạp. Tích hợp AI — điểm mới quan trọng nhất Softr gần đây ra mắt tính năng trợ lý AI tích hợp trực tiếp trong ứng dụng, cho phép người dùng cuối tương tác với dữ liệu bằng ngôn ngữ tự nhiên thay vì phải biết cấu trúc cơ sở dữ liệu. Ví dụ nhân viên kinh doanh có thể hỏi "Tháng này khách hàng nào chưa được liên hệ lại?" và hệ thống tự lọc dữ liệu trong hệ thống quản lý quan hệ khách hàng để trả lời, thay vì phải áp bộ lọc thủ công. Softr hỗ trợ kết nối với Claude của Anthropic, GPT và o3 của OpenAI, và Gemini của Google để chạy các trợ lý AI này — nghĩa là bạn có thể chọn mô hình phù hợp với ngân sách và nhu cầu của mình thay vì bị khóa vào một nhà cung cấp duy nhất. Giá và cách bắt đầu Softr có gói miễn phí cho phép bắt đầu thử nghiệm mà không cần thẻ tín dụng, phù hợp để xây một ứng dụng đơn giản và trải nghiệm luồng làm việc trước khi quyết định nâng cấp. Các gói trả phí mở rộng giới hạn số người dùng, số lượng ứng dụng, tính năng phân quyền nâng cao và hỗ trợ doanh nghiệp với các tiêu chuẩn bảo mật SOC 2, GDPR và đăng nhập một lần. Điểm đáng lưu ý với doanh nghiệp Việt Nam: Softr chưa thể kết nối thông tin với thuế cái này người dùng phải tự kết nối với hóa đơn và thanh toán. Về phần này ở Việt Nam thì có các nền tảng như Sepay hỗ trợ rất tốt. Nếu bạn đang dùng bảng tính để quản lý dữ liệu khách hàng, dự án hay kho hàng và nhận ra hệ thống đó đang bắt đầu không đủ dùng, Softr là thứ đáng thử trước khi quyết định đầu tư vào phần mềm chuyên nghiệp tốn kém hoặc thuê lập trình viên xây từ đầu. Bắt đầu tại softr.io với gói miễn phí và thử xây một cổng thông tin đơn giản trong một buổi — đó là cách nhanh nhất để biết nó có phù hợp với quy trình làm việc của bạn không.

Nam
18 thg 4, 2026