Làm Cùng Long.
← Quay lại Bắt Nhịp
Automation · 13 phút đọc · · Make

Make đưa Maia vào Scenario Builder: từ mô tả bằng lời đến workflow nhìn thấy được

Khi AI bắt đầu tự dựng automation, nút thắt không biến mất. Nó dịch từ việc kéo từng module sang mô tả đúng ý định, kiểm tra logic, quyền truy cập và điều kiện được phép chạy thật.

Một câu mô tả đi qua lớp kính trong suốt và biến thành chuỗi module automation nhìn thấy được, với một điểm kiểm tra của con người trước đầu ra

Minh họa editorial tạo cho Làm Cùng Long

Có một kiểu demo AI đang trở nên rất quen: nhập vài câu mô tả, chờ vài giây, rồi một sản phẩm gần như hoàn chỉnh xuất hiện. Website, code, slide, báo cáo và giờ là cả workflow automation đều đang đi theo hướng đó.

Make vừa đưa Maia vào chính Scenario Builder. Người dùng có thể mô tả bằng ngôn ngữ tự nhiên thứ mình muốn tự động hóa; Maia phân tích yêu cầu, chọn module, dựng luồng, cấu hình từng bước và hiển thị quá trình đó trực tiếp trên canvas của Make.

Nếu chỉ nhìn ở bề mặt, đây là một phiên bản mới của câu chuyện “AI giúp làm nhanh hơn”. Nhưng phần đáng chú ý hơn nằm ở chỗ khác: AI bắt đầu tự dựng workflow, nhưng thứ nó dựng ra vẫn được biểu diễn thành một hệ thống mà con người có thể nhìn, sửa, kiểm tra và bàn giao.

Đây có thể là một hướng quan trọng cho automation trong doanh nghiệp. Khi phần lắp ráp ngày càng được AI làm thay, năng lực có giá trị hơn sẽ dịch sang việc mô tả đúng ý định, kiểm tra logic, quản lý quyền truy cập, xác nhận đầu ra và quyết định khi nào một workflow thực sự được phép chạy.

Mục lục

1. Maia thực sự thay đổi điều gì?

FACT: Make công bố Maia ngày 12/08/2026 và hiện cung cấp công cụ này trực tiếp trong Scenario Builder. Theo tài liệu chính thức, người dùng có thể mô tả một automation hoặc AI Agent bằng ngôn ngữ tự nhiên; Maia sẽ ánh xạ luồng xử lý, chọn công cụ phù hợp, cấu hình module và thể hiện từng bước ngay trên giao diện trực quan của Make.

Maia không chỉ dùng cho scenario mới. Make cho biết công cụ có thể tùy chỉnh template, chỉnh sửa workflow đang tồn tại, giải thích logic và hỗ trợ tìm lỗi ở module thất bại. Trong quá trình dựng, Maia có thể đặt câu hỏi làm rõ thay vì âm thầm đoán toàn bộ ý định của người dùng.

Đến ngày 02/09/2026, trang sản phẩm của Make vẫn xác nhận Maia đang khả dụng. Người dùng gói trả phí có quyền truy cập theo cơ chế credit của Make; gói miễn phí có thời gian dùng thử. Chi tiết hạn mức có thể thay đổi theo chính sách sản phẩm, nên phần quan trọng hơn với người làm vận hành không phải số tin nhắn mà là cơ chế xây workflow bằng hội thoại đã trở thành một phần của sản phẩm chính.

INTERPRETATION: Delta đáng chú ý không phải “Make có thêm chatbot”. Nó nằm ở việc Make đưa lớp hội thoại vào ngay nơi workflow được xây, thay vì tách AI tư vấn ở một cửa sổ và phần triển khai ở một hệ thống khác.

Trước đây, một cách làm phổ biến là hỏi ChatGPT hoặc một LLM cách nối Gmail với Sheets, CRM hay Slack, sau đó quay lại Make để tự tìm module, map trường dữ liệu, đặt filter và sửa lỗi. Với Maia, khoảng cách giữa mô tả ý định và tạo cấu hình thực thi ngắn đi đáng kể.

2. Trước đây nút thắt của automation nằm ở đâu?

No-code đã giúp automation dễ tiếp cận hơn code thuần, nhưng “không cần viết code” chưa bao giờ đồng nghĩa với “không cần hiểu hệ thống”.

