Làm thế nào để duy trì tư duy phản biện khi các tác nhân AI chiếm lĩnh công việc

Tác giả: Addy Osmani (đội ngũ Anthropic Claude Code, kiến trúc sư công nghệ nổi tiếng)

Biên dịch: Deep潮 TechFlow

Dẫn nhập của Shenchao: Khi các luồng công việc agent được triển khai rộng rãi, các kỹ sư phần mềm và nhóm sản phẩm đang trải qua sự tái cấu trúc mạnh mẽ trong mô hình hợp tác giữa con người và máy móc. Khoảng đệm nhận thức từng được nuôi dưỡng giữa câu hỏi và câu trả lời giờ đây đã bị thu hẹp xuống chỉ vài giây; khi các mô hình lớn ngày càng chân thực và chính xác cao, các lỗi hiển nhiên giảm mạnh, nhưng con người dần trượt vào trạng thái “ đầu hàng nhận thức” trong cảm giác dễ chịu khi tuân theo, dẫn đến sự suy giảm nhanh chóng về khả năng hiểu hệ thống và các kỹ năng nền tảng một cách vô thức.

Là cựu trưởng nhóm kỹ thuật của Google Chrome và hiện là thành viên cốt lõi của đội ngũ Anthropic Claude Code, Addy Osmani trong bài viết này phân tích hệ thống hiện tượng trượt dốc từ “giải tải nhận thức”, “hoãn phán xét” đến “đầu hàng nhận thức”. Ông không chỉ làm rõ cơ chế tích lũy ngầm của nợ hiểu biết hệ thống, mà còn đề xuất một chiến lược đọc chủ động và đặt câu hỏi đối kháng, mang tính thực tiễn và phòng vệ, dành cho quy trình làm việc hàng ngày, đồng thời giải thích lý do tại sao con người vẫn phải kiên trì giữ vững ranh giới trách nhiệm và năng lực tư duy phản biện, ngay cả khi AI có xác suất thắng cao hơn trong tương lai.

Từng có một thời, tư duy phản biện được dạy trong trường học yêu cầu mọi người tiếp cận thông tin mới với sự tò mò khiêm tốn và thái độ nghi ngờ vừa phải: lắng nghe nhiều phía, lắng nghe toàn diện để hiểu rõ hơn, từ đó hình thành quan điểm độc lập của riêng mình. Nguyên tắc này vẫn còn giá trị cho đến ngày nay, nhưng hiện nay, khi phần lớn công việc hàng ngày của tôi đều được giao cho các tác nhân (Agents) xử lý, thực tế gần như không còn gì buộc tôi phải sử dụng tư duy phản biện nữa.

Đối với những kỹ sư và sản phẩm đã hoàn toàn đón nhận luồng công việc của tác nhân, chạy đồng thời nhiều phiên trong cuộc sống hàng ngày và kiên nhẫn chờ đợi hiệu suất mô hình không ngừng được cải thiện, tôi muốn nói rõ trước tiên: chính tôi cũng là người hâm mộ trung thành của các công cụ này. Tôi viết bài viết này hoàn toàn không nhằm khuyến khích mọi người giảm bớt việc sử dụng luồng công việc của tác nhân.

Mục tiêu cốt lõi của tôi là: trong thế giới nơi mọi thứ đều có thể dễ dàng giao cho các tác nhân, giúp bạn vẫn giữ vững tư duy phản biện của chính mình.

Trong quá khứ, phần lớn quá trình xử lý nhận thức và phán xét thẩm mỹ của con người đều được nuôi dưỡng trong khoảng trống giữa câu hỏi và câu trả lời. Tuy nhiên, ngày nay, khoảng trống này đã thu hẹp xuống chỉ còn vài giây. Bạn càng sử dụng sâu hơn các luồng làm việc của tác nhân, việc duy trì sự tỉnh thức càng trở nên khó khăn (dù cách khó khăn này có thể không giống như những gì đại chúng mong đợi): khi các mô hình liên tục được cải tiến, tỷ lệ những lỗi vô lý rõ ràng đã giảm mạnh. Hầu hết các kết quả được tạo ra đều được viết một cách rất đàng hoàng và nhìn chung chính xác, nhưng chính sự đàng hoàng tưởng chừng không thể chê vào đâu này lại khiến người ta chẳng hề muốn nhìn thêm lần thứ hai.

Dù bạn đang chạy đồng thời hàng chục tác nhân thông minh, thì cuối cùng, người kiểm tra kết quả đầu ra vẫn chỉ là đôi mắt của chính bạn.

Bạn phải chủ động lồng ghép tư duy phản biện một cách có chủ ý vào các quy trình hàng ngày, vì ở trạng thái mặc định, không có lực lượng bên ngoài nào sẽ thay bạn kiểm soát.

