Kodlash agenti uchun lean-mode yordamida me’yorli muhandislik va samarali tekshirish ish jarayonini yaratish

lean-mode nima?

lean-mode — kodlash agentlari uchun mo‘ljallangan SKILL.md fayli. Uning maqsadi “kod qancha kam bo‘lsa, shuncha yaxshi” emas, balki agentga aniq mezonlar berib, ikki muhandislik savoliga javob topishga yordam berishdir:

1. Tekshiruv, try/catch, abstraksiya qatlami, zaxira mantiq yoki qo‘shimcha xavfsizlik quyi tizimi kabi tashqi ko‘rinishda xavfsiz kodni yozish kerakmi?
2. Joriy build va testlar nega sekin ishlayapti va samarasiz tekshiruv siklini qanday qilib maqbul darajagacha qisqartirish mumkin?

Ko‘nikma fayli skills/lean-mode/SKILL.md manzilida joylashgan bo‘lib, standart frontmatter, ya’ni name, description va Markdown matnidan foydalanadi. U muayyan hostga bog‘liq emas: SKILL.md kelishuvini qo‘llab-quvvatlaydigan har qanday agent undan foydalanishi mumkin.

U hal qiladigan asosiy muammolar

Uzoq davom etadigan kodlash sessiyalarida model odatda ikki tizimli moyillikni namoyon qiladi: haddan tashqari himoyaviy dasturlash va sam09arasiz tekshiruv sikli.

Haddan tashqari himoyaviy dasturlash

Odatdagi ko‘rinishlar: ichki ishonchli ma’lumotlarda null tekshiruvlarini takrorlash, sababni yashirish uchun istisnolarni ushlash, bitta implementatsiya uchun oldindan abstraksiya yaratish hamda muammo manbasi tasdiqlanmagan bo‘lsa ham zaxira mantiqni qo‘shishda davom etish. Kod tashqi tomondan “xavfsizroq” ko‘rinadi, ammo amalda xizmat ko‘rsatish xarajatlarini oshirishi va aniq xatoni kuzatish qiyin bo‘lgan xato qiymatiga aylantirishi mumkin.

Sam09arasiz tekshiruv sikli

Odatdagi ko‘rinishlar: to‘liq buildni tez-tez ishga tushirish, clean buyrug‘idan qayta-qayta foydalanish, doimiy jarayonlarni o‘chirish, har safar barcha testlarni ishga tushirish va aniq qotib qolgan buyruqlarning uzoq vaqt kutilishi. lean-mode bu xatti-harakatlarni jarayonlarni qayta ishlatish, inkremental bajarish, ko‘lamni boshqarish, bajarish tartibi, chaqirish chastotasi va timeoutni boshqarishga oid olti turdagi qoida bilan cheklaydi.

README dagi miqdoriy ma’lumotlar taxminan 20k qatorli Java va Gradle loyihasidagi bitta uzoq sessiyadan olingan. Ular muammo haqiqatan mavjudligini ko‘rsatish uchungina keltirilgan va turli modellar yoki loyihalar uchun sanoat mezoni deb qaralmasligi kerak.

Asosiy imkoniyatlar

• Ishonch chegarasida faqat bir marta tekshirish: avval “bu null qayerdan keladi?” degan savolga javob berishni talab qiladi va ishonchli ma’lumotlar tizimga kirgandan keyin ularni qatlamma-qatlam takroran tekshirishning oldini oladi.
• Asosiy sababni yashirmaslik: catch dan keyin null, false, bo‘sh to‘plam yoki nol qiymat qaytarishdan ogohlantiradi, chunki bular aniq xatoni topish qiyinroq bo‘lgan xatoga aylantirishi mumkin.
• Oldindan abstraksiyalashni cheklash: faqat bitta implementatsiyaga ega yoki kelajakda almashtirilishi mumkinligi uchungina yaratilgan abstraksiya har doim ham haqiqiy barqaror kengaytirish chegarasini hosil qilmaydi.
• Avval asosiy sababni tuzatish: zaxira mantiqni qo‘shish asosiy sabab hali to‘liq bartaraf etilmaganini anglatadi. Zaxira mantiq chindan kerak bo‘lsa, muammo kimga tegishli ekani, uni olib tashlash sharti va tekshirilgan asos ko‘rsatilishi kerak.
• O‘zgarish hajmini xatti-harakatdagi o‘zgarishga moslash: yangi kod 50 qatordan oshsa, avval umumiy qatorlar soni, tekshiruv va zaxira mantiqqa tegishli qatorlar soni hamda bu kodni yozmaslikning amaliy narxini bildirish.
• Xavfsiz kod yozishdan oldin uch savolga javob berish: muammo haqiqatan yuz beradimi, yuz bersa foydalanuvchiga qanday ta’sir qiladi, yozmaslikning narxi nima. Istalgan savolga javob bo‘lmasa, avval kod qo‘shmaslik.
• Tekshiruv siklini qisqartirish: Gradle, Maven, Go, Node va TypeScript, Rust, Python hamda .NET kabi yetti turdagi build tizimi uchun minimal tekshiruv yondashuvlarini qamrab oladi.
• “O‘zgartirish shart emas” degan xulosaga ruxsat berish: maqsad muammoni hal qilish, majburan kod chiqarish emas; foydalanuvchi so‘ramagan joylarni qo‘shimcha mustahkamlash ham kerak emas.
• Mavjud kodni audit qilish jarayonini taqdim etish: avval zichlikni miqdoriy baholash, keyin eng muammoli fayllarni tekshirish, har bir holatni o‘chirish, yuqoriga ko‘chirish yoki qoldirish deb baholash va o‘zgartirishdan oldin natijalar jadvalini foydalanuvchiga taqdim etish.

