Those who take context budget seriously will have a better AI-assisted experience than those who mindlessly stack Skill.

Tác giả bài viết, nguồn: 0x9999in1, ME News

Tóm tắt ngắn

• Hệ sinh thái kỹ năng/plugin của các trợ lý lập trình AI phổ biến hiện nay đang trải qua tình trạng “tiêu hóa kém sau giai đoạn phát triển bùng nổ” – sự tích tụ các kỹ năng trùng lặp, dư thừa và vô dụng đang xâm phạm nghiêm trọng tài nguyên cửa sổ ngữ cảnh quý giá.
• Lobster Dad đã mở nguồn một meta-skill chuyên dụng để thực hiện "kiểm tra toàn diện" cho Skill, 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, quét tài nguyên bỏ trống, kiểm toán thư mục gốc và tinh gọn mô tả.
• Cửa sổ ngữ cảnh là một trong những tài nguyên khan hiếm nhất của mô hình AI lớn, sự hiện diện của mỗi Skill thừa thãi đều đang chiếm dụng không gian suy luận mà bạn thực sự cần bằng các token vô nghĩa.
• Giá trị cốt lõi của công cụ này không phải là "thêm một Skill nữa", mà là dùng một Skill để quản lý tất cả các Skill—nó ở cấp độ hạ tầng.
• Sự hỗn loạn trong hệ sinh thái Skill không phải là hiện tượng cá biệt, mà là vấn đề cấu trúc. Hệ thống plugin không có cơ chế kiểm toán cuối cùng sẽ dẫn đến tăng entropy.
• 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, đây có thể là điểm khởi đầu cho tiêu chuẩn hóa quản trị Skill.

Trước tiên hãy nói về hiện trạng: kho kỹ năng của bạn có thể đã trở thành một bãi rác

Câu này nghe không dễ chịu. Nhưng bạn hãy mở cấu hình trợ lý AI của mình, đếm xem đã cài bao nhiêu Skill, rồi nghĩ lại xem lần cuối bạn dùng đến những cái nào.

Câu trả lời rất có thể khiến mọi người im lặng.

Từ nửa sau năm 2025, các công cụ lập trình AI như Cursor, Windsurf, Codex, Claude Code đồng loạt bước vào "cuộc chạy đua vũ trang kỹ năng". Các đóng góp từ cộng đồng tăng đột biến, thư viện tích hợp sẵn của nền tảng không ngừng mở rộng, và các cấu hình cá nhân được tích lũy ngày càng nhiều lớp.

What’s the result?

Một người dùng nặng điển hình, số lượng Skill dễ dàng vượt quá 50. Trong số đó, có thể dưới 10 Skill được kích hoạt hàng ngày. 40 Skill còn lại nằm yên lặng, mỗi lần bắt đầu cuộc hội thoại đều được tải vào ngữ cảnh, âm thầm tiêu tốn ngân sách token, rồi—không làm gì cả.

Đây không phải là sự lãng phí. Đây là tội phạm.

Tại sao lại nói như vậy? 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 vẫn nằm trong khoảng 128K đến 200K token, nghe thì có vẻ nhiều đúng không? Nhưng bạn hãy tính 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ả Skill… không gian thực sự dành cho “suy nghĩ” xa kém hơn bạn tưởng.

Mỗi mô tả Skill vô ích chiếm 200 token, 50 cái là 10.000 token. Một vạn token, đủ để mô hình đọc thêm 400 dòng mã.

Đây không phải là suy luận lý thuyết. Đây là điều đang xảy ra mỗi ngày.

Tại sao không ai quản lý? Vì "thêm" dễ hơn "bớt" một vạn lần

Con người có một thiên kiến tâm lý ăn sâu bẩm sinh: thiên vị thêm vào (Addition Bias).

Khi đối mặt với vấn đề, chúng ta có xu hướng tự nhiên muốn "thêm vào" để giải quyết, thay vì "bỏ bớt đi". Một nghiên cứu được công bố trên tạp chí Nature năm 2021 đã chỉ rõ rằng con người hệ thống bỏ qua các giải pháp "giảm bớt", ngay cả khi chúng hiệu quả hơn.

Hệ sinh thái Skill đã tái tạo hoàn hảo sự lệch lạc này.

