Krumov
Well-Known Member
Виж поста ми #524 по-горе ще ти спести много ресурс от лимита. Правиш си AI WORKSHOP в репозитори на проекта и през Control room го командваш. Ето подробни интрукици и за теб и за Фалко:
Практическа система за работа с ChatGPT + Codex без излишно горене на лимити
Основната идея
Не използвайте Codex едновременно за:разбиране на проблема → проектиране на решение → търсене из проекта → писане на код → тестване.
Това често е скъпият начин на работа.
Вместо това разделете процеса на няколко роли:
Идея → Анализ → Техническо решение → Кратка задача → Codex → Проверка
Codex трябва да получава предимно последната част: ясно дефинирана задача за изпълнение.
1. Започнете в обикновен ChatGPT чат
Тук няма нужда да пестите контекст до крайност.Обяснете какво искате:
Обсъдете с ChatGPT:
- какъв е проблемът;
- как трябва да работи функцията;
- какви са граничните случаи;
- какво не трябва да се счупи;
- как бихте проверили резултата.
2. Използвайте отделен технически чат като „AI Workshop“
Когато вече знаете какво искате, дайте проблема на отделен ChatGPT чат и му задайте техническа роля.Например:
Този чат може да свърши „скъпото мислене“:
варианти → архитектура → рискове → зависимости → тестове → избрано решение
Ако има два възможни начина, решете кой искате преди Codex.
3. Направете финален execution contract
Сега превърнете техническото решение в кратка задача.Полезен формат е:
Код:
TARGET=
TASK=
REUSE=
INPUT=
PROTECT=
NO_CHANGE=
CHECK=
ACTION=
TEST=
OUTPUT=
STOPКакво означават
| Поле | Какво казва |
|---|---|
TARGET | Къде точно трябва да работи |
TASK | Какъв е крайният резултат |
REUSE | Какво вече съществува и трябва да се използва |
INPUT | Какви входове/данни са релевантни |
PROTECT | Какво задължително трябва да остане непроменено |
NO_CHANGE | Какво изрично е забранено |
CHECK | Какво трябва първо да бъде потвърдено |
ACTION | Конкретните промени |
TEST | Как се доказва резултатът |
OUTPUT | Какво точно трябва да докладва |
STOP | След задачата спира, вместо сам да продължава |
4. Едва сега дайте задачата на Codex
Например:
Код:
Mode: Token conservation. No long reasoning. No extra architecture discussion. Do the task and report only facts.
MODE=STRICT
TARGET=src/session_monitor.py
TASK=Add stale-session detection.
REUSE=existing SessionState + timestamp helper.
PROTECT=current API/schema/lifecycle.
NO_CHANGE=no dependencies, refactor, cleanup, or unrelated files.
ACTION=
- store last valid update time
- STALE after >5s
- ACTIVE on next valid update
- expose via existing snapshot
TEST=ACTIVE → STALE → ACTIVE; existing tests PASS.
OUTPUT=RESULT; FILES_CHANGED; TESTS; FACTS; BLOCKER.
STOPCodex вече не трябва да решава какво всъщност сте искали да направите.
5. Не използвайте Codex като изследовател без причина
Избягвайте задачи като:Тук сте оставили огромно пространство за действие:
Какво да търси? → Кои файлове? → Какво означава „подобрим“? → Каква архитектура? → Какви зависимости? → Какво може да променя?Агентът трябва сам да извърши голяма discovery и reasoning работа.
По-добре първо друг агент да установи необходимото и после Codex да получи:
6. Една задача = една проверима цел
Не изпращайте:Разделете това на отделни задачи.
Например:
Task 1: stale-session detection
Task 2: session telemetry
Task 3: logging
Task 4: performance optimization
След всяка задача трябва да можете да кажете:
PASS / FAIL / BLOCKED
Това значително улеснява и откриването на регресии.
7. За по-големи промени използвайте поетапна интеграция
Ако имате например 8 отделни функции, не е необходимо веднага да ги хвърляте всички в основната версия.По-безопасният процес е:
Код:
Task A → implementation → test → PASS
Task B → implementation → test → PASS
Task C → implementation → test → PASS
...
Task H → implementation → test → PASS
↓
combined test
↓
integration into development pipeline
↓
full regression
↓
promotion/release8. Какво да правите, ако Codex открие неочакван проблем
Не му давайте автоматично право да разширява задачата.Добро правило е:
Код:
If required state is missing or contradicts the task:
report BLOCKED with evidence and STOP.
Do not infer a new architecture.Процесът става:
Код:
Codex → BLOCKED
↓
ChatGPT / Workshop анализира причината
↓
нова bounded задача
↓
Codex9. Не оптимизирайте броя думи. Оптимизирайте неопределеността.
Това е най-важният принцип.Prompt от 100 думи може да бъде много скъп, ако казва:
Prompt от 200 думи може да бъде много по-ефективен, ако задава:
Код:
точен target
+ точна задача
+ съществуващи компоненти
+ защитени компоненти
+ забранени промени
+ конкретни действия
+ acceptance test
+ точен output
+ STOPа:
Най-простата версия за начинаещ
Не е необходимо от първия ден да изграждате сложна multi-agent система.Започнете само с три стъпки:
Код:
1. CHATGPT
Обсъждам какво искам и изчиствам идеята.
↓
2. CHATGPT / TECHNICAL CHAT
Превръщам идеята в конкретно техническо решение и тест.
↓
3. CODEX
Получава само:
TARGET + TASK + REUSE + PROTECT + ACTION + TEST + OUTPUT + STOPПравилото в едно изречение
Не плащайте на implementation агента с quota, за да открива проблем, който по-евтин агент може предварително да превърне в еднозначна, ограничена и проверима задача.И още по-кратко:
