Samouczek API Grok 4.7: zbuduj recenzenta projektów układów elektronicznych z AI

Schemat elektryczny to diagram pokazujący, jak łączą się elementy elektroniczne. Przegląd takiego schematu oznacza sprawdzenie, czy elementy i ich wartości spełniają wymagania projektu. Czy zasilacz dostarczy wystarczająco prądu? Czy procesor odczyta pełny sygnał z sensora? Odpowiedzi biorą się ze schematu, kart katalogowych komponentów i kilku obliczeń.

Chciałem sprawdzić, czy Grok 4.7 potrafi przeprowadzić cały taki przegląd. Przewodnik po Grok 4.7 mówi, że model został wytrenowany do dłuższych zadań i dokładniejszego sprawdzania własnej pracy. Układ dostarcza też liczb, które zwykły kod Pythona może zweryfikować, więc nie potrzebujemy innego modelu AI do oceny wyniku.

Do eksperymentu zbudowałem EnviroNode Rev A, małą płytkę zasilaną z USB, i umieściłem w jej projekcie trzy usterki. Grok nie wie, ile ich jest. Musi je znaleźć, podeprzeć każde znalezisko dokumentacją komponentu, zaproponować poprawki i przekazać skorygowane wartości do sprawdzeń w Pythonie.

Nie potrzebujesz wykształcenia z elektroniki, żeby nadążyć. Każdą zasadę obwodu wyjaśniam, gdy pojawia się po raz pierwszy. Dowiesz się, jak:

• Wysłać obraz schematu do Grok 4.7 przez Responses API

• Dołączyć karty katalogowe przez Files API i pozwolić Grokowi je przeszukać

• Sprawdzić obliczenia dzięki wykonywaniu kodu i limity przy pomocy wyszukiwania w sieci

• Dać Grokowi lokalną funkcję verify_design(), która decyduje o zaliczeniu lub oblanej próbie

• Zmieszczać długą, bogatą w dokumenty rozmowę w limicie kontekstu modelu

• Zwracać spójny format recenzji, a potem porównać poziomy rozumowania

Ta sama płytka pozostaje w polu widzenia od pierwszej oceny obrazu po finałowe sprawdzenie w Pythonie.

TL;DR

Grok 4.7 zidentyfikował każdą zaszytą usterkę, gdy miał karty katalogowe, a poprawiony projekt przeszedł testy w Pythonie. To mówi coś o tych trzech usterkach, nie o przeglądzie układów ogólnie.

• Bez dokumentów Grok odmówił zgadywania: sam obraz dał jeden potwierdzony defekt, a limity stabilizatora i przetwornika analogowo-cyfrowego (ADC) trafiły do „wymaga dowodów”.
• Karty katalogowe zamieniły podejrzenia w dowody: każde znalezisko cytowało wartość z dokumentu, bez wskazywania poprawnych części jako błędnych.
• Obciążone plikami tury mogą wyczerpać długotrwały kontekst: po powtarzanych wyszukiwaniach w PDF-ach kontynuacja przekroczyła okno 500 tys.; poprawiona pętla kompresuje treść przed następną turą.
• Low przeszło weryfikator, ale odsłoniło ślepą plamkę: wartości filtru spełniły zapisane testy, pozostawiając nieprzetestowane obciążenie pojemnościowe i zachowanie podczas ustalania się sygnału.

To jedna mała płytka, nie benchmark. Płytka z tuzinem kart katalogowych stworzy większy kontekst i może dać inne wyniki.

Czym jest API Grok 4.7?

API Grok 4.7 daje aplikacjom w Pythonie wejście tekstowe i obrazowe, wyjście tekstowe i okno kontekstu 500 000 tokenów przez identyfikator modelu grok-4.7. Oficjalny przewodnik wymienia poziomy rozumowania low, medium, high (domyślny) i xhigh; rozumowania nie da się wyłączyć. API obsługuje też wywoływanie funkcji, strukturyzowane wyniki, wyszukiwanie w sieci, X search oraz wykonywanie kodu.

Nasz przegląd Grok 4.7 omawia premierę i benchmarki. SpaceXAI oznacza Chat Completions jako przestarzałe, więc każdy przykład tutaj używa Responses API.

Ile kosztuje Grok 4.7?

Poniżej 200 000 tokenów w promptcie Grok 4.7 kosztuje $2 za milion tokenów wejściowych, $0,50 za milion buforowanych tokenów wejściowych i $6 za milion tokenów wyjściowych. Gdy prompt osiągnie 200 000 tokenów, każdy token w tym żądaniu jest naliczany po $4, $1 i $12.

