Ang mga taong seryosong tumutugon sa kanilang budget para sa konteksto ay makakaranas ng mas mabuting AI-assisted experience kaysa sa mga taong walang pag-iisip na nagdadagdag ng Skill.

May-akda at pinagkukunan ng artikulo: 0x9999in1, ME News

TL;DR

• Ang kasalukuyang ekosistema ng mga skill o plugin ng pangunahing AI code assistants ay dumadaan sa "pagkakalito pagkatapos ng wild growth"—pagkakaroon ng paulit-ulit, sobrang dami, at mga patay na skill na malubhang nagpapababa sa halaga ng mga resource ng context window.
• Ang Lobster Dad ay nagbukas ng isang meta-skill na espesyal na ginawa para sa "buong katawan na pagsusuri" ng Skill, na sumasakop sa limang pangunahing tampok: pagsusuri ng budget, paghahanap ng paulit-ulit, pagpapalit ng walang ginagawa, pagsusuri ng root directory, at pagpapalakas ng deskripsyon.
• Ang kontekstong window ay isa sa pinakamakukulang na yaman ng malalaking AI model, at ang bawat walang kahulugang Skill ay nagpapaloko ng token na dapat ay gamitin para sa tamang pag-iisip.
• Hindi ang pangunahing halaga ng kasangkapan na ito ang "isang karagdagang Skill," kundi ang paggamit ng isang Skill upang pamahalaan ang lahat ng Skill—ito ay galing sa antas ng imprastruktura.
• Ang kaguluhan sa ekosistema ng Skill ay hindi isang okasyonal na pangyayari, kundi isang structural na problema. Ang isang plugin system na walang mekanismo ng audit ay magtatapos sa pagtaas ng entropy.
• Ang pagiging open-source ay nangangahulugan na ang komunidad ay maaaring mag-iterate dito, na maaaring maging simula ng pagpapastandard ng pamamahala ng Skill.

Una sa kasalukuyang kalagayan: Ang iyong Skill repository, maaaring naging dumi na.

Masama marinig iyon. Pero buksan mo ang iyong sariling AI assistant configuration, bilangin kung ilang Skill ang nakapag-install, at isipin kung alin ang huling ginamit mo.

Ang sagot ay malamang na magpapahinga sa kahinaan.

Simula sa ikalawang kalahati ng 2025, ang mga AI coding tool tulad ng Cursor, Windsurf, Codex, at Claude Code ay pumasok sa pagsisikap na magkaroon ng "Skill arms race". Ang mga contributor ng komunidad ay naglalabas ng malaking halaga, patuloy na lumalaki ang mga built-in library ng opisyal, at patuloy na dumadagdag ang mga personal na konfigurasyon.

Ano ang resulta?

Isang karaniwang malalim na gumagamit, ang bilang ng Skill ay madaling lalampas sa 50. Maaaring mas mababa sa 10 ang maaaring ma-trigger araw-araw. Ang natitirang 40, tahimik na nakatira doon, binabawasan ang token budget bawat pag-start ng usapan, at pagkatapos—hindi nagagawa ang anumang bagay.

Hindi ito pagkawala. Ito ay krimen.

Bakit sinasabi nito? Dahil ang context window ay hindi walang hanggan. Kahit sa taong 2026, ang epektibong haba ng context ng mga pangunahing model ay nasa pagitan ng 128K hanggang 200K token, maliit ba ito? Pero isipin mo: ang system prompt, ang kasaysayan ng pag-uusap, ang code snippets, ang nilalaman ng mga file, ang mga tool definition, ang Skill description... ang tunay na espasyo na natitira para sa "pag-iisip" ay mas maliit kaysa sa iyong inaasahan.

Ang bawat karagdagang deskripsyon ng walang kwentang Skill ay nagmumula sa 200 na token; ang 50 ay 10,000 na token. Sapat ang 10,000 na token para sa modelong basahin ang 400 na linya ng code.

Hindi ito teoretikal na pagsusuri. Ito ay nangyayari araw-araw.

Bakit walang nag-aalala? Dahil mas madali ang "dagdag" kaysa sa "bawas" ng libo-libo beses.

Mayroong isang malalim na psikolohikal na pagkiling sa mga tao: ang pagkiling sa pagdaragdag (Addition Bias).

Kapag nakakakita tayo ng isang problema, natural nating gustong "dagdagan" ang mga bagay upang lutasin ito, hindi "bawasan". Ipinakita ng isang pag-aaral noong 2021 sa Nature na ang mga tao ay sistematikong nag-iisip na walang halaga ang mga solusyong "pagsasaliw", kahit na mas epektibo ito.

