Далучайцеся да нашага Тэлеграм-канала

Bel-Geek - гэта адкрытая пляцоўка для публікацыі артыкулаў розных аўтараў на беларускай мове на свабодныя тэмы.

Перад тым як прыступіць да стварэння ўласнага артыкула, трэба аўтарызавацца. Калі ў вас няма акаунта, то трэба зарэгістравацца на сайце па спасылцы: https://bel-geek.com/register.

Далей трэба націснуць на тры кропкі ў шапцы сайта, каб з'явілася меню. Выбраць пункт "Стварыць артыкул", і перайсці на старонку рэдактара, ці скарыстацца спасылкай: https://bel-geek.com/editor/add

Пры стварэнні артыкула абавязкова трэба дадаць назву артыкула, імя аўтара ды тэгі ў адпаведныя палі формы, пажадана дадаць апісанне.

Напрыклад:

Як бачна на малюнку, з правага боку будзе панэль, на якой знаходзіцца прадагляд артыкула. З левага боку - рэдактар.

Важна!

Захоўвайце час ад часу свае артыкулы з дапамогай кнопкі "Захаваць" (працуем над аўтазахаваннем), каб выпадкова не згубіць напісанае. Таксама можна захаваць напісанае і адкласці работу з артыкулам на іншы дзень.

Калі вы ўжо вядзеце блогі ў іншых сацыяльных сетках, то дадавайце спасылкі на іх у сваіх артыкулах, каб чытачы маглі знайсці больш цікавай ім інфармацыі.

Калі артыкул будзе гатовы, трэба перавесці перамыкач над рэдактарам тэксту "Паказваць усім" у актыўнае становішча і націснуць кнопку "Захаваць".

PS. Калі вы ствараеце пераклад - то абавязкова пакідайце спасылкі на арыгінал.


Карысныя спасылкі, якімі можна карыстацца падчас напісання артыкулаў:

Мноства слоўнікаў: https://slounik.org/

Правапіс слоў у розных склонах і ліках: https://starnik.by/

Артыкул
LoveJS, 2023-08-06

head

Што вы даведаецеся: Як будаваць AI-агентныя сістэмы з LangGraph - ад базавых канцэпцый да працуючага кода. Мы створым пайплайн для напісання артыкулаў з некалькімі AI-агентамі, якія супрацоўнічаюць, правяраюць працу адзін аднаго і ітэруюць, пакуль вынік не будзе ідэальным.


ЧАСТКА 1: Базавыя канцэпцыі

Што такое граф?

Перш чым разбірацца з LangGraph, трэба зразумець, што такое граф у праграмаванні.

Граф - гэта структура даных

Уявіце карту метро:

  • Станцыі - гэта вузлы (nodes)
  • Лініі паміж станцыямі - гэта пераходы (edges)
text
1    Звычайны граф:              Карта метро (аналогія):
2
3        [A]                         [Плошча Перамогі]
4         │                                 │
5         ▼                                 ▼
6        [B]───────►[C]              [Кастрычніцкая]───►[Купалаўская]
7         │                                 │
8         ▼                                 ▼
9        [D]                         [Інстытут культуры]

У LangGraph:

  • Вузлы - гэта функцыі (агенты), якія нешта робяць.
  • Пераходы - гэта правілы, хто пасля каго працуе.

Навошта патрэбны LangGraph?

Праблема: Звычайныя AI-праграмы лінейныя

text
1Звычайны ланцужок (Chain):
2
3    Пытанне → LLM → Адказ
4
5    або
6
7    Пытанне → Інструмент 1 → LLM → Інструмент 2 → Адказ

Гэта працуе для простых задач, але што, калі:

  • Трэба вярнуцца назад і перарабіць?
  • Трэба праверыць вынік і, магчыма, паўтарыць?
  • Трэба некалькі агентаў з рознымі ролямі?

Рашэнне: LangGraph дазваляе ствараць цыклы

text
1LangGraph (Граф):
2
3                    ┌──────────────────────┐
4                    │                      │
5                    ▼                      │
6    Пытанне → [Даследчык] → [Пісьменнік] → [Рэцэнзент]
789                                          Добра? ───НЕ───► назад да Пісьменніка
1011                                              ТАК
121314                                           [Вынік]

Што такое "стан" (State)?

Стан - гэта памяць праграмы

Уявіце, што вы пішаце артыкул з камандай:

  • Даследчык сабраў матэрыялы → трэба некуды запісаць.
  • Пісьменнік напісаў чарнавік → трэба перадаць рэцэнзенту.
  • Рэцэнзент напісаў заўвагі → трэба вярнуць пісьменніку.

Стан - гэта "кошык", куды ўсе кладуць свае вынікі і адкуль бяруць даныя.

text
1┌─────────────────────────────────────────────────────────────┐
2│                         СТАН (State)                        │
3├─────────────────────────────────────────────────────────────┤
4│                                                             │
5│   topic: "Пра што пішам"                                    │
6│   research: "Матэрыялы ад даследчыка"                       │
7│   draft: "Чарнавік ад пісьменніка"                          │
8│   review: "Заўвагі ад рэцэнзента"                           │
9│   finalArticle: "Гатовы артыкул"                            │
10│   messages: [гісторыя ўсіх паведамленняў]                   │
11│                                                             │
12└─────────────────────────────────────────────────────────────┘
13         ▲                    ▲                    ▲
14         │                    │                    │
15    Даследчык            Пісьменнік           Рэцэнзент
16    (чытае і піша)       (чытае і піша)       (чытае і піша)

ЧАСТКА 2: Annotation - Як ствараецца стан

Што такое Annotation?

Annotation - гэта спосаб апісання структуры стану. Гэта як стварэнне формы з палямі.

Аналогія: Анкета

Уявіце, што вы ствараеце анкету:

text
1┌─────────────────────────────────────────┐
2│            АНКЕТА РАБОТНІКА             │
3├─────────────────────────────────────────┤
4│ Імя: ___________________                │
5│ Узрост: _____                           │
6│ Вопыт працы (гады): _____               │
7│ Спіс навыкаў: ___, ___, ___             │
8└─────────────────────────────────────────┘

У кодзе гэта выглядае так:

typescript
1// АНАЛОГІЯ: Стварэнне формы анкеты
2const Anketa = {
3    imya: '', // Тэкставае поле
4    uzrost: 0, // Лік
5    vopyt: 0, // Лік
6    navyki: [], // Спіс
7};

У LangGraph: Annotation.Root

У LangGraph стан ствараецца з дапамогай Annotation.Root(). Гэта спецыяльная функцыя, якая апісвае структуру вашых даных - якія палі існуюць і як яны павінны абнаўляцца.

typescript
1import { Annotation } from '@langchain/langgraph';
2
3const ResearchState = Annotation.Root({
4    // Кожнае поле апісваецца праз Annotation<Тып>
5    topic: Annotation<string>({...}),
6    research: Annotation<string>({...}),
7    draft: Annotation<string>({...}),
8    // і г.д.
9});

Кожнае поле ўнутры Annotation.Root мае дзве важныя ўласцівасці: reducer (як абнаўляць значэнне) і default (пачатковае значэнне). Мы разбяром іх далей.


Што такое Reducer?

Праблема: Як аб'ядноўваць даныя?

Калі некалькі агентаў пішуць у адно поле, што рабіць?

text
1Агент 1 піша: topic = "Тэма А"
2Агент 2 піша: topic = "Тэма Б"
3
4Што павінна быць у topic? "Тэма А"? "Тэма Б"? "Тэма А + Тэма Б"?

Рашэнне: Reducer - функцыя, якая вырашае

Reducer - гэта функцыя, якая атрымлівае:

  1. Бягучае значэнне (што ўжо ёсць)
  2. Новае значэнне (што прыйшло)

І вяртае: вынік (што захаваць)

typescript
1reducer: (current, update) => результат;
2//         ▲         ▲           ▲
3//         │         │           └── Што захаваецца
4//         │         └── Новае значэнне
5//         └── Бягучае значэнне

Прыклады Reducer-аў:

1. Reducer "ЗАМЯНІЦЬ" (replace)

Новае значэнне поўнасцю замяняе старое.

typescript
1// Код:
2reducer: (current, update) => update;
3
4// Прыклад:
5// Бягучае: "Тэма А"
6// Новае:   "Тэма Б"
7// Вынік:   "Тэма Б"  ← новае замяніла старое

Аналогія: Вы перазапісваеце файл - новы змест замяняе стары.

text
1файл.txt
2──────────────
3Было:   "Стары тэкст"
4        ▼ (перазапіс)
5Стала:  "Новы тэкст"
2. Reducer "ДАДАЦЬ" (append)

Новыя элементы дадаюцца да існуючых.

typescript
1// Код:
2reducer: (current, update) => [...current, ...update];
3
4// Прыклад:
5// Бягучае: ["Паведамленне 1", "Паведамленне 2"]
6// Новае:   ["Паведамленне 3"]
7// Вынік:   ["Паведамленне 1", "Паведамленне 2", "Паведамленне 3"]

Аналогія: Вы дадаеце новыя запісы ў дзённік - старыя застаюцца.

text
1дзённік.txt
2──────────────
3Было:   "Панядзелак: зрабіў А"
4        "Аўторак: зрабіў Б"
5        ▼ (дадаём)
6Стала:  "Панядзелак: зрабіў А"
7        "Аўторак: зрабіў Б"
8        "Серада: зрабіў В"  ← дадалося

Поўны прыклад стану:

typescript
1const ResearchState = Annotation.Root({
2    // ═══════════════════════════════════════════════════════
3    // ПОЛЕ: messages (паведамленні)
4    // ═══════════════════════════════════════════════════════
5    messages: Annotation<BaseMessage[]>({
6        // REDUCER: Дадаваць новыя паведамленні да існуючых
7        reducer: (current, update) => [...current, ...update],
8        // DEFAULT: Пачатковае значэнне - пусты масіў
9        default: () => [],
10    }),
11    //
12    // Як гэта працуе:
13    // 1. Пачатак:    messages = []
14    // 2. Даследчык:  messages = [] + [AIMessage] = [AIMessage]
15    // 3. Пісьменнік: messages = [AIMessage] + [AIMessage] = [AIMessage, AIMessage]
16    // 4. І г.д. - усе паведамленні захоўваюцца
17
18    // ═══════════════════════════════════════════════════════
19    // ПОЛЕ: topic (тэма)
20    // ═══════════════════════════════════════════════════════
21    topic: Annotation<string>({
22        // REDUCER: Замяняць старое значэнне новым
23        reducer: (_, update) => update, // "_" значыць "ігнаруем"
24        // DEFAULT: Пачатковае значэнне - пусты радок
25        default: () => '',
26    }),
27    //
28    // Як гэта працуе:
29    // 1. Пачатак:    topic = ""
30    // 2. Карыстач:   topic = "" → "LangChain"
31    // Калі хтось яшчэ напіша ў topic - старое значэнне знікне
32
33    // ═══════════════════════════════════════════════════════
34    // ПОЛЕ: iterationCount (лічыльнік ітэрацый)
35    // ═══════════════════════════════════════════════════════
36    iterationCount: Annotation<number>({
37        reducer: (_, update) => update, // Проста замяняем
38        default: () => 0, // Пачынаем з 0
39    }),
40    //
41    // Пісьменнік кожны раз піша: iterationCount: state.iterationCount + 1
42    // 1. Пачатак:         iterationCount = 0
43    // 2. Пісьменнік (1):  iterationCount = 0 + 1 = 1
44    // 3. Пісьменнік (2):  iterationCount = 1 + 1 = 2
45    // 4. Пісьменнік (3):  iterationCount = 2 + 1 = 3
46});

Візуалізацыя Reducer-аў:

text
1┌─────────────────────────────────────────────────────────────────┐
2│                    REDUCER: ЗАМЯНІЦЬ                            │
3├─────────────────────────────────────────────────────────────────┤
4│                                                                 │
5│   Бягучае:  █████████████  "Стары тэкст"                        │
6│                   ▼                                             │
7│   Новае:    ░░░░░░░░░░░░░  "Новы тэкст"                         │
8│                   ▼                                             │
9│   Вынік:    ░░░░░░░░░░░░░  "Новы тэкст"  ← толькі новае         │
10│                                                                 │
11└─────────────────────────────────────────────────────────────────┘
12
13┌─────────────────────────────────────────────────────────────────┐
14│                    REDUCER: ДАДАЦЬ                              │
15├─────────────────────────────────────────────────────────────────┤
16│                                                                 │
17│   Бягучае:  [█] [█] [█]         ← тры элементы                  │
18│                   +                                             │
19│   Новае:    [░] [░]             ← два новыя                     │
20│                   =                                             │
21│   Вынік:    [█] [█] [█] [░] [░] ← усе разам                     │
22│                                                                 │
23└─────────────────────────────────────────────────────────────────┘

Што такое default?

default - гэта функцыя, якая вяртае пачатковае значэнне поля.

typescript
1default: () => значэнне

Чаму функцыя, а не проста значэнне?

Гэта распаўсюджаная пастка JavaScript. Калі вы выкарыстоўваеце просты аб'ект або масіў як default, усе экзэмпляры будуць спасылацца на адну і тую ж спасылку - змены ў адным месцы паўплываюць на ўсе астатнія!

typescript
1// ДРЭННА: Калі гэта аб'ект або масіў
2default: []  // Усе экзэмпляры будуць спасылацца на адзін масіў!
3
4// ДОБРА: Функцыя стварае новы масіў кожны раз
5default: () => []  // Кожны экзэмпляр атрымае свой масіў

Прыклады:

typescript
1// Для радка
2default: () => ''        // Пусты радок
3
4// Для ліку
5default: () => 0         // Нуль
6
7// Для масіва
8default: () => []        // Пусты масіў
9
10// Для аб'екта
11default: () => ({})      // Пусты аб'ект
12
13// Для boolean
14default: () => false     // false

ЧАСТКА 3: Вузлы (Nodes) - Агенты

Што такое вузел?

Вузел (Node) - гэта функцыя, якая:

  1. Атрымлівае поўны стан
  2. Робіць нейкую працу (напрыклад, выклікае LLM)
  3. Вяртае частковае абнаўленне стану

Аналогія: Работнік на канвееры

text
1┌─────────────────────────────────────────────────────────────┐
2│                         КАНВЕЕР                             │
3├─────────────────────────────────────────────────────────────┤
4│                                                             │
5│   [Каробка] ──► [Работнік 1] ───────► [Работнік 2] ──────►  │
6│                    │                      │                 │
7│                    ▼                      ▼                 │
8│              Дадае дэталь А         Дадае дэталь Б          │
9│                                                             │
10└─────────────────────────────────────────────────────────────┘
11
12Кожны работнік:
131. Бачыць, што ўжо зроблена (стан)
142. Робіць сваю частку работы
153. Перадае далей з дапаўненнямі

Структура вузла ў кодзе:

typescript
1async function myNode(
2    state: ResearchStateType // ← УВАХОД: Поўны стан
3): Promise<Partial<ResearchStateType>> {
4    // ← ВЫХАД: Частковае абнаўленне
5    // 1. Чытаем даныя са стану
6    const data = state.someField;
7
8    // 2. Робім працу
9    const result = await doSomething(data);
10
11    // 3. Вяртаем абнаўленне (толькі тое, што змянілі)
12    return {
13        someField: result,
14    };
15}

Важна: Partial<State>

Вузел не абавязаны вяртаць увесь стан - толькі палі, якія змяніліся. LangGraph аб'яднае вашае частковае абнаўленне з існуючым станам з дапамогай reducer-аў, якія вы вызначылі.

typescript
1// Поўны стан мае 6 палёў:
2state = {
3    topic: "...",
4    research: "...",
5    draft: "...",
6    review: "...",
7    finalArticle: "...",
8    messages: [...],
9    iterationCount: 0
10}
11
12// Але вузел можа вярнуць толькі тое, што змяніў:
13return {
14    draft: "Новы чарнавік",           // Змянілі
15    messages: [new AIMessage("...")], // Дадалі
16    // Астатнія палі не згадваем - яны застануцца як былі
17}

Нашы вузлы падрабязна

Цяпер разгледзім чатыры вузлы ў нашай сістэме напісання артыкулаў. Кожны вузел мае канкрэтную ролю і перадае свае вынікі наступнаму праз агульны стан.

Вузел 1: Даследчык (researcherNode)

Даследчык - першы агент у нашым пайплайне. Ён бярэ тэму і генеруе даследчыя матэрыялы, якія будуць выкарыстоўвацца пісьменнікам.

typescript
1async function researcherNode(
2    state: ResearchStateType
3): Promise<Partial<ResearchStateType>> {
4    // ┌─────────────────────────────────────────────────────────────┐
5    // │ КРОК 1: Атрымліваем тэму для даследавання                  │
6    // └─────────────────────────────────────────────────────────────┘
7    const topic =
8        state.topic ||
9        String(state.messages[state.messages.length - 1]?.content) ||
10        '';
11    //            ▲               ▲
12    //            │               └── Альбо апошняе паведамленне
13    //            └── Спачатку спрабуем узяць topic
14
15    // ┌─────────────────────────────────────────────────────────────┐
16    // │ КРОК 2: Фармуем prompt для LLM                             │
17    // └─────────────────────────────────────────────────────────────┘
18    const prompt = `Ты эксперт-даследчык. Твая задача - сабраць ключавую інфармацыю.
19    Тэма: ${topic}
20    Правядзі кароткае даследаванне...`;
21
22    // ┌─────────────────────────────────────────────────────────────┐
23    // │ КРОК 3: Выклікаем LLM                                      │
24    // └─────────────────────────────────────────────────────────────┘
25    const response = await model.invoke([
26        { role: 'system', content: prompt }, // Інструкцыі для AI
27        { role: 'user', content: `Даследуй тэму: ${topic}` }, // Запыт
28    ]);
29
30    const research = String(response.content); // Вынік ад LLM
31
32    // ┌─────────────────────────────────────────────────────────────┐
33    // │ КРОК 4: Вяртаем абнаўленне стану                           │
34    // └─────────────────────────────────────────────────────────────┘
35    return {
36        research, // Запісваем вынік даследавання
37        messages: [
38            new AIMessage({ content: `[Даследаванне завершана]\n${research}` }),
39        ],
40        // ▲ Дадаем паведамленне ў гісторыю
41    };
42}

Што адбываецца:

text
1УВАХОД (state):                    ВЫХАД (абнаўленне):
2┌─────────────────────┐            ┌─────────────────────┐
3│ topic: "LangChain"  │            │ research: "LangCh.. │
4│ research: ""        │  ──────►   │ messages: [+1 msg]  │
5│ draft: ""           │            └─────────────────────┘
6│ messages: [1 msg]   │
7└─────────────────────┘
8
9                                    ▼ Пасля аб'яднання:
10                               ┌─────────────────────┐
11                               │ topic: "LangChain"  │
12                               │ research: "LangCh...│ ← абноўлена
13                               │ draft: ""           │
14                               │ messages: [2 msgs]  │ ← дадалося
15                               └─────────────────────┘

Вузел 2: Пісьменнік (writerNode)

Пісьменнік бярэ даследаванне і стварае чарнавік артыкула. Калі гэта перапрацоўка (пасля водгукаў рэцэнзента), ён таксама ўлічвае каментары да рэцэнзіі. Звярніце ўвагу, як iterationCount дапамагае адсочваць, колькі разоў артыкул быў перапісаны.

typescript
1async function writerNode(
2    state: ResearchStateType
3): Promise<Partial<ResearchStateType>> {
4    // ┌─────────────────────────────────────────────────────────────┐
5    // │ КРОК 1: Чытаем даследаванне і магчымую рэцэнзію            │
6    // └─────────────────────────────────────────────────────────────┘
7    const prompt = `Ты тэхнічны пісьменнік. На аснове даследавання напішы артыкул.
8
9Даследаванне:
10${state.research}
11
12${
13    state.review
14        ? `Папярэдняя рэцэнзія (улічы заўвагі):
15${state.review}`
16        : ''
17}
18`;
19
20    // ┌─────────────────────────────────────────────────────────────┐
21    // │ КРОК 2: Выклікаем LLM                                       │
22    // └─────────────────────────────────────────────────────────────┘
23    const response = await model.invoke([
24        { role: 'system', content: prompt },
25        { role: 'user', content: 'Напішы артыкул на аснове даследавання' },
26    ]);
27
28    const draft = String(response.content);
29
30    // ┌─────────────────────────────────────────────────────────────┐
31    // │ КРОК 3: Вяртаем абнаўленне                                  │
32    // └─────────────────────────────────────────────────────────────┘
33    return {
34        draft, // Чарнавік артыкула
35        iterationCount: state.iterationCount + 1, // Павялічваем лічыльнік
36        messages: [
37            new AIMessage({
38                content: `[Чарнавік ${state.iterationCount + 1}]`,
39            }),
40        ],
41    };
42}