Himoyaviy kod uchun ko‘nikma Java, Go, TypeScript va Python tillaridagi to‘rtta qarshi misolni taqdim etadi. Bu agentga turli sintaksislar ortidagi bir xil muammolarni aniqlashga yordam beradi.

lean-mode ni o‘rnatish

1-usul: URL orqali yuklab olish

Agar host URL orqali ko‘nikma import qilishni qo‘llab-quvvatlasa, masalan Vantaloom ko‘nikmalar sahifasi, ombor manzilini bevosita joylashtirish mumkin. Host ko‘nikma faylini skills/lean-mode/ ichidan topadi.

https://github.com/Timefiles404/lean-mode-skill

2-usul: Ishchi sohaga nusxalash

Avval omborni klonlang, so‘ng ko‘nikma katalogini host belgilagan joyga nusxalang. Vantaloom ish sohasi kelishuvlaridan foydalanilganda quyidagini bajaring:

git clone https://github.com/Timefiles404/lean-mode-skill.git
cp -r lean-mode-skill/skills/lean-mode <ishchi_sohangiz>/.vantaloom/skills/

Agar host Claude uslubidagi ko‘nikmalar katalogidan foydalansa, uni .claude/skills/ ichiga nusxalang:

cp -r lean-mode-skill/skills/lean-mode <ishchi_sohangiz>/.claude/skills/

3-usul: Ko‘nikmani qo‘lda yaratish

Host ichida yangi ko‘nikma yarating va ombordagi skills/lean-mode/SKILL.md faylining to‘liq mazmunini joylashtiring. Yuqoridagi frontmatterni qoldirib ketmang, chunki host ko‘nikmani qachon yuklashni undagi description asosida aniqlaydi.

Asosiy foydalanish jarayoni

O‘rnatilgandan keyin lean-mode asosan ko‘nikma tavsifining kerak bo‘lganda kontekstga kirishiga tayanadi. Agent tekshiruv, istisnolarni ushlash, abstraksiya qatlami, zaxira mantiq yoki qo‘shimcha xavfsizlik quyi tizimini qo‘shishga tayyorlanganda yoki bir davrada build va testlarni bir necha marta ishga tushirganda, u ishga tushirilishi kerak.

1-scenario: Yangi tekshiruv kerakligini aniqlash

1. Avval ma’lumot manbasini aniqlang va u tashqi kiritma, interfeys chegarasi yoki boshqa ishonchsiz manbadan kelgan-kelmaganini tasdiqlang.
2. Xuddi shu cheklov ishonch chegarasida allaqachon tekshirilganini tekshiring.
3. Muammo haqiqatan yuz berishi mumkinmi, foydalanuvchiga qanday ta’sir qiladi va tekshiruvni yozmaslikning narxi nima degan savollarga javob bering.
4. Ma’lumot ichki tizimga kirgach ishonchli bo‘lsa, bir xil runtime tekshiruvlarini qatlamma-qatlam takroran qo‘shmang.

Masalan, agent bir nechta ichki metodga takroran Objects.requireNonNull qo‘shmoqchi bo‘lsa, parametr “nazariy jihatdan null bo‘lishi mumkin” degan sababning o‘zi yetarli emas. Avval nullning haqiqiy manbasini kuzatish va chegarada tekshiruv allaqachon bajarilgan-bajarilmaganini aniqlash kerak.

2-scenario: Istisnolarni qayta ishlash