Narzędzia po stronie serwera mają osobne opłaty: strona cen nalicza $5 za 1000 wywołań wyszukiwania w sieci lub wykonywania kodu. Wyszukiwania w dołączonych dokumentach kosztują po jednym centzie, a przechowywane dokumenty mają też dzienną opłatę za GiB. Używaj stabilnego prompt_cache_key dla powiązanych żądań, ale uwzględnij w budżecie niebuforowane wejście.

Kwotę na fakturze odczytasz z usage.cost_in_usd_ticks. Dokumentacja śledzenia kosztów mówi, że obejmuje ona buforowanie i opłaty za narzędzia. Podziel tę wartość przez 10^10, aby uzyskać dolary.

Dlaczego testować Grok 4.7 na projektowaniu układów?

Projekt układów testuje czytanie dokumentów, obliczenia, użycie narzędzi i weryfikację w jednym zadaniu. SpaceXAI raportuje 64,0% dla Grok 4.7 na EEBench. Metodologia EEBench używa symulacji i sprawdzeń listy materiałowej (BOM), a nie sędziego LLM; EnviroNode trzyma się tej samej zasady.

Co zbudujemy: przegląd układu EnviroNode Rev A

EnviroNode Rev A to węzeł czujnikowy zasilany przez USB. Cały projekt możesz pobrać z GitHuba.

Na schemacie są wszystkie wartości elementów, których Grok potrzebuje do przeglądu. Każde wymaganie ma identyfikator, np. PWR-002 lub BW-001, więc każde znalezisko może wskazać jedną regułę.

Schemat EnviroNode Rev A z wartościami. Obraz: autor.

Zanim Grok przejrzy płytkę, ujawnij każdą regułę, której użyje weryfikator. Funkcja zwraca pięć sprawdzeń pass-or-fail zbudowanych z tych ośmiu wymagań:

• PWR-001: Wejście USB zostaje między 4,75 V a 5,25 V
• PWR-002: Stabilizator pokrywa obciążenie szczytowe
• PWR-003: Obciążenia nie-MCU mają budżet 10 mA
• SIG-001: Pełna skala sensora to 1,0 V
• ADC-001: Wejście ADC pozostaje na poziomie ≤ 2 250 mV
• ADC-002: Wejście ADC osiąga co najmniej 1 500 mV
• BW-001: Sygnały do 100 Hz tracą mniej niż 1 dB
• BW-002: Częstotliwość odcięcia filtru ≤ 500 Hz

Model dostaje ten sam zestaw wymagań. Żaden limit weryfikatora nie pojawia się dopiero po tym, jak Grok zaproponuje poprawkę.

Jakie są trzy zaszyte usterki?

Trzy usterki da się sprawdzić liczbami. Ich liczby nie ujawniamy w promptcie.

• Zbyt mały stabilizator (PWR-002): TI TLV700 jest na 200 mA, podczas gdy karta ESP32-C3 podaje 335 mA szczytu nadawania Wi‑Fi, a checklista schematu Espressifa wymaga co najmniej 500 mA.

• Przekroczenie zakresu ADC (ADC-001): wzmocnienie 3 daje 3,0 V na ADC, ale efektywny zakres z karty kończy się na 2 500 mV, a wymaganie dopuszcza 90% tego.

• Zbyt wolny filtr (BW-001): 10 kΩ i 1 µF dają odcięcie 15,9 Hz, podczas gdy sygnały do 100 Hz mogą stracić najwyżej 1 dB.

Usterka ADC dotyczy zakresu pomiarowego, nie uszkodzenia pinu. Poprawne wybory, jak rezystor LED i opóźnienie CHIP_EN, sprawiają, że fałszywe alarmy są wymierzalne.

Jak działa pętla przeglądu?

Przegląd potrzebuje jasnej granicy: Grok proponuje zmiany, a Python decyduje o zaliczeniu lub nie. Diagram pokazuje, gdzie do tej pętli wchodzą dokumenty i narzędzia.

Pętla przeglądu oddziela propozycję od weryfikacji. Obraz: autor.

Zdefiniuj sukces przed pierwszym wywołaniem API. Licz usterkę tylko wtedy, gdy Grok powiąże ją z wymaganiem i dowodem. Licz poprawkę tylko wtedy, gdy verify_design() zwróci all_pass = true.

Jak skonfigurować API Grok 4.7 w Pythonie

Potrzebujesz klucza API xAI z doładowanymi środkami, Pythona 3.10 lub nowszego i pakietu SDK OpenAI dla Pythona skierowanego na bazowy URL xAI. Utwórz klucz w konsoli xAI, a potem zainstaluj pakiety użyte poniżej.

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