Што адбываецца пры паўторным выкліку:

text
1ПЕРШЫ ВЫКЛІК:                      ДРУГІ ВЫКЛІК (пасля рэцэнзіі):
2┌─────────────────────┐            ┌─────────────────────┐
3│ research: "..."     │            │ research: "..."     │
4│ review: ""          │            │ review: "Дапрацуй...│ ← ёсць заўвагі!
5│ iterationCount: 0   │            │ iterationCount: 1   │
6└─────────────────────┘            └─────────────────────┘
7         │                                   │
8         ▼                                   ▼
9  Піша без заўваг                   Улічвае заўвагі
10         │                                   │
11         ▼                                   ▼
12┌─────────────────────┐            ┌─────────────────────┐
13│ draft: "Версія 1"   │            │ draft: "Версія 2"   │
14│ iterationCount: 1   │            │ iterationCount: 2   │
15└─────────────────────┘            └─────────────────────┘

Вузел 3: Рэцэнзент (reviewerNode)

Рэцэнзент ацэньвае чарнавік і вырашае, ці гатовы ён да публікацыі. Ключавы момант тут - вывад: калі рэцэнзія змяшчае "ЗАЦВЕРДЖАНА", артыкул ідзе на фіналізацыю. У адваротным выпадку ён вяртаецца да пісьменніка для паляпшэнняў. Менавіта гэта дазваляе ствараць цыкл у нашым графе.

typescript
1async function reviewerNode(state: ResearchStateType): Promise<Partial<ResearchStateType>> {
2
3    // ┌─────────────────────────────────────────────────────────────┐
4    // │ КРОК 1: Фармуем запыт на рэцэнзію                          │
5    // └─────────────────────────────────────────────────────────────┘
6    const prompt = `Ты строгі рэдактар. Ацані артыкул.
7
8Артыкул:
9${state.draft}
10
11Ацані па крытэрыях:
121. Дакладнасць інфармацыі
132. Структура і лагічнасць
143. Якасць мовы
154. Паўната раскрыцця тэмы
16
17Калі артыкул добры - скажы "ЗАЦВЕРДЖАНА".
18Калі трэба дапрацаваць - дай канкрэтныя рэкамендацыі.`;
19
20    // ┌─────────────────────────────────────────────────────────────┐
21    // │ КРОК 2: Атрымліваем рэцэнзію                                │
22    // └─────────────────────────────────────────────────────────────┘
23    const response = await model.invoke([...]);
24    const review = String(response.content);
25
26    // ┌─────────────────────────────────────────────────────────────┐
27    // │ КРОК 3: Вяртаем рэцэнзію                                    │
28    // └─────────────────────────────────────────────────────────────┘
29    return {
30        review,  // Рэцэнзія (або "ЗАЦВЕРДЖАНА" або заўвагі)
31        messages: [new AIMessage({ content: `[Рэцэнзія]\n${review}` })],
32    };
33}

Два магчымыя вынікі:

text
1ВАРЫЯНТ А: Артыкул добры           ВАРЫЯНТ Б: Трэба дапрацаваць
2┌─────────────────────────┐        ┌─────────────────────────┐
3│ review: "ЗАЦВЕРДЖАНА.   │        │ review: "Дапрацаваць:   │
4│ Артыкул выдатны!"       │        │ 1. Дадай прыклады       │
5│                         │        │ 2. Удакладні тэрміны"   │
6└─────────────────────────┘        └─────────────────────────┘
7         │                                   │
8         ▼                                   ▼
9    Ідзём да                           Вяртаемся да
10    finalizer                          writer

Вузел 4: Фіналізатар (finalizerNode)

Фіналізатар - найпрасцейшы вузел - ён проста капіюе зацверджаны чарнавік у поле finalArticle, пазначаючы канец нашага працоўнага працэсу. Ён выклікаецца, калі рэцэнзент зацвярджае артыкул.

typescript
1async function finalizerNode(
2    state: ResearchStateType
3): Promise<Partial<ResearchStateType>> {
4    // Просты вузел - капіюе чарнавік у фінальны артыкул
5    return {
6        finalArticle: state.draft, // Гатовы артыкул
7        messages: [new AIMessage({ content: `[ГАТОВА]\n\n${state.draft}` })],
8    };
9}

Што адбываецца:

text
1УВАХОД:                            ВЫХАД:
2┌─────────────────────┐            ┌─────────────────────┐
3│ draft: "Гатовы..."  │ ──────►    │ finalArticle:       │
4│ finalArticle: ""    │            │   "Гатовы..."       │
5└─────────────────────┘            └─────────────────────┘

ЧАСТКА 4: Пераходы (Edges)

Што такое пераход?

Пераход (Edge) - гэта правіла, якое кажа: "Пасля гэтага вузла выконваецца той вузел".

Аналогія: Стрэлкі на схеме

text
1Рэцэпт пічы:
2
3    [Зрабіць цеста] ─────► [Дадаць соус] ─────► [Дадаць сыр] ─────► [Выпекчы]
4           │                     │                    │                 │
5           ▼                     ▼                    ▼                 ▼
6       ПЕРАХОД              ПЕРАХОД              ПЕРАХОД           КАНЕЦ

Два тыпы пераходаў у LangGraph:

1. Простыя пераходы (addEdge)

Заўсёды ідзём у адзін і той жа вузел.

typescript
1workflow.addEdge('researcher', 'writer');
2//                    ▲            ▲
3//                    │            └── Куды ідзём
4//                    └── Адкуль ідзём
5
6// Значыць: Пасля researcher ЗАЎСЁДЫ ідзём да writer

Візуалізацыя:

text
1    [researcher] ───────────────► [writer]
2                   (заўсёды)
2. Умоўныя пераходы (addConditionalEdges)

Выбар наступнага вузла залежыць ад стану.

typescript
1workflow.addConditionalEdges(
2    'reviewer', // Адкуль ідзём
3    shouldContinue, // Функцыя, якая вырашае куды
4    {
5        writer: 'writer', // Калі функцыя верне 'writer' → ідзём у writer
6        finalizer: 'finalizer', // Калі функцыя верне 'finalizer' → ідзём у finalizer
7    }
8);

Візуалізацыя:

text
1                            ┌──────────► [writer]
23    [reviewer] ─────► [?] ──┤
45                            └──────────► [finalizer]
6
7    Функцыя shouldContinue вырашае, якую стрэлку абраць

Функцыя shouldContinue падрабязна

Гэта "мозг" нашага ўмоўнага пераходу. Ён аналізуе бягучы стан і вырашае, куды ісці далей. Функцыя павінна вярнуць радок, які адпавядае аднаму з ключоў у аб'екце супастаўлення, вызначаным у addConditionalEdges.

typescript
1function shouldContinue(state: ResearchStateType): 'writer' | 'finalizer' {
2    //                                              ▲
3    //                                              └── Вяртае адзін з гэтых радкоў
4
5    const review = state.review.toLowerCase();
6    const maxIterations = 3;
7
8    // ═══════════════════════════════════════════════════════════════
9    // УМОВА 1: Рэцэнзент сказаў "ЗАЦВЕРДЖАНА"
10    // ═══════════════════════════════════════════════════════════════
11    if (review.includes('зацверджана') || review.includes('approved')) {
12        console.log('Артыкул зацверджаны');
13        return 'finalizer'; // ← Ідзём завяршаць
14    }
15
16    // ═══════════════════════════════════════════════════════════════
17    // УМОВА 2: Занадта шмат спробаў (абарона ад бясконцага цыкла)
18    // ═══════════════════════════════════════════════════════════════
19    if (state.iterationCount >= maxIterations) {
20        console.log('Дасягнуты максімум ітэрацый');
21        return 'finalizer'; // ← Прымусова завяршаем
22    }
23
24    // ═══════════════════════════════════════════════════════════════
25    // ІНАКШ: Патрэбна дапрацоўка
26    // ═══════════════════════════════════════════════════════════════
27    console.log('Патрабуецца дапрацоўка');
28    return 'writer'; // ← Вяртаемся да пісьменніка
29}

Блок-схема рашэння:

text
1                         ┌───────────────────┐
2                         │  shouldContinue   │
3                         │    (функцыя)      │
4                         └─────────┬─────────┘
567                    ┌──────────────────────────────┐
8                    │ Ці ёсць "зацверджана"        │
9                    │ у рэцэнзіі?                  │
10                    └──────────────┬───────────────┘
1112                      ┌────────────┴────────────┐
13                      │                         │
14                     ТАК                       НЕ
15                      │                         │
16                      ▼                         ▼
17               ┌────────────┐      ┌──────────────────────────┐
18               │  return    │      │ Ці iterationCount >= 3?  │
19               │'finalizer' │      └──────────────┬───────────┘
20               │            │                     │
21               └────────────┘        ┌────────────┴────────────┐
22                                     │                         │
23                                    ТАК                       НЕ
24                                     │                         │
25                                     ▼                         ▼
26                              ┌────────────┐            ┌────────────┐
27                              │  return    │            │  return    │
28                              │'finalizer' │            │  'writer'  │
29                              │            │            │            │
30                              └────────────┘            └────────────┘

Як будуецца граф

Цяпер давайце злучым усё разам! Пабудова графа ў LangGraph ідзе па простым шаблоне: стварыць граф, дадаць вузлы, злучыць іх пераходамі і скампіляваць.

Паслядоўнасць стварэння:

typescript
1// ═══════════════════════════════════════════════════════════════
2// КРОК 1: Ствараем StateGraph з нашым станам
3// ═══════════════════════════════════════════════════════════════
4const workflow = new StateGraph(ResearchState)
5
6    // ═══════════════════════════════════════════════════════════
7    // КРОК 2: Дадаем вузлы (рэгіструем функцыі)
8    // ═══════════════════════════════════════════════════════════
9    .addNode('researcher', researcherNode) // Імя 'researcher' → функцыя
10    .addNode('writer', writerNode) // Імя 'writer' → функцыя
11    .addNode('reviewer', reviewerNode) // Імя 'reviewer' → функцыя
12    .addNode('finalizer', finalizerNode) // Імя 'finalizer' → функцыя
13
14    // ═══════════════════════════════════════════════════════════
15    // КРОК 3: Дадаем простыя пераходы
16    // ═══════════════════════════════════════════════════════════
17    .addEdge('__start__', 'researcher') // Пачатак → Даследчык
18    .addEdge('researcher', 'writer') // Даследчык → Пісьменнік
19    .addEdge('writer', 'reviewer') // Пісьменнік → Рэцэнзент
20
21    // ═══════════════════════════════════════════════════════════
22    // КРОК 4: Дадаем умоўны пераход
23    // ═══════════════════════════════════════════════════════════
24    .addConditionalEdges('reviewer', shouldContinue, {
25        writer: 'writer', // Калі 'writer' → назад да пісьменніка
26        finalizer: 'finalizer', // Калі 'finalizer' → да фіналізатара
27    })
28
29    // ═══════════════════════════════════════════════════════════
30    // КРОК 5: Дадаем канчатковы пераход
31    // ═══════════════════════════════════════════════════════════
32    .addEdge('finalizer', '__end__'); // Фіналізатар → Канец

Спецыяльныя вузлы:

text
1┌─────────────────────────────────────────────────────────────┐
2│  '__start__'  │  Віртуальны пачатковы вузел                │
3│               │  LangGraph аўтаматычна пачынае з яго        │
4├───────────────┼─────────────────────────────────────────────┤
5│  '__end__'    │  Віртуальны канчатковы вузел               │
6│               │  Калі дайшлі да яго - граф завяршыўся       │
7└─────────────────────────────────────────────────────────────┘

ЧАСТКА 5: Кампіляцыя і запуск

Мы вызначылі наш стан, вузлы і пераходы. Цяпер час ператварыць гэты чарцёж у працуючае прыкладанне!

Што такое compile()?

compile() - гэта працэс пераўтварэння апісання графа ў выканальную праграму. Пакуль вы не выклічаце compile(), у вас ёсць толькі апісанне таго, што вы хочаце пабудаваць - а не рэальна працуючая сістэма.

typescript
1// Апісанне графа (blueprint)
2const workflow = new StateGraph(ResearchState)
3    .addNode(...)
4    .addEdge(...);
5
6// Кампіляцыя ў выканальную праграму
7const app = workflow.compile();
8//    ▲
9//    └── Цяпер гэта можна запускаць!

Аналогія: Рэцэпт vs. Гатовая страва

text
1workflow (апісанне)              app (скампіляваная праграма)
2────────────────────            ──────────────────────────────
3Рэцэпт на паперы                 Гатовая піца
4   - Як рабіць цеста                (можна есці)
5   - Што дадаваць
6   - Як выпякаць
7
8Нельга есці!                     Можна есці!

Checkpointer (MemorySaver)

Што гэта такое?

Checkpointer - гэта механізм для захавання стану пасля кожнага кроку.

typescript
1import { MemorySaver } from '@langchain/langgraph';
2
3const checkpointer = new MemorySaver();
4
5const app = workflow.compile({
6    checkpointer, // ← Дадаем checkpointer
7});

Навошта гэта патрэбна?

text
1БЕЗ CHECKPOINTER:
2═══════════════════════════════════════════════════════════════
3
4    Запуск 1:   START → researcher → writer → ... → END
5
6    Запуск 2:   START → researcher → ...  (усё з пачатку!)
7
8    Немагчыма працягнуць з месца спынення
9    Немагчыма праглядзець гісторыю
10
11
12З CHECKPOINTER:
13═══════════════════════════════════════════════════════════════
14
15    Запуск 1:   START → researcher → [ЗАХАВАНА]
1617                                   thread_id: "chat-123"
18
19    Запуск 2:   [АДНАЎЛЕННЕ] → writer → reviewer → ...
2021                thread_id: "chat-123"
22
23    Можна працягнуць з месца спынення
24    Можна праглядзець гісторыю
25    Можна мець некалькі незалежных "размоў"

Thread ID - ідэнтыфікатар "трэда"

typescript
1const config = {
2    configurable: {
3        thread_id: 'article-1', // Унікальны ID для гэтай "размовы"
4    },
5};
6
7// Кожны thread_id - гэта асобная гісторыя
8// 'article-1' - пра адзін артыкул
9// 'article-2' - пра іншы артыкул
10// Яны не перасякаюцца!

Запуск графа

Нарэшце! Давайце запусцім наш граф. Функцыя invoke() прымае пачатковыя значэнні стану і канфігурацыю, а затым выконвае ўвесь граф ад пачатку да канца.

Функцыя invoke()

typescript
1const result = await app.invoke(
2    // Пачатковыя даныя для стану
3    {
4        topic: 'Перавагі LangChain',
5        messages: [new HumanMessage('Перавагі LangChain')],
6    },
7    // Канфігурацыя
8    {
9        configurable: {
10            thread_id: 'article-1',
11        },
12    }
13);

Што адбываецца пры invoke():

text
1┌─────────────────────────────────────────────────────────────────┐
2│                         invoke()                                 │
3└───────────────────────────────┬─────────────────────────────────┘
456┌─────────────────────────────────────────────────────────────────┐
7│ 1. ІНІЦЫЯЛІЗАЦЫЯ СТАНУ                                          │
8│    state = {                                                     │
9│        topic: "Перавагі LangChain",                             │
10│        messages: [HumanMessage],                                 │
11│        research: "",  ← default                                  │
12│        draft: "",     ← default                                  │
13│        review: "",    ← default                                  │
14│        finalArticle: "", ← default                               │
15│        iterationCount: 0, ← default                              │
16│    }                                                             │
17└───────────────────────────────┬─────────────────────────────────┘
181920┌─────────────────────────────────────────────────────────────────┐
21│ 2. ПАЧАТАК: __start__ → researcher                              │
22│    Выконваем researcherNode(state)                              │
23│    → Атрымліваем абнаўленне {research: "...", messages: [...]}  │
24│    → Аб'ядноўваем са станам праз reducers                       │
25│    Захоўваем checkpoint                                          │
26└───────────────────────────────┬─────────────────────────────────┘
272829┌─────────────────────────────────────────────────────────────────┐
30│ 3. ПЕРАХОД: researcher → writer                                 │
31│    Выконваем writerNode(state)                                  │
32│    → Атрымліваем абнаўленне {draft: "...", iterationCount: 1}   │
33│    → Аб'ядноўваем са станам                                     │
34│    Захоўваем checkpoint                                         │
35└───────────────────────────────┬─────────────────────────────────┘
363738┌─────────────────────────────────────────────────────────────────┐
39│ 4. ПЕРАХОД: writer → reviewer                                   │
40│    Выконваем reviewerNode(state)                                │
41│    → Атрымліваем абнаўленне {review: "..."}                     │
42│    → Аб'ядноўваем са станам                                     │
43│    Захоўваем checkpoint                                         │
44└───────────────────────────────┬─────────────────────────────────┘
454647┌─────────────────────────────────────────────────────────────────┐
48│ 5. УМОЎНЫ ПЕРАХОД: shouldContinue(state)                        │
49│    → Вяртае 'writer' або 'finalizer'                            │
50│    → Калі 'writer' - вяртаемся да кроку 3                       │
51│    → Калі 'finalizer' - ідзём далей                             │
52└───────────────────────────────┬─────────────────────────────────┘
53                                │ (калі 'finalizer')
5455┌─────────────────────────────────────────────────────────────────┐
56│ 6. ПЕРАХОД: reviewer → finalizer                                │
57│    Выконваем finalizerNode(state)                               │
58│    → Атрымліваем абнаўленне {finalArticle: "..."}               │
59│    → Аб'ядноўваем са станам                                     │
60│    Захоўваем checkpoint                                         │
61└───────────────────────────────┬─────────────────────────────────┘
626364┌─────────────────────────────────────────────────────────────────┐
65│ 7. КАНЕЦ: finalizer → __end__                                   │
66│    Граф завяршыўся                                              │
67│    Вяртаем фінальны стан                                        │
68└───────────────────────────────┬─────────────────────────────────┘
697071                        return state (поўны)

ЧАСТКА 6: FAQ - Частыя пытанні

Чаму reducer для messages дадае, а для topic замяняе?

Паведамленні - гэта гісторыя. Мы хочам захаваць усе паведамленні за ўвесь працэс.

Topic - гэта бягучая тэма. Калі тэма змянілася - старая не патрэбна.

Што будзе, калі я не ўкажу reducer?

LangGraph выкарыстае паводзіны па змаўчанні - замена (як для topic).

Нашто патрэбен iterationCount?

Каб абараніцца ад бясконцага цыкла. Калі рэцэнзент ніколі не скажа "зацверджана", праграма будзе бясконца круціцца паміж writer і reviewer.

Ці можа адзін вузел выклікаць іншы напрамую?

Не. Вузлы не ведаюць адзін пра аднаго. Яны толькі чытаюць/пішуць стан. LangGraph сам вырашае, хто выконваецца наступным, на аснове пераходаў.

Што такое start і end?

Гэта спецыяльныя віртуальныя вузлы:

  • __start__ - адкуль пачынаецца граф
  • __end__ - дзе граф завяршаецца

Яны не выконваюць код - толькі пазначаюць межы.

Ці можна мець некалькі канчатковых вузлоў?

Так! Напрыклад:

typescript
1.addEdge('success', '__end__')
2.addEdge('error', '__end__')

Выснова

Віншуем! Вы вывучылі асноўныя канцэпцыі LangGraph. Давайце падвядзём вынікі таго, што мы разгледзелі:

КанцэпцыяШто робіць
State + AnnotationВызначае структуру даных, якія перадаюцца паміж агентамі
ReducerВызначае, як аб'ядноўваць новыя даныя з існуючымі
Nodes (Вузлы)Функцыі, якія апрацоўваюць стан
Edges (Пераходы)Правілы, якія вызначаюць парадак выканання
Conditional EdgesДынамічны выбар наступнага вузла
CheckpointerЗахаванне стану для працягу пазней

