FDE: Còi hiệu báo chuyển đổi nghề nghiệp trong kỷ nguyên AI đã vang lên?
Tuyển chọn TechFlowTuyển chọn TechFlow
FDE: Còi hiệu báo chuyển đổi nghề nghiệp trong kỷ nguyên AI đã vang lên?
Từ cá nhân siêu việt đến vị trí công việc siêu việt.
Chuyên sâu báo cáo Web3👦🏻 Tác giả: Henry (Đội DeerFlow)[1]
Trong tháng gần đây, tôi đã gặp bốn người bạn đang chuẩn bị chuyển đổi nghề nghiệp — một kỹ sư frontend, một kiến trúc sư giải pháp, một quản lý sản phẩm và một kỹ sư thuật toán truyền thống. Họ có nền tảng, độ tuổi và thành phố sinh sống khác nhau, nhưng cùng đặt ra một câu hỏi giống nhau về một từ viết tắt tiếng Anh: FDE[2] — liệu vị trí này có đáng để tôi theo đuổi?
FDE là viết tắt của Forward Deployed Engineer[2]. Hai năm trước, đây vẫn chỉ là một thuật ngữ nội bộ trong giới Palantir; hôm nay, nó đã lặng lẽ trở thành lời mở đầu quen thuộc của các chuyên viên tuyển dụng, một vị trí thường xuyên xuất hiện trong các tin tuyển dụng, đồng thời cũng là một trong những ứng cử viên hàng đầu cho danh hiệu “vị trí giá trị nhất trong kỷ nguyên AI” trên mạng xã hội. Tháng 5 năm 2026, OpenAI chính thức thành lập Công ty Triển khai (Deployment Company)[3] mang tên này, với khoản đầu tư ban đầu lên tới 4 tỷ USD, và tuyên bố rõ ràng rằng sẽ cử kỹ sư đến làm việc trực tiếp tại hiện trường khách hàng, tích hợp sâu vào quy trình công việc của họ; đội Applied AI của Anthropic cũng đang tuyển dụng FDE đồng thời tại bốn múi giờ khác nhau. Từ một thuật ngữ nội bộ, FDE đã trở thành một khái niệm phổ biến chỉ trong hơn một năm.
Bài viết trước đây của tôi — “Gửi tới những cá nhân siêu việt”[4] — tập trung phân tích “động cơ con người”: sự tò mò, khả năng tự học, tinh thần tự chủ, năng lực thực hành — làm thế nào để những yếu tố này được khơi dậy một cách toàn diện trong một vòng khép kín (Closed-loop) hoàn chỉnh. Nhưng con người không tồn tại lơ lửng giữa không trung; họ cần được “neo đậu” vào một hệ tọa độ công việc cụ thể. Nếu coi “cá nhân siêu việt” là “nguyên liệu thô” của quan hệ sản xuất trong kỷ nguyên AI, thì FDE chính là hình thái vị trí rõ ràng nhất mà thị trường đã tạo ra trong năm qua.
Theo quan điểm của tôi, FDE không nằm trong nhóm tư vấn, cũng không thuộc nhóm ngoại包. Nó gần gũi nhất với “cá nhân siêu việt” — điểm khác biệt duy nhất là FDE là một “cá nhân siêu việt” được tổ chức hóa trong khoảng không kẹp giữa “công ty mô hình × khách hàng”.
Bạn có biết “Forward Deployed” bắt nguồn từ đâu không? Thuật ngữ này vốn là một khái niệm quân sự của Mỹ — Forward Deployed Forces — chỉ các lực lượng được triển khai ở nước ngoài hoặc tiền tuyến, sẵn sàng phản ứng nhanh chóng tại chỗ, trái ngược với các lực lượng hậu phương đóng tại căn cứ trong nước. Cuối những năm 2000, Palantir đã đưa khái niệm này vào ngành phần mềm để mô tả mô hình làm việc “gửi kỹ sư rời khỏi trụ sở, đến ở và làm việc trực tiếp tại hiện trường khách hàng”, thậm chí còn đặt tên các nhóm nội bộ theo bảng ký hiệu âm thanh quân sự: Delta và Echo. Việc OpenAI và Anthropic tái sử dụng lại thuật ngữ này không phải là ngẫu nhiên — việc gửi kỹ sư lên “tiền tuyến” luôn giữ nguyên bản chất cốt lõi.
Bài viết này nhằm trả lời ba thắc mắc cụ thể mà bốn người bạn trên đã đặt ra cho tôi gần đây:
- FDE có phải là một công ty tư vấn khoác áo AI? Ranh giới giữa FDE và tư vấn truyền thống nằm ở đâu?
- FDE có phải là một dạng ngoại包 phần mềm cao cấp hơn? Nó khác gì so với công việc hiện tại của tôi — một bên cung cấp dịch vụ (vendor)?
- Tôi có phù hợp để làm FDE không? Loại người nào sẽ được vị trí này khuếch đại, còn loại nào sẽ bị bào mòn?
Quan điểm của tôi là thận trọng nhưng lạc quan: FDE thực sự đang phát triển mạnh mẽ, song nó tuyệt nhiên không phải là lối thoát chuyển đổi nghề nghiệp cho tất cả mọi người. Việc làm rõ bản chất của FDE quan trọng hơn nhiều so với việc chỉ đơn thuần làm nổi bật nó.
Bắt đầu từ Đội Triển khai (Deployment Team) của OpenAI
Nếu chỉ được chọn một sự kiện đánh dấu thời điểm FDE lần này quay trở lại sân khấu rộng lớn, tôi sẽ chọn ngày 11 tháng 5 năm 2026 — khi OpenAI tuyên bố thành lập Công ty Triển khai (Deployment Company)[5], COO Brad Lightcap rời mảng kinh doanh truyền thống để đảm nhận vai trò dự án đặc biệt (special projects), báo cáo trực tiếp cho Sam Altman và toàn tâm toàn ý phụ trách lĩnh vực này. Cùng tuần đó, OpenAI mua lại công ty tư vấn AI có trụ sở tại Anh — Tomoro — và đưa thẳng 150 kỹ sư FDE cùng các chuyên gia triển khai (Deployment Specialist) vào công ty mới.
Đáng chú ý, trang tuyển dụng của OpenAI đang đăng tải hàng chục vị trí FDE tại các địa điểm như San Francisco, New York và Washington, đồng thời chia theo lĩnh vực chuyên sâu như Khoa học đời sống (Life Sciences), Bán dẫn (Semiconductor), Chính phủ (Gov), v.v.; thậm chí vị trí “Chuyên viên tuyển dụng FDE”[6] cũng đang được tuyển. Các nhà phân tích ước tính đội ngũ này sẽ mở rộng lên quy mô 2.000–4.000 người trong vòng ba năm. Đây không còn là quy mô của một nhóm nghiên cứu nhỏ, mà là một đạo quân chính quy.
Anthropic cũng hành động gần như đối xứng. Các vị trí Forward Deployed Engineer[7] thuộc Đội Applied AI đang được tuyển đồng thời tại sáu thành phố: Boston, New York, Seattle, San Francisco, Washington và London, với yêu cầu 25%–50% thời gian đi công tác tại hiện trường khách hàng. Một ví dụ gần đây thường được trích dẫn là công ty công nghệ tài chính FIS — trong thông báo chính thức, FIS viết rõ: “Đội Applied AI của Anthropic và các kỹ sư forward-deployed đã được tích hợp sâu vào FIS, cùng thiết kế Agent AI chống tội phạm tài chính (Financial Crimes AI Agent), đồng thời chuyển giao tri thức cho FIS để họ có thể tự chủ mở rộng thêm nhiều agent trong tương lai.”
Đoạn văn trên chứa đựng bản chất thực sự của công việc FDE. Đó không phải là kiến trúc sư tiền bán hàng (pre-sales architect), không phải là chuyên viên phát triển doanh số (SDR), cũng không phải là nhà truyền bá (Evangelist) đến đào tạo khách hàng. Đó là một kỹ sư mang theo mô hình, sống và làm việc trực tiếp trong kho mã nguồn của khách hàng. Brad Lightcap nói thẳng thừng hơn: “Khách hàng của chúng tôi cho biết họ cần khả năng chuyển từ giai đoạn thử nghiệm (pilot) sang vận hành thực tế (production). Công ty Triển khai chính là việc đưa kỹ sư của chúng tôi vào đội ngũ khách hàng, cung cấp đầy đủ nguồn lực để đảm bảo bàn giao thành công.”
Khi biểu diễn điều này dưới dạng sơ đồ, mối quan hệ giữa ba bên sẽ trở nên cực kỳ rõ ràng:
Lưu ý hai đường nối mang nhiều thông tin nhất trong sơ đồ này — đó là hai luồng phản hồi do FDE gửi đi. Về phía khách hàng, FDE không bán mô hình như một dịch vụ SaaS, mà kết nối dữ liệu, quyền truy cập, tuân thủ quy định và hệ thống nội bộ của khách hàng thành một “ống dẫn” duy nhất có thể chạy được mô hình; về phía công ty mô hình, FDE mang trở lại những đau điểm thực tế và các mẫu thất bại từ khách hàng để ảnh hưởng trực tiếp tới lộ trình phát triển sản phẩm (roadmap) và nghiên cứu — một mẫu lỗi gọi công cụ (tool calling pattern) lặp đi lặp lại có thể trở thành một trừu tượng (abstraction) được tích hợp sẵn trong SDK phiên bản tiếp theo.
Đây chính là lý do vì sao FDE được hai công ty mô hình hàng đầu đồng loạt tái sử dụng trong đợt này — đằng sau đó không đơn giản chỉ là “chúng ta cũng muốn học theo Palantir làm tư vấn”. Thay vào đó, FDE là một thiết bị thu thập tín hiệu của công ty mô hình — những đau điểm dày đặc nhất từ khách hàng ở “tiền tuyến” chỉ có thể được nắm bắt khi có người của chính công ty hiện diện tại chỗ; nhu cầu được đối tác truyền đạt lại luôn bị “lọc mất một lớp”. Anthropic lựa chọn con đường hỗn hợp: vừa vận hành đội FDE riêng, vừa xây dựng mạng lưới triển khai liên doanh với các công ty tư vấn và các tập đoàn đầu tư tư nhân (PE) khổng lồ. Một bên thiên về vận hành nội bộ, một bên thiên về hệ sinh thái (ecosystem), nhưng cốt lõi đều giống nhau: công ty mô hình không còn chỉ là nhà cung cấp API, mà phải trực tiếp cử kỹ sư vào bên trong sản phẩm của khách hàng.
Tiếp theo, chúng ta sẽ trả lời hai câu hỏi so sánh phổ biến nhất — ranh giới giữa FDE và tư vấn truyền thống (như McKinsey, Accenture) nằm ở đâu? Và FDE có phải là một dạng ngoại包 phần mềm quen thuộc hay không?
FDE không phải McKinsey: Ranh giới mô hình vs. ranh giới quy trình
Nhiều người lần đầu nghe mô tả công việc FDE thường phản ứng ngay: “Đây chẳng phải phiên bản mới của McKinsey hay Accenture sao?”
Tôi hiểu sự liên tưởng này. Mặc vest, đi công tác tại hiện trường khách hàng, ngồi trong phòng họp của khách hàng vẽ bảng trắng, đồng bộ với các giám đốc cấp C — xét về hình ảnh bề ngoài, FDE và cố vấn tư vấn quả thật rất giống nhau. Nhưng chỉ cần đi sâu một lớp, bản chất công việc của hai bên hoàn toàn khác biệt. Tư vấn bán ranh giới quy trình, còn FDE bán ranh giới mô hình.
Khi đặt hai khái niệm này cạnh nhau trong một bảng so sánh, sự khác biệt sẽ hiện rõ ngay lập tức.
Dòng “khấu hao tài sản” trong bảng này là điểm đáng dừng lại suy ngẫm nhất.
Lý do khiến tư vấn truyền thống kiếm được nhiều tiền nhất là khả năng tái sử dụng tài sản — một giải pháp dành cho một ngân hàng có thể được chỉnh sửa nhẹ rồi bán lại cho ngân hàng khác; một “sổ tay chuyển đổi số” cho ngành bán lẻ có thể được áp dụng lặp lại cho ba mươi khách hàng. Đây là mô hình kinh tế nền tảng giúp Accenture, Deloitte và McKinsey Digital phát triển mạnh mẽ trong ba thập kỷ qua.
FDE không có loại tài sản như vậy. Khả năng của mô hình vẫn đang thay đổi rất nhanh — hôm nay vẫn cần thiết kế chuỗi prompt rất công phu, nhưng phiên bản mô hình tiếp theo có thể xử lý chỉ bằng một câu lệnh. “Phương pháp luận tích lũy” của tư vấn sẽ nhanh chóng mất giá trong bối cảnh tốc độ này. Vì vậy, FDE không thể vận hành theo mô hình tái sử dụng tài sản, mà buộc phải chạy lại toàn bộ vòng khép kín mỗi lần — đánh giá lại ranh giới mô hình, lựa chọn lại stack công cụ, thiết kế lại hình thái sản phẩm. Nhìn có vẻ kém hiệu quả, nhưng đây lại là cách duy nhất để theo kịp tốc độ phát triển của mô hình.
Bạn có biết “Product Overhang” là gì không? Tôi đã giải thích khái niệm này trong bài viết trước — “Gửi tới những cá nhân siêu việt”[4]: đây là tình trạng khả năng của mô hình đã vượt xa hình thái sản phẩm hiện có, nhưng lại thiếu cổng vào sản phẩm, thiếu quyền truy cập và thiếu bối cảnh để hiện thực hóa tiềm năng đó. Giá trị cốt lõi của vị trí FDE chính là biến những “Product Overhang” treo lơ lửng trong bối cảnh khách hàng thành một sản phẩm cụ thể có thể vận hành thực tế. Khách hàng không mua hạn mức gọi API mô hình, mà mua khả năng “có người thực sự có thể triển khai khối ‘Overhang’ này vào hoạt động kinh doanh của tôi”.
Điều này cũng giải thích sự khác biệt ở dòng “cấu trúc dự án”. Cấu trúc tiêu chuẩn của dự án tư vấn là SOW (Statement of Work) + WBS (Work Breakdown Structure) + nghiệm thu từng giai đoạn: hợp đồng ghi rõ phải bàn giao cái gì, khi nào và theo tiêu chuẩn nào. Cơ sở của cấu trúc này là mục tiêu đã được xác định rõ ràng ngay từ lúc ký hợp đồng.
Dự án FDE không thể vận hành theo khuôn mẫu này. Câu nói thường gặp nhất từ khách hàng là: “Tôi biết AI chắc chắn có thể giúp tôi làm điều gì đó, nhưng tôi chưa biết chính xác đó là gì.” Mục tiêu bản thân đã là một phần của dự án. Vì vậy, FDE không nhận SOW, mà nhận “mission” — một định hướng tương đối mơ hồ; sau đó dùng các vòng lặp (iteration) để làm rõ dần định hướng đó; và cuối cùng, trong một vòng lặp cụ thể nào đó, hiện thực hóa hiểu biết tích lũy được về mô hình thành một hình thái sản phẩm cụ thể.
Dòng “sản phẩm bàn giao” cũng đáng được làm rõ. Sau khi FDE rời đi, điều còn lại trong hệ thống khách hàng là một chức năng thực sự vận hành được — có thể rất nhỏ, có thể xấu xí, có thể không có giao diện người dùng, nhưng nó thực sự được người dùng gọi đến mỗi ngày, được người dùng chỉnh sửa và thậm chí bị người dùng chê bai. Sản phẩm bàn giao của tư vấn là slide PowerPoint và báo cáo quản trị thay đổi (change management report), ngay cả khi dự án có viết mã hoặc cấu hình ERP, thì thứ cuối cùng nằm trong tay lãnh đạo cấp cao của khách hàng vẫn chỉ là một tài liệu phương pháp luận.
Dòng “hào quang bảo hộ” (moat) là tinh tế nhất. Hào quang bảo hộ của FDE là cảm giác trực quan, cập nhật liên tục về ranh giới khả năng của mô hình — bạn đã chạy bao nhiêu tình huống khách hàng thực tế trong tháng này, thì bạn càng hiểu rõ hơn người khác điều gì Claude 4.7 có thể làm và điều gì phải đợi đến Claude 5. Cảm giác này không thể đưa vào slide PowerPoint, cũng không thể lưu vào cơ sở tri thức — nó chỉ có thể phát triển trong bộ não của một kỹ sư đã thực sự “động tay” trong 90 ngày gần nhất.
Vì vậy, lần tới khi ai đó nói “FDE chẳng qua chỉ là phiên bản mới của Accenture”, bạn có thể trả lời như sau: kỹ sư của Accenture đến để thiết kế lại quy trình của khách hàng, còn FDE đến để khám phá lại ranh giới của mô hình. Tài sản của bên trước có thể tích lũy trong mười năm, còn tài sản của bên sau phải “mọc lại” sau mỗi 90 ngày.
FDE không phải ngoại包 phần mềm: Khám phá chung vs. Hiện thực hóa yêu cầu
Nếu “FDE là phiên bản mới của Accenture” là sự nhầm lẫn ở tầng thứ nhất, thì “FDE là ngoại包 phần mềm đắt tiền” là sự nhầm lẫn ở tầng thứ hai. Lớp nhầm lẫn này còn gây hiểu lầm hơn, bởi các bằng chứng bề ngoài trông rất thuyết phục: FDE thực sự đến hiện trường khách hàng để viết mã, thực sự tùy chỉnh chức năng theo nghiệp vụ khách hàng, và thực sự bị khách hàng điều phối thời gian làm việc. Nhìn thoáng qua, dường như chẳng khác gì kỹ sư ngoại包.
Nhưng chỉ cần nhìn vào cơ chế phản hồi (feedback loop), sự khác biệt sẽ lộ rõ.
Sự khác biệt then chốt trong sơ đồ này không nằm ở phần trên đơn giản đến đâu, mà nằm ở phần dưới — nơi có thêm một chuỗi phản hồi kéo dài về phía công ty mô hình. Chuỗi phản hồi này không phải trang trí, mà chính là lý do tồn tại thực sự của vị trí FDE. Khi phân tích sâu hơn sự khác biệt này, ít nhất có bốn cặp so sánh.
Thứ nhất, điều được nhận vào khác nhau. Ngoại包 nhận SOW — một danh sách yêu cầu đã được xác định rõ ràng trước khi ký hợp đồng: phải làm những chức năng nào, dùng stack công nghệ nào, nghiệm thu theo tiêu chuẩn nào, vi phạm thì bồi thường thế nào. FDE nhận “mission” — khách hàng bản thân cũng chưa rõ mình muốn gì, chỉ biết “AI chắc chắn có thể giúp tôi làm điều gì đó”. SOW dựa trên tiền đề của tính xác định, còn mission dựa trên tiền đề của sự khám phá. Hai tư thế khởi động dự án hoàn toàn khác nhau.
Thứ hai, phạm vi công việc khác nhau. Ngoại包 thực hiện giao hàng cục bộ — một module, một website, một pipeline dữ liệu, làm xong thì bàn giao và rời đi, sang khách hàng khác. FDE thực hiện giao hàng đầu cuối (end-to-end) — từ đau điểm nghiệp vụ, đến lựa chọn mô hình, thiết kế hình thái sản phẩm, đến tỷ lệ giữ chân người dùng (retention) và tỷ lệ rời bỏ (churn) sau khi ra mắt.
Thứ ba, cách tính phí khác nhau. Điều này phản trực quan nhất. Một công ty mô hình cử FDE vào hiện trường khách hàng, cuối cùng quan tâm không chỉ là khoản phí tư vấn thu được từ dự án này, mà còn là: khách hàng này sắp tới sẽ tiêu thụ bao nhiêu token? Liệu họ có trở thành khách hàng giữ chân (retention customer)? Có mở rộng sang nhiều mảng nghiệp vụ khác không? KPI thực sự của FDE là đường cong tiêu thụ token dài hạn của mô hình, chứ không phải con số trên biên bản nghiệm thu dự án.
Thứ tư, hướng phản hồi khác nhau. Đây là cặp so sánh sâu sắc nhất. Trong dự án ngoại包, phản hồi từ khách hàng chỉ đi xa nhất tới công ty ngoại包, và sẽ không ảnh hưởng đến sản phẩm mà công ty này bán cho khách hàng khác trong tương lai. Còn phản hồi từ FDE lại chảy ngược về lộ trình phát triển (roadmap) của công ty mô hình — mỗi “cái坑” (pitfall), mỗi lần prompt thất bại, mỗi lỗi gọi công cụ mà khách hàng gặp phải trong tình huống thực tế đều sẽ trở thành đầu vào cho dữ liệu huấn luyện phiên bản tiếp theo, thiết kế công cụ phiên bản tiếp theo và chức năng sản phẩm phiên bản tiếp theo. Nói cách khác, mỗi khách hàng được FDE triển khai đều đồng thời là một đối tác thiết kế (design partner) tự nhiên đối với công ty mô hình.
Đây mới chính là lý do thực sự khiến các công ty mô hình sẵn sàng trả lương cao để tuyển FDE. Họ không chỉ đang bán một dịch vụ, mà còn đang thu thập tín hiệu về hình thái sản phẩm trong thế giới thực ngay tại hiện trường khách hàng. Những tín hiệu này không thể mua được, không thể thu thập được, và cũng không thể lấy được qua khảo sát — chúng chỉ có thể do một kỹ sư cụ thể, trong một quy trình nghiệp vụ cụ thể của khách hàng, đích thân va chạm vài lần rồi mang về.
Bạn có biết tổng gói lương (total compensation) của FDE tại OpenAI và Anthropic có thể lên tới mức nào không? Dựa trên dữ liệu công khai về kỹ sư phần mềm (SDE) của Anthropic trên Levels.fyi[8], mức lương trung vị cho vị trí SDE cấp cao đã đạt 710.000 USD. Vị trí FDE có rủi ro cao hơn — vừa phải đối mặt với sự bất định về khả năng mô hình, vừa phải đối mặt với sự bất định về nghiệp vụ khách hàng, lại vừa phải chịu trách nhiệm về sự bất định về hình thái sản phẩm. Do đó, theo báo cáo tổng hợp ngành[9], tổng gói lương cho FDE cấp trung – cao tại các phòng thí nghiệm AI tiên phong thường dao động từ 350.000 – 550.000 USD, còn cấp Staff trở lên có thể đạt trên 630.000 USD. Con số này không phải để trả cho “giờ công ngoại包”, mà là để trả cho người chịu trách nhiệm tổng hợp ba loại rủi ro: “sản phẩm + khách hàng + mô hình”.
> Nhớ lại năm 2006, khi tôi vừa tốt nghiệp và gia nhập một tập đoàn nhà nước, lúc ấy tập đoàn đang tiến hành chuyển đổi số hóa. Thời điểm đó, tập đoàn mời các cố vấn của Accenture đến làm việc tại chỗ, và phải trả cho Accenture phí tư vấn 3.500 Nhân dân tệ mỗi ngày, kéo dài suốt nhiều năm — thời ấy được báo chí gọi là “lớp lãnh đạo vàng”. Sau đó tôi chuyển sang làm việc cho SAP Đức, và SAP thậm chí còn định nghĩa hẳn một ngành tư vấn mang tên mình — các cố vấn tư vấn SAP trở thành biểu tượng của “lớp lãnh đạo vàng”. Như vậy, mức lương của FDE ít nhất sẽ tiếp tục tăng trong vòng 24–36 tháng tới, đồng thời nhu cầu tuyển dụng cũng sẽ ổn định tăng lên.
Ngoại包 là khai thác chênh lệch lao động, còn FDE là thiết bị cảm biến tiền tuyến. Nhầm lẫn hai khái niệm này sẽ khiến khách hàng lầm tưởng rằng có thể tuyển FDE theo cách thức SOW, và khiến ứng viên tiếp cận FDE với tư thế của một kỹ sư ngoại包. Cả hai bên đều sẽ nhanh chóng vấp ngã.
Hai gốc rễ quốc tế của FDE: Palantir và các công ty mô hình thế hệ mới
Nhiều người lầm tưởng rằng từ “FDE” do OpenAI sáng tạo ra. Thực tế không phải vậy. Nó có hai gốc rễ lịch sử: một bắt nguồn từ Palantir, một bắt nguồn từ các công ty mô hình thế hệ mới sau năm 2023. So sánh hai gốc rễ này song song sẽ giúp ta hiểu rõ hơn FDE thực sự đang làm gì.
Hãy xem một dòng thời gian.
Gốc rễ thứ nhất là Palantir.
Palantir được thành lập năm 2003 bởi Peter Thiel, Alex Karp, Joe Lonsdale và một số người khác, khách hàng đầu tiên là các cơ quan tình báo Hoa Kỳ. Bản thân Karp không có nền tảng khoa học máy tính (CS) — ông từng theo học tiến sĩ triết học dưới sự hướng dẫn của nhà triết học Jürgen Habermas tại Frankfurt, sau đó mới được Thiel mời về Mỹ đảm nhận vị trí CEO. Chính từ sự kết hợp “CEO phi truyền thống + khách hàng có tính bảo mật cao” này mà vị trí FDE đã được “ép” ra đời: bài hồi cố của 36Kr[10] viết rất rõ ràng — giai đoạn đầu, Palantir bị các cơ quan tình báo chỉ trích nặng nề, lý do là kỹ sư của họ không tiếp cận được tình huống nghiệp vụ thực tế, và yêu cầu sau khi được dịch qua nhiều tầng đã bị bóp méo. Sau đó, Palantir đã thương lượng thành công một thỏa thuận — cho phép kỹ sư của mình trực tiếp vào hiện trường khách hàng, làm việc cùng các nhà phân tích tình báo. Mô hình này sau đó được Shyam Sankar hệ thống hóa, từ đó hình thành nên tiền thân của FDE.
Đến năm 2009, FDE mở rộng sang lĩnh vực thương mại. Khi JPMorgan triển khai nền tảng Metropolis của Palantir, 120 kỹ sư FDE đã vào làm việc tại chỗ để giám sát các mối đe dọa nội bộ. Từ thời điểm này, FDE không còn chỉ đơn thuần là “gửi kỹ sư đi công tác”, mà đã trở thành một chiến lược tích hợp khách hàng có hệ thống: đưa các nền tảng Foundry/Gotham thực sự vận hành trong quy trình nghiệp vụ của khách hàng, chứ không chỉ đơn thuần cấp giấy phép (license) rồi rời đi.
Việc tuyển dụng FDE của Palantir có một tiêu chuẩn phản trực quan — không yêu cầu bằng cử nhân CS. Điều này có thể đưa vào mục “Bạn có biết không?”.
Bạn có biết không — FDE của Palantir không yêu cầu bằng cử nhân CS? Theo tiêu chuẩn tuyển dụng Palantir được tổng hợp bởi SkillScouter[11] và trang tuyển dụng chính thức của Palantir[12], Palantir rõ ràng hoan nghênh ứng viên không chuyên CS, và gần đây những người được tuyển làm FDE đến từ các ngành như kỹ thuật cơ khí, kinh tế học, triết học, v.v. Hai yếu tố Palantir thực sự sàng lọc là: khả năng hành động trong điều kiện thông tin không đầy đủ, và khả năng đối thoại trực tiếp với lãnh đạo cấp C của khách hàng. Bằng cử nhân CS là một lợi thế, chứ không phải tấm vé vào cửa. Bản thân Karp chính là ví dụ đầu tiên cho tiêu chuẩn này — một CEO học triết học, dẫn dắt một đội ngũ FDE học vật lý, toán học và triết học.
Gốc rễ thứ hai là các công ty mô hình thế hệ mới sau năm 2023.
Sau khi ChatGPT ra mắt vào cuối năm 2022, OpenAI nhanh chóng nhận ra một điều: chỉ cần đăng API mô hình lên tài liệu và để khách hàng tự kết nối là hoàn toàn bất khả thi. Khách hàng không phải không muốn dùng, mà là không biết cách dùng — họ có vấn đề nghiệp vụ, nhưng lại thiếu hình thái sản phẩm. Vì vậy, một loạt công ty gồm OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia và Decagon bắt đầu tuyển dụng FDE với quy mô lớn.
Thế hệ FDE mới này học theo “sổ tay” của Palantir — gửi kỹ sư đến hiện trường khách hàng để chạy trọn vẹn một quy trình công việc. Nhưng phương tiện sản phẩm đã hoàn toàn khác: FDE thời Palantir tập trung vào tích hợp dữ liệu và tùy chỉnh giao diện người dùng (UI), còn FDE thế hệ mới tập trung vào thiết kế prompt, sắp xếp agent, gọi công cụ và tích hợp vào quy trình làm việc.
Bài viết chuyên sâu về FDE của Pragmatic Engineer[13] gọi phiên bản mới này là “được tích hợp sâu vào doanh nghiệp để khiến Claude giải quyết những vấn đề thực tế, cụ thể và có giá trị cao” — cách diễn đạt gần như giống hệt thời Palantir, chỉ thay “dữ liệu” bằng “mô hình”.
Khi đặt hai gốc rễ này cạnh nhau, ta thấy một tập hợp điểm chung và khác biệt rất rõ ràng.
Điểm chung: khách hàng không mua phần mềm. Khách hàng mua là “kỹ sư có thể giải quyết vấn đề của tôi + bộ công cụ đi kèm”. Trong suốt ba mươi năm lịch sử phần mềm doanh nghiệp, điều này thực tế là một hiện tượng phản thường. SAP, Oracle, Salesforce bán chính là phần mềm — kỹ sư chỉ là nguồn lực hỗ trợ để “giúp khách hàng có thể sử dụng phần mềm này”. Palantir lại làm ngược lại: công cụ tồn tại để “hỗ trợ FDE giải quyết vấn đề tại hiện trường khách hàng”. Các công ty mô hình thế hệ mới kế thừa mối quan hệ đảo ngược này — OpenAI không bán giấy phép GPT-4, mà bán “đội FDE của chúng tôi có thể dùng GPT-4 giúp bạn tự động hóa bộ phận chăm sóc khách hàng”.
Sự khác biệt: thời Palantir thiên về tích hợp OPS — trọng tâm là tích hợp dữ liệu, xây dựng mô hình thực thể (ontology modeling), quản trị quyền truy cập. Thế hệ mới thiên về hiện thực hóa khả năng mô hình — trọng tâm là thiết kế prompt, sắp xếp agent, tối ưu tỷ lệ giữ chân (retention). Bên trước giống một phiên bản nâng cao của nhà tích hợp hệ thống, bên sau giống một phiên bản mở rộng của kỹ sư sản phẩm.
Cuối cùng còn một sự thật thú vị: nhiều FDE đầu tiên của Palantir sau này trở thành nhà khởi nghiệp, hoặc trực tiếp gia nhập các công ty mô hình thế hệ mới. Trong các đội ngũ sáng lập của Anthropic, OpenAI, Sierra và Hebbia, ta có thể dễ dàng liệt kê một danh sách dài những cái tên từng làm việc tại Palantir. Đây không phải là ngẫu nhiên — vị trí FDE bản thân nó đã buộc một người đồng thời đảm nhận rủi ro sản phẩm, rủi ro khách hàng và rủi ro kỹ thuật, gần như chính là một khóa huấn luyện khởi nghiệp. Tôi thậm chí còn muốn coi Palantir như một “trại huấn luyện khởi nghiệp vô hình”: nó không chỉ đào tạo ra các kỹ sư, mà còn nuôi dưỡng một nhóm người biết cách thúc đẩy một việc từ con số 0 đến 1 trong điều kiện thông tin không đầy đủ. Hai gốc rễ, cuối cùng hội tụ vào năm 2023 trở đi.
FDE tại Trung Quốc: Từ kỹ sư kiến trúc giải pháp đến kỹ sư triển khai AI
Sự hội tụ của hai gốc rễ này chủ yếu xảy ra ở nước ngoài. Tại Trung Quốc, từ “FDE” xuất hiện chưa lâu, nhưng nội dung công việc tương ứng không phải là điều xuất hiện từ hư không. Để hiểu FDE tại Trung Quốc, ta cần nhìn rõ hai tiền thân bản địa của nó, rồi nhìn rõ ba khác biệt do điều kiện “thủy thổ” gây ra so với phiên bản FDE tại Mỹ.
Hai tiền thân bản địa
Tiền thân thứ nhất là kỹ sư kiến trúc giải pháp (Solution Architect – SA) của các nhà cung cấp điện toán đám mây. Trong mười năm qua, Alibaba Cloud, Tencent Cloud và Huawei Cloud đã xây dựng một đội ngũ Solution Architect (SA) hoàn chỉnh, chuyên trình bày kiến trúc cho khách hàng, viết POC, lập kế hoạch di chuyển và phối hợp triển khai đến khi bàn giao. Huawei thậm chí còn có một chuỗi “kỹ sư triển khai” chuyên biệt phụ trách việc đưa dự án vào phòng máy chủ của khách hàng. Hệ thống này đã thực hiện tới 80% công việc của FDE, nhưng trọng tâm vẫn nằm ở khâu tiền bán hàng và triển khai — trách nhiệm cải tiến sản phẩm đầu cuối (end-to-end) không thuộc về SA, việc thay đổi yêu cầu phải đi qua quy trình thay đổi, và việc cập nhật mô hình phải chờ lịch trình từ trụ sở.
Tiền thân thứ hai là chuỗi vị trí mới xuất hiện trong các công ty khởi nghiệp AI. MiniMax đang đăng tuyển “Chuyên gia giải pháp tiền bán hàng AI” trên BOSS Zhipin, còn các công ty mô hình như Moonshot, Zhipu, Tongyi và Hunyuan cũng đang đăng tuyển các vị trí tương tự. Tên gọi có chút khác biệt, nhưng mô tả công việc (JD) lại rất đồng nhất: hiểu bối cảnh khách hàng, làm demo, điều chỉnh prompt, chạy RAG, viết phương án bàn giao, phối hợp với đội kỹ thuật khách hàng đến khi triển khai xong. Chính nhóm vị trí này mới thực sự là “FDE nội địa”.
Ba khác biệt do điều kiện “thủy thổ”
Triển khai riêng tư (private deployment) và yêu cầu tuân thủ dữ liệu khiến mô hình thuần túy chỉ gọi API trở nên bất khả thi. Khách hàng B2B tại Trung Quốc có yêu cầu cao hơn thị trường Mỹ rất nhiều về việc dữ liệu không được rời khỏi phạm vi nội bộ, trọng số mô hình phải kiểm soát được và quá trình kiểm toán phải truy vết được. Trong một dự án FDE, công việc thuần túy gọi API và chạy prompt có thể chỉ chiếm 30%, còn lại 70% là việc đưa mô hình vào phòng máy chủ của khách hàng, vận hành thành công cơ chế xác thực (auth), tích hợp với nền tảng dữ liệu trung tâm (data mid-platform) và thực hiện các thủ tục tuân thủ.
Khả năng mô hình vẫn đang chạy đua để bắt kịp SOTA, nên không gian thể hiện bị thu hẹp xuống tầng kỹ thuật. Tại Mỹ, OpenAI và Anthropic có thể dùng chính khả năng mô hình để chinh phục khách hàng; trong khi các mô hình nội địa như Tongyi, Doubao, Kimi, GLM và DeepSeek chưa có sự khác biệt rõ rệt về khả năng, nên khách hàng đánh giá chủ yếu dựa trên các năng lực kỹ thuật như sắp xếp agent, chất lượng truy xuất RAG, tích hợp công cụ và thiết kế quy trình làm việc (Workflow). FDE nội địa không cạnh tranh bằng “mô hình nhà tôi mạnh thế nào”, mà bằng “tôi có thể thực sự chạy thông nghiệp vụ này hay không”.
Khả năng chi trả và nhịp độ định giá cho khách hàng B2B tại Trung Quốc không giống với Mỹ. Mô hình của Palantir — “trước hết cử FDE vào hiện trường, sau đó thu phí đăng ký cao” — rất khó sao chép trực tiếp. Ngân sách của khách hàng nội địa gắn chặt với quy trình mua sắm hàng năm, việc thanh toán thiên về mô hình dự án, nên mô hình thương mại của FDE thường là sự kết hợp giữa đăng ký, cấp phép triển khai riêng tư và bàn giao dự án.
Một vị trí đặc thù: FDE nội bộ
Nhiều công ty lớn đang áp dụng mô hình FDE để phục vụ “khách hàng nội bộ”. PAI của Alibaba Cloud cử kỹ sư vào làm việc tại Taobao, còn mô hình Hunyuan của Tencent cũng có cơ chế tương tự để phối hợp với WeChat và các mảng kinh doanh quảng cáo. Trên các trang tuyển dụng, vị trí này được đăng với tên gọi như “Kỹ sư triển khai ngành”, “Kỹ sư ứng dụng AI”, “Chuyên gia kinh doanh thông minh”, thực chất chính là FDE nội bộ — đưa năng lực của đội mô hình chạy trọn vẹn đến phía nghiệp vụ. Điều này mở ra một góc nhìn mới cho các nhà lãnh đạo công ty lớn: chỉ cần vài FDE nội bộ “đóng quân” tại phía nghiệp vụ, chạy thành công demo đầu tiên và nộp dữ liệu ROI cho lãnh đạo nghiệp vụ, bức tường ngăn cách giữa các phòng ban sẽ tan biến nhanh hơn nhiều so với việc tổ chức mười cuộc họp đồng bộ hóa.
Ai phù hợp làm FDE, ai không phù hợp
Trong bài viết trước — “Gửi tới những cá nhân siêu việt”[4] — tôi đã nói về năm “động cơ” của cá nhân siêu việt: tò mò mạnh, tinh thần khám phá và đổi mới mạnh, tự học tốt, tự chủ cao và thực hành giỏi. Năm yếu tố này là “vé vào cửa” cho FDE, nhưng chưa phải là tất cả. Ngoài năm “động cơ” này, vị trí FDE còn đòi hỏi một tập hợp đặc điểm cụ thể rất rõ ràng, đồng thời cũng có một số kiểu tính cách rõ ràng không phù hợp. Tôi đã chứng kiến quá nhiều kỹ sư xuất sắc chuyển sang FDE nhưng lại “không hòa hợp với môi trường”, và vấn đề thường không nằm ở năng lực, mà ở tính cách và sở thích làm việc.
Năm đặc điểm phù hợp với FDE
Không ngại bán hàng và giao tiếp. Công việc thường ngày của FDE không phải là đóng cửa viết mã, mà là giao tiếp trực tiếp với CTO, người phụ trách nghiệp vụ, bộ phận mua sắm, tuân thủ và IT của khách hàng. Một nhịp làm việc điển hình: CTO khách hàng ngắt giữa buổi demo, phản ứng của FDE không được là “tôi về sửa một bản, tuần sau quay lại”, mà phải ngay lập tức mở IDE, chỉnh prompt và chạy lại ngay tại chỗ cho họ xem. “Khách hàng có mặt, tôi đang sửa” là trạng thái bình thường của FDE.
Thích thú với vùng mờ. FDE không nhận được một tài liệu yêu cầu sản phẩm (PRD) rõ ràng, mà chỉ nhận được một câu nói như “chúng tôi muốn dùng AI làm điều gì đó”. Chính khách hàng cũng chưa rõ mình muốn gì, và FDE phải đồng hành cùng họ để biến kỳ vọng mơ hồ này thành một hình thái cụ thể. Nếu bạn chỉ có thể hành động khi có yêu cầu rõ ràng, FDE sẽ khiến bạn cảm thấy lo âu mỗi ngày.
Năng lực kỹ thuật vững vàng nhưng không cần đạt trình độ “10x”. FDE không yêu cầu bạn là người viết mã sạch nhất hay hiểu thuật toán sâu nhất trong công ty; điều nó cần là khả năng chạy trọn vẹn một vòng: frontend có thể “vẽ tạm” một giao diện có thể nhấn được, backend có thể dựng một dịch vụ có thể chạy được, và mô hình có thể kết nối với nguồn dữ liệu nghiệp vụ. Trong thế giới FDE, “cũng được thôi” không phải là điểm yếu, mà là một đức tính.
Thích được rèn giũa qua phản hồi. Công việc FDE có rất nhiều khoảnh khắc “bị khách hàng chê, phải làm lại từ đầu”: demo hôm nay ngày mai bị bộ phận nghiệp vụ nói “đây không phải thứ tôi cần”; phương án đã đồng bộ tuần trước, tuần này khách hàng thay đổi lãnh đạo cấp cao nên lại phải làm lại. Người phù hợp với FDE sẽ coi phản hồi này như nhiên liệu, sẵn sàng chịu trách nhiệm đầu cuối và không đổ lỗi cho “bên yêu cầu chưa nói rõ”.
Nhạy bén với ranh giới mô hình. Đây là đặc điểm kỹ thuật nhất và cũng ẩn tàng nhất. FDE phải có khả năng đánh giá nhiệm vụ nào nên giao cho LLM xử lý, nhiệm vụ nào không nên, và nên xử lý dự phòng (fallback) thế nào — độ nhạy này không thể học từ bài báo, mà chỉ có thể rèn luyện qua các tình huống thất bại. Khi tích lũy đủ các mẫu thất bại, FDE sẽ hình thành “trí nhớ cơ bắp” về ranh giới mô hình: tình huống nào nên dùng RAG, tình huống nào nên dùng quy tắc, tình huống nào bắt buộc phải để con người có một cổng vào dự phòng.
Bốn kiểu người không phù hợp với FDE
Người kỹ thuật thuần túy muốn “ẩn mình” trong mã nguồn. Khoảng 50% thời gian của FDE không dành để viết mã — mà dành cho các cuộc họp khách hàng, điều phối nội bộ, thảo luận sản phẩm và thúc đẩy hợp đồng. Nếu niềm vui của bạn đến từ việc viết mã liên tục bốn tiếng đồng hồ mà không bị ai làm phiền, FDE sẽ khiến bạn rơi vào tình trạng kiệt sức tinh thần kéo dài.
Người chỉ hành động khi có OKR. Mục tiêu của FDE nằm ở phía khách hàng, chứ không nằm trong bảng đánh giá hiệu suất cá nhân. Tiến độ công việc do các mốc dự án của khách hàng, sự thay đổi khả năng mô hình và đánh giá cá nhân về tình huống cùng quyết định. Người quen “phải có OKR trước rồi mới biết mình cần làm gì” sẽ không tìm được điểm neo.
Người coi “thăng tiến” quan trọng hơn “tác phẩm”. FDE không có lợi thế trong hệ thống thăng tiến của các công ty lớn — các chỉ số như mức độ hài lòng của khách hàng, tỷ lệ ký hợp đồng, tỷ lệ tái sử dụng… khi so với số lượng mã viết ra hay tần suất triển khai, thường không thuyết phục được hội đồng đánh giá cấp bậc. Nếu động lực làm việc của bạn đặt thăng tiến lên hàng đầu, FDE không phải lựa chọn tốt.
Người phản kháng bối cảnh thương mại. FDE bắt buộc phải hiểu báo cáo lợi nhuận – lỗ (P&L), ROI, quy trình mua sắm và yêu cầu tuân thủ của khách hàng. Nếu bạn phản cảm tự nhiên với việc nói chuyện về tiền bạc, hợp đồng và logic thương mại, công việc FDE sẽ khiến bạn cảm thấy mình đang phản bội lý tưởng kỹ thuật.
Danh sách tự kiểm tra (Self-Check)
7 câu hỏi, mỗi câu tương ứng với một tình huống công việc thực tế của FDE. Trả lời “Có” cho 5 câu trở lên thì bạn có thể nghiêm túc cân nhắc FDE; trả lời “Có” cho dưới 3 câu thì hãy cân nhắc kỹ.
1. Bạn có sẵn sàng chuyển 50% thời gian mỗi ngày từ viết mã sang các cuộc họp khách hàng, trả tin nhắn và gọi điện thoại không?
2. Khi khách hàng nói với bạn “cái này không ổn, nhưng tôi cũng không rõ vì sao”, phản ứng đầu tiên của bạn là tò mò hay bực bội?
3. Không ai viết PRD cho bạn, bạn có thể tự cùng Claude Code chạy thông một prototype có thể trình bày cho khách hàng trong vòng một tuần không?
4. Cùng một sản phẩm bàn giao, khách hàng yêu cầu bạn chỉnh sửa 8 phiên bản, bạn vẫn giữ được khả năng phán đoán chứ không chỉ thực hiện máy móc?
5. Khi mô hình đưa ra câu trả lời sai, phản ứng đầu tiên của bạn là thiết kế cơ chế dự phòng, hay phàn nàn về mô hình?
6. Bạn có sẵn sàng ký hợp đồng, viết báo cáo, chạy nghiệm thu với khách hàng, và làm việc với pháp chế về các điều khoản tuân thủ không?
7. Bạn có chấp nhận nguyên mẫu nhanh (rapid prototyping) và thất bại nhanh (rapid failure) không?
Năm đặc điểm, bốn kiểu phản diện, bảy câu hỏi tự kiểm tra — cuối cùng đều xoay quanh cùng một câu hỏi: Bạn có sẵn sàng để cảm quan sản phẩm, năng lực kỹ thuật và phán đoán thương mại của mình cùng được rèn giũa trong cùng một quy trình làm việc không?
Kết luận: Từ cá nhân siêu việt đến vị trí siêu việt
Trong bài viết trước, tôi thảo luận về “động cơ con người”: sự tò mò, tinh thần khám phá, khả năng tự học, tinh thần tự chủ và năng lực thực hành — làm thế nào để những yếu tố này được khơi dậy một cách toàn diện trong một vòng khép kín bên trong các công ty lớn. Bài viết này thảo luận về một vấn đề khác — hình thái vị trí. FDE là hình thái vị trí mới đầu tiên trong cuộc cách mạng công nghiệp AI có tên gọi rõ ràng, có dải lương xác định, có mô tả công việc (JD) cụ thể và được khách hàng trả tiền để xác nhận. Nó không phải là từ đồng nghĩa với khái niệm “cá nhân siêu việt”, mà là tọa độ đầu tiên chuyển từ lý thuyết sang hiện thực trong đợt tái cấu trúc này.
FDE không phải là điểm kết thúc. Theo đánh giá của tôi, FDE chỉ là hình thái đầu tiên trong một cấu trúc phân công lao động mới được đặt tên. Phía sau sẽ còn xuất hiện Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher — tất cả các vị trí gắn bó chặt chẽ với bối cảnh khách hàng và cần “nuôi lớn” sản phẩm trong vùng mờ đều sẽ xuất hiện phiên bản “triển khai tiền tuyến” của riêng mình. Tên gọi vị trí có thể thay đổi, nhưng logic nền tảng là như nhau: khả năng mô hình chạy ở phía trước, hình thái sản phẩm đuổi theo phía sau, và cấu trúc vị trí sẽ được cắt lại theo quy trình làm việc.
Tôi xin để lại một câu nói ngắn cho ba nhóm độc giả.
Dành cho người làm kỹ thuật: FDE không yêu cầu bạn là người viết mã giỏi nhất trong công ty, nhưng nó yêu cầu bạn sẵn sàng chuyển một nửa thời gian từ viết mã sang phía khách hàng. Nếu câu trả lời của bạn là “sẵn sàng”, thì cơ hội thị trường vừa mới mở ra — các công ty mô hình hàng đầu trong nước, các nhà cung cấp điện toán đám mây và các đội AI nội bộ của các công ty lớn đều đang đẩy nhanh tuyển dụng. Nếu câu trả lời là “không sẵn sàng”, thì cũng chẳng sao cả — trong cấu trúc phân công lao động mới vẫn sẽ xuất hiện những vị trí khác dành riêng cho bạn.
Dành cho HR và OD: Hãy cảnh giác với hiện tượng “danh thực bất phù”. Có thể công ty bạn đã có một nhóm FDE đang làm việc, nhưng mã vị trí của họ lại đang ghi là “Chuyên gia giải pháp”, “Kiến trúc sư ngành” hay “Kỹ sư ứng dụng AI”. Nhận diện họ, phân loại lại và xây dựng cho họ một lộ trình phát triển phù hợp với nội dung công việc — điều này hiệu quả hơn nhiều so với việc tuyển mới từ đầu.
Dành cho nhà quản lý: Mô hình FDE không chỉ áp dụng được bên ngoài, mà còn có thể áp dụng nội bộ. Thiết lập một vài “FDE nội bộ” tại các mảng nghiệp vụ, đưa năng lực của đội mô hình chạy trọn vẹn vào quy trình nghiệp vụ, có thể hiệu quả hơn nhiều so với việc thành lập một phòng AI mới rồi tổ chức mười cuộc họp đồng bộ hóa liên phòng ban. Bức tường ngăn cách giữa các phòng ban không bị xóa bỏ bởi thiết kế tổ chức, mà bị xóa bỏ bởi một bản demo thực sự chạy thông được.
Cuộc chuyển đổi nghề nghiệp trong kỷ nguyên AI đã chính thức bắt đầu, và FDE là phát tín hiệu đầu tiên — nó cho chúng ta biết: tốc độ thay đổi khả năng mô hình đã nhanh đến mức buộc phải sinh ra những vị trí mới. Tôi muốn để lại một câu hỏi cụ thể cho bạn đọc — nếu ba năm nữa, trên sơ đồ tổ chức công ty bạn xuất hiện thêm ba vị trí mới, bạn đoán đó sẽ là ba vị trí nào? Việc suy ngẫm rõ ràng câu hỏi này sẽ hữu ích hơn nhiều so với việc chỉ đọc xong bài viết này.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