Cộng tác viên cộng đồng đã viết một Skill mới và phát hành. Người dùng cảm thấy "có lẽ sẽ hữu ích" và cài đặt. Đội ngũ chính thức cho rằng "phạm vi chức năng rộng", nên tích hợp sẵn.

Ai xóa? Ai kiểm toán? Ai nói “Kỹ năng này trùng với cái kia, xóa một cái đi”?

Không ai.

Vì xóa bỏ không mang lại phần thưởng. Hãy tạo một Skill mới, có thể nhận được star, được cộng đồng công nhận và đưa vào hồ sơ xin việc. Dọn dẹp một Skill cũ? Bạn sẽ chẳng nhận được gì cả.

Đây là một sự khó khăn về cấu trúc. Không phải vấn đề kỹ thuật, mà là vấn đề về cơ chế kích thích.

Cho đến khi có người quyết định: Tôi không quan tâm đến phần thưởng, việc này tôi sẽ làm.

Cha của tôm hùm ra tay: Dùng một Skill để quản lý mọi Skill

Ai là cha đẻ của con tôm hùm? Nếu bạn tham gia cộng đồng công cụ lập trình AI, bạn sẽ không lạ gì với ID này. Một người chơi sâu sắc lâu năm trong hệ sinh thái Codex và Claude, nổi bật với tư duy hệ thống và sự cầu toàn về kỹ thuật. Chính cái tên “cha đẻ của con tôm hùm” đã thể hiện sự công nhận từ cộng đồng — được gọi là “cha đẻ” nghĩa là trong lĩnh vực chuyên sâu nào đó, anh ta là người không thể bỏ qua.

Điều anh ấy mở nguồn lần này, về bản chất, là một kỹ năng siêu (Meta-Skill).

Khái niệm kỹ năng nền tảng là gì? Đó là “kỹ năng quản lý các kỹ năng”. Nó không giúp bạn viết mã, không giúp bạn gọi API, cũng không giúp bạn tạo tài liệu. Nó chỉ làm một việc duy nhất: thực hiện một cuộc kiểm tra toàn diện, định lượng và có thể thực thi cho tất cả các kỹ năng bạn đang có.

Five features, broken down one by one.

Đây là cái khó nhất.

Nó thực hiện một việc rất trực tiếp: tính toán không gian token ngữ cảnh mà mỗi Skill chiếm dụng, xác định tỷ lệ phần trăm của từng Skill so với ngân sách tổng, sau đó đưa ra các đề xuất tối ưu hóa.

Tại sao điều này lại quan trọng? Vì phần lớn người dùng hoàn toàn không nhận thức được "Skill đã tiêu tốn bao nhiêu tài nguyên".

Bạn nghĩ rằng việc thêm một Skill chỉ là thêm một tính năng. Thực tế, mọi nội dung 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 đưa vào prompt hệ thống. Mỗi lần mô hình suy luận, nó đều phải “đọc” lại toàn bộ những nội dung này trước khi quyết định có gọi hay không.

Giống như bạn đang mang một chiếc ba lô leo núi chứa 50 công cụ. Bạn nghĩ "mang theo thì không亏", nhưng mỗi thêm một kg, năng lượng của bạn lại tiêu hao thêm một chút. Khi bạn thực sự cần tăng tốc, bạn đã hết sức rồi.

Việc kiểm toán ngân sách là mở túi ra và nói với bạn: "Chiếc dao đa năng Thụy Sĩ nặng 3kg nhưng bạn chưa bao giờ dùng đến, hãy vứt đi."

Vấn đề mà tính năng này giải quyết có thể nghiêm trọng hơn bạn tưởng.

Phạm vi quét của nó bao gồm bốn cấp độ:

• Thư viện tích hợp trong Codex
• Plugin cache
• Code repository
• Root directory of personal skills

Quét xuyên cấp độ 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 trùng lặp.

Tại sao lại có sự lặp lại? Có nhiều nguyên nhân.

Hệ thống chính thức đã tích hợp sẵn một Skill "định dạng mã", bạn không biết và lại cài thêm một Skill từ cộng đồng có chức năng gần như giống hệt. Hai Skill làm cùng một việc, chiếm hai khoản ngân sách.