Một phần lý do khiến mọi người khó tự điều chỉnh là trải nghiệm của các luồng công việc trí tuệ nhân tạo thực sự quá tuyệt vời. Trong những ngày làm việc bận rộn, việc nhận được câu trả lời sẵn sàng, ổn thỏa và tương đối chính xác một cách nhanh chóng thật sự khiến tinh thần sảng khoái; nhưng chính điều này cũng là môi trường lý tưởng khiến con người dễ dàng buông lỏng cảnh giác và đầu hàng hoàn toàn.

Khi thảo luận về hiện tượng này với các đồng nghiệp, tôi thường mô tả nó như một quang phổ liên tục:

Ở đỉnh cao nhất của thang đo là “giải phóng nhận thức” (Cognitive Offloading), tức là giao các nhiệm vụ cụ thể và phức tạp cho AI thực hiện, nhưng con người luôn giữ quyền sở hữu và trách nhiệm tuyệt đối đối với kết quả cuối cùng. Tôi tự bản thân mình làm điều này cả ngày, và bạn cũng nên làm như vậy.

Ở giữa thang đo là “hoãn phán xét” (Deferral), lúc này kết quả do công cụ đưa ra trực tiếp trở thành đầu vào mới cho bước tiếp theo, nội dung được tạo ra không còn được xem là một giả thuyết cần được xác minh.

Ở cực dưới của thang đo là “sự đầu hàng nhận thức” (Cognitive Surrender): đầu ra của AI vô thức trở thành quan điểm của chính bạn, đến mức bạn thậm chí cảm thấy hoàn toàn không cần phải xác minh nó.

Thuật ngữ “đầu hàng nhận thức” được Steven Shaw và Gideon Nave từ Trường Kinh doanh Wharton đề xuất. Nó mô tả một cách cực kỳ chính xác những gì tôi đã chứng kiến gần đây: khi niềm tin vào công cụ tăng lên (hoặc do sự lười biếng phát sinh), con người vô thức trượt dần dọc theo thang đo này.

Sự trượt dốc này thường rất tinh vi và khó nhận ra, vì từng bước đều diễn ra dần dần và dường như hợp lý ngay tại thời điểm đó: bạn đã đọc kỹ câu trả lời lần trước, nên lần sau bạn chỉ lướt qua đại khái; lần sau nữa, bạn chỉ lướt qua sơ đồ khung xương; cho đến một ngày, khi người khác chỉ vào một dòng mã và hỏi bạn, bạn mới giật mình nhận ra rằng ngay cả khi có sự hỗ trợ của tác nhân thông minh, bạn cũng hoàn toàn không thể giải thích rõ ràng logic nền tảng của nó.

Đây chính là sự đầu hàng nhận thức rõ ràng. Đó chính là nguồn gốc khiến "nợ nhận thức" (Cognitive Debt) tích lũy âm thầm. Nợ này thường chỉ bộc lộ rõ khi bạn cố gắng truy cập mô hình tâm trí toàn cục của hệ thống, nhưng phát hiện trong đầu trống rỗng.

Nhà học giả Margaret-Anne Storey từng viết rằng, điều này thể hiện trong hợp tác nhóm qua sự suy giảm liên tục trong khả năng hiểu chung về lý thuyết hệ thống. Tôi cũng từng viết về hiện tượng tương đương ở cấp độ mã nguồn, gọi là “nợ hiểu biết” (Comprehension Debt – thuật ngữ do Jeremy Twei đề xuất). Trong quá trình viết mã hàng ngày, khoản nợ này hoàn toàn vô hình: kho mã trông gọn gàng và tinh tế, tất cả các bài kiểm tra tự động đều xanh lá. Tuy nhiên, khi hệ thống cần được tái cấu trúc ở cấp độ kiến trúc, mọi người đều rơi vào tình thế lúng túng: không một ai trong nhóm thực sự hiểu rõ hệ thống này. Vấn đề tương tự cũng xảy ra khi bạn chỉ lướt qua mục lục của một kế hoạch chiến lược hoặc tài liệu kỹ thuật, rồi ký duyệt một cách bừa bãi.

Cần làm rõ rằng, tôi không đang ủng hộ một chủ nghĩa hoàn hảo không thực tế. Việc yêu cầu các kỹ sư luôn duy trì một mô hình tâm lý đầy đủ về toàn bộ kho mã nguồn hiện đại khổng lồ là không thể. Trước đây, nhóm Claude Code đã công khai cho biết họ hiện đang áp dụng chiến lược “xây dựng lại sự hiểu biết theo nhu cầu”: khi cần sửa đổi một mô-đun nào đó, hãy để Claude giải thích trực tiếp logic của phần đó thay vì cố gắng duy trì hình ảnh tổng thể trong đầu.

Như tôi đã chỉ ra trước đây, khoản nợ hiểu biết cục bộ này thực ra dễ khắc phục hơn nhiều so với hầu hết các kỹ sư tưởng tượng. Chỉ cần bạn có thể tái xây dựng sự hiểu biết cục bộ khi cần, bạn không cần phải duy trì toàn bộ bức tranh tổng thể liên tục. Nhưng điểm cốt lõi là: bạn phải rõ ràng về những khu vực nào mình đang có điểm mù.

