Grok 4.7 API-handledning: Bygg en AI-granskare för kretsscheman

Ett kretsschema är en bild som visar hur elektroniska komponenter kopplas ihop. Att granska ett sådant innebär att kontrollera om komponenterna och deras värden uppfyller konstruktionskraven. Kan strömförsörjningen leverera tillräcklig ström? Kan processorn läsa av sensorns fulla utsignal? Svaren kommer från schemat, komponenternas datablad och några beräkningar.

Jag ville se om Grok 4.7 kunde genomföra hela den granskningen. Guiden för Grok 4.7 säger att modellen tränats för längre uppgifter och för att kontrollera sitt eget arbete mer noggrant. En krets ger oss också tal som vanlig Python-kod kan verifiera, så vi behöver inte en annan AI-modell för att bedöma resultatet.

För experimentet byggde jag EnviroNode Rev A, ett litet USB-driven sensor­kort, och planterade tre fel i dess konstruktion. Grok får inte veta hur många fel som finns. Den måste hitta dem, styrka varje fynd med komponentdokumentation, föreslå korrigeringar och skicka de korrigerade värdena till Python-kontroller.

Du behöver ingen bakgrund i elektroteknik för att hänga med. Jag förklarar varje kretssregel när den dyker upp första gången. Du lär dig hur du:

• Skickar en schemabild till Grok 4.7 via Responses API

• Bifogar datablad med Files API och låter Grok söka i dem

• Kontrollerar beräkningar med kodkörning och gränser med webbsökning

• Ger Grok en lokal verify_design()-funktion som avgör godkänd eller underkänd

• Håller en lång, dokumenttung konversation inom modellens kontextgräns

• Returnerar ett konsekvent granskningsformat och jämför sedan resonemangsnivåer

Samma kort ligger till grund från första bildgranskningen till den sista Python-kontrollen.

Sammanfattning

Grok 4.7 hittade alla planterade fel när den fick datablad, och den korrigerade konstruktionen klarade Python-kontrollerna. Det säger något om just dessa tre fel, inte om kretsgranskning i allmänhet.

• Utan dokument vägrade Grok att gissa: bilden ensam gav ett bekräftat fel, och regulatorns och ADC:ns gränser hamnade under ”behöver bevis”.
• Datablad förvandlade misstanke till bevis: varje fynd citerade ett dokumentvärde, utan att en korrekt komponent flaggades.
• Filintensiva vändor kan tömma långtidskontexten: efter upprepade PDF-sökningar överskred en fortsättning 500K-fönstret; den åtgärdade loopen komprimerar innan nästa vända.
• Low klarade verifieraren men blottlade en blind fläck: dess filtervärden uppfyllde de skrivna kontrollerna men lämnade kapacitiv last och insvängningsbeteende otestade.

Detta är ett litet kort, inte ett riktmärke. Ett kort med ett dussin datablad skapar större kontext och kan ge andra resultat.

Vad är Grok 4.7 API?

Grok 4.7 API ger Python-appar text- och bildinmatning, textutmatning och ett kontextfönster på 500 000 token via modell-ID grok-4.7. Den officiella guiden listar resonemangsnivåerna low, medium, high (standard) och xhigh; resonemang kan inte stängas av. API:et stöder även funktionsanrop, strukturerade utdata, webbsökning, X-sökning och kodkörning.

Vår översikt av Grok 4.7 täcker lanseringen och riktmärkena. SpaceXAI märker Chat Completions som föråldrat, så alla exempel här använder Responses API.

Vad kostar Grok 4.7?

Under 200 000 prompt-token kostar Grok 4.7 2 $ per miljon indatatoken, 0,50 $ per miljon cachade indatatoken och 6 $ per miljon utdata­token. När en prompt når 200 000 token debiteras varje token i den begäran med 4, 1 respektive 12 $.

Serverbaserade verktyg har separata avgifter: prissidan tar 5 $ per 1 000 webbsökningar eller kodkörningsanrop. Sökningar i bifogade dokument kostar ett öre styck, och lagrade dokument har också en daglig avgift per GiB. Använd en stabil prompt_cache_key för relaterade begäranden, men budgetera för icke-cachad indata.