Што далей?

Цяпер, калі вы разумееце асновы, вы можаце:

  1. Пабудаваць уласную агентную сістэму - Пачніце з простага графа з двух вузлоў і паступова дадавайце складанасць
  2. Эксперыментаваць з рознымі патокамі - Паспрабуйце ствараць графы з некалькімі ўмоўнымі галінамі
  3. Дадаць персістэнтнасць - Выкарыстоўвайце MemorySaver або checkpointer-ы на базе дадзеных для прадакшна
  4. Даследаваць прасунутыя магчымасці - Вывучыце падграфы, паралельнае выкананне і патэрны з удзелам чалавека

Ключавыя высновы

  • Думайце графамі: Разбівайце ваш AI-працоўны працэс на дыскрэтныя крокі (вузлы), злучаныя правіламі (пераходамі)
  • Стан - гэта ўсё: Уся камунікацыя паміж вузламі адбываецца праз агульны стан
  • Reducer-ы важныя: Выбірайце правільны reducer для кожнага поля - дадаванне для гісторыі, замена для бягучых значэнняў
  • Цыклы дазваляюць ітэрацыі: У адрозненне ад простых ланцужкоў, графы могуць вяртацца назад для дапрацоўкі

Прыклад з напісаннем артыкула, які мы пабудавалі, дэманструе рэальны патэрн: даследаванне → напісанне → рэцэнзаванне → (паўтарыць пры неабходнасці) → фіналізацыя. Гэты ж патэрн прымяняецца да многіх AI-прыкладанняў: рэцэнзаванне кода, мадэрацыя кантэнту, шматкрокавае разважанне і многае іншае.

Паспяховага кодзінгу! 🚀

LangChain
LangGraph
AI
tools
Admin, 2025-11-26

farmer

Вайб-кодынг - гэта не «магія ў вакууме», а свядомая тэхніка хуткай распрацоўкі з надзейным каркасам. За апошнія месяцы я прайшоў шлях ад bolt.new да Copilot, Claude, Cursor і Google AI Studio: больш за тысячу промптаў, дзясяткі ітэрацый, шмат урокаў. Ніжэй - не зборнік банальнасцяў, а адшліфаваны набор прынцыпаў, інструментаў і шаблонаў, якія сапраўды эканомяць час, грошы і нервы, калі колькасць коду расце.

Уводзіны: што рабіць, каб не падгарала дупа.

Ідэя простая: мы рухаемся маленькімі, але дакладнымі крокамі, замацоўваем вынікі ў git, просім ШІ рабіць лакальныя патчы «diff-only», а не перапісаць усё навокал, і падтрымліваем дызайн-сістэму з першых радкоў. Замест «агента, які ўсё зробіць за вас» - сумесная праца з памочнікам, якому вы ясна фармулюеце задачу і межы. Так мы пазбягаем «галюцынацый», дарэмнай перабудовы і не губляем кантроль над токенамі.

1. План фічы і спецыфікацыя (уваходы/выхады/памылкі)

Перад любым кодам - кароткі, але канкрэтны план:

  • 1–2 сказы пра тое што робім: «Карыстальнік робіць X і атрымлівае Y» (прыклад: «Стварае і дзяліцца спісамі задач за 30 секунд без рэгістрацыі»).
  • 3–7 асноўных flow (сцэнарыяў) і экранаў: напрыклад «Sign in -> Dashboard -> Create item». Без дэталёвай разметкі — проста назвы і парадак.
  • Каркас у межах файлаў: «маршруты -> модулі -> паўторна выкарыстоўваемыя кампаненты».
  • Чорны спіс «не вынаходзіць нанова»: кнопкі, інпуты, алерты, хэлперы, схемы валідацыі.

Далей — спецыфікацыя фічы: уваходы, выхады, памылкі, абмежаванні, крытэрыі done. Усе наступныя промпты — строга ў межах гэтай спецыфікацыі.

2. Сплануй UI/UX наперад (да кода)

Перад кодам — візуалізуй і эксперыментуй з layout. Выкарыстоўвай інструменты накшталт v0, каб хутка пабачыць, як будуць выглядаць экраны, і ўнесці карэкціроўкі.

Кансістэнтнасць - база. Вызнач дызайн-сістэму на старце і трымайся яе:

  • Адзін базавы файл: breakpoints, spacing scale, grid, тыпаграфіка.
  • Стварыце паўторна выкарыстоўваемыя кампаненты адразу: Button, Input, Select, Alert, Loader, Empty/Error states ці спасылайцесь на бібліятэку.
  • Праверка пасля кожнай ітэрацыі: ці не «распаўзліся» памеры і шрыфты.
  • У промптах: «Выкарыстай існуючыя ButtonX, InputY. Новыя стылі не ўводзіць без патрэбы».

Гэта зэканоміць вам тоны часу і выратуе ад хаатычных рэфактарынгаў пазней, ну і не будзе паліць токены.

Рэсурсы: 21st.dev — гатовыя UI-патэрны з AI-промптамі, проста капіруй-устаўляй.

3. Папулярны стэк, які дапамагае (не перашкаджае)

Чым шырэй супольнасць і дакументацыя, тым дакладней ШІ трапляе ў API і патэрны. Практычныя звязкі:

  • Next.js - фронт + лёгкі API-слой.
  • Tailwind CSS - хуткія кансістэнтныя стылі без «CSS-кашы» на старце.
  • Fastify + MongoDB або Supabase - мінімум рытуалаў, шмат гатовых рэцэптаў.

Галоўнае - не экзотыка, а надзейныя адказы мадэлі.

4. Git-дысцыпліна: рабіце каміты як мага часцей

Ваш лепшы страхавы поліс:

  • Адна фіча - асобная галіна.
  • Маленькія працоўныя кавалкі - частыя каміты з яснымі паведамленнямі.
  • Перад рызыкоўнымі генерацыямі/рэарганізацыямі - commit або branch.

Так не давядзецца «адкручваць» назад па 700 радкоў, калі ШІ «аптымізаваў» не там.

5. Дробім складанае: Спецыфікацыя -> Каркас -> Логіка -> Тэсты

Не трэба даваць вялікія промпты накшталт «зрабі ўвесь модуль цалкам». ШІ пачне галюцынаваць і выдаваць лайно. Раздзяляйце любую складаную фічу на этапы (фазы): замест аднаго вялікага запыту - 3–5 малых або больш, калі трэба.

Паслядоўны канвеер:

  1. Маршруты і каркас файлаў.
  2. Базавая разметка і кампаненты.
  3. Логіка/валідацыя/станы.
  4. Тэсты, бяспека, аптымізацыя.

ШІ працуе найбольш стабільна, калі граніцы задачы вузкія і выразныя.

6. Канкрэтныя промпты з межамі (diff-only)

Garbage in, garbage out. Даваць дрэнныя промпты = атрымаць такое ж лайно. Промпты павінны быць настолькі падрабязнымі, наколькі магчыма — не пакідайце месца для здагадак ШІ. Калі не атрымліваецца, запусці Gemini 2.5 Pro ў Google AI Studio і папрасі яго зрабіць дэталёвы промпт на аснове тваёй ідэі (Чат GPT таксама добра выконвае такую задачу).

Канчатковае фармуляванне — ваш рычаг кіравання. Мінімальны шаблон:

«Адрэфактар ProfileForm.tsx: вынесі валідацыю ў асобны хук, API не чапай, захавай імёны пропсаў і публічны API, выкарыстоўвай InputX і ButtonY. Не змяняй нічога па-за пералічаным.»

Дадайце прыклад фрагмента кода/інтэрфейса — мадэль хутчэй «зловіць» ідэю. Ахоўная фраза «Не змяняй нічога, пра што не прасіў» — абавязковая.

7. Кантэкст чата і reset: калі адкрываць новы трэд (чат)

Вялікі чат = дрэйф патэрнаў, страта кантэкста. Перазапуск - гэта не параза, а гігіена:

  • Кароткае ўвядзенне для новага акна: «Фіча X, файлы A/B/C, чапаць дазволена толькі …»
  • Памятайце: занадта шмат кантэксту так жа шкодна, як і яго недахоп - пакідайце толькі істотнае.

8. Эканомія токенаў: асцярожна з бюджэтам

  • Дробныя патчы замест гіганцкіх «перапісаў».
  • Diff-first: «пакажы план патча + diff, потым прыменім» .
  • Пераключэнне мадэляў: простыя рашэнні - Auto/меншая мадэль; агляды і бяспека - Gemini 2.5 Pro / Sonnet.

9. Кода-гігіена: ESLint, тыпы, мінімальныя тэсты

  • Маленькія чыстыя функцыі, без «лянівых» пабочных эфектаў.
  • ESLint + аўтафіксы; выдаленне мёртвага кода на кожным кроку.
  • Мінімум юніт-тэстаў: «шчаслівы шлях» + пагранічныя выпадкі (null/пуста/невядомы тып).
  • TypeScript са строгімі правіламі - менш каментароў, больш гарантый.

Перад камітам: прыбярыце лішнія логі і «часовыя» каментары - яны з’ядаюць увагу падчас ітэрацый і ядуць токены.

10. Бяспека: кароткі, але сур'ёзны чэкліст

(на самой справе - проста відавочная база, але ў працы з ШІ - трэба заўседы кантраляваць)

Тут заўсёды будуць недахопы (у кожнага), але гэтыя правілы выратуюць ад самых жорсткіх:

Давяраць кліенцкім даным: прыняць form/URL уводы напрамую.
-> Fix: Заўсёды валідуй і санітызуй на серверы; экрануй вывад.

Сакрэты ў фронтэндзе: API-ключы/credentials у React/Next.js кліенцкім кодзе.
-> Fix: Трымай сакрэты толькі на серверы (env vars, .env у .gitignore).

Слабая аўтарызацыя: правяраць толькі "ці залагінены", а не "ці дазволена гэта".
-> Fix: Сервер павінен правяраць дазволы для кожнага дзеяння і рэсурсу.

Лішак у памылках: паказваць stack trace / памылкі базы карыстальніку.
-> Fix: Агульнае паведамленне карыстальніку, падрабязныя логі — распрацоўшчыку.

IDOR і ўласнасць: дазваляць карыстальніку X рэдагаваць даныя карыстальніка Y праз ID.
-> Fix: Сервер павінен пацвердзіць, што бягучы карыстальнік валодае гэтым ID.

Ігнараванне DB-бяспекі: абыходзіць такія рэчы, як RLS (Row Level Security).
-> Fix: Вызнач правілы доступу да даных наўпрост у базе (RLS).

Незахаваныя API: адсутнасць rate limit; незашыфраваныя чуллівыя даныя.
-> Fix: Rate limit праз middleware; шыфруй даныя ў спакоі; заўсёды HTTPS.

11. Ітэратыўны агляд (Gemini/Claude): праблема -> рызыка -> патч

Гэта выкарыстоўваць не зусім проста праз тое што капіраваць усе файлы цяжка, але нават просты аналіз з чату можа выявіць значныя недахопы, таму перыядычна робім гэта.

Пасля пабудовы фічы скапіруй увесь код у Gemini 2.5 Pro (у Google AI Studio) ці проста запусці якія вялікія мадэлі для праверкі коду і фіч — яны маюць вялікае кантэкстнае вакно і выдатна знаходзяць уразлівасці і дрэнныя патэрны.

Як працаваць:

  1. Скажы Gemini: «Ты эксперт па бяспецы. Знайдзі ўразлівасці.» / «Ты эксперт па [твой стэк]. Знайдзі праблемы прадукцыйнасці і дрэнныя патэрны.»
  2. Gemini вяртае спіс праблем. Скапіруй іх у Claude ў Cursor і скажы выправіць.
  3. Пасля выпраўлення — зноў Gemini, пакуль ён не скажа "усё ОК".

Мэты аналізу: бяспека, прадукцыйнасць, дубляжы, лішнія залежнасці.

Фармат адказу, які працуе:

  1. Праблема;
  2. Чаму гэта праблема;
  3. Рызыка;
  4. Канкрэтны патч/крокі.

Далей — лакальныя diff-патчы, невялікія тэсты, паўторны прагляд.

12. "Упартыя" багі: фіксім без панікі

Калі пасля 2–3 заходаў усё яшчэ «не туды»:

  1. Папрасіце мадэль назваць топ-падазраваных па ланцужку залежнасцяў.
  2. Дадайце логі ў вузкія месцы, дадайце факты (stack, payload, межы).
  3. Пры неабходнасці - адкат да апошняга паспяховага каміту і дробныя крокі наперад. Часам толькі так і вырашаюцца праблемы. Ну ці самаму рукамі выпраўляць, але ж мы не за гэтым прыйшлі да вайбкодынгу.

13. Правіла межаў: «Не чапай, калі не прасілі»

ШІ любіць «падчысціць», калі бачыць магчымасць. Абмежаванні - заключная фраза ў кожным промпце: «Нічога не змяняй па-за пералічаным». Пасля некалькіх ітэрацый мадэль пачынае паважаць межы.

14. Repo-інструкцыі і «Агульныя памылкі ШІ» як код

  • Вядзіце ai_common_mistakes.md: ШІ любіць пераносіць валідацыю ў UI; змяняе назвы пропсаў; выдаляе патрэбныя імпарты - усё сюды.
  • Папка instructions/ з markdown-прыкладамі, шаблонамі промптаў, «Cursor Rules», кароткімі best practices.
  • У новай фічы дадавайце спасылку на файл памылак - эканоміць токены і час.

15. Інструменты і патэрны, якія працу паскараюць без мітусні

Інструменты:

  • Storybook - ізаляваны UI і дакументаванне патэрнаў.
  • Playwright / Vitest - хуткія E2E/юніт-тэсты; добра спалучаюцца з diff-патчамі.
  • CodeSandbox / StackBlitz - імгненныя пясочніцы для PoC.
  • Sourcegraph Cody - глыбокі пошук + кантэкстныя патчы.
  • Continue / Aider / Windsurf / Codeium - лёгкія асістэнты для «застряганняў».
  • Tabby / лакальныя LLM - танная генерацыя для шаблоннага коду.
  • Perplexity / Phind - хуткае тэхнічнае даследаванне і параўнанне падыходаў.
  • MCP (Model Context Protocol) - стандартызаваны доступ да файлаў/камандаў без «балбатні» ў промпце.
  • Commit message генератары (глядзіце таксама CommitGPT) - эканомяць час, але чытайце перад пушам.
  • ESLint з аўтафіксам - машынная гігіена «на ўваходзе».

Патэрны працы:

  • Triple Pass Review: структура -> логіка/паток даных -> краявыя выпадкі/бяспека.
  • Interface Freeze: замарозьце публічны API/параметры перад глыбокімі генерацыямі (рэфактарынгам).
  • Context Ledger: кароткія запісы па фічах (файлы, рашэнні, outstanding TODO) - лёгка перанесці ў новы чат.
  • Session Reset Cadence: рэгулярнае абнуленне доўгіх сесій.
  • Red Team Self-Check: асобны праход на ін’екцыі, IDOR, гонкі.

16. Cursor Rules, інструкцыі і «не баяцца вяртацца назад»

  • Cursor Rules - выдатная адпраўная кропка: зафіксуйце стэк, патэрны, забароны, анты-прыёмы.
  • Папка з інструкцыямі: прыклады кампанентаў, кароткія рэцэпты для тыпавых задач (замена «гарачай памяці» чата).
  • Калі мадэль збілася: вяртайцеся на крок назад, удакладняйце промпт і кантэкст - працягваць «па інэрцыі» даражэй.

17. Прадухіленне непажаданых змен ад ШІ — каротка

Паўтараем правіла з п.13: «Не дадавай/не выдаляй/не пераймяноўвай тое, пра што не прасіў». Ясныя межы лепшыя за эмацыйныя фразы — і працуюць стабільней.

18. Міні-чэкліст перад камітам

  • Функцыя ўпісаная ў існуючыя патэрны і кампаненты.
  • Тыпы строгія, без any; базавыя тэсты і логі прысутнічаюць.
  • Бяспека: сакрэты на сервэры; правы і валідацыя правераныя.
  • UI кансістэнтны: водступы, станы, назвы.
  • Паведамленне каміту кароткае і змястоўнае.

Карысныя знешнія рэсурсы

Ніжэй - толькі знешнія, публічныя крыніцы (сэрвісы і інструменты), якія даюць практычную вартасць пры «вайб»-падыходзе.

bolt.new
Што: онлайн-асяроддзе хуткага стварэння каркаса (Full‑stack / frontend) з генерацыяй пачатковага коду праз ШІ.
Навошта: імгненны MVP / протатып да таго, як укладвацца ў структуру асноўнага рэпазіторыю.
Калі: у фазе праверкі ідэі або пошуку агульнай формы без тонкай архітэктуры.

GitHub Copilot
Што: інструмент аўтадапаўнення і inline-падказак у рэдактара (VS Code, JetBrains).
Навошта: паскорыць шаблонны код (канфігурацыі, дапаможныя функцыі, невялікія React‑кампаненты), знізіць колькасць механічнага набору.
Калі: калі патрэбны хуткі «скетч» або дапаўненне радкоў, а не глыбокая шматфайлавая генерацыя логікі. (Але зараз ужо +- добра працуе і тут)

Claude Sonnet / мадэлі Anthropic
Што: мадэлі з моцным разуменнем кантэксту і больш менш дакладным вывадам.
Навошта: агляд вялікіх кавалкаў коду, прапановы па структуры, бяспецы, стылі.
Калі: перад рэфактарынгам, для пошуку дубляў або патэнцыйных уразлівасцяў.

Cursor
Што: IDE (форк VS Code) з глыбокай інтэграцыяй LLM (чат + генерацыя патчаў + «Rules»).
Навошта: кіраваныя промпты, лакальныя diff‑патчы, хуткія ітэрацыі без ручнога капіравання.
Калі: у асноўнай распрацоўцы, калі патрэбна шмат малых структурных змяненняў.

cursor.directory
Што: каталог гатовых Cursor Rules і промпт-шаблонаў.
Навошта: стартавы набор правілаў (стыль, архітэктура, ахоўныя абмежаванні) замест ручнога выпрацоўвання.
Калі: на этапе наладжвання «правілаў гульні» ў праекце.

Google AI Studio (Gemini 2.5 Pro)
Што: інтэрфейс да мадэляў з вялікім кантэкстным акном.
Навошта: комплексныя праверкі - бяспека, прадукцыйнасць, дублі, залежнасці; падсумаванне перад перабудовай.
Калі: калі код-база ўжо значная і патрэбны «стратэгічны прагляд».

21st.dev
Што: калекцыя UI-патэрнаў з прыкладнымі промптамі.
Навошта: уніфікаваць стылі і структуру кампанентаў без прыдумвання «з нуля».
Калі: перад маштабаваннем фронтэнду або стандартызацыяй форм / спісаў.

Sourcegraph Cody
Што: інтэлектуальны пошук па вялікіх рэпазіторыях + генерацыя патчаў.
Навошта: знайсці ўсе ўжыванні функцыі / залежнасці, пабудаваць карціну сувязяў перад зменамі.
Калі: перад глыбокім рэфактарынгам або выдаленнем модуля.

CodeSandbox
Што: хмарныя пясочніцы для імгненнага запуску прыкладання без лакальнай інсталяцыі.
Навошта: праверыць бібліятэку, пратэставаць ідэю, паказаць канцэпт калегам.
Калі: ранняя валідацыя або ізаляваная дэманстрацыя.

Storybook
Што: ізаляванае асяроддзе для прагляду і тэставання UI-кампанентаў.
Навошта: гарантаваць кансістэнтнасць дызайн-сістэмы, візуальны кантроль станаў (loading/empty/error).
Калі: у момант вылучэння агульных кампанентаў або перад маштабаваннем фронтэнду.

Playwright
Што: інструмент для E2E-тэстаў (браузерныя сцэнары з высокай дакладнасцю).
Навошта: праверыць ключавыя карыстальніцкія патокі пасля аўтаматычных патчаў ад ШІ.
Калі: перад merge важных змен або выпуском версіі.

Vitest
Што: хуткі юніт/інтэграцыйны тэстар для экосістэмы Vite / сучаснага TS.
Навошта: пакрыць чыстыя функцыі і hooks, каб стабілізаваць рэфактарынг.
Калі: адразу пасля вылучэння невялікіх утыліт / логікі ў асобныя модулі.

