После того как ИИ написал 60% кода: как Kuaishou контролирует разработку с ИИ с помощью 415 правил и 4 рубежей защиты

Примечание автора: за год доля кода, сгенерированного ИИ в Kuaishou, выросла с 26% до 60%. В статье мы разберём типичные сбои при AI Coding, подход «знания + ограничения» и четыре уровня защиты, а также соберём вопросы, которые помогут вашей команде проверить собственные процессы.

Доля кода, сгенерированного ИИ в Kuaishou, выросла с 26% в 25Q3 до 60% в 26Q2. Скорость генерации больше не является узким местом. Главный вопрос теперь в том, успевают ли средства проверки за этой скоростью. Технический эксперт Kuaishou Сюн Цзиюань выступит на AICon в Пекине с докладом «Управление дополнительными рисками AI Coding: внедрение контрольных проверок Skill и Harness». В анонсе уже раскрыли немало важных подробностей.

Это не общие рассуждения о том, что «ИИ опасно доверять написание кода». В анонсе говорится о нескольких выявленных сбоях в продакшене: проверочный Skill обнаружил в общей сложности более 3000 проблем, а для управления рисками уже разработали 415 правил в 7 категориях. Важно оговориться: пока доступен только анонс доклада. Данные о точности проверок, доле пропущенных проблем и ложных срабатываний, а также о сокращении числа сбоев обещают раскрыть на самом выступлении.

Что вы узнаете: пять типичных видов сбоев в коде, созданном ИИ, подход к управлению рисками на основе «знаний + ограничений» и четырёх уровней защиты, а также сможете проверить, успевают ли контрольные проверки вашей команды за скоростью генерации кода с помощью ИИ.

Главное о контрольных механизмах AI Coding

Собрали ключевые факты из анонса в одной таблице, чтобы быстро оценить масштаб управления AI Coding в Kuaishou.

Почему технический долг от AI Coding растёт по принципу сложного процента

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

Недавний публичный пример Google подтверждает этот вывод. За 11 часов автономной работы Gemini 4 Argon предложила варианты оптимизации кодовой базы ADK объёмом около 200 тысяч строк и выполнила все 16892 модульных теста. В итоге два предложения приняли, а ещё 4 отклонили при ручном ревью: они не соответствовали ожиданиям по надёжности, поддерживаемости, совместимости или фактической производительности. Даже для лучших моделей узкое место, похоже, сместилось с задачи «написать код» на задачу «надёжно его проверить».

Пять типичных сбоев AI Coding: анализ первопричин от Kuaishou

В анонсе причины сбоев в продакшене разделены на пять категорий: нехватка знаний о бизнесе и исторических ограничениях, а также отсутствие ограничений по производительности, безопасности и стилю кода. На основе перечисленных случаев мы составили таблицу для самопроверки. Столбец «Тип защитного механизма» — наше обобщение по логике материала, а не соответствия, опубликованные Kuaishou.

Что общего у этих сбоев AI Coding

У всех пяти типов сбоев есть общая черта: дело не в том, что модель недостаточно способна. Ей не хватает внутреннего контекста организации и понимания границ, которые нельзя нарушать. Неправильный SQL — это проблема знаний, которую помогают смягчить промпты и базы знаний. А вот когда модель намеренно пропускает проверку ради успешной компиляции, проблема другого рода: если ограничение остаётся на уровне «рекомендации», AI может счесть его препятствием и обойти.

Поэтому каждому техническому руководителю стоит запомнить одну мысль из анонса: ограничения нужно превращать в проверки, которые AI не может обойти. Правила в промпте — лишь напоминание. Настоящая защитная проверка встроена в процесс и способна заблокировать слияние или выпуск.

Решение для контрольного барьера AI Coding: «знания + ограничения»

Команда архитектурного управления Kuaishou предложила подход, основанный на двух составляющих — «знаниях + ограничениях», и интегрировала его в рабочий Harness в формате Skill. Правила разделили на две части:

