AI Agent thực sự ứng dụng kiểm thử và xác thực đến mức nào?

Chúng tôi đã lưu ý trước đây rằng, mặc dù việc đạt được một tiêu chuẩn chất lượng nhất định trở nên dễ dàng hơn bao giờ hết nhờ việc các coding agent sử dụng các kỹ thuật kiểm thử hiệu quả, nhưng chất lượng phần mềm dường như đang ngày càng tệ đi. Điều này cho thấy các thiết lập mặc định mà các lập trình viên đang sử dụng có thể không thực sự hiệu quả. Tại đây, chúng tôi kiểm tra xem liệu các hướng dẫn đơn giản yêu cầu agent sử dụng các kỹ thuật hoặc thư viện cụ thể có cải thiện độ chính xác của việc triển khai hay không. Đây giống như một bài kiểm tra để xem các agent hiệu quả đến mức nào khi được hướng dẫn bởi một người không có chuyên môn về kiểm thử, nhưng có thể đã nghe nói rằng bạn nên áp dụng một số kỹ thuật hoặc sử dụng một số thư viện nhất định.

Chúng tôi sẽ tái sử dụng đánh giá (eval) về việc triển khai Zstd đã được thảo luận trong bài so sánh về hiệu quả của ngôn ngữ lập trình cho agent này. Thay vào đó, chúng tôi sẽ so sánh các kỹ thuật kiểm thử và thư viện kiểm thử khác nhau khi các agent được cung cấp prompt để triển khai Zstd với các phần bổ sung khác nhau, chẳng hạn như "Sử dụng phát triển hướng kiểm thử (test-driven development)", "Sử dụng Lean 4", "Sử dụng QuickCheck", "Sử dụng kiểm thử dựa trên thuộc tính (property-based testing)", v.v. Tôi cũng đã chạy một số đánh giá khác, chẳng hạn như trên IMAP RFC, những đánh giá này được thảo luận ngắn gọn.

Tất cả các triển khai đều bằng Rust. 26 điều kiện prompt được kiểm tra bao gồm: ACL2, Alloy, "Audit and fuzz risky areas" (Kiểm toán và fuzz các khu vực rủi ro), "Audit first" (Kiểm toán trước), Creusot, Default (không có hướng dẫn bổ sung), Differential testing (Kiểm thử vi sai), Fuzzing, Hegel, Insta, Judgement (yêu cầu agent sử dụng kỹ thuật tốt nhất), Kani, Lean 4, "Make no mistakes" (Không được mắc lỗi), Metamorphic testing (Kiểm thử biến hình), Mutation testing (Kiểm thử đột biến), Property-based testing (Kiểm thử dựa trên thuộc tính), Proptest, QuickCheck, rstest, Rust built-in test framework (khung kiểm thử tích hợp của Rust), SMT solvers (với Z3, cvc5 và Yices, tất cả đều có sẵn), Spin, TDD, TLA+ và Verus. Ngoài ra, 4 kỹ năng (skills) đã được kiểm tra: Hegel với kỹ năng Hegel chính thức, kỹ năng kiểm thử ECC Rust (ECC là một tập hợp các kỹ năng với 250 nghìn sao trên GitHub và 38 nghìn fork), kỹ năng kiểm thử thuộc tính Trail of Bits và một kỹ năng kiểm thử do tôi tự viết (tôi là một người lạc hậu, sử dụng prompt thay vì kỹ năng và không có cảm nhận về cách viết một kỹ năng tốt). Ngoài kỹ năng của tôi, các kỹ năng khác được chọn vì đó là những kỹ năng hàng đầu mà codex tìm thấy khi được yêu cầu tìm các kỹ năng liên quan.

Dự đoán

Tôi đã đăng ký trước một số dự đoán về kết quả của các điều kiện:

Kết quả tổng thể