Läs debiterad kostnad från usage.cost_in_usd_ticks. Dokumentationen för kostnadsspårning säger att den inkluderar cache och verktygsavgifter. Dela värdet med 10^10 för dollar.

Varför testa Grok 4.7 på kretkonstruktion?

Kretkonstruktion testar dokumentläsning, beräkningar, verktygsanvändning och verifiering i en och samma uppgift. SpaceXAI rapporterar 64,0 % för Grok 4.7 på EEBench. EEBench-metodiken använder simuleringar och BOM-kontroller (stycklista) istället för en LLM-domare, och EnviroNode följer samma princip.

Vad vi bygger: Granskning av EnviroNode Rev A

EnviroNode Rev A är en USB-driven sensornod. Du kan ladda ner hela projektet från GitHub.

Schematiskt finns alla komponentvärden Grok behöver för granskningen. Varje krav har ett ID såsom PWR-002 eller BW-001, så att varje fynd kan peka tillbaka till en regel.

EnviroNode Rev A schematisk med värden. Bild av författaren.

Innan Grok granskar kortet, exponera varje regel som verifieraren kommer att använda. Funktionen returnerar fem godkänd/underkänd-kontroller byggda från dessa åtta krav:

• PWR-001: USB-ingången ligger mellan 4,75 V och 5,25 V
• PWR-002: Regulatorn täcker toppbelastning
• PWR-003: Icke-MCU-laster använder en budget på 10 mA
• SIG-001: Sensorns fullskala är 1,0 V
• ADC-001: ADC-ingången ligger på eller under 2 250 mV
• ADC-002: ADC-ingången når minst 1 500 mV
• BW-001: Signaler upp till 100 Hz förlorar mindre än 1 dB
• BW-002: Filteravskärningen ligger på eller under 500 Hz

Modellen får samma kravuppsättning. Ingen verifierargräns dyker bara upp efter att Grok föreslår en åtgärd.

Vilka är de tre planterade felen?

Tre fel kan kontrolleras med siffror. Deras antal hålls utanför prompten.

• För liten regulator (PWR-002): TI TLV700 är märkt för 200 mA, medan ESP32-C3-databladet listar en Wifi-sändningstopp på 335 mA och Espressifs schematickontrollista kräver minst 500 mA.

• ADC överspann (ADC-001): en förstärkning på 3 ger 3,0 V till ADC:n, men databladets effektiva område toppar vid 2 500 mV, och kravet tillåter 90 % av det.

• För långsamt filter (BW-001): 10 kΩ och 1 µF ger en avskärning på 15,9 Hz, medan signaler upp till 100 Hz får förlora högst 1 dB.

ADC-felet gäller mätområde, inte skador på pinnen. Korrekta val, såsom LED-resistorn och CHIP_EN-fördröjning, gör falska positiva mätbara.

Hur fungerar granskningsloopen?

Granskningen behöver en tydlig gräns: Grok föreslår ändringar, medan Python avgör godkänd eller underkänd. Diagrammet visar var dokument och verktyg kommer in i loopen.

Granskningsloop separerar förslag från verifiering. Bild av författaren.

Definiera framgång innan första API-anropet. Räkna ett fel först när Grok kopplar det till ett krav och stödjande bevis. Räkna en fix först när verify_design() returnerar all_pass = true.

Så sätter du upp Grok 4.7 API i Python

Du behöver en xAI API-nyckel med förbetalda krediter, Python 3.10 eller nyare och OpenAI:s Python-SDK pekat mot xAI:s bas-URL. Skapa nyckeln i xAI Console, och installera sedan paketen nedan.

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  # Valfria diagram och verifieringstester