• Знания (37 правил): сведения о компонентах и бизнесе, которые помогают предотвратить галлюцинации об API — например, когда ИИ вызывает несуществующий внутренний интерфейс или использует неверные параметры компонента.
• Ограничения (378 правил): нормативные правила по пяти направлениям — архитектура, стабильность, производительность, безопасность и качество кода.

Разница в количестве заслуживает внимания. Правил со знаниями немного, и они точечные: их задача — восполнить контекст компании, которого модели не хватает больше всего. Правил-ограничений гораздо больше: они превращают накопленные за годы командные нормы в исполняемые проверки. А вот подробное деление на 7 категорий и примеры правил в анонсе не раскрыли — их предстоит узнать из выступления.

Обеспечение качества Skill для контрольного барьера AI Coding

Сами правила тоже могут ошибаться. Слишком мягкие пропускают нарушения, слишком строгие дают ложные срабатывания. Если ложных срабатываний много, разработчики начинают искать способы обойти барьер, и он теряет смысл. Чтобы этого избежать, Kuaishou выстроила цикл обеспечения качества Skill из трёх этапов:

1. Разработка: проверка точности самих правил.
2. Допуск к выпуску: особое внимание пропущенным нарушениям и ложным срабатываниям; правило можно запустить только после выполнения требований.
3. Оценка результатов: постоянный мониторинг того, насколько эффективно правила блокируют нарушения после запуска.

Управлять правилами как «продуктом», который нужно тестировать, выпускать и отслеживать, — ключевая часть этой системы, о которой небольшие и средние команды чаще всего забывают.

Как устроены четыре уровня защиты при AI Coding

Kuaishou выстроила четыре линии защиты на разных этапах разработки. Каждая решает свою задачу и подстраховывает остальные.

Логика этой схемы проста: чем раньше обнаружена проблема, тем дешевле её устранить; чем позже проверка, тем шире охват. Harness работает на этапе написания кода и лучше всего учитывает специфику бизнеса, но каждому направлению нужно подключаться отдельно. Интеллектуальные проверки CR и ArchAgent не требуют изменений в бизнес-процессах, поэтому могут охватить всю компанию, но обнаруживают проблемы позже. В анонсе также отмечается, что эффективность каждой линии защиты подтверждают метриками процесса, а не оценивают на глаз.

Три варианта внедрения проверок AI Coding

В анонсе три бизнес-направления представляют типичные стадии подключения. На выступлении расскажут, с чего начинали в каждом случае, как устроен механизм, что удалось перехватить и каких затрат это потребовало:

• Основной сайт Mina: интеграция завершена, контроль качества уже ведётся.
• Зарубежный AIFlow: работает с разными технологическими стеками, внедрение продолжается.
• PandoraFlow в электронной коммерции: сложные бизнес-процессы, подключение с нуля.

Эти примеры полезны и другим командам: большинство компаний находится на одной из таких стадий и может сопоставить её со своей ситуацией.

Контрольные проверки AI Coding: с чего начать небольшой команде

415 правил и четыре линии защиты Kuaishou — результат работы крупной организации. Небольшим командам не обязательно копировать этот подход целиком. Ниже мы предлагаем шаги для старта, опираясь на логику исходного материала. Это не выводы Kuaishou, а рекомендации для ознакомления.

Первый шаг неслучайно стоит на первом месте: он почти ничего не стоит и при этом напрямую предотвращает одну из самых незаметных проблем — попытки AI пойти в обход проверок. Ниже — минималистичный скрипт, который запрещает пропускать проверки. Он использует детерминированные правила и не зависит от модели:

import re, subprocess, sys

# Получаем строки кода, добавленные в текущем коммите
diff = subprocess.run(["git", "diff", "--cached", "-U0"],
                      capture_output=True, text=True).stdout
added = [l for l in diff.splitlines() if l.startswith("+") and not l.startswith("+++")]

BYPASS = [r"#\s*noqa", r"//\s*nolint", r"@SuppressWarnings", r"pytest\.mark\.skip", r"eslint-disable"]
hits = [l for l in added for p in BYPASS if re.search(p, l)]
if hits:
    print("门禁拦截：检测到新增的检查豁免\n" + "\n".join(hits))
    sys.exit(1)