Dưới đây là một biểu đồ rất lộn xộn hiển thị kết quả cho các điều kiện đã kiểm tra (codex với GPT-5.6 Sol, với nỗ lực trung bình và rất cao). Khi xem dữ liệu, tôi có xu hướng thích các biểu đồ dày đặc và lộn xộn hơn hầu hết mọi người, chẳng hạn như biểu đồ đầu tiên ở đây. Vì hầu hết mọi người thấy những loại biểu đồ này lộn xộn đến mức không thể đọc được, tôi có xu hướng chia thông tin thành một loạt các biểu đồ, mỗi biểu đồ hiển thị ít thông tin hơn khi trình bày cho người khác. Vì những lý do được thảo luận bên dưới, tôi sẽ không làm điều đó ở đây mà chỉ trình bày biểu đồ cực kỳ lộn xộn này, nơi chúng ta có chi phí trên trục x và tỷ lệ các lần chạy vượt qua 100% các bài kiểm tra (ẩn) trên trục y, trung bình từ 80 lần chạy cho mỗi điều kiện và nỗ lực (di chuột qua các mục sẽ hiển thị bootstrap covariance, độ không đảm bảo 50%, và có một số nỗ lực làm cho các mục tương tự có màu sắc giống nhau, ví dụ: màu hơi xanh cho các phương pháp hình thức, màu hơi xanh lá cây cho kiểm thử dựa trên thuộc tính, v.v.):

Một điều chúng ta có thể thấy là không có gì thực sự vượt trội hoàn toàn. Tuy nhiên, Default (không có hướng dẫn bổ sung) hoạt động tốt hơn mức trung bình. Nhìn vào mức nỗ lực rất cao (xhigh), trung bình, các điều kiện liên quan đến fuzzing và PBT hoạt động tốt hơn một chút so với các phương pháp hình thức, trong khi tình hình hỗn hợp hơn nhiều ở mức trung bình (medium). Các kỹ năng liên quan đến kiểm thử mà codex khuyến nghị chúng ta thử đã hoạt động kém hiệu quả, mặc dù kỹ năng tùy chỉnh nhanh của chúng tôi hoạt động ổn (một sự khác biệt lớn là kỹ năng của chúng tôi được thiết kế để hướng agent ra khỏi hành vi mặc định của chúng sang các hành vi hiệu quả hơn, trong khi các kỹ năng khác giống như các bài hướng dẫn hơn). TDD không hoạt động tốt như dự đoán (một kỹ năng cũng gợi ý rằng các agent sử dụng TDD, và kỹ năng đó cũng hoạt động kém trong các trường hợp agent cố gắng làm theo hướng dẫn).

Nếu chúng ta thực sự nhìn vào những gì các agent đã làm, sẽ nhanh chóng thấy rõ rằng, nhìn chung, các agent không biết cách sử dụng các công cụ hoặc kỹ thuật này một cách hiệu quả. Như chúng tôi đã lưu ý ở đây, và như tất cả những người tôi đã nói chuyện cũng đã lưu ý, các agent thực sự rất tệ trong việc kiểm thử và dường như không hiểu cách kiểm thử hợp lý "theo mặc định". Ví dụ, đây là một bình luận của Gary Bernhardt:

Cách tiếp cận kiểm thử của các AI agent, ít nhiều là:

Lấy các trường hợp bệnh lý được nghĩ ra bởi một người phản đối mocks cách đây 15 năm, mà chưa bao giờ thực sự sử dụng mocks. Những giấc mơ ngây thơ về việc mock quá mức.

Biến những bệnh lý đó thành xương sống cho chiến lược kiểm thử của bạn.

Hóa ra, nếu bạn yêu cầu các agent sử dụng một kỹ thuật kiểm thử hoặc thư viện kiểm thử cụ thể, cách tiếp cận này không thay đổi nhiều như bạn hy vọng. Chúng ta sẽ xem xét chi tiết hơn những gì đã xảy ra trong các trường hợp, nhưng ở cấp độ cao, với các kỹ thuật kiểm thử, các agent có xu hướng chỉ viết các bài kiểm tra mà chúng thường viết, nhưng bên trong một khung cho một loại kỹ thuật kiểm thử khác, hoặc chúng sẽ sử dụng một kỹ thuật một cách hời hợt mà không thực sự thực hiện những việc mang lại giá trị từ kỹ thuật đó. Phần lớn, khi một kỹ thuật được nêu tên, chúng đã làm những gì Gary mô tả, nhưng liên quan đến kỹ thuật đó (ví dụ, đối với các phương pháp hình thức, chúng chủ yếu chứng minh các thuộc tính không liên quan và với kiểm thử dựa trên thuộc tính, các agent sẽ dựa nhiều vào các đầu vào hoàn toàn ngẫu nhiên và đánh mạnh vào các trường hợp không hợp lệ/từ chối hoặc tìm một thuộc tính tầm thường để kiểm tra và chạy các trường hợp ngẫu nhiên giá trị thấp chống lại thuộc tính tầm thường đó). Kết quả không khác biệt đáng kể trên IMAP RFC (nơi tôi đã thử 40 lần chạy cho mỗi điều kiện) hoặc các RFC ngẫu nhiên khác (nơi tôi đã thử một vài lần chạy riêng lẻ). Nhìn chung, bất kể loại vấn đề là gì, cho dù đó là một loại vấn đề thao tác bit như Zstd, một giao thức như IMAP1 hay bất cứ thứ gì khác, các agent đã không sử dụng các phương pháp hình thức hoặc thư viện hoặc kỹ thuật kiểm thử một cách hiệu quả.