API-exemplen använder den första paketgruppen; den andra stöder diagram och tester i repot. Jag testade med Python 3.11.9, openai 3.19.2, pydantic 2.13.5, streamlit 1.64.0 och httpx 0.28.1. Spara nyckeln som miljövariabeln XAI_API_KEY och ladda den med python-dotenv istället för att lägga den i källkod; vår guide till virtuella miljöer förklarar inställningen om den är ny för dig.

Gör ditt första Grok 4.7 API-anrop

Om din nyckel redan fungerar med Responses API, hoppa till Steg 1. Annars kontrollerar den här begäran nyckeln, bas-URL:en och modell-ID i ett svep.

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)

Ett svar på en mening betyder att uppsättningen fungerar. Den långa timeouten spelar roll senare, eftersom begäranden som använder resonemang och verktyg kan ta flera minuter.

Steg 1: Kan Grok 4.7 granska en krets från en bild?

Ja, Grok 4.7 kan granska ett schema enbart från en bild, så länge prompten uttryckligen säger att inga verktyg kommer. Baslinjen skickar PNG:n som en base64-data-URL tillsammans med kravtexten.

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},
    ]}],
)

Prompten ber om tre avsnitt: bekräftat, behöver mer bevis samt kontrollerat och acceptabelt. Den nämner inte antalet fel eller en misstänkt komponent.

Vad hittade bild‑endast‑granskningen?

Tala om uttryckligen när inga verktyg eller datablad finns tillgängliga. Annars kan modellen avsluta svaret efter att ha sagt att den ska slå upp en specifikation som den inte kan komma åt.

Som nämnts i sammanfattningen bekräftade Grok filterfelet med 15,9 Hz avskärning och 16,1 dB förlust vid 100 Hz. Den placerade regulatorn och ADC:n under ”behöver mer bevis” istället för att gissa deras gränser.

Steg 2: Hur lägger man till datablad med Files API

Bifogade dokument förvandlar en vag oro till ett påstående som stöds av siffror. Ladda upp varje dokument en gång och referera det via 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}]

Eftersom denna handledning sätter expires_after till sju dagar, är cachade ID:n bara giltiga inom det fönstret. Utan expires_after behåller xAI uppladdade filer tills du tar bort dem.

I OpenAI-SDK:ns svar som fångats här dök bilagesökning upp som custom_tool_call-objekt med namnen pdf_search och pdf_browse, medan användningen räknade dem under document_search_calls. Det är observerat beteende, inte det allmänna kontraktet för verktygstyp, så loopen kontrollerar också den dokumenterade användningsräknaren.

Hur förändrar datablad granskningen?

Dokumenten löste de två öppna frågorna från Steg 1 och stödde fynden för kraft, ADC och filter. Regulatorfyndet citerade TLV700:s märkström på 200 mA, ESP32-C3:s sändningstopp på 335 mA och rekommendationen om 500 mA matning.

För filtret räknade Grok ut vilka kondensatorvärden som skulle uppfylla båda bandbreddsreglerna med R5 oförändrad: ungefär 32 till 81 nF. Varje blindgång hamnade under ”kontrollerat och acceptabelt” med motivering.

Steg 3: Hur verifierar man beräkningar med Grok 4.7 kodkörning

Kodkörning är xAI:s serverbaserade Python-sandlåda, som läggs till i tools som {"type": "code_interpreter"} när du använder OpenAI-klienten. Prompten lägger till en regel: varje påstående med en siffra måste beräknas innan det räknas som bekräftat.

Guiden till kodkörning som länkades tidigare säger att sandlådan saknar nätverksåtkomst och inte behåller tillstånd mellan begäranden. För några databladsvärden räcker det.

Vilka beräkningar ska Grok kontrollera?

Be Grok kontrollera effektbudgeten, ADC-området och filterbandbredden i ett skript. Om kretsar inte är din grej kan du hoppa över utdata nedan; slutsatsen följer därefter.

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

Minimiavskärningen 196,5 Hz är talet som filterfixen beror på, och kod beräknar det istället för att lämna det till modellens aritmetik. Även i hörnet med minst dämpning förloras mer än 15 dB vid 100 Hz, så utslaget står sig.