Hoặc tinh vi hơn: Sáu tháng trước, bạn đã viết một Skill tùy chỉnh để xử lý phân tích JSON, sau đó bản chính thức được cập nhật và thêm vào một phiên bản tốt hơn trong thư viện tích hợp. Phiên bản cũ của bạn vẫn còn đó, nhưng không ai thông báo cho bạn xóa nó.

Việc phát hiện trùng lặp không chỉ dựa vào tên. Những cái có tên khác nhau nhưng mô tả tương đồng cao cũng sẽ bị đánh dấu. Đó mới là phần thực sự mang tính kỹ thuật — nó phải thực hiện so sánh độ tương đồng về ngữ nghĩa, chứ không phải chỉ đơn thuần là so sánh chuỗi ký tự.

Dựa trên nhật ký lịch sử, xác định các "kỹ năng zombie" chưa được sử dụng trong thời gian dài.

Logic này rất rõ ràng: nếu một Skill chưa từng được kích hoạt trong 30 ngày, 60 ngày hay 90 ngày qua, rất có thể xảy ra hai trường hợp — hoặc quy trình làm việc của bạn không cần nó, hoặc điều kiện kích hoạt của nó được thiết kế không hợp lý khiến mô hình không bao giờ chọn nó.

Dù là loại nào, kết luận cũng giống nhau: nó đang lãng phí ngân sách.

Chức năng này tạo ra một "danh sách ứng viên để dọn dẹp". Lưu ý, đó là "ứng viên", không phải 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 rất kiềm chế và thông minh — nó biết rõ ranh giới của mình.

Một số kỹ năng thực sự là hiếm gặp nhưng lại cực kỳ quan trọng. Ví dụ như “hỗ trợ di chuyển cơ sở dữ liệu”, bạn có thể chỉ dùng đến ba tháng một lần, nhưng khi cần thì lại cứu cánh. Do đó, kết quả lọc chỉ mang tính tham khảo, không phải phán quyết.

Chức năng này mang tính chất "vận hành và bảo trì", nhưng cực kỳ hữu ích.

Nó thực hiện: thống kê tất cả các thư mục nguồn của Skill, ghi chú trạng thái bật/tắt và sắp xếp chuỗi tải.

Tại sao cần điều này? Vì nguồn của Skill là đa dạng. Một số đến từ cấu hình toàn cầu, một số từ cấu hình cấp dự án, một số từ việc tự động chèn bởi plugin, và một số từ việc người dùng tạo thủ công.

Khi số lượng Skill ít, bạn rõ ràng trong đầu. Nhưng khi số lượng tăng lên hàng chục, bạn đã không còn rõ “Skill này đến từ đâu”, “Tôi có thể xóa nó một cách an toàn không”, “Xóa nó có ảnh hưởng đến những thứ khác không?”.

Đánh giá gốc chính là vẽ cho bạn một bản đồ. Cho bạn biết mỗi Skill ở đâu, ai đã tải nó, và hiện tại nó đang hoạt động hay đã tắt.

With this map, you can perform the surgery safely.

Tính năng cuối cùng, dù trông có vẻ "nhỏ" nhất, thực chất lại có đòn bẩy cực lớn.

Nó thực hiện: Tìm ra những Skill có mô tả quá dài và đề xuất phương án rút gọn.

Tại sao độ dài mô tả lại quan trọng đến vậy? Quay lại điều đã nói ở trên: Mô tả Skill cần được đưa vào prompt hệ thống. Mỗi từ đều là một token. Nếu mô tả một Skill có thể được nén từ 200 token xuống còn 80 token, không gian tiết kiệm được nhân với số lượng Skill sẽ tạo ra tổng lượng rất đáng kể.

Nhiều kỹ năng do cộng đồng đóng góp có mô tả giống như tóm tắt luận văn—bối cảnh, động cơ, bối cảnh áp dụng, lưu ý, ví dụ đầu vào/đầu ra, dài dòng. Người viết cố gắng rất nhiều, nhưng về mặt kỹ thuật, đây là thiết kế quá mức.