Một workflow có vài bước đơn giản thường dễ dựng. Nhưng khi quy trình bắt đầu có router, filter, nhiều nhánh dữ liệu, API, webhook, trạng thái lỗi, retry hoặc nhiều hệ thống liên quan, phần khó nhanh chóng chuyển sang những câu hỏi như:

  • Trigger nào thực sự đại diện cho sự kiện cần xử lý?
  • Trường dữ liệu nào tương ứng với trường nào ở hệ thống đích?
  • Nếu dữ liệu thiếu hoặc sai định dạng thì đi nhánh nào?
  • Khi API trả lỗi, workflow thử lại hay dừng?
  • Agent hoặc scenario được đọc và ghi những gì?
  • Một hành động có thể tạo hậu quả thật có cần người duyệt không?

Đó là lý do nhiều automation demo rất nhanh nhưng production lại khó. Phần kéo module chỉ là một lớp của bài toán. Phía dưới vẫn là logic nghiệp vụ, dữ liệu, quyền và cách xử lý thất bại.

Trong Vault của Làm Cùng Long, một tín hiệu gần đây về AI agent quản lý quảng cáo cũng đi tới kết luận tương tự: mô hình AI không phải phần khó nhất. Khi agent bắt đầu làm việc với dữ liệu và hệ thống thật, độ tin cậy phụ thuộc vào dữ liệu đầu vào, business context, quyền truy cập, evidence và guardrail. Một hệ thống có thể tạo ra lời giải thích rất thuyết phục nhưng vẫn sai nếu nó thiếu ngữ cảnh hoặc nhìn dữ liệu chưa trưởng thành.

Maia không xóa các vấn đề đó. Nó làm một việc khác: giảm chi phí lắp ráp để người dùng đi tới các vấn đề thật sớm hơn.

3. Điểm khác biệt đáng chú ý: AI làm nhưng workflow vẫn nhìn thấy được

Make nhấn mạnh Maia không vận hành như một “hộp đen” chỉ nhận yêu cầu rồi trả về kết quả cuối cùng. Khi Maia dựng scenario, người dùng nhìn thấy module, route, connection và logic xuất hiện trên canvas; sau đó có thể chỉnh sửa chúng như một workflow Make thông thường.

Ở góc độ vận hành, điều này quan trọng hơn lời hứa “build nhanh”.

Một automation dùng trong doanh nghiệp không chỉ cần chạy được. Nó còn cần trả lời được các câu hỏi:

  • Nó đang lấy dữ liệu từ đâu?
  • Nó sẽ gửi dữ liệu đi đâu?
  • Điều kiện nào kích hoạt hành động?
  • Hệ thống nào đang có quyền ghi dữ liệu?
  • Khi đổi một module, những nhánh nào bị ảnh hưởng?
  • Người khác có thể tiếp quản và sửa nó hay không?

Khi logic được biểu diễn trực quan, người kiểm tra có một “bề mặt” để audit. Điều đó không đảm bảo workflow đúng, nhưng ít nhất tạo điều kiện để con người kiểm chứng thay vì phải tin vào một kết quả đã được AI đóng gói hoàn chỉnh.

INTERPRETATION: Đây là điểm Maia phù hợp với một nguyên tắc rộng hơn của AI Agent: execution success không đồng nghĩa với đúng. Một scenario chạy xanh chỉ chứng minh hệ thống không gặp lỗi kỹ thuật ở lần chạy đó. Nó chưa chứng minh dữ liệu được map đúng, khách hàng được phân loại đúng, nội dung được gửi đúng người hay hành động đó nên được thực hiện.

Khả năng nhìn thấy logic giúp thu hẹp khoảng cách giữa “AI đã làm xong” và “con người có thể xác minh AI đã làm gì”. Với automation production, khoảng cách này rất đáng giá.

4. Vai trò của người làm automation sẽ dịch chuyển như thế nào?

Khi AI có thể tự tìm module và dựng phần lớn scenario, kỹ năng kéo-thả sẽ bớt là lợi thế độc lập. Nhưng điều đó không có nghĩa người làm automation ít quan trọng hơn.

Nó làm vai trò dịch lên một tầng.

Thay vì bắt đầu bằng “phải nối module nào trước?”, người làm tốt sẽ phải bắt đầu bằng một đặc tả rõ hơn:

Input → Decision → Action → Evidence → Failure path.

Ví dụ, yêu cầu “Khi có lead mới thì gửi cho sales” vẫn quá mơ hồ dù Maia hiểu được câu chữ. Một đặc tả production cần rõ hơn:

  • Lead mới được xác định ở nguồn nào?
  • Điều kiện nào khiến lead hợp lệ?
  • Trùng số điện thoại hoặc email xử lý thế nào?
  • Sales nào nhận lead dựa trên tiêu chí nào?
  • Nếu CRM lỗi thì có được gửi tiếp qua kênh khác không?
  • Sau khi ghi thành công, bằng chứng nào xác nhận tác vụ hoàn tất?
  • Nếu agent không đủ dữ liệu để quyết định thì dừng ở đâu?

AI có thể dựng nhanh phần cơ khí từ đặc tả đó. Nhưng chất lượng đặc tả vẫn đến từ người hiểu quy trình kinh doanh.

Vì vậy, INTERPRETATION: lợi thế của người làm automation đang dịch từ “biết công cụ” sang bốn năng lực: mô hình hóa quy trình, thiết kế dữ liệu, đặt guardrail và xác minh kết quả.

Đây cũng là lý do Maia có thể hữu ích cho cả người mới và người có kinh nghiệm theo hai cách khác nhau. Người mới giảm rào cản để bắt đầu; người có kinh nghiệm giảm thời gian lắp ráp và bảo trì. Nhưng nhóm thứ hai vẫn có lợi thế nếu biết nhìn một workflow như một hệ thống cần vận hành lâu dài, chứ không phải một chuỗi module chạy được một lần.

5. Bốn rủi ro không biến mất khi AI biết tự dựng workflow

1. Prompt đúng câu chưa chắc đặc tả đúng bài toán

Ngôn ngữ tự nhiên giúp diễn đạt ý tưởng dễ hơn, nhưng sự mơ hồ của nghiệp vụ vẫn còn nguyên. Nếu người dùng mô tả sai mục tiêu, AI có thể rất hiệu quả trong việc dựng đúng thứ không nên dựng.

Vì vậy, trước khi prompt cho Maia, nên viết được ít nhất ba dòng: đầu vào là gì, đầu ra mong muốn là gì, điều kiện nào khiến workflow không được phép tiếp tục.

2. Mapping dữ liệu vẫn có thể “trông hợp lý” nhưng sai nghĩa

Hai trường có tên gần giống nhau chưa chắc là cùng một khái niệm. customer_id, lead_id, contact_id hoặc một trường doanh thu ở nhiều hệ thống có thể có logic hoàn toàn khác.

Visual workflow giúp thấy mapping, nhưng người hiểu data model vẫn phải kiểm tra ý nghĩa của mapping đó.

3. Quyền truy cập là ranh giới thật, không phải chi tiết kỹ thuật

Một automation có quyền đọc email, ghi CRM, gửi Slack và gọi API đã có khả năng tác động đến nhiều hệ thống thật. Việc AI dựng được kết nối không đồng nghĩa mọi quyền kết nối đó đều nên được cấp.

Nguyên tắc an toàn vẫn nên là quyền tối thiểu cần cho đúng nhiệm vụ. Với hành động có tác động lớn — gửi ra ngoài, xóa dữ liệu, thay trạng thái khách hàng, thay ngân sách hoặc cập nhật hệ thống lõi — nên có bước duyệt hoặc giới hạn rõ.

4. Chạy được chưa phải bằng chứng workflow đáng tin

Một lần test thành công thường chỉ kiểm tra “happy path”. Production còn có dữ liệu trống, trùng, API timeout, rate limit, lỗi xác thực, schema thay đổi và những trường hợp người dùng không dự đoán từ đầu.

AI làm scenario nhanh hơn có thể khiến ta muốn bỏ qua phần test để sớm tận hưởng kết quả. Đây lại là lúc nên làm ngược: thời gian tiết kiệm được ở khâu dựng nên được chuyển sang khâu kiểm chứng.

6. Cách thử Maia mà không biến một demo đẹp thành rủi ro vận hành

Nếu đang dùng Make, cách hợp lý nhất để đánh giá Maia không phải hỏi “AI này thông minh tới đâu?”, mà chọn một workflow thật, rủi ro thấp và có tiêu chí kiểm tra rõ.