Trên những việc nhỏ nhặt với chi phí thử sai cực thấp, mọi người hoàn toàn có thể an tâm giao toàn bộ quyền quyết định. Nhưng một khi bạn đối mặt với một vấn đề then chốt, thậm chí ngay cả khi sử dụng tác nhân thông minh cũng không thể giải thích được câu trả lời nền tảng của nó, bạn đã thực sự từ bỏ hoàn toàn quyền sở hữu hệ thống.

Tất nhiên, điều này không có nghĩa là mọi tình huống đều phải căng thẳng như vậy. Không lâu trước đây, tôi cần ghi một khóa học và phải chọn một trong ba khách sạn có đánh giá gần như nhau làm địa điểm quay phim. Lúc đó, tôi thực sự không có thời gian để đọc từng đánh giá của khách hàng, nên tôi đã hoàn toàn giao quyết định này cho một AI. Kết quả rất đáng hài lòng, và lần tới khi gặp tình huống tương tự, tôi vẫn sẽ làm như vậy.

Tuy nhiên, khi liên quan đến đầu tư tài sản cốt lõi, lập kế hoạch sự nghiệp cho con cái, hoặc trong công việc quyết định nên phát triển tính năng nào, thay đổi sẽ ảnh hưởng đến những người dùng thực tế nào, mã có đạt tiêu chuẩn an toàn để đưa lên sản xuất hay không, tôi tuyệt đối không giao quyền quyết định cho người khác. Ở những vùng biên giới nơi chi phí sai lầm thấp, bạn có thể thoải mái giao lại; nhưng ở những khâu cốt lõi mà người khác phải trả giá cho hậu quả, bạn phải kiên quyết giữ vững lập luận logic của con người.

Khi bản thân tôi từng rơi vào tình trạng tư duy hỗn loạn, tôi thường quay lại danh sách những câu hỏi cơ bản cực kỳ đơn giản: Làm sao tôi biết mình đang giải quyết đúng vấn đề? Làm sao tôi biết con đường giải quyết mình chọn là đúng? Có bằng chứng khách quan chắc chắn nào hỗ trợ kết luận của tôi không? Tôi làm thế nào để xác nhận công việc này đã hoàn thành triệt để? Hầu hết thời gian, đây chỉ là nguyên tắc năm W (Who, What, Where, Why, When và How) kinh điển trong báo chí. Khi viết ra giấy, chúng trông có vẻ ngây thơ như trò đùa, nhưng lại buộc bạn xem xét từ những góc độ mù lòa mà bạn thường bỏ qua.

Trong thời đại hiện nay, con người quá dễ dàng bỏ qua tất cả những suy nghĩ đau đớn này và quay sang hỏi các tác nhân thông minh: “Theo bạn, tôi nên làm gì?”. Vì vậy, tôi đã cập nhật cho mình một danh sách phản tư hoàn toàn mới dành cho thời đại tác nhân:

• Trước khi đặt câu hỏi, tôi đã hình thành giả định ban đầu của mình chưa? Trước khi khởi động tác nhân xử lý bất kỳ nhiệm vụ nào không đơn giản, tôi luôn buộc bản thân ghi lại (trên giấy hoặc giấy ghi chú) những hướng trả lời mà tôi nghĩ có thể xảy ra, dù đó chỉ là một phỏng đoán thô sơ và kém hoàn hảo. Bạn hoàn toàn có quyền bác bỏ và thay đổi ý kiến sau khi tiếp nhận thông tin mới. Nhưng một khi bạn đã đọc một câu trả lời được tạo ra với văn phong cực kỳ trôi chảy và tinh tế, bạn sẽ rất khó để tưởng tượng bất kỳ khả năng nào khác. Nếu bạn hoàn toàn không có ý tưởng gì, hãy thử phương pháp “đặt câu hỏi phát hiện điểm mù” do Thariq Shihipar đề xuất: liệt kê toàn bộ những gì bạn đã biết, và yêu cầu mô hình giúp bạn tìm ra những điều chưa biết mà bạn chưa từng nghĩ đến.

• Tôi đang dùng nó để hỗ trợ suy nghĩ của mình, hay đang giao toàn bộ quá trình suy nghĩ cho nó? Cả hai chế độ này đều được phép, điều quan trọng là bạn phải luôn tỉnh táo và rõ ràng về việc mình đang ở trạng thái nào.

• Những điều kiện tiên quyết nào phải có để phương án này hoàn toàn thất bại? Sau khi suy nghĩ kỹ, hãy ngay lập tức thực hiện kiểm tra thực tế. Mức độ tự đánh giá độ tin cậy của mô hình đối với câu trả lời của chính nó có giá trị tham khảo xa kém so với việc bạn tự chạy một bài kiểm tra thực tế, vì vậy hãy đặt cho nó một bài kiểm tra thực sự.

