Những người coi trọng việc lập ngân sách ngữ cảnh sẽ có trải nghiệm hỗ trợ AI tốt hơn so với những người chỉ tích lũy kỹ năng một cách mù quáng.
Tác giả và nguồn bài viết: 0x9999in1, ME News
Tóm lại
- Hệ sinh thái kỹ năng/ plug-in trợ lý lập trình AI chính thống hiện nay đang trải qua tình trạng "khó tiêu sau giai đoạn phát triển mạnh" - các kỹ năng lặp đi lặp lại, dư thừa và lỗi thời đang tích tụ, làm suy giảm nghiêm trọng các tài nguyên cửa sổ ngữ cảnh quý giá.
- Lobster Dad mã nguồn mở một siêu kỹ năng được thiết kế đặc biệt để thực hiện "kiểm tra toàn diện" các Kỹ năng, bao gồm năm chức năng cốt lõi: kiểm toán ngân sách, phát hiện trùng lặp, sàng lọc các mục không hoạt động, kiểm toán mục lục gốc và đơn giản hóa mô tả.
- Cửa sổ ngữ cảnh là một trong những tài nguyên khan hiếm nhất trong các mô hình AI lớn. Sự tồn tại của mọi kỹ năng dư thừa đều sử dụng các token vô nghĩa để chiếm không gian suy luận mà bạn thực sự cần.
- Giá trị cốt lõi của công cụ này không phải là "một kỹ năng khác", mà là sử dụng một kỹ năng để quản lý tất cả các kỹ năng khác—điều này nằm ở cấp độ cơ sở hạ tầng.
- Sự hỗn loạn trong hệ sinh thái Kỹ năng không phải là hiện tượng riêng lẻ, mà là một vấn đề mang tính cấu trúc. Các hệ thống plug-in thiếu cơ chế kiểm toán cuối cùng sẽ dẫn đến sự gia tăng tính hỗn loạn.
- Mã nguồn mở có nghĩa là cộng đồng có thể phát triển dựa trên nền tảng này, và đây có thể là điểm khởi đầu cho việc chuẩn hóa quản trị kỹ năng.
Trước tiên, hãy cùng bàn về tình hình hiện tại: kho kỹ năng của bạn có thể đã trở thành bãi chứa đồ linh tinh.
Nghe có vẻ khắc nghiệt. Nhưng nếu bạn mở cài đặt trợ lý AI của mình, đếm xem bạn đã cài đặt bao nhiêu kỹ năng và nhớ lại lần cuối bạn sử dụng những kỹ năng nào.
Câu trả lời rất có thể sẽ khiến bạn không nói nên lời.
Bắt đầu từ nửa cuối năm 2025, các công cụ lập trình AI như Cursor, Windsurf, Codex và Claude Code sẽ cùng nhau bước vào một "cuộc chạy đua kỹ năng". Cộng đồng người dùng sẽ tạo ra một lượng lớn nội dung, các thư viện tích hợp chính thức sẽ tiếp tục được mở rộng, và các cấu hình cá nhân sẽ được chồng lớp lên nhau.
Và kết quả là gì?
Một người dùng thành thạo điển hình dễ dàng sở hữu hơn 50 kỹ năng. Trong đó, có lẽ chỉ chưa đến 10 kỹ năng được sử dụng hàng ngày. 40 kỹ năng còn lại nằm im lặng, được tải vào ngữ cảnh lần khi bắt đầu cuộc trò chuyện, âm thầm tiêu tốn ngân sách token, và sau đó—không làm gì cả.
Đây không phải là sự lãng phí. Đây là một tội ác.
Tại sao tôi lại nói vậy? Bởi vì cửa sổ ngữ cảnh không phải là vô hạn. Ngay cả đến năm 2026, độ dài ngữ cảnh hiệu quả của các mô hình phổ biến cũng chỉ nằm trong khoảng từ 128.000 đến 200.000 từ. Nghe có vẻ nhiều, phải không? Nhưng hãy thử tính toán xem: lời nhắc hệ thống, lịch sử hội thoại, đoạn mã, nội dung tệp, định nghĩa công cụ, mô tả kỹ năng... không gian thực sự còn lại để "suy nghĩ" ít hơn nhiều so với bạn tưởng tượng.
Mỗi đoạn văn mô tả kỹ năng không cần thiết bổ sung chiếm 200 token; 50 đoạn như vậy sẽ tương đương với 10.000 token. Mười nghìn token là đủ để mô hình đọc thêm 400 dòng mã.
Đây không phải là một suy diễn lý thuyết. Đây là điều xảy ra mỗi ngày.
Sao không ai làm gì về chuyện này? Bởi vì phép cộng dễ hơn phép trừ gấp triệu lần.
Con người có một thiên kiến tâm lý ăn sâu trong tiềm thức: thiên kiến cộng trừ.
Đối diện một vấn đề, chúng ta thường nghĩ đến việc "thêm vào" để giải quyết nó, thay vì "bớt đi". Một nghiên cứu năm 2021 được công bố trên tạp chí Nature đã chỉ ra rõ ràng rằng con người thường xuyên bỏ qua các "giải pháp trừ đi" khi muốn cải thiện mọi thứ, ngay cả khi việc trừ đi hiệu quả hơn.
Hệ sinh thái Kỹ năng tái hiện hoàn hảo sự sai lệch này.
Một thành viên cộng đồng đã viết một kỹ năng mới và phát hành nó. Người dùng nghĩ, "Có lẽ nó sẽ hữu ích," và đã cài đặt nó. Chính thức nghĩ, "Nó có chức năng rộng," và đã đưa nó vào trò chơi.
Ai sẽ xóa chúng? Ai sẽ kiểm toán? Ai sẽ nói, "Kỹ năng này trùng lặp với kỹ năng kia, hãy xóa một trong hai"?
Không có ai cả.
Xóa một kỹ năng cũ không mang lại khích lệ. Tạo một kỹ năng mới sẽ giúp bạn nhận được sao, sự công nhận từ cộng đồng và một vị trí trong sơ yếu lý lịch. Còn xóa một kỹ năng cũ thì sao? Chẳng được gì cả.
Đây là một vấn đề nan giải về cấu trúc. Nó không phải là vấn đề kỹ thuật, mà là vấn đề khích lệ.
Cho đến khi có người quyết định: Tôi không quan tâm đến khích lệ, tôi sẽ làm điều này.
Cha đẻ của loài tôm hùm hành động: Sử dụng một kỹ năng để chi phối mọi kỹ năng.
Ai là "Cha đẻ của Lobster"? Nếu bạn thường xuyên tham gia các cộng đồng công cụ lập trình AI, bạn sẽ quen thuộc với ID này. Là một độ sâu tích cực lâu năm trong hệ sinh thái Codex và Claude, ông nổi tiếng với tư duy hệ thống và phương pháp kỹ thuật tỉ mỉ. Danh hiệu "Cha đẻ của Lobster" tự nó đã mang lại sự công nhận trong cộng đồng—được phong danh hiệu "Cha đẻ" cho thấy rằng trong một lĩnh vực chuyên môn nhất định, ông là một nhân vật không thể thiếu.
Lần, thứ mà anh ấy mã nguồn mở về cơ bản là một kỹ năng bậc cao .
Kỹ năng siêu cấp là gì? Đó là "kỹ năng quản lý kỹ năng". Nó không tự viết mã, gọi API hay tạo tài liệu cho bạn. Nó chỉ làm một việc duy nhất: cung cấp cho bạn một đánh giá toàn diện, định lượng và có thể thực hiện được về tất cả các kỹ năng hiện có của bạn.
Năm chức năng chính được phân tích chi tiết từng phần.
Chức năng 1: Gợi ý kỹ năng Kiểm toán ngân sách
Đây là phiên bản "nguy hiểm" nhất.
Chức năng của nó rất đơn giản: tính toán không gian mã thông báo ngữ cảnh mà mỗi Kỹ năng chiếm dụng, xác định tỷ lệ phần trăm ngân sách tổng thể mà mỗi Kỹ năng chiếm dụng, và sau đó đưa ra các đề xuất tối ưu hóa.
Tại sao điều này lại quan trọng? Bởi vì đại đa số người dùng hoàn toàn không biết Skill thực sự tiêu tốn bao nhiêu tài nguyên.
Bạn có thể nghĩ rằng việc cài đặt một Skill chỉ đơn giản là thêm một tính năng khác. Trên thực tế, văn bản mô tả, định nghĩa tham số, mã ví dụ và quy tắc kích hoạt của mỗi Skill đều phải được viết vào các lời nhắc của hệ thống. Mô hình phải "đọc" tất cả thông tin này trước khi quyết định có gọi nó lần lần lặp suy luận hay không.
Nó giống như mang một chiếc ba lô chứa 50 món đồ. Bạn nghĩ, "Đáng giá đấy," nhưng cứ mỗi kilogram thừa ra, bạn lại tiêu hao thêm năng lượng. Đến lúc bạn thực sự cần chạy nước rút, bạn đã kiệt sức rồi.
Kiểm toán ngân sách giống như việc mở ba lô của bạn ra và nói, "Con dao đa năng Thụy Sĩ này nặng 3 kg nhưng bạn chưa bao giờ dùng đến, hãy vứt nó đi."
Chức năng 2: Phát hiện kỹ năng lặp đi lặp lại
Vấn đề mà tính năng này giải quyết có thể nghiêm trọng hơn bạn nghĩ.
Phạm vi quét của nó bao gồm bốn cấp độ:
- Thư viện tích hợp Codex
- Bộ nhớ plug-in
- thư viện mã
- Mục lục gốc Kỹ năng cá nhân
Quét qua các cấp độ để tìm các kỹ năng có cùng tên, mô tả tương tự và chức năng trùng lặp, đánh dấu các mục dư thừa.
Tại sao lại có sự lặp lại? Có nhiều lý do.
Tài liệu chính thức bao gồm kỹ năng "định dạng mã" được tích hợp sẵn, nhưng bạn có thể không biết rằng một kỹ năng khác với chức năng gần như tương tự đã được cài đặt từ cộng đồng. Hai kỹ năng, cùng thực hiện một việc, nhưng lại tiêu tốn hai ngân sách khác nhau.
Hoặc, một cách tế nhị hơn: Bạn đã viết một kỹ năng tùy chỉnh để xử lý việc phân tích cú pháp JSON sáu tháng trước, và sau đó thư viện chính thức được cập nhật, bổ sung thêm một kỹ năng tốt hơn. Phiên bản cũ của bạn vẫn còn đó, và không ai bảo bạn xóa nó đi.
Việc phát hiện trùng lặp không chỉ dựa vào tên. Các mục có tên khác nhau nhưng mô tả rất giống nhau cũng sẽ được gắn cờ. Đây mới là phần kỹ thuật thực sự — nó thực hiện so sánh độ tương đồng về ngữ nghĩa, chứ không chỉ đơn thuần là so khớp chuỗi.
Chức năng 3: Sàng lọc các kỹ năng chưa được sử dụng
Dựa trên nhật ký lịch sử, hãy xác định những "kỹ năng zombie" đã không được sử dụng trong một thời gian dài.
Nguyên tắc rất rõ ràng: nếu một kỹ năng chưa từng được kích hoạt trong 30, 60 hoặc 90 ngày qua, điều đó có thể cho thấy một trong hai điều sau: hoặc quy trình làm việc của bạn không cần đến kỹ năng đó, hoặc các điều kiện kích hoạt của nó được thiết kế kém, khiến mô hình không bao giờ chọn nó.
Cho dù là trường hợp nào, kết luận cũng giống nhau: đó là sự lãng phí ngân sách.
Tính năng này xuất ra một "danh sách ứng viên sạch". Lưu ý rằng đó là "ứng viên", chứ không phải là xóa trực tiếp. Quyết định cuối cùng thuộc về người dùng. Thiết kế này khá tiết chế và thông minh - nó biết rõ giới hạn của mình.
Một số kỹ năng tuy hiếm khi được sử dụng nhưng lại vô cùng quan trọng. Ví dụ, "hỗ trợ di chuyển cơ sở dữ liệu" có thể chỉ được dùng một lần mỗi ba tháng, nhưng lại có thể cứu nguy khi cần thiết. Do đó, kết quả sàng lọc chỉ nên được dùng tham khảo , chứ không phải để đánh giá.
Chức năng 4: Kiểm toán mục lục mục gốc kỹ năng
Tính năng này thiên về "vận hành và bảo trì", nhưng nó cực kỳ hữu ích.
Chức năng: đếm số mục lục nguồn của tất cả các Kỹ năng, đánh dấu trạng thái bật/tắt của chúng và theo dõi Chuỗi tải.
Tại sao điều này lại cần thiết? Bởi vì các kỹ năng đến từ nhiều nguồn khác nhau. Một số đến từ cấu hình toàn cục, một số từ cấu hình cấp dự án, một số từ việc tự động chèn plug-in và một số từ việc tạo người dùng thủ công.
Khi bạn chỉ có một số ít kỹ năng, bạn sẽ dễ dàng nắm bắt được tình hình. Nhưng khi số lượng tăng lên đến hàng chục, bạn sẽ mất phương hướng về "kỹ năng này đến từ đâu", "liệu mình có thể xóa nó một cách an toàn không", và "việc xóa nó có ảnh hưởng đến những thứ khác không".
Kiểm toán mục lục gốc giống như việc vẽ một bản đồ cho bạn. Nó cho bạn biết mỗi kỹ năng nằm ở đâu, ai đã tải nó lên và liệu nó hiện đang hoạt động hay không.
Với bản đồ này, bạn có thể tiến hành phẫu thuật một cách an toàn.
Tính năng 5: Đơn giản hóa và tối ưu hóa mô tả
Tính năng cuối cùng, trông có vẻ "nhỏ nhất", thực chất lại có sức ảnh hưởng rất lớn.
Chức năng: Xác định các kỹ năng có mô tả quá dài dòng và đề xuất các giải pháp ngắn gọn.
Tại sao độ dài mô tả lại quan trọng đến vậy? Quay lại với điều chúng ta đã nói trước đó: Mô tả kỹ năng được bao gồm trong các lời nhắc của hệ thống. Mỗi từ là một token. Nếu một mô tả kỹ năng có thể được rút gọn từ 200 token xuống còn 80 token, thì không gian tiết kiệm được, nhân với số lượng kỹ năng, sẽ trở nên khá đáng kể.
Nhiều kỹ năng do cộng đồng đóng góp được mô tả giống như tóm tắt bài báo khoa học — bối cảnh, động lực, các tình huống áp dụng, biện pháp phòng ngừa, ví dụ về đầu vào và đầu ra, tất cả đều rất chi tiết. Người viết đã bỏ ra rất nhiều công sức, nhưng xét từ góc độ kỹ thuật, điều này là thiết kế quá mức cần thiết.
Mô tả mà một mô hình cần phải chính xác, độc đáo và dễ phân biệt. Chỉ cần sử dụng ít từ nhất có thể để mô hình hiểu "kỹ năng này làm gì và khi nào nên sử dụng nó". Mỗi từ thừa đều là sự lãng phí tài nguyên ngữ cảnh.
Tính năng đơn giản hóa mô tả về cơ bản là "tối ưu hóa ngược của kỹ thuật tạo lời nhắc" - không phải là viết lời nhắc tốt hơn, mà là nén các lời nhắc hiện có để ngắn gọn hơn mà không làm mất thông tin.
Giá trị của nó nằm ở đâu? Không phải ở chức năng, mà ở tư duy.
Năm chức năng này đã được phân tích chi tiết. Xét riêng lẻ, không chức năng nào có vẻ đặc biệt đột phá. Nhưng khi kết hợp lại, chúng thể hiện một sự thay đổi trong tư duy:
Từ "tạo ra thêm kỹ năng" đến "quản lý các kỹ năng hiện có".
Ý nghĩa của vấn đề này không nằm ở lượng mã lập trình hay độ phức tạp của thuật toán, mà nằm ở chỗ cuối cùng cũng có người coi vấn đề này như một "vấn đề ưu tiên hàng đầu".
Trong hai năm qua, hệ sinh thái công cụ AI đã tập trung hoàn toàn vào việc "thêm tính năng": nhiều mô hình hơn, nhiều chức năng hơn, nhiều plug-in hơn và nhiều kỹ năng hơn. Họ đã phát triển nhanh chóng và mạnh mẽ, không ai nhìn lại phía sau.
Nhưng bất cứ ai có kinh nghiệm về kỹ thuật đều biết rằng nếu độ phức tạp của một hệ thống tăng trưởng đến một mức nhất định, nó sẽ sụp đổ nếu không có cơ chế quản trị tương ứng.
Đó không phải là điều có thể xảy ra. Đó là điều chắc chắn sẽ xảy ra.
Trong kỹ thuật phần mềm, có một khái niệm gọi là "nợ kỹ thuật". Mỗi giải pháp tạm thời, mỗi quyết định "tạm thời cứ để vậy", mỗi sự dư thừa không được sử dụng đều là một dạng nợ. Bạn càng vay nhiều, lãi suất càng cao, cho đến một ngày bạn nhận ra rằng tất cả năng lượng của mình đều dành để trả nợ, không còn năng lượng cho những việc mới.
Vấn đề nợ kỹ thuật trong hệ sinh thái Skill đã đến mức cần phải được giải quyết.
Công cụ được cha đẻ của ngành tôm hùm mô tả về cơ bản là một kiểm toán nợ . Nó không giúp bạn trả hết nợ, nhưng nó cho bạn biết bạn nợ bao nhiêu, nợ ở đâu và khoản nợ nào nên được trả trước.
Điều này có giá trị hơn nhiều so với việc nói "Tôi đã viết thêm một kỹ năng hữu ích nữa".
Tầm quan trọng của mã nguồn mở: từ các công cụ cá nhân đến các tiêu chuẩn cộng đồng
Quyết định mã nguồn mở của cha đẻ loài tôm hùm tự nó đã là một điều đáng để bàn luận.
Anh ấy hoàn toàn có thể biến công cụ này thành một plug-in trả phí. Nhu cầu thị trường rất rõ ràng, vấn đề thực sự tồn tại, và sẽ không thiếu người dùng trả phí. Nhưng anh ấy đã chọn biến nó thành mã nguồn mở.
Tại sao?
Tôi cho rằng có hai yếu tố cần xem xét.
Lớp đầu tiên: Để công cụ này thực sự phát huy giá trị, nó cần sự hợp tác của cộng đồng. Các nền tảng AI khác nhau có cơ chế tải kỹ năng, định dạng nhật ký và cấu trúc mục lục khác nhau. Một người có thể không đủ khả năng để điều chỉnh nó, nhưng hàng trăm người đóng góp thì có thể.
Lớp thứ hai: Ông ấy có thể muốn quảng bá không chỉ một công cụ, mà là một tiêu chuẩn . Việc quản trị kỹ năng nên được thực hiện như thế nào? Phạm vi của kiểm toán là gì? Đâu là những thực tiễn tốt nhất cho việc phân bổ ngân sách? Những câu hỏi này đòi hỏi sự đồng thuận của cộng đồng để tìm ra câu trả lời.
Mã nguồn mở là cách tốt nhất để đạt được sự đồng thuận.
Nhìn lại lịch sử kỹ thuật phần mềm, ESLint đã trở thành tiêu chuẩn thực tế cho kiểu mã JavaScript, Black cho định dạng Python và Prettier cho kiểu mã giao diện người dùng vì mã nguồn mở cho phép cộng đồng tham gia vào việc xây dựng các quy tắc.
Liệu kỹ năng "Cha đẻ của Tôm Hùm" có thể trở thành một ESLint (Engineering-to-Skill) để quản lý kỹ năng hay không?
Còn quá sớm để đưa ra nhận định ngay bây giờ, nhưng hướng đi này là đúng đắn.
Một câu hỏi sâu sắc hơn: Liệu hệ thống kỹ năng có cần được thiết kế lại hay không?
Các công cụ kiểm toán giải quyết những vấn đề hiện có. Nhưng nếu chúng ta mở rộng tầm nhìn, chúng ta sẽ phát hiện ra một vấn đề cơ bản hơn:
Tại sao Skill lại mất kiểm soát?
Câu trả lời là: Hệ thống Kỹ năng hiện tại thiếu quản lý vòng đời.
Một khi kỹ năng được tạo ra, nó sẽ tồn tại vô thời hạn. Không có cơ chế hết hạn, không có việc loại bỏ phiên bản và không có sự suy giảm hoạt động. Nó giống như một tiến trình không bao giờ chết, chiếm dụng tài nguyên cho đến khi ai đó tự tay tắt nó đi.
Hãy so sánh điều này với việc quản lý tiến trình của một hệ điều hành: nó bao gồm việc tạo, lập lịch, ngủ đông và chấm dứt. Nó có một vòng đời khép kín hoàn chỉnh.
Hãy so sánh các phương pháp quản lý phụ thuộc của các trình quản lý gói: npm audit kiểm tra lỗ hổng bảo mật, npm outdated kiểm tra các phụ thuộc đã hết hạn và npm prune dọn dẹp các gói không sử dụng. Các công cụ quản trị là một phần của hệ sinh thái.
Còn hệ thống kỹ năng thì sao? Tạo → Sử dụng → ...chỉ vậy thôi. Thiếu lượng lớn bước.
Các công cụ do cha đẻ của ngành công nghệ tôm hùm phát triển về cơ bản đang sử dụng các công cụ bên ngoài để bù đắp những thiếu sót trong thiết kế hệ thống . Chúng hữu ích, nhưng cũng cho thấy thực tế rằng cơ sở hạ tầng cho các nền tảng công cụ AI trong quản trị kỹ năng vẫn còn ở giai đoạn sơ khai.
Đây không phải là lời chỉ trích. Đây là một giai đoạn phát triển tất yếu. Từ năm 2024 đến năm 2025, mục tiêu chính của nền tảng là "đưa hệ sinh thái hoạt động", còn vấn đề quản trị sẽ được giải quyết sau. Nhưng đến giữa năm 2026, hệ sinh thái sẽ đã hoạt động. Đã đến lúc phải bắt kịp.
Tóm lại
Quay trở lại câu hỏi ban đầu: Có bao nhiêu kỹ năng trong trợ lý AI của bạn thực sự đang hoạt động?
Nếu bạn không thể trả lời câu hỏi, điều đó có nghĩa là bạn cần phải đi khám sức khỏe.
Cha đẻ của ngành công nghiệp tôm hùm đã cung cấp các công cụ. Miễn phí. Mã nguồn mở. Năm chiều, phạm vi bao phủ toàn diện.
Việc bạn sử dụng hay không là chuyện riêng của bạn.
Nhưng có một điều tôi chắc chắn: những người coi trọng việc lập ngân sách ngữ cảnh sẽ có trải nghiệm hỗ trợ AI tốt hơn những người chỉ tích lũy kỹ năng một cách mù quáng.
Bởi vì trí tuệ nhân tạo không phải là toàn năng. Nó có khả năng chú ý, bộ nhớ và nguồn lực suy luận hạn chế. Thông tin càng chính xác và đầy đủ, kết quả đầu ra mà nó cung cấp càng tốt hơn.
Đây không phải là siêu hình học. Đây là lý thuyết thông tin.
Ngay từ năm 1948, Shannon đã cho chúng ta biết rằng dung lượng kênh truyền có hạn, và càng nhiều nhiễu thì tốc độ truyền tải thông tin hiệu quả càng thấp.
Những kỹ năng zombie trong danh sách kỹ năng của bạn chỉ là vô nghĩa mà thôi.
Giết chúng đi.
Tham khảo
- Adams, GS, Converse, BA, Hales, AH, & Klotz, LE (2021). Mọi người thường xuyên bỏ qua những thay đổi mang tính trừ đi. Nature , 592(7853), 258–261.
- Shannon, CE (1948). Lý thuyết toán học về truyền thông. Tạp chí kỹ thuật hệ thống Bell , 27(3), 379–423.
- OpenAI. (2024). Tài liệu về cửa sổ ngữ cảnh và giới hạn token của GPT-4 Turbo. https://platform.openai.com/docs/models
- Anthropic. (2025). Thẻ mô hình Claude: Sử dụng cửa sổ ngữ cảnh và chi phí nhắc nhở hệ thống. https://docs.anthropic.com/en/docs/about-claude/models
- Nhóm Cursor. (2025). Quy tắc & Kỹ năng: Cách các hướng dẫn tùy chỉnh được tải vào ngữ cảnh. Tài liệu Cursor.
- Tài liệu npm. (2025). npm-audit, npm-prune: Quản lý vòng đời gói. https://docs.npmjs.com/cli
- Cha đẻ của loài tôm hùm. (2026). Kỹ năng Siêu kỹ năng Kiểm tra Sức khỏe [Dự án Mã nguồn mở]. Kho lưu trữ GitHub.
- Sculley, D., et al. (2015). Nợ kỹ thuật tiềm ẩn trong các hệ thống học máy. Tiến bộ trong các hệ thống xử lý thông tin thần kinh (NeurIPS) , 28.