Agent istisnoni ushlab, standart qiymat qaytarishga tayyorlanganda, avval bunday qayta ishlash asosiy sababni yashirib qo‘ymasligini aniqlashi kerak. Quyidagi namuna alohida tekshirilishi lozim:

catch (...) {
    return false;
}

Maqsad barcha istisnolarni ushlashni taqiqlash emas, balki kuzatish mumkin bo‘lgan xatoni konteksti yetishmaydigan false, null, bo‘sh natija yoki nol qiymatga aylantirmaslikdir. Biznes talabi haqiqatan pasaytirilgan rejimni talab qilsa, ko‘nikmadagi istisno shartlari asosida baholash davom ettirilishi kerak.

3-scenario: Abstraksiya qatlamini baholash

Agar interfeys hozircha faqat bitta implementatsiyaga ega bo‘lsa va uni yaratishning yagona sababi “kelajakda almashtirilishi mumkin” degan taxmin bo‘lsa, agent to‘xtab, haqiqiy o‘zgarish chegarasini tekshirishi kerak. lean-mode abstraksiyani inkor etmaydi, balki joriy ehtiyoj va barqaror chegara bo‘lmagan paytda bilvosita qatlamni oldindan yaratishga qarshi.

4-scenario: Build va testlarni qisqartirish

1. Mavjud build jarayonlarini qayta ishlatishni ustuvor qiling va keraksiz sovuq ishga tushirishlardan saqlaning.
2. Inkremental natijalarni saqlang, clean buyrug‘ini odat bo‘yicha ishlatmang.
3. Avval faqat kompilyatsiya qiladigan, faqat tegishli modulni tekshiradigan yoki faqat bitta testni ishga tushiradigan minimal buyruqni bajaring.
4. Minimal tekshiruvdan o‘tgach, modul testlari yoki to‘liq testlargacha ko‘lamni bosqichma-bosqich kengaytiring.
5. Takroriy chaqirish chastotasini boshqaring va kod o‘zgarmaganida bir xil buyruqni qayta-qayta bajarmang.
6. Qotib qolishi mumkin bo‘lgan buyruqlar uchun oqilona timeout belgilang va xatodan keyin avval birinchi asosiy sababni tahlil qiling.

README dagi to‘liq ko‘nikma matni yetti turdagi build tizimi uchun “faqat shu bittasini ishga tushirish” minimal tekshiruv siklini beradi. Amalda bu misollarni loyihada bevosita bajarish mumkin bo‘lgan haqiqiy buyruqlar bilan almashtirish kerak.

Haddan tashqari himoyaviy kodni audit qilish

lean-mode allaqachon ko‘plab tekshiruv, zaxira yoki istisnoni yutib yuboruvchi mantiq to‘plangan loyihalar uchun “avval o‘lcha, keyin o‘chir” audit jarayonini taqdim etadi.

1. Qidirish va miqdoriy baholash: tilga mos ravishda ilovadagi qidiruv andozalaridan foydalanib, tegishli andozalar soni va zichligini hisoblang.
2. Tekshiruv ko‘lamini toraytirish: muammo eng ko‘p to‘plangan 5 ta faylni ko‘ring va omborni boshidan oxirigacha audit qilishdan saqlaning.
3. Har bir holatni tasniflash: har bir mantiqni “o‘chir”, “yuqoriga ko‘chir” yoki “qoldir” deb belgilang. “Yuqoriga ko‘chirish” odatda tekshiruvni haqiqiy ishonch chegarasida jamlashni anglatadi.
4. Avval hisobot, keyin o‘zgartirish: avval audit jadvalini foydalanuvchiga tanlash uchun taqdim eting; tasdiqsiz katta hajmda o‘chirishni boshlamang.
5. Bo‘lib tekshirish: o‘zgartirishdan keyin eng kichik build va test ko‘lamidan foydalanib tekshiring, so‘ng natijaga qarab ko‘lamni kengaytiring.

Bu jarayon “himoyaviy kodni kamaytirish”ni yana bir nazoratsiz katta refaktoringa aylantirmasdan, kuzatuvchanlik, tanlash imkoniyati va qaytarish imkonini ta’kidlaydi.

SKILL.md ni moslashtirish

SKILL.md ning o‘zi Markdown bo‘lib, uni bevosita tahrirlash mumkin. Quyidagi uch turdagi moslashtirish eng foydalidir.

Loyiha tekshiruv buyruqlarini almashtirish