• Tôi đã từng nghe các lập luận phản biện từ góc nhìn đối lập chưa? Khi tôi hình thành một quan điểm vững chắc về một câu hỏi mở, tôi yêu cầu mô hình đóng vai trò một phe phản đối khắt khe, liệt kê riêng cho tôi những phản bác mạnh mẽ nhất chống lại quan điểm đó. Điều này không nhất thiết nhằm bác bỏ quyết định của tôi, mà nhằm buộc tôi phải đối mặt với những điểm mù bất lợi mà trước đây tôi vô thức loại bỏ khi mọi chuyện thuận lợi.

• Nếu phải tự mình bảo vệ kết quả này, tôi sẽ nói thế nào? Hãy tạm đóng cửa sổ đại lý, thử giải thích phương án này bằng lời nói đơn giản, thuần túy của chính bạn với đồng nghiệp. Nếu bạn thấy mình nói lắp bắp, không diễn đạt rõ ràng, điều đó có nghĩa là bạn chưa thực sự hiểu nó — lúc này bạn chỉ đang đóng vai người truyền lời của AI một cách máy móc.

Trong chế độ đọc thụ động, não bộ bạn chỉ trượt theo văn bản đã định sẵn một cách máy móc, tiếp nhận dòng thông tin một cách bị động. Vì văn bản do các tác nhân tạo ra thường trôi chảy, tu từ chỉnh chu và ngữ pháp không có gì để chê, việc đọc thụ động trong môi trường này cực kỳ dễ khiến bạn lầm tưởng rằng mình đã nắm vững được tinh hoa. Điều này giống như việc bạn đang tham dự một hội nghị công nghệ, nhìn các diễn giả hàng đầu trình diễn các thao tác kiến trúc trôi chảy, bạn gật đầu liên tục ở hàng ghế dưới và cho rằng mọi thứ là hiển nhiên, nhưng khi trở về khách sạn và mở trình soạn thảo trống, bạn phát hiện mình không thể viết được một dòng mã nào.

Đọc chủ động là một hành vi xem xét mang giả định đối lập. Nó không chỉ quan tâm đến những gì văn bản đã viết, mà còn chất vấn quyết liệt: Tại sao nó lại được viết ở đây? Nó đã bỏ qua những điểm khó cốt lõi nào? Tại sao nó lại chọn cách giải quyết này thay vì một cách khác?

Đối với các kế hoạch dài do tác nhân tạo ra, tôi thường đọc với hai góc nhìn cực kỳ rõ ràng để chỉ trích:

Trước tiên, hãy tìm những “bối cảnh bị thiếu”: Những giả định ngầm định của nó là gì? Nó có bỏ sót những trường hợp ngoại lệ nào không? Khi hai yêu cầu xung đột với nhau, nó đã dựa trên nguyên tắc nào để thầm lặng lựa chọn thay cho tôi?

Tiếp theo là chủ động đặt ra những câu hỏi mang tính thách thức: Nếu lưu lượng truy cập đồng thời tăng đột biến mười lần, thiết kế này sẽ sụp đổ như thế nào? Nếu dịch vụ phụ thuộc bên ngoài của bên thứ ba ngừng hoạt động trong nửa giờ, hệ thống sẽ gặp phải những thảm họa dây chuyền gì? Thay vì thụ động đọc những câu trả lời có sẵn tràn ngập trên trang giấy, hãy chủ động cầm lấy con dao mổ để thực hiện kiểm tra áp lực cho nó.

Agent không chỉ có thể được sử dụng để viết các bài luận dài, mà còn có thể được huấn luyện để trở thành đồng minh mạnh mẽ hỗ trợ bạn trong việc đọc sâu và phê phán. Chìa khóa nằm ở chỗ, bạn không nên chỉ yêu cầu nó đưa ra những kết luận khiến tất cả đều hài lòng, mà phải để nó phơi bày những bất đồng và mâu thuẫn đằng sau:

Bạn có thể yêu cầu nó thực hiện việc đối chiếu chéo giữa hai thiết kế kiến trúc dường như đối lập, chỉ ra từng bên đã nhượng bộ điều gì; bạn có thể để nó đóng vai một người kiểm tra mã khắt khe, chuyên tìm ra những đoạn mã xấu dù vẫn chạy qua bài kiểm tra nhưng ẩn chứa bẫy bảo trì trong tương lai; thậm chí bạn có thể yêu cầu nó sau khi hoàn thành đầu ra văn bản dài, ngẫu nhiên trích ra ba chi tiết từ giữa để đặt câu hỏi ngược lại với bạn, nhằm kiểm tra xem bạn có thực sự hiểu bối cảnh hay không.

Hãy coi tác nhân như một viên đá mài tư duy, chứ không phải là vật thay thế tư duy.

Viết mã và kiểm tra mã là hai kỹ năng tư duy hoàn toàn khác biệt. Trước dòng mã được tạo ra với số lượng lớn, việc con người kiểm tra dễ dàng trở nên suy giảm do mệt mỏi, biến thành việc đóng dấu “con dấu cao su” với mắt nhắm.