AI-ревью из четвёртого шага можно реализовать через любой OpenAI-совместимый интерфейс. В примере ниже несколько важных правил команды передаются как системный промпт, после чего модель проверяет diff:

import subprocess, openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # OpenAI-совместимый интерфейс APIYI
)

RULES = """你是代码评审门禁。仅依据以下规则检查 diff,逐条输出违规项，无违规输出 PASS:
1. 不得删除带有 compat/legacy 注释的兼容代码
2. 新建线程池必须设置有界队列和最大线程数
3. 涉及用户数据的接口必须有鉴权校验"""

diff = subprocess.run(["git", "diff", "origin/main...HEAD"],
                      capture_output=True, text=True).stdout

resp = client.chat.completions.create(
    model="gpt-4o-mini",  # Можно заменить на другую модель и сравнить результаты
    messages=[{"role": "system", "content": RULES},
              {"role": "user", "content": diff[:60000]}],
    temperature=0,
)
print(resp.choices[0].message.content)

import json, subprocess, sys, openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

def load_rules(path="ai_gate_rules.json"):
    """Файл правил: [{"id": "PERF-01", "text": "..."}]"""
    with open(path, encoding="utf-8") as f:
        return json.load(f)

def review(diff: str, rules: list, model: str = "gpt-4o-mini") -> dict:
    rule_text = "\n".join(f"[{r['id']}] {r['text']}" for r in rules)
    prompt = ("仅依据下列规则审查 diff。以 JSON 返回 "
              '{"violations":[{"rule_id":"","line":"","reason":""}]},无违规返回空数组。\n'
              + rule_text)
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": prompt},
                  {"role": "user", "content": diff[:60000]}],
        temperature=0,
        response_format={"type": "json_object"},
    )
    result = json.loads(resp.choices[0].message.content)
    result["usage"] = resp.usage.total_tokens  # Записываем расход токенов для оценки затрат
    return result

if __name__ == "__main__":
    diff = subprocess.run(["git", "diff", "origin/main...HEAD"],
                          capture_output=True, text=True).stdout
    if not diff.strip():
        sys.exit(0)
    result = review(diff, load_rules())
    print(json.dumps(result, ensure_ascii=False, indent=2))
    # При нарушениях блокируем; также рекомендуется записывать результат в лог для подсчёта выявлений и ложных срабатываний
    sys.exit(1 if result.get("violations") else 0)

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

🚀 Официальная рекомендация: при создании AI-проверки для допуска изменений сначала сравните долю выявленных нарушений и ложных срабатываний нескольких моделей на одной и той же подборке прошлых PR. Через APIYI apiyi.com можно вызывать модели OpenAI, Claude, Gemini и других разработчиков с одним API-ключом. Для переключения достаточно изменить параметр model, а новым пользователям доступна бесплатная квота для тестирования.

Анализ влияния контрольных проверок AI Coding

Влияние на команды разработки

• Смещение фокуса ревью: чем больше кода пишет ИИ, тем сложнее проверять его вручную построчно. Командам приходится переключаться с «просмотра кода» на поддержку правил и контрольных проверок.
• Правила становятся активом: знания о бизнесе и уроки прошлых инцидентов нужно превращать в исполняемые правила, а не оставлять их разбросанными по документации и в головах опытных сотрудников.
• Новая статья расходов: чем больше правил и чем чаще проводится ревью, тем выше расход токенов. Kuaishou отдельно указала среди результатов проекта «необходимость оптимизации затрат на токены». Это говорит о том, что при масштабном внедрении проблема уже вполне реальна, хотя конкретные цифры пока не раскрыты.

Влияние на отрасль

• От конкуренции в генерации к конкуренции в управлении: и случай с Google Argon, и практика Kuaishou показывают, что на следующем этапе разницу будут определять возможности валидации, ревью и управления работой систем в продакшене.
• Инженерный подход к Harness: включение знаний, ограничений, тестов и циклов обратной связи в среду выполнения агента становится стандартной практикой при внедрении Coding Agent в компаниях.
• Борьба с ложными срабатываниями станет долгосрочной задачей: по мере роста числа правил поддерживать их точность и не допускать усталости разработчиков от уведомлений будет сложнее, чем писать сами правила.

💰 Совет по затратам: оценивая расход токенов на контрольные проверки с ИИ-ревью, начните с учёта фактического потребления в небольшой группе репозиториев. APIYI apiyi.com предлагает оплату по фактическому использованию и статистику расхода — это поможет оценить затраты на полномасштабное внедрение.

Частые вопросы FAQ

AI Coding: главное о проверках качества

• Генерация больше не узкое место: доля AI-кода в Kuaishou за год выросла с 26% до 60%, а вот возможности проверки не успевают за ней.
• Пять типичных причин сбоев: нехватка бизнес-знаний и исторических правил контроля, а также ограничений по производительности, безопасности и стилю кода.
• Ограничения нужно закреплять обязательными проверками: ради успешной компиляции AI может пропустить проверку, поэтому одних «рекомендаций» в промпте недостаточно.
• Знаниями и ограничениями управляют отдельно: 37 правил, связанных со знаниями, помогают избежать галлюцинаций, а 378 ограничений обеспечивают соблюдение стандартов.
• Четыре взаимодополняющие линии защиты: Harness при написании кода, подстраховка через плагин, интеллектуальное ревью кода и ArchAgent в продакшене.
• Сами правила тоже нужно тестировать: цикл из разработки, проверки перед выпуском и отзыва правил помогает контролировать пропущенные проблемы и ложные срабатывания.
• Небольшим командам стоит начать с обязательных проверок: прежде всего не допускать их пропуска, а AI-ревью можно недорого опробовать через APIYI apiyi.com.

Итоги

Анонс выступления Kuaishou даёт понятный ориентир для управления AI Coding:

1. Оценка проблемы: объём AI-кода растёт быстрее, чем возможности его проверки, технический долг накапливается всё быстрее, а сбои в продакшене уже происходят.
2. Методология: сочетание знаний и ограничений, встроенных в процесс разработки в виде Skill. Качество самих правил тоже контролируется в рамках замкнутого цикла.
3. Структура внедрения: четыре линии защиты — написание кода, плагин, ревью и продакшен. Путь выбирается в зависимости от того, подключено ли к системе соответствующее направление бизнеса.

Командам, которые уже широко используют AI для программирования, можно начать с самопроверки по таблицам пяти типов сбоев и четырёх линий защиты из этой статьи: они помогут понять, какие уровни охвачены проверками. За полными данными об эффективности и деталями реализации стоит следить на официальном выступлении в декабре.

Если вы планируете опробовать AI-ревью на этапе PR, рекомендуем через APIYI apiyi.com быстро сравнить качество ревью и расход токенов у разных моделей, а затем решить, сколько ресурсов в это вкладывать.

📚 Источники

1. InfoQ — Управление дополнительными рисками AI Coding: проверки Skill и внедрение Harness｜AICon Beijing: оригинальный анонс выступления Kuaishou
2. Ссылка: infoq.cn/article/XieGrL5pws7jG1zxKPle

3. Описание: данные о доле кода, написанного ИИ, количестве правил, четырёх рубежах защиты и плане выступления

4. InfoQ — Google за ночь оптимизировала 200 тысяч строк кода в кодовой базе ADK с помощью Gemini 4 Argon: пример использования Coding Agent для переработки существующей кодовой базы

5. Ссылка: infoq.cn/article/u4fAoAH5vZPCV4TVqAcO
6. Описание: данные о результатах работы агента и доле изменений, отклонённых при ручной проверке. Косвенно подтверждают, что именно проверка становится узким местом

Автор: техническая команда APIYI
Технические вопросы: связаться с нами можно через главную страницу APIYI apiyi.com. Дополнительные материалы по интеграции доступны в центре документации docs.apiyi.com