Meta và Google bị kết tội về thiết kế gây nghiện: Đằng sau những dòng code "bẫy" người dùng
Một phán quyết pháp lý mới đây đã buộc Meta và Google phải chịu trách nhiệm về việc thiết kế các tính năng "gây nghiện" như cuộn vô tận và tự động phát video. Bài viết sẽ phân tích các đoạn mã cụ thể tạo ra những mô hình hành vi này và đặt ra câu hỏi về đạo đức nghề nghiệp của các kỹ sư phần mềm.
Một bồi thẩm đoàn đã làm những gì Quốc hội Mỹ không thể làm được. Nhiều năm qua diễn ra các phiên điều trần tại Thượng viện, các tài liệu rò rỉ từ người tố giác và vô số bài báo phẫn nộ, nhưng tất cả đều như "đổ sông đổ biển". Nhưng rồi, mười hai người bình thường trong một phòng xử án đã nhìn vào cách Instagram và YouTube được xây dựng, nhìn vào những thiệt hại mà những thiết kế đó gây ra cho một phụ nữ trẻ, và tuyên bố: Các ông đã làm điều này cố ý.
Meta và Google hiện đang phải chịu trách nhiệm pháp lý về việc thiết kế các nền tảng của họ theo hướng gây nghiện. Không phải vì lưu trữ nội dung xấu, mà vì cách họ kỹ thuật hóa chính trải nghiệm người dùng.
Sự phân biệt này cực kỳ quan trọng. Bởi vì mọi lập trình viên đang đọc bài viết này đều từng phát hành một phiên bản nào đó của những mô hình này.
Vấn đề thực sự được đưa ra xét xử
Nguyên đơn không lập luận rằng mạng xã hội là xấu. Luật sư của họ đã tấn công vào một điểm rất cụ thể: Meta và Google cố ý thiết kế các tính năng để tối đa hóa mức độ tương tác ngay cả khi các nghiên cứu nội bộ cho thấy những tính năng đó gây hại về mặt tâm lý cho người dùng trẻ tuổi.
Các tài liệu nội bộ đã chứng minh cả hai công ty đều biết điều này. Các kỹ sư và nhà nghiên cứu bên trong tổ chức đã báo cáo về vấn đề này. Ban lãnh đạo vẫn chọn các chỉ số tương tác thay vì sự an toàn của người dùng. Một bồi thẩm đoàn đã xem những tài liệu đó và đi đến kết luận hiển nhiên.
Đây là phần khiến mọi lập trình viên từng ngồi trong các cuộc họp lập kế hoạch Sprint (sprint planning), nơi "tăng thời gian phiên" (increase session duration) là ưu tiên hàng đầu, phải lo ngại: Các tính năng bị đưa ra xét xử không hề xa lạ. Chúng chính là những mô hình đang nằm trong kho mã (codebase) của bạn ngay lúc này.
Cho tôi xem Code
Đừng nói lý thuyết suông nữa. Hãy xem "thiết kế để gây nghiện" trông như thế nào khi nó được đưa vào sản xuất thực tế.
Cuộn vô tận (Infinite Scroll): Loại bỏ lối thoát
Toàn bộ mục đích của tính năng cuộn vô tận là loại bỏ các điểm ra quyết định. Phân trang (pagination) mang lại cho người dùng một khoảnh khắc tự nhiên để suy nghĩ "Tôi có muốn xem thêm không?". Cuộn vô tận loại bỏ khoảnh khắc đó.
// Mô hình vừa trở thành rủi ro pháp lý
class InfiniteFeed {
constructor(feedElement, api) {
this.feed = feedElement;
this.api = api;
this.loading = false;
this.cursor = null;
// Không có điểm kết thúc. Đó là ý định của nó.
this.hasMore = true;
this.setupObserver();
}
setupObserver() {
// Kích hoạt khi người dùng cách đáy 800px
// Họ không bao giờ thấy kết thúc đang đến. Họ không bao giờ chạm tới nó.
const observer = new IntersectionObserver(
(entries) => {
if (entries[0].isIntersecting && !this.loading) {
this.loadMore();
}
},
{ rootMargin: '800px' }
);
observer.observe(this.feed.querySelector('.sentinel'));
}
async loadMore() {
this.loading = true;
const { posts, nextCursor } = await this.api.getFeed(this.cursor);
this.cursor = nextCursor;
// Lưu ý điều bị thiếu: không có điều kiện nào để hasMore
// trở thành false. API luôn trả về thứ gì đó.
// Hết nội dung mới? Phục vụ nội dung cũ. Hết tài khoản theo dõi?
// Phục vụ nội dung "được gợi ý". Bảng tin không bao giờ kết thúc.
// Người dùng không bao giờ có lý do để dừng lại.
this.renderPosts(posts);
this.loading = false;
}
}
Đoạn rootMargin: '800px' đang làm việc rất nặng nhọc. Nó có nghĩa là nội dung mới được tải lên trước khi người dùng kịp nhận ra họ đang ở gần cuối cùng. Không có đường ghép trong trải nghiệm. Không có khoảng nghỉ. Không có khoảnh khắc "khoan đã, tại sao tôi vẫn ở đây?".
Một bảng tin phân trang với nút "Tải thêm" sẽ hoạt động tốt. Nhưng nó sẽ trao quyền chủ động cho người dùng. Và quyền chủ động sẽ giết chết thời lượng phiên sử dụng.
Tự động phát (Autoplay): Đánh cắp quyết định
Tính năng tự động phát loại bỏ lựa chọn có ý thức để xem video tiếp theo. Khi video trước kết thúc, và trước khi bộ não người dùng kịp xử lý xong ý nghĩ "Tôi xong rồi", video tiếp theo đã chạy sẵn.
class AutoplayEngine {
constructor(player, recommendationAPI) {
this.player = player;
this.recAPI = recommendationAPI;
this.nextVideo = null;
// Tải trước (pre-fetch) video tiếp theo trong khi video hiện tại đang phát.
// Đến khi video này kết thúc, video tiếp theo đã được lưu vào bộ nhớ đệm
// và sẵn sàng chạy ngay lập tức. Độ trễ bằng không bằng
// cơ hội suy nghĩ lại.
this.player.on('timeupdate', () => {
if (this.remainingTime() < 15 && !this.nextVideo) {
this.prefetchNext();
}
});
this.player.on('ended', () => this.playNext());
}
remainingTime() {
return this.player.duration - this.player.currentTime;
}
async prefetchNext() {
// "Video tiếp theo" được chọn bởi dự đoán mức độ tương tác, không phải
// sự liên quan, không phải chất lượng, không phải những gì người dùng tìm kiếm.
const recommendations = await this.recAPI.getNext({
currentVideoId: this.player.videoId,
watchHistory: this.getSessionHistory(),
// Cờ này là thật. Điểm tương tác là khóa sắp xếp.
sortBy: 'predicted_watch_time',
});
this.nextVideo = recommendations[0];
this.preloadVideo(this.nextVideo);
}
playNext() {
// Overlay đếm ngược: "Video tiếp theo trong 5...4...3..."
// Người dùng phải chủ động can thiệp để KHÔNG xem.
// Hành vi mặc định là tiếp tục tiêu thụ.
this.showCountdown(5, () => {
this.player.load(this.nextVideo);
this.player.play();
});
}
}
Hãy đọc lại một lần nữa: Người dùng phải chủ động can thiệp để dừng lại. Mặc định là thêm nội dung mới. Đó không phải là quyết định UX (trải nghiệm người dùng). Đó là cơ chế giữ chân người dùng được ngụy trang dưới sự tiện lợi.
Thời điểm thông báo: Sự cấp bách được kỹ thuật hóa
Điều này tinh vi và có lẽ là hoài nghi nhất. Thông báo không được gửi khi chúng xảy ra. Chúng được gom nhóm và lên lịch để kéo người dùng quay lại trong các khung thời gian dự báo mức độ tương tác thấp.
class NotificationScheduler:
"""
Thông báo không phải là cảnh báo. Chúng là tác kích
tái tương tác. Thời điểm là tất cả.
"""
def schedule(self, user, notification):
# Không thông báo cho người dùng đang hoạt động.
# Đó là lãng phí thông báo. Hãy để dành cho khi
# họ đã vắng mặt quá lâu.
if self.is_currently_active(user):
return self.queue_for_later(user, notification)
# Tìm khoảnh khắc họ có khả năng quay lại nhất
optimal_time = self.predict_reengagement_window(user)
# Nếu họ đã vắng mặt một lúc, hãy tăng cấp độ khẩn cấp
hours_absent = self.hours_since_last_session(user)
if hours_absent > 24:
# "Bạn có 14 thông báo mới" sẽ tạo cảm giác khác biệt
# so với "Ai đó đã thích bài viết của bạn"
notification = self.batch_and_amplify(
user,
min_batch_size=5
)
elif hours_absent > 6:
# Tác kích bằng chứng xã hội: "X và 3 người khác..."
notification = self.add_social_proof(notification)
return self.send_at(notification, optimal_time)
def predict_reengagement_window(self, user):
"""
Mô hình ML được đào tạo trên các mẫu lịch sử của người dùng.
Biết khi nào họ kiểm tra điện thoại. Biết giờ làm việc của họ.
Biết giờ nghỉ trưa. Biết khi nào họ thức dậy.
"""
return self.timing_model.predict(
user_id=user.id,
features=[
user.historical_open_times,
user.timezone,
user.device_usage_pattern,
self.get_current_context(user),
]
)
Trình lập lịch đó không quan tâm đến việc thông báo cho người dùng. Nó được tối ưu hóa cho một điều duy nhất: kéo họ trở lại ứng dụng. Thông báo không phải là thông điệp. Thông báo là cái mồi câu.
Phần thưởng biến đổi: Máy đánh bạc trong túi bạn
Kéo để làm mới (Pull-to-refresh) không phải là một yêu cầu kỹ thuật. API có thể đẩy cập nhật. Nhưng kéo để làm mới tạo ra một vòng lặp phần thưởng biến đổi giống hệt như cần gạt máy đánh bạc.
class PullToRefresh {
onRefresh() {
// Đôi khi là 0 mục mới. Đôi khi là 12.
// Sự không thể đoán trước là tính năng, không phải lỗi.
// Lịch trình củng cố tỷ lệ biến đổi:
// cùng một tâm lý học làm cho cờ bạc gây nghiện.
return this.api.getNewContent().then(items => {
if (items.length === 0) {
// Ngay cả "không có gì mới" cũng củng cố thói quen.
// Người dùng kéo, không được gì, và sẽ
// kéo lại sau 3 phút để kiểm tra.
// Đó không phải là thất bại. Đó là hiệu ứng "gần thắng"
// giữ cho vòng lặp sống động.
this.showEmptyState("Bạn đã xem hết tất cả!");
} else {
// Cú hít Dopamine. Nội dung mới. Số lượng ngẫu nhiên.
// Bộ não ghi nhận đây là một lần kéo thành công
// và tăng khả năng lặp lại.
this.renderNewItems(items);
}
});
}
}
Thông điệp "Bạn đã xem hết tất cả!" nghe có vẻ thân thiện. Nhưng màn hình đó tồn tại để xác nhận việc kiểm tra và khuyến khích lần kiểm tra tiếp theo. Nếu sản phẩm thực sự muốn người dùng ngừng kiểm tra, nó sẽ nói "Không có gì mới. Chúng tôi sẽ thông báo khi có."
Điểm số tương tác (Engagement Score): Nơi mọi thứ kết nối
Dưới bề mặt, mỗi mô hình này đều phục vụ một chỉ số duy nhất. Dưới đây là phiên bản đơn giản hóa của hệ thống tính điểm tương tác:
def calculate_engagement_score(user, content):
"""
Hàm này là mô hình kinh doanh. Mọi thứ khác
chỉ là cơ sở hạ tầng để phục vụ đầu ra của nó.
"""
score = 0.0
# Thời gian xem/đọc dự đoán (tín hiệu chính)
score += predict_consumption_time(user, content) * 0.4
# Khả năng tương tác (thích, bình luận, chia sẻ)
score += predict_interaction(user, content) * 0.25
# Kích hoạt cảm xúc (hưng phấn cao = tương tác cao)
# Sự giận数据和 lo âu đạt điểm cao ở đây. Sự phẫn nộ cũng vậy.
# Đây là nơi vấn đề "nội dung khiêu khỗi trồi lên đầu" sinh sống.
# Nó không phải là lỗi. Nó là một tính năng được trọng số.
score += predict_emotional_activation(user, content) * 0.2
# Xác suất mở rộng phiên
# "Mẩu nội dung này có khiến họ ở lại lâu hơn không?"
score += predict_session_extension(user, content) * 0.15
return score
Hãy chú ý những gì không nằm trong hàm này. Đó là sự an tâm của người dùng (wellbeing). Giá trị thông tin. Liệu nội dung có thực sự tốt hay không. Điểm số tối ưu hóa cho một điều duy nhất: giữ mắt người dùng dán vào màn hình lâu hơn. Mọi thứ khác chỉ là yếu tố bên ngoài.
Một bồi thẩm đoàn đã nhìn vào phép toán này và gọi nó bằng đúng tên của nó.
"Chỉ làm theo thông số kỹ thuật sản phẩm" đã chết
Có một câu chuyện mà các lập trình viên thường tự nhủ: Sản phẩm ra quyết định, kinh doanh đặt mục tiêu, kỹ sư chỉ gõ phím. Đừng trách người chơi đàn piano.
Phán quyết này đã giết chết câu chuyện đó.
Khi một bồi thẩm đoàn nhận thấy rằng thiết kế của sản phẩm là nguồn gốc gây hại, mọi người trong chuỗi thiết kế đều có liên quan. Điều này bao gồm người quản lý sản phẩm (PM) đã viết thông số kỹ thuật, nhà thiết kế đã loại bỏ phân trang, và kỹ sư đã chọn predicted_watch_time làm khóa sắp xếp.
Kỹ sư xây dựng không thể đổ lỗi cho kiến trúc sư khi một tòa nhà sụp đổ do các lỗi cấu trúc được biết đến mà họ vẫn xây dựng không phản đối. Kỹ sư ô tô không thể nấp sau sự quản lý khi họ tung ra một chiếc xe có khiếm khuyết an toàn được biết đến.
Kỹ sư phần mềm vừa gia nhập câu lạc bộ đó.
Cỗ máy khuyến khích
Đây là lý do tại sao vấn đề này không chỉ dành riêng cho Meta và Google.
Toàn bộ nền kinh tế công nghệ được hỗ trợ bởi quảng cáo chạy dựa trên sự chú ý. Sự chú ý nhiều hơn có nghĩa là nhiều quảng cáo hiển thị hơn. Nhiều hiển thị hơn có nghĩa là doanh thu cao hơn. Mọi tính năng làm tăng thời gian trực tiếp trên trang đều làm tăng trực tiếp lợi nhuận của công ty.
Sự thăng tiến được trao cho đội ngũ đã dịch chuyển chỉ số giữ chân. Tiền thưởng gắn liền với sự tăng trưởng của người dùng hoạt động hàng ngày (DAU). Các đánh giá hiệu suất ca ngợi kỹ sư có thuật toán đề xuất giúp tăng thời lượng phiên trung bình 12%.
Sản phẩm có lợi nhất là sản phẩm gây nghiện nhất. Đó không phải là sự đồng thuận. Đó là một mô hình kinh doanh. Và một bồi thẩm đoàn vừa phán quyết rằng mô hình kinh doanh này có thể tạo ra trách nhiệm pháp lý.
Thực tế sẽ thay đổi như thế nào
Bản án đang được kháng cáo. Meta và Google có ngân sách pháp lý gần như vô hạn. Tiền lệ sẽ mất nhiều năm để được định đoạt.
Nhưng tín hiệu đã được đưa ra. Dưới đây là ý nghĩa của nó trong thực tế:
Đánh giá đạo đức trở thành cổng phát hành. Không phải vì các công ty tìm thấy đạo đức, mà vì đội ngũ pháp lý của họ hiện đang định lượng rủi ro trong mọi tính năng tương tác. Hãy mong đợi "đánh giá đạo đức" sẽ ngồi cạnh đánh giá bảo mật và kiểm tra khả năng truy cập trong quy trình triển khai.
Sự bất đồng nội bộ hiện là bằng chứng. Khi các kỹ sư nêu lo ngại về các tính năng có hại và những lo ngại đó được ghi lại, chúng trở thành bằng chứng của nguyên đơn. Các công ty phớt lờ cảnh báo nội bộ đang tự xây dựng vụ kiện chống lại chính mình. Các tổ chức thông minh sẽ tạo ra các kênh chính thức cho các phản đối đạo đức. Những tổ chức thông minh hơn nữa thực sự sẽ lắng nghe.
Các điểm dừng tự nhiên, logic đề xuất minh bạch, quyền kiểm soát thực sự của người dùng over tần suất thông báo -- những thứ này không còn chỉ là chủ đề thảo luận trong các hội nghị nữa. Chúng là lá chắn pháp lý.
Và hồ sơ năng lực cũng đọc khác đi. "Xây dựng động cơ đề xuất tăng thời gian phiên 40%" sẽ mang lại cảm giác khác so với hai năm trước. Thị trường cho các nhà phát triển có thể xây dựng sản phẩm hấp dẫn mà không có các mô hình bóc lột sắp phát triển.
Lưu ý: Các nhà phát triển mã nguồn mở và độc lập cũng không được miễn trừ. Nguyên tắc pháp lý áp dụng cho chính các mô hình thiết kế, không chỉ dành cho các công ty trên mức định giá nhất định. Quy mô ảnh hưởng đến mức thiệt hại. Nó không ảnh hưởng đến trách nhiệm pháp lý.
Đường ranh giới
Không có điều nào có nghĩa là tương tác là xấu. Mọi người thực sự thích những sản phẩm được thiết kế tốt. Xây dựng một cái gì đó mà mọi người muốn sử dụng không phải là tội phạm và không nên là như vậy.
Đường ranh giới nằm giữa sự tương tác và sự bóc lột. Một sản phẩm mà mọi người thích sử dụng so với một sản phẩm được thiết kế để lấn át khả năng dừng lại của họ. Nội dung mà ai đó thực sự đánh giá cao so với một vòng lặp mà họ không thể thoát ra.
Đường ranh giới đó luôn tồn tại về mặt đạo đức. Giờ đây nó tồn tại về mặt pháp lý.
Các lập trình viên có thể làm gì ngay bây giờ
Nếu bất kỳ đoạn mã nào ở trên trông có vẻ quen thuộc, đây là những gì bạn có thể làm:
Kiểm tra việc triển khai cuộn của bạn. Bảng tin của bạn có điểm kết thúc tự nhiên không? Nếu không, tại sao không? Bạn có thể thêm phân trang hoặc một điểm kiểm tra "bạn đã cuộn trong 20 phút" không?
Kiểm tra các mặc định tự động phát của bạn. Tự động phát là opt-in (chọn tham gia) hay opt-out (chọn không tham gia)? Người dùng có phải hành động để ngừng tiêu thụ, hay để bắt đầu? Hãy lật ngược mặc định đó.
Logic thông báo của bạn cũng xứng đáng được nhìn nhận kỹ lưỡng. Thông báo được tính giờ để thông báo hay để tái tương tác? Có trình lập lịch tối ưu hóa cho các lần truy cập quay lại không? Đó là phần mà luật sư của nguyên đơn sẽ đưa lên slide.
Sau đó là điểm số tương tác. Điều gì đang được tối ưu hóa? Nếu câu trả lời chỉ là thời gian trên trang và khối lượng tương tác, đó là hàm mà bồi thẩm đoàn vừa tìm thấy có lỗi. Hãy thêm các tín hiệu an tâm. Thêm các vòng lặp phản hồi tiêu cực. Thêm một thứ gì đó không chỉ là "nhiều hơn".
Cuối cùng, ghi lại sự phản đối của bạn. Nếu bạn nêu lên mối lo ngại về một tính năng có khả năng gây hại và lãnh đạo bác bỏ nó, hãy đảm bảo nó được ghi lại. Điều này bảo vệ bạn và tạo ra sự minh bạch.
Phần không thoải mái
Hầu hết các lập trình viên không bắt đầu với ý định xây dựng các sản phẩm gây nghiện. Họ bắt đầu để xây dựng phần mềm tốt. Nhưng các chỉ số tương tác rất quyến rũ. Nhìn các con số của bạn tăng vọt cảm giác như đang thắng. Nó mang tính xác nhận. Gây nghiện, thậm chí.
Có một sự mỉa mai ở đây: những người xây dựng các vòng lặp tương tác chính họ cũng bị mắc kẹt trong một vòng lặp tương tác. Giao tính năng, xem chỉ số tăng, được khen ngợi, giao thêm tính năng. Vòng lặp Dopamine không chỉ nằm trong sản phẩm. Nó nằm trong cuộc họp rà soát Sprint.
Phán quyết này là một điểm dừng bắt buộc. Một khoảng nghỉ phân trang trong một ngành công nghiệp đã cuộn vô tận trong mười lăm năm qua.
Các kỹ sư xây dựng thế hệ sản phẩm tiếp theo sẽ quyết định chúng trông như thế nào. Họ có thể xây dựng các hệ thống tôn trọng quyền tự chủ của người dùng. Họ có thể chống lại các thông số kỹ thuật coi sự nghiện là chỉ số hiệu suất chính (KPI). Họ có thể thiết kế các điểm dừng thay vì loại bỏ chúng.
Hoặc họ có thể tiếp tục triển khai các mô hình cũ và chờ đời trát hầu tòa.
Phán quyết này sẽ định hình lại cách chúng ta xây dựng phần mềm. Nếu bạn từng triển khai bất kỳ mô hình nào được mô tả ở trên, bạn sẽ thay đổi điều gì? Bạn đã từng phản đối một tính năng tương tác tại nơi làm việc chưa? Hãy chia sẻ kinh nghiệm của bạn trong phần bình luận.