Vì vậy, khi xem xét các thay đổi mã (Diff), hãy cố gắng giả định rằng mã này không phải do AI tài ba viết ra, mà là do một thực tập sinh mới vào làm nộp lên. Quan trọng hơn, đừng chỉ tập trung vào các dòng mã được thêm hoặc xóa, mà hãy xuyên qua bề mặt mã để đặt câu hỏi về những quyết định vi mô quan trọng nào mà tác nhân đã âm thầm thực hiện thay bạn: Nó đã chọn giá trị mặc định nào? Nó đã loại bỏ những logic phức tạp nào ra khỏi phạm vi này? Khi hai yêu cầu sản phẩm mâu thuẫn nhau, nó đã tự ý diễn giải lại yêu cầu nào?

Nếu một báo cáo chỉ nhẹ nhàng thông báo với bạn rằng “tất cả đều suôn sẻ, mọi bài kiểm tra đều qua”, bạn sẽ chẳng bao giờ nhìn thấy được những nội dung bên trong các quyết định then chốt. Vì vậy, hãy yêu cầu rõ ràng một danh sách riêng biệt: nêu rõ những giả định chủ quan và lựa chọn thỏa hiệp nào đã được đưa ra trong nhiệm vụ này. Sau đó, tự kiểm tra ngẫu nhiên mình: chọn ngẫu nhiên hai hoặc ba dòng mã quan trọng, tự hỏi tại sao mình lại viết như vậy? Nếu đó là một tài liệu thiết kế, hãy đóng trang lại và cố gắng nhớ lại hoàn toàn để diễn đạt lại luận điểm cốt lõi cho người khác. Tôi cực kỳ ưa thích một quy tắc nghiêm ngặt mà một số đội ngũ áp dụng: yêu cầu các tác nhân đính kèm một bộ câu hỏi tự kiểm tra ở cuối báo cáo thay đổi, với quy định bắt buộc của đội ngũ là “chỉ khi tôi trả lời đúng 100% các câu hỏi kiểm tra, mã mới được phép hợp nhất”.

Hãy đảm bảo rằng bạn hiểu sâu sắc và có đủ tự tin về sản phẩm mà bạn triển khai, sẵn sàng đứng ra bảo vệ nó bất cứ khi nào. Vì một ngày nào đó trong tương lai, chắc chắn sẽ có người mang theo câu hỏi tìm đến bạn.

Đồng thời, các tác nhân thông minh cũng có thể giúp chúng ta xây dựng hàng phòng thủ giá trị cho sự chú ý. Ví dụ, tôi đang duy trì một dự án mã nguồn mở lớn tiếp nhận lượng lớn Pull Request. Tôi sẽ để các tác nhân giúp tôi sàng lọc ban đầu: xác định những đề xuất nào vi phạm quy tắc đóng góp của cộng đồng và những đề xuất nào cần tôi dành sự quan tâm đặc biệt. Tôi tuyệt đối không để các tác nhân tự quyết định có hợp nhất hay không, nhưng chúng có thể giúp tôi thu hẹp chính xác ống kính chú ý, để tôi có thể tập trung toàn bộ băng thông nhận thức con người vào việc “những thay đổi này có đang giải quyết đúng vấn đề thực sự bằng con đường đúng đắn hay không”.

Cuối cùng, phải đối mặt với sự phình đại tâm lý do sự bùng nổ sản lượng mang lại. Tôi gọi đây là “loại thuế biên soạn” (Orchestration Tax), về bản chất là khoảng cách khổng lồ giữa khối lượng sản phẩm công nghiệp được tạo ra hàng loạt bởi các tác nhân và khối lượng sản phẩm tinh hoa mà bạn thực sự sẵn sàng đặt tên mình vào. Nếu tốc độ tích lũy đầu ra đã vượt xa giới hạn sinh lý của bạn trong việc kiểm tra kỹ lưỡng, thì việc mở một phiên hội thoại song song mới hoàn toàn vô ích: bạn phải ли siết chặt quy trình kiểm tra tự động, ли quyết định giảm tốc độ.

Khi những gì bạn tạo ra đã vượt quá phạm vi mà bạn có thể chịu trách nhiệm, bạn không còn đang thực hiện việc kiểm duyệt chuyên nghiệp nữa, bạn chỉ đang hy vọng may mắn sẽ không xảy ra sự cố.

Trong hệ thống hợp tác giữa con người và máy móc, mô hình nhận thức của con người không biến mất, mà chỉ dịch chuyển trọng tâm: nó được chuyển toàn bộ từ giai đoạn mã hóa trung gian kéo dài sang hai đầu là đầu vào nhiệm vụ và đầu ra kiểm định. Bạn dồn toàn bộ năng lực nhận thức vào việc phân tích nhiệm vụ ban đầu, cung cấp ngữ cảnh, cũng như kiểm tra chặt chẽ vòng闭环 ở giai đoạn cuối. Chính vì vậy, chất lượng của prompt (lệnh nhắc) có ảnh hưởng quyết định đến kết quả cuối cùng, và tôi luôn coi kỹ thuật prompt xuất sắc là một nghệ thuật cốt lõi của tư duy phản biện cấp cao.