Przykłady API korzystają z pierwszej grupy pakietów; druga wspiera diagramy repozytorium i testy. Testowałem je z Pythonem 3.11.9, openai 3.19.2, pydantic 2.13.5, streamlit 1.64.0 i httpx 0.28.1. Zapisz klucz jako zmienną środowiskową XAI_API_KEY i ładuj go przez python-dotenv zamiast umieszczać w kodzie; nasz przewodnik po środowiskach wirtualnych wyjaśnia konfigurację, jeśli to dla ciebie nowość.

Wykonaj pierwsze wywołanie API Grok 4.7

Jeśli twój klucz już działa z Responses API, przejdź do Kroku 1. W przeciwnym razie to żądanie sprawdza klucz, bazowy URL i identyfikator modelu za jednym razem.

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)

Jednozdaniowa odpowiedź oznacza, że konfiguracja działa. Długi timeout będzie ważny później, bo żądania z rozumowaniem i narzędziami mogą trwać kilka minut.

Krok 1: Czy Grok 4.7 potrafi przejrzeć układ z obrazu?

Tak, Grok 4.7 potrafi przejrzeć schemat tylko na podstawie obrazu, pod warunkiem że w promptcie jasno powiesz, że nie będzie narzędzi. Wersja bazowa wysyła PNG jako adres URL danych base64 razem z treścią wymagań.

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

Prompt prosi o trzy sekcje: potwierdzone, wymaga dalszych dowodów oraz sprawdzone i akceptowalne. Nie wspomina o liczbie defektów ani podejrzanym elemencie.

Co znalazła recenzja wyłącznie z obrazu?

Powiedz modelowi wprost, gdy nie ma dostępnych narzędzi ani kart katalogowych. W przeciwnym razie może zakończyć odpowiedź po stwierdzeniu, że sprawdzi specyfikację, do której nie ma dostępu.

Jak w TL;DR, Grok potwierdził usterkę filtru z odcięciem 15,9 Hz i tłumieniem 16,1 dB przy 100 Hz. Stabilizator i ADC trafiły do „wymaga dalszych dowodów” zamiast zgadywania ich limitów.

Krok 2: Jak dodać karty katalogowe przez Files API

Dołączone dokumenty zamieniają niejasną obawę w twierdzenie poparte liczbami. Prześlij każdy dokument raz i odwołuj się do niego przez 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}]

Ponieważ ten samouczek ustawia expires_after na siedem dni, zbuforowane ID są ważne tylko w tym oknie. Bez expires_after xAI przechowuje przesłane pliki do czasu ich usunięcia.

W odpowiedziach SDK OpenAI zarejestrowanych tutaj wyszukiwanie załączników pojawiało się jako elementy custom_tool_call o nazwach pdf_search i pdf_browse, a użycie liczyło je pod document_search_calls. To zachowanie obserwowane, nie kontrakt ogólny typu narzędzia, więc pętla sprawdza też udokumentowany licznik użycia.

Jak karty katalogowe zmieniają przegląd?

Dokumenty rozwiązały dwa otwarte pytania z Kroku 1 i wsparły znaleziska dotyczące zasilania, ADC i filtru. Wniosek o stabilizatorze cytował 200 mA TLV700, 335 mA szczytu nadawania ESP32-C3 i rekomendację zasilania 500 mA.

W przypadku filtru Grok wyliczył, jakie wartości kondensatora spełnią oba wymagania pasma przy niezmienionym R5: około 32–81 nF. Każda zmyłka trafiła do „sprawdzone i akceptowalne” z uzasadnieniem.

Krok 3: Jak weryfikować obliczenia przez wykonywanie kodu w Grok 4.7

Wykonywanie kodu to piaskownica Pythona po stronie serwera xAI, dodawana do tools jako {"type": "code_interpreter"} przy użyciu klienta OpenAI. Prompt dodaje jedną zasadę: każde twierdzenie z liczbą musi być policzone, zanim uznamy je za potwierdzone.

Przewodnik do wykonywania kodu podlinkowany wcześniej mówi, że piaskownica nie ma dostępu do sieci i nie utrzymuje stanu między żądaniami. Do kilku liczb z kart to wystarczy.

Które obliczenia Grok powinien sprawdzić?

Poproś Groka o sprawdzenie budżetu mocy, zakresu ADC i pasma filtru w jednym skrypcie. Jeśli obwody nie są twoją bajką, pomiń poniższy wynik; sedno znajdziesz po nim.

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