Ang Skill ecosystem ay perpektong inirereplica ang pagkakaiba-iba na ito.

Isinulat ng community contributor ang bagong Skill at ipinakalabas. Naniniwala ang user na "baka magamit ito" at i-install. Naniniwala ang opisyal na "malawak ang sakop ng function" at isinama sa loob.

Sino ang magde-delete? Sino ang mag-audit? Sino ang sasabing "重复 ng Skill na ito sa iyon, tanggalin ang isa"?

Walang sinuman.

Kasi wala naman na incentive sa pag-delete. Gumawa ng isang bagong Skill, kung saan makakakuha ka ng star, makakatanggap ng pagkilala mula sa komunidad, at makakasulat sa iyong resume. Mag-clear ng isang lumang Skill? Wala kang makukuha.

Ito ay isang structural dilemma. Hindi ito isang teknikal na problema, kundi isang problemang nagmumula sa incentive mechanism.

Hanggang sa isang tao ang desisyun: Hindi ko na kailangan ang insentibo, ako na ang gagawin ito.

Ang ama ng lobster ay lumabas: Gamit ang isang Skill, pinag-aaralan ang lahat ng Skill

Sino ang ama ng lobster? Kung ikaw ay bahagi ng komunidad ng AI programming tools, hindi ka makakalimot sa ID na ito. Matagal nang aktibo sa mga ecosystem ng Codex at Claude, isang deep player na kilala sa sistematisong pag-iisip at engineering-level na pagiging perpekto. Ang pangalang "ama ng lobster" ay may sariling pagkilala mula sa komunidad—ang pagkakaloob ng "ama" ay nangangahulugan na sa isang partikular na larangan, siya ang taong hindi mo maiiwasan.

Ang binuksan niya sa open source ay isang meta-skill sa kanyang kalikasan.

Ano ang meta-skill? Ito ay "ang kasanayan sa pagpapamahala ng mga kasanayan." Hindi ito nagpapalit ng code, hindi ito nagpapagana ng API, at hindi ito nagpapagawa ng dokumentasyon. Isa lang ang ginagawa nito: magbigay ng komprehensibong, kuantitatibo, at praktikal na pagsusuri sa lahat ng iyong kasalukuyang skill.

Limang pangunahing tampok, bawat isa ay hihiwalayin.

Ito ang pinakamahigpit.

Direktang ginagawa nito: kalkulahin ang bawat Skill na nakakatira sa context token space, tukuyin ang porsyento nito sa kabuuang budget, at bigyan ng mga rekomendasyon para sa pagpapabuti.

Bakit ito mahalaga? Dahil walang kamalayang malaki ang karamihan sa mga user kung gaano karaming yaman ang kinain ng "Skill".

Isinip mo na ang pag-install ng isang Skill ay nagdadala lang ng karagdagang tampok. Sa katotohanan, ang bawat deskripsyon ng Skill, mga depinisyon ng parameter, halimbawang code, at mga patakaran sa pag-trigger ay kailangang isama sa system prompt. Bawat beses na mag-r推理 ang modelo, kailangan muna itong "basahin" ang lahat ng mga ito bago makapag-decide kung susundin ito.

Parang may dala kang backpack na puno ng 50 mga kasangkapan. Paniniwala mo na "mas mabuti na may dala ka kaysa walang dala," ngunit bawat karagdagang kilo, mas marami ang iyong pagkabawas ng enerhiya. Kapag nangangailangan ka na ng pagpapabilis, wala ka nang lakas.

Ang ginagawa ng budget audit ay ang pagbukas ng bag at pagsasabi sa iyo: "Ang Swiss army knife na ito ay may timbang na 3 kg ngunit hindi mo ito ginamit, ilabas mo na."

Ang problema na nalulutas ng tampok na ito ay maaaring mas serio kaysa sa iyong inaasahan.

Ang sakop nito ay kumakapit sa apat na antas:

• Built-in library ng Codex
• Plugin cache
• Code repository
• Root directory ng personal na kasanayan

I-scan ang mga kasanayan na may parehong pangalan, magkakatulad na deskripsyon, at overlapping na pag-andar, at i-mark ang mga redundant na item.

Bakit may duplication? Maraming dahilan.

May built-in na "code formatting" Skill ang opisyal, ngunit hindi mo alam at nag-install ka pa ng isa mula sa komunidad na may magkaparehong pag-andar. Dalawang Skill, iisang gawain, nagmumula sa dalawang budget.