Trước đây, nếu bạn ném một yêu cầu mơ hồ cho đồng nghiệp con người, họ sẽ lập tức phản hồi lại ngay, và bạn sẽ tự vấn bản thân và bừng tỉnh: “Hóa ra tôi chưa từng thật sự suy nghĩ kỹ về việc này.” Tuy nhiên, các tác nhân thông minh thường không dừng bạn lại ở thời điểm này. Chúng sẽ lặng lẽ bổ sung mọi chi tiết bạn bỏ sót, rồi đưa lại một sản phẩm đầu ra bề ngoài cực kỳ chỉnh chu và đầy đủ, dù ý định cốt lõi đằng sau vẫn còn mờ mịt. Tôi gọi hiện tượng này là “Nợ ý định” (Intent Debt): những mục tiêu và ràng buộc ngầm được ẩn sâu trong sản phẩm đầu ra, nhưng chính bạn cũng chưa từng thực sự suy ngẫm kỹ lưỡng. Khác với các khoản nợ khác, không ai có thể thay bạn thanh toán nợ ý định; ý định cốt lõi phải 100% xuất phát từ chính bạn.

Câu bạn viết ra chính là tấm gương phản chiếu độ sâu hiểu biết của bạn về vấn đề; nếu bạn không thể diễn đạt nó bằng ngôn ngữ rõ ràng và chính xác, điều đó thường có nghĩa là nó trong đầu bạn vốn dĩ là một đống hỗn độn.

Trước khi tìm kiếm sự hỗ trợ về sức mạnh tính toán từ bên ngoài, hãy tự viết một bản tóm tắt yêu cầu nhiệm vụ bằng ngôn ngữ đơn giản, dễ hiểu của chính bạn. Xác định rõ đối tượng tiếp nhận, xác định các điều kiện cấm tuyệt đối, và đưa ra các tiêu chuẩn验收 khách quan để đánh giá công việc hoàn thành (Definition of Done). Khi các lần chỉnh sửa thứ hai vẫn không đạt được kỳ vọng, hãy dừng ngay việc điều chỉnh tinh vi một cách mù quáng và viết lại hoàn toàn câu lệnh đầu vào của bạn.

Bạn cũng có thể sử dụng tác nhân để thúc đẩy chất lượng đầu vào của chính mình. Nhà triết học Andy Clark từng phân biệt rõ ràng giữa “giao nhiệm vụ một chiều cho AI” và “hợp tác sâu sắc hai chiều với AI”. Trong mô hình hợp tác thực sự, bạn sẽ bước vào một vòng lặp tích cực hỗ trợ lẫn nhau: những hướng dẫn chính xác của bạn tạo ra sản phẩm xuất sắc, và sản phẩm đó ngược lại thúc đẩy bạn đưa ra những hướng dẫn sâu sắc hơn, từ đó làm sâu sắc đáng kể mô hình tâm trí của bạn về hệ thống. Nếu không chắc chắn liệu logic của bạn có chặt chẽ hay không, hãy để tác nhân tiến hành phỏng vấn ngược lại bạn, đặt câu hỏi sâu về những điểm bạn chưa hiểu rõ. Nếu khi kết thúc một cuộc hội thoại, logic trong đầu bạn đã được nâng lên một cấp độ mới, đó mới là dấu hiệu thực sự của thành công.

Ngoài ra, cần cảnh giác cao độ với ô nhiễm ngữ cảnh. Khi nhiều tác nhân hợp tác, rất dễ xảy ra tình trạng tác nhân sau chỉ dựa vào tóm tắt nén của tác nhân trước để tiếp tục công việc, dẫn đến suy giảm dần dần, đến tác nhân thứ ba thậm chí chưa bao giờ đọc được tài liệu cốt lõi ban đầu.

Đồng thời, bạn phải xây dựng tiêu chuẩn thẩm mỹ và chất lượng riêng của mình. Tôi đã thử nghiệm AI trong nhiều lĩnh vực sáng tạo và kỹ thuật khác nhau, và phần lớn đầu ra của nó chưa bao giờ được công bố vì chúng hoàn toàn không đạt tiêu chuẩn cá nhân của tôi. Trong thời đại hiện nay, mọi đầu ra của mô hình đều có thể được trình bày một cách tinh tế, tự tin và chắc chắn, do đó “độ trơn tru bề ngoài” đã không còn là tín hiệu đáng tin cậy để đánh giá chất lượng.

AI có thể đã tăng đáng kể tốc độ của quy trình sản xuất nội dung, nhưng bất kỳ sản phẩm nào khiến tôi cảm thấy ngại khi ký tên mình vào, tôi sẽ không bao giờ cho phép nó được phát hành ra ngoài.

Khi một đầu ra không đạt tiêu chuẩn, hãy ghi rõ nguyên nhân thất bại vào tệp cấu hình chia sẻ, hook chặn Git hoặc trường hợp kiểm thử tự động, đảm bảo sai lầm tương tự sẽ không bao giờ tái diễn. Đây mới là con đường đúng đắn để tích lũy hương vị và tiêu chuẩn theo cách lãi kép, và việc ghi nhận một cách tỉnh thức những gì chưa đạt ngưỡng chính là một cuộc tu dưỡng nhận thức vô cùng giá trị.

