Печалби:
- Възможност за картографиране на завършване на редактора, асистент за чат, CLI агент и категории за автоматизация на CI към задачи
- Възможност за регулиране на нивото на автономност според риска и прилагане на дисциплината „първо планирайте“ към CLI агентите
- Възможност за трансформиране на използването на AI в екипна система, базирана на валидиран инструмент, порта за проверка, прозрачност и отчетност
Досега сме се научили да използваме AI в отделни задачи (кодиране, преглед, тестване, отстраняване на грешки). В този последен модул ние събираме парчетата заедно: запознаване с различни инструменти за кодиране на AI, съпоставяне на правилния инструмент с правилната работа и безопасното им вграждане в ежедневния ви поток на разработка – от редактор до контрол на версиите, от CI/CD конвейер до управление на екип. Целта е да превърнете разхвърляния навик „питайте AI от време на време“ в последователна и подлежаща на одит работеща система.
Ние покриваме типовете превозни средства с неутрални категории (конкретните имена на продукти се променят бързо; има значение какво прави категорията). Всяка категория има „сладко място“ и рисков профил; Майсторството е да знаеш колко автономия да дадеш на коя задача.
Категории инструменти за кодиране на AI
1. Завършване в редактора. Добавки, които предлагат редове/блокове, докато пишете във вашата IDE (средата за разработка, в която пишете код). Сладко място: скорост в потока, шаблонен код. Риск: тесен контекст, приемане на предложението без замисляне.
2. Асистент за чат/страничен панел. Интерфейс за чат, вграден в IDE с видимост в част от вашата кодова база. Sweet spot: описание, рефактор, тестване, анализ на грешки. Риск: ограничен до контекста, който давате, изисква проверка.
3. CLI агенти (агентни инструменти). Инструментите, които се изпълняват от командния ред, могат да четат и модифицират множество файлове, да изпълняват команди и да изпълняват многоетапни задачи самостоятелно. Сладко място: промени в няколко файла, повтарящи се задачи, задачи от типа „добавете това свойство“. Риск: висока автономност = голямо въздействие; Ако не бъде отметнато, това води до широки и трудни за проверка промени.
4. Интеграция на линия/автоматизация. CI (непрекъсната интеграция) ботове, които оставят автоматични коментари за преглед на PR, предлагат тестове или създават журнали за промени. Sweet spot: първа цедка без умора, консистенция. Риск: шум, фалшива увереност.
Подсказка: С увеличаването на автономията контролът също трябва да се увеличи. Тъй като завършването на редактора е малко и мигновено, то се контролира леко; Многофайловата модификация на CLI агент трябва да се изследва също толкова, ако не и по-внимателно, отколкото човешки PR.
Стъпка по стъпка: Вграждане на AI в работния процес
- Съпоставете задачата с инструмента. Малко добавяне в поток → завършване; разбиране/рефакторинг/тест → чат; многофайлова, повтаряща се работа → CLI агент; непрекъснат първи филтър → CI интеграция.
- Изберете нивото на автономност. Колко свобода има агентът? Предложение само за четене или модификация на файл + изпълнение на команда? Приспособете се към риска.
- Подхранвайте контекста. Постоянно въвеждане на правила за проекта (стил, архитектура, „не трябва“) в инструмента; Използвайте файл с инструкции за проекта, вместо да го обяснявате отново и отново.
- Поддържайте врати за проверка. Промяната на AI е като човешката промяна: преминава през компилация, тестване, преглед и (ако е критично) експертно одобрение. Откриването на AI не заобикаля одобрението.
- Измерете и регулирайте. Гледайте какво наистина ускорява, къде корекционната тежест се увеличава; Отрежете употребите, които не работят.
Три мини калъфа
Случай 1 — CLI агент обработи многофайлово преименуване. Един екип би преименувал концепция, разпределена в 60 файла. Те дадоха задачата на CLI агент, първо поискаха план, одобриха плана, след това направиха промяната и пуснаха целия тестов пакет. Агент 3 е пропуснал крайния случай във файла; Тестовете го хванаха, оправиха го. Работата, която отне приблизително 3 часа ръчно, беше завършена за 50 минути с надзор.
Случай 2 — Непроверената автономия даде обратен ефект. Друг разработчик каза на агент да "подобри този модул" и го пусна; Агентът промени 18 файла и добави две зависимости. Промяната беше толкова широка, че не можеше да бъде прегледана и трябваше да бъде оттеглена. Урок: дайте на агентите тесен обхват, ясни критерии за приемане и дисциплина първо планирайте, по-късно направете.
Случай 3 — CI преглед бот стана първият филтър. Един екип изгради бот, който оставя автоматизирани коментари за преглед на AI на PR. След като ботът улови пропуски при нулеви проверки и проблеми със стила, рецензентите успяха да посветят времето си на бизнес логиката. Екипът обаче даде да се разбере, че ботът не предоставя „одобрение“: все още се изисква поне едно човешко одобрение. За да намалят шума, те настройват лодката да оставя само шум с висока/средна интензивност.
Четири копируеми шаблона
Дисциплина „Планирайте първо“ за CLI агент:
Задача: {{ясна, тясна задача}}Критерии за приемане: {{измерим резултат}}Ограничение: работа само върху {{следната директория/файлове}}; добавяне на нова зависимост. Първо представете план БЕЗ ПРОМЯНА: кои файлове, какво ще се промени, кои тестове да стартирате. Изчакайте да ОДОБРИМ плана. След това го приложете стъпка по стъпка, като провеждате тестове на всяка стъпка.
Файл с инструкции за проекта (постоянен контекст на инструментите):
Постоянни правила за AI инструменти в този проект:- Език/версия: {{...}}. Стил: {{...}}.- Архитектурно ограничение: {{напр. посока между слоевете}}.- НИКОГА: вграждане на тайни, използване на производствени данни, {{забранени библиотеки}}.- Всяка промяна трябва да може да се тества; Промяна на публичния API подпис БЕЗ питане. - Когато се съмнявате, спрете и попитайте.
Решение за картографиране на задачи и инструменти:
Дефинирам следната задача: {{задача}}. С какъв клас инструменти трябва да направя това: (a) завършване на редактора, (b) асистент за чат, (c) CLI агент, (d) CI автоматизация? Напишете вашата обосновка, риск и препоръчително ниво на автономност (просто предложение / промяна на файла / изпълнение на команда).
Кодекс на поведение на бота за преглед на CI:
Оставете само констатации с ВИСОКА и СРЕДНА тежест като коментари в PR прегледа. Всяка находка: категория, тежест, предложена корекция. Съберете бележки на ниво предпочитание за стил в отделен, един обобщен коментар. Вие НЕ СЕ СЪГЛАСЯВАТЕ; изисква се одобрение от човек.
Слаба подкана / Силна подкана
Слаб: (към CLI агент) „Направете модула за плащане по-добър.“
Силно: (Към CLI агент) "Само изпълнение под src/плащания/. Задача: Извличане на рекурсивната валидираща логика от функцията refund() в единичен помощник; поведението и подписите не се променят. Първо представете плана и изчакайте моето одобрение; след това изпълнете и стартирайте пакета tests/payments/. Добавете нова зависимост."
Силната версия стеснява обхвата, задава критерии за приемане и ограничения и налага дисциплината „планирай първо“. Неясните изисквания „направи по-добре“ са основната причина за огромни и неконтролируеми промени.
клас превозно средство
В какво е най-добър
автономия
инспекционно тегло
Завършване на редактора
Малко добавяне в поток
ниско
Светлина (незабавно четене)
асистент за чат
Разберете, тествайте, преработете
среден
Среден (проверка на изхода)
CLI агент
Многофайлов, рекурсивен
високо
Тежък (план + пълен преглед)
CI автоматизация
Непрекъснат първи филтър
среден
Среден (правило + човешко одобрение)
Екипно управление: от индивидуално умение до споделена система
Използването на AI добре на индивидуална основа е начало; истинската зрялост е последователна система на ниво екип. Тази система се основава на няколко стълба: списък с одобрени инструменти (кои инструменти могат да се използват с какви данни — от единица 10), врати за проверка (промяната на AI минава през същите врати за изграждане/тест/преглед — от единица 11), прозрачност (заявявайки, че промяната е задвижвана от AI, осигурява проследимост, когато е необходимо) и яснота на отговорността (лицето, което се подписва и отговаря, е ясно). Тази рамка ограничава риска, като същевременно поддържа скорост и гарантира, че новите членове на екипа работят със същата дисциплина.
Внимание: Колкото по-висока е автономността на даден инструмент – особено на CLI агентите, които могат да променят файлове, да изпълняват команди – толкова по-строго се ограничава достъпът му до производствената среда, поверителни данни и трудни за възстановяване операции. Свържете разрушителните команди (постоянно изтриване, внедряване) с одобрението на човека.
Често срещани грешки
- Задача-означава несъвместимост. Опитвате се да направите многофайлова работа с редакторско завършване или малък прикачен файл с тежък агент.
- Освобождаване на агента. Задачите на агента, дадени с тесен обхват и без „първо планиране“, водят до непроверени промени.
- Разхлабване на вратите за проверка за AI. „AI го направи, да продължим бързо“ е най-опасното изключение; Вратите са еднакви за всички.
- Ръчно даване на контекста всеки път. Незаписването на проектни правила в постоянен файл с инструкции води до несъответствие и дублиране.
- Объркайте одобрението на CI бота с човешко одобрение. Ботът е филтър; Отговорното човешко одобрение е задължително.
В обобщение
Инструментите за кодиране на AI попадат в четири основни категории: завършване на редактор, асистент за чат, CLI агенти и CI автоматизация. Майсторството е съпоставяне на задачата с правилния инструмент и правилното ниво на автономност; С увеличаването на автономията се увеличава и контролът. Осигурете на инструментите постоянен контекст на проекта, наложете дисциплина „първо планирайте“ на многофайлови агенти и прекарайте промяната на AI през същите врати за проверка като човешката промяна. Индивидуално умение; Превърнете го в екипна система, изградена върху одобрен списък с инструменти, врати за проверка, прозрачност и яснота на отговорността. AI е множител на скоростта от край до край; Лицето, което подписва и дава сметката, винаги е компетентно лице.
Задача за приложение
Избройте три реални задачи, които ще направите следващата седмица. Използвайте шаблона „решение за съвпадение на задача с превозно средство“ за всеки, за да обосновете кой клас превозно средство и какво ниво на автономност ще изберете. След това изпълнете тясна задача за CLI агент (или чат асистент) с дисциплина „първо планирайте“: одобрете плана, наложете го, изпълнете тестовете и прегледайте промяната като човешки PR. И накрая, изгответе 5-точково „правило за използване на AI“ за вашия екип (одобрени инструменти, правило за данни, порта за проверка, ограничение на автономността, отчетност).
контролен списък
- [ ] Мога да правя разлика между категориите инструменти за кодиране с изкуствен интелект и предпочитанията на всеки от тях.
- [ ] Насочвам задачата към правилния клас превозно средство и подходящото ниво на автономност.
- [ ] Давам постоянен контекст на проекта (файл с инструкции) на инструментите.
- [ ] Прилагам тесен обхват и дисциплина „планирай първо“ към CLI агентите.
- [ ] Прекарвам промените на AI през същите врати за проверка като човешките промени.
- [ ] Аз се застъпвам за валидиран инструмент, правило за данни, рамка за прозрачност и отчетност на ниво екип.
Изпит по модул
1. Какво всъщност прави основният голям езиков модел на асистент за кодиране, когато произвежда код?
- A) Предсказва по модел най-вероятното продължение въз основа на дадения контекст ✔
- B) Гарантира правилния резултат чрез действително компилиране и изпълнение на кода
- C) Сканира кода в целия интернет на живо и копира най-точния.
- Г) Разбира логиката на кода като човешки инженер и разбира намерението
Пояснение: LLM не „разбира“ кода като човек; Той генерира най-вероятното продължение на дадения контекст въз основа на модели, които научава от много голям набор от текст и код. Следователно качеството на изхода директно зависи от качеството на контекста и инструкциите, които давате, и всеки изход трябва да бъде валидиран.
2. Как го наричате, когато AI убедително съчинява несъществуваща функция или библиотека и коя е единствената истинска противоотрова?
- A) Това се нарича грешка при компилиране; Противоотровата е по-силно оборудване
- Б) Това се нарича халюцинация; Противоотровата е да проверите кода и всеки използван API ✔
- В) Това се нарича регресия; Противоотровата е да рестартирате модела
- D) Това се нарича препълване на контекста; Противоотровата е да съкратите подканата
Описание: Това се нарича халюцинация и причинява един от най-скъпите грешки в софтуера. Единственият истински противоотрова е проверката: потвърждаване, че всяка използвана функция, API и пакет действително съществува и че кодът работи. Увереният тон на модела не е доказателство за точност.
3. Кой подход подобрява най-много качеството и последователността на изхода при генериране на код с AI?
- A) Освобождаване на модела, като се каже „напиши ми това“, без да се дава никакъв контекст
- B) Написване на възможно най-дългата и фантастична подкана
- C) Посочете и дайте примери за договор за вход/изход, крайни случаи, версия и стил ✔
- D) Комбиниране на генерирания код директно, без да го четете
Обяснение: Определянето на типовете вход/изход на функцията (договор), крайните случаи, ограничението за език/версия и стил и даването на пример на модела позволява прехода от прогнозиране към прецизност. Безконтекстните заявки „напиши ми това“ създават код, който е различен всеки път и често заобикаля крайните случаи.
4. Когато изследвате чужда кодова база с AI, името на функцията може да е „validateAndSave“, но AI дайджестът може да е неправилен. Какъв е правилният подход?
- A) Пълна увереност в резюмето на AI, тъй като името се обяснява само по себе си
- B) Промяна на функцията директно, без да я четете
- В) Вземане на решение само като погледнете името на функцията
- D) Отнасяйте се към описанието на AI като към хипотеза и проверете критичните твърдения ред по ред в кода ✔
Обяснение: AI може да погледне името в кода и да ви каже „какво изглежда, че прави“, но в действителност логиката може да е различна (или дори обърната). Така че обяснението на AI е хипотеза; Критичните претенции, особено тези, които включват сигурност, правомощия или паричен поток, трябва да бъдат визуално проверени на съответните редове.
5. Каква е най-голямата опасност в това да кажете „ИИ го погледна, ясно е“ в прегледа на кода с помощта на ИИ?
- A) AI може да произведе фалшиви отрицания; Истинските пропуснати грешки създават фалшива увереност ✔
- B) AI прегледът е твърде бавен, така че губи време
- C) Екипът не разбира, защото AI коментира само на английски
- D) PR не се сближава, защото AI винаги прекалено много интерпретира
Обяснение: AI произвежда както фалшиви положителни резултати (отбелязване на проблем, когато не съществува), така и фалшиви отрицателни резултати (пропускане на истинската грешка). Фалшивите негативи са тихи; Най-опасните грешки са тези, които изобщо не са споменати в прегледа. Така че AI е първи филтър, а не одобрение; Решението за сливане е на отговорно лице.
6. Кой е най-коварният капан, който се случва, когато просто дадете на AI кода и отпечатате тестове?
- A) AI винаги пише твърде много тестове и раздува кодовата база
- B) AI тества текущото (може би грешно) поведение на кода като „правилно“ и коригира грешката ✔
- C) AI автоматично изтрива кода при писане на тестове
- Г) AI пише тестове не само за щастливия път, но винаги и за крайния случай
Обяснение: AI има тенденция да разглежда кода и да пише твърдения, които тестват текущото поведение. Ако кодът е грешен от самото начало, AI коригира това грешно поведение като „правилно“. Следователно очакванията на теста трябва да бъдат написани според изискваното правило (спецификация), а не според текущия изход на кода.
7. Какво най-много определя точността на хипотезите при отстраняване на грешки с AI?
- А) Колко учтиво е написана подканата.
- Б) Колко пъти въпросът е зададен отново
- C) Качество на доказателствата, предоставени на модела: пълно съобщение за грешка, проследяване на стека, въвеждане и очаквано поведение ✔
- Г) В каква цветова тема е написан кодът?
Обяснение: AI не вижда грешката по начина, по който вие; Той знае само доказателствата, които му даваш. Предвид пълното съобщение за грешка, проследяване на стека, задействащ вход и очаквано поведение, моделът изброява реалните възможности; Ако няма доказателства, това прави предположение (халюцинация) и ви води по грешен път.
8. Коя е най-критичната стъпка, преди да дадете производствени регистрационни файлове на AI за анализ?
- A) Залепване на дневника такъв, какъвто е, покриващ целия ден
- B) Първо преобразувайте дневника в главни букви
- C) Подреждане на редове в журнала по азбучен ред
- D) Маскиране на лични данни и тайни и предоставяне само на съответния прозорец ✔
Описание: Необработените производствени регистрационни файлове съдържат IP, имейл, идентификатор на сесия, токен и понякога открит секрет. Залепването им в AI инструмент без маскирането им е сериозно нарушение на поверителността. Освен това дневникът трябва да бъде филтриран до тесен времеви прозорец; Но първата необходимост е да почистите чувствителните данни.
9. Какво трябва да се направи, ако AI каже, че две събития са се случили „едновременно“ в анализа на регистрационния файл и декларира едното като първопричина?
- A) Пренебрегване на корелацията като причинно-следствена връзка и проверка на твърдението с показатели и код ✔
- B) Приемане на причината за окончателна, защото AI установява времева връзка
- C) Незабавно рестартиране на първия обвиняем компонент
- D) Пълно изтриване на регистрационните файлове и събирането им отново
Обяснение: Най-честата клопка в анализа на журнала е объркването на корелацията с причинно-следствената връзка. Времевата връзка, установена от AI, е улика, а не доказателство. Истинската причинно-следствена връзка изисква време, механизъм и, ако е възможно, повторяемост; Искът трябва да бъде валидиран с показатели и код.
10. Кое е златното правило, което не подлежи на обсъждане при рефакторинг с AI и какво го гарантира?
- А) Кодът трябва да е по-кратък; Броят на редовете гарантира това
- Б) Няма промяна в поведението; тестове, които улавят текущото поведение, гарантират това ✔
- В) Кодът съдържа повече коментари; AI гарантира това
- Г) Пренаписване на целия файл наведнъж; агентът гарантира това
Обяснение: Рефакторингът подобрява вътрешната структура на кода, без да променя външното му поведение; Златното правило е, че поведението остава постоянно. Това, което гарантира това, е тестването: тестова мрежа, която улавя текущото поведение, преди да го промени, се настройва и стартира след всяка стъпка. Рефакторингът без тестова мрежа е хазарт.
11. Какъв е слоят в производството на документация, който AI не може да знае и е опасно да се компенсира?
- A) Как да стартирате стъпките за инсталиране
- B) Списък с параметри на функция
- C) Обосновка на „защо“ решението за проектиране е взето по този начин ✔
- Г) На какъв език е написан кодът?
Описание: AI може да извлече слоя „какво/как“ (какво прави функцията, как се настройва) от кода; но не може да знае слоя „защо“ (обосновката на дизайна за решение, причината за гранична стойност). Измислената „причина“ е по-опасна от липсата на оправдание; Собственикът на кода трябва да добави този слой.
12. Какво трябва да направи разработчикът, ако иска да постави конфигурационен файл, съдържащ активен API ключ, в неодобрен AI инструмент, докато разрешава спешна грешка?
- A) За бързина поставете файла такъв, какъвто е и след това изтрийте чата
- B) Добавете бележка „поверително“ в края на файла и го изпратете
- В) Оставете ключа и сменете само името на файла
- D) Премахнете/маскирайте тайните и дайте само необходимия нечувствителен контекст ✔
Разкриване: Тайни, лични данни и поверителни активи никога не трябва да се въвеждат в неодобрени средства; Спешността не спира тази червена линия. Правилният подход е първо да извлечете/маскирате тайните и да дадете само необходимия, нечувствителен контекст. Ако все пак изтече тайна, първото нещо, което трябва да направите, е незабавно да завъртите ключа.
13. Код, генериран от изкуствен интелект, преминава тестове и работи в производство. Това доказва ли, че кодът е безопасен?
- А) Не; „работи“ не означава сигурно, сигурността изисква отделен слой за удостоверяване ✔
- Б) Да; Кодът, който преминава теста, е безопасен по дефиниция
- В) Да; Пускането му в производство елиминира всички уязвимости
- Г) Не; но сигурността има значение само ако кодът е бавен
Пояснение: „Работещ“ не е същото като „сигурен“. Дори ако кодът съдържа уязвимост като SQL инжектиране, той може да премине тестване и да работи гладко; Уязвимостта се разкрива само когато нападателят я открие. Следователно, в допълнение към точността, прегледът, ориентиран към сигурността и сканирането като SAST, трябва да се извършват като отделен слой.
14. Коя е най-безопасната дисциплина при даване на многофайлова задача на CLI агент (автономен инструмент, който може да променя файлове и да изпълнява команди)?
- A) Казване на агента „подобри този модул“ и предоставяне на пълна свобода
- B) Предоставяне на тесен обхват и критерии за приемане, първо искане за план, одобряване, прилагане стъпка по стъпка и провеждане на тестове ✔
- C) Директно обединяване на всички промени на агента, без да ги преглеждате
- Г) Предоставяне на агента на неограничен достъп до производствената среда и поверителни данни
Обяснение: С увеличаване на автономията контролът също трябва да се увеличи. Предоставяне на агента на тесен обхват и ясни критерии за приемане, първо искане за план без промени, одобряване на плана, след това прилагането му стъпка по стъпка и провеждане на тестове на всяка стъпка; Той предотвратява промени, които са широки, неподлежат на преглед и трябва да бъдат върнати назад.
15. Кой носи отговорност, произтичаща от код, генериран от AI в критичен за сигурността софтуер (напр. плащане или удостоверяване)?
- A) Тъй като кодът идва от AI, той е в доставчика на превозното средство
- B) Ако AI е достатъчно развит, никой не е; няма нужда от проверка
- C) Екипът/инженерът, който изследва, сглобява и разпространява кода; AI не замества съгласието ✔
- Г) Само лицето, което пише подканата, не тези, които я преглеждат
Описание: AI е умножител на скоростта и генератор на чертежи; не може да поеме отговорност. Отговорността за всякакви грешки, уязвимости или нарушения, произтичащи от кода в производството, е на екипа, който преглежда, сглобява и разпространява този код. В критични за безопасността области изходът на AI не е заместител на преглед и одобрение от квалифициран инженер при никакви обстоятелства.