Учебник по API Grok 4.7: создаём ИИ‑ревьюера схемотехники

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

Хотелось понять, сможет ли Grok 4.7 выполнить всё ревью целиком. Руководство по Grok 4.7 утверждает, что модель обучали для длительных задач и более тщательной самопроверки. Схема также даёт нам числа, которые можно проверить обычным Python‑кодом, так что не нужен ещё один ИИ для оценки результата.

Для эксперимента была собрана EnviroNode Rev A — небольшая датчиковая плата с питанием от USB — и в её схему внедрены три ошибки. Grok не сообщает, сколько ошибок существует. Он должен найти их, подтвердить каждую документами по компонентам, предложить исправления и проверить скорректированные значения в Python.

Чтобы следить за ходом эксперимента, не нужно образование в области электротехники. Каждое правило поясняется при первом появлении. Вы узнаете, как:

• Отправить изображение схемы в Grok 4.7 через Responses API

• Прикрепить даташиты с помощью Files API и дать Grok искать по ним

• Проверять расчёты с выполнением кода, а пределы — с помощью веб‑поиска

• Дать Grok локальную функцию verify_design(), которая выносит вердикт «принято/не принято»

• Удерживать длинный, насыщенный документами диалог в пределах контекста модели

• Вернуть согласованный формат ревью и сравнить уровни рассуждения

Одна и та же плата остаётся в фокусе от первого просмотра изображения до финальной проверки в Python.

Кратко

Grok 4.7 нашёл все внедрённые ошибки после получения даташитов, а исправленный дизайн прошёл проверки Python. Это говорит именно об этих трёх ошибках, а не о ревью схем вообще.

• Без документов Grok отказался гадать: одно подтверждённое несоответствие по изображению, а пределы регулятора и АЦП (ADC) отправлены в «нужны доказательства».
• Даташиты превратили подозрения в доказательства: каждое замечание ссылается на значение из документа; корректные компоненты не были ошибочно помечены.
• Тяжёлые по файлам ходы могут выработать долгий контекст: после повторных поисков по PDF продолжение превысило окно в 500K; исправленный цикл сжимает историю перед следующим ходом.
• low прошёл валидатор, но выявил «слепую зону»: значения фильтра уложились в прописанные проверки, оставив вне теста ёмкостную нагрузку и установление режима.

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

Что такое API Grok 4.7?

API Grok 4.7 даёт Python‑приложениям текстовый и графический ввод, текстовый вывод и контекстное окно на 500 000 токенов через идентификатор модели grok-4.7. В официальном руководстве перечислены уровни рассуждения low, medium, high (по умолчанию) и xhigh; рассуждения нельзя отключить. API также поддерживает вызов функций, структурированные ответы, веб‑поиск, поиск по X и выполнение кода.

Наш обзор Grok 4.7 охватывает запуск и бенчмарки. SpaceXAI помечает Chat Completions как устаревшие, поэтому все примеры здесь используют Responses API.

Сколько стоит Grok 4.7?

До 200 000 токенов промпта Grok 4.7 стоит $2 за миллион входных токенов, $0.50 за миллион кешированных входных токенов и $6 за миллион выходных токенов. Как только промпт достигает 200 000 токенов, каждый токен в этом запросе тарифицируется по $4, $1 и $12.

Серверные инструменты тарифицируются отдельно: на странице цен указано $5 за 1 000 вызовов веб‑поиска или выполнения кода. Поиск по прикреплённым документам стоит один цент за запрос, а хранение документов дополнительно тарифицируется по суточной ставке за ГиБ. Используйте стабильный prompt_cache_key для связанных запросов, но планируйте бюджет с учётом некешированных входных данных.

Считывайте стоимость из usage.cost_in_usd_ticks. В документации по отслеживанию стоимости сказано, что она включает кеширование и оплату инструментов. Поделите значение на 10^10, чтобы получить доллары.

Почему тестировать Grok 4.7 на схемотехнике?

Проектирование схем одновременно проверяет чтение документов, расчёты, использование инструментов и верификацию. SpaceXAI сообщает 64,0% для Grok 4.7 на EEBench. Методология EEBench опирается на симуляции и проверку спецификации (BOM), а не на оценку LLM, и EnviroNode следует тому же принципу.

Что мы построим: ревью схемы EnviroNode Rev A

EnviroNode Rev A — датчиковый узел с питанием от USB. Полный проект можно скачать с GitHub.

На схеме есть все номиналы, необходимые Grok для ревью. У каждого требования есть идентификатор, например PWR-002 или BW-001, чтобы каждую находку можно было привязать к конкретному правилу.

