Техническите решения не се случват в страничните ленти на IDE. Те се случват в нишките на Slack, на същото място, където вашият екип вече говори, дебютира, вече работи по проблемите заедно. That disconnect is a problem. Разговорът за Да се изгради се случва на едно място, а действителната сграда се случва някъде другаде напълно. Контекстът се губи. Решенията се обясняват отново. Някой неизбежно копира проблем в AI чат някъде и поставя отговора обратно и всеки се преструва, че това е нормален работен поток. Какво Просто изпратих нещо, което всъщност се отнася до това: Екипът зад него използва бота вътрешно в продължение на месеци и фундаментално е променен начинът, по който те изграждат и доставят. Кило Слаба интеграция Kilo за Slack ви позволява да @ споменавате агент за кодиране на AI директно в разговорите на вашия екип. Той чете пълния контекст на нишките, се свързва с вашия GitHub repos и може да отговаря на въпроси или да отваря PR, без някой да напуска Slack. TL;DR: Изпробвайте Kilo за Slack . Др ; Др : Try Kilo for Slack Изпробвайте Kilo за Slack . Контекст-сменящ се данък Ето един сценарий, който вероятно е познат. Някой съобщава за грешка в екипния канал на Slack. Трима инженери се занимават с теории. Един разработчик се навива през нишката, абсорбира контекста, след това alt-tabs към своя IDE. Те отварят своя агент за кодиране на AI по избор и започват да обясняват ситуацията отново от нулата. Те поставят грешката. Те описват това, което е било опитано. Те предоставят контекста, който вече е бил в тази нишка на Slack, с изключение на сега те го въвеждат отново. След това се връща към Slack, за да сподели връзката и да обобщи промените. Това се случва десетки пъти седмично на активни инженерни екипи.И всеки път има данък на триене.Контекстният трансфер, повторното обяснение, умствената смяна между "режим на дискусия" и "режим на изпълнение". Това не е огромен данък за един случай, но той се натрупва.И по-важното е, че създава изкуствена граница между мястото, където се вземат решения, и мястото, където се извършва работата. Какво Kilo за Slack всъщност прави Вземете същата Slack нишка: бъгът е бил обсъден, теориите са били плаващи и има груб консенсус за това, което трябва да се случи. @Kilo based on this thread, can you implement the fix for the null pointer exception in the Authentication service? Ботът чете цялата нишка и тъй като е свързан към GitHub repos на екипа чрез платформата Kilo, той се върти нагоре. Няколко минути по-късно има PR връзка точно там в Slack. Облачен агент Няма копиране. няма alt-tabbing. няма обясняване на едно и също нещо два пъти. контекстът, който вече е съществувал в разговора, става вход за изпълнението. За по-прости въпроси, тя работи по същия начин: @Kilo how is error handling implemented in the payment module? Тя чете вашата кодова база и отговаря в нишката.Колегите от екипа могат да видят отговора и можете да поискате последващи действия и да дадете инструкции за изпълнение.Знанията остават в Slack, където могат да бъдат препратени по-късно. Как екипът на Kilo всъщност използва това Екипът използва Kilo за Slack вътрешно от преди публичното пускане и това се превърна в стандартния начин, по който се правят много промени. Появяващите се модели са по-разнообразни от очакваното: Реално време Bug Fixes Може би най-очевидният случай на употреба, и този, който се удари постоянно. Появява се грешка в производството. Някой я знамени в Slack. Екипът обсъжда какво може да го причини. И след това вместо някой доброволно да "погледне", те просто маркират @Kilo. Ключовото нещо: ботът не започва от нулата, когато чете този проблем. Той има пълен контекст на разговора и достъп до цялата кодова база. Той може да чете това, което екипът подозира, и това, което е било изключено. Той знае какво трябва да бъде очакваното поведение. Той работи със същата информация, която човешкият разработчик би имал след четене на нишката: @Kilo I'm seeing this error in production: [stack trace]. Based on what we discussed above, can you create a PR with a fix? PR се приземява в нишката. Някой го преразглежда. Ако изглежда добре, той се слива. Целият цикъл се случва, без някой официално да "побира" задачата. Бързи кодови промени от дискусии Това е нещо, което се е превърнало в ежедневен опит за много хора в Kilo. Разговорът се случва за функция или поведение. Някой казва: „Ние вероятно трябва да променим X на Y.“ В традиционния работен поток това се превръща в умствена бележка, или билет, или нещо, което се обработва „по-късно“. С бота Slack, "по-късно" става "точно сега."Човекът, който имал идеята, просто етикетира Kilo и описва какво трябва да се промени. @Kilo please change "2025" to "2026" through all of the announcement files in our kilo-org/kilocode repo За екип, който се движи бързо, това има значение. триенето на малките промени е това, което ги кара да се натрупват. Документация и актуализации на съдържанието Това се отнася за хора в по-малко технически или не-технически роли. екипът на Kilo използва бота за всички видове промени в цялата платформа на Kilo непрекъснато. копия на целевата страница, вписвания в ръководството, актуализации на документацията, README подобрения. Моделът е същият: в Slack се случва дискусия за това какво трябва да се промени, а след това ботът го изпълнява. @Kilo the getting started guide is missing the new authentication flow. Can you update it based on what we discussed in this thread? За съдържание, което живее в репо (което, ако правите docs-as-code, е по-голямата част от вашето съдържание), този работен поток е огромен спестяващ време. Особено за хора, които се чувстват претоварени да се потопите в работен поток за разработване, само за да направите проста промяна на целевата страница. Използване на функции от Spec дискусии Понякога нишката се развива от "трябва ли да направим това?" до "тук е приблизително как трябва да работи" до "добре, нека наистина да го изградим." @Kilo please implement the caching improvements we discussed in this thread Това работи най-добре, когато нишката съдържа достатъчно специфичност. ботът е добър в заключаването на намерението, но по-ясният контекст води до по-добър изход. Кръстосано-репо координация Истинската инженерна работа обикновено обхваща множество хранилища. Фронт-енд, бак-енд, споделени библиотеки, конфигурации на инфраструктурата. За разлика от някои други интеграции на Slack, Kilo автоматично отчита коя репо се препраща. @Kilo the API change we discussed needs updates in both the backend service and the frontend client. Can you create PRs for both? Няма ръчна конфигурация на канал. Няма контекст за превключване, за да се посочи кой репо да се използва. Той чете нишката, разбира какво се препраща и действа съответно. Защо това е различно от другите Slack ботове Много AI Slack интеграции се чувстват като нововъведения - те са с обща цел AI се опитва да се маскира като специалист във всяка категория.Те отговарят на въпроси, може би генерират някои кодови откъси, но в момента, в който се появява нещо не-тривиално, той се връща към копиране в IDE. Подходът на Кило е архитектурно различен по начини, които имат значение. Многопосочни разговори Повечето AI Slack ботове са предназначени за еднократно взаимодействие. Задайте въпрос, получите отговор. Следващите действия по същество започват нов разговор. Kilo се основава на цялата нишка. Той поддържа контекст в множество обмени. Може да се случи дискусия назад и назад, подходът може да бъде усъвършенстван, могат да бъдат зададени изясняващи въпроси, а след това може да се задейства изпълнението. Това отразява как работят човешките разговори.Никой не обяснява цялата ситуация всеки път, когато добавят към дискусия. Мулти-репозиторий по подразбиране Интеграцията с Slack на Cursor изисква конфигуриране на едно хранилище на работно пространство или канал.Това е добре за прости настройки, но бързо се разпада, когато инженерната работа обхваща няколко хранилища. Kilo извлича съответното хранилище от разговора.Ако се споменават файлове или услуги, които живеят в различни хранилища, той се справя с това.Няма предварителна конфигурация.Няма превключване между каналите за работа с различни кодови бази. Това изглежда като малко нещо, докато не сте работили по проект, където фронт-ендът, бак-ендът и инфраструктурата живеят в отделно помещение. Реално изпълнение, не само чат Това е основната разлика. Kilo за Slack не е Q&A бот. Когато се изисква да се изпълни нещо, той затваря агент в облака, създава клон, прави промените и отваря PR. Той върши работата, а не просто говори за работата. И тъй като използва облачните агенти на Kilo, няма локална машина, която да е замесена. Репото не се нуждае от локално клониране. Непрекъснат контакт с PR След като PR съществува, ботът може да продължи да работи върху него.Ако дойде обратна връзка от прегледа, Kilo може да бъде помолен да се обърне към нея в същата нишка.Разговорът за PR и прилагането на промените се случва на същото място: @Kilo the reviewer asked for better error handling in the auth flow. Can you update the PR? Има непрекъснат разговор за това, което се изгражда, и кодът се развива в отговор на този разговор. Технически детайли За тези, които са любопитни как това всъщност работи под капака: Когато @Kilo се споменава в канал или DM, ботът чете контекста на нишката. Той получава достъп до свързани GitHub хранилища (настройки веднъж в таблото на Kilo). Въз основа на искането, той или отговаря с информация, или изключва агент в облака, за да направи промени. на Те работят в инфраструктурата на Kilo, създават клонове, правят ангажименти и отварят PR срещу repos. Облачни агенти Цените са базирани на използването, със същата цена на токен като използването на модела директно чрез Kilo - което означава, че ви се начисляват само точно цените, определени от доставчиците на модели. поставяйки го на Инсталацията отнема около две минути: Създаване на Kilo акаунт (безплатно да започнете) Свържете GitHub repos в раздела Интеграции на app.kilo.ai Добавяне на интеграцията на Slack от същата страница за интеграции Започнете да споменавате или DM @Kilo в работната област Километър сметки Интеграция на таб Слаба интеграция Ботът може да бъде DM-ed директно за частни въпроси, или да се споменава във всеки канал, където е добавен за видими взаимодействия от екипа. Връзката с GitHub е важна част - и отнема около 10 секунди и 2 кликвания. ботът се нуждае от достъп, за да отговори на въпроси за кодовата база и да създаде PR. За какво да се използва Някои модели са се появили за това къде това блести: Бързи поправки и малки промени.Овърхедът за отваряне на IDE, намиране на правилния файл, извършване на промяна и натискане на PR е висок по отношение на самата работа. Когато "какво" и "защо" вече са заловени в нишка, се чувства естествено просто да добавите "да го направя" в края. Документация и съдържание. Всичко, което живее в репо, но не е строго код. READMEs, ръководства, конфигурационни файлове, копия на целевата страница. Когато една промяна трябва да докосне няколко хранилища, управлението на това от един Slack thread е по-чисто, отколкото отблъскването между IDE прозорците. Мобилни и асинхронни ситуации. PR може да бъде стартиран от телефон. Работата се извършва в облака. Прегледът се извършва по-късно. Когато идеята все още печели Това не е заместител на среда за развитие, това е допълнение. Бърза итерация, локално тестване и преработка в реално време все още искат IDE или Kilo CLI. Стъпките през кода, проверката на състоянието и разбирането на поведението изискват пълно инструментиране. Големите архитектурни промени се възползват от пълния контекст, предоставен от IDE. 1 кг клип Менталният модел: Slack-първо за промените, които се появяват от разговори, IDE-първо за промените, които изискват дълбоко инженерство. По-широката платформа Kilo for Slack е част от по-голямата платформа за инженеринг на агенти на Kilo. , , на и на килото на Същата платформа, същите 500+ варианта за модели и същото качество, достъпни само от различна повърхност. срещу кода JetBrains 1 кг клип Облачни агенти Слаба интеграция Когато завършите изграждането в Кило, можете също да активирате AI-powered Един клик , и дори споделяте сесиите си в целия си екип с . Преглед на кода Разполагащи Кило сесии За екипите, които оценяват инструментите за кодиране на ИИ, това си струва да се мисли.Не е само за това кой инструмент генерира най-добрия код - което е безспорно важно - но също така е за това кой инструмент се вписва в действителния работен поток с най-малко триене.Ако екипът живее в Slack, AI, който може да участва в тези разговори, без да изисква контекстни превключватели, е значително подобрение. Мястото, където екипите обсъждат кода, сега може да бъде мястото, където кодът се пише.Обсъждането и изпълнението се случват заедно.Контекстът протича естествено от единия към другия. Това е вид подобрение на работния поток, който се съчетава с времето. » Опитайте Kilo за Slack сега Опитайте Kilo за Slack сега Kilo е агент за кодиране на AI с отворен код с над 1 милион потребители. Той е наличен в VS Code, JetBrains и CLI, Cloud Agents, Live-preview App Builder, едно кликване на разгръщане, автоматизирани кодови прегледи и сега Slack интеграция. Километърът е . Километърът е