Minimalne odcięcie 196,5 Hz to liczba, od której zależy poprawka filtru, i kod ją wylicza zamiast zostawiać to arytmetyce modelu. Nawet skraj z najmniejszym tłumieniem traci ponad 15 dB przy 100 Hz, więc werdykt się utrzymuje.

Krok 4: Czy Grok 4.7 potrafi wyszukiwać w sieci przez API?

Tak. Wyszukiwanie w sieci sprawdza, czy dołączone dokumenty są wciąż aktualne, bo producenci aktualizują karty po dacie odcięcia treningu modelu. Ogranicz je do oficjalnych domen, by dowody były pierwszorzędne.

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

Przewodnik wyszukiwania w sieci podlinkowany wyżej pozwala na maksymalnie pięć allowed_domains, w tym subdomeny takie jak docs.espressif.com. Zostawiłbym ten krok nawet wtedy, gdy dołączone karty są aktualne, bo może wychwycić rewizję opublikowaną po twoim uploadzie.

Co potwierdzają cytowane źródła?

Grok powinien cytować aktualną stronę produktu TI, dokumentację ESP32-C3, checklistę sprzętową i ewentualne erraty. Traktuj te cytowania jako dowód źródła, nie dowód, że wniosek inżynierski jest poprawny.

Filtry domen wciąż mogą zwrócić nieistotną stronę. Sprawdź, czy każde cytowanie wspiera dokładnie ten komponent i limit użyty w obliczeniu.

Grok przeszukuje pliki, liczy, sprawdza źródła. Obraz: autor.

Krok 5: Jak dodać weryfikator przez wywoływanie funkcji w Grok 4.7

verify_design() to zwykła funkcja Pythona działająca na twojej maszynie i jest jedynym sędzią, czy rewizja przechodzi. Grok proponuje wartości projektu przez wywoływanie funkcji, a funkcja sprawdza je względem stałych limitów.

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

Zdolność mocy musi spełnić max((335 + 10) mA × 1.25, 500 mA). Dla ADC 1.0 V × (1 + Rf/Rg) musi pozostać między 1 500 a 2 250 mV. Sprawdzenia filtru mierzą tłumienie przy 100 Hz i limitują odcięcie do 500 Hz; każde zwraca wartość, limit i wynik zal./nie.

Schemat narzędzia mówi Grokowi tylko, jakie wartości wysłać. Rdzeń logiki pass-or-fail to zwykły 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}

Pełna funkcja odrzuca też nieprawidłowe wartości i zwraca pomiary przy każdym wyniku. Przetestuj ją na projekcie poprawnym, złym, z nieznanym komponentem i bliskim trafieniu.

Dlaczego oceniać poprawki w kodzie, a nie w modelu?

Trzymaj parametry elementów poza kontrolą modelu. Nie pozwoliłbym modelowi podawać własnych wartości prądu. Grok wysyła numer części, a funkcja szuka parametru w katalogu aplikacji.

Agent nie powinien jednocześnie proponować rozwiązania i decydować, czy jest poprawne, gdy kod może sprawdzić odpowiedź. Zastąp verify_design() zestawem testów lub walidacją schematu, gdy zadanie się zmieni. Napisanie weryfikatora to dodatkowa praca, ale jego wynik pass/fail nie zależy od opinii modelu.

Krok 6: Jak przeprojektować i zweryfikować układ

Daj Grokowi jeden cel: naprawić każde potwierdzone naruszenie najmniejszym rozsądnym zestawem zmian i nie uznawaj projektu za ukończony, dopóki wcześniej zdefiniowane sprawdzenie nie przejdzie. Zapewnij dowody i narzędzia z Kroków 3–5, a potem ustaw limit żądań.

Tu liczy się ostrzeżenie o kontekście z TL;DR. Rozwiąż je, zanim dodasz kolejne tury.

Dlaczego pętle z wieloma plikami potrzebują kompresji kontekstu?

Kontynuowane żądanie zawiera wcześniejsze wyniki narzędzi, a wyszukiwania w dokumentach mogą zwrócić dużo tekstu. W nieudanym prototypie następna kontynuacja doszła do 1 116 321 tokenów i przekroczyła okno 500 000 tokenów Grok 4.7.

Kompresja kontekstu nie uratuje żądania, które już przekroczyło limit. Poprawiona pętla kompresuje każdą udaną turę z wyszukiwaniem w dokumentach przed wysłaniem kolejnego żądania.

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)

Zachowaj to ostatnie append. Kompresja usuwa rozwlekłe wyniki narzędzi, więc powtórzenie wyniku weryfikatora pomaga kolejnej odpowiedzi uniknąć zmyślonych lub pomylonych sprawdzeń. Kompresja po każdej turze z dużą liczbą dokumentów to zachowawcze tempo; większy system może użyć progu tokenów wejściowych.

