Материал: Часть 21. Qwen Code-процесс для DataLakeHouse

Урок 1 из 5 в модуле «Часть 21. Qwen Code-процесс для DataLakeHouse»

Вы просматриваете урок без входа. Войдите, чтобы сохранять прогресс и проходить тесты.

Источник

Часть 21. Qwen Code-процесс для DataLakeHouse

Теперь процесс можно оформить как Qwen-процесс:

/sdd:profile -> /sdd:contract -> /sdd:build -> /sdd:verify -> /sdd:release

Главная идея: одна команда не должна делать весь процесс. В банковских данных опасно, когда агент сам профилирует источник, сам решает контракт, сам пишет SQL и сам себя ревьюит.

Команды проекта

Пример содержит:

.qwen/commands/sdd/profile.md
.qwen/commands/sdd/contract.md
.qwen/commands/sdd/build.md
.qwen/commands/sdd/verify.md
.qwen/commands/sdd/release.md

Команды разделены по точкам подтверждения человеком:

profile собирает факты источника;
contract формулирует или проверяет обещание;
build меняет dbt-модели;
verify запускает проверки и ищет дрейф;
release собирает пакет доказательств.

Навыки и субагенты

data-contract-review хранит чек-лист ревью. data-profiler читает источники и возвращает манифест без записи моделей. Генератор и ревьюер должны быть разными ролями. Иначе агент проверяет собственные догадки.

Ревьюер в режиме только чтения особенно важен после /clear: если он не может понять изменение

по файлам репозитория, значит автор оставил смысл в чате.

Хуки

Хук может блокировать запись в models/marts/, если изменение добавляет поле pii_ или меняет YAML контракта без метки подтверждения. В учебном примере хук описывается концептуально; писать его стоит после первого практического зачёта, когда команда уже понимает, какие нарушения повторяются.

Минимальный выход

Соберите карту процесса:

/sdd:profile -> Schema Manifest
/sdd:contract -> обновление ODCS/ODPS
/sdd:build -> изменение dbt-модели
/sdd:verify -> dbt build + проверочные факты
/sdd:release -> пакет доказательств
data-contract-review -> отчёт ревьюера

Если команда не оставляет артефакт, она не нужна на первом проходе.

Разбор для читателя

Команды Qwen в этой главе не должны превращаться в магическую панель управления. Их смысл в разделении ответственности. /sdd:profile наблюдает источник. /sdd:contract формулирует обещание. /sdd:build меняет модели. /sdd:verify ищет расхождения. /sdd:release собирает доказательства. Если одна команда делает всё, она стирает подтверждения человеком и снова превращает SDD в автопилот.

Навыки и субагенты полезны тогда, когда они сужают роль. Data-profiler не должен писать marts. Ревьюер контрактов не должен исправлять SQL. Генератор не должен сам утверждать, что его изменение безопасно. Такое разделение кажется формальным, пока не появляется ошибка. После ошибки именно роль показывает, кто должен был заметить проблему и какой артефакт должен был её удержать.

Хуки — следующий уровень дисциплины, но их не стоит писать раньше процесса. Если команда ещё не понимает, какие нарушения повторяются, хук будет либо слабым, либо раздражающим. Хороший хук блокирует известный опасный класс изменений: PII в models/marts/, YAML контракта без маркера утверждения, изменение grain без заметки о влиянии. Он не заменяет ревью, а не даёт очевидной ошибке дойти до него.

Эта глава соединяет весь том в рабочий цикл. После неё читатель должен уметь сказать, какой командой собирать факты источника, какой — проверять контракт, какой — строить модель, какой — запускать проверки и какой — готовить релиз. Если этого разделения нет, агент снова получает слишком широкую власть над данными.

Практика

Прогоните один и тот же запрос в двух ролях: автор и ревьюер. Автор может

предлагать изменения; ревьюер обязан работать в режиме только чтения. Сравните, какие замечания появляются только после разделения ролей.

Типичная ошибка

Делать одну команду /sdd:do-everything. Она удобна в демонстрации, но опасна в банковских данных: подтверждение человеком исчезает, а дрейф контракта обнаруживается слишком поздно.