तुमचे क्रॅश रिपोर्ट, कोणीतरी वाचलेले
Crashlytics तुम्हाला काय बिघडले ते सांगते. चाळीसपैकी कोणती समस्या तुमच्या सकाळच्या वेळेसाठी योग्य आहे हे ते सांगत नाही, तिचे वर्णन करत नाही किंवा तिकीट उघडत नाही. हे ते काम दर तासाला करते आणि एकाच क्रॅशची दोनदा नोंद करत नाही.
हे कसे काम करते
तीन पायऱ्या, आणि त्यातील एकही “कॉन्फिगर करा” नाही.
- 01
Firebase आणि GitHub कनेक्ट करा
क्रॅश रिपोर्टसाठी तुमचे Google खाते, इश्यूसाठी तुमचे GitHub. नंतर तुमच्या ॲपचे क्रॅश कोणत्या रिपॉझिटरीशी संबंधित आहेत ते सांगा — ते तुमच्यासाठी उघडत असलेल्या फाइलमधील एक ओळ.
- 02
हे तासाला एक क्रॅश निवडते
हे क्रमवारी लावलेला रिपोर्ट वाचते, आधीच नोंदवलेले सर्व काही वगळते आणि उरलेली सर्वात वाईट गोष्ट घेते. प्रति रन एक, योग्य प्रकारे केले जाते — एक तास वाट पाहणे जास्त नाही आणि अर्धा बग रिपोर्ट कोणालाही मदत करत नाही.
- 03
तुम्हाला एक इश्यू आणि क्रॅशवर एक टीप मिळते
प्रभाव, स्टॅक ट्रेस आणि काय घडत आहे याचे आकलन असलेला GitHub इश्यू. त्यानंतर Crashlytics इश्यूवर त्यांनी कोणता उघडला हे सांगणारी एक टीप, जेणेकरून क्रॅश पाहणारा कोणीही पाहू शकेल की एजंट येथे आला होता.
हे काय करू शकते
कोणता क्रॅश सर्वात गंभीर आहे हे त्याला माहीत असते
एकूण इव्हेंटच्या संख्येपेक्षा प्रभावित वापरकर्ते, वर्षभरापासून चालत असलेल्या समस्येपेक्षा सध्याच्या व्हर्जनमधील बिघाड, आणि फ्रेमवर्कमधील स्टॅक ट्रेसपेक्षा तुमच्या कोडकडे निर्देश करणारा स्टॅक ट्रेस यांना प्राधान्य दिले जाते. याने काय वगळले आणि का वगळले ते हे सांगते, जेणेकरून तुम्ही असमत असू शकता.
हे एकाच बगची दोनदा नोंद करणार नाही
हे नोंदवत असलेला प्रत्येक क्रॅश त्याच्या Crashlytics आयडीनुसार रेकॉर्ड केला जातो. मेमरी नसलेले दर तासाचे काम दुपारच्या जेवणाआधी एकाच तिकिटाची बारा वेळा नोंद करेल, ज्यामुळे कोणीही ते कायमचे बंद करेल.
अधुरे राहिलेले काम पुढच्या रनमध्ये पूर्ण केले जाते
हे काय करणार आहे ते आधी लिहून ठेवते. एखादा रन अर्ध्यावर थांबल्यास, पुढचा रन ती नोंद वाचतो, इश्यू खरोखर नोंदवला गेला आहे का हे तपासतो आणि पुन्हा नव्याने सुरू न करता किंवा दुबार नोंद न करता तिथूनच पुढे चालू ठेवतो.
हे कसे सेट केले आहे
कार्यपद्धती, जेणेकरून साइन इन करण्यापूर्वी तुम्हाला काय मिळत आहे हे तुम्हाला माहीत असेल.
- वातावरण
- कोणताही सँडबॉक्स नाही आणि शेल नाही — हे एका API मधून वाचते आणि दुसऱ्या API मध्ये लिहिते. शेड्यूल्ड रन्सना एका शेड्यूलपुरती मर्यादित अल्पकालीन क्रेडेंशियल मिळतात, तुमच्या सत्राची प्रत नाही.
- साधने
- अहवाल, समस्या, इव्हेंट्स आणि नोट्ससाठी MCP द्वारे Firebase Crashlytics; नोंदणीसाठी MCP द्वारे GitHub. स्वतःच्या रेकॉर्डसाठी readFile, writeFile, editFile, glob आणि grep, तसेच getCurrentTime, scheduleRun, listSchedules आणि cancelSchedule.
- मॉडेल
- Claude Sonnet 5 वर पिन केले आहे, ज्याच्या मागे Haiku 4.5 आहे. निर्णय क्षमता हेच मुख्य उत्पादन आहे — क्रॅशकडे एखाद्या व्यक्तीचे लक्ष जाणे गरजेचे आहे की नाही हे ठरवणे आणि बंद करण्याऐवजी ज्यावर कारवाई केली जाईल असा अहवाल लिहिणे.
- सुरुवातीच्या फाइल्स
- रिपॉझिटरी मॅपिंगसह सुरू केले जाते आणि दुसरं काहीही नाही. नोंदवलेला रेकॉर्ड नसणे हीच गोष्ट पहिल्या रनला सांगते की हा पहिला रन आहे.
- काय राहते
- याने नोंदवलेली माहिती सत्रात राहते, याच कारणास्तव ते स्वतःची पुनरावृत्ती न करता दर तासाला चालू शकते. रन्सच्या दरम्यान काहीही हटवले जात नाही.
लोक ज्या गोष्टी विचारतात
- “सध्या सर्वात जास्त कशामुळे क्रॅश होत आहे?”
- “सर्वात वाईट क्रॅशची नोंद करा आणि आतापासून दर तासाला तपासा.”
- “तुम्ही आधीच कोणत्या क्रॅशची नोंद केली आहे?”
- “दर तासाचा रन थांबवा.”
हे काय करणार नाही
यातील प्रत्येक मर्यादा आम्ही प्रत्यक्षात अनुभवली आहे, हा रोडमॅपचा भाग नाही.
- हे क्रॅश वाचते आणि इश्यू नोंदवते. हे तोडगा लिहीत नाही — ते वेगळे काम आहे, आणि तुमच्याकडे असल्यास ते इतर काही दाखवण्याऐवजी हा इश्यू GitHub Copilot कडे सोपवेल.
- Firebase कनेक्ट करताना ते वापरते त्यापेक्षा जास्त ॲक्सेस मागितला जातो. Google Crashlytics साठी कोणतीही फक्त-वाचण्याची श्रेणी प्रकाशित करत नाही, म्हणून संमती स्क्रीन “पहा आणि व्यवस्थापित करा” असे म्हणते. हे रिपोर्ट वाचते आणि टिप्पण्या जोडते; टोकन कधीही मॉडेलपर्यंत पोहोचत नाही.
- प्रति रन एक क्रॅश. एका रनमधील टप्प्यांपेक्षा खूप जास्त क्रॅश असतात, आणि चार अपूर्ण रिपोर्टपेक्षा एक संपूर्ण बग रिपोर्ट चांगला असतो.
- शेड्यूल्ड रन तुम्हाला काहीही विचारू शकत नाहीत. उत्तर देण्यासाठी तिथे कोणीही नसते, त्यामुळे ते लिहिलेल्या सूचनेनुसार काम करतात — म्हणूनच ते बुक करण्यापूर्वी तुम्हाला त्या सूचनेला मंजुरी देण्यास सांगते.
कोणते मॉडेल हे सर्वोत्तम करते
या एजंटच्या वास्तविक रन्सवर, प्रति मॉडेल मोजलेले. जेव्हा एखादा रन स्वतःहून उत्तर तयार करतो तेव्हा तो पूर्ण झालेला मानला जातो — काहीही अयशस्वी झाले नाही, कोणालाही कशास मान्यता देण्यास सांगितले गेले नाही, आणि त्याच्या पायऱ्या संपल्या नाहीत. तीनही स्तंभ एकत्र वाचा: हार मानून वेगाने संपवणारे मॉडेल पहिल्या स्तंभावर वाईट स्कोअर करते, आणि सर्वकाही कसून पूर्ण करणारे मॉडेल दुसऱ्या स्तंभावर वाईट स्कोअर करते.
| मॉडेल | पूर्णतेचा दर | मध्यक खर्च | मध्यक वेळ | रन्स |
|---|---|---|---|---|
| claude-sonnet-5anthropic | 72% | $0.236 | 80से | 50 |
- पूर्णतेचा दर
- तुम्हाला हस्तक्षेप न करता काम पूर्ण करणाऱ्या रन्स.
- मध्यक खर्च
- क्रेडिट्समध्ये, एका सामान्य रनचा खर्च किती येतो.
- मध्यक वेळ
- भिंतीवरील घड्याळ, पहिल्या संदेशापासून उत्तरापर्यंत.
प्रत्येक रांगेच्या मागील रन्सवरील मध्यक. या एजंटवर 3 रन्स झाल्यावर एक मॉडेल दिसते, आणि रन संख्या दर्शविली जाते जेणेकरून एखादा आकडा कशावर आधारित आहे याचा तुम्ही अंदाज लावू शकाल.
तुमचे क्रॅश रिपोर्ट, कोणीतरी वाचलेले
हे आधीच सेट केले आहे. ते उघडा आणि काहीतरी विचारा.
क्रॅश वर्गीकरण सेट करा