O higit pa sa iyon: isinulat mo ang isang custom Skill na nag-aayos ng JSON nung anim na buwan ang nakalipas, at pagkatapos ay isinama ng opisyal na update ang isang mas mabuting library. Patuloy pa rin ang iyong lumang bersyon, at wala kang sinabing dapat mong tanggalin.

Hindi lang pinagmamasdan ang pangalan sa pagdidiscover ng pagkakapareho. Maaaring magkaiba ang pangalan, ngunit kung ang paglalarawan ay mataas na katulad, babalanggitan din ito. Ito ang totoong bahagi na may teknikal na kakayahan—nagpapagana ito ng paghahambing sa antas ng kahulugan, hindi lang sa pagkakatugma ng mga string.

Batay sa nakaraang log, kilalanin ang mga "zombie skill" na hindi na ginamit nang matagal.

Malinaw ang lohika na ito: Kung isang Skill ay hindi nag-trigger sa nakaraang 30 araw, 60 araw, at 90 araw, malamang may dalawang sitwasyon—o hindi ito kailangan ng iyong workflow, o may problema sa pagdidisenyo ng mga kondisyon ng pag-trigger na nagiging sanhi ng pagkakamali ng model sa pagpili nito.

Anuman ang uri, ang konklusyon ay pareho: Ito ay nagpapalabas ng budget nang walang kabuluhan.

Ang function na ito ay naglalabas ng isang "listahan ng mga kandidato para sa paglinis." Tandaan, ito ay "kandidato," hindi direktang i-delete. Ang huling desisyon ay nasa kamay ng user. Ang disenyo ay maliwanag at matalino—alam nito kung saan ang mga hangganan nito.

May ilang kasanayan na talagang mababa ang kalimitan ng paggamit ngunit mahalaga. Halimbawa, ang "pagtutulungan sa paglipat ng database," maaari mong gamitin ito ngayon na lang sa loob ng tatlong buwan, ngunit kapag ginagamit mo, ito ang nagliligtas. Kaya ang mga resulta ng pagsuri ay gabay lamang, hindi desisyon.

Ang tampok na ito ay may katangian na "operasyon at pangangalaga," ngunit napakagamit.

Ang mga ginagawa nito: I-stat ang lahat ng mga pinagmulan ng direktoryo ng Skill, i-label ang estado ng pagpapagana/pagpapahinto, at i-organisa ang chain ng pag-load.

Bakit kailangan nito? Dahil mula sa iba’t ibang pinagmulan ang Skill. Mayroon na mula sa global configuration, mayroon na mula sa project-level configuration, mayroon na mula sa automatic injection ng plugin, at mayroon na mula sa manual na paglikha ng user.

Kapag kaunti ang bilang ng Skill, alam mo kung ano ang nangyayari. Kapag tumagal na sa mga dosenang Skill, hindi na mo malalaman kung "Saan galing ang Skill na ito", "Pwede ko ba itong tanggalin nang ligtas", o "Makakaapekto ba ito sa iba pang mga bagay".

Ang root directory audit ay parang paggawa ng isang mapa para sa iyo. Ipinapakita nito kung saan nakatira ang bawat Skill, sino ang nag-load nito, at kung ito ay buhay o patay ngayon.

With this map, you can safely perform the surgery.

Ang huling tampok, kahit na tila pinakamaliit, sa katotohanan ay may malaking lebad.

Ang ginagawa nito: Hanapin ang mga Skill na may sobrang habang paglalarawan, at i-recommend ang mga solusyon para i-abbreviate.

Bakit mahalaga ang haba ng deskripsyon? Balik sa nabanggit na: Ang Skill description ay isusulat sa system prompt. Bawat titik ay isang token. Kung ang deskripsyon ng isang Skill ay maaaring i-compress mula sa 200 token hanggang 80 token, ang napupuntong puwang ay marami sa pagkakataon ng bilang ng Skills.

Maraming skill na nagmula sa komunidad, ang mga deskripsyon ay parang abstrak ng papel—pangkalahatang-kaalaman, motibasyon, mga kahilingan sa paggamit, mga babala, at mga halimbawa ng input at output, malawak ang paglalahad. Ang mga sumulat ay may mabuting intensyon, ngunit sa pananaw ng inhenyeriya, ito ay overdesign.

Ang kinakailangang deskripsyon ng modelo ay: tumpak, natatangi, makakilala. Sapat na ang pinakamaliit na bilang ng salita upang maunawaan ng modelo kung ano ang gagawin ng Skill at kailan ito dapat gamitin. Ang bawat dagdag na salita ay pagkawala sa budget ng konteksto.

