REA jämfört med Chrome DevTools: agentledd undersökning eller direkt felsökning?

Välj Chrome DevTools för direkt felsökning i webbläsaren, ändringar i DOM/CSS, brytpunkter i JavaScript och granskning av prestanda. Välj REA när du vill att en kodningsagent ska undersöka en webbsida, koppla utvalda skript eller anrop till en fråga och förklara resultaten med belägg.

REA:s arbetsflöde för webbläsare kräver en förberedd lokal webbläsaranslutning. Det granskar inte en webbplats bara för att någon anger en URL på den här communitywebbplatsen. Den här oberoende guiden länkar till den officiella dokumentationen för REA:s webbläsarflöde och dokumentationen för Chrome DevTools.

Hur skiljer sig de två arbetsflödena för webbläsare åt?

Chrome DevTools är inbyggt i Chrome. Panelerna låter en utvecklare granska en sida som körs, ändra stilar, pausa JavaScript, granska anrop, spela in användarflöden samt undersöka prestanda och minnesanvändning. Du styr undersökningen direkt i webbläsaren. Googles översikt över DevTools beskriver de arbetsflödena.

REA ger din kodningsagent tillgång till utvalda observationer från webbläsaren, bland annat sidstruktur, inlästa skript, nätverkstrafik och begärda skärmbilder. Agenten använder observationerna för att besvara en avgränsad fråga eller föreslå en rekonstruktion. REA har också separata arbetsflöden för lokala programfiler och nativa binärfiler, vilket ligger utanför DevTools vanliga inriktning på felsökning av webbsidor. REA:s README skiljer mellan dessa typer av analysobjekt.

Vad vill du göra?	Rekommenderad startpunkt	Indata	Resultat eller fördel
Omedelbart justera avstånd, layout eller en CSS-regel	Chrome DevTools	Valt DOM-element	Direkt redigering av stilar med visuell återkoppling
Pausa på en rad i JavaScript och granska tillståndet	Chrome DevTools	Sida som körs och en brytpunkt	Direkt kontroll över felsökaren och granskning av variabler
Hitta en flaskhals vid inläsning eller ett minnesproblem	Chrome DevTools	Prestandainspelning eller minnesprofil	Specialiserade tidslinjer och diagnostikpaneler
Fråga en agent hur en funktion i webbläsaren fungerar	REA:s arbetsflöde för webbläsare	Förberedd lokal anslutning och avgränsad fråga	Utvald kod och observationer som tolkas av agenten
Följa en funktion från ett Electron-paket till nativ kod	REA:s separata arbetsflöden för program och nativ kod	Lokala programartefakter och lämpliga analysmotorer	Underlag från flera typer av analysobjekt

När är Chrome DevTools det bättre valet?

Använd DevTools när du redan vet vad du ska undersöka och vill ha omedelbar återkoppling. Att välja ett element, testa en stil, lägga till en brytpunkt eller granska ett anrop är ofta en snabb, direkt åtgärd. Med DevTools slipper du den extra konfiguration och tolkning som ett utbyte med en agent innebär.

DevTools är också den bättre startpunkten för detaljerad granskning av webbläsarens prestanda och minnesanvändning. Panelen Prestanda visar inspelningar av inläsning och körning. Minnesverktygen hjälper dig att undersöka minnesproblem. Att REA kan samla in observationer från webbläsaren innebär inte att det har ett motsvarande gränssnitt för varje diagnostikfunktion i DevTools. Börja med Googles dokumentation om prestanda eller dokumentationen om minne för sådana uppgifter.

Om ett anrop misslyckas ger panelen Nätverk dig direkt tillgång till den aktivitet som webbläsaren har registrerat. En agent kan hjälpa till att tolka underlaget, men ett extra agentlager behövs inte när svarets status eller innehållet i anropet redan förklarar problemet.

När hjälper en undersökning med REA?

REA är användbart när din fråga kräver flera sammanhängande observationer och du vill att kodningsagenten ska förklara sambandet. Fråga om ett specifikt beteende, ange vilken sida som ska undersökas och be om relevant inläst kod och relevanta observationer. En bred prompt som ”förklara hela den här webbplatsen” ger dig färre tydliga sätt att kontrollera svaret.