Yettinchi bo‘limdagi umumiy buyruqlarni joriy loyihada haqiqatan bajariladigan “faqat kompilyatsiya” va “faqat bitta testni ishga tushirish” buyruqlari bilan almashtiring. Bevosita nusxalab bajarish mumkin bo‘lgan bitta buyruq odatda abstrakt tamoyildan ko‘ra agent xatti-harakatini yaxshiroq cheklaydi.

Qidiruv andozalarini moslashtirish

Loyiha kod uslubiga qarab ilovadagi qidiruv qoidalarini o‘zgartiring. Masalan, Java loyihasi Guava Preconditions dan foydalanishi yoki asosan Objects.requireNonNull ga tayanishi mumkin. Qidiruv andozalari haqiqiy kodga mos bo‘lishi kerak.

Ma’lumotnoma zichligini sozlash

Ko‘nikma har 200 dan 500 qatorgacha bitta tekshiruvni tajribaviy ma’lumotnoma sifatida ko‘rsatadi, ammo bu yagona standart emas. Parser, protokol chegarasi va biznes CRUD uchun oqilona tekshiruv zichligi turlicha bo‘ladi; uni soha xatari va ma’lumot manbasiga qarab sozlash kerak.

Yuqori darajadagi foydalanish tavsiyalari

• Istisnolarni ham kontekstda saqlang: ko‘nikmadagi mezonlar evristik qoidalar, teoremalar emas. “Tekshirmang” yoki “catch ishlatmang” kabi soddalashtirilgan shiorlargina qoldirilmasin.
• Agentdan o‘zgarish tarkibini hisobot qilishni so‘rang: yangi kod 50 qatordan oshganda, umumiy qatorlar soni, tekshiruv va zaxira mantiq qatorlari hamda bu mantiqni amalga oshirmaslik narxini aniq ko‘rsatishini talab qiling.
• Tekshiruv ko‘lamini bosqichma-bosqich kengaytiring: tegishli fayl, bitta test yoki moduldan boshlang, keyin kattaroq test ko‘lamiga o‘ting; har bir o‘zgarishda to‘liq build ishga tushishining oldini oling.
• Zaxira mantiqni dalil bilan asoslang: uni saqlash zarur bo‘lsa, muammo manbasi, tekshiruv natijasi va kelajakda olib tashlash shartini qayd eting. Tekshirib bo‘lmaydigan “ba’zi muhitlarda xato yuz berishi mumkin” kabi iboralardan foydalanmang.
• “O‘zgartirmaslik”ni haqiqiy natija deb biling: muammo mavjud mantiq bilan allaqachon hal qilingan bo‘lsa yoki yangi kodning foydasi aniq bo‘lmasa, agent o‘zgartirish kerak emasligini to‘g‘ridan-to‘g‘ri ayta olishi kerak.

Imkoniyatlar chegarasi va ixtiyoriy qo‘shimchalar

lean-mode modelning qobiliyatini emas, moyilligini o‘zgartiradi. U modelni muayyan turdagi kodni yozishni to‘xtatishga majburlay olmaydi; faqat mos vaqtda mezonlarni kontekstga kiritadi. Shu sababli u foydali, ammo kafolat bermaydi.

U statik analizator ham emas: kodni avtomatik o‘qimaydi yoki skanerlamaydi. Ilovadagi audit agentdan tegishli qidiruv buyruqlarini o‘zi ishga tushirishini va natijalarga qarab xulosa chiqarishini talab qiladi.

Ixtiyoriy Vantaloom plaginining xuddi shu nomdagi varianti qisqartirilgan qoidalarni har bir davrada dinamik kontekstga doimiy ravishda joylaydi hamda vosita natijalari uchun izohlar va lean_review vositasini taqdim etadi. Plagin doimiy eslatib turadi, ko‘nikma esa to‘liq mezonlarni beradi. Plagin o‘rnatilmagan taqdirda ham ushbu ko‘nikmadan mustaqil foydalanish mumkin.

Loyiha omborini GitHub dagi lean-mode-skill sahifasida ko‘rish mumkin; loyiha MIT litsenziyasi asosida tarqatiladi.

Xulosa

lean-mode ning qiymati kodni mexanik ravishda kamaytirishda emas, balki har bir tekshiruv, istisnolarni qayta ishlash, abstraksiya, zaxira mantiq va tekshiruv buyrug‘i o‘z sababini izohlashi mumkin bo‘lishidadir. O‘rnatilgach, uni loyiha buyruqlari, qidiruv andozalari va xatar zichligiga moslab sozlash kodlash agentiga asosiy sababga ko‘proq e’tibor qaratish hamda qisqaroq va ishonchliroq muhandislik fikr-mulohaza siklini yaratishga yordam beradi.