Figma mở rộng MCP: Bài học về ngữ cảnh và quyền dữ liệu cho PM

Figma công bố thêm 20 đối tác MCP nhưng Dylan Field cho rằng giao thức này còn nhiều điểm cần cải thiện. Với PM, đây là lời nhắc: AI có thể tổng hợp ngữ cảnh liên công cụ, song quyền dữ liệu và kiểm chứng vẫn phải được kiểm soát chặt.

Một PM chuẩn bị review PRD thường phải mở nhiều nơi: thiết kế ở Figma, yêu cầu trong Notion, lỗi khách hàng nằm trong ticket, còn quyết định ưu tiên có thể ở một công cụ khác. Khi muốn AI hỗ trợ tổng hợp, việc sao chép thủ công từng phần vào cửa sổ chat vừa tốn thời gian, vừa dễ mất ngữ cảnh.

Model Context Protocol (MCP) hứa hẹn giúp kết nối các mảnh thông tin đó. Tuy vậy, thông điệp đáng chú ý từ Figma không phải là “cứ kết nối mọi thứ với AI”. Dù mở rộng hỗ trợ MCP, công ty vẫn cho rằng giao thức này chưa hoàn hảo và không nên phơi toàn bộ dữ liệu cho agent.

Figma mở rộng MCP, nhưng không mở mọi cánh cửa

MCP, viết tắt của Model Context Protocol, là tiêu chuẩn mã nguồn mở hỗ trợ AI agent kết nối với dữ liệu và công cụ bên ngoài.

Tại Config, sự kiện lần đầu của Figma tại Ấn Độ, công ty công bố thêm 20 đối tác MCP. Danh sách được nêu gồm Amp, ClickUp, Dia, Junie của JetBrains, Linear, Meta Muse, Mistral, Notion, OpenCode và Sarvam Agents.

Với đội ngũ sản phẩm, hướng kết nối này có thể mở ra khả năng đặt nhiều nguồn ngữ cảnh cạnh nhau, chẳng hạn:

Thiết kế: luồng người dùng và trạng thái giao diện trong Figma. Công việc triển khai: ticket, lỗi và backlog trong Linear hoặc ClickUp. Tài liệu sản phẩm: PRD, quyết định và ghi chú nghiên cứu trong Notion. AI agent: công cụ hỗ trợ trả lời câu hỏi hoặc tạo bản nháp dựa trên ngữ cảnh được cấp quyền.

Điểm cần nhớ: MCP là cách kết nối, không tự biến dữ liệu rời rạc thành một nguồn sự thật đáng tin cậy. Nếu tài liệu đã cũ, ticket thiếu bối cảnh hoặc file thiết kế chưa phản ánh quyết định mới nhất, AI vẫn có thể đưa ra kết luận nghe hợp lý nhưng sai.

Giá trị với PM: giảm chuyển ngữ cảnh, không thay thế quyết định

Giá trị thực tế của AI liên công cụ không nằm ở việc “tự làm product”, mà ở việc giảm công sức gom thông tin trước khi thảo luận và ra quyết định.

Ví dụ, trước một buổi refinement, PM có thể muốn rà soát:

Thiết kế hiện tại thể hiện những bước nào? Ticket đang mô tả vấn đề và phạm vi ra sao? PRD đã cam kết điều gì? Ghi chú nghiên cứu gợi ý rào cản nào? Có mâu thuẫn nào giữa thiết kế, yêu cầu và phản hồi khách hàng không?

Nếu tổ chức có kết nối được phê duyệt và dữ liệu phù hợp, AI có thể hỗ trợ tạo bản nháp như:

Tóm tắt các insight cần kiểm chứng. Liệt kê câu hỏi còn bỏ ngỏ. Soạn draft problem statement. Lập bảng giả thuyết và bằng chứng. Gợi ý tiêu chí nghiệm thu dựa trên yêu cầu hiện có. Chỉ ra khác biệt giữa thiết kế và tài liệu.

Đây là hướng hữu ích vì phần khó của công việc product hiếm khi chỉ là viết nhanh hơn. Thách thức lớn hơn là duy trì một cách hiểu chung giữa design, engineering, support và lãnh đạo. AI có thể thấy nhiều mảnh của bức tranh hơn, nhưng PM vẫn phải đánh giá nguồn nào đáng tin, điều gì cần xác minh và dữ liệu nào không nên chia sẻ.

Cách thử nghiệm an toàn: bắt đầu từ bài toán nhỏ

Thông tin hiện có không nêu quy trình thiết lập chi tiết, phạm vi quyền hay cách vận hành cụ thể của từng kết nối MCP. Vì vậy, không nên giả định mọi workspace Figma, Notion hoặc Linear đều triển khai giống nhau.

Khi doanh nghiệp đã có kết nối được phê duyệt, PM có thể bắt đầu từ một bài toán hẹp và rủi ro thấp:

Chọn việc cần tổng hợp, không phải quyết định tự động Chẳng hạn, rà soát sự nhất quán giữa thiết kế và ticket của một tính năng.