Det officiella REA-exemplet med dinosauriespelet är en konkret illustration. REA läser det skript som har laddats av ett dinosauriespel baserat på Chromium. Agenten identifierar en starthastighet på 6, en acceleration på 0.001 per uppdatering utan kollision och en maxhastighet på 13. Sedan använder den regeln i ett litet spel med justerbar hastighet. Exemplet innehåller källkodshänvisningar och en kontrollerad verifiering av hastighetsregeln.

Exemplet har skapats av REA-projektet. Det är inget belägg för att alla webbplatser kan rekonstrueras och bör inte presenteras som en oberoende communityanvändares erfarenhet. I vår samling av communityfall hålls ursprungliga inlägg åtskilda från officiella genomarbetade exempel.

Hur förbereder du en undersökning i webbläsaren?

Följ REA:s förberedelser för webbläsaren för en webbläsare i Chrome-familjen och en lokal felsökningsanslutning. Ge agenten URL:en till den avsedda sidan, den lokala ändpunkt som guiden kräver och en fråga. Följ guidens avgränsning för anslutningen i stället för att exponera en felsökningstjänst på det publika internet.

En prompt för en demosida som du äger kan se ut så här:

Använd REA med den förberedda lokala webbläsaranslutningen för att granska
min demosida. Förklara hur sökrutan uppdaterar resultaten.
Visa det relevanta inlästa skriptet och platserna i källkoden.
Lista observationerna som stöder förklaringen och det som fortfarande är okänt.

Kontrollera att underlaget som returneras beskriver den åtgärd och det tillstånd du avsåg. Om programmet har flera sidor eller tillstånd kanske ett skript från ett tillstånd inte förklarar ett annat. Upprepa åtgärden manuellt i DevTools när det behövs för att bekräfta det anrop eller den kodväg som agenten beskriver.

Kan något av verktygen visa webbplatsens källkod på serversidan?

Skript och anrop som är synliga i webbläsaren visar det beteende på klientsidan som exponeras i den aktuella webbläsarsessionen. De avslöjar inte automatiskt privat implementationskod på servern, databasernas innehåll eller dolda affärsregler. Ett svar kan visa vad servern returnerade för ett enskilt anrop utan att förklara alla interna steg som ledde fram till det.

Behandla agentens föreslagna arkitektur för serversidan som en hypotes om den inte stöds av separat underlag som du har behörighet att använda. Att återskapa ett observerat gränssnitt och att återvinna dess ursprungliga implementation är olika påståenden. REA:s underlag och begränsningar hjälper till att tydliggöra gränsen. Agenten behöver fortfarande respektera den.

Material som samlats in från webbläsaren kan innehålla sessionsspecifika data, innehåll i anrop eller känsliga URL:er. REA utför analysen lokalt, men verktygsresultaten skickas till din kodningsagent och omfattas av modellleverantörens datapolicy. REA:s officiella sida med vanliga frågor förklarar denna gräns för datahanteringen. Dela bara observationer som är lämpliga för din uppgift och som du har behörighet att dela.

Vilka frågor brukar uppstå när man väljer mellan dem?

Ersätter REA Chrome DevTools?

REA erbjuder ett gränssnitt för undersökningar med en kodningsagent. DevTools erbjuder direkt felsökning i webbläsaren och specialiserade diagnostikpaneler. Att använda DevTools för att verifiera ett resultat från REA är en användbar kombination.

Behöver jag Hopper, Ghidra eller IDA för en webbplats?

REA:s arbetsflöde för webbläsare kräver en kompatibel webbläsare och den dokumenterade lokala anslutningen. Nativa analysmotorer används för separat djupanalys av nativa binärfiler, inte för vanlig sidgranskning.

Körs REA på den här webbplatsen?

Nej. reverseengineeranything.tools publicerar communityexempel och guider. Installera det officiella REA-paketet på din egen dator för att göra undersökningar. Den här webbplatsen har ingen funktion för uppladdning till analys eller körning i en värdtjänst.

Kan jag använda DevTools utan en AI-modell?

Ja. Chrome DevTools finns direkt i Chrome. REA:s CLI kan också köra arbetsflöden som stöds utan en kodningsagent. En agentledd undersökning med REA använder däremot klientens egen modellåtkomst och dess villkor.

Hur börjar jag använda REA med en agent?

Läs vår guide till den första undersökningen och följ sedan de officiella guiderna för installation och webbläsare. Kontrollera verktygslistan för den installerade servern. Funktioner som dokumenteras i kodarkivets main-gren kan vara nyare än det publicerade paketet.