Perplexity
Што: LLM-пашукавікі з абагульняючымі адказамі і спасылкамі.
Навошта: імгненна даведацца нюансы API, статус бібліятэк, параўнаць падыходы.
Калі: перад выбарам стэка або аптымізацыяй.

LangSmith
Што: інструменты ацэнкі якасці інтэграцый LLM і промптаў.
Навошта: аб’ектыўна меркаваць, ці паляпшаецца вынік ад вашых правілаў/карэкціровак.
Калі: калі колькасць промптаў і мадэляў > 1 і патрабуецца кіраванне якасцю.

Regex101
Што: онлайн-адладчык рэгулярных выразаў з тлумачэннямі.
Навошта: хутка правяраць і правільна будаваць правілы валідацыі / парсінгу.
Калі: перад уключэннем складанай валідацыі ў форму / API.

Як эфектыўна спалучаць:

  1. Ідэя -> bolt.new (прататып) -> перанос у Cursor.
  2. Структура -> Sourcegraph (залежнасці) -> Claude (заўвагі) -> лакальныя патчы.
  3. UI -> 21st.dev (патэрн) + Storybook (прагляд) + Tailwind (стылі).
  4. Бяспека -> OWASP (чэкліст) + Gemini (аўдыт) + Playwright (патокі).
  5. Чысціня -> ESLint (правілы) + TypeScript (строгія тыпы) + Vitest (тэсты).

Паступова ўводзьце рэсурсы - не ўсе адразу: гэта зніжае кагнітыўную нагрузку і павялічвае стабільнасць працэсу.

Заключэнне: хуткасць з каркасам

Вайб-кодынг - гэта не хаос і не «мэта сама па сабе». Гэта цыкл «бачанне -> маленькі крок -> праверка -> стабілізацыя». Чым лепш бачанне і патэрны, тым больш ШІ становіцца партнёрам, а не крыніцай сюрпрызаў і праблем. Памылкі будуць, але з гэтым наборам вы не згубіцеся - проста працягнеце ітэраваць без болю.

Дзякуй за ўвагу

Дзякуй, што дачыталі. Спадзяюся, матэрыял будзе для вас карысны. Калі спадабалася — падтрымайце наш праект і падзяліцеся з калегамі.

ЗЫ: Выява ў шапцы спецыяльна крыху ўпоратая.

Vibe
AI
Admin, 2025-11-07

head

Goman.live - сэрвіс для лакалізацый і перакладаў пры дапамозе ШІ

Вітанкі ўсім!
Сёння я падрабязней распавяду пра ствараемы мной сэрвіс Goman.live - пра тое, што ён робіць, як працуе, каму можа быць карысны і куды мы з ім рухаемся далей.


Што такое Goman.live

У першую чаргу, Goman.live - гэта сэрвіс для кіравання лакалізацыямі і перакладамі пры дапамозе сучасных мадэляў штучнага інтэлекту.
Ён дапамагае падтрымліваць шматмоўныя вэб- і мабільныя прыкладанні, гульні, або проста перакладаць тэксты хутчэй і без лішняй руціны.

Сэрвіс працуе ў двух асноўных рэжымах:

  • праз MCP (Model Context Protocol) - калі хочацца ўсё рабіць праз агентаў у Copilot або Cursor,
  • і праз уласны рэдактар, дзе можна ўручную кіраваць лакалізацыямі, правяраць пераклады, дадаваць кантэкст і правілы.

Каму ён падыходзіць

Goman.live падыходзіць тым, хто працуе з кантэнтам і хоча зрабіць пераклад больш разумным і арганізаваным:

  • 👨‍💻 распрацоўшчыкам шматмоўных прыкладанняў;
  • 👩‍💼 камандам, што працуюць праз GitHub Copilot, Cursor або іншыя MCP-кліенты;
  • 🗣️ перакладчыкам і кантэнт-менеджарам, якім трэба хутка абнаўляць пераклады;
  • 🌐 усім, хто хоча мець пад рукой “разумны” рэдактар для лакалізацый.

Пра MCP

Кіраванне лакалізацыямі праз MCP дазваляе літаральна праз агентаў захоўваць, абнаўляць і выдаляць ключы і лакалізацыі.
Агенты ведаюць, якія мовы падтрымлівае ваш дадатак, і адразу ствараюць пераклады на ўсе гэтыя мовы.

Сэрвіс правярае, ці існуе запіс перад тым, як стварыць або змяніць яго - гэта дазваляе пазбегнуць дубляў і калізій.
Такі падыход вельмі спрашчае працу з кантэнтам і дазваляе хутка абнаўляць тэксты “на ляту”.

Адзінае, што пакуль патрабуе ўвагі - гэта празмерная генерацыя ключоў і перакладаў, якія не выкарыстоўваюцца.
Мы працуем над аўтаматычнай праверкай і выдаленнем такіх лакалізацый.
Але нават цяпер MCP-падыход робіць кіраванне лакалізацыямі хуткім і празрыстым.


editor

Пра рэдактар

Рэдактар - гэта другі важны інструмент у Goman.live.
Ён дазваляе не толькі ствараць новыя лакалізацыі, але і рэдагаваць ужо наяўныя, рабіць пераклады на некалькі моў адразу, шукаць памылкі, працаваць з кантэкстам і многае іншае.

Праз рэдактар можна перакладаць нават вялікія тэксты - з улікам кантэксту, праверкай памылак і магчымасцю захавання вынікаў.
Ён добра падыходзіць і для тэхнічных тэкстаў, і для звычайных.


languages

Падтрымліваемыя мовы

Поўнага спісу моў у сэрвісе няма - і гэта добра.
Мы выкарыстоўваем мадэлі, якія ўмеюць працаваць з дзясяткамі і сотнямі моў, таму абмежаванняў фактычна няма.
Якасць перакладу залежыць ад самога тэксту, ад распаўсюджанасці мовы і ад таго, ці ёсць падобныя пераклады ў вашай базе.

Пераклады праз рэдактар часта атрымліваюцца лепшыя, чым праз звычайныя інструменты, бо ўлічваецца кантэкст і папярэднія вынікі.
А калі вы працуеце праз MCP, якасць залежыць ад мадэлі, якую выкарыстоўвае ваш агент - напрыклад, Claude, GPT ці інш.


prompt

Пра кантэкст і промпты

Кантэкст - адна з самых важных частак у перакладзе.
У Goman.live можна выкарыстоўваць як папярэднія пераклады (RAG), так і ўласныя промпты, дзе вы самі задаяце правілы і абмежаванні.

Такі промпт можа замяніць “гласарый” - ён дапамагае мадэлі разумець ваш стыль, тэрміналогію і нават тон.
Промпты падтрымліваюць версіяніраванне, таму вы можаце захоўваць розныя варыянты і вяртацца да старых.

Акрамя таго, можна ствараць невялікія пашырэнні кантэксту непасрэдна ў рэдактары - калі, напрыклад, трэба ўдакладніць пераклад нейкага слова ці фразы.


mistakes

Праверка і выпраўленне памылак

Давайце пагаворым пра выпраўленне памылак
У Goman.live ёсць дзве простыя, але карысныя магчымасці працы з імі:

  1. Можна ўключыць аўтаматычную праверку пры перакладзе (чэкбокс “Use Syntax Check”) - пасля перакладу мадэль правярае тэкст і ўносіць выпраўленні самастойна.
  2. Або зрабіць ручную праверку ў рэдактары - усе падазроныя месцы падсвятляюцца, і вы можаце самі вырашыць, ці прымаць прапанаваныя змены.

Так што вы заўсёды трымаеце кантроль у сваіх руках.


Абмежаванні і асаблівасці

Паколькі сэрвіс працуе на LLM, ён мае свае асаблівасці.
Перш за ўсё - гэта памер кантэксту: мадэль можа апрацоўваць толькі пэўную колькасць інфармацыі за раз (у сярэднім каля 8–10 тысяч токенаў).
Калі тэкст занадта вялікі, яго лепш падзяліць на лагічныя часткі - так мадэль лепш разумее структуру і кантэкст, і пераклады выходзяць больш дакладнымі.

Пры выкарыстанні RAG кантэкст таксама можа быць непоўны - бо ў ім захоўваюцца асобныя кавалкі тэксту і пашук адбываецца па ім.
Таму лепш перакладаць невялікімі блокамі і пазбягаць перагрузу мадэлі.

Гэта не недахоп, а хутчэй асаблівасць працы LLM - яны проста павінны “разумець” тэкст у межах свайго кантэкстнага вакна.
Затое гэта дазваляе дасягаць стабільных вынікаў і лёгка апрацоўваць пераклады.


Дадатковы функцыянал

Goman.live - гэта не толькі лакалізацыі.
Сэрвіс дазваляе тэставаць промпты, глядзець вынікі, захоўваць іх у розных версіях і нават працаваць у камандзе. Больш дакладна гэта апісана ў дакументацыі сэрвісу


versions

Захоўванне промптаў і версіяніраванне

Вы можаце захоўваць да чатырох (пакуль чатырох) версій аднаго промпта і пераключацца паміж імі ў адзін клік.
Гэта вельмі зручна, калі хочаце эксперыментаваць з фармулёўкамі або правіламі перакладу. Версіянірванне промптаў пры належным карчстанні можа дазволіць значна паменьшыць разход токенаў. Таксама гэта можа быць карысна пры тэсціраванні і пошуку найбольш падыходзячых промптаў - у нас дададзена сістэма тэсціравання промптаў - можна адразу запускаць запыты на выкананне і атрымліваць вынікі.

Сумесная праца

Калі вы працуеце не адны - проста дадайце email калегі.
Ён атрымае доступ да вашага праекта, і вы зможаце разам працаваць над лакалізацыямі і перакладамі. Абмежаванні толькі па тарыфным плане. Токены пры перакладзе бяруцца з уліковага запісу ўласніка - то бок таго, хто "пашарыў"


Пра токены

Пры перакладзе праз рэдактар выкарыстоўваюцца LLM, таму ўлічваюцца токены - як уваходныя, так і выхадныя. Вынікі выкарыстозвання падлічваюцца пры запытах і абнаўляюцца праз кароткі час - звычайна адна дхьве хаіліны. Гэта неабходна для празрыстага коштаутварэння.
Калі ж вы працуеце праз MCP, токены увогуле не выкарыстоўваюцца - бо ўсё перакладаецца праз агента (Copilot, Cursor і г.д.).

Як эканоміць токены.

Адразу трэба адзначыць што такія функцыі як праверка і выпраўленне памылак патрабуюць дадатковых токенаў. Таксама токены могуць губляцца пры выкарыстанні завялікіх промптаў- Яны ж таксама пападаюць у мадэль.Таму часам лепш маніпуляваць некалькімі промптамі ці мець некалькі розных версій чым мець адзін вялікі.

Як атрымаць зніжку

У нас існуе рэферальная праграма: прывядзіце новага карыстальніка - і атрымаеце да 90% зніжкі на месяц.
Дробязь, але прыемна 🙂 . Таму калі вы зацікаўленыя - пішыце нам на емэйл.


Пра захаванне даных

Усе вашы даныя захоўваюцца на ўласных серверах.
Мы робім дамп кожныя 6 гадзін і не перадаем інфармацыю трэцім бакам апроч мадэлей (LLM), якія апрацоўваюць пераклады. Даныя пасля выдаленне аплікацыі могуць яшчэ некаторы час захоўвацца - зроблена для магчымасці па персанальным запыце усе ж аднавіць іх. Так сама вы у любы час можаце выгрузіць лакалізацыі у прапанаванай у сэрвісе форме. Загружаць даныя магчыма яз праз MCP, праз форму (па адным запісы) ці адразу шмат з файла у неабходным формаце.


Пра супрацу

Тут хацелася б адзначыць што мы адкрытыя да новых ідэй і супрацоўніцтва.
Калі ў вас ёсць сэрвіс ці бізнес, які можна інтэграваць з Goman.live - пішыце! Ці вас проста зацікавіла што-небудзь.
Мы гатовыя рабіць кастамныя планы, API-інтэграцыі і нават асобныя рашэнні пад вашыя патрэбы.


Што далей

Мы ўжо працуем над наступнымі рэчамі:

  • магчымасць выкарыстоўваць промпты напроста ў GitHub Copilot і Cursor,
  • выбар мадэлі перакладу ды выкарыстанне ўласных API-ключоў,
  • паляпшэнне RAG і аўтаматычнае абнаўленне лакалізацый,
  • і яшчэ шмат ідэй, якія зробяць працу з перакладамі яшчэ зручнейшай.

PS

Дзякуй вялікі, што дачыталі!
Буду вельмі ўдзячны за каментары, водгукі і прапановы.
Ваш фідбэк - гэта тое, што дапамагае сэрвісу развівацца і станавіцца лепшым.

👉 Заходзьце на goman.live - паглядзіце, як усё працуе на практыцы 🌍

AI
MCP
translations
Admin, 2025-11-02

Вітанкі! Сення невялікі гайд пра тое як наладзіць праект для працы з Github Copilot. Таксама не забудзьце азнаеміцца з папярэднімі артыкуламі:


Надзейны AI‑workflow з GitHub Copilot: поўны гайд з прыкладамі (2025)

Гэты гайд паказвае, як збудаваць прадказальныя і паўтаральныя AI‑працэсы (workflow) у вашым рэпазіторыі і IDE/CLI праз агентныя прымітывы (agentic primitives) і інжынерыю кантэксту (context engineering). Тут вы знойдзеце структуру файлаў, гатовыя шаблоны, правілы бяспекі і таксама каманды.

⚠️ Заўвага: функцыянал prompt‑файлаў і агентны рэжым у IDE/CLI можа змяняцца - прыстасоўвайце гайд да канкрэтнай версіі вашага Copilot і VS Code.


1) Абагульненне: з чаго складаецца workflow