Mô hình cần mô tả: chính xác, duy nhất, có thể phân biệt. Chỉ cần dùng ít từ nhất để mô hình hiểu "Skill này làm gì và khi nào nên gọi nó". Mỗi từ thừa đều là sự lãng phí ngân sách ngữ cảnh.

Mô tả tóm tắt tính năng này, về bản chất là đang thực hiện "tối ưu ngược cho kỹ thuật prompt" — không phải viết prompt tốt hơn, mà là rút gọn các prompt hiện có sao cho ngắn hơn mà không làm mất đi lượng thông tin.

Giá trị thực sự nằm ở đâu? Không phải ở tính năng, mà là ở tư duy.

Đã tách xong năm tính năng. Nhìn riêng lẻ từng cái, dường như không có cái nào "đổi mới toàn diện". Nhưng khi kết hợp lại, chúng đại diện cho một sự thay đổi trong mô hình tư duy:

Từ "tạo ra nhiều Skill hơn" đến "quản trị các Skill hiện có".

Giá trị thực sự của việc này không nằm ở số lượng mã nguồn hay độ phức tạp của thuật toán, mà ở chỗ — cuối cùng cũng đã có người coi vấn đề này là “công dân hạng nhất”.

Hai năm qua, sự chú ý của hệ sinh thái công cụ AI hoàn toàn tập trung vào "làm phép cộng". Nhiều mô hình hơn, nhiều tính năng hơn, nhiều plugin hơn, nhiều Skill hơn. Chạy nhanh, chạy mạnh, không ai quay đầu lại nhìn.

Nhưng bất kỳ ai có kinh nghiệm kỹ thuật đều biết: khi độ phức tạp của hệ thống tăng đến một mức độ nhất định, nếu không có cơ chế quản lý tương ứng, nó sẽ sụp đổ.

Không phải có thể. Mà là chắc chắn.

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 lần "để vậy đã", mỗi phần dư thừa không được dọn dẹp, đều là đang vay nợ. Vay càng nhiều, lãi càng cao, cho đến một ngày bạn nhận ra toàn bộ năng lượng đều dùng để trả nợ, không còn sức lực nào để làm việc mới.

Nợ kỹ thuật của hệ sinh thái Skill đã đến lúc phải đối mặt.

Công cụ Cha của Tôm Hùm về bản chất là một công cụ kiểm toán nợ. Nó không giúp bạn trả nợ, nhưng nó cho bạn biết: bạn nợ bao nhiêu, nợ ở đâu, và nên ưu tiên trả khoản nào.

Điều này có giá trị hơn nhiều so với "lại viết thêm một Skill hữu ích".

Ý nghĩa của mã nguồn mở: Từ công cụ cá nhân đến tiêu chuẩn cộng đồng

Cha của tôm hùm chọn mở nguồn, quyết định này bản thân nó đáng để bàn luận.

Anh ấy hoàn toàn có thể biến công cụ này thành plugin trả phí. Nhu cầu thị trường rõ ràng, điểm đau thực sự tồn tại, số lượng người dùng trả phí sẽ không ít. Nhưng anh ấy đã chọn mở nguồn.

Tại sao?

Tôi đoán 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ị, cần sự共建 của cộng đồng. Cơ chế tải Skill, định dạng nhật ký và cấu trúc thư mục của các nền tảng AI khác nhau là khác nhau. Một người không thể thích nghi được, nhưng một trăm người đóng góp thì có thể.

Lớp thứ hai: Anh ấy có thể muốn thúc đẩy không chỉ là một công cụ, mà còn là một tiêu chuẩn. Quản trị Skill nên được thực hiện như thế nào? Các chiều kích kiểm toán là gì? Những thực hành tốt nhất về phân bổ ngân sách là gì? Những câu hỏi này cần sự đồng thuận của cộng đồng để tạo ra câu trả lời.

Open source is the best way to build consensus.

Trong lịch sử kỹ thuật phần mềm, ESLint đối với quy ước mã JavaScript, Black đối với định dạng Python, Prettier đối với phong cách mã frontend—những công cụ này trở thành tiêu chuẩn thực tế nhờ vào việc mã nguồn mở cho phép cộng đồng tham gia vào việc xây dựng quy tắc.

Liệu Meta-Skill của Cha của tôm hùm có thể trở thành ESLint cho việc quản trị Skill không?