Ở mức nỗ lực rất cao (xhigh), các agent nhìn chung có thể làm cho các bài kiểm tra mà chúng viết vượt qua, nhưng chúng viết các bài kiểm tra kém (ví dụ: chúng sẽ gửi bốn luồng bit giống hệt nhau vào một bài kiểm tra tính năng sử dụng bốn luồng bit và bỏ lỡ bất kỳ lỗi nào xảy ra do chúng chuyển vị các luồng bit). Và như chúng tôi đã lưu ý trước đây về đánh giá Zstd liên quan đến ngôn ngữ, việc chạy ở mức nỗ lực thấp hơn trong một vòng lặp ngây thơ sẽ mang lại kết quả tồi tệ hơn (các agent thực hiện điều này nhiều hơn nữa và bị đình trệ với độ chính xác thấp hơn).

Tôi tò mò tại sao các phòng thí nghiệm AI chưa tạo ra các môi trường RL (học tăng cường) để giúp các agent học cách kiểm thử tốt, vì phần mềm không hoạt động hợp lý dường như rất quan trọng đối với việc áp dụng coding agent và nó cũng có vẻ là loại vấn đề phù hợp với RL. Như chúng ta đã thấy trước đây, các agent đã trở nên khá giỏi trong các vấn đề tối ưu hóa thời gian chạy có giới hạn, điều này có ý nghĩa vì đó chính xác là loại vấn đề mà bạn có thể tạo ra hàng tấn môi trường RL để huấn luyện với chi phí thấp. Có lẽ đây là một trong những điều khó hơn vẻ ngoài của nó khi bạn thử, nhưng việc tạo ra các môi trường RL cho kiểm thử hiệu quả và các kỹ thuật kiểm thử dường như nằm trong cùng một loại vấn đề. Có lẽ yếu tố hạn chế chỉ là kiến thức về các kỹ thuật kiểm thử hiệu quả không được phổ biến rộng rãi, vì vậy không ai nghĩ đến việc thử nó và mọi người đang khiến các agent kiểm thử không hiệu quả (ví dụ: bằng cách thực hiện kiểm thử đơn vị tiêu chuẩn)2, hoặc có lẽ vấn đề này khó đóng gói hơn nhiều so với tối ưu hóa thời gian chạy vì lý do nào đó? Có khả năng đây sẽ là một vấn đề không còn quan trọng sớm nếu các agent trở nên giỏi đến mức chúng có thể viết mã chính xác mà không cần kiểm thử hoặc xác minh, nhưng ít nhất đối với trạng thái của các agent có sẵn công khai từ khi bắt đầu cho đến nay (tháng 9 năm 2026), có vẻ như việc các agent có một số ý tưởng về cách kiểm thử mà không cần sự hướng dẫn của chuyên gia kiểm thử sẽ làm tăng đáng kể hiệu quả lập trình của agent.

Dưới đây chúng ta sẽ xem xét cách các agent thực hiện mọi thứ cho từng điều kiện, được sắp xếp từ độ chính xác kém nhất đến tốt nhất, nhưng tôi cảnh báo bất kỳ ai không nên rút ra bất kỳ kết luận mạnh mẽ nào từ thứ tự này.