Асноўная мэта - гэта раскласці працу агента на празрыстыя крокі і зрабіць іх кіраванымі. Для гэтага існуюць наступныя інструменты:

  • Custom Instructions (.github/copilot-instructions.md) - глабальныя правілы праекта (як збіраць, як тэставаць, стыль кода, палітыкі PR).
  • Path‑specific Instructions (.github/instructions/*.instructions.md) - даменныя правілы з таргетаваннем праз applyTo (glob‑шаблоны).
  • Chat Modes (.github/chatmodes/*.chatmode.md) - спецыялізаваныя рэжымы чату (напрыклад, Plan/Frontend/DBA) з фіксаванымі інструментамі і мадэллю.
  • Prompt Files (.github/prompts/*.prompt.md) - паўторныя сцэнары/«праграмы» для тыпавых задач (агляды, рэфактарынг, генерацыя).
  • Context helpers (docs/*.spec.md, docs/*.context.md, docs/*.memory.md) - спецыфікацыі, даведкі і памяць праекта для дакладнага кантэксту.
  • MCP servers (.vscode/mcp.j son або праз UI) - інструменты і знешнія рэсурсы, якімі можа карыстацца агент.

2) Файлавая структура праекту

Наступная структура адпавядае разгледжаным вышэй інструментам і дапамагае скласці паўнавартасны workflow для працы агентаў.

text
1.github/
2  copilot-instructions.md
3  instructions/
4    backend.instructions.md
5    frontend.instructions.md
6    actions.instructions.md
7  prompts/
8    implement-from-spec.prompt.md
9    security-review.prompt.md
10    refactor-slice.prompt.md
11    test-gen.prompt.md
12  chatmodes/
13    plan.chatmode.md
14    frontend.chatmode.md
15.vscode/
16  mcp.json
17docs/
18  feature.spec.md
19  project.context.md
20  project.memory.md

3) Файлы і іх прызначэнні - тэхнічнае тлумачэнне

А зараз разгледзім асобна кожны з інтсрументаў і іх ролю. Ніжэй - «як гэта ўладкавана пад капотам»: што за файлы, навошта яны, як яны ўплываюць на разуменне задачы агентам, і ў якім парадку аб’ядноўваюцца (merge/override). Код‑прыклады прадстаўленыя далей адпавядаюць спецыфікацыі.

Файл/папкаШто гэтаНавоштаДзе дзейнічае
.github/copilot-instructions.mdГлабальныя правілы праектаАднолькавыя стандарты для ўсіх адказаўУвесь рэпазіторый
.github/instructions/*.instructions.mdТаргетаваныя інструкцыі для пэўных шляхоўРозныя правілы для фронту/беку/CIТолькі для файлаў, што трапляюць пад applyTo
.github/chatmodes/*.chatmode.mdНабор правіл + дазволеных інструментаў для рэжыму чатуПадзяляць фазы працы (план/рэфактар/DBA)Калі выбраны гэты chat mode
.github/prompts/*.prompt.md«Сцэнар» задач (workflow)Паўторна запускаць тыпавыя працэсыКалі запускаецца праз /name або CLI
docs/*.spec.mdСпецыфікацыіДакладная пастаноўка задачыКалі вы іх @‑згадваеце ў дыялогу
docs/*.context.mdСталыя даведкіСкарочваць «шум» у чатахПа спасылцы/@‑згадцы
docs/*.memory.mdПамяць праектаФіксаваць рашэнні, каб не паўтарацьПа спасылцы/@‑згадцы
.vscode/mcp.jsonКанфіг MCP сервераўДоступ да GitHub/інш. інструментаўДля гэтага workspace

Парадак аб’яднання правіл і настроек: Prompt frontmatter → Chat mode → Repo/Path instructions → Defaults.


І так разгледзім зараз кожны інструмент паасобку.

3.1. Глабальныя правілы - .github/copilot-instructions.md

Што гэта: Markdown‑файл з кароткімі, правяраемымі правіламі: як збіраць, як тэставаць, стыль кода, палітыкі PR.

Навошта: Каб усе адказы апіраліся на адзіныя стандарты (без дублявання ў кожным prompt).

Як працуе: Файл аўтаматычна трапляе ў сістэмны кантэкст для ўсіх пытанняў у межах рэпазіторыя. Ніякіх applyTo (пра яго далей) - дзейнічае ўсюды.

Мінімальны прыклад:

md
1# Repository coding standards
2- Build: `npm ci && npm run build`
3- Tests: `npm run test` (coverage ≥ 80%)
4- Lint/Typecheck: `npm run lint && npm run typecheck`
5- Commits: Conventional Commits; keep PRs small and focused
6- Docs: update `CHANGELOG.md` in every release PR

Парады.

  1. Кароткія пункты;
  2. без агульных фраз;
  3. толькі тое, што можа паўплываць на вынік (build/test/lint/type/PR policy).

3.2. Таргетаваныя інструкцыі - .github/instructions/*.instructions.md

Што гэта: Модульныя правілы з YAML‑frontmatter applyTo - glob‑шаблоны файлаў, для якіх яны ўключаюцца.

Навошта: Адрозніваць стандарты для розных зон (frontend/backend/CI). Дазваляе кіраваць кантэкстам у залежнасці ад тыпу задачы.

Як працуе: Пры апрацоўцы задачы Copilot шукае ўсе *.instructions.md, чые applyTo супадаюць з актуальным кантэкстам (файлы, якія вы абмяркоўваеце/рэдагуеце). Супадаючыя правілы дадаюцца да глабальных.

Прыклад:

md
1---
2applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
3---
4- React: function components and hooks
5- State: Zustand; data fetching with TanStack Query
6- Styling: Tailwind CSS; avoid inline styles except dynamic cases
7- Testing: Vitest + Testing Library; avoid unstable snapshots

Увага.

  1. Не дубліруйце тое, што ўжо ёсць у глабальных правілах;
  2. правярайце, што glob сапраўды трапляе ў патрэбныя шляхі.

3.3. Chat modes - .github/chatmodes/*.chatmode.md

Што гэта: файлы‑канфігі, што задаюць аперацыйны рэжым агента для дыялогу: кароткае апісанне, мадэль (пры патрэбе) і спіс дазволеных інструментаў.

Навошта: каб аддзяліць фазы працы (планаванне/фронтэнд/DBA/бяспека) і абмежаваць інструменты у кожнай фазе. Так вынікі становяцца больш прадказальнымі.

Структура файла:

md
1---
2description: "Plan - analyze code/specs and propose a plan; read-only tools"
3model: GPT-4o
4tools: ['search', 'codebase']
5---
6In this mode:
7- Produce a structured plan with risks and unknowns
8- Do not edit files; output a concise task list instead

Як працуе:

  • Дзеянне chat mode распаўсюджваецца на бягучы чат у IDE.
  • Калі актывуеце prompt‑файл, яго frontmatter мае прыярытэт над chat mode (можа змяніць мадэль і звузіць tools).
  • Фактычна дазволеныя інструменты : (tools chat mode) / (tools prompt) / (CLI‑флагі --allow/--deny).

Кіраванне і пераключэнне:

  • У IDE (VS Code):

    1. Адкрыйце панэль Copilot Chat.
    2. У верхняй панэлі абярыце патрэбны chat mode з выпадаючага спісу (спіс збіраецца з .github/chatmodes/*.chatmode.md + убудаваныя рэжымы).
    3. Рэжым дзейнічае толькі для гэтага трэда. Каб змяніць - абярыце іншы або стварыце новы трэд з патрэбным рэжымам.
    4. Праверыць актыўны рэжым можна ў загалоўку/панэлі размовы і ў References (файл *.chatmode.md будзе пазначаны).
  • У CLI: *(неяк кастыльна, лепш праз промпты) *

    • Пераключальніка рэжыму як флага звычайна няма; энкодзьце патрэбныя абмежаванні ў frontmatter prompt‑файла і/або праз флагі --allow-tool/--deny-tool.
    • Можна даць інструкцыю ў першым радку: “Use the i18n chat mode.” - калі версія падтрымлівае, агент пераключыцца; калі не, frontmatter prompt усё роўна зафіксуе інструменты.
  • Без пераключэння рэжыму: запускайце prompt з патрэбным tools: у frontmatter - ён абмяжуе інструменты незалежна ад рэжыму чату.

Дыягностыка: калі агент выкарыстоўвае «лішнія» інструменты або не бачыць патрэбныя - праверце: (1) які chat mode выбраны; (2) tools у frontmatter prompt; (3) флагі --allow/--deny у CLI; (4) References у адказе (бачныя файлы *.chatmode.md/*.prompt.md).


3.4. Prompt files - .github/prompts/*.prompt.md

Што гэта: Файлы‑сцэнары для паўторных задач. Складаюцца з YAML‑frontmatter (канфіг) і цела (інструкцыі/крокі/критэрыі прыёмкі). Запускаюцца ў чаце як /name або праз CLI.

Калі выкарыстоўваць. Калі трэба зрабіць працэс прадказальным і аўтаматызаваным: агляд PR, генерацыя тэстаў, рэалізацыя фіч па спецыфікацыі і г.д.

Структура frontmatter

  • description - кароткая мэта сцэнару.
  • mode - ask (Q&A, без змен файлаў) · edit (лакальныя змены ў адкрытых файлах) · agent (шматкрокавы працэс з інструментамі).
  • model - жаданы мадэльны профіль.
  • tools - спіс дазволеных інструментаў для сцэнару (абмяжоўвае нават тое, што дазволіў chat mode).

Алгарытм выканання (паслядоўнасць)

  1. Дзе запускаем:

    • У чаце: у полі паведамлення ўводзіце /імя‑prompt і аргументы.
    • У CLI: выклікаеце copilot і перадаеце радок з /імя‑prompt … (інтэрактыўна або праз heredoc / флаг -p).
  2. Збор кантэксту: Copilot будуе схему выканання ў такім парадку: repo‑instructionspath‑instructions (applyTo)chat modefrontmatter prompt (мае найвышэйшы прыярытэт і можа звузіць інструменты/змяніць мадэль).

  3. Парсінг параметраў (дзе і як):

    • У чаце: параметры ідуць у тым жа паведамленні пасля назвы, напрыклад: /security-review prNumber=123 target=apps/web.
    • У CLI: параметры ідуць у тым жа радку /… у stdin або пасля флага -p.
    • Унутры prompt‑файла яны даступныя як ${input:імя}. Калі патрэбнага параметра няма - prompt можа запытаць яго тэкстава ў дыялогу.
  4. Вырашэнне дазволаў інструментаў:

    • Фактычна дазволеныя інструменты : (chat mode tools) / (prompt tools) /(CLI‑флагі --allow/--deny).
    • Калі інструмент забаронены, адпаведны крок пропускаецца або патрабуе пацвярджэння/змены палітык.
  5. Выканаўчыя крокі з цела prompt: агент ідзе строга па парадку Steps, робячы толькі тое, што дазволена палітыкамі/інструментамі (пошук у кодзе, генерацыя diff, запуск тэстаў і г.д.). Для патэнцыйна рызыковых дзеянняў просіцца пацвярджэнне.

  6. Validation gates: у канцы prompt запускае праверкі (build/tests/lint/typecheck, праверка фармату выхаду). Калі gate не пройдзены - вяртаецца спіс праблем і прапанова наступных крокаў (без аўта‑мерджа/запісаў).

  7. Дзе з'яўляецца вынік (што і дзе бачым):

    • Асноўны адказ - у панэлі чату (IDE) або ў stdout (CLI): табліцы, спісы, тэкставыя справаздачы, code blocks з diff.
    • Змены ў файлах - у вашым working tree: у IDE бачыце diff/тыповыя прапанаваныя патчы; у CLI - файлы змяняюцца лакальна (калі гэта дазволена інструментамі).
    • Дадатковыя артыфакты - напрыклад, каментар у PR, калі дазволены інструменты GitHub і так прапісана ў prompt.

Выніковы фармат і праверкі (рэкамендавана)

  • Абавязкова задавайце фармат выхаду (напрыклад, табліца «issue | file | line | severity | fix»).
  • Дадайце validation gates: build/tests/lint/typecheck; патрабаванне unified‑diff для прапанаваных змен; TODO‑спіс на вырашэнне спрэчных пытанняў.

Прыклад поўнага prompt‑файла

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implement a feature from a spec'
6---
7Goal: Implement the feature described in @docs/feature.spec.md.
8
9Steps:
101) Read @docs/feature.spec.md and produce a short implementation plan (bullets)
112) List files to add/modify with paths
123) Propose code patches as unified diff; ask before installing new deps
134) Generate minimal tests and run them (report results)
14
15Validation gates:
16- Build, tests, lint/typecheck must pass
17- Output includes the final diff and a TODO list for anything deferred
18- If any gate fails, return a remediation plan instead of "done"

Анты‑патэрны

  • «Вада» ў апісанні: трымайце description 1–2 радкі.
  • Адсутнасць фармату выніку.
  • Празмерная колькасць інструментаў: дазваляйце толькі патрэбныя (tools).

Хуткі запуск

  • Чат: /implement-from-spec
  • CLI: copilot <<<'/implement-from-spec' або copilot -p "Запусці /implement-from-spec"

3.5. Кантэкст‑файлы - specs/context/memory

Што гэта: Дапаможныя Markdown‑файлы (не спецыяльныя тыпы), якія вы @‑згадваеце ў дыялогу/прампце. Звычайна размешчаны як дакументацыя.

  • docs/*.spec.md - дакладная пастаноўка (goal, acceptance, edge cases, non‑goals).
  • docs/*.context.md - кароткія даведкі (API policies, security, UI styleguide, SLA).
  • docs/*.memory.md - «журнал рашэнняў» з датамі і прычынамі, каб agent не вяртаўся да старых спрэчак.

Прыклад:

md
1# Feature: Export report to CSV
2Goal: Users can export the filtered table to CSV.
3Acceptance criteria:
4- "Export CSV" button on /reports
5- Server generates file ≤ 5s for 10k rows
6- Column order/headers match UI; locale-independent values
7Edge cases: empty values, large numbers, special characters
8Non-goals: XLSX, multi-column simultaneous filters

3.6. MCP - .vscode/mcp.json

Што гэта: Канфігурацыя Model Context Protocol сервераў (напрыклад, GitHub MCP), якія адкрываюць інструменты для агента. Мы разглядалі гэта раней у артыкуле Ствараем свой першы MCP-сервер

Навошта: Каб агент мог чытаць PR/issues, запускаць тэсты, працаваць з БД/браузерам - у межах дазволаў.

Прыклад:

json
1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Бяспека. Падлучайце толькі давераныя серверы; выкарыстоўвайце allow/deny‑спісы інструментаў у prompt/chat mode/CLI.


3.7. Агульны парадак аб’яднання кантэксту і прыярытэтаў (rules & tools)

  1. Instructions: copilot-instructions + усе *.instructions.md з applyTo, якія супалі з актуальнымі шляхамі. Канкрэтная інструкцыя дадаецца да агульнага кантэксту.
  2. Chat mode: абмяжоўвае набор інструментаў і (пры патрэбе) мадэль для сесіі.
  3. Prompt frontmatter: мае найвышэйшы прыярытэт; можа абмежаваць інструменты і перазапісаць мадэль.
  4. Кантэкст: тое, што вы @‑згадаеце, гарантавана трапіць ва ўвагу мадэлі.

Дыягностыка. Правярайце ў выдачы раздзел References - там бачна, якія файлы інструкцый былі ўлічаныя і які prompt быў запушчаны.

3.8. Прыклад - поўны i18n‑цыкл з Goman MCP (стварэнне/абнаўленне/ачыстка)

Ніжэй - дакладны працэс і шаблоны, як гарантаваць: (а) пры стварэнні UI‑кампанентаў ключы лакалізацыі ствараюцца/абнаўляюцца ў Goman; (б) пры выдаленні кампанентаў - выяўляюцца і (пасля пацвярджэння) выдаляюцца непатрэбныя запісы.

Код‑фрагменты і frontmatter - англійскай, па дыяпазоне дакументацыі.

3.8.1. MCP канфіг - падключаем Goman

/.vscode/mcp.json

json
1{
2  "servers": {
3    "goman-mcp": {
4      "type": "http",
5      "url": "https://mcp.goman.live/mcp",
6      "headers": {
7        "apiKey": "<YOUR_API_KEY>",
8        "applicationid": "<YOUR_APPLICATION_ID>"
9      }
10    }
11  }
12}

3.8.2. Repo/Path‑правілы - прымушаем i18n па змаўчанні

/.github/instructions/frontend.instructions.md (дапаўненне)

md
1---
2applyTo: "apps/web/**/*.{ts,tsx}"
3---
4- All user‑facing strings **must** use i18n keys (no hardcoded text in JSX/TSX)
5- Key naming: `<ui_component_area>.<name>` (e.g., `ui_button_primary.label`)
6- When creating components, run `/i18n-component-scaffold` and commit both code and created keys
7- When deleting components, run `/i18n-prune` and confirm removal of unused keys

3.8.3. Chat mode - абмежаваны набор інструментаў i18n

/.github/chatmodes/i18n.chatmode.md

md
1---
2description: "i18n - manage localization keys via Goman MCP; enforce no hardcoded strings"
3model: GPT-4o
4tools: ["files","goman-mcp:*"]
5---
6In this mode, prefer:
7- Creating/updating keys in Goman before writing code
8- Checking for existing keys and reusing them
9- Producing a table of changes (created/updated/skipped)

3.8.4. Prompt - стварэнне кампанента + ключы ў Goman

/.github/prompts/i18n-component-scaffold.prompt.md

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Scaffold a React component with i18n keys synced to Goman'
6---
7Inputs: componentName, namespace (e.g., `ui.button`), path (e.g., `apps/web/src/components`)
8
9Goal: Create a React component and ensure all user‑visible strings use i18n keys stored in Goman.
10
11Steps:
121) Plan the component structure and list all user‑visible strings
132) For each string, propose a key under `${namespace}`; reuse if it exists
143) Using Goman MCP, create/update translations for languages: en, be, ru (values may be placeholders)
154) Generate the component using `t('<key>')` and export it; add a basic test
165) Output a Markdown table: key | en | be | ru | action(created/updated/reused)
17
18Validation gates:
19- No hardcoded literals in the produced .tsx
20- Confirm Goman actions succeeded (report tool responses)
21- Tests and typecheck pass

Прыклад кода кампанента:

tsx
1import { t } from '@/i18n';
2import React from 'react';
3
4type Props = { onClick?: () => void };
5
6export function PrimaryButton({ onClick }: Props) {
7  return (
8    <button aria-label={t('ui.button.primary.aria')} onClick={onClick}>
9      {t('ui.button.primary.label')}
10    </button>
11  );
12}

3.8.5. Prompt - ачысціць непатрэбныя ключы пры выдаленні

/.github/prompts/i18n-prune.prompt.md

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Find and prune unused localization keys in Goman after code deletions'
6---
7Inputs: pathOrDiff (e.g., a deleted component path or a PR number)
8
9Goal: Detect keys that are no longer referenced in the codebase and remove them from Goman after confirmation.
10
11Steps:
121) Compute the set of removed/renamed UI elements (scan git diff or provided paths)
132) Infer candidate keys by namespace (e.g., `ui.<component>.*`) and check code references
143) For keys with **zero** references, ask for confirmation and delete them via Goman MCP
154) Produce a Markdown table: key | status(kept/deleted) | reason | notes
16
17Validation gates:
18- Never delete keys that still have references
19- Require explicit confirmation before deletion
20- Provide a rollback list of deleted keys

3.8.6. Prompt - сінхранізацыя і праверка прапушчаных лакалізацый (апцыянальна)

/.github/prompts/i18n-sync.prompt.md

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Sync new/changed i18n keys and check for missing translations'
6---
7Goal: Compare code references vs Goman and fill gaps.
8
9Steps:
101) Scan code for `t('...')` keys under provided namespaces
112) For missing keys in Goman - create them (placeholder text ok)
123) For missing languages - create placeholders and report coverage
134) Output coverage table: key | en | be | de | missing

4) Як гэтым карыстацца (IDE і CLI)

4.1. У VS Code / іншай IDE

  • Адкрыйце Copilot Chat - выберыце Agent/Edit/Ask у выпадаючым меню.
  • Для prompt‑файлаў проста набярыце /назва‑файла без пашырэння (напр. /security-review).
  • Дадавайце кантэкст з дапамогай @‑згадвання файлаў і каталогаў.
  • Пераключайце chat mode (Plan/Frontend/DBA), калі задача змянілася.

4.2. У Copilot CLI (тэрмінал)

  • Усталёўка (прыклад): npm install -g @github/copilot → запусціце copilot.
  • Інтэрактыўна: «Запусці /implement-from-spec па @docs/feature.spec.md».
  • Праграмна/у CI: copilot -p "Рэалізуй фічу з @docs/feature.spec.md" --deny-tool shell("rm *").
  • Дадайце/абмяжуйце інструменты флагамі: --allow-all-tools, --allow-tool, --deny-tool (глабальныя або па шаблонах, напр. shell(npm run test:*)).

4.3. Cookbook каманд для CLI (chat modes і prompts)

Ніжэй - гатовыя рэцэпты. Усе каманды выконваюцца ў карані праекта і падтрымліваюць вашыя deny/allow‑спісы.

A. Запусціць prompt‑файл у інтэрактыўнай сесіі

bash
1copilot
2# унутры сесіі (радок уводзіцца як ёсць)
3/security-review prNumber=123

B. Запусціць prompt‑файл неінтэрактыўна (heredoc)

bash
1copilot <<'EOF'
2/security-review prNumber=123
3EOF

C. Перадаць параметры prompt‑файлу

bash
1copilot <<'EOF'
2/implement-from-spec path=@docs/feature.spec.md target=apps/web
3EOF

Унутры prompt можна чытаць значэнні праз ${input:target} і ${input:path}.

D. Запусціць prompt з бяспечнымі дазволамі інструментаў

bash
1copilot --allow-tool "shell(npm run test:*)" \
2        --deny-tool  "shell(rm*)" \
3        <<'EOF'
4/security-review prNumber=123
5EOF

E. Выкарыстаць chat mode (спецыялізаваны рэжым) у CLI

bash
1copilot
2# унутры сесіі - папрасіце перайсці ў патрэбны рэжым і запусціце prompt
3Use the i18n chat mode.
4/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components

Калі ваш кліент падтрымлівае выбар рэжыму праз меню - абярыце i18n перад запускам prompt. Калі не - пазначайце абмежаванні ў самым prompt (frontmatter tools і правілы ў целе файла).

F. Адправіць спасылкі на файлы/дыфы як кантэкст

bash
1copilot <<'EOF'
2Please review these changes:
3@apps/web/src/components/PrimaryButton.tsx
4@docs/feature.spec.md
5/security-review prNumber=123
6EOF

G. Змяніць мадэль для канкрэтнага запуску

Рэкамендуем указваць мадэль у frontmatter prompt‑файла. Калі падтрымліваецца флаг, можна вызначыць мадэль пры запуску:

bash
1copilot --model GPT-4o <<'EOF'
2/implement-from-spec
3EOF

H. i18n‑цыкл з Goman MCP (CHAT)

У чат‑трэды запускайце паслядоўна:

text
1/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components
2/i18n-prune pathOrDiff=@last-diff
3/i18n-sync namespace=ui.button

Што атрымаеце:

  • выніковыя табліцы/справаздачы - у панэлі чату;
  • змяненні кода - у вашым working tree (IDE пакажа diff);
  • ніякіх CLI‑камандаў для Goman MCP тут не патрабуецца.

5) Інжынерыя кантэксту: як не «заліваць» лішняе

  1. Дзяліце сесіі па фазах: План → Рэалізацыя → Агляд/Тэсты. У кожнай - свой Chat Mode.
  2. Падключайце толькі патрэбныя інструкцыі: праз path‑specific *.instructions.md замест «усё ў кучы».
  3. Памяць праекта: рабіце кароткія ADR у project.memory.md - гэта зніжае «забыццё» агента паміж задачамі.
  4. Кантэкст‑хэлперы: частыя даведкі (API/бяспека/UI) трымайце ў *.context.md і спасылайцеся на іх з prompt‑файлаў.
  5. Канцэнтрацыя на задачы: у prompt‑файлах заўсёды пішыце мэту, крокі і фармат выніку (табліца, diff, чэк‑ліст).

6) Бяспека і кіраванне інструментамі

  • Яўнае пацвярджэнне запуску камандаў/інструментаў. У CLI выкарыстоўвайце --deny-tool па змаўчанні і дадавайце лакальныя allow‑спісы.
  • Патэрны дазволаў: дазвольце толькі тое, што трэба (shell(npm run test:*), playwright:*), забараніце небяспечнае (shell(rm*)).
  • Сакрэты: ніколі не кладзіце ключы ў prompt/інструкцыі; карыстайцеся GitHub Environments або .env з .gitignore.
  • Любы MCP - толькі з давераных крыніц; аглядайце код/канфіг перад уключэннем.
  • Праверка патчаў: у prompt‑файлах патрабуйце unified‑diff і тлумачэнні - гэта спросціць рэўю.

7) CI/CD рэцэпт (апцыянальны прыклад)

Пацвярджанне, што «ўсё збіраецца»: запускаем Copilot CLI ў «сухім» рэжыме, каб атрымаць каментар да PR.

yaml
1# .github/workflows/ai-review.yml
2name: AI Review (Copilot CLI)
3on:
4  pull_request:
5    types: [opened, synchronize, reopened]
6
7jobs:
8  ai_review:
9    runs-on: ubuntu-latest
10    permissions:
11      contents: read
12      pull-requests: write
13    steps:
14      - uses: actions/checkout@v4
15      - uses: actions/setup-node@v4
16        with:
17          node-version: 22
18      - name: Install Copilot CLI
19        run: npm install -g @github/copilot
20      - name: Run security review prompt (no dangerous tools)
21        env:
22          PR: ${{ github.event.pull_request.number }}
23        run: |
24          copilot -p "Запусці /security-review з prNumber=${PR}" \
25            --deny-tool shell("rm*") --deny-tool shell("curl*") \
26            --allow-tool shell("npm run test:*") \
27            --allow-tool "github:*" \
28            > ai-review.txt || true
29      - name: Comment PR with results
30        if: always()
31        run: |
32          gh pr comment ${{ github.event.pull_request.number }} --body-file ai-review.txt

Парада: захоўвайце строгія deny/allow‑спісы; не давайце агенту «поўнай свабоды» ў CI.