Việc đưa ra phán đoán lúc này còn quá sớm. Nhưng hướng đi là đúng.

Một câu hỏi sâu hơn: Hệ thống Skill có nên được thiết kế lại không?

Công cụ kiểm toán giải quyết vấn đề "tồn kho". Nhưng nếu chúng ta nâng cao góc nhìn một bậc, sẽ thấy một vấn đề cơ bản hơn:

Tại sao Skill lại mất kiểm soát?

Đáp án là: Hệ thống Skill hiện tại thiếu quản lý vòng đời.

Sau khi một Skill được tạo ra, nó sẽ tồn tại vĩnh viễn. Không có cơ chế hết hạn, không có việc loại bỏ phiên bản, không có suy giảm mức độ 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 có người tắt nó thủ công.

So sánh quản lý tiến trình của hệ điều hành: có tạo, có lập lịch, có ngủ đông, có kết thúc. Vòng đời hoàn chỉnh và khép kín.

再对比一下包管理器的依赖管理：npm audit检查安全漏洞、npm outdated检查过期依赖、npm prune清理无用包。治理工具是生态的一部分。

Hệ thống Skill thì sao? Tạo → Sử dụng → … hết rồi. Thiếu rất nhiều bước ở giữa.

Công cụ của Cha của Con Tôm Hùm về bản chất là sử dụng công cụ bên ngoài để bù đắp cho sự thiếu hụt trong thiết kế hệ thống. Nó rất hữu ích, nhưng nó cũng phơi bày một thực tế: cơ sở hạ tầng về quản trị Skill của các nền tảng công cụ AI vẫn còn ở giai đoạn nguyên thủy.

Đây không phải là sự chỉ trích. Đây là giai đoạn phát triển tất yếu. Từ năm 2024 đến 2025, mục tiêu hàng đầu của nền tảng là “kích hoạt hệ sinh thái”, việc quản trị có thể để sau. Nhưng đến giữa năm 2026, hệ sinh thái đã vận hành. Đã đến lúc phải bù đắp.

Viết ở cuối

Trở lại câu hỏi ban đầu: Trong trợ lý AI của bạn, có bao nhiêu Skill đang hoạt động?

Nếu bạn không trả lời được, điều đó cho thấy bạn cần đi khám sức khỏe.

Cha của tôm hùm đã cung cấp công cụ. Miễn phí. Mã nguồn mở. Năm chiều, bao phủ toàn diện.

Dùng hay không, đó là việc của bạn.

But one thing I’m certain about: those who take context budget seriously will have a better AI-assisted experience than those who mindlessly stack Skill.

Vì AI không phải là vạn năng. Sự chú ý của nó có hạn, trí nhớ của nó có hạn, tài nguyên suy luận của nó cũng có hạn. Thông tin bạn cung cấp cho nó càng chính xác và sạch sẽ, thì đầu ra nó trả về cho bạn càng tốt.

Đây không phải là huyền học. Đây là lý thuyết thông tin.

Shannon đã chỉ ra từ năm 1948 rằng: dung lượng kênh có hạn, nhiễu càng nhiều thì tỷ lệ 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ính là tiếng ồn.

Take them out.

Tham khảo

1. Adams, G. S., Converse, B. A., Hales, A. H., & Klotz, L. E. (2021). Mọi người hệ thống bỏ qua các thay đổi loại trừ.Nature, 592(7853), 258–261.
2. Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal, 27(3), 379–423.
3. 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
4. Anthropic. (2025). Thẻ mô hình Claude: Sử dụng cửa sổ ngữ cảnh và chi phí lệnh hệ thống. https://docs.anthropic.com/en/docs/about-claude/models
5. Nhóm Cursor. (2025). Quy tắc & Kỹ năng: Cách tải hướng dẫn tùy chỉnh vào ngữ cảnh. Tài liệu Cursor.
6. Tài liệu npm. (2025). npm-audit, npm-prune: Quản lý vòng đời gói. https://docs.npmjs.com/cli
7. Cha của tôm hùm. (2026). Skill Health Check Meta-Skill [Dự án mã nguồn mở]. GitHub Repository.
8. Sculley, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems (NeurIPS), 28.