Nếu bạn có niềm tin vững chắc vào tương lai của AI, giống như nhiều người đam mê xung quanh tôi, bạn có thể đã nảy sinh suy nghĩ này ngay từ khi đọc những chương đầu tiên: “Chỉ trong một hoặc hai năm nữa, khả năng sửa lỗi và hiểu sâu của mô hình chắc chắn sẽ vượt trội hoàn toàn so với tôi, vậy thì tôi còn phải vất vả duy trì kỹ năng đánh giá phê phán này làm gì?”

Trên nhiều phép kiểm tra chỉ số kỹ thuật thuần túy, dự đoán của bạn rất có thể hoàn toàn chính xác, và bản thân tôi cũng luôn ủng hộ việc chuyển ngày càng nhiều quyền kiểm tra tự động cho các tác nhân. Nhưng tại sao khả năng này vẫn mang trọng lượng vô cùng quan trọng trong tương lai? Lý do duy nhất là: về cốt lõi, cuối cùng vẫn phải có một con người thực sự chịu trách nhiệm toàn bộ cho kết quả thực tế được đưa vào vận hành. Dù có sử dụng bao nhiêu sức mạnh tính toán đi chăng nữa, người cuối cùng bước lên tòa án hoặc gánh chịu hậu quả vẫn chỉ là con người thực sự.

Việc quyết định mức độ tin tưởng nào nên được gán cho một tác nhân trong một nhiệm vụ cụ thể chính là một phán quyết định tính đòi hỏi trí tuệ cao độ. Để duy trì khả năng đánh giá chính xác liên tục, bạn phải tự mình kiểm tra công việc thường xuyên, vì những mô hình lỗi kỳ lạ của mô hình luôn thay đổi động. Nghiên cứu theo dõi các kỹ sư và nhà nghiên cứu hàng đầu của Anthropic đã làm rõ bẫy chết người của “nghịch lý giám sát”: những kỹ năng kỹ thuật và kiến trúc cấp cao cần thiết để giám sát và điều khiển Claude chính là những kỹ năng cốt lõi mà con người dễ dàng suy giảm nhanh nhất khi quá phụ thuộc vào AI.

Những câu hỏi sâu sắc này là những vấn đề tôi coi trọng nhất, và bất kỳ mô hình lớn nào mạnh mẽ đến đâu cũng không thể thay bạn trả lời: Bạn thực sự vì sao lại tạo ra sản phẩm này? Nó mang lại giá trị xã hội và thương mại như thế nào? Nó sẽ ảnh hưởng sâu sắc đến những ai cụ thể? Để hiện thực hóa nó, bạn sẵn sàng trả giá và nhượng bộ những gì? Tất cả những điều này đều phải do chính bạn tự trả lời. Các tác nhân thông minh có thể tỏa sáng trong quá trình suy luận làm rõ những câu hỏi này, và tôi rất hoan nghênh điều đó, nhưng dấu ấn quyết định cuối cùng luôn nằm trong tay bạn.

Bạn có thể giao toàn bộ công việc cụ thể và thậm chí nhiều khâu kiểm toán cho thuật toán, nhưng quyền trách nhiệm cuối cùng và nghĩa vụ trách nhiệm, bạn sẽ không bao giờ có thể giao bỏ.

Bạn hoàn toàn không cần phải cứng nhắc thực hiện tất cả các giáo điều một cách máy móc, chỉ cần chọn những phương pháp phù hợp với quy trình làm việc của bạn để hòa nhập một cách tự nhiên:

• Thực hành có chủ ý ngoại tuyến mỗi tuần: Dành một khoảng thời gian cố định mỗi tuần để hoàn toàn tách rời sự hỗ trợ của tác nhân, tự tay viết một đoạn mã quan trọng hoặc tự mình thực hiện một nhiệm vụ cốt lõi mà nếu thiếu kỹ năng sẽ dẫn đến hậu quả nghiêm trọng (tôi gọi đây là bài tập hiệu chỉnh nhận thức, hoàn toàn không phải là sự ép buộc đạo đức).

• Đánh giá năng lực hàng tháng: Mỗi tháng, hãy lập một danh sách để rà soát những việc bạn đã ngừng tự mình thực hiện do phụ thuộc vào AI, và nghiêm túc xem xét: Những kỹ năng nào trong số đó bạn thực sự có thể an tâm chấp nhận để vĩnh viễn quên đi? Câu hỏi tôi đặt ra trong một bài blog cũ cách đây nhiều năm, đến hôm nay vẫn còn vang vọng mạnh mẽ: Nếu một ngày nào đó AI đột ngột biến mất hoàn toàn, bạn sẽ rơi vào tình trạng tê liệt và bối rối đến mức nào?