Steg 4: Kan Grok 4.7 söka på webben via API:et?

Ja. Webbsökning kontrollerar om de bifogade dokumenten fortfarande är aktuella, eftersom tillverkare reviderar datablad efter en modells träningsavskärning. Begränsa till officiella domäner så att bevisen förblir förstahandskällor.

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

Guiden för webbsökning som länkades tidigare tillåter upp till fem allowed_domains, inklusive underdomäner som docs.espressif.com. Jag skulle behålla detta steg även när de bifogade databladet är aktuella, eftersom det kan fånga en revision som publicerats efter din uppladdning.

Vad bevisar källhänvisningarna?

Grok bör citera den aktuella TI-produktsidan, ESP32-C3-dokumentationen, hårdvarukontrollistan och relevant errata. Behandla dessa hänvisningar som bevis på källan, inte som bevis på att den tekniska slutsatsen är korrekt.

Domänfilter kan ändå returnera en irrelevant sida. Kontrollera att varje källhänvisning stöder exakt den komponent och gräns som används i beräkningen.

Grok söker i filer, beräknar, kontrollerar källor. Bild av författaren.

Steg 5: Så lägger du till en verifierare med Grok 4.7 funktionsanrop

verify_design() är en vanlig Python-funktion som körs på din maskin, och den är den enda domaren för om en revision godkänns. Grok föreslår konstruktionsvärden via funktionsanrop, och funktionen kontrollerar dem mot fasta gränser.

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"],
    },
}

Effektkapacitet måste uppfylla max((335 + 10) mA × 1.25, 500 mA). För ADC:n måste 1.0 V × (1 + Rf/Rg) ligga mellan 1 500 och 2 250 mV. Filterkontroller mäter förlust vid 100 Hz och begränsar avskärningen till 500 Hz; varje kontroll returnerar ett värde, en gräns och godkänd/underkänd.

Verktygsschemat talar bara om för Grok vilka värden som ska skickas. Den centrala logiken för godkänd/underkänd är vanlig 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}

Helfunktionen avvisar också ogiltiga värden och returnerar mätningar med varje resultat. Testa den med en känd bra konstruktion, en känd dålig, en okänd komponent och en nära‑ögat‑miss.

Varför ska kod, inte modellen, betygsätta fixen?

Håll komponentbetyg utanför modellens kontroll. Jag skulle inte låta modellen ange sin egen strömklassning. Grok skickar ett artikelnummer, och funktionen slår upp klassningen i applikationens katalog.

En agent bör inte både föreslå en lösning och avgöra om den är korrekt när kod kan kontrollera svaret. Byt ut verify_design() mot en testsvit eller schemakontroll när uppgiften ändras. Att skriva verifieraren kräver extra arbete, men dess godkänd/underkänd-resultat beror inte på modellens åsikt.

Steg 6: Så gör du om och verifierar kretsen

Ge Grok ett mål: åtgärda varje bekräftad överträdelse med minsta rimliga uppsättning ändringar, och kalla inte konstruktionen klar förrän kontrollen som definierades tidigare passerar. Ge bevisen och verktygen från Steg 3 till 5, och sätt sedan en begärandegräns.

Här spelar kontextvarningen från sammanfattningen roll. Lös det innan du lägger till fler vändor.

Varför behöver filintensiva loopar kontextkomprimering?

En fortsättning inkluderar tidigare verktygsresultat, och dokumentsökningar kan returnera mycket text. I den misslyckade prototypen nådde nästa fortsättning 1 116 321 token och överskred Grok 4.7:s fönster på 500 000 token.

Kontextkomprimering kan inte rädda en begäran som redan är över gränsen. Den korrigerade loopen komprimerar varje lyckad dokumentsökningsvända innan nästa begäran skickas.

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)

Behåll den sista append. Komprimering tappar detaljerade verktygsutdata, så att återge verifierarens resultat hjälper nästa svar att undvika påhittade eller förväxlade kontroller. Att komprimera efter varje dokumenttung vända är en försiktig takt; ett större system kan använda en indata‑token‑tröskel istället.