8) невялікія сцэнары і парады якія могуць спатрэбіцца

  • З ідэі да PR: /plan - абмеркаванне плана - /implement-from-spec → лакальныя тэсты - PR - /security-review.
  • Падтрымка: /refactor-slice для лакальных паляпшэнняў без змен паводзінаў.
  • Тэсты: /test-gen на новыя модулі + ручное дапаўненне гранічных сцэнарыяў.
  • Паступовае ўвядзенне: пачынайце з 1–2 prompt‑файлаў і аднаго chat‑mode; далей пашырайце.

9) Праверкі якасці (validation gates)

У кожным prompt‑файле зафіксуйце «што лічыцца гатовым»:

  • Фармат выхаду: табліца рызыкаў, unified‑diff, чэк‑ліст.
  • Аўтаматычныя праверкі: build, unit/integration‑тэсты, lint/typecheck.
  • Мануальная праверка: «OK to merge?» з аргументацыяй і residual‑рызыкамі.

10) Анты‑патэрны і лайфхакі

  • Анты‑патэрн: адзін велізарны instructions.md. Лепш замяніце на некалькі *.instructions.md з applyTo.
  • Анты‑патэрн: агульныя словы замест правілаў. Лепш пішыце канкрэтныя каманды/крокі.
  • Анты‑патэрн: запуск небяспечных shell‑каманд без gate. Карыстайцеся deny/allow і ручным пацвярджэннем.
  • Анты‑патэрн: «забыліся» пра specs/memory. Вядзіце feature.spec.md і project.memory.md.
  • Анты‑патэрн: змешванне задач у адной сесіі. Пад кожную фазу стварайце свой Chat Mode.

11) Чэк‑ліст імплементацыі

  1. Дадайце .github/copilot-instructions.md (мінімум 5–8 булшытаў пра зборку/тэсты/стыль).
  2. Стварыце 1–2 *.instructions.md з applyTo (frontend/backend або workflows).
  3. Дадайце plan.chatmode.md і адзін prompt (напрыклад, implement-from-spec.prompt.md).
  4. Стварыце docs/feature.spec.md і docs/project.memory.md.
  5. Уключыце MCP (GitHub MCP як мінімум) праз .vscode/mcp.json.
  6. Запусціце workflow у VS Code: /implement-from-spec - праверка - PR.
  7. (Апцыянальна) Дадайце просты AI‑агляд у CI праз Copilot CLI з жорсткім deny/allow‑спісам.

12) Пытанні і адказы (FAQ)

Q: Як пераканацца, што Copilot «бачыць» мае інструкцыі? A: У адказах глядзіце рэзюмэ/References; акрамя таго, трымайце правілы кароткімі і канкрэтнымі.

Q: Ці можна дынамічна перадаваць параметры ў prompt‑файл? A: Так, звычайна праз падстаўныя зменныя (кшталту ${prNumber}) або проста праз тэкст запыту пры запуску /prompt у чаце.

Q: Дзе лепш захоўваць сакрэты для MCP? A: У Environments GitHub або ў лакальных сакрэт‑менеджарах; не ў .prompt.md/.instructions.md.

Q: Што выбраць: Chat Mode vs Prompt File? A: Chat Mode задае «раму» (мадэль/інструменты/роля). Prompt File - «сцэнар» у гэтай раме.


13) Далейшыя крокі

  • Дадайце другі prompt для вашага найбольш частага «ручнога» працэсу.
  • Увядзіце project.memory.md як абавязковы пункт пасля ўсіх архітэктурных рашэнняў.
  • Паступова пераносьце калектыўныя веды ў *.context.md і спасылайцеся на іх з prompt‑файлаў.

Appendix A - Quickstart templates

All keys, paths, and flags match the docs (Oct 28, 2025).

/.github/copilot-instructions.md - repository-wide rules

md
1# Repository coding standards
2- Build: `npm ci && npm run build`
3- Tests: `npm run test` (coverage ≥ 80%)
4- Lint/Typecheck: `npm run lint && npm run typecheck`
5- Commits: Conventional Commits; keep PRs small and focused
6- Docs: update `CHANGELOG.md` in every release PR

/.github/instructions/frontend.instructions.md - path‑specific rules

md
1---
2applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
3---
4- React: function components and hooks
5- State: Zustand; data fetching with TanStack Query
6- Styling: Tailwind CSS; avoid inline styles except dynamic cases
7- Testing: Vitest + Testing Library; avoid unstable snapshots

/.github/instructions/backend.instructions.md - path‑specific rules

md
1---
2applyTo: "services/api/**/*.{ts,js},packages/server/**/*.{ts,js}"
3---
4- HTTP: Fastify; version APIs under `/v{N}`
5- DB access: Prisma; migrations via `prisma migrate`
6- Security: schema validation (zod), rate limits, audit logs
7- Testing: integration tests via `vitest --config vitest.integration.ts`

/.github/instructions/actions.instructions.md - GitHub Actions

md
1---
2applyTo: ".github/workflows/**/*.yml"
3---
4- Keep jobs small; reuse via composite actions
5- Cache: `actions/setup-node` + built-in cache for npm/pnpm
6- Secrets: only through GitHub Environments; never hardcode

/.github/chatmodes/plan.chatmode.md - custom chat mode

md
1---
2description: "Plan - analyze code/specs and propose a plan; read-only tools"
3model: GPT-4o
4tools:
5  - "search/codebase"
6---
7In this mode:
8- Produce a structured plan with risks and unknowns
9- Do not edit files; output a concise task list instead

/.github/prompts/security-review.prompt.md - prompt file

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Perform a security review of a pull request'
6---
7Goal: Review PR ${input:prNumber} for common security issues.
8
9Checklist:
10- Authentication/authorization coverage
11- Input validation and output encoding (XSS/SQLi)
12- Secret management and configuration
13- Dependency versions and known CVEs
14
15Output:
16- A Markdown table: issue | file | line | severity | fix
17- If trivial, include a unified diff suggestion

/.github/prompts/implement-from-spec.prompt.md - prompt file

md
1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implement a feature from a spec'
6---
7Your task is to implement the feature described in @docs/feature.spec.md.
8
9Steps:
101) Read @docs/feature.spec.md and summarize the plan
112) List files to add or modify
123) Propose code changes; ask before installing new dependencies
134) Generate minimal tests and run them
14
15Validation gates:
16- Build, tests, lint/typecheck must pass
17- Provide a TODO list for anything deferred

/.github/prompts/refactor-slice.prompt.md - prompt file