• Khi gặp điều chưa hiểu, hãy tự mình tìm hiểu sâu: Nếu gặp một khái niệm nằm ngoài phạm vi hiểu biết hiện tại, bạn phải tự mình học một cách hệ thống. Khi viết bài, nếu tôi gặp một thuật ngữ mới mẻ chưa từng tiếp xúc, tôi hoàn toàn có thể tìm một câu giải thích sẵn từ Wikipedia và chèn vào văn bản, nhưng tôi thiên về dành ra một khoảng thời gian nhỏ để thực hiện một nghiên cứu vi mô sâu sắc, hiểu rõ nguyên nhân và hệ quả của nó, cho đến khi hoàn toàn nắm rõ vị trí của nó trong toàn cảnh kiến thức.

• Lên lịch kiểm duyệt máy móc như một công việc chính thức: Việc kiểm tra kỹ lưỡng sản phẩm do máy tạo ra chính là một công việc trí óc cực kỳ nặng nhọc. Việc giả vờ rằng công việc này dễ dàng chính là nguyên nhân khiến nhiều đội ngũ cuối cùng từ bỏ hoàn toàn việc kiểm duyệt, dẫn đến những hậu quả nghiêm trọng. Kiểm duyệt không phải là bữa ăn miễn phí, hãy chính thức đưa nó vào lịch làm việc hàng ngày của bạn, để bạn thực sự có đủ năng lượng thực hiện nó một cách nghiêm túc.

• Kỹ năng ngừng luyện tập sẽ nhanh chóng suy giảm: Bất kỳ cơ trí tuệ nào bạn bỏ bê trong thời gian dài đều sẽ teo lại nhanh chóng, và tốc độ suy giảm thường nhanh hơn nhiều so với dự đoán trực giác của bạn. Hãy chắc chắn rằng bạn luôn tự mình thực hành những kỹ năng cốt lõi mà bạn绝不甘心 để mất.

• Giữ ý định rõ ràng: Agent hoàn toàn có thể kiểm tra ngược lại bạn, phỏng vấn bạn và trình bày các lập luận cơ bản, nhưng điều kiện là bạn phải chủ động thiết kế và cấu hình cơ chế hợp tác này. Vì vậy, hãy xây dựng ngay lập tức.

• Thành thật đối mặt với vị trí thực sự của bạn trên thang đo: nếu bạn thậm chí không thể giải thích rõ ràng nguồn gốc của câu trả lời cho người khác mà không có sự gợi ý từ tác nhân, hãy thừa nhận: bạn đã rơi vào tình trạng đầu hàng nhận thức.

• Luôn đặt câu hỏi với giả định sẵn: Trước khi hỏi AI, hãy hình dung sẵn trong đầu giả thuyết của bạn, dù tốt hay xấu.

• Một dấu tích màu xanh chỉ cho thấy một bài kiểm tra đã qua: hãy luôn đặt câu hỏi: nó kiểm tra điều gì? Nó đã bỏ sót điều gì một cách lặng lẽ?

• Xem các lập luận khách quan trước, sau đó mới đọc các kết luận chủ quan: Trước khi xem qua các tóm tắt hoa mỹ mà nó đưa ra, hãy từng dòng kiểm tra xem nó đã thực hiện những lệnh thực tế nào và truy xuất những dữ liệu nền tảng nào.

• Đọc với sự nhạy cảm đối với quyết định: Hiểu rõ ràng các quyết định vi mô nào mà tác nhân đã tự ý đưa ra trong đầu ra này thay cho bạn.

• Tinh chỉnh kỹ lưỡng lời nhắc của bạn: Độ sâu và cấu trúc bạn sử dụng khi viết lời nhắc sẽ phản ánh trực tiếp mức độ hiểu biết thực sự của bạn về bản chất vấn đề.

• Thiết lập và kiên trì giữ vững đường dây giao hàng tuyệt đối: Nếu một thứ gì đó mà ngay cả bản thân bạn cũng cảm thấy xấu hổ khi đặt tên, thì tuyệt đối không được phê duyệt.

Bằng cách liên tục thực hành trực tiếp những kỹ năng cốt lõi quan trọng, hãy luôn giữ vững vị trí trung tâm trên bàn cờ. Một thói quen vi mô cực kỳ đơn giản bạn có thể thử ngay trong cuộc sống hàng ngày: trước khi hỏi AI, hãy ghi lại trên giấy ghi chú những hướng đi bạn dự đoán; sau khi AI hoàn thành nhiệm vụ, hãy lập tức ghi lại một điểm mù mà nó đã bỏ sót. Hãy xem liệu thói quen đối kháng nhỏ bé này có thể hoàn toàn thay đổi chiều sâu tư duy của bạn khi đánh giá kết quả do AI tạo ra hay không. Tư duy độc lập, đặt ra những câu hỏi chất lượng cao và có tính xuyên thấu hơn, đồng thời chịu hoàn toàn trách nhiệm với kết quả cuối cùng.

Hình: Duy trì tư duy độc lập và vòng lặp trách nhiệm trong luồng làm việc của tác nhân AI