Czy Rev B przeszedł weryfikację?

Tak. Grok zmienił po jednym elemencie w każdym zawodzącym podsystemie: zasilanie, wzmocnienie ADC i pasmo filtru. Diagram pokazuje dokładne wartości Rev A i Rev B.

Trzy zmiany elementów korygują Rev A. Obraz: autor.

Skorygowane wartości trafiają do verify_design(). Zwraca on po jednym wyniku dla każdego wymagania.

Zmieniony projekt przechodzi wszystkie sprawdzenia. Obraz: autor.

Wynik niezaliczony wraca jako function_call_output, więc Grok może poprawiać projekt, aż testy przejdą lub wyczerpie się limit żądań.

Krok 7: Jak zwrócić ustrukturyzowaną recenzję układu

Strukturyzowane wyniki zwracają obiekt zgodny ze schematem zamiast prozy, którą musiałbyś parsować. Wywołaj client.responses.parse() z modelem Pydantic w tej samej rozmowie, z wyłączonymi wywołaniami narzędzi.

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

Poprawny schemat nie dowodzi, że treść jest prawidłowa, więc dołącz wyniki weryfikatora i powiedz Grokowi, by opierał verifier_result na nich. JSON może potem zasilić tracker błędów lub kolejkę akceptacji przez człowieka.

Co zgłosiła ustrukturyzowana recenzja?

Ustrukturyzowany raport powinien oznaczyć każdą pierwotną usterkę jako rozwiązaną, zacytować wartość zmierzoną przez weryfikator i zostawić nietestowane obawy w open_risks. W tym projekcie to m.in. stabilizator równo na progu 500 mA i kondensator ADC inny niż rekomendacja Espressifa.

Czy wyższy wysiłek rozumowania w Grok 4.7 poprawia przegląd układu?

Wyższy wysiłek nie poprawił wyniku weryfikatora, ale zmienił jakość poprawki filtru. Każdy poziom dostał ten sam schemat, prompt, narzędzia i limit żądań.

low zredukował rezystor i zostawił kondensator 1 µF, zostawiając poza weryfikatorem obciążenie pojemnościowe i zachowanie podczas ustalania. Wytyczne Microchipa dot. obciążenia pojemnościowego mówią, że rezystor szeregowy może poprawić stabilność, więc to nie dowodzi, że poprawka jest niestabilna; wzywa do testów charakterystyki częstotliwościowej, odpowiedzi skokowej lub pomiarów. high zmienił kondensator, a xhigh wybrał te same wartości końcowe co high po dodatkowym wywołaniu weryfikatora.

Kiedy warto użyć rozumowania xhigh?

W tym pojedynczym porównaniu high dał lepszy balans. Uniknął niezamodelowanej kwestii obciążenia bez dodatkowego wywołania weryfikatora, jakie zrobił xhigh. Jedno wykonanie na poziom nie ustanawia ogólnej hierarchii.

Czy Grok 4.7 naprawił układ?

Odpowiedź na pytanie otwierające brzmi: tak, w ramach pięciu sprawdzeń weryfikatora. Tabela streszcza wcześniejsze ustalenia w jednym widoku.

• Obraz i wymagania
  • Dodaje: Inspekcję wizualną
  • Wynik: Potwierdza to, co da się udowodnić samym schematem
• Karty katalogowe
  • Dodaje: Limity producenta
  • Wynik: Zamienia dwa otwarte pytania w znaleziska
• Wykonywanie kodu
  • Dodaje: Sprawdzone obliczenia
  • Wynik: Mierzy problemy z mocą i filtrem
• Wyszukiwanie w sieci
  • Dodaje: Aktualne oficjalne źródła
  • Wynik: Sprawdza, czy dołączone dowody są aktualne
• Lokalny weryfikator
  • Dodaje: Zaliczenie lub nie z Pythona
  • Wynik: Akceptuje tylko rewizję, która przechodzi każdą regułę

Grok naprawił zakodowane wymagania. Nie udowodnił, że zmieniona płytka jest elektrycznie kompletna ani gotowa do produkcji.

Dokumenty decydują, czy obawa ma dowody. Python decyduje, czy rewizja przechodzi. Płynna proza nie zastąpi żadnego z nich.

Obejrzyj przegląd w Streamlit

Nasz przewodnik po Streamlit wyjaśnia użyty tutaj interfejs. Wykorzystuje streaming, żeby pokazywać wywołania narzędzi na bieżąco, a potem wyniki weryfikatora i raport końcowy.