Tôi sẽ đi theo một vòng thử sáu bước.

Bước 1 — Chọn một quy trình nhỏ nhưng có thật. Ví dụ: nhận form nội bộ → chuẩn hóa vài trường → ghi vào một sheet test → gửi thông báo vào kênh thử nghiệm. Không bắt đầu bằng workflow đang thay đổi dữ liệu khách hàng hoặc tiền quảng cáo.

Bước 2 — Viết contract trước khi prompt. Ghi rõ input, output, điều kiện hợp lệ, trường hợp phải dừng và evidence cần có sau khi hoàn tất.

Bước 3 — Để Maia dựng scenario. Quan sát Maia chọn module, map dữ liệu và hỏi lại những gì. Phần đáng đánh giá không chỉ là tốc độ, mà là những giả định nào nó tự đưa vào khi yêu cầu chưa đủ rõ.

Bước 4 — Audit từng lớp trước khi chạy. Kiểm tra connection, permission, mapping, filter/router, hành động ghi dữ liệu và error path. Nếu không giải thích được một module đang làm gì, chưa nên bật workflow thật.

Bước 5 — Test bằng dữ liệu fixture. Có ít nhất dữ liệu bình thường, dữ liệu thiếu, dữ liệu trùng và một tình huống lỗi có chủ đích. So sánh đầu ra với expected result thay vì chỉ nhìn run status màu xanh.

Bước 6 — Chỉ production khi có đường quay lại. Với workflow quan trọng, cần log, cảnh báo, người chịu trách nhiệm và cách tắt nhanh. Tự động hóa càng dễ tạo, việc quản lý inventory và ownership càng quan trọng vì số workflow trong tổ chức cũng có thể tăng nhanh hơn trước.

Cách thử này làm rõ một điểm: Maia không cần phải hoàn hảo mới có giá trị. Nếu nó giúp rút ngắn phần dựng scenario nhưng vẫn để phần kiểm chứng trong tay người vận hành, nó đã có thể tạo ra một bước tiến đáng kể về năng suất.

7. Điều gì hiện vẫn chưa nên kết luận?

Có ba điều tôi sẽ giữ ở trạng thái UNKNOWN.

Thứ nhất, chưa có benchmark độc lập đủ mạnh để kết luận Maia giảm bao nhiêu phần trăm thời gian dựng workflow hoặc tỷ lệ scenario được dựng đúng ngay lần đầu. Make mô tả công cụ giúp xây nhanh hơn, nhưng không nên biến thông điệp sản phẩm thành một con số hiệu suất khi chưa có bằng chứng độc lập.

Thứ hai, Make đã nói về hướng phát triển để Maia hiểu toàn bộ “automation landscape” và chủ động phát hiện vấn đề, nhưng đây là hướng tương lai. Không nên viết như thể Maia hiện đã tự giám sát toàn bộ hệ thống và chủ động sửa production.

Thứ ba, tính “visible” không đồng nghĩa với “verified”. Workflow hiển thị rõ ràng giúp audit dễ hơn, nhưng tính đúng vẫn cần test, dữ liệu chuẩn và người hiểu nghiệp vụ.

Điểm đáng giữ lại từ Maia vì vậy không phải câu “sắp tới ai cũng làm automation được”. Câu đó dễ tạo cảm giác rằng kỹ năng automation đã trở nên không cần thiết.

Một cách nhìn hữu ích hơn là:

AI đang làm cho việc dựng workflow rẻ hơn. Nhưng khi chi phí tạo giảm, chi phí của một workflow sai không tự giảm theo.

Vì vậy, bước tiến đáng chú ý của Maia không chỉ là biến lời nói thành automation. Nó là việc biến lời nói thành một automation còn có thể nhìn thấy, sửa được và kiểm tra được.

Nếu hướng này tiếp tục phát triển, phần việc con người cần giữ sẽ ngày càng rõ: mô tả đúng bài toán, giới hạn quyền, kiểm tra dữ liệu, thiết kế failure path và quyết định khi nào một hệ thống đủ đáng tin để được phép hành động.

Đó có lẽ là ranh giới quan trọng giữa một demo AI rất đẹp và một workflow thực sự có thể sống lâu trong doanh nghiệp.

Nguồn kiểm chứng