Rất nhiều thất bại ở đây dường như tương tự như những thất bại mà chúng ta đã thấy khi xem xét tác động của ngôn ngữ lập trình đối với việc sử dụng token và độ chính xác, ở chỗ các thất bại thường mang tính đặc thù. Ví dụ, với các ngôn ngữ lập trình, chúng ta thấy rằng các agent có tỷ lệ khá cao trong việc hiểu sai ngữ nghĩa của việc chuyển đổi byte trong Clojure nhưng không phải Java, mặc dù các agent "nên" (và có lẽ phần nào đó là có) biết rằng chúng có thể có được ngữ nghĩa chuyển đổi byte của Java bằng cách chuyển đổi với unchecked-byte thay vì byte.

Mặc dù mọi người có đủ loại giải thích cấp cao mơ hồ về lý do tại sao một số ngôn ngữ tốt hơn cho các agent so với những ngôn ngữ khác, khi chúng ta nhìn vào những gì các agent thực sự làm và các chế độ thất bại là gì, không có giải thích nào tôi nghe được về lý do tại sao ngôn ngữ ưa thích của ai đó lại phù hợp cho lập trình agent, cho dù đó là Elixir hay Ocaml hay J, thực sự là đúng (ngoại trừ các bình luận về tính an toàn bộ nhớ của Rust, đã được xác nhận trong đánh giá đa ngôn ngữ pandoc mà chúng tôi đã thử bằng cách so sánh các vấn đề an toàn bộ nhớ giữa C, C++ và Rust do agent viết). Thay vào đó, chúng ta thấy một loạt các thất bại đặc thù xảy ra vì những lý do không rõ ràng3. Với các ngôn ngữ, vì chúng ta có thể quan sát thấy mối tương quan vừa phải giữa mức độ phổ biến của ngôn ngữ và hiệu suất (cả chi phí thấp hơn và độ chính xác cao hơn), có vẻ hợp lý khi đoán rằng lý do là vì có nhiều dữ liệu huấn luyện hơn (có thể là dữ liệu tổng hợp chứ không chỉ là mã do con người viết) cho các ngôn ngữ phổ biến hơn. Ở đây, không có mô hình rõ ràng nào, ngoài việc các agent hầu hết không hiệu quả lắm trong việc áp dụng các kỹ thuật kiểm thử hoặc xác minh khi tất cả những gì chúng có là tên của một thư viện hoặc kỹ thuật (chúng tôi sẽ thảo luận về những gì hoạt động tốt hơn sau đó). Nếu bạn không muốn đọc về những gì đã xảy ra trong từng điều kiện, hãy nhấp vào đây để bỏ qua mục cuối cùng.

Verus

Verus sử dụng bộ giải SMT và nhiều loại suy luận khác nhau để chứng minh rằng mã khớp với các đặc tả.

Mặc dù Verus có thể chứng minh rằng mã khớp với các đặc tả, các agent đã không làm điều đó. Thay vào đó, chúng đã đưa ra các bằng chứng về nhiều thuộc tính trừu tượng liên quan đến Zstd. Bản thân tôi chưa sử dụng một công cụ như Verus, vì vậy tôi không thể nói về những gì một người dùng chuyên gia hoặc thậm chí là người mới bắt đầu thường làm, nhưng khi đọc hướng dẫn, tôi thấy hơi lạ là các agent đã không cố gắng sử dụng Verus để xác minh bất kỳ mã thực tế nào và chỉ sử dụng nó để thực hiện suy luận trừu tượng, vì nó dường như được thiết kế để giúp dễ dàng chứng minh các thuộc tính về mã thực tế.

Ngoài ra, nếu chúng ta nhìn vào các thuộc tính được chứng minh, nhìn chung có rất ít thuộc tính được chứng minh và các thuộc tính được chứng minh là không thú vị. Ví dụ, các agent sẽ chứng minh những điều như "với một con trỏ/chỉ mục/khoảng cách hợp lệ, thao tác kết quả vẫn nằm trong giới hạn", điều này không tệ để chứng minh, nhưng không thực sự là nguồn gốc của lỗi. Ngoài ra, các agent thường viết các bằng chứng trống rỗng, thực tế là A => A. Một bằng chứng Verus thực tế thuộc dạng này là:

Trong các trường hợp các agent thực sự chứng minh được điều gì đó, chúng thường chứng minh một điều gì đó tương đối đơn giản và tránh chứng minh các thuộc tính về các phần có khả năng xảy ra lỗi (ví dụ, các agent thường không đảo ngược thứ tự luồng bit cho mã hóa và giải mã và sẽ viết các bài kiểm tra không phát hiện ra điều này vì các bài kiểm tra là đối xứng; có lẽ một loại bằng chứng đảo ngược ở đây có thể khiến các agent "suy nghĩ" về điều này theo một cách khác).