Pinapadali ang tampok na ito, na sa本质上 ay isang "reverse optimization ng prompt engineering"—hindi nagpapabuti ng mga prompt, kundi pinapaliit ang mga umiiral na prompt nang higit pa, habang nananatili ang impormasyon.

Saan ang halaga? Hindi ang mga tampok, kundi ang paraan ng pag-iisip

Napagtapos na ang limang tampok. Sa pag-iisip ng bawat isa, tila hindi ito “nakakabagabag.” Ngunit kapag pinagsama, ito ay nagpapakita ng isang pagbabago sa paraan ng pag-iisip:

Mula sa "paglikha ng higit pang Skill" hanggang sa "pangangasiwa ng mga umiiral na Skill".

Ang halaga ng bagay na ito ay hindi nasa dami ng code, hindi nasa kumplikadong algoritmo, kundi sa—sakto na may tao na pinagtrabahuhan ang problema na ito bilang "isang pangunahing mamamayan".

Sa nakalipas na dalawang taon, ang lahat ng atensyon sa ekosistema ng AI tools ay nakatuon sa "pagdaragdag". Mas maraming modelo, mas maraming tampok, mas maraming plugin, mas maraming Skill. Mabilis at malakas ang paggalaw, walang nagtatapos na tingin pabalik.

Ngunit alam ng anumang may karanasan sa inhenyeriya: kapag tumataas ang kumplikadong kalikasan ng isang sistema hanggang sa isang tiyak na puntos, at walang katumbas na mekanismo ng pamamahala, ito ay maaaring magkakaroon ng pagkabagsak.

Hindi posibilidad. Tiyak.

May konsepto sa software engineering na tinatawag na "technical debt." Bawat pansamantalang solusyon, bawat "sige na muna ito," at bawat hindi nalilinis na sobra, ay isang pautang. Mas marami ang pinagkakautang, mas mataas ang interes, hanggang sa isang araw ay natutuklasan mo na ang lahat ng iyong enerhiya ay ginagamit para sa pagbabayad ng utang, at wala nang lakas para sa mga bagong gawain.

Ang teknikal na utang ng Skill ecosystem ay nasa punto na kailangang harapin.

Ang tool na "Ama ng Talangka" ay isang auditor ng utang. Hindi ito nagtataguyod ng pagbabayad ng iyong utang, ngunit sinasabi nito sa iyo: gaano ka karaming utang, saan ito nakalagay, at alin ang dapat unahin.

Mas malaki ang halaga nito kaysa sa "isang mabuting Skill na isinulat muli."

Kahulugan ng open source: Mula sa personal na kasangkapan hanggang sa pamantayan ng komunidad

Ang pagpili ng Father of Lobster na gawing open source ay isang desisyon na值得说道.

Maaari niyang gawing paid plugin ang kasangkapan na ito. Malinaw ang pangangailangan ng merkado, tunay ang mga problema, at hindi mababaw ang bilang ng mga gumagamit na magbabayad. Ngunit pinili niya na gawing open source.

Bakit?

Naniniwala akong may dalawang pag-iisip.

Unang antas: Upang talagang magkaroon ng halaga ang kasangkapan na ito, kailangan ng pagkakaisa ng komunidad. Magkakaiba ang mekanismo ng pag-load ng Skill, ang format ng log, at ang istruktura ng direktoryo sa iba’t ibang AI platform. Hindi kayang i-adapter ng isang tao, ngunit maaari ng isang daan na contributor.

Pangalawang antas: Maaaring nais niyang itaguyod ang higit pa sa isang kasangkapan, kundi isang pamantayan. Paano dapat gawin ang pamamahala ng Skill? Ano ang mga dimensyon ng audit? Ano ang mga pinakamahusay na praktika sa pagkakaloob ng budget? Ang mga tanong na ito, kailangan ng komunidad na pagkakasunduan upang mabuo ang mga sagot.

Ang open source ay ang pinakamahusay na paraan upang makamit ang pagkakasundo.

Sa pagtingin sa kasaysayan ng software engineering, ang ESLint para sa mga patakaran sa JavaScript, ang Black para sa pag-format ng Python, at ang Prettier para sa istilo ng frontend code—ang mga kasangkapan na ito ay naging de facto standard dahil sa open source na nagbigay-daan sa komunidad na makilahok sa paggawa ng mga patakaran.

Maaari ba ang meta-skill na ito ng Ama ng Alimango na maging ang ESLint ng Skill governance?

Masyadong maaga para magkaroon ng pagtataya. Ngunit ang direksyon ay tama.