Chỉ dùng nguồn dữ liệu cần thiết Ưu tiên thiết kế đã chốt, PRD bản mới nhất, ticket liên quan và ghi chú nghiên cứu đã được xử lý phù hợp.

Xác định đầu ra cụ thể Thay vì hỏi “hãy đề xuất roadmap”, hãy yêu cầu bảng gồm: điểm khớp, điểm mâu thuẫn và câu hỏi cần xác minh.

Yêu cầu tách sự kiện khỏi suy luận Mỗi nhận định nên chỉ rõ nguồn, hoặc được đánh dấu là giả thuyết khi chưa có bằng chứng.

Đối chiếu lại với nguồn gốc Kiểm tra thiết kế, ticket, tài liệu nghiên cứu và dữ liệu liên quan trước khi đưa kết luận vào PRD hoặc roadmap.

Giữ người chịu trách nhiệm trong vòng phê duyệt AI có thể hỗ trợ soạn ticket hoặc gợi ý câu hỏi nghiên cứu. Các thay đổi về scope, ưu tiên hay trải nghiệm vẫn cần người phụ trách phê duyệt.

Prompt mẫu để rà soát ngữ cảnh liên công cụ

Prompt dưới đây phù hợp khi agent đã được cấp quyền truy cập cần thiết và dữ liệu trong ngữ cảnh hiện tại được phép sử dụng.

text Bạn là trợ lý phân tích sản phẩm. Hãy rà soát tính nhất quán giữa thiết kế, tài liệu và ticket được cung cấp trong ngữ cảnh hiện tại.

<product context> [Loại sản phẩm, mục tiêu tính năng, phần thiết kế và tài liệu được phép dùng] </product context>

<user segment> [Nhóm người dùng mục tiêu] </user segment>

<research notes> [Các insight đã được xử lý phù hợp; nêu rõ đâu là bằng chứng đã xác thực] </research notes>

<constraints> [Phạm vi phát hành, ràng buộc kỹ thuật, thương hiệu và dữ liệu] </constraints>

Hãy trả về: Các sự kiện có nguồn rõ ràng. Các điểm mâu thuẫn giữa thiết kế, ticket và tài liệu. Các giả thuyết AI suy luận nhưng chưa có bằng chứng. Câu hỏi cần kiểm chứng trước khi quyết định. Draft tiêu chí nghiệm thu, chỉ dựa trên thông tin đã xác thực.

Không tự tạo insight người dùng, số liệu, yêu cầu kỹ thuật hoặc cam kết roadmap. Nếu thiếu nguồn, ghi rõ “chưa đủ dữ liệu”.

Một đầu ra tốt không phải là kết luận vội vàng như “hãy bỏ bước xác minh”. Nó cần phân biệt rõ:

Figma đang hiển thị gì. Ticket yêu cầu gì. Ghi chú nghiên cứu mới chỉ gợi ý điều gì. Cần kiểm tra thêm dữ liệu nào trước khi thay đổi luồng.

Vì sao Figma vẫn cảnh giác với MCP?

Dylan Field cho biết Figma muốn mở hệ sinh thái, nhưng MCP “còn rất nhiều chỗ để cải thiện”. Ông cũng nhận định giao thức này có thể thuận lợi hơn cho các phòng thí nghiệm AI tuyến đầu.

Một điểm tranh luận khác là điều Field gọi là “asymmetric context sharing” — chia sẻ ngữ cảnh bất đối xứng. Theo lập luận này, một bên có thể phải mở nhiều dữ liệu cho hệ thống bên ngoài, trong khi bên kia không mở tương xứng các tài nguyên của mình.

Vì thế, câu hỏi không chỉ là “mở hay đóng”, mà là:

> Ai được thấy dữ liệu nào, dùng vào mục đích gì và có thể làm gì sau khi truy cập?

Figma cũng nêu lo ngại rằng càng mở nhiều dữ liệu qua MCP, nguy cơ bị lạm dụng càng cao. Dù phần lớn người dùng không có ý đồ xấu, doanh nghiệp vẫn cần tính đến các tình huống rủi ro.

Checklist cho product team trước khi dùng agent liên công cụ

[ ] Bài toán có đầu ra cụ thể và mức rủi ro phù hợp. [ ] Mỗi nguồn dữ liệu đều có chủ sở hữu và quyền truy cập rõ ràng. [ ] Dữ liệu cá nhân, dữ liệu định danh và thông tin nhạy cảm được xử lý theo chính sách của tổ chức. [ ] Prompt yêu cầu phân biệt bằng chứng, suy luận và phần thiếu dữ liệu. [ ] PM hoặc người phụ trách domain kiểm tra lại kết luận với nguồn gốc. [ ] Agent không được tự động thay đổi thiết kế, ticket hoặc tài liệu quan trọng nếu chưa có cơ chế phê duyệt.

MCP có thể giúp thiết kế, ticket và tài liệu bớt bị cô lập. Nhưng lợi thế của một đội product không đến từ việc kết nối nhiều dữ liệu nhất, mà từ việc kết nối đúng ngữ cảnh, kiểm chứng đúng lúc và giữ quyền quyết định ở đúng người.