Klarade Rev B verifieringen?

Ja. Grok bytte en komponent i varje felande delsystem: kraft, ADC‑förstärkning och filterbandbredd. Diagrammet visar exakta värden för Rev A och Rev B.

Tre komponentändringar rättar Rev A. Bild av författaren.

De reviderade värdena går sedan till verify_design(). Den returnerar ett resultat för varje krav.

Reviderad konstruktion klarar alla verifieringskontroller. Bild av författaren.

Ett underkänt resultat går tillbaka som en function_call_output, så Grok kan revidera konstruktionen tills kontrollerna passerar eller begärandegränsen nås.

Steg 7: Så returnerar du en strukturerad kretsgranskning

Strukturerade utdata returnerar ett objekt som matchar ett schema istället för prosa som du måste parsa. Anropa client.responses.parse() med en Pydantic‑modell i samma konversation, med verktygsanrop avstängda.

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,
)

Ett giltigt schema är inget bevis på att innehållet stämmer, så inkludera verifierarens resultat och be Grok basera verifier_result på dem. JSON:en kan sedan mata ett ärendehanteringssystem eller en mänsklig godkännandekö.

Vad rapporterade den strukturerade granskningen?

Den strukturerade rapporten bör markera varje ursprungligt fel som åtgärdat, citera det uppmätta värdet som verifieraren returnerade och behålla otestade farhågor under open_risks. För denna konstruktion inkluderar de farhågorna en regulator som ligger precis på 500 mA‑golvet och en ADC‑kondensator som avviker från Espressifs rekommendation.

Förbättrar högre resonemangsnivå i Grok 4.7 kretsgranskningen?

Högre nivå förbättrade inte verifierarpoängen, men den ändrade kvaliteten på filterfixen. Varje nivå fick samma schema, prompt, verktyg och begärandegräns.

low reducerade resistorn och behöll 1 µF‑kondensatorn, vilket lämnade kapacitiv last och insvängningsbeteende utanför verifieraren. Microchips vägledning för kapacitiv last säger att ett seriemotstånd kan förbättra stabiliteten, så detta resultat bevisar inte att fixen är instabil; det kräver frekvensrespons‑, stegsvar‑ eller bänkprovning. high ändrade i stället kondensatorn, medan xhigh valde samma slutvärden som high efter ett extra verifieraranrop.

När är xhigh-resonemang värt det?

För denna enskilda jämförelse gav high den bättre balansen. Den undvek den omodellerade lastfrågan utan det extra verifieraranrop som xhigh gjorde. En körning per nivå kan inte fastställa en allmän rangordning.

Fixade Grok 4.7 kretsen?

Svaret på inledningsfrågan är ja, inom verifierarens fem kontroller. Tabellen kondenserar de tidigare fynden till en översikt.

• Bild och krav
  • Lägger till: Visuell inspektion
  • Resultat: Bekräftar vad schemat ensamt kan bevisa
• Datablad
  • Lägger till: Tillverkargränser
  • Resultat: Konverterar två öppna frågor till fynd
• Kodkörning
  • Lägger till: Kontrollerade beräkningar
  • Resultat: Mäta kraft- och filterproblemen
• Webbsökning
  • Lägger till: Aktuella officiella källor
  • Resultat: Kontrollerar om de bifogade bevisen är aktuella
• Lokal verifierare
  • Lägger till: Godkänd eller underkänd från Python
  • Resultat: Accepterar endast en revision som passerar varje regel

Grok fixade de inkoderade kraven. Den bevisade inte att det reviderade kortet var elektriskt komplett eller redo för produktion.

Dokument avgör om en farhåga har bevis. Python avgör om en revision passerar. Välformulerad prosa kan inte ersätta något av detta.

Se granskningen i Streamlit

Vår Streamlit-guide förklarar gränssnittet som används här. Den använder strömning för att visa verktygsanrop när de kommer, och visar sedan verifierarkontrollerna och slutrapporten.