Có vẻ như các agent không nhận được giá trị từ Verus khi chỉ được cung cấp Verus và tài liệu Verus.

Nếu chúng ta nhìn vào kết quả, kết quả Verus tổng hợp ở mức nỗ lực rất cao (xhigh) là ổn (độ chính xác thấp hơn một chút so với trung bình, nhưng rẻ hơn nhiều). Kết quả ở mức trung bình (medium) có chi phí trung bình và tỷ lệ phần trăm các lần chạy chính xác thấp nhất cũng như số lượng bài kiểm tra chính xác trung bình thấp nhất. Vì các agent không thực sự nhận được giá trị từ Verus, những gì chúng thực sự làm để đạt được độ chính xác chủ yếu chỉ là các bài kiểm tra truyền thống (các hàm #[test] tích hợp của Rust với các bài kiểm tra đơn vị). Khi chuyển từ mức trung bình sang mức rất cao, các agent dành nhiều nỗ lực hơn cho việc kiểm thử truyền thống và chỉ dành thêm một chút nỗ lực để sử dụng Verus, điều này cho phép kết quả ở mức rất cao là ổn.

Nhìn vào các bài kiểm tra thực tế, đối với một trong hai tính năng mà các agent sử dụng Verus hoạt động kém hơn nhiều (bảng nhảy bốn luồng), các agent Verus đã viết một bài kiểm tra cho tính năng này trong 89 trên 160 trường hợp, tình cờ là cùng một số lượng với các agent Default, nhưng các agent Verus có nhiều khả năng viết các bài kiểm tra tồi hơn. Chúng có nhiều khả năng mã hóa các kết quả không chính xác vào các bài kiểm tra cũng như tạo ra các bài kiểm tra dễ vượt qua mà không bao phủ tốt không gian, chẳng hạn như làm cho cả bốn luồng giống hệt nhau. Loại điều này là những gì tôi muốn nói khi tôi nói rằng các thất bại mang tính đặc thù. Không có gì về Verus nhất thiết khiến người ta viết các bài kiểm tra kém khi không sử dụng Verus và chúng ta sẽ không, nhìn chung, mong đợi một con người đã sử dụng Verus viết các bài kiểm tra đơn vị tồi, giống như chúng ta sẽ không mong đợi một con người sử dụng Clojure mắc nhiều lỗi chuyển đổi byte hơn, nhưng điều này đã xảy ra ở đây vì lý do nào đó (có thể là một sự trùng hợp).

Tôi không biết liệu mọi người trong các phòng thí nghiệm AI có thể tiếp cận thông tin tốt hơn về lý do tại sao mọi thứ xảy ra hay không, nhưng ở đây bên ngoài, nhìn chung rất khó để biết tại sao điều gì đó như thế này lại xảy ra (ngay cả khi chúng tôi đã hình thành một giả thuyết hợp lý cho vấn đề ngôn ngữ, nó đòi hỏi phải chạy nhiều mẫu của nhiều ngôn ngữ, và các bài báo chúng tôi xem xét nghiên cứu cùng một điều đã không quan sát thấy mối tương quan giữa mức độ phổ biến của ngôn ngữ / hiệu quả của agent vì chúng hoặc xem xét quá ít ngôn ngữ để có thể suy luận về mối tương quan yếu như vậy hoặc chúng xem xét các vấn đề quá nhỏ và quá tầm thường).

Alloy

Alloy thường được gọi là bộ kiểm tra mô hình có giới hạn (bounded model checker). Điều này có lẽ không hoàn toàn đúng với Alloy 6 vì nó giới thiệu một số tính năng bổ sung, nhưng điều này nằm ngoài lĩnh vực chuyên môn của tôi. Tôi hiểu rằng, với Alloy, bạn thường chứng minh các thuộc tính về mô hình của mình (trái ngược với việc chứng minh rằng mã của bạn hoạt động).

Alloy có điểm số độ chính xác tệ thứ 2 và, một cách bất thường, nhìn chung đạt điểm kém ở cả mức trung bình và rất cao. Mặc dù nó không được hiển thị (vì nó dường như không thêm bất cứ điều gì), nhìn chung, kết quả có mối tương quan cao giữa mức tối đa và rất cao, vốn khá khác biệt so với kết quả ở mức trung bình.

Như chúng ta đã thấy với Verus, các agent sử dụng Alloy chủ yếu dựa vào #[test] tiêu chuẩn của Rust để đảm bảo độ chính xác và hầu hết đều loay hoay với Alloy. Một lần nữa, việc sử dụng một công cụ hình thức một cách kém hiệu quả không giúp ích gì cho độ chính xác.

Có những trường hợp riêng lẻ sử dụng Alloy gần như tìm ra một vấn đề hoặc rủi ro, nhưng ngay cả khi đó, chỉ có một số lượng nhỏ. Trong một trường hợp, Alloy đã tìm thấy một phản ví dụ, sau đó khiến agent triển khai phiên bản Rust với một biện pháp giảm thiểu cho lỗi tiềm ẩn. Thật không may, phản ví dụ dựa trên sự tràn 8-bit không thể xảy ra trong thực tế vì việc triển khai thực tế sử dụng usize 64-bit mà không có khả năng tràn với các đầu vào đã cho, vì vậy nó chỉ làm cho mã phức tạp hơn mà không ngăn chặn được lỗi thực tế.

Trong một trường hợp khác, đặc tả Alloy không chính xác và một bài kiểm tra liên quan đã thất bại. Sau khi bài kiểm tra thất bại, agent đã sửa đặc tả Alloy. Nếu đặc tả chính xác, có lẽ agent đã viết mã chính xác mà không gặp thất bại. Có một số trường hợp có khả năng phiên bản tốt của điều này đã xảy ra, nhưng không rõ liệu một lỗi tiềm ẩn thực tế có được ngăn chặn hay không.

Các agent Alloy đã mô hình hóa những thứ liên quan chặt chẽ hơn đến thuật toán Zstd so với các agent Verus (vốn chủ yếu kiểm tra những thứ như số học), nhưng đó vẫn là mô hình hóa sai.

Kiểm thử vi sai (Differential testing)

Kiểm thử vi sai là một kỹ thuật trong đó bạn cung cấp cùng một đầu vào cho nhiều triển khai và sau đó so sánh kết quả để tìm vấn đề. Về nguyên tắc, điều này có vẻ là một điều hợp lý để thử với các LLM vì chúng ta thường nhận được các kết quả khác nhau từ các lần tung xúc xắc khác nhau, và như chúng tôi đã lưu ý ở đây, việc để một agent lặp lại nhiều hơn trên một triển khai (có thể chỉ là một phần của toàn bộ, thậm chí có thể chỉ là một phần của một hàm) thường hoạt động kém hơn so với việc để agent bắt đầu lại từ đầu.

Nhưng điều này đã mang lại cho chúng tôi kết quả tệ thứ ba. Trong trường hợp này, chúng tôi có kết quả cao hơn một chút so với trung bình ở mức rất cao và thấp hơn nhiều so với trung bình ở mức trung bình. Không có agent nào tạo ra hai triển khai đầy đủ để so sánh. Trong số 160 lần chạy, 135 lần đã làm điều gì đó mà bạn có thể gọi là kiểm thử vi sai, nhưng giống như các điều kiện khác mà chúng ta đã thấy, chúng nhìn chung là tầm thường và thực tế là vô dụng. Và, trong các trường hợp mà kiểm thử vi sai có thể đã bắt được một lỗi, thay vì triển khai mọi thứ theo những cách độc lập, các agent chỉ làm cùng một việc hai lần và mã hóa cùng một lỗi trong cả hai phiên bản.

Đôi khi tôi bảo các agent làm mọi việc một cách độc lập và khiến chúng khởi chạy với các ngữ cảnh riêng biệt, nhưng điều này đã không được thực hiện hiệu quả cho kiểm thử vi sai và các agent thường chỉ viết cùng một thứ hai lần.

Kỹ năng Hegel

Việc thảo luận về cách kỹ năng Hegel chính thức thay đổi hành vi của Hegel là hợp lý, nhưng theo thứ tự độ chính xác ngược lại, Kỹ năng Hegel xuất hiện phía trên Hegel vì kết quả về độ chính xác tệ hơn. Xem phần Hegel bên dưới để thảo luận về kỹ năng này.