Isang mas malalim na tanong: Dapat ba ring muli ay disenyo ang Skill system?

Lumalutas ang audit tool sa "存量问题". Ngunit kung ilalapit natin ang ating pananaw nang isang antas, makikita natin ang isang mas pangunahing problema:

Bakit nawawala ang kontrol sa Skill?

Ang sagot ay: Kulang ang kasalukuyang sistemang Skill sa pamamahala ng buhay.

Pagkatapos makalikha ng isang Skill, ito ay magpapaliban na. Walang mekanismo ng pagkakalipas, walang pagtanggal ng bersyon, walang pagbaba ng aktibidad. Ito ay parang isang proseso na hindi maaaring mamatay, nagpapaligoy ng mga yaman hanggang sa may tao na manu-manong i-kill ito.

Ihambing ang process management ng operating system: may paglikha, may pag-schedule, may pag-iiwan, at may pagtatapos. Buong sariling buhay na loop.

Magkumpara naman ng pagpapamahala ng mga dependency ng package manager:npm auditay tinitingnan ang mga security vulnerability, npm outdateday tinitingnan ang mga outdated dependency, npm pruneay linisin ang mga walang kinalaman na package. Ang governance tools ay bahagi ng ecosystem.

Saan ang Skill system? Gumawa→Paggamit→……wala na. Nawawala ang maraming mga hakbang sa gitna.

Ang mga kasangkapan ng Ama ng Alimango ay naglalayong kumompensa sa kakulangan sa disenyo ng sistema. Mahalaga ito, ngunit ipinapakita nito ang katotohanan: ang mga platform ng AI tool ay nasa maaaring tawagin na primitibong yugto sa paggawa ng imprastruktura para sa paggawa ng Skill.

Hindi ito kritika. Ito ay natural na bahagi ng pag-unlad. Noong 2024 hanggang 2025, ang pangunahing layunin ng platform ay "gawing gumana ang ekosistema", at ang pamamahala ay maaaring ipagpaliban. Ngunit noong gitna ng 2026, ang ekosistema ay nagsimula nang gumana. Nandito na ang panahon para mag补课.

Isulat sa huli

Bumalik sa unang tanong: Ilan sa mga Skill sa iyong AI assistant ang aktibo?

Kung hindi mo masagot, ibig sabihin ay kailangan mong magkaroon ng isang medical check-up.

Ang ama ng lobster ay nagbigay ng kasangkapan. Libre. Buksan ang source. Limang dimensyon, buong sakop.

Gagamitin o hindi, iyon ang desisyon mo.

Ngunit isang bagay ang sigurado ko: ang mga taong seryosong tumutugon sa kanilang budget para sa konteksto ay makakaranas ng mas magandang AI-assisted experience kaysa sa mga taong walang pakiinggit at nagdadagdag ng Skill nang walang hanggan.

Dahil hindi ang AI lahat-lahat. Limitado ang kanyang atensyon, limitado ang kanyang memorya, at limitado ang kanyang mga yunit para sa pag-iisip. Mas mabuti ang output na ibinabalewala nito kung mas tumpak at mas malinis ang impormasyon na ibinigay mo sa kanya.

Hindi ito mystisismo. Ito ay teorya ng impormasyon.

Sinabi na ni Shannon noong 1948: may limit ang kapasidad ng channel, at mas maraming ingay, mas mababa ang rate ng epektibong pagpapadala ng impormasyon.

Ang mga zombie skill sa iyong listahan ay ingay lang.

Wala nang mga tag sa input, kaya ang direct translation ay: Burahin sila.

Reference

1. Adams, G. S., Converse, B. A., Hales, A. H., & Klotz, L. E. (2021). Ang mga tao ay sistematikong naglalabas ng mga pagbabago na pagsasalin.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). Dokumentasyon ng context window at token limits ng GPT-4 Turbo. https://platform.openai.com/docs/models
4. Anthropic. (2025). Claude model card: Context window utilization and system prompt overhead. https://docs.anthropic.com/en/docs/about-claude/models
5. Cursor Team. (2025). Mga Patakaran at Kasanayan: Paano hinahawakan ang mga custom instruction sa konteksto. Cursor Documentation.
6. npm Documentation. (2025). npm-audit, npm-prune: Pagpapamahala sa buhay ng package. https://docs.npmjs.com/cli
7. Ama ng Lobster. (2026). Skill Health Check Meta-Skill [Open Source Project]. GitHub Repository.
8. Sculley, D., et al. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems (NeurIPS), 28.