md
1---
2mode: 'agent'
3model: GPT-4o
4description: 'Refactor a specific code slice without changing behavior'
5---
6Goal: Improve readability and reduce side effects in @src/feature/* while keeping behavior unchanged.
7Criteria: fewer side effects, clearer structure, all tests pass.

/.github/prompts/test-gen.prompt.md - prompt file

md
1---
2mode: 'agent'
3model: GPT-4o-mini
4description: 'Generate tests for a given file/module'
5---
6Ask the user to @-mention the target file; generate unit/integration tests and edge cases.

/docs/feature.spec.md - spec skeleton

md
1# Feature: Export report to CSV
2Goal: Users can export the filtered table to CSV.
3Acceptance criteria:
4- "Export CSV" button on /reports
5- Server generates file ≤ 5s for 10k rows
6- Column order/headers match UI; locale-independent values
7Edge cases: empty values, large numbers, special characters
8Non-goals: XLSX, multi-column simultaneous filters

/.vscode/mcp.json - minimal MCP config

json
1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Appendix B - Operational extras (CLI & CI examples)

These examples complement Appendix A; they cover runtime/automation usage and do not duplicate templates above.

Copilot CLI - safe tool permissions (interactive/CI)

bash
1# Start an interactive session in your repo
2copilot
3
4# Allow/deny specific tools (exact flags per GitHub docs)
5copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)"
6
7# Run a prompt file non-interactively (example)
8copilot <<'EOF'
9/security-review prNumber=123
10EOF

GitHub Actions - comment review results on a PR

yaml
1name: AI Security Review (Copilot CLI)
2on:
3  pull_request:
4    types: [opened, synchronize, reopened]
5
6jobs:
7  review:
8    runs-on: ubuntu-latest
9    permissions:
10      contents: read
11      pull-requests: write
12    steps:
13      - uses: actions/checkout@v4
14      - uses: actions/setup-node@v4
15        with:
16          node-version: 22
17      - name: Install Copilot CLI
18        run: npm install -g @github/copilot
19      - name: Run security review prompt
20        env:
21          PR: ${{ github.event.pull_request.number }}
22        run: |
23          copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)" <<'EOF'
24          /security-review prNumber=${PR}
25          EOF
26      - name: Post results
27        run: |
28          gh pr comment ${{ github.event.pull_request.number }} --body "Copilot review completed. See artifacts/logs for details."

Крыніцы

Custom chat modes in VS Code

Use MCP servers in VS Code

Adding repository custom instructions for GitHub Copilot

How to build reliable AI workflows with agentic primitives and context engineering

🙌 PS:

Дзякуй, што дачытаў(-ла) да канца! Калі матэрыял быў карысны - будзем вельмі рады, калі:

  • 💬 Напішаш каментар ці пытанне,
  • 📨 Падкінеш ідэю для наступнага артыкула,
  • 🚀 Або проста падзелішся з сябрамі!

Тэхналогіі становяцца бліжэй, калі іх разумець. І ты ўжо зрабіў(ла) першы важны крок 💪

Да сустрэчы ў наступным артыкуле! Дзякуй вам за падтрымку!

AI
Copilot
Admin, 2025-10-28

goman

Прывітанне, спадарства!

Як вы, напэўна, заўважылі, апошнім часам я стаў менш пісаць артыкулаў, а ўвогуле мая актыўнасць крыху спала.

Дык вось — увесь гэты час я працаваў над уласным праектам, прызначаным для кіравання лакалізацыямі і перакладамі. І сёння хачу крыху распавесці пра яго.

Што гэта за сэрвіс і навошта ён патрэбны

Ужо даўно я займаюся распрацоўкай і часта сутыкаюся з патрэбай падтрымкі шматлікіх лакалізацый і моваў. Звычайна гэта выглядала так: у кодзе ўручную прапісваліся ключы, а ў файлы лакалізацыі дадаваліся пераклады. Гэта заўсёды займала шмат часу і высілкаў.

Таму я вырашыў стварыць уласны сэрвіс, які дазваляе кіраваць лакалізацыямі і кантэнтам непасрэдна праз VS Code, Cursor. На дадзены момант ўжо атрымалася зрабіць так, што агенты (Copilot і іншыя) праз MCP могуць падключацца да сэрвісу, і дадаваць, выдаляць, рэдактаваць лакалізацыі

Сам сэрвіс не абмежаваны MCP: ён таксама падтрымлівае ШІ-пераклад, рэдагаванне і іншыя функцыі.


ШІ-перакладчык

ШІ-перакладчык дазваляе генераваць пераклады з улікам загадзя падрыхтаваных промптаў, што значна паляпшае якасць выніку. Акрамя таго, сэрвіс можа ўлічваць папярэднія пераклады пры стварэнні новых — гэта бывае вельмі карысна. Промпты падтрымліваюць версіяніраванне, і іх можна пераключаць перад выкарыстаннем.

Экспарт і сумесная праца

Усе створаныя пераклады можна выгрузіць у фармаце JSON у розных структурах (якія можна выбраць перад спампоўкай). Сэрвіс дазваляе працаваць над лакалізацыямі некалькім карыстальнікам адначасова, дзяліцца доступам з іншымі членамі каманды.

Дадатковыя магчымасці

Акрамя лакалізацый, сэрвіс мае просты мэнэджар промптаў і SDK, які дазваляе запускаць аддалена розныя мадэлі і сэрвісы, а таксама назіраць вынікі. Але пра гэта будзе асобны артыкул.

Пра бэкапы

Зараз у распрацоўцы магчымасць версіяніравання лакалізацый, каб іх можна было аднавіць у выпадку праблем. Але ўжо цяпер сервер кожныя 6 гадзін робіць бэкапы базы дадзеных, якія захоўваюцца цягам аднаго тыдня.

Пра бэта-тэставанне і далейшае развіццё

Зараз сэрвіс знаходзіцца на стадыі бэта-тэставання. Мы запрашаем усіх жадаючых далучыцца, паспрабаваць яго ў працы і падзяліцца сваімі ўражаннямі.

Асабліва важная для нас ваша зваротная сувязь: усе слушныя парады і пажаданні будуць уважліва разгледжаныя і ўлічаныя ў далейшай распрацоўцы.

У будучыні будуць розныя тарыфныя планы, але пакуль галоўная мэта — атрымаць водгукі, зрабіць сэрвіс зручным і карысным для супольнасці.

Пра планы

У бліжэйшы час я планую больш шчыльна працаваць над магчымасцямі ШІ-перакладу. Будзе дададзена падтрымка новых рэдактараў, акрамя Cursor і VS Code. З’явіцца функцыя нататак — яны будуць даступныя ўсім, хто працуе над перакладамі.

Для беларускамоўнай супольнасці

Таксама я планую рабіць добрыя зніжкі для беларускамоўнага кам’юніці. Вы заўсёды можаце звярнуцца за зніжкай або павелічэннем лімітаў.

📩 Звязацца з намі можна праз пошту goman.live.service@gmail.com

💬 Або далучайцеся да нашага Discord-сервера

Ну і першае невялікае прома пра тое як працуе MCP разам з сэрвісам

AI
ШІ
Admin, 2025-09-25

header

Вітанкі!

Я ўжо больш за месяц як пачаў пісаць гэты артыкул , але то часу няма, то настрою. Але ўсё ж я сабраўся з думкамі і нарэшце нешта зляпіў. Спадзяюся вам будзе карысна. Зьвярніце ўвагу на гітхаб - там ужо гатовыя працуючыя прыклады, якія можна запускаць. Для лепшага разумення што адбываецца - азнаемцеся з структурай і кодам MCP сервера

Сёння мы падключаем Cursor і VS Code да вашых API праз MCP.

Часам глядзіш на ўласныя карысныя скрыпты і думаеш: «Як акуратна, без лішняй мукі падключыць іх да ШІ? Што для гэтага трэба? З якога боку падысці?». І вось сёння ў гэтым артыкуле мы паспрабуем вырашыць гэтую праблему і навучыцца ствараць уласныя MCP.

Ну і можаце глянуць мае папярэднія артыкулы пра ШІ


MCP у двух словах

MCP (Model Context Protocol) - уніфікаваны «перакладчык» паміж вашымі інструментамі і разумнымі кліентамі (чат-асістэнтамі, напрыклад агентамі ў Cursor). Замест чарговага разрозненага API вы дакладна апісваеце, што ўмее ваш інструмент і якія ў яго ўваходы/выхады - далей усё працуе па стандарце.

Чым MCP зручны

Асноўная ідэя MCP у тым, што ваша API можа быць падлучана да мадэлі як асобны агент з празрыстымі правіламі:

  • Стандартызацыя. Адзіная мова для інструментаў і кліентаў замест набора разнастайных пратаколаў.
  • Кіраванасць. Падлучаныя да мадэлі інструменты маюць яўныя схемы, прадказальныя паводзіны, выразныя правы.
  • Хуткая інтэграцыя. Падключылі API/FS/БД/DevOps-працэсы - і карыстаецеся з IDE або з чата.

Дзе MCP асабліва дарэчны

MCP падыходзіць для розных задач, найчасцей звязаных з распрацоўкай (цяпер найперш рэдактары адаптаваныя для працы з вонкавымі інструментамі праз MCP). Напрыклад:

  • DevTools і ChatOps: CI/CD-каманды, дыягностыка, доступ да логаў.
  • Data/BI: агрэгаваныя запыты, разумныя зводкі.
  • Унутраныя API: адзіная кантрольная кропка для каманды.
  • RAG/аўтаматызацыя: збор, перад-/пасляапрацоўка дадзеных.
  • Праца з дакументацыяй (напрыклад, Confluence) і інш.

Спіс прапанаваных MCP для VS Code: github


Як зрабіць просты MCP-сервер з HTTP-транспартам (Bun/Node)

Вернемся да стварэння нашага сервера. Я ўжо падрыхтаваў некалькі прыкладаў інструментаў у навучальным рэпазіторыі; азнаёміцца з імі можна па спасылцы lesson8_mcp/mcp_server у рэпазіторыі bel_geek. Код сумяшчальны з Bun і Node.js.

Што збудуем

Створым просты сервер без лішніх «наваротаў». Гэта будзе лакальны HTTP-сервер з /healthz і /mcp, без стану (stateless), з трыма дэма-інструментамі (тым жа наборам, што ў рэпазіторыі) - каб адразу «памацаць» MCP:

  • Маршруты:
    • GET /healthz - праверка здароўя.
    • /mcp - MCP-эндапоінт (GET, POST, DELETE).
  • Stateless-рэжым (без сесій).
  • Тры інструменты:
    • echo - вяртае перададзены тэкст.
    • get_proverb_by_topic - прыказкі па тэме (topic, random, limit).
    • get_weather - лаканальнае надвор’е з wttr.in.


🚀 Збіраем сервер і падключаем яго да Cursor/VS Code

Тэорыя скончана, час дзейнічаць: клон, усталёўка, запуск - і MCP ўжо працуе.

🔑 Перадумовы (што трэба перад стартам)

Тут без сюрпрызаў:

  • Node.js ≥ 18 або Bun ≥ 1.x (Bun хутчэйшы пры старце - менш лішніх рухаў).
  • Два пакеты: @modelcontextprotocol/sdk (аснова MCP) і zod (каб апісваць уваходныя параметры дакладна і надзейна).
  • Docker - толькі калі хочаце адразу пакласці ўсё ў кантэйнер. Для лакальнага тэставання не патрэбны.

⚡️ Запускаем прыклад

Без лішняй філасофіі - проста клануем рэпазіторый і запускаем:

text
1
2git clone https://github.com/bel-frontend/RAG
3cd RAG/lesson8_mcp/mcp_server
text
1
2bun install
3bun index.ts

Калі ўсё добра - у кансолі з’явіцца паведамленне:

text
1MCP Streamable HTTP Server on http://localhost:3002/mcp
2Available endpoints: /healthz, /mcp

🎉 Сервер! Жыві!

Праверым яго «пульс»:

text
1curl -s http://localhost:3002/healthz

Адказ павінен быць у фармаце { ok: true, timestamp: ... }.

🧩 Архітэктура простымі словамі

Як працуе сервер:

  1. Ствараецца MCP-сервер - у ім рэгіструюцца інструменты (echo, get_proverb_by_topic, get_weather).
  2. Дадаецца HTTP-транспарт - MCP можа прымаць і адпраўляць запыты праз /mcp.
  3. Маршруты:
    • /healthz - вяртае просты JSON, каб праверыць, што сервер жывы.
    • /mcp - асноўны эндпоінт, праз які Cursor або VS Code звязваюцца з інструментамі.
  4. Кантэкст - загалоўкі (apikey, applicationid) кладуцца ў сховішча, каб інструменты маглі іх выкарыстоўваць.
  5. Завяршэнне - пры спыненні (SIGINT/SIGTERM) сервер карэктна закрываецца.

🛠 Інструменты - галоўная магія тут

Дададзены тры простыя інструменты для хуткага эксперымента:

  • echo - вяртае тэкст, які вы яму перадалі (карысна для праверак).
  • get_proverb_by_topic - выдае прыказкі па тэме; падтрымлівае random і limit.
  • get_weather - паказвае надвор’е праз сэрвіс wttr.in.

Кожны інструмент апісаны праз zod-схему. Гэта гарантуе дакладнасць: калі карыстальнік пераблытаў параметры, MCP паведаміць пра няправільны фармат.

🖇 Падключаемся да Cursor і VS Code

І тут пачынаецца самае цікавае - інтэграцыя. Калі MCP працуе, мы можам выкарыстоўваць яго праз Cursor або GitHub Copilot у VS Code.

Cursor:

  1. Запусці сервер (bun index.ts).
  2. Ствары ў праекце файл ./.cursor/mcp.json з канфігурацыяй:
text
1{
2  "mcpServers": {
3    "test-mcp": {
4      "type": "http",
5      "url": "http://localhost:3002/mcp",
6      "headers": {
7        "apiKey": "API_KEY_1234567890",
8        "applicationid": "APPLICATION_ID"
9      }
10    }
11  }
12}

Адкрый налады → Model Context Protocol і пераканайся, што test-mcp ёсць у спісе. У чаце Cursor напішы (пераканайся, што ўключаны менавіта агент): «Выкліч тул get_weather для Minsk» - і паглядзі адказ.

VS Code (Copilot Chat)

Тут амаль тое самае, толькі файл трэба пакласці ў .vscode/mcp.json. Пасля гэтага ў панэлі інструментаў Copilot Chat павінен з’явіцца ваш інструмент.

text
1{
2    "servers": {
3        "test-mcp": {
4            "type": "http",
5            "url": "http://localhost:3002/mcp",
6            "headers": {
7                "apiKey": "API_KEY_1234567890",
8                "applicationid": "APPLICATION_ID"
9            }
10        }
11    }
12}

🐳 Docker-рэжым

Хочаце адразу ўпакоўку? Збіраем і запускаем у Docker:

text
1docker compose build --no-cache
2docker compose up -d

MCP будзе даступны на http://localhost:3002/mcp. Зручна для каманднай працы: усе карыстаюцца аднолькавым вобразам і не марнуюць час на «у мяне працуе - у цябе не».

🤔 Тыповыя «граблі» і як іх абысці

  • CORS - калі падключаецеся з браўзера, трэба дазволіць загалоўкі. Мы дадалі базавы варыянт у код.
  • Stateless/Stateful - ў прыкладзе сервер «без памяці». Калі патрэбныя сесіі - уключайце sessionIdGenerator.
  • API-загалоўкі - - у Node.js яны прыходзяць у ніжнім рэгістры (apikey, а не apiKey). Лёгка заблытацца.
  • Знешнія сэрвісы - прыказкі і надвор’е могуць тармазіць. Дадавайце таймаўты і кэш.

✍️ Як зрабіць свой інструмент

Просты прыклад:

text
1import { z } from 'zod';
2import type { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
3
4export function registerMyTools(mcp: McpServer) {
5  mcp.registerTool(
6    'my_tool',
7    {
8      title: 'my_tool',
9      description: 'Просты інструмент, які складае 2+2',
10      inputSchema: { name: z.string() },
11    },
12    async ({ name }) => ({
13      content: [{ type: 'text', text: `Вітаю, ${name}! 2+2 = 4` }],
14    }),
15  );
16}

Гатова - цяпер вы можаце дадаваць свае «чараўніцтвы» ў MCP і карыстацца імі з IDE.

🎯 Вынікі

Мы сабралі MCP-сервер на Bun/Node, дадалі тры дэма-інструменты, падключылі яго да Cursor і VS Code, запусцілі ў Docker і абмеркавалі тыповыя праблемы. Галоўнае - MCP робіць падключэнне ўласных інструментаў да разумных IDE простым і стандартызаваным.

Далейшае - толькі ваша фантазія: можна інтэграваць DevOps-працэсы, базу дадзеных, BI-запыты, унутраныя API. MCP дазваляе гэта зрабіць так, каб іншыя члены каманды маглі проста ўзяць і выкарыстоўваць.

Што далей

Мы сабралі акуратны MCP-сервер з HTTP-транспартам, дадалі тры наглядныя інструменты, наладзілі CORS і паказалі канфігурацыі для Cursor і GitHub Copilot (VS Code), а таксама Docker-запуск. Наступныя крокі - пашырэнне набору інструментаў, аўтэнтыфікацыя, лагіраванне, кэш; пры патрэбе - stateful-сесіі і вынясенне ў prod.

Калі гэта вас зачапіла - стварайце ўласныя інструменты і дзяліцеся імі з супольнасцю! Запрашаем далучацца да аўтараў bel-geek.com - будзем разам ствараць разумныя і карысныя рэчы.

MCP
Admin, 2025-08-13

дарожная карта

Гэты артыкул - абагульненне некалькіх артыкулаў пра новы напрамак, які ўжо зараз ператвараецца у новую прафесію , якая з часам будзе вельмі запатрабаванай.

Context Engineering: Новая прафесія на скрыжаванні інтэлекту і інфармацыі

1. Чаму гэта важна?

Сённяшнія LLMs — гэта не проста тэкставыя генератары. Гэта магутныя сістэмы, здольныя:

  • аналізаваць інфармацыю;
  • будаваць лагічныя ланцужкі;
  • прымаць рашэнні;
  • падтрымліваць складаныя дыялогі.

Аднак іх здольнасці абмяжоўваюцца толькі тым, які кантэкст яны атрымліваюць. І нават самая дасканалая мадэль будзе марнаваць свой патэнцыял, калі “не зразумее”, што ад яе патрабуецца.

Кантэкст — гэта не проста запыт. Гэта цэлае інфармацыйнае асяроддзе, у якім працуе ШІ: дакументы, прыклады, накіраванні, ранейшыя размовы, — усё, што ўплывае на разуменне і прыняцце рашэння. І тое, як мы ствараем і падаем гэты кантэкст, — вызначае эфектыўнасць усяго ўзаемадзеяння з мадэллю.

Так з’явілася цэлая галіна — context engineering. Яна вырасла з prompt engineering і ператварылася ў асобную прафесію, якая спалучае тэхналогіі, логіку і інфармацыйны дызайн. Гаворка ідзе пра сістэмны падыход да працы з кантэкстам: ад яго пошуку да кіравання ім у рэжыме рэальнага часу.

2. Аснова context engineering — што яна сабой уяўляе?

Калі prompt engineering — гэта пра тое, як сфармуляваць запыт, то context engineering — гэта пра стварэнне ўмоў для разумнага адказу. Гэта як не проста задаць пытанне, а даць чалавеку дакументы, факты, прыклады і мову, якой варта карыстацца.

Context engineering ахоплівае тры асноўныя кампаненты:

2.1. Context retrieval and generation

На першым этапе трэба знайсці і падаць мадэлі патрэбную інфармацыю:

  • Prompt engineering — базавыя запыты і іх структура.
  • In-context learning — метады накшталт zero-shot, few-shot, chain-of-thought, калі мадэль вучыцца на прыкладах унутры кантэксту.
  • Retrieval знешніх ведаў — напрыклад, з баз дадзеных ці дакументаў (retrieval-augmented generation).
  • Дынамічныя шаблоны — адаптыўныя запыты (напрыклад, CLEAR framework), якія змяняюцца ў залежнасці ад сітуацыі.

2.2. Context processing

Далей — апрацоўка інфармацыі:

  • Працэсінг доўгіх паслядоўнасцей — мадэлі, здольныя працаваць з тэкстамі на тысячы токенаў (Mamba, LongNet).
  • Самаўдасканаленне — мадэлі, што вучацца з уласных адказаў і карэктуюць кантэкст.
  • Мультымадальнасць — камбінацыя тэксту, гуку, выяваў, табліц.
  • Аптымізацыя ўвагі і памяці — тэхнікі сціску, sparsity, забывання непатрэбнага.

2.3. Context management

І, нарэшце, кіраванне кантэкстам у часе:

  • Памяць: кароткатэрміновая (размова), доўгатэрміновая (біяграфія карыстальніка), знешняя (базы дадзеных).
  • Context compression — аўтакодэры, рэкурэнтнае сцісканне.
  • Paging — падзел кантэксту на старонкі з доступам да патрэбнай інфармацыі.
  • Маштабаванае кіраванне — для складаных сцэнароў з некалькімі агентамі.

3. Як гэта працуе: архітэктурныя рашэнні

Context engineering ужо ўвасабляецца ў канкрэтныя тэхнічныя мадэлі і архітэктуры. Вось некалькі прыкладаў:

3.1. Retrieval-augmented generation (RAG)

Калі мадэль не мае патрэбнай інфармацыі — яна можа “запытаць” яе звонку. RAG дазваляе LLM:

  • шукаць дадатковыя звесткі;
  • выкарыстоўваць іх у рэжыме рэальнага часу;
  • абапірацца на факты пры генерацыі адказу.

3.2. Сістэмы памяці

LLM з памяццю — гэта мадэль, што не “забывае”:

  • можа весці працяглыя дыялогі;
  • успамінае вашыя папярэднія пытанні;
  • адаптуецца да вашых інтарэсаў (напрыклад, MemGPT).

3.3. Інструментальныя агенты (tools, agents)

Мадэль, што не толькі адказвае, але і дзейнічае:

  • запускае код;
  • шукае інфармацыю ў інтэрнэце;
  • узаемадзейнічае з API.

3.4. Шматагентныя сістэмы

Некаторыя задачы патрабуюць каманды. Шматагентныя сістэмы:

  • падзяляюць ролі;
  • абменьваюцца кантэкстам;
  • працуюць сінхронна для вырашэння складаных задач.

4. Што яшчэ не зроблена: асноўныя праблемы

Тэхналогія развіваецца імкліва, але ёсць і праблемы:

  • Разрыў разумення і генерацыі — LLM можа зразумець складаны кантэкст, але не заўсёды здольны стварыць якасны вынік на яго аснове.
  • Метрыкі ацэнкі — класічныя метрыкі (BLEU, ROUGE) недастатковыя для ацэнкі reasoning або кааперацыі агентаў.
  • Мультымадальная інтэграцыя — цяжка аб’яднаць тэкст, гук, выявы, табліцы ў адзінны лагічны ланцуг.
  • Бяспека і этыка — кантэкст можа быць скажоны, маніпулятыўны або прыватны.

5. Напрамкі будучыні: што чакае context engineering

Што будзе развівацца:

  • Уніфікаваная тэорыя — фармалізацыя прынцыпаў context engineering.
  • Новая генерацыя памяці — мадэлі, што памятаюць не толькі тэкст, але і сэнс.
  • Поўная мультымадальная інтэграцыя — тэкст + відэа + аўдыё + графы.
  • Лепшыя метады ацэнкі — метрыкі, што ўлічваюць логіку, паслядоўнасць, адаптыўнасць.
  • Этычнае разгортванне — празрыстасць, тлумачальнасць, справядлівасць.

6. Рэзюмэ

Context engineering — гэта не проста новы трэнд. Гэта аснова новай хвалі штучнага інтэлекту:

  • разумнага;
  • адаптыўнага;
  • карыснага;
  • адказнага.

І калі вы працуеце з LLM, то хутчэй за ўсё — вы ўжо context engineer. Пытанне толькі ў тым, ці робіце вы гэта інтуітыўна — ці свядома і прафесійна.

Крыніцы

  1. https://github.com/Marktechpost/AI-Tutorial-Codes-Included
  2. https://www.marktechpost.com/2025/08/03/a-technical-roadmap-to-context-engineering-in-llms-mechanisms-benchmarks-and-open-challenges/
  3. https://arxiv.org/abs/2507.13334
context
engineering
Admin, 2025-08-06

head

1. Першае знаёмства: уваход у вайб-кодынг

Не так даўно я выпадкова натрапіў на відэа, дзе нейкі распрацоўшчык за некалькі хвілін стварыў цэлы дадатак з дапамогай штучнага інтэлекту. Сэрвіс называўся bolt.new. Ну і, як не цяжка здагадацца, я вырашыў сам выпрабаваць гэтага звера.

Першыя ўражанні былі, скажам шчыра, вельмі натхняльнымі. Ты даеш каманду — атрымліваеш код. Як у марах юнага дэвелопера: без мітынгаў, рэв’ю і вечаровых званкоў ад праектавага менеджара. Але, як гэта бывае ў казках, усё ішло добра… да пэўнага моманту.

Калі ўзнікла патрэба штосьці змяніць у кодзе — пачаліся праблемы. Bolt вельмі хутка “з’ядае” токены, а з пошукам і выпраўленнем памылак у яго, скажам мякка, праблемы. У выніку — выдатны інструмент для хуткага MVP, але ніяк не для падтрымкі або маштабавання. Так пачалася мая вайб-кодынгавая эпапея.

2. План Б: Copilot і боль у сэрцы

Пасля першага расчаравання я перанёс распрацоўку на лакальны кампутар. Уключыў VS Code, падключыў Copilot — і зноў у бой. Па змаўчанні ён працуе з мадэллю GPT-4.1. Для простых задач — піша, каментуе, дапамагае. Усё выглядае нядрэнна.

Але варта было папрасіць яго зрабіць нешта сур’ёзнае — напрыклад, прааналізаваць некалькі файлаў і прапрацаваць логіку — як усё пачало сыпацца. Памылкі, некансістэнтнасць, кодавы кактэйль з глюкаў. Стала відавочна: праблема — у абмежаваным кантэксце. У рэжыме “агента” мадэль не цягне вялікі аб’ём дадзеных.

Я пераключыўся на Claude Sonnet 3.7 — і тут ужо было лепш. З’явілася надзея. Потым выяыіў што ёсць Sonnet 4 — і тут сапраўды пачалася магія: мадэль пісала код, правярала лінтары і выпраўляла сва ж памылкі, запускала скрыпты ў тэрмінале… Але — так, вы ўжо здагадаліся — токены скончыліся.... І свет зноў стаў шэрым.

3. Cursor: другая спроба магіі

Пасля чарговага фіяска, калі токены скончыліся, а душа — апусцела, я не здаўся. Я вырашыў: “Хопіць гэтага здзеку!” І пайшоў качаць Cursor. Купіў PRO-версію і адразу — у бой.

Cursor у спалучэнні з Sonnet-4 + Max(пашырае кантэкст) працаваў нармальна. Не так глянцава, як Copilot, але дастаткова эфектыўна. Пачаў ствараць дадатак: адзін файл, другі, трэці… Усё ішло добра. Пакуль не стала зразумела — нават з Max мадэль пачынае “забывацца”: губляе кантэкст, выдаляе важныя часткі кода, забывае пра логіку папярэдняй ітэрацыі. Але пакуль — трывожны, але не крытычны сігнал.

Крытычна стала… на наступны дзень. Вы не паверыце — зноў скончыліся токены! Я забіў іх за два дні на 10-экранным дадатку. Было адчуванне, быццам я гляджу, як мая зарплата проста ператвараецца ў пустэчу. Але не здаўся! Купіў Cursor Pro+ і працягнуў (зарплата - да сустрэчы). Бо вайб-кодзінг — ён такі.

4. Момант ісціны: архітэктура ці хаос

Калі дадатак стаў выглядаць як нешта жывое, я вырашыў правесці код-рэв’ю сам сабе. І — жах! Кожны экран быў асобнай “планетай”, ніякіх шаблонаў, усе элементы дубляваліся, як быццам нейкая таямнічая сіла вырашыла паказаць мне, што такое пекла для UI-дызайнера. Кожны асобны экран хоць і быў падоны да папярэдняга але не.

Звычайныя рэчы — кшталту афсэтаў ці водступаў — трэба было выпраўляць рукамі на кожным экране. Прасіць мадэль зрабіць гэта аўтаматычна — марная справа. Яна выпраўляла ў адным месцы, і адначасова ламала у іншым. У гэты момант я ўсвядоміў сваю галоўную памылку: я не прапрацаваў архітэктуру дадатку з самага пачатку.

Па сутнасці, я далей я ўвесь час працаваў як “сеньёр, што на хаду дрэсіруе мадэль-джуна”: “Не! Гэта — асобны кампанент! Тут — вынесем стылі! Не пхай чатыры кампаненты ў адзін файл!” (былі файлы больш за 1000 радкоў). І гэта, канешне, крыху выбівала з каляі.

5. Рэкамендацыі: як не патануць у вайбе

Пасля ўсіх гэтых перыпетый я вырашыў — трэба падзяліцца досведам. Вось некалькі парад тым, хто хоча вайб-кодзіць, але не трапіць у багну:

  1. Стварыце структуру. Адразу вызначце, як будуць выглядаць папкі і файлы.
  2. Правярайце стылі. Пасля кожнай ітэрацыі сачыце за кансістэнтнасцю.
  3. Выносіце кампаненты. Калі нешта паўтараецца — у асобны файл! Але дакладна ўказвайце, куды.
  4. Адна задача — адзін промпт. Інакш атрымаеце салянку.
  5. Цярпенне — ключ. Мадэль часам бачыць памылку і сама яе выпраўляе. Не спяшайцеся.
  6. Каміт — ваш сябра. Калі нешта працуе — фіксуйце. Наступны крок можа ўсё зламаць.
  7. Абнуляйце кантэкст. Пачынаеце новую фічу? Стварыце новы чат. І не забывайце пра git commit!

І галоўнае — не губляйце кантроль над грашыма. Гэтыя звяры любяць есці токены, як галодны студэнт — піцу. Не паспееш азірнуцца — усё скончылася. Зноў.

6. Вынікі: без прафесіяналаў — няма магіі

Пасля ўсяго перажытага, адна рэч стала цалкам зразумелай: на дадзены момант без прафесіяналаў штучны інтэлект не здольны ствараць сапраўды якасныя прадукты. Так, ШІ значна паскарае распрацоўку, выконвае шмат руціннай працы, дапамагае “выплюхнуць” MVP у рэкордна кароткія тэрміны. Але ўсё гэта працуе толькі пры ўмове, што побач ёсць чалавек, які ведае, што робіць.

Без правільнага кіравання, мадэлі губляюць кантэкст, паўтараюцца, робяць “выпадковыя” архітэктурныя рашэнні — і вынік нагадвае кодавых маўпаў, якія з нейкай верагоднасцю усё ж напішуць кнігу. Таму, як бы гэта парадаксальна ні гучала, каб не пісаць код — трэба ўсё яшчэ добра яго разумець.

У будучыні, відавочна, мы будзем усё менш і менш пісць код уручную. Але каб сапраўды эфектыўна выкарыстоўваць ШІ, мы павінны вучыцца думаць як інжынеры і кіраваць працэсам — а не проста “размаўляць з ботам”.

І так, халера, токены зноў скончыліся. Але цяпер вы хаця б будзеце ведаць, што рабіць далей.

MVP
Admin, 2025-06-01

header

Сёння я хачу падзяліцца сваім невялікім спісам MCP-сервераў, якімі я карыстаюся кожны дзень на працы і ў сваіх праектах.


1. GitHub MCP Server

Што робіць

GitHub MCP Server дазваляе працаваць з GitHub праз ШІ-агента: глядзець код, шукаць файлы, чытаць і самарызаваць дакументацыю ў рэпазіторыях, працаваць з issues і pull-requests, бачыць агульную карціну па праектах.

Як я выкарыстоўваю

  • чытаю і раблю дакументацыю ў рэпазіторыях;
  • дапісваю або ствараю новую тэхнічную дакументацыю;
  • аналізую pull-requests (што змянілася, якія рызыкі, што варта даправіць), пры гэтым часта вельмі дапамагаюць rules, праз якія мы дадаем абмежаванні код-стайлу;
  • ствараю пул-рэквэсты;
  • гляджу актуальныя для мяне issues, каб разумець, чым заняцца ў першую чаргу.

Гэта прыкметна зніжае колькасць пераключэнняў паміж IDE і браўзерам, асабліва калі трэба хутка пагрузіцца ў некалькі PR адразу.

Каму падыходзіць

  • Распрацоўшчыкам, якія "жывуць" у IDE і не любяць пастаянна адкрываць GitHub у браўзеры.
  • Тым, хто шмат працуе з PR і тэхнічнай дакументацыяй.

Спасылкі

GitHub MCP


2. Atlassian MCP Server (Jira / Confluence)

Што робіць

Atlassian MCP Server дае доступ да Jira і Confluence праз ШІ-агента: можна ствараць і абнаўляць задачы, чытаць старонкі ў Confluence, шукаць інфармацыю і атрымліваць самарызацыі па дакументацыі і бэклогу.

Як я выкарыстоўваю

  • чытаю вялікія Confluence-старонкі і атрымліваю кароткія самарызацыі замест ручнога скролу;
  • пішу і дапрацоўваю тэхнічную дакументацыю (дызайн-дакументы, нататкі пасля мітынгаў, інструкцыі);
  • ствараю таскі ў Jira (bug, task, sub-task) з простых тэкставых нататак;
  • рэдагую існыя задачы: апісанні, acceptance criteria, статус, прыярытэты;
  • раблю хуткі агляд таскаў, якія актуальныя менавіта для мяне: што ў працы, што ў «to do», што заблакавана.

Па факце, гэта мой асноўны спосаб працаваць з Jira, не залазячы ў яе цяжкі вэб-інтэрфейс.

Каму падыходзіць

  • PM, BA, Team/Tech Leads, якія "жывуць" у Jira і Confluence.
  • Інжынерам, якія хочуць бачыць «што ад мяне чакаюць» у зручным тэкставым фармаце.
  • Камандам, дзе шмат дакументацыі і доўгіх Confluence-старонак.

Спасылкі


3. Figma MCP Server

Што робіць

Figma MCP Server падцягвае ў асістэнта дызайн-кантэкст: фрэймы, кампаненты, стылі, токены, layout. Дапамагае перанесці макет з Figma ў код: зразумець структуру экрана, адступы, назвы кампанентаў і сувязі паміж элементамі.

Як я выкарыстоўваю

  • значна спрашчаю напісанне кампанентаў, асабліва калі экран складаны;
  • атрымліваю структуру фрэйма і магу спакойна перанесці яе ў код;
  • менш памыляюся ў дэталях: аднолькавыя адступы, правільныя колеры, стылі тэксту.

У выніку час ад «ёсць макет у Figma» да «экран працуе ў кодзе» скарачаецца, а якасць рэалізацыі бліжэй да зыходнага дызайну.

Каму падыходзіць

  • Frontend-распрацоўшчыкам, якія шмат працуюць з Figma.
  • Дызайнерам і інжынерам, якія хочуць менш «рукдзела» пры пераносе макета ў код.
  • Камандам з поўнай дызайн-сістэмай і токенамі.

Спасылкі

Figma MCP


4. Goman.live — MCP Localization Manager

Што робіць

Goman.live праз MCP дапамагае працаваць з лакалізацыямі: ствараць новыя ключы, глядзець існуючыя, атрымліваць чарнавыя пераклады на некалькі моў без ручнога рэдагавання JSON-файлаў, перакладаць тэксты, не губляючы кантэкст.

Як я выкарыстоўваю

  • Падчас вайб-кодынгу, калі адразу відаць, што тэкст трэба будзе перакладаць.
  • У праектах, якія патрабуюць лакалізацыі на шмат моў (такіх праектаў у мяне ўжо некалькі).
  • Калі трэба хутка дадаць новыя ключы і атрымаць чарнавы пераклад, а потым нармальна яго адрэв’юіць на старонцы сэрвісу.

На дадзены момант я задаволены: працэс лакалізацыі стаў больш прадказальным і менш нервовым. Але трэба кантраляваць актуальнасць ключоў — агенты любяць нарабіць кучу неактуальных.

Каму падыходзіць

  • Камандам, дзе ёсць i18n і некалькі моў інтэрфейсу.
  • Распрацоўшчыкам, якія не хочуць самастойна падтрымліваць JSON-файлы з перакладамі.
  • Лакалізатарам і кантэнт-камандам, якія хочуць мець цэнтральнае месца для перакладаў.

Спасылкі

*: MCP Localization Manager

5. Playwright MCP

Што робіць

Playwright MCP дазваляе кіраваць браўзерам праз асістэнта на базе Playwright: адкрываць старонкі, запаўняць формы, націскаць кнопкі, правяраць табліцы, чытаць тэксты на старонцы. Ён працуе з семантычнай структурай (a11y-дрэвам), а не з «карцінкай экрана», таму паводзіць сябе стабільней.

Як я выкарыстоўваю / калі гэта карысна

  • для простых smoke-тэстаў асноўных карыстальніцкіх сцэнарыяў (login, checkout, форма замовы і г.д.);
  • для хуткай праверкі таго, што ключавыя патокі не паламаліся пасля зменаў;
  • для збору інфармацыі са старонак без напісання поўных e2e-тэстаў рукамі.

Гэта не чароўная замена ўсім тэстам, але добры інструмент, каб даць агентам доступ да браўзэра і аўтаматызаваць руцінныя праверкі.

Каму падыходзіць

  • QA, якія ўжо выкарыстоўваюць Playwright.
  • Распрацоўшчыкам, якія хочуць лёгка праверыць асноўныя сцэнарыі пасля зменаў.
  • Аналітыкам, якім патрэбна аўтаматычна выцягваць дадзеныя з вэб-старонак.

Спасылкі

Playwright MCP


Кароткая выснова

  • Atlassian MCP — мой асноўны інструмент для дакументацыі і задач (Jira/Confluence).
  • GitHub MCP — для кода, PR і агляду рэпазіторыяў.
  • Figma MCP — калі рэалізоўваю дызайны і хачу быць бліжэй да макета.
  • Goman MCP — калі праект патрабуе лакалізацыі на некалькі моў.
  • Playwright MCP — аўтаматызацыя UI, smoke-тэсты і праверка асноўных карыстальніцкіх сцэнарыяў.
ШІ
AI
MCP
Admin, 2025-11-23

space

Прывітанне! Спадарства!

Працягваем наш цыкл артыкулаў пра ШІ (Штучны інтэлект) і як ім карыстацца. Сёння наш артыкул будзе больш тэарытычны. Мы паспрабуем разабрацца, што такое мадэлі, якія яны бываюць, як іх выкарыстоўваць, і якія яны маюць асаблівасці.

Калі вы не чыталі нашыя папярэднія артыкулы - раю пачытаць.

Спадзяюся вам будзе цікава, таму паехалі!

І так, як звычайна (ну падаецца ж так у школе рабілі) - давайце разбярэмся з паняццем ШІ-мадэлі.


Штучны інтэлект — гэта не чараўніцтва, гэта матэматыка на стэроідах

Калі чуеце “ШІ-мадэль”, можа здацца, што гаворка пра нешта накшталт робата, які думае, як чалавек. Але насамрэч усё куды прасцей (і складаней адначасова). ШІ-мадэль — гэта матэматычная канструкцыя, якая вучылася на даных, каб пасля прадказваць, класіфікаваць ці нават генераваць новыя тэксты, выявы ці коды.

Прыкладам, калі вы карыстаецеся перакладчыкам, атрымліваеце рэкамендацыі ў Spotify або фільтруеце спам у пошце — там працуе адна ці некалькі такіх мадэляў. Але важна разумець: мадэль — гэта не сам алгарытм, а вынік яго прымянення да даных.

Звычайна працэс выглядае так: вы бераце алгарытм (напрыклад, градыентны бустынг, нейронную сетку ці SVM), “корміце” яго дадзенымі — і атрымліваеце мадэль. Потым гэтая мадэль ужо можа самастойна прымаць рашэнні — напрыклад, вызначыць, ці ёсць на здымку котка, ці гэта проста пухнаты коўдрык.

У гэтым артыкуле мы разбярэмся глыбей: чым розныя мадэлі адрозніваюцца, навошта патрэбныя фундаментавыя мадэлі (як GPT,Claude і г.д.), і чаму без магутных GPU сёння не зварганіш нават простага чат-бота.


Як ШІ-мадэль “запамінае” інфармацыю: вектары, прасторы і матэматычная магія

Добра, мы ўжо ведаем, што мадэль — гэта вынік навучання на даных. Але ўзнікае лагічнае пытанне: а як яна ўсё гэта захоўвае? Ці не захоўвае, як Google Docs?

Не. ШІ-мадэль нічога не запамінае “па-людску”. Яна не ведае, што “котка” мякае, а “піцца” смачная. Замест гэтага яна ўяўляе сабе свет праз вектары — гэта матэматычныя аб’екты, якія складаюцца з набораў лікаў. Груба кажучы, кожнае слова, карцінка, запыт ці нават паняцце пераўтвараецца ў лічбавы код — набор значэнняў у прасторы з сотнямі ці тысячамі вымярэнняў.


🧠 Прыклад:

text
1“котка” = [0.12, -0.98, 3.45, …]

Калі мадэль “думае” пра слова “котка” (звыяайна яна стварае вектары для цэлых выразаў), яна працуе не з тэкстам, а з яго вектарным уяўленнем. Тое ж самае са словам “сабака”, “пухнаты”, “мурлыкае” і г.д.


vectors

(Візуалізацыя вектараў. Зверху злева - вектары тэкстаў пра промптынг. Знізу справа - вектары тэкстаў пра беларускую мову. )


Цікава, што вектары, блізкія ў гэтай шматмернай прасторы, азначаюць паняцці, блізкія па сэнсе. Напрыклад, калі вектар “котка” побач з “сабака”, гэта значыць, што мадэль навучылася бачыць нешта агульнае паміж імі (жывёлы, хатнія, пухнатыя).

Як вектары параўноўваюцца?

Мадэль вымярае косінуснае падабенства або эўклідаву адлегласць паміж вектарамі. Прасцей кажучы — яна вылічвае, наколькі “паралельныя” ці “блізкія” вектары адзін да аднаго. Чым меншая адлегласць або большы косінус, тым мацней сувязь паміж паняццямі.

Так, напрыклад, у вялікіх мовахвых мадэлях (LLM) тыпу GPT:

  • “Мінск” + “Беларусь” ≈ “Парыж” + “Францыя”
  • “Кніга” + “чытаць” — “папера” ≈ “электронная”

І навошта гэта трэба?

Усё, ад разумення пытанняў карыстальніка да генерацыі адказаў, адбываецца праз маніпуляцыю гэтымі вектарамі. Калі вы пішаце ў чат: “парай фільм як Inception”, мадэль шукае вектар “Inception”, знаходзіць яго суседзяў у прасторы (напрыклад, “Interstellar”, “Tenet”), і на аснове гэтага генеруе рэкамендацыю.

Не ўсе ШІ-мадэлі аднолькавыя: як іх падзяляюць

Разнастайнасць мадэляў уражвае. Так можна знайсці мадэлі якія займаюцца аналізам мапаў ці выяўленнем хвароб па здымках.

Давайце паспрабуем неяк тыпізаваць ШІ мадэлі.

Пачнем з таго, што мадэлі могуць падзяляцца па тыпах дадзеных з якімі яны працуюць:

🧠 Моўныя мадэлі (LLM)

Працуюць з тэкстам: разумеюць, працягваюць, аналізуюць, генеруюць. Сучасныя прыклады:

  • Qwen 3 — падтрымлівае як dense, так і Mixture-of-Experts архітэктуры.
  • Gemma 3 — кампактная, эфектыўная, працуе нават на 1 GPU.
  • DeepSeek-R1 — робіць упор на разважанне і лагіку.
  • LLaMA 3.3 / 4 — новыя open-source LLM.

👁 Візуальныя мадэлі (Computer Vision / Multimodal Vision)

Працуюць з выявамі: распазнаюць, аналізуюць, генеруюць.

  • LLaMA 4 Vision — разумее малюнкі і можа адказваць на пытанні па візуальным кантэксце.
  • Gemma Vision — маштабаваная візуальная мадэль ад Google.
  • DALL-E
🎤 Гукавыя і маўленчыя мадэлі

Для распазнавання маўлення, генерацыі голасу, эмоцый і г.д. (Пакуль найноўшых open-source канкурэнтаў Whisper або VALL-E не шмат, але чакаюцца.)

🔀 Мультымадальныя (Multimodal)

Здольныя апрацоўваць некалькі тыпаў дадзеных: тэкст + выява, тэкст + аўдыё і інш. Напрыклад LLaMA 4 — аб’ядноўвае моўную мадэль з магчымасцю анвлізаваць выявы і падтрымлівае агенты (Пра іх у наступных артыкулах).


🧰 Па функцыянальнасці мадэлі можна падзяліць:
  1. Адназадачныя мадэлі (Task-specific) Тонка адаптаваныя пад адну задачу (напрыклад, генерацыя SQL, аўтаматычны медыцынскі аналіз).
  2. Шыроказадачныя мадэлі (General-purpose) Выконваюць мноства задач без спецыфічнай адаптацыі. Сюды адносяцца ўсе сучасныя флагманскія мадэлі: Qwen 3, LLaMA 3.3, Gemma 3, DeepSeek-R1.
  3. Агенты з інструментамі (Tool-augmented models) Могуць карыстацца раўзам з калькулятарамі, пошукам, базамі даных, нават іншымі ШІ. Прыклад: GPT-4 Turbo з інструментамі, LLaMA 4 Agents, DeepSeek Agent (на базе R1).

🏋️ Па памеры мадэлі можна падзяліць па колькасці параметраў якія яны падтрымліваюць (В - Мільярды):
  • Tiny / Small (0.6B – 4B параметраў) — працуе на лакальных прыладах.
  • Medium (7B – 14B) — патрабуе GPU, працуе стабільна.
  • Large (30B – 70B) — для дата-цэнтраў або энтузіястаў з кластарамі.
  • Ultra-large (100B – 700B+) — патрэбен спец-абсталяванне.

Давайце разгледзім асаблівасці мадэляў, пра якія вы магчыма і не ведалі.

🧠 Мадэль — не чалавек. Яна нічога не “памятае”

Можна падумаць, што калі мадэль адказвае на вашы пытанні з улікам папярэдніх, то яна “памятае” размову. Але гэта ілюзія. У рэчаіснасці мадэль — гэта матэматычная функцыя, якая не мае памяці ў чалавечым сэнсе.


Кантэкст — вось дзе “жыве” ўся памяць

Кожны раз, калі вы адпраўляеце запыт у мадэль, разам з ім перадаецца так званы кантэкст — тэкст папярэдніх размоў, дакументаў, інструкцый. Гэта як калі б вы далі чалавеку шпаргалку перад тым, як нешта спытаць. І калі наступны запыт не ўтрымлівае папярэдні тэкст — мадэль усё “забывае”.

📌 Мадэль не захоўвае ніякай інфармацыі пасля адказу. Усё, што яна “ведае”, — гэта тое, што вы ёй перадалі ў бягучы момант.


Чаму гэта важна?

Бо гэта азначае, што мадэль не можа запамінаць карыстальнікаў, кантэкст размовы ці падзеі. Мадэль памятае толькі тыя дадзеныя якім яе навучылі пад час навучання ці файн-цюнінгу. Калі вам здаецца, што яна “памятае”, гэта не заслуга мадэлі, а сістэмы вакол яе, якая:

  • захоўвае кантэкст,
  • дынамічна яго падгружае,
  • або выкарыстоўвае вектарныя базы даных ці іншыя інструменты, каб аднавіць патрэбную інфармацыю.
🧊 Мадэль — гэта “замарожаная матэматыка”

Калі вельмі спрасціць: мадэль — гэта функцыя, якая пераўтварае ўваход (запыт + кантэкст) у выхад (адказ). І ўсё. У ёй няма ніякай унутранай дынамікі, якая б змянялася паміж выклікамі. (У больш простых мадэлях можна заўважыць што на адзін і той жа промпт будзе адзін і той жа адказ)

Гэта як калькулятар: вы ўвялі 2 + 2 — атрымалі 4. Калі хочаце атрымаць 4 зноў — трэба зноў увесці 2 + 2.

Усё, што звязана з “памяццю”, “асабістай гісторыяй”, “ўзгадваннем”, — гэта архітэктурныя надбудовы. Напрыклад, агенты з “памяццю” працуюць так:

  1. Увесь дыялог захоўваецца звонку (у базе, файле ці вектарнай сістэме).
  2. Пры кожным новым запыце, агент адшуквае адпаведныя фрагменты з “памяці”.
  3. Ён дадае іх у кантэкст, і толькі потым перадае ўсё мадэлі.

Сама мадэль нават не “ведае”, што гэты тэкст з памяці — для яе гэта проста яшчэ адна частка ўваходу.

🙅‍♂️ Ці можа мадэль навучацца падчас размовы?

Не. Тыповая ШІ-мадэль (у тым ліку GPT, Claude, LLaMA) не мяняе сябе падчас працы. Каб яна нешта “навучылася”, трэба прайсці працэс рэтрэйнінгу або файнт’юнінгу, і гэта цэлы асобны этап, які не адбываецца падчас чата.

Нават калі мадэль 100 разоў адказала няправільна — яна працягне рабіць тое ж самае, пакуль вы самі не створыце новую мадэль або не зменіце кантэкст.

📏 Кантэкст не гумавы: чаму мадэль не можа “прачытаць усё”

Адна з найбольш частых памылак карыстальнікаў у разуменні ШІ — ілюзія, што мадэль можа працаваць з “усёй кнігай”, “усёй базай даных”, ці “вялікай колькасцю дакументаў адначасова”. Але гэта не так. Мадэлі маюць строгае абмежаванне на памер кантэксту, які яны могуць апрацаваць за раз.


Што такое кантэкст у тэхнічным сэнсе?

Кантэкст — гэта ўвесь набор інфармацыі, якую вы перадаеце мадэлі пры адным выкліку: ваш запыт, інструкцыі, дакументы, гісторыя дыялогу і г.д. Гэта не проста “тэкст”, а набор токенаў — спецыяльных адзінак, на якія разбіваецца тэкст для апрацоўкі.

Прыклад:

Слова “котка” — гэта 1 токен. Слова “аўтамабілебудаванне” — можа змяшчаць 2-3 токены. Англійскае “The quick brown fox jumps over the lazy dog.” — гэта 9 токенаў.

Колькі токенаў “могуць трымаць” сучасныя мадэлі?
  1. GPT-3.5 - 4 096 токенаў
  2. GPT-4 - 8 192 - 32 000 токенаў
  3. GPT-4o - да 128 000 токенаў
  4. Claude 3 - да 200 000 токенаў
  5. LLaMA 3 - звычайна - 8k - 32k токенаў

128 000 токенаў — гэта прыкладна 300 старонак тэксту. Здаецца шмат? Але гэта хутка скончваецца, калі вы дадаеце, напрыклад, тэхнічную дакументацыю або код.

🧨 Што адбываецца, калі перадаць занадта шмат?

  1. Промпт не змесціцца — мадэль адмовіцца апрацоўваць яго або абрэжа частку (звычайна пачатак) і згубіцца частка дадзеных.
  2. Калі вы падаеце занадта доўгія тэксты, важныя часткі могуць быць “адсунуты” за межы бачнасці.
  3. Меншая дакладнасць — нават калі ўся інфармацыя змяшчаецца, мадэль можа “згубіцца” ў аб’ёме і прапусціць важнае.

Чаму проста не зрабіць “бясконцы кантэкст”?

Праблема ў тым, што ўсе токены апрацоўваюцца разам — і чым іх больш, тым:

  • больш памяці патрабуецца на GPU (Працэсары якія апрацоўваюць дадзеныя),
  • больш часу займае вылічэнне,
  • горш працуе ўвага (attention): мадэль “распыляецца” і не разумее, на што глядзець.

Як працаваць з вялікімі дадзенымі?

Калі тэкст не ўмяшчаецца ў кантэкст, існуюць рашэнні:

  1. 🔍 RAG (Retrieval-Augmented Generation) — выбар найбольш рэлевантных кавалкаў перад кожным запытам
  2. 📚 Вектарны пошук — знаходжанне блізкіх па сэнсе тэкстаў
  3. 🪓 Разбіццё — вы даяце інфармацыю часткамі
  4. 🧠 Агент з памяццю — выкарыстоўвае знешнюю базу, каб “узгадваць” ранейшае

✨ Падвядзем вынікі…

Фух! Калі вы дачыталі да гэтага моманту — вы ўжо амаль эксперт 😎 Давайце яшчэ раз коратка прабяжымся па галоўным:

✅ ШІ-мадэль — гэта не магія, а матэматыка, якая вучылася на даных ✅ Усе “веды” мадэлі захоўваюцца не як у чалавечай памяці, а ў вектарах ✅ Мадэль не памятае вас — уся “памяць” жыве ў кантэксце ✅ Ёсць шмат розных мадэляў: па тыпу дадзеных, функцыянальнасці і памеры ✅ Кантэкст абмежаваны — і гэта не баг, а фіча, з якой трэба працаваць ✅ “Навучыць мадэль у размове” — пакуль не зусім рэальнасць

Так што, калі вам здаецца, што ШІ “разумее” або “памятае” — успомніце, што на самой справе перад вамі вельмі разумны калькулятар, а не віртуальны Ян Баян з амнэзіяй 🙂


✍️ ЗЫ: Хочаце стаць суаўтарам?

Калі вы чытаеце гэта і думаеце: “О, я б таксама мог/магла напісаць пра што-небудзь па-беларуску!” — мы вас чакаем! Хутка будзе новы артыкул пра агентаў і інструменты, але мы адкрытыя да новых тэм, голасаў і ідэй. Калі ласка далучайцеся да нас! Пішыце, прапаноўвайце, далучайцеся! Ну і вы можаце падтрымаць нашы высілкі праз кнопку "Падтрымаць праект" у версе старонкі

ШІ
AI
мадэлі
models
Admin, 2025-05-02