Схема EnviroNode Rev A с номиналами. Изображение автора.

Прежде чем Grok начнёт ревью платы, раскройте все правила, которые будет использовать валидатор. Функция возвращает пять проверок «принято/не принято», построенных на этих восьми требованиях:

• PWR-001: Вход USB остаётся в диапазоне 4,75–5,25 В
• PWR-002: Регулятор покрывает пиковую нагрузку
• PWR-003: Нагрузки, кроме МК, укладываются в бюджет 10 мА
• SIG-001: Полный диапазон датчика — 1,0 В
• ADC-001: Вход АЦП не превышает 2 250 мВ
• ADC-002: Вход АЦП достигает как минимум 1 500 мВ
• BW-001: Сигналы до 100 Гц теряют менее 1 дБ
• BW-002: Частота среза фильтра не превышает 500 Гц

Модель получает тот же набор требований. Ни одно ограничение валидатора не появляется только после того, как Grok предложит исправление.

Какие три ошибки были внедрены?

Три ошибки проверяются цифрами. Их количество не упоминается в промпте.

• Регулятор слишком мал (PWR-002): TI TLV700 рассчитан на 200 мА, тогда как даташит ESP32‑C3 указывает пик 335 мА при передаче по Wi‑Fi, а чек‑лист схем Espressif требует как минимум 500 мА.

• Перегрузка входа АЦП (ADC-001): коэффициент усиления 3 даёт 3,0 В на АЦП, но эффективный диапазон по даташиту ограничен 2 500 мВ, а требование допускает 90% от этого.

• Фильтр слишком медленный (BW-001): 10 кОм и 1 мкФ дают частоту среза 15,9 Гц, тогда как сигналы до 100 Гц могут терять не более 1 дБ.

Дефект АЦП относится к диапазону измерения, а не к повреждению вывода. Корректные решения, такие как резистор светодиода и задержка CHIP_EN, позволяют измерить ложноположительные случаи.

Как работает цикл ревью?

Нужна чёткая граница: Grok предлагает изменения, а Python выносит вердикт «принято/не принято». Диаграмма показывает, где документы и инструменты входят в цикл.

Цикл ревью разделяет предложение и проверку. Изображение автора.

Определите успех до первого вызова API. Считайте дефектом только то, что Grok связал с требованием и доказательствами. Считайте исправлением только то, когда verify_design() вернуло all_pass = true.

Как настроить API Grok 4.7 в Python

Понадобится ключ API xAI с предоплаченными кредитами, Python 3.10 или новее и SDK OpenAI для Python, направленный на базовый URL xAI. Создайте ключ в консоли xAI, затем установите пакеты ниже.

python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install openai python-dotenv pydantic httpx streamlit
pip install matplotlib schemdraw pytest  # Optional diagrams and verifier tests

Примеры API используют первую группу пакетов; вторая поддерживает диаграммы и тесты репозитория. Они были проверены с Python 3.11.9, openai 3.19.2, pydantic 2.13.5, streamlit 1.64.0 и httpx 0.28.1. Сохраните ключ в переменной окружения XAI_API_KEY и загружайте его с помощью python-dotenv вместо размещения в исходниках; наш гид по виртуальным окружениям поможет, если это ново для вас.

Сделайте первый вызов API Grok 4.7

Если ваш ключ уже работает с Responses API, переходите к Шагу 1. Иначе этот запрос разом проверит ключ, базовый URL и идентификатор модели.

import os
import httpx
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI(api_key=os.environ["XAI_API_KEY"], base_url="https://api.x.ai/v1",
                timeout=httpx.Timeout(3600.0))

response = client.responses.create(
    model="grok-4.7",
    reasoning={"effort": "low"},
    input="In one sentence, what does a low-dropout regulator do?",
)
print(response.output_text)

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

Шаг 1: Может ли Grok 4.7 ревьюировать схему по изображению?

Да, Grok 4.7 может провести ревью схемы только по изображению, если в промпте прямо указать, что инструменты не будут использоваться. Базовый вариант отправляет PNG как data URL в base64 вместе с текстом требований.

image = {
    "type": "input_image",
    "image_url": f"data:image/png;base64,{SCHEMATIC_B64}",
    "detail": "high",
}
response = client.responses.create(
    model="grok-4.7",
    input=[{"role": "user", "content": [
        image,
        {"type": "input_text", "text": REVIEW_PROMPT},
    ]}],
)

Промпт просит три раздела: подтверждено, нужны дополнительные доказательства, проверено и приемлемо. В нём нет числа дефектов или подозреваемого компонента.

Что показал обзор только по изображению?

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

Как указано в кратком изложении, Grok подтвердил дефект фильтра с частотой среза 15,9 Гц и ослаблением 16,1 дБ на 100 Гц. Регулятор и АЦП он поместил в «нужны дополнительные доказательства», не угадывая их пределы.

Шаг 2: Как добавить даташиты через Files API

Прикреплённые документы превращают расплывчатое подозрение в утверждение, подкреплённое числами. Загружайте каждый документ один раз и ссылайтесь на него по file_id.

with open(DATASHEET_PATH, "rb") as datasheet:
    uploaded = client.files.create(
        file=datasheet,
        purpose="assistants",
        expires_after={"anchor": "created_at", "seconds": 7 * 24 * 3600},
    )
content = [image, *[{"type": "input_file", "file_id": fid} for fid in file_ids],
           {"type": "input_text", "text": EVIDENCE_PROMPT}]

Поскольку в этом учебнике задано expires_after на семь дней, кешированные ID действительны только в этот период. Без expires_after xAI хранит загруженные файлы, пока вы их не удалите.

В ответах SDK OpenAI, зафиксированных здесь, поиск по вложениям отображался как элементы custom_tool_call с именами pdf_search и pdf_browse, а usage учитывал их в document_search_calls. Это наблюдаемое поведение, а не общий контракт типов инструментов, поэтому цикл также проверяет документированный счётчик использования.

Как даташиты меняют ревью?

Документы разрешили два открытых вопроса из Шага 1 и подкрепили выводы по питанию, АЦП и фильтру. По регулятору приводилась ссылка на номинал TLV700 в 200 мА, пик 335 мА у ESP32‑C3 при передаче и рекомендацию источника на 500 мА.

Для фильтра Grok вычислил, какие значения конденсатора удовлетворят обоим правилам по полосе при неизменном R5: примерно 32–81 нФ. Все ложные приманки попали в «проверено и приемлемо» с пояснением.

Шаг 3: Как проверить расчёты с выполнением кода Grok 4.7

Выполнение кода — это серверная песочница Python от xAI, добавляемая в tools как {"type": "code_interpreter"} при использовании клиента OpenAI. Промпт добавляет правило: каждое утверждение с числом должно быть вычислено, чтобы считаться подтверждённым.

Как сказано в руководстве по выполнению кода, песочница не имеет сетевого доступа и не сохраняет состояние между запросами. Для нескольких чисел из даташитов этого достаточно.

Какие расчёты должен проверить Grok?

Попросите Grok проверить бюджет питания, диапазон АЦП и полосу фильтра в одном скрипте. Если схемы — не ваше, пропустите вывод ниже; суть следует за ним.

f=  100.0 Hz  |H|=0.157177  attenuation=16.0722 dB
fc required for <= 1 dB at 100 Hz: fc >= 196.5227 Hz
V_adc_fs = 3.0000 V
90% limit = 2.2500 V
required rating = max(headroom, mcu min) = 500.00 mA

Минимальная частота среза 196,5 Гц — это число, от которого зависит исправление фильтра, и его вычисляет код, а не арифметика модели. Даже при минимальном ослаблении на «толчковом» углу допусков потери на 100 Гц превышают 15 дБ, так что вывод остаётся в силе.

Шаг 4: Может ли Grok 4.7 искать в вебе через API?

Да. Веб‑поиск проверяет актуальность прикреплённых документов, ведь производители обновляют даташиты после среза обучения модели. Ограничьте его официальными доменами, чтобы доказательства были первоисточниками.

tools = [
    {"type": "code_interpreter"},
    {"type": "web_search", "filters": {"allowed_domains": ["ti.com", "espressif.com"]}},
]

Руководство по веб‑поиску позволяет до пяти allowed_domains, включая поддомены вроде docs.espressif.com. Я бы оставил этот шаг даже при актуальных прикреплённых даташитах — он может поймать ревизию, опубликованную после вашей загрузки.

Что доказывают цитаты?

Grok должен ссылаться на актуальную страницу продукта TI, документацию ESP32‑C3, аппаратный чек‑лист и релевантные errata. Рассматривайте цитаты как свидетельство источника, а не гарантию правильности инженерного вывода.

Фильтры доменов всё равно могут вернуть нерелевантную страницу. Проверьте, что каждая ссылка поддерживает именно тот компонент и предел, которые использованы в расчёте.

Grok ищет в файлах, считает, сверяет источники. Изображение автора.

Шаг 5: Как добавить валидатор через вызов функций Grok 4.7

verify_design() — это обычная Python‑функция, работающая на вашей машине, и только она решает, прошла ли ревизия. Grok предлагает значения дизайна через вызов функций, а функция проверяет их по фиксированным пределам.

VERIFY_DESIGN_TOOL = {
    "type": "function",
    "name": "verify_design",
    "description": "Deterministically check an EnviroNode revision against EN-REQ-001...",
    "parameters": {
        "type": "object",
        "properties": {
            "revision": {"type": "string"},
            "regulator_part": {"type": "string"},
            "gain_rf_ohm": {"type": "number"},
            "gain_rg_ohm": {"type": "number"},
            "filter_r_ohm": {"type": "number"},
            "filter_c_nf": {"type": "number"},
        },
        "required": ["revision", "regulator_part", "gain_rf_ohm",
                     "gain_rg_ohm", "filter_r_ohm", "filter_c_nf"],
    },
}

Мощность должна удовлетворять max((335 + 10) mA × 1.25, 500 mA). Для АЦП 1.0 V × (1 + Rf/Rg) должно оставаться между 1 500 и 2 250 мВ. Проверки фильтра измеряют потери на 100 Гц и ограничивают частоту среза 500 Гц; каждая проверка возвращает значение, предел и «принято/не принято».

Схема инструмента лишь говорит Grok, какие значения отправлять. Основная логика «принято/не принято» — это обычный Python:

import math

part = PARTS.get(regulator_part.strip().upper())
required_ma = max((335 + 10) * 1.25, 500)
power_ok = (
    part is not None
    and float(part["rated_iout_ma"]) >= required_ma
    and float(part["vin_max_v"]) >= 5.25
    and float(part["vout_v"]) == 3.3
)

gain = 1 + gain_rf_ohm / gain_rg_ohm
adc_mv = gain * 1000

fc = 1 / (2 * math.pi * filter_r_ohm * filter_c_nf * 1e-9)
loss_db = 10 * math.log10(1 + (100 / fc) ** 2)

checks = {
    "PWR-002": power_ok,
    "ADC-001": adc_mv <= 2250,
    "ADC-002": adc_mv >= 1500,
    "BW-001": loss_db <= 1.0,
    "BW-002": fc <= 500,
}
return {"all_pass": all(checks.values()), "checks": checks}

Полная функция также отклоняет некорректные значения и возвращает измерения вместе с результатами. Протестируйте её на заведомо хорошем дизайне, заведомо плохом, неизвестном компоненте и пограничном случае.

Почему оценивать исправления должен код, а не модель?

Держите номиналы компонентов вне контроля модели. Я бы не позволял модели самой указывать номинал тока. Grok присылает номер детали, а функция смотрит номинал в каталоге приложения.

Агент не должен одновременно предлагать решение и решать, верно ли оно, если ответ можно проверить кодом. Заменяйте verify_design() на набор тестов или проверку схемы, когда задача меняется. Написать валидатор — дополнительная работа, но его вердикт не зависит от мнения модели.

Шаг 6: Как перепроектировать и проверить схему

Поставьте Grok одну цель: исправить каждое подтверждённое нарушение минимально разумным набором изменений и не считать дизайн завершённым, пока ранее определённая проверка не пройдена. Предоставьте доказательства и инструменты из Шагов 3–5, затем задайте лимит запросов.

Здесь важна оговорка о контексте из «Кратко». Решите её до добавления новых ходов.

Почему циклам с множеством файлов нужно сжатие контекста?

Продолжение запроса включает предыдущие результаты инструментов, а поиски по документам могут вернуть много текста. В неудачном прототипе следующее продолжение достигло 1 116 321 токена и превысило окно 500 000 токенов Grok 4.7.

Сжатие контекста не спасёт запрос, который уже вышел за предел. Исправленный цикл сжимает каждый ход с поиском по документам перед отправкой следующего запроса.

details = (response.usage.model_extra or {}).get(
    "server_side_tool_usage_details", {}
)
observed_attachment_call = any(
    item.type == "custom_tool_call"
    and item.name in {"pdf_search", "pdf_browse"}
    for item in response.output
)
used_documents = (
    details.get("document_search_calls", 0) > 0
    or observed_attachment_call
)

if used_documents:
    compacted = client.responses.compact(
        model="grok-4.7", input=history + list(response.output) + follow_up)
    history = list(compacted.output)  # pass the compaction item back unchanged
    # Compaction drops tool output, so restate the verifier's verdict ourselves.
    history.append({"role": "user", "content":
                    "verify_design results, exactly as returned: " + json.dumps(results)})
else:
    history = history + list(response.output) + follow_up
response = client.responses.create(model="grok-4.7", input=history, tools=TOOLS,
                                   store=False, prompt_cache_key=cache_key)

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

Прошла ли Rev B проверку?

Да. Grok заменил по одному компоненту в каждой падающей подсистеме: питание, усиление АЦП и полоса фильтра. Диаграмма показывает точные значения Rev A и Rev B.

Три изменения компонентов исправляют Rev A. Изображение автора.

Скорректированные значения затем идут в verify_design(). Она возвращает результат по каждому требованию.

Обновлённый дизайн проходит все проверки. Изображение автора.

Неуспешный результат возвращается как function_call_output, поэтому Grok может пересматривать дизайн, пока проверки не пройдут или не будет достигнут лимит запросов.

Шаг 7: Как вернуть структурированное ревью схемы

Структурированные ответы возвращают объект, соответствующий схеме, вместо текста, который пришлось бы разбирать. Вызовите client.responses.parse() с моделью Pydantic в том же разговоре, отключив инструменты.

class Finding(BaseModel):
    violated_requirement: str
    severity: Literal["blocker", "major", "minor"]
    evidence: list[str]
    recommended_change: str
    verifier_result: Literal["pass", "fail", "not_verified"]

parsed = client.responses.parse(
    model="grok-4.7", input=history + [REPORT_REQUEST],
    text_format=DesignReview, tools=TOOLS, tool_choice="none", store=False,
)

Корректная схема не доказывает, что содержание верно, поэтому включите результаты валидатора и попросите Grok основывать verifier_result на них. Затем JSON можно отправить в трекер задач или очередь на утверждение.

Что показало структурированное ревью?

Структурированный отчёт должен отметить каждый изначальный дефект как исправленный, сослаться на измеренное валидатором значение и оставить нетестированные риски в open_risks. В этом дизайне к ним относятся регулятор, который ровно на нижней границе 500 мА, и конденсатор на входе АЦП, отличающийся от рекомендации Espressif.

Улучшает ли повышенное усилие рассуждения Grok 4.7 ревью схемы?

Повышенное усилие не улучшило счёт валидатора, но повлияло на качество исправления фильтра. Каждый уровень получил одну и ту же схему, промпт, инструменты и лимит запросов.

low уменьшил резистор и оставил конденсатор 1 мкФ, оставив вне валидатора вопросы ёмкостной нагрузки и установления. В рекомендациях Microchip по ёмкостной нагрузке говорится, что последовательный резистор может повысить устойчивость, так что это не доказывает, что фикс неустойчив; это повод для частотной/ступенчатой/лабораторной проверки. high вместо этого изменил конденсатор, а xhigh выбрал те же финальные значения, что и high, после дополнительного вызова валидатора.

Когда стоит использовать xhigh‑рассуждение?

В этом единичном сравнении high дал лучший баланс. Он избежал немоделированного риска нагрузки без лишнего вызова валидатора, как у xhigh. Один прогон на уровень не устанавливает общего рейтинга.

Исправил ли Grok 4.7 схему?

Ответ на начальный вопрос — да, в пределах пяти проверок валидатора. Таблица сводит предыдущие результаты в одну картину.

• Изображение и требования
  • Что добавляет: Визуальный осмотр
  • Итог: Подтверждает то, что схема сама по себе может доказать
• Даташиты
  • Что добавляют: Пределы производителей
  • Итог: Превращают два открытых вопроса в выводы
• Выполнение кода
  • Что добавляет: Проверенные расчёты
  • Итог: Измеряет проблемы с питанием и фильтром
• Веб‑поиск
  • Что добавляет: Актуальные официальные источники
  • Итог: Проверяет, актуальны ли прикреплённые доказательства
• Локальный валидатор
  • Что добавляет: Вердикт «принято/не принято» из Python
  • Итог: Принимает только ревизию, прошедшую все правила

Grok исправил закодированные требования. Он не доказал, что обновлённая плата электрически полноценна или готова к производству.

Документы решают, есть ли у опасения доказательства. Python решает, проходит ли ревизия. Гладкий текст не заменяет ни то, ни другое.

Посмотрите ревью в Streamlit

Наш гид по Streamlit объясняет использованный интерфейс. Он применяет стриминг, чтобы показывать вызовы инструментов по мере поступления, затем отображает проверки валидатора и финальный отчёт.