एक्सेलेरेटर्स और आईपी योगदान

स्क्रीन 1: अंत तक आप क्या कर सकेंगे

अभिविन्यास डेवलपर मॉड्यूल 5 · 2 मिनट अंत तक आप क्या कर सकेंगे

बिल्ड को अच्छी तरह से दस्तावेज़ करें और अगली एनगेजमेंट इसे शुरुआत से बजाय इससे बनाई जाए।

पिछले तीन मॉड्यूल में आपने एक प्रोडक्शन एजेंट बनाया, इसे सही अनुमति और संदर्भ नियंत्रण के साथ Claude Code में जोड़ा, और MCP कनेक्शन सेट अप किए जो सुरक्षा समीक्षा पास करते हैं। उनमें से प्रत्येक एक कार्यशील बिल्ड था।

यह मॉड्यूल कवर करता है कि बिल्ड के काम करने के बाद क्या होता है। आप या तो अगली एनगेजमेंट पर इसे शुरुआत से फिर से बनाते हैं, या आप इसे एक बार पैकेज करते हैं, ताकि अगली टीम इसे कॉन्फ़िगर करे। दूसरा रास्ता वह है जो आपके समय को दोहराए गए पुनर्निर्माण के बजाय नए काम के लिए मुक्त करता है।

इस मॉड्यूल के अंत तक, आप सक्षम होंगे:

1 एक कार्यशील समाधान को एक पुन: प्रयोज्य एक्सेलेरेटर के रूप में पैकेज करें, चाहे वह एक पैरामीटरयुक्त एजेंट टेम्पलेट हो, एक कॉन्फ़िगरेबल MCP सर्वर हो, या एक पोर्टेबल eval सूट हो, ताकि अगली एनगेजमेंट एक संपत्ति को कॉन्फ़िगर करे बजाय पूरी तरह से इसे फिर से बनाने के। 2 एक टूल, पैटर्न, या फिक्स को दस्तावेज़ित चैनलों के माध्यम से वापस योगदान दें और इसे तैयार करें ताकि एक रखरखाव कर्ता इसे स्वीकार कर सके, एक निजी संपत्ति को साझा बुनियादी ढांचे में बदल दें। 3 चुनें कि Claude वर्कलोड पहली-पक्ष API, Amazon Bedrock, Google Vertex AI, और तीसरे-पक्ष प्लेटफॉर्म में कहां चलता है, और संस्करण करें कि क्या शिप होता है ताकि एक मॉडल या प्रॉम्प्ट परिवर्तन प्रोडक्शन को चुप से तोड़ न दे। 4 उन प्लेटफॉर्म की तुलना विलंबता, अनुपालन, और लागत पर करें ताकि पसंद एक ऐसी हो जिसे एक प्रोक्योरमेंट और सुरक्षा टीम साइन ऑफ कर सके, बजाय एक डिफ़ॉल्ट के जो आपकी टीम पहुंची हो। 5 एक एप्लिकेशन बनाएं जो कई Claude डिप्लॉयमेंट को एक वर्कफ़्लो में समन्वय करता है और इसे स्कोप करें ताकि डेटा और पहचान सीमाएं सुरक्षा या अनुपालन समीक्षा के तहत रखी जाएं।

यह मॉड्यूल उस डेवलपर के लिए है जिसके पास एक बिल्ड है जो काम करता है और अब इसे टिकाऊ बनाना चाहिए। आप व्यावहारिक, कोड-फॉरवर्ड, और पैटर्न-उन्मुख हैं, और पिछले मॉड्यूल ने इसे मान लिया और बनाया। इस बिंदु तक आप एक प्रोडक्शन एजेंट लिख सकते हैं, इसे Claude Code में कॉन्फ़िगर कर सकते हैं, MCP कनेक्शन वायर कर सकते हैं जो सुरक्षा समीक्षा पास करते हैं, और evals के साथ यह सब साबित कर सकते हैं। यह मॉड्यूल इनमें से किसी को फिर से नहीं सिखाता। यह उस क्षण को उठाता है जब आपका कोड सही तरीके से चलता है और कठिन सवाल पूछता है: क्या कोई और इसे फिर से उपयोग कर सकता है, क्या एक रखरखाव कर्ता इसे स्वीकार कर सकता है, क्या यह एक मॉडल अपडेट से बच सकता है, और क्या एक सुरक्षा या प्रोक्योरमेंट टीम साइन ऑफ कर सकती है कि यह कहां चलता है। यहां का काम कोड लिखने के बारे में कम है और उन निर्णयों के बारे में अधिक है जो समाप्त कोड को पुन: प्रयोज्य, तैनाती योग्य, और उन लोगों के लिए रक्षणीय बनाते हैं जिन्होंने इसे नहीं लिखा।

"इस मॉड्यूल में बिल्ड"

इस मॉड्यूल में सब कुछ एक आवर्ती अंतर पर निर्भर करता है: एक बिल्ड जो काम करता है वह अभी तक एक बिल्ड नहीं है जो पुन: उपयोग, समीक्षा, या तैनाती से बचता है। विकास में, टेम्पलेट चला, योगदान ने आपकी समस्या को हल किया, मॉडल ने जवाब दिया, प्लेटफॉर्म बनाने के लिए आसान था, और प्रत्येक प्लेटफॉर्म ने अपने स्वयं के परीक्षण पास किए। इनमें से कोई भी समाप्त स्थिति नहीं है। एक ही टेम्पलेट को एक टीम के लिए कॉन्फ़िगर किया जाना चाहिए जिसने कभी आपसे बात नहीं की। एक ही योगदान को एक रखरखाव कर्ता द्वारा सत्यापित किया जाना चाहिए जिसे कुछ भी पुनर्निर्माण नहीं करना चाहिए। एक ही मॉडल को पिन किया जाना चाहिए ताकि एक अपस्ट्रीम परिवर्तन एक निर्णय हो बजाय एक आश्चर्य के। एक ही प्लेटफॉर्म को एक ग्राहक की निवास और अनुपालन समीक्षा को साफ करना चाहिए। एक ही जुड़े प्लेटफॉर्म को ऑडिट के तहत अपनी विश्वास सीमाएं रखनी चाहिए। इस मॉड्यूल में प्रत्येक विषय एक ही पाठ का एक अलग संस्करण है: वह बिंदु जहां कोड काम करना शुरू करता है वह है जहां इस मॉड्यूल का काम शुरू होता है। इन निर्णयों में से अधिक जो आप सोच सकते हैं वह ग्राहक के मौजूदा क्लाउड, अनुपालन मुद्रा, और समीक्षा प्रक्रिया द्वारा संचालित होते हैं।

शैक्षणिक सामग्री के लिए अस्वीकरण / नोटिस

हमने यह डेवलपर कोर्स मॉड्यूल 5: एक्सेलेरेटर्स और आईपी योगदान बनाया ताकि आप Claude के साथ वास्तविक काम कर सकें। इसे शैक्षणिक सामग्री के रूप में मानें। यह कानूनी, वित्तीय, या अन्य व्यावसायिक सलाह का गठन नहीं करता है, इसलिए जो आप सीखते हैं उसे अपनी स्थिति के अनुसार अनुकूलित करें। हमारे उत्पाद और सेवाएं तेजी से विकसित होती हैं, इसलिए कुछ सामग्री में त्रुटियां हो सकती हैं या पुरानी हो सकती हैं; Anthropic की वेबसाइट या दस्तावेज़ पर सत्यापित करना याद रखें। पाठ्यक्रम में उपयोग किए गए उदाहरण और परिदृश्य सचित्र हैं और अक्सर काल्पनिक हैं। यदि पाठ्यक्रम सामग्री एक कंपनी या उत्पाद का उल्लेख करती है, तो इसका मतलब यह नहीं है कि Anthropic उन्हें समर्थन करता है, वे Anthropic को समर्थन करते हैं, या कि हम संबद्ध हैं। यह भी ध्यान दें कि Anthropic उत्पादों और सेवाओं का आपका उपयोग हमारी शर्तों, नीतियों और दस्तावेज़ द्वारा कवर किया गया है; यदि इस पाठ्यक्रम में कुछ उनके साथ विरोध करता है, तो वे नियंत्रण करते हैं।

स्क्रीन 2: एक कार्यशील बिल्ड को पैकेज करना ताकि अगली एनगेजमेंट एक संपत्ति से शुरू हो

शिक्षणपुन: उपयोग के लिए पैकेजिंग·16 मिनट एक कार्यशील बिल्ड को पैकेज करना ताकि अगली एनगेजमेंट एक संपत्ति से शुरू हो आपने पिछले मॉड्यूल को एक बिल्ड के साथ समाप्त किया जो चलता है: एक एजेंट लूप, एक कॉन्फ़िगर किया गया MCP सर्वर, एक eval जो साबित करता है कि प्रॉम्प्ट काम करता है। एक टीम पर सबसे समय लेने वाली और महंगी चीज इंजीनियरिंग समय है जो अगले ग्राहक के लिए एक ही चीज को फिर से बनाने में खर्च होता है। एक एक्सेलेरेटर क्या करता है: पुन: प्रयोज्य भागों को रखें और बाकी को अलग करें एक एक्सेलेरेटर एक समाधान है जो पैकेज किया गया है ताकि भविष्य की एनगेजमेंट एक कार्यशील नींव से शुरू हो बजाय एक खाली रिपॉजिटरी से। ब्लूप्रिंट शर्तों में, यह पुन: उपयोग के लिए पैकेजिंग है: एनगेजमेंट-विशिष्ट कोड को पुन: प्रयोज्य कोर से अलग करना और बाकी को पैरामीटरयुक्त करना। एक कार्यशील बिल्ड लें, उन भागों को अलग करें जो ग्राहक-विशिष्ट हैं, और उन्हें दस्तावेज़ित डिफ़ॉल्ट के साथ पैरामीटर के रूप में उजागर करें। संपत्ति तब कॉन्फ़िगर करती है बजाय पूरी तरह से फिर से लिखी जाती है। पुन: उपयोग के लिए पैकेजिंग जबकि बिल्ड ताजा है महीनों बाद इरादे को फिर से बनाने की तुलना में सस्ता है, जब वह व्यक्ति जो जानता था कि एक मान को हार्डकोड क्यों किया गया था चला गया है। अधिकांश पुन: प्रयोज्य काम विभिन्न संपत्ति प्रकारों में आता है, और प्रत्येक अलग तरीके से पैकेज करता है अधिकांश पुन: प्रयोज्य काम इस मॉड्यूल में उपयोग की जाने वाली तीन श्रेणियों में से एक में आता है: एक टेम्पलेट, एक कॉन्फ़िगरेबल सर्वर, या एक पोर्टेबल eval। प्रत्येक प्रकार एक अलग तरह का काम रखता है और अपने स्वयं के तरीके से पैकेज किया जाना चाहिए। गलत प्रकार तक पहुंचना एक संपत्ति को पुन: प्रयोज्य दिख सकता है जबकि इसे लागू करना अभी भी मुश्किल बनाता है।

संपत्ति प्रकारयह क्या बंडल करता हैसही पैकेजिंग के लिए क्या आवश्यक है एजेंट टेम्पलेटएक कार्यशील एजेंट से सिस्टम प्रॉम्प्ट, टूल स्कीमा, और लूप संरचना।डोमेन-विशिष्ट मानों को कॉन्फ़िगरेशन में खींचें दस्तावेज़ित डिफ़ॉल्ट के साथ, ताकि एक नई टीम लूप को संपादित करने के बजाय मान सेट करे। MCP सर्वर पैकेजसर्वर जो उजागर करता है, उनके इनपुट और स्कोप के साथ जो इंस्टॉलिंग टीम नियंत्रण करता है।प्रत्येक टूल इनपुट को दस्तावेज़ित करें और इंस्टॉलिंग टीम को स्कोप सेट करने दें, ताकि सर्वर कोड संपादन के बिना एक नए वातावरण में इंस्टॉल हो। Eval सूटग्रेडेड टेस्ट सेट और जज रूब्रिक जो साबित करते हैं कि संपत्ति काम करती है।डेटासेट और रूब्रिक को एक साथ शिप करें ताकि एक नई टीम उन्हें अपने संदर्भ में चला सके और पुष्टि कर सके कि संपत्ति अभी भी वहां काम करती है। एक ही eval सूट तैनाती पर गेट के रूप में भी कार्य करता है। जब आप एक नए मॉडल संस्करण को प्रोडक्शन में प्रचार करते हैं, तो संस्करण लाइव जाने से पहले इसे एक पिन किए गए बेसलाइन स्कोर के विरुद्ध चलाएं।

एक एजेंट को ढीली स्क्रिप्ट के सेट के रूप में शिप करना बजाय एक टेम्पलेट के गलत दृष्टिकोण का सबसे सामान्य संस्करण है। स्क्रिप्ट चलती हैं, इसलिए वे पुन: प्रयोज्य दिखते हैं, लेकिन हर ग्राहक-विशिष्ट मान एक अलग फ़ाइल में दफन है, और अगली टीम उन्हें कॉपी और विचलित करती है बजाय एक संपत्ति को कॉन्फ़िगर करने के। कोड और धारणाओं दोनों को दस्तावेज़ित करें कोड व्यवहार का वर्णन करता है। दस्तावेज़ कवर करता है कि एक भविष्य के निर्माता को स्रोत को पढ़ने से विश्वसनीय रूप से क्या अनुमान नहीं लगा सकता: संपत्ति अपने वातावरण के बारे में जो धारणाएं करता है, जो इनपुट वह उम्मीद करता है, विफलता के तरीके जो वह पहले से संभालता है, और eval जो परिभाषित करता है कि क्या यह अभी भी काम करता है। इसके बिना, अगली टीम संपत्ति को एक ब्लैक बॉक्स के रूप में मानती है और इसे फिर से बनाती है। ऑडिट लॉग को पैकेज के हिस्से के रूप में बंडल करें एक विनियमित ग्राहक का समीक्षक पूछता है कि संपत्ति कौन सा डेटा छूती है, किस पहचान के तहत यह कार्य करता है, और किस लॉग को यह छोड़ता है। एक एक्सेलेरेटर इन के बिना एक डेमो पास करता है और पहली सुरक्षा समीक्षा पर ठहरता है। ऑडिट लॉग को पैकेज के हिस्से के रूप में मानें। पैकेजिंग चेकलिस्ट इस चेकलिस्ट को बिल्ड के बगल में रखें जबकि आप इसे पैकेज करते हैं। प्रत्येक कॉलम एक निर्णय है जो आप प्रति संपत्ति एक बार करते हैं।

संपत्ति प्रकारक्या पैरामीटरयुक्त करेंक्या दस्तावेज़ित करेंऑडिट के लिए क्या बंडल करें एजेंट टेम्पलेटहर मान जो प्रति ग्राहक बदलता है: प्रॉम्प्ट, पथ, स्कोप, संदर्भ द्वारा क्रेडेंशियल, और थ्रेसहोल्ड।वातावरण धारणाएं, अपेक्षित इनपुट, संभाली गई विफलता के तरीके, और eval जो कार्यशील को परिभाषित करता है।डेटा छुआ, पहचान के तहत कार्य किया, और संपत्ति ने क्या किया का लॉग। MCP सर्वरस्कोप, संदर्भ द्वारा क्रेडेंशियल, और प्रति-ग्राहक पथ।प्रति टूल अपेक्षित इनपुट, स्कोप सीमाएं, और संभाली गई विफलता के तरीके।डेटा छुआ, पहचान के तहत कार्य किया, और संपत्ति ने क्या किया का लॉग। Eval सूटथ्रेसहोल्ड और डेटासेट पथ जो प्रति ग्राहक या वातावरण बदलते हैं।रूब्रिक तर्क, स्कोर का क्या मतलब है, और बेसलाइन संपत्ति पिन की गई है।डेटा छुआ, पहचान के तहत कार्य किया, और संपत्ति ने क्या किया का लॉग।

अच्छी तरह से संभालता है बिल्ड ताजा होने पर पैरामीटरयुक्त करना एक डिलीवरी को एक संपत्ति में बदल देता है जो अगली एनगेजमेंट घंटों में कॉन्फ़िगर करती है।

लागत या जटिलता जोड़ता है सामान्यीकरण योग्य से ग्राहक-विशिष्ट भागों को अलग करना और धारणाओं को दस्तावेज़ित करना पहली बिल्ड में वास्तविक समय जोड़ता है।

एक अलग दृष्टिकोण का उपयोग करें एक बार के लिए जो ग्राहक कभी फिर से उपयोग नहीं करेगा, पैकेजिंग ओवरहेड इसके लायक नहीं है: बिल्ड शिप करें और आगे बढ़ें।

स्क्रीन 3: टेम्पलेट जो तेजी से शिप हुआ और पुन: उपयोग नहीं किया जा सका

सावधानी रखेंपुन: उपयोग के लिए पैकेजिंग·2 मिनट टेम्पलेट जो तेजी से शिप हुआ और पुन: उपयोग नहीं किया जा सका

सेटअप हार्डकोडिंग तेजी से शिप होती है और आप एक समय सीमा के तहत काम कर रहे थे, इसलिए आपने डेमो को बनाने वाले मानों को हार्डकोड किया। टेम्पलेट काम करता था। यह बिल्कुल वही कारण है कि जब तक अगली टीम इसे फिर से उपयोग करने की कोशिश नहीं करती तब तक कोई भी इसे फिर से नहीं देखता।

यह एक पोस्टमॉर्टम है, जिस तरह से एक टीम एक लिखती है पुन: उपयोग प्रयास विफल होने के बाद, ताकि आप विफलता को देख सकें इससे पहले कि कोई इसे एक गलती के रूप में लेबल करे। क्या हुआ एक टीम ने एक ग्राहक एनगेजमेंट के लिए एक एजेंट टेम्पलेट बनाया और समय पर शिप किया। समय सीमा को पूरा करने के लिए, ग्राहक-विशिष्ट मान सीधे कोड में चले गए: रिपॉजिटरी पथ, मॉडल नाम, समीक्षा थ्रेसहोल्ड, और उस ग्राहक के डोमेन के लिए विशिष्ट कुछ प्रॉम्प्ट टुकड़े। टेम्पलेट चला, एनगेजमेंट बंद हुई, और बिल्ड को पुन: प्रयोज्य के रूप में लेबल किए गए साझा रिपॉजिटरी में रखा गया। महीनों बाद एक दूसरी टीम ने इसे एक समान एनगेजमेंट के लिए उठाया। वे इसे कॉन्फ़िगर नहीं कर सकते थे, क्योंकि कॉन्फ़िगर करने के लिए कुछ नहीं था। हर मान जो बदलने की जरूरत थी लूप में बेक किया गया था जहां दूसरी टीम पूरी फ़ाइल को पढ़े बिना इसे नहीं देख सकती थी। कोई दस्तावेज़ नहीं था जो कहता था कि कौन से मान ग्राहक-विशिष्ट थे और कौन से भार-असर थे। कोई बंडल किया गया eval भी नहीं था, इसलिए यहां तक कि अनुमान के बाद, कुछ भी पुष्टि नहीं करता था कि टेम्पलेट अभी भी नए संदर्भ में काम करता था। उन्हें इसे शुरुआत से फिर से लिखना पड़ा।

क्यों यह टूट गया बिल्ड को समाप्त माना गया था जब यह चलता था बजाय जब यह पुन: उपयोग किया जा सकता था। हार्डकोडिंग एक समय सीमा के तहत उचित कॉल था, और इसे कभी फिर से देखा नहीं गया। एक कार्यशील टेम्पलेट घोषणा नहीं करता है कि यह पुन: उपयोग नहीं किया जा सकता। लागत केवल तब दिखाई दी जब एक दूसरी टीम ने पुनर्निर्माण के लिए भुगतान किया जो पैकेजिंग को रोकना था, साथ ही समय जो उन्होंने खोजा कि टेम्पलेट एक मृत अंत था।

क्या सावधानी रखें एक टेम्पलेट जो चलता है पुन: उपयोग के लिए पैकेज नहीं किया गया है। ये अलग समाप्ति राज्य हैं। चेतावनी के संकेत तीन चीजों की अनुपस्थिति हैं: कोई पैरामीटर नहीं जहां ग्राहक-विशिष्ट मान संबंधित हैं, कोई दस्तावेज़ नहीं जो धारणाओं का वर्णन करता है, और कोई बंडल किया गया eval नहीं जो साबित करता है कि संपत्ति अभी भी एक अलग संदर्भ में काम करती है। संपत्ति को पैकेज करें जबकि बिल्ड ताजा है। जो ग्राहक-विशिष्ट है इसका ज्ञान उन लोगों के चले जाने के बाद पुनर्निर्माण करने के लिए सबसे महंगा है।

स्क्रीन 4: चेकपॉइंट 1: टूटे हुए एक्सेलेरेटर टेम्पलेट को ठीक करें

चेकपॉइंटएक पुन: प्रयोज्य एक्सेलेरेटर पैकेजिंग·4 मिनट चेकपॉइंट 1: टूटे हुए एक्सेलेरेटर टेम्पलेट को ठीक करें अभी कोशिश करें। नीचे एक एजेंट टेम्पलेट है जो एक अन्य टीम को फिर से उपयोग करना है। इसमें एक दोष है: एक ग्राहक-विशिष्ट मान हार्डकोड किया गया है जहां एक पैरामीटर संबंधित है। टेम्पलेट जैसा शिप किया गया

def build_review_agent(): return Agent( model="claude-opus-4-8", system_prompt=SYSTEM_PROMPT, tools=[read_file, run_linter], repo_path="/home/acme/checkout-service", # customer repo ) (बिल्ड समय पर platform. claude. com/docs/en/about-claude/models पर वर्तमान मॉडल ID की पुष्टि करें।) हार्डकोड किए गए मान की पहचान करें, फिर सही किए गए फ़ंक्शन हस्ताक्षर और पैरामीटरयुक्त लाइन लिखें जो इसे बदलती है।

मॉडल उत्तर के साथ तुलना करें अभी के लिए छोड़ें

छोड़ दिया गयाआगे बढ़ें यदि आपको चाहिए लेकिन संचयी कार्य से पहले वापस आएं। एक बाद की चेकपॉइंट इस एक ही हार्डकोडिंग दोष को दो अन्य के बीच रोपण करता है और बहु-परत भार के तहत स्पॉट करना कठिन है।

स्क्रीन 5: एक संपत्ति को निजी पुन: उपयोग से साझा बुनियादी ढांचे में स्थानांतरित करना एक रखरखाव कर्ता स्वीकार करता है

शिक्षणवापस योगदान·12 मिनट एक संपत्ति को निजी पुन: उपयोग से साझा बुनियादी ढांचे में स्थानांतरित करना एक रखरखाव कर्ता स्वीकार करता है आपने पहले से ही अधिकांश काम कर चुके हैं जो एक संपत्ति को साझा करने योग्य बनाता है। जब आपने इसे अपनी टीम के पुन: उपयोग के लिए पैकेज किया, तो आपने पैरामीटर खींचे, धारणाओं को लिखा, और eval को बंडल किया। पैरामीटर दिखाते हैं कि संपत्ति को कॉन्फ़िगर किया जा सकता है बजाय फिर से लिखा जाता है। दस्तावेज़ित धारणाएं रखरखाव कर्ता को बताती हैं कि संपत्ति किस वातावरण की उम्मीद करता है। बंडल किया गया eval उन्हें यह पुष्टि करने का एक तरीका देता है कि यह अभी भी काम करता है। एक आंतरिक पुन: उपयोग के लिए पैकेज की गई संपत्ति पहले से ही एक रखरखाव कर्ता को स्वीकार करने के लिए आवश्यक के करीब है। योगदान चैनल उस पैकेज की गई संपत्ति को प्राप्त करने के लिए डिज़ाइन किया गया है। यह संस्करण, इंस्टॉलेशन चरण, और घटकों को एक एकल इकाई के रूप में ले जाता है, ताकि एक टीम जिसने कभी आपसे बात नहीं की वह इसे इंस्टॉल कर सके और एक ही कार्यशील सेटअप प्राप्त कर सके। योगदान को इसके लिए बनाए गए चैनल से मेल खाएं वापस योगदान देना एक संपत्ति को निजी पुन: उपयोग से साझा बुनियादी ढांचे में एक दस्तावेज़ित चैनल के माध्यम से स्थानांतरित करना है। प्रत्येक चैनल एक विशिष्ट प्रकार के योगदान के लिए बनाया गया है। Claude Cookbook एक GitHub रिपॉजिटरी है जिसमें केंद्रित संदर्भ कार्यान्वयन हैं। यह स्वयं-निहित एकल- या बहु-पैटर्न कार्यान्वयन के लिए डिज़ाइन किया गया है जो स्पष्ट रूप से प्रदर्शित और अंत से अंत तक काम करते हैं। ओपन-सोर्स MCP सर्वर और टूल प्रत्येक अपने स्वयं के रिपॉजिटरी में अपने स्वयं के योगदान सम्मेलन के साथ रहते हैं। Cookbook को एक पूर्ण बहु-घटक एप्लिकेशन भेजना एक बेमेल है। रिपॉजिटरी एक केंद्रित पैटर्न की समीक्षा करने के लिए सेट अप किया गया है बजाय एक पूरी एप्लिकेशन के, इसलिए एक प्रस्तुति जो बड़ी है वह फिट नहीं होती है जो समीक्षकों को देख रहे हैं और ठहर जाएगी। पहला कदम योगदान को इसके लिए बनाए गए चैनल से मेल खाना है। एक पूर्ण एप्लिकेशन को रखना जहां एक केंद्रित उदाहरण संबंधित है एक योगदान को कभी समीक्षा नहीं किए जाने के सबसे सामान्य कारणों में से एक है। एक योगदान को सत्यापित करना क्या संभव बनाता है एक रखरखाव कर्ता एक योगदान स्वीकार करता है जो वे सत्यापित कर सकते हैं। बार को सेट किया जाता है जो उन्हें जांचने की जरूरत है, न कि कोड कितना चतुर है। चार चीजें सत्यापन को संभव बनाती हैं:

1कोड एक चीज करता है। एक विस्तृत योगदान एक समीक्षक को आपके इरादे को फिर से बनाने के लिए मजबूर करता है। 2एक उदाहरण इसे चलाते हुए दिखाता है। एक समीक्षक को व्यवहार को देखने के लिए एक हार्नेस बनाना नहीं चाहिए। 3एक परीक्षण साबित करता है कि यह काम करता है। एक परीक्षण एक रखरखाव कर्ता को परिणाम को सत्यापित करने देता है बिना तर्क को फिर से बनाए। 4एक छोटा बयान धारणाओं का नाम देता है। अन्यथा, पहली विफलता रखरखाव कर्ता की समस्या बन जाती है।

अधिकार और विशेषता तकनीकी समीक्षा से पहले आते हैं लाइसेंसिंग और विशेषता तय करते हैं कि क्या एक योगदान को बिल्कुल स्वीकार किया जा सकता है, यही कारण है कि वे तकनीकी समीक्षा से पहले आते हैं। एक ग्राहक एनगेजमेंट से किया गया कोड कहां जा सकता है इस पर बाधाएं हो सकती हैं। पुष्टि करना कि आपके पास इसे योगदान देने का अधिकार है, और आपने जो बनाया है उसे विशेषता देना, एक गेट है जो योगदान को पहले पास करना चाहिए। इसे छोड़ना वह है जो एक योगदान को एक समस्या में बदल देता है जिसे कानूनी टीम को बाद में सुलझाना चाहिए। यहां काम किया गया उदाहरण ग्राहक सेवा एजेंट केस है। एक पुन: प्रयोज्य बातचीत-हैंडलिंग पैटर्न, एक एनगेजमेंट के दौरान बनाया गया, ग्राहक विशिष्टताओं से छीन लिया जाता है और Cookbook के लिए एक सामान्य उदाहरण के रूप में तैयार किया जाता है। योगदान-वापस गति इस पाठ्यक्रम में सभी तीन भूमिकाओं में साझा की जाती है। डेवलपर के रूप में आपका काम तकनीकी तैयारी है: केंद्रित कोड, उदाहरण, परीक्षण, धारणाएं, और अधिकार जांच। एनगेजमेंट संदर्भ व्यापक टीम से आता है। योगदान-तैयारी संदर्भ

चैनलएक रखरखाव कर्ता क्या जांचता हैलाइसेंसिंग और विशेषताउदाहरण और परीक्षण बार को साफ करने के लिए Cookbook एक केंद्रित उदाहरण के लिए, या टूल या सर्वर के अपने रिपॉजिटरी के लिए एक टूल या फिक्स के लिए।कि कोड एक चीज करता है और कि वे इसे पूरी तरह से पढ़ सकते हैं।पुष्टि करें कि आपके पास एक एनगेजमेंट से कोड योगदान देने का अधिकार है, पूर्व काम विशेषता के साथ।एक चलाने योग्य उदाहरण प्लस एक परीक्षण जो व्यवहार साबित करता है, केवल एक विवरण नहीं।

अच्छी तरह से संभालता है एक पैकेज की गई संपत्ति को केवल उदाहरण, परीक्षण, और अधिकार जांच की जरूरत है साझा बुनियादी ढांचे बनने के लिए जो अन्य बनाते हैं।

लागत या जटिलता जोड़ता है रखरखाव कर्ता बार को साफ करना और लाइसेंसिंग गेट कोड को चलाने के लिए वास्तविक काम है।

एक अलग दृष्टिकोण का उपयोग करें जब कोड एक एनगेजमेंट लाइसेंसिंग बाधा ले जाता है जिसे आप साफ नहीं कर सकते, तो इसे योगदान न दें: इसके बजाय मालिक को बढ़ाएं।

स्क्रीन 6: पुल अनुरोध जो एक रखरखाव कर्ता सत्यापित नहीं कर सका

सावधानी रखेंवापस योगदान·2 मिनट पुल अनुरोध जो एक रखरखाव कर्ता सत्यापित नहीं कर सका

सेटअप आपने योगदान को सटीक कोड के साथ खोला जो आपकी समस्या को हल करता है। यह प्राकृतिक पसंद था क्योंकि यह आपके मामले में काम करता था और यह सुलभ था। यह आपके लिए काम करता है, लेकिन यह बिल्कुल वही कारण है कि यह एक अजनबी को विश्वास करने की जरूरत है सब कुछ याद कर रहा था।

यह एक आंतरिक चैनल से एक विनिमय है ताकि आप सुन सकें कि एक रखरखाव कर्ता एक पुल अनुरोध पर चुप्पी की व्याख्या कैसे करता है। विनिमय डेवलपर: मेरा PR तीन सप्ताह के लिए कोई समीक्षा के साथ खुला है। कोड काम करता है, मैं इसे हर दिन उपयोग करता हूं। होल्डअप क्या है? रखरखाव कर्ता: यह संभवतः आपके लिए काम करता है। समस्या यह है कि मैं नहीं बता सकता। कोई परीक्षण नहीं है जो मैं चला सकता हूं, कोई उदाहरण नहीं जो व्यवहार साबित करता है, और कुछ भी नहीं कहता है कि यह वातावरण के बारे में क्या मानता है। डेवलपर: तो, आप चाहते हैं कि मैं एक परीक्षण और एक उदाहरण जोड़ूं? रखरखाव कर्ता: हां। एक योगदान जो एक समीक्षक सत्यापित नहीं कर सकता वह तब तक कतार के पीछे बैठता है जब तक कि किसी के पास इसे फिर से बनाने का समय न हो। एक केंद्रित PR एक परीक्षण और एक उदाहरण के साथ तेजी से समीक्षा हो जाता है क्योंकि समीक्षक के लिए फिर से इंजीनियर करने के लिए कुछ नहीं है।

क्यों यह टूट गया कोड सही था। योगदान ठहर गया क्योंकि रखरखाव कर्ता इसे सत्यापित नहीं कर सकता था बिना डेवलपर के काम को फिर से बनाए। वह अंतर आसानी से अनदेखा किया जा सकता है क्योंकि लेखक के पास पहले से ही लापता संदर्भ है। उदाहरण, परीक्षण, और धारणाएं बयान सभी कोड बनाने वाले व्यक्ति के लिए स्पष्ट लगते हैं। रखरखाव कर्ता के लिए, हालांकि, वे नहीं हैं, और एक समीक्षक जिसे इरादे को फिर से बनाना चाहिए वह हमेशा इसे अंतिम करेगा।

क्या सावधानी रखें एक पुल अनुरोध जो समीक्षक सत्यापित नहीं कर सकता उस पर ठहरता है। योगदान खोलने से पहले, उदाहरण जोड़ें जो इसे चलाते हुए दिखाता है, परीक्षण जो व्यवहार साबित करता है, और छोटा बयान जो नाम देता है कि यह क्या मानता है। वे तीन विशेषताएं वह हैं जो एक योगदान को कतार के पीछे से एक तेजी से समीक्षा में स्थानांतरित करती हैं, क्योंकि वे रखरखाव कर्ता को फिर से इंजीनियर करने के लिए कुछ नहीं छोड़ते हैं।

स्क्रीन 7: चेकपॉइंट 2: योगदान चैनल चुनें और तैयारी फिक्स करें

चेकपॉइंटइकोसिस्टम में वापस योगदान·3 मिनट चेकपॉइंट 2: योगदान चैनल चुनें और तैयारी फिक्स करें अभी कोशिश करें। नीचे तीन मामले पढ़ें। प्रत्येक मामले को इसके लिए बनाए गए चैनल से मेल खाएं और प्रत्येक मामले को एक तैयारी आइटम से मेल खाएं जो स्निपेट याद कर रहा है।

मामला A: एक केंद्रित टूल जो एक एकल API को एक स्वच्छ फ़ंक्शन में लपेटता है। स्निपेट फ़ंक्शन और कुछ नहीं है। मामला B: एक पूर्ण ग्राहक-सेवा एप्लिकेशन जो एक डेवलपर पूरी तरह से साझा करना चाहता है, इसके UI और तैनाती स्क्रिप्ट सहित। मामला C: एक Cookbook उदाहरण के लिए एक-पंक्ति फिक्स। स्निपेट सही की गई लाइन है, एक ग्राहक एनगेजमेंट से किया गया।

मेल 1: मामले को चैनल से मामला A: एक केंद्रित टूल जो एक एकल API को एक स्वच्छ फ़ंक्शन में लपेटता है। स्निपेट फ़ंक्शन और कुछ नहीं है।टूल के अपने रिपॉजिटरीCookbook, लेकिन केवल पुन: प्रयोज्य पैटर्न को एक केंद्रित उदाहरण के रूप में छीन लिया जाता हैCookbook उदाहरण के अपने रिपॉजिटरी मामला B: एक पूर्ण ग्राहक-सेवा एप्लिकेशन साझा किया गया पूरी तरह से, इसके UI और तैनाती स्क्रिप्ट सहित।टूल के अपने रिपॉजिटरीCookbook, लेकिन केवल पुन: प्रयोज्य पैटर्न को एक केंद्रित उदाहरण के रूप में छीन लिया जाता हैCookbook उदाहरण के अपने रिपॉजिटरी मामला C: एक Cookbook उदाहरण के लिए एक-पंक्ति फिक्स। स्निपेट सही की गई लाइन है, एक ग्राहक एनगेजमेंट से किया गया।टूल के अपने रिपॉजिटरीCookbook, लेकिन केवल पुन: प्रयोज्य पैटर्न को एक केंद्रित उदाहरण के रूप में छीन लिया जाता हैCookbook उदाहरण के अपने रिपॉजिटरी मेल 2: मामले को लापता तैयारी आइटम से मामला A: एक केंद्रित टूल जो एक एकल API को एक स्वच्छ फ़ंक्शन में लपेटता है। स्निपेट फ़ंक्शन और कुछ नहीं है।एक परीक्षण जो रैपर व्यवहार साबित करता हैएक एकल केंद्रित पैटर्न में कमी, क्योंकि एक पूरी एप्लिकेशन एक पैटर्न के लिए बनाई गई समीक्षा में फिट नहीं होती हैअधिकार जांच, क्योंकि एनगेजमेंट कोड एक लाइसेंसिंग बाधा ले जा सकता है जो विलय से पहले ब्लॉक करता है मामला B: एक पूर्ण ग्राहक-सेवा एप्लिकेशन साझा किया गया पूरी तरह से, इसके UI और तैनाती स्क्रिप्ट सहित।एक परीक्षण जो रैपर व्यवहार साबित करता हैएक एकल केंद्रित पैटर्न में कमी, क्योंकि एक पूरी एप्लिकेशन एक पैटर्न के लिए बनाई गई समीक्षा में फिट नहीं होती हैअधिकार जांच, क्योंकि एनगेजमेंट कोड एक लाइसेंसिंग बाधा ले जा सकता है जो विलय से पहले ब्लॉक करता है मामला C: एक Cookbook उदाहरण के लिए एक-पंक्ति फिक्स। स्निपेट सही की गई लाइन है, एक ग्राहक एनगेजमेंट से किया गया।एक परीक्षण जो रैपर व्यवहार साबित करता हैएक एकल केंद्रित पैटर्न में कमी, क्योंकि एक पूरी एप्लिकेशन एक पैटर्न के लिए बनाई गई समीक्षा में फिट नहीं होती हैअधिकार जांच, क्योंकि एनगेजमेंट कोड एक लाइसेंसिंग बाधा ले जा सकता है जो विलय से पहले ब्लॉक करता है

जमा करें अभी के लिए छोड़ें

स्क्रीन 8: व्यावसायिक आवश्यकताओं से कार्यात्मक और बुनियादी ढांचे की आवश्यकताओं तक

शिक्षणआवश्यकताएं और जीवनचक्र·8 मिनट व्यावसायिक आवश्यकताओं से कार्यात्मक और बुनियादी ढांचे की आवश्यकताओं तक जो तैनाती-प्लेटफॉर्म निर्णय अनुसरण करते हैं वे सभी मानते हैं कि आवश्यकताएं पहले से मौजूद हैं: निवास नियम, विलंबता लक्ष्य, पहचान मॉडल। यह स्क्रीन है जहां वे आते हैं: एक व्यावसायिक समस्या को कार्यात्मक और बुनियादी ढांचे की आवश्यकताओं में बदलना जो एक तैनाती निर्णय का बचाव किया जा सकता है। एक व्यावसायिक समस्या से कार्यात्मक आवश्यकताओं को कैप्चर करना एक कार्यात्मक आवश्यकता नाम देती है कि सिस्टम को क्या करना चाहिए, पर्याप्त विवरण के साथ कहा गया है जांच करने के लिए। एक व्यावसायिक समस्या (जैसे "समर्थन एजेंटों को तेजी से जवाब देने में मदद करें") अभी तक एक आवश्यकता नहीं है; कार्यात्मक आवश्यकताएं इससे प्राप्त होती हैं (जैसे "प्रत्येक टिकट को चार कतारों में से एक में वर्गीकृत करें; प्रासंगिक नीति का हवाला देते हुए एक ड्राफ्ट जवाब; मानव अनुमोदन के बिना कभी ऑटो-भेजें नहीं")। अनुशासन प्रत्येक को जांचने योग्य व्यवहार के बयान के रूप में लिखना है। एक अस्पष्ट लक्ष्य को डिज़ाइन नहीं किया जा सकता या सत्यापित किया जा सकता है, जबकि एक विशिष्ट एक eval में एक पंक्ति बन जाता है और समीक्षा पर एक मानदंड। बुनियादी ढांचे की आवश्यकताओं को प्राप्त करना बुनियादी ढांचे की आवश्यकताएं गैर-कार्यात्मक बाधाएं हैं जो तैनाती को संतुष्ट करनी चाहिए। अधिकांश उन्हें व्यावसायिक समस्या में नहीं कहा जाता है; इसके बजाय, आप उन्हें उन प्रश्नों को पूछकर प्राप्त करते हैं जो व्यावसायिक समस्या निहित करता है। विलंबता: एक प्रतिक्रिया कितनी तेजी से होनी चाहिए, जहां उपयोगकर्ता को मापा जाता है? स्केल: कितने अनुरोध, और किस शिखर पर? निवास: डेटा को कहां संसाधित किया जाना चाहिए, और किस विनियमन के तहत? पहचान: कौन कार्य करता है, किस क्रेडेंशियल के तहत, और क्या ऑडिट करने योग्य होना चाहिए? विलंबता, स्केल, निवास, और पहचान बुनियादी ढांचे की आवश्यकताएं हैं जो अक्सर तैनाती प्लेटफॉर्म तय करती हैं, और वे शुरुआत में कैप्चर करने के लिए सबसे आसान हैं, इससे पहले कि एक प्लेटफॉर्म अन्य कारणों के लिए चुना जाए। आवश्यकताओं को दस्तावेज़ित करना ताकि एक निर्णय का बचाव किया जा सके आवश्यकताएं लिखी जाती हैं क्योंकि तैनाती निर्णय की समीक्षा उन लोगों द्वारा की जाएगी जिन्होंने उन्हें एकत्र नहीं किया। कार्यात्मक व्यवहार, बुनियादी ढांचे की बाधाओं, और प्रत्येक बाधा आने वाले विनियमन को कवर करने वाली एक छोटी आवश्यकताएं रिकॉर्ड आपको एक प्लेटफॉर्म पसंद का बचाव करने देती है क्योंकि यह आवश्यकताओं से अनुसरण करता है बजाय परिचितता से। यह रिकॉर्ड अगली स्क्रीन के तैनाती निर्णय को पढ़ने के लिए इनपुट है।

अच्छी तरह से संभालता है एक व्यावसायिक समस्या को जांचने योग्य कार्यात्मक और बुनियादी ढांचे की आवश्यकताओं में बदलना किसी भी प्लेटफॉर्म को चुनने से पहले।

लागत या जटिलता जोड़ता है बुनियादी ढांचे की बाधाओं को अग्रिम रूप से निकालना एक स्कोपिंग बातचीत लेता है जो टीम छोड़ने के लिए लुभाई जाती है।

एक अलग दृष्टिकोण का उपयोग करें एक फेंकने योग्य प्रोटोटाइप के लिए कोई समीक्षा और कोई विनियमित डेटा के साथ, हल्के नोट्स पर्याप्त हैं।

स्क्रीन 9: चेकपॉइंट 3: आवश्यकताओं को निकालें

चेकपॉइंटआवश्यकताएं और जीवनचक्र·2 मिनट चेकपॉइंट 3: आवश्यकताओं को निकालें अभी कोशिश करें। एक विनियमित EU बैंक एक एजेंट चाहता है जो अपनी समर्थन टीम के लिए ग्राहक कॉल ट्रांसक्रिप्ट को सारांशित करता है, EU में संग्रहीत होने से पहले सारांश की समीक्षा की जाती है। प्रश्न 1एक विनियमित EU बैंक एक एजेंट चाहता है जो अपनी समर्थन टीम के लिए ग्राहक कॉल ट्रांसक्रिप्ट को सारांशित करता है। निम्नलिखित में से कौन सा एक वैध कार्यात्मक आवश्यकता है? Aएजेंट तेजी और सटीक होना चाहिए।Bएजेंट एक सारांश तैयार करता है जिसे एक मानव अनुमोदित करता है इससे पहले कि यह संग्रहीत हो।Cसिस्टम को एक अनुमोदित क्लाउड प्रदाता का उपयोग करके बनाया जाना चाहिए।Dट्रांसक्रिप्ट डेटा EU को नहीं छोड़ना चाहिए। प्रश्न 2एक ही परिदृश्य से, निम्नलिखित में से कौन सा एक वैध बुनियादी ढांचे की आवश्यकता है? Aएजेंट को सारांश तेजी से उत्पादित करना चाहिए ताकि समर्थन कर्मचारी उन पर कार्य कर सकें।Bएजेंट एक पूर्व-अनुमोदित प्रॉम्प्ट टेम्पलेट का उपयोग करके ट्रांसक्रिप्ट को सारांशित करता है।Cट्रांसक्रिप्ट डेटा EU में संसाधित किया जाता है।Dएक मानव प्रत्येक सारांश की समीक्षा करता है इससे पहले कि यह संग्रहीत हो।

जमा करें अभी के लिए छोड़ें

स्क्रीन 10: Claude एप्लिकेशन के लिए सिस्टम जीवनचक्र

शिक्षणआवश्यकताएं और जीवनचक्र·8 मिनट Claude एप्लिकेशन के लिए सिस्टम जीवनचक्र आपने जो आवश्यकताएं कैप्चर की हैं वह एक लंबे चाप का पहला चरण है। यह स्क्रीन उस चाप को सिस्टम जीवनचक्र के रूप में नाम देती है, ताकि इस मॉड्यूल में तैनाती, संस्करण, और सीमा काम असंबंधित कार्य के रूप में आने के बजाय सही चरण में बैठे। Claude एप्लिकेशन पर लागू जीवनचक्र चरण एक Claude एप्लिकेशन किसी भी इंजीनियर किए गए सिस्टम के समान जीवनचक्र से गुजरता है, मॉडल काम इस पर मैप किया गया:

1आवश्यकताएं: कार्यात्मक और बुनियादी ढांचे की जरूरतों को कैप्चर करें 2डिजाइन: प्लेटफॉर्म, मॉडल, और विश्वास सीमाओं को चुनें 3बिल्ड: एजेंट, टूल, और प्रॉम्प्ट लिखें 4परीक्षण: evals, यूनिट, एकीकरण, और अंत से अंत तक जांच 5तैनाती: संस्करण को पिन करें, eval पर प्रचार को गेट करें 6संचालन: लागत, विलंबता, और त्रुटियों को साधन करें; guardrails को लागू करें 7पुनरावृत्ति: प्रोडक्शन निष्कर्षों को आवश्यकताओं में वापस खिलाएं

चरण वही हैं जो पिछले मॉड्यूल एक बार सिखाते हैं। उन्हें एक जीवनचक्र के रूप में पहचानना वह है जो दिखाता है कि वे कैसे जुड़ते हैं। चरणों के बीच गेटिंग एक गेट एक चरण से अगले चरण में जाने का निर्णय है, और यह है जहां एक विनियमित एनगेजमेंट नियंत्रण रखता है। आप डिजाइन से बिल्ड तक नहीं जाते जब तक प्लेटफॉर्म निवास आवश्यकता को संतुष्ट नहीं करता; आप तैनाती से पूर्ण प्रोडक्शन की ओर नहीं जाते जब तक नया संस्करण पिन किए गए बेसलाइन के विरुद्ध eval को साफ नहीं करता। इंजीनियरिंग काम को सही चरण में रखना, और एक गेट को छोड़ने से इनकार करना, वह है जो एक Claude एप्लिकेशन को समीक्षा योग्य रखता है।

अच्छी तरह से संभालता है प्रत्येक इंजीनियरिंग काम को जीवनचक्र चरण में रखना जो यह संबंधित है, एक परिभाषित कलाकृति और गेट के साथ।

लागत या जटिलता जोड़ता है चरणों के बीच गेटिंग चेकपॉइंट जोड़ता है जो एक समय सीमा के तहत एक टीम छोड़ने के लिए लुभाई जाती है।

एक अलग दृष्टिकोण का उपयोग करें एक बार के प्रयोग को चरणों को ढहा सकता है, लेकिन एक विनियमित तैनाती नहीं कर सकता।

स्क्रीन 11: चेकपॉइंट 4: काम को सही चरण में रखें

चेकपॉइंटआवश्यकताएं और जीवनचक्र·2 मिनट चेकपॉइंट 4: काम को सही चरण में रखें अभी कोशिश करें। प्रत्येक गतिविधि को जीवनचक्र चरण में रखें जो यह संबंधित है: आवश्यकताएं, डिजाइन, परीक्षण, तैनाती, संचालन। (a) पूर्ण मॉडल ID को पिन करना और पूर्व संस्करण को रखनाआवश्यकताएंडिजाइनपरीक्षणतैनातीसंचालन(b) एक संस्करण प्रोडक्शन में जाने से पहले eval परिणाम पर प्रचार को गेट करनाआवश्यकताएंडिजाइनपरीक्षणतैनातीसंचालन(c) डेटा को एक विशिष्ट क्षेत्र में संसाधित किया जाना चाहिए यह तय करनाआवश्यकताएंडिजाइनपरीक्षणतैनातीसंचालन(d) प्रोडक्शन में प्रति कॉल token लागत और विलंबता को साधन करनाआवश्यकताएंडिजाइनपरीक्षणतैनातीसंचालन(e) Amazon Bedrock चुनना क्योंकि ग्राहक वहां अपनी अनुपालन मुद्रा रखता हैआवश्यकताएंडिजाइनपरीक्षणतैनातीसंचालन

जमा करें अभी के लिए छोड़ें

स्क्रीन 12: चुनना कि Claude वर्कलोड कहां चलता है और संस्करण को पिन करना जो शिप होता है

शिक्षणतैनाती और संस्करण·15 मिनट चुनना कि Claude वर्कलोड कहां चलता है और संस्करण को पिन करना जो शिप होता है एक पैकेज की गई संपत्ति और एक योगदान की गई एक दोनों केवल कोड हैं जब तक कुछ उन्हें नहीं चलाता। संपत्ति अब एक अलग सवाल का सामना करती है: यह कहां चलता है और इसके संस्करण को कैसे लॉक करें, ताकि एक अपस्ट्रीम परिवर्तन प्रोडक्शन में एक अनुरेखित परिवर्तन न बन जाए। वह प्लेटफॉर्म निर्णय शायद ही कभी तकनीकी योग्यता के बारे में अकेले होता है। व्यवहार में, यह आमतौर पर जहां ग्राहक के पास पहले से क्लाउड बुनियादी ढांचा, पहचान प्रबंधन, और अनुपालन समझौते हैं द्वारा आकार दिया जाता है। पहला सवाल आमतौर पर कौन सा प्लेटफॉर्म है जो ग्राहक पहले से विश्वास करता है और संचालित करता है। ग्राहक का क्लाउड आमतौर पर प्लेटफॉर्म निर्धारित करता है तैनाती प्लेटफॉर्म वह वातावरण है जहां Claude वर्कलोड चलता है। एक ही मॉडल कई तैनाती वातावरण में चल सकता है, और ग्राहक का मौजूदा क्लाउड आमतौर पर कौन सा निर्धारित करता है। पहली-पक्ष Claude API Anthropic का अपना वातावरण है और आमतौर पर नई विशेषताएं पहले प्राप्त करता है। AWS पर Claude प्लेटफॉर्म ग्राहक के AWS खाते के माध्यम से एक्सेस किया जाता है Anthropic के अपने मॉडल IDs और जीवनचक्र का उपयोग करके; अनुमान AWS सीमा के बाहर Anthropic-संचालित है। Amazon Bedrock दो एकीकरण प्रदान करता है: Amazon Bedrock में Claude /anthropic/v1/messages पर Messages API का उपयोग करता है व्यापक विशेषता समानता के साथ; Bedrock दस्तावेज़ के विरुद्ध किसी भी विशेषता-विशिष्ट आवश्यकताओं की पुष्टि करें, जैसा कि एक विशेषताएं-समर्थित नहीं सूची मौजूद है, जबकि Amazon Bedrock पर Claude (विरासत) InvokeModel/Converse APIs का उपयोग करता है ARN-संस्करण पहचानकर्ता के साथ। Google Vertex AI Google Cloud के अंदर एक ही करता है। तीसरे-पक्ष प्लेटफॉर्म, जैसे Microsoft Foundry, Claude को एक उत्पाद के अंदर एम्बेड करते हैं जो ग्राहक पहले से उपयोग करता है। Microsoft Foundry Claude को दो होस्टिंग रूपों में प्रदान करता है: Azure पर होस्ट किया गया (वर्तमान में Claude Opus 4. 8, Claude Sonnet 5, और Claude Haiku 4. 5, अनुमान Azure बुनियादी ढांचे पर अंत से अंत तक चल रहा है, आमतौर पर उपलब्ध) और Anthropic पर होस्ट किया गया (सभी अन्य Foundry Claude मॉडल, Anthropic-संचालित बुनियादी ढांचे पर अनुमान के साथ)। विनियमित ग्राहकों के लिए निवास धारणाएं विशिष्ट मॉडल के होस्टिंग रूप पर निर्भर करती हैं। बिल्ड समय पर Microsoft के साथ होस्टिंग रूप और वर्तमान मॉडल विभाजन की पुष्टि करें। पहचान और डेटा निवास सुरक्षा के लिए महत्वपूर्ण हैं पहचान और डेटा स्थान आपके कोड द्वारा नहीं, प्लेटफॉर्म द्वारा उत्तर दिए जाते हैं। Bedrock AWS पहचान का उपयोग करता है और डेटा को ग्राहक के AWS सीमा के अंदर रखता है; Vertex Google Cloud पहचान और सीमा का उपयोग करता है। दोनों निवास एक बाधा होने पर क्षेत्रीय रूटिंग प्रदान करते हैं। प्लेटफॉर्म को ग्राहक के मौजूदा अनुपालन समझौते से मेल खाना शुरुआत से एक डेटा-निवास समीक्षा से बचाता है। संस्करण को पिन करें ताकि एक अपस्ट्रीम मॉडल परिवर्तन एक मूक प्रोडक्शन परिवर्तन न हो संस्करण वह है जो एक मॉडल या प्रॉम्प्ट परिवर्तन को प्रोडक्शन में एक मूक परिवर्तन बनने से रोकता है। हर Claude मॉडल ID एक विशिष्ट मॉडल स्नैपशॉट की ओर इशारा करता है। Opus और Sonnet जैसे उपनाम सुविधाजनक हैं, लेकिन वे समय के साथ विकसित होते हैं और तैनाती प्लेटफॉर्म में विभिन्न संस्करणों को हल कर सकते हैं। एक पिन किया गया पूर्ण मॉडल ID एक निश्चित स्नैपशॉट को हल करता है। उपनाम के बजाय विशिष्ट मॉडल संस्करण को पिन करें, ताकि एक अपस्ट्रीम मॉडल अपडेट एक जानबूझकर पसंद हो बजाय एक मूक प्रोडक्शन परिवर्तन के। फिर प्रॉम्प्ट और संपत्ति को कोड के साथ संस्करण करें। अंत में, पूर्व संस्करण को उपलब्ध रखें ताकि प्रतिगमन को वापस किया जा सके। एक अनपिन किया गया तैनाती हर अपस्ट्रीम मॉडल अपडेट को एक अनुरेखित प्रोडक्शन परिवर्तन बनाता है। पहली पंक्ति एक चलती उपनाम का अनुसरण करती है। दूसरी स्नैपशॉट को पिन करती है।

model = "claude-haiku-4-5"

model = "claude-haiku-4-5-20251001" Claude 4. 6 और बाद के लिए, मॉडल ID अकेले एक विशिष्ट स्नैपशॉट को पिन करता है; पहले के मॉडल के लिए, ID प्लस एक तारीख प्रत्यय आवश्यक है। बिल्ड समय पर platform. claude. com पर वर्तमान सम्मेलन सत्यापित करें। eval के माध्यम से एक संस्करण को प्रचार करें प्रचार को eval सूट पर गेट करें। ट्रैफिक के एक हिस्से को एक नया संस्करण भेजें, पिन किए गए बेसलाइन के विरुद्ध तुलना करें, और परिणाम पर प्रचार या वापस करें। यह है जहां eval एक बार की परीक्षा बनना बंद करता है और तैनाती गेट बन जाता है। तैनाती-प्लेटफॉर्म निर्णय तालिका

प्लेटफॉर्मपहचान और डेटा मॉडलइसे कब चुनेंसंस्करण कैसे पिन किया जाता है पहली-पक्ष Claude APIAnthropicपहचान और शर्तें।ग्राहक के पास कोई बाध्यकारी क्लाउड या निवास बाधा नहीं है और नई क्षमताएं चाहता है।पूर्ण मॉडल ID को पिन करें और पूर्व स्नैपशॉट रखें। AWS पर Claude प्लेटफॉर्मAnthropicपहचान और शर्तें, ग्राहक के AWS खाते के माध्यम से एक्सेस किया गया; अनुमान AWS सीमा के बाहर Anthropic-संचालित है। मॉडल जीवनचक्र Anthropic के मूल्यह्रास अनुसूची का अनुसरण करता है।ग्राहक AWS पर है लेकिन Anthropic मॉडल IDs, जीवनचक्र, और पहली-पक्ष API के साथ विशेषता समानता चाहता है।Claude API के समान मॉडल ID प्रारूप का उपयोग करके पिन करें (उदाहरण के लिए, claude-opus-4-8)। जीवनचक्र Anthropic की अनुसूची का अनुसरण करता है। (प्रकाशन समय पर पुष्टि करें।) Amazon Bedrock में Claude/anthropic/v1/messages पर Messages API, पहली-पक्ष API के साथ व्यापक विशेषता समानता; Bedrock दस्तावेज़ के विरुद्ध विशेषता-विशिष्ट आवश्यकताओं की पुष्टि करें। डेटा ग्राहक के कॉन्फ़िगर किए गए AWS सीमा के अंदर रहता है।ग्राहक AWS पर है, पहली-पक्ष API के साथ व्यापक विशेषता समानता चाहता है (विशेषता-विशिष्ट आवश्यकताओं की पुष्टि करें), और वहां एक अनुपालन मुद्रा रखता है।anthropic. प्रत्यय प्रारूप का उपयोग करके पूर्ण मॉडल ID को पिन करें। भागीदार सेवानिवृत्ति तारीखें Anthropic की अनुसूची से भिन्न होती हैं। प्रकाशन समय पर पुष्टि करें। Amazon Bedrock पर Claude (विरासत)AWS पहचान और बिलिंग, InvokeModel/Converse APIs ARN-संस्करण मॉडल पहचानकर्ता के साथ।ग्राहक एक मौजूदा Bedrock एकीकरण पर है InvokeModel या Converse का उपयोग करके और Messages API में माइग्रेट नहीं हुआ है।Bedrock के संस्करण नियंत्रण के अनुसार ARN-संस्करण मॉडल पहचानकर्ता के माध्यम से पिन करें। Google Vertex AIGoogle Cloud पहचान, Identity and Access Management (IAM), और बिलिंग, निवास के लिए क्षेत्रीय या वैश्विक अंतिम बिंदु के साथ।ग्राहक Google Cloud पर है और वहां एक अनुपालन मुद्रा रखता है।रोलआउट से पहले Vertex के मॉडल ID प्रारूप का उपयोग करके पूर्ण मॉडल ID को पिन करें। भागीदार सेवानिवृत्ति तारीखें Anthropic की अनुसूची से भिन्न होती हैं। तीसरे-पक्ष प्लेटफॉर्मलपेटने वाले उत्पाद की पहचान और बिलिंग मॉडल। नोट: Claude in Microsoft Foundry दो होस्टिंग रूपों में Claude प्रदान करता है: Azure पर होस्ट किया गया (वर्तमान में Opus 4. 8, Sonnet 5, और Haiku 4. 5; अनुमान अंत से अंत तक Azure पर) और Anthropic पर होस्ट किया गया (सभी अन्य Foundry Claude मॉडल)। इस पथ को एक विनियमित ग्राहक के लिए चुनने से पहले Microsoft के साथ निवास और अनुपालन शर्तों की पुष्टि करें।ग्राहक पहले से प्लेटफॉर्म चलाता है जो Claude को एम्बेड करता है।प्लेटफॉर्म के संस्करण नियंत्रण के अनुसार पिन करें।

अच्छी तरह से संभालता है प्लेटफॉर्म को ग्राहक क्लाउड से मेल खाना और संस्करण को पिन करना एक माइग्रेशन को समीक्षा योग्य रखता है और एक रोलबैक संभव बनाता है।

लागत या जटिलता जोड़ता है पिन करना, पूर्व संस्करण रखना, और eval पर प्रचार को गेट करना हर तैनाती के लिए रिलीज-प्रक्रिया ओवरहेड जोड़ता है।

एक अलग दृष्टिकोण का उपयोग करें एक फेंकने योग्य प्रोटोटाइप के लिए जो कभी प्रोडक्शन को नहीं छूता, एक चलती उपनाम ठीक है: पिन करना जो शिप होता है के लिए है।

स्क्रीन 13: तैनाती जो टूट गई जब मॉडल उपनाम चला गया

सावधानी रखेंतैनाती और संस्करण·3 मिनट तैनाती जो टूट गई जब मॉडल उपनाम चला गया

सेटअप आपने अनुशंसित संस्करण की ओर इशारा करने वाले उपनाम के विरुद्ध शिप किया, क्योंकि यह सुविधाजनक डिफ़ॉल्ट था और यह आपको मुफ्त में नवीनतम मॉडल दिया। यह काम करता था। फिर उपनाम आगे बढ़ गया, और जो मुफ्त था वह एक कीमत निकला।

यह एक प्रोडक्शन लॉग से एक ट्रेस अंश है, जिस तरह का आप एक घटना के बाद वापस स्क्रॉल करेंगे। यह दिन दिखाता है जब आउटपुट आकार बदल गया और क्यों वापस करने के लिए कुछ नहीं था। लॉग --: deploy: model="opus" status=ok --: alias advanced -> new opus version (no app change) --: parser: KeyError "summary" in response payload --: Error: output shape changed; downstream parse failed --: rollback attempted -> no pinned prior version retained --: incident: hotfix parser; root cause = unpinned deployment

क्यों यह टूट गया एप्लिकेशन कभी नहीं बदला, लेकिन उपनाम ने किया। कोई पिन किया गया पूर्व संस्करण नहीं रखा गया था, इसलिए वापस करने के लिए कुछ नहीं था। hotfix ने पार्सर की मरम्मत की लेकिन अनपिन किया गया तैनाती जगह में छोड़ दिया।

क्या सावधानी रखें एक उपनाम एक चलती लक्ष्य को हल करता है; एक पिन किया गया पूर्ण मॉडल ID एक निश्चित स्नैपशॉट है। पूर्ण मॉडल ID को पिन करें ताकि एक अपस्ट्रीम अपडेट कुछ आप जानबूझकर अपनाते हैं। पिन किए गए पूर्व संस्करण को उपलब्ध रखें ताकि एक प्रतिगमन एक hotfix के बजाय एक रोलबैक हो। नए संस्करण को eval के माध्यम से प्रचार करने से पहले गेट करें, ताकि आउटपुट-आकार परिवर्तन प्रोडक्शन में बजाय एक परीक्षण रन में दिखाई दे।

स्क्रीन 14: चेकपॉइंट 5: तैनाती प्लेटफॉर्म और संस्करण पिन को प्रत्येक परिदृश्य से मेल खाएं

चेकपॉइंटतैनाती प्लेटफॉर्म और संस्करण·4 मिनट चेकपॉइंट 5: तैनाती प्लेटफॉर्म और संस्करण पिन को प्रत्येक परिदृश्य से मेल खाएं अभी कोशिश करें। एक ग्राहक AWS चलाता है एक डेटा-निवास आवश्यकता के साथ और एक मॉडल अपडेट को वापस करने में सक्षम होने की जरूरत है। नीचे प्रत्येक समूह में एक सही टुकड़ा चुनें न्यूनतम तैनाती कॉन्फ़िगरेशन को इकट्ठा करने के लिए जो दोनों को संतुष्ट करता है। जो संबंधित नहीं है उसे छोड़ दें। प्लेटफॉर्म समूहपहली-पक्ष APIAmazon BedrockGoogle Vertex AIपहचान समूहAWS पहचान संदर्भAnthropicAPI कीमॉडल संदर्भ समूहएक पिन किया गया पूर्ण मॉडल IDAएक चलती उपनामरोलबैक समूहपूर्व पिन किए गए संस्करण को रखेंकोई प्रतिधारण

जमा करें अभी के लिए छोड़ें

स्क्रीन 15: विलंबता, अनुपालन, और लागत पर प्लेटफॉर्म की तुलना करना ताकि पसंद समीक्षा से बचे

शिक्षणप्लेटफॉर्म की तुलना·12 मिनट विलंबता, अनुपालन, और लागत पर प्लेटफॉर्म की तुलना करना ताकि पसंद समीक्षा से बचे पिछली दो स्क्रीन में आपने एक प्लेटफॉर्म चुना और इसके संस्करण को पिन किया। वह पसंद ग्राहक के क्लाउड के लिए सही था, लेकिन "उनके क्लाउड के लिए सही" अभी तक एक तर्क नहीं है जो एक प्रोक्योरमेंट और सुरक्षा टीम साइन ऑफ करेगी। ग्राहक के क्षेत्र से विलंबता को मापें विलंबता प्लेटफॉर्म पर निर्भर करता है जहां यह ग्राहक के सापेक्ष चलता है और कैसे नई विशेषताओं तक पहुंच रूट की जाती है। एक प्लेटफॉर्म ग्राहक के अपने क्लाउड क्षेत्र में चल रहा है एक पहली-पक्ष अंतिम बिंदु की तुलना में दूर स्थित राउंड-ट्रिप समय को कम कर सकता है। ट्रेड-ऑफ समय है: पहली-पक्ष API आमतौर पर अन्य प्लेटफॉर्म तक पहुंचने से पहले नई क्षमताएं प्राप्त करता है। संख्या केवल सटीक है जब आप इसे ग्राहक के वास्तविक क्षेत्र से ग्राहक के वास्तविक पेलोड के विरुद्ध मापते हैं। आपके लैपटॉप से एक माप राउंड-ट्रिप दंड को छुपाता है जो एक बार वर्कलोड जहां ग्राहक है वहां चलता है। संख्या केवल सटीक है जब आप इसे ग्राहक के वास्तविक क्षेत्र से ग्राहक के वास्तविक पेलोड के विरुद्ध मापते हैं। Bedrock के भीतर विशेष रूप से, वैश्विक और क्षेत्रीय अंतिम बिंदु के बीच पसंद भी प्राथमिक निवास नियंत्रण है और लागत को प्रभावित कर सकता है। प्रतिबद्ध करने से पहले ग्राहक के वास्तविक क्षेत्र से दोनों विकल्पों के विरुद्ध विलंबता को मापें। अनुपालन अक्सर प्लेटफॉर्म निर्धारित करता है अनुपालन अक्सर वह आयाम है जो बहस को समाप्त करता है। एक ग्राहक जो पहले से एक क्लाउड पर एक प्रमाणपत्र रखता है दूसरे पर फिर से प्रमाणित होने की संभावना नहीं है। डेटा निवास एक नियम है कि ग्राहक का डेटा एक विशिष्ट देश या क्षेत्र में संसाधित किया जाना चाहिए। उपलब्ध अनुपालन प्रमाणपत्र और कौन पहुंच को ऑडिट कर सकता है प्लेटफॉर्म द्वारा भिन्न होता है, और एक विनियमित वित्तीय या स्वास्थ्यसेवा ग्राहक इन्हें पास-या-विफल के रूप में मानता है बजाय संतुलन के लिए ट्रेड-ऑफ के रूप में। पहली-पक्ष Claude API EU डेटा निवास प्रदान नहीं कर सकता है; platform. claude. com पर वर्तमान क्षेत्रीय कवरेज की पुष्टि करें, क्योंकि EU-केवल निवास आमतौर पर Bedrock या Vertex AI की आवश्यकता होती है; तीसरे-पक्ष प्लेटफॉर्म जैसे Microsoft Foundry पर, होस्टिंग प्रति-मॉडल है: Azure-होस्ट किए गए Foundry मॉडल अनुमान अंत से अंत तक Azure बुनियादी ढांचे पर चलाते हैं, जबकि Anthropic-होस्ट किए गए Foundry मॉडल EU क्षेत्रीय निवास आवश्यकताओं को संतुष्ट नहीं करते हैं। निवास को Microsoft के साथ प्रति मॉडल और तैनाती के साथ पुष्टि किया जाना चाहिए। स्कोपिंग के दौरान अनुपालन बाधा को उठाएं, या यह काम पूरा होने के बाद अनुबंध समीक्षा पर सतह करता है। कुल लागत को प्रति-token दर से परे क्या चलाता है प्रति-token दरें व्यापक रूप से प्लेटफॉर्म में संरेखित होती हैं; कुल लागत निकास, प्लेटफॉर्म शुल्क, और एकीकरण प्रयास पर चलती है। एक कम token कीमत कुल में अधिक लागत कर सकता है एक बार डेटा स्थानांतरण और एकीकरण को ध्यान में रखा जाता है। प्रत्येक प्लेटफॉर्म के लिए प्रति कॉल लागत को साधन करें। स्कोपिंग पर वर्तमान मूल्य निर्धारण पृष्ठों की पुष्टि करें। क्रॉस-प्लेटफॉर्म तुलना संदर्भ

आयामयह प्लेटफॉर्म द्वारा कैसे भिन्न होता हैइसे कैसे मापें जहां प्रत्येक प्लेटफॉर्म जीतता है विलंबताएक प्लेटफॉर्म ग्राहक के क्षेत्र में राउंड ट्रिप को छोटा करता है, जबकि पहली-पक्ष API नई विशेषताओं तक पहुंचने में पहले हो सकता है।ग्राहक के वास्तविक क्षेत्र से उनके वास्तविक पेलोड के विरुद्ध।एक क्षेत्र-क्लाउड प्लेटफॉर्म राउंड-ट्रिप विलंबता पर जीतता है, जबकि पहली-पक्ष API सबसे पहली विशेषता पहुंच पर लाभ है। अनुपालनडेटा निवास, प्रमाणपत्र, और ऑडिट नियंत्रण तैनाती प्लेटफॉर्म द्वारा निर्धारित किए जाते हैं।ग्राहक के मौजूदा प्रमाणपत्र और निवास आवश्यकताओं के विरुद्ध स्कोपिंग के दौरान।ग्राहक पहले से प्रमाणित क्लाउड प्लेटफॉर्म जीतता है, क्योंकि इसे फिर से प्रमाणित करने की जरूरत नहीं है। लागतToken कीमत, डेटा निकास, प्लेटफॉर्म शुल्क, और एकीकरण प्रयास सभी भिन्न होते हैं।प्रति कॉल कुल लागत प्रति प्लेटफॉर्म, निकास और एकीकरण सहित, token कीमत अकेले के बजाय।वास्तविक वर्कलोड के लिए सबसे कम कुल लागत वाला प्लेटफॉर्म जीतता है, जो हमेशा सबसे सस्ता token नहीं है।

अच्छी तरह से संभालता है सभी तीन आयामों को प्रति प्लेटफॉर्म मापना एक प्लेसमेंट को एक ऐसा बनाता है जो एक प्रोक्योरमेंट टीम साइन ऑफ करेगी।

लागत या जटिलता जोड़ता है प्लेटफॉर्म में विलंबता, अनुपालन, और लागत को साधन करना किसी भी कोड शिप से पहले वास्तविक माप काम की आवश्यकता होती है।

एक अलग दृष्टिकोण का उपयोग करें जब ग्राहक की अनुपालन आवश्यकता पहले से ही पास-या-विफल है, पूर्ण तुलना को छोड़ दें। वह बाधा अकेले प्लेसमेंट निर्धारित करता है।

स्क्रीन 16: प्लेटफॉर्म परिचितता पर चुना गया जो निवास विफल हुआ

सावधानी रखेंप्लेटफॉर्म की तुलना·2 मिनट प्लेटफॉर्म परिचितता पर चुना गया जो निवास विफल हुआ

सेटअप आपने प्लेटफॉर्म चुना जो आपकी टीम पहले से शिप कर चुकी थी, क्योंकि माइग्रेशन आसान दिख रहा था और समय सीमा तेजी से आ रही थी। यह बिल्कुल ठीक बनाया; परेशानी यह थी कि बनाने में आसान और शिप करने की अनुमति अलग मानदंड हैं।

निम्नलिखित anecdote वह तरह है जो एक डेवलपर एक सहकर्मी को बताता है एक समीक्षा गलत हो जाने के बाद। यह आपको परिचित प्लेटफॉर्म जाल को देखने देता है इससे पहले कि कोई इसे एक गलती कहे। क्या हुआ एक विनियमित ग्राहक के लिए बनाने वाले डेवलपर ने प्लेटफॉर्म चुना जो टीम पहले से शिप कर चुकी थी। एकीकरण एक साथ आया क्योंकि टीम उपकरण और संसाधनों को जानती थी। बिल्ड ने अपने कार्यात्मक परीक्षण पास किए। ग्राहक की सुरक्षा समीक्षा पर, समीक्षक ने पूछा कि डेटा कहां संसाधित किया जा रहा था। चुना गया प्लेटफॉर्म ग्राहक की निवास आवश्यकताओं को संतुष्ट नहीं करता था। एक अलग प्लेटफॉर्म, जो टीम कम जानती थी, क्षेत्रीय तैनाती विकल्पों के माध्यम से आवश्यकता को संतुष्ट करता था जो ग्राहक पहले से साफ कर चुका था। प्लेसमेंट को अस्वीकार कर दिया गया, और एकीकरण को निवास बाधा को पूरा करने वाले प्लेटफॉर्म पर फिर से बनाया जाना था।

क्यों यह टूट गया परिचितता गलत परीक्षा के लिए अनुकूलित। आसान माइग्रेशन ने उत्तर दिया कि क्या टीम तेजी से बना सकती है। यह कभी उत्तर नहीं दिया कि क्या तैनाती ग्राहक की निवास समीक्षा पास करेगी, जो वह परीक्षा थी जो यह निर्धारित करती है कि क्या यह शिप कर सकता है। क्योंकि अनुपालन आवश्यकता स्कोपिंग के दौरान पूरी नहीं की गई थी, यह जाओ-नहीं-जाओ समीक्षा पर आई। यह सबसे महंगी जगह है इसे खोजने के लिए, क्योंकि बिल्ड पहले से ही पूरी थी।

क्या सावधानी रखें एक प्लेटफॉर्म जो आपकी टीम के लिए बनाने में आसान है वह जरूरी नहीं है कि एक प्लेटफॉर्म ग्राहक को चलाने की अनुमति है। जब ग्राहक विनियमित है, निवास और अनुपालन बाधा अक्सर पास-या-विफल होती है, बजाय संतुलन के लिए ट्रेड-ऑफ के। स्कोपिंग के दौरान उन्हें पहचानें और परिचितता करने से पहले प्लेसमेंट को प्रभावित करने दें। जल्दी जांच करना एक स्कोपिंग बातचीत की लागत है, जबकि देर से जांच करना एक पूरी पुनर्निर्माण की लागत है।

स्क्रीन 17: चेकपॉइंट 6: एक तुलना ट्रेस से प्लेटफॉर्म बेमेल का निदान करें

चेकपॉइंटविलंबता, अनुपालन, और लागत पर प्लेटफॉर्म की तुलना·3 मिनट चेकपॉइंट 6: एक तुलना ट्रेस से प्लेटफॉर्म बेमेल का निदान करें अभी कोशिश करें। नीचे तुलना ट्रेस एक तैनाती प्लेटफॉर्म दिखाता है परिचितता पर चुना गया एक ग्राहक आवश्यकता विफल। तंत्र की पहचान करें, फिर तीन विकल्पों से लक्षित फिक्स चुनें। ट्रेस platform_selected = "team_default" # chosen on familiarity latency_test: measured from dev laptop -> 180ms (looked fine) customer_region: eu-west, payload 12 KB compliance_check: data residency = EU-only required result: REJECTED reason="data processed outside EU on selected platform" Aविकल्प 1: लैपटॉप पर मापी गई 180ms विलंबता को कम करने के लिए पार्सर को अनुकूलित करें।Bविकल्प 2: EU-west से विलंबता को फिर से मापें और प्लेटफॉर्म चुनें जिसका क्षेत्र EU-केवल निवास को संतुष्ट करता है।Cविकल्प 3: चुने गए प्लेटफॉर्म पर प्रति कॉल लागत को कम करने के लिए एक कैशिंग परत जोड़ें।

जमा करें अभी के लिए छोड़ें

स्क्रीन 18: कई Claude डिप्लॉयमेंट को समन्वय करना विश्वास सीमाओं के साथ समीक्षा के तहत रखना

शिक्षणविश्वास सीमाएं·14 मिनट कई Claude डिप्लॉयमेंट को समन्वय करना विश्वास सीमाओं के साथ समीक्षा के तहत रखना एक्सेलेरेटर, डिप्लॉयमेंट, और ट्रेड-ऑफ अब एक एकल एप्लिकेशन में एक साथ आते हैं। घटकों को जोड़ना उन जगहों को गुणा करता है जहां पहचान, रहस्य, और अविश्वसनीय इनपुट पार कर सकते हैं। अनुशासन हर सीमा की पहचान करना है इससे पहले कि कुछ भी जुड़ा हो। कनेक्ट करने से पहले मानचित्र करें कि कौन सा घटक क्या करता है एक बहु-घटक ऐप एक एकल वर्कफ़्लो में एक से अधिक Claude क्षमता को समन्वय करता है। एक API अनुरोध Claude Code कार्य को ट्रिगर कर सकता है, जो तब एक MCP सर्वर के माध्यम से एक ग्राहक सिस्टम तक पहुंचता है। प्रत्येक घटक एक क्षमता में योगदान देता है जो अन्य के पास नहीं है। चुनौती यह है कि उनके बीच हर कनेक्शन एक जगह बनाता है जहां पहचान, रहस्य, और अविश्वसनीय इनपुट पार कर सकते हैं। कुछ भी जोड़ने से पहले मानचित्र करें कि कौन सा घटक क्या करता है। विश्वास सीमा वह जगह है जहां डेटा चलता है विश्वास सीमा वह बिंदु है जहां डेटा या निर्देश एक तैनाती वातावरण से दूसरे में चलते हैं। यह बिल्कुल जहां इंजेक्शन है और पिछले मॉड्यूल से नियंत्रण लागू होते हैं। Claude Code कार्य द्वारा लाया गया सामग्री अविश्वसनीय है जब यह अगले घटक तक पहुंचता है। प्राप्त करने वाला घटक इसे डेटा के रूप में मानना चाहिए, बजाय निर्देशों के, सुरक्षा मॉड्यूल में उपयोग किए गए सिद्धांत का पालन करते हुए। मुख्य अनुशासन हर सीम को एक सीमा के रूप में पहचानना है। एक घटक को विश्वसनीय मत मानो केवल इसलिए कि यह अपने आप पर सही तरीके से काम करता था। कम से कम विशेषाधिकार पूरी एप्लिकेशन पर लागू होता है पहचान और कम से कम विशेषाधिकार, जिसका अर्थ है प्रत्येक घटक को केवल वह पहुंच देना जो इसके कार्य की जरूरत है और कुछ नहीं, पूरी एप्लिकेशन पर लागू होता है। प्रत्येक घटक एक पहचान के तहत संचालित होता है। एप्लिकेशन केवल इसके सबसे विशेषाधिकार प्राप्त सीम के रूप में निहित है, जिसका अर्थ है कि एक घटक बहुत व्यापक दायरे में एक कमजोर बिंदु बन जाता है यहां तक कि जब हर दूसरा घटक ठीक से दायरे में हो। आप प्रत्येक घटक को कम से कम विशेषाधिकार के लिए दायरे में करते हैं जो वर्कफ़्लो में इसकी भूमिका की आवश्यकता होती है। यह वह है जो एक निर्देशित घटक को अपने इच्छित कार्य से परे पहुंचने से रोकता है। एक विनियमित समीक्षा के लिए दायरे में रखना मॉड्यूल को एक साथ खींचता है एक विनियमित समीक्षा पूरी एप्लिकेशन में ऑडिट लॉगिंग, डेटा-निवास निर्णय, और अनुमति नियंत्रण को न्यायसंगत बनाने की आवश्यकता होती है। विनियमित डिप्लॉयमेंट के लिए, Bedrock और Vertex AI आमतौर पर प्लेटफॉर्म हैं जो क्षेत्रीय निवास बाधाओं को संतुष्ट करते हैं। Anthropic Trust Center और platform. claude. com के विरुद्ध प्रत्येक घटक के लिए ZDR और HIPAA BAA पात्रता की पुष्टि करें दायरे में रखने से पहले। बहु-घटक एकीकरण मानचित्र

घटकयह क्या योगदान देता हैइसके सीम पर विश्वास सीमायह नियंत्रण को लागू करता है पहली-पक्ष APIवर्कफ़्लो को ऑर्केस्ट्रेट करता है और प्रवेश बिंदु रखता है।बाहर से ऐप में प्रवेश करने वाला अनुरोध।इनपुट सत्यापन और पहचान कॉल चलाता है। Claude Code कार्यagentic काम चलाता है और बाहरी सामग्री लाया जा सकता है।सामग्री जो यह लाया, जो अविश्वसनीय है अगले में।अगले सीम पर लाया गया सामग्री को डेटा के रूप में मानें। MCP सर्वरएक ग्राहक सिस्टम तक पहुंचता है पढ़ने या कार्य करने के लिए।सिस्टम पहुंच यह ऐप की ओर से रखता है।सर्वर को कम से कम विशेषाधिकार के लिए दायरे में करें और पहुंच को लॉग करें।

अच्छी तरह से संभालता है हर सीम को एक सीमा के रूप में नाम देना और प्रत्येक घटक को कम से कम विशेषाधिकार के लिए दायरे में करना एक बहु-घटक ऐप को समीक्षा के तहत तैनाती योग्य बनाता है।

लागत या जटिलता जोड़ता है सीम को मैप करना, प्रत्येक पर नियंत्रण को लागू करना, और सीमा पार को लॉग करना हर एकीकरण में डिजाइन और ऑडिट काम जोड़ता है।

एक अलग दृष्टिकोण का उपयोग करें जब एक सीम को सुरक्षित नहीं किया जा सकता, तो इसे शिप न करें: एक मानव मालिक को बढ़ाएं।

स्क्रीन 19: वह सीम जिसे कोई सीमा के रूप में चिह्नित नहीं किया

सावधानी रखेंविश्वास सीमाएं·2 मिनट वह सीम जिसे कोई सीमा के रूप में चिह्नित नहीं किया

सेटअप आपने घटकों को जोड़ा जो प्रत्येक अपने परीक्षण पास किए। भाग पहले से ही जांचे गए थे और सत्यापित भागों को जोड़ना सुरक्षित महसूस होता है। प्रत्येक को अलगाव में विश्वास किया गया था। अंतर यह था कि दो विश्वसनीय भागों के बीच एक सीम को स्वचालित रूप से विश्वसनीय नहीं किया जा सकता।

यह एक जोड़ी सत्र से एक छोटा प्रतिलेख है, जिस तरह की बातचीत उस क्षण पर समाप्त होती है जब अचिह्नित सीम की पहचान की जाती है। सत्र Dev A: सभी तीन घटक अपने परीक्षण पास करते हैं। मैंने बस उन्हें जोड़ा। Dev B: Claude Code कार्य जो लाया वह कहां भेजता है? Dev A: अगली कॉल के हिस्से के रूप में सीधे प्रॉम्प्ट में। यह केवल सामग्री है जो हमने ग्राहक पृष्ठ से खींची। Dev B: वह सामग्री अविश्वसनीय है। यदि यह निर्देश ले जाता है, तो अगला घटक उन्हें चलाता है, क्योंकि हम कभी उस सीम को सीमा के रूप में चिह्नित नहीं करते। Dev A: लेकिन प्रत्येक घटक अपने आप पर विश्वसनीय था। Dev B: सही है, और उनके बीच सीम नहीं था। यह वह है जिसे कोई सीमा के रूप में मानता है, इसलिए कोई नियंत्रण इसे जांचता है। एक घटक जो अपने परीक्षण पास करता है उसके पास सीम-स्तर के नियंत्रण नहीं होते हैं। हर बिंदु जहां डेटा तैनाती वातावरण के बीच पार करता है एक विश्वास सीमा की आवश्यकता होती है भले ही प्रत्येक घटक स्वतंत्र रूप से कैसे व्यवहार करता है।

क्यों यह टूट गया प्रत्येक घटक के अपने परीक्षण पास करना उनके बीच सीम के बारे में कुछ नहीं कहा। लाया गया सामग्री अविश्वसनीय थी जब यह Claude Code कार्य को छोड़ दिया। यह एक घटक से आया जो अलगाव में काम करता था और यह अगली कॉल में विश्वसनीय निर्देशों के रूप में पारित किया गया था। सीमा डेटा प्रवाह में मौजूद थी। यह केवल चिह्नित नहीं था, इसलिए कोई नियंत्रण इसे जांचता है। एक घटक जो अपने परीक्षण पास करता है उसके पास सीम-स्तर के नियंत्रण नहीं होते हैं। हर बिंदु जहां डेटा तैनाती वातावरण के बीच पार करता है एक विश्वास सीमा की आवश्यकता होती है भले ही प्रत्येक घटक स्वतंत्र रूप से कैसे व्यवहार करता है।

क्या सावधानी रखें एक घटक जो अलगाव में विश्वसनीय है वह इसे छोड़ने वाली सीम को स्वचालित रूप से विश्वसनीय नहीं बनाता। हर जगह डेटा या निर्देश एक तैनाती वातावरण से दूसरे में पार करते हैं एक सीमा के रूप में चिह्नित करें। एक नियंत्रण वहां रखें जो लाया गया सामग्री को डेटा के रूप में मानता है, निर्देशों के रूप में नहीं, बिल्कुल जैसे सुरक्षा काम सिखाया। सीम जिसे कोई पहचानता है वह है जहां एक निर्देशित कार्य पार करता है।

स्क्रीन 20: चेकपॉइंट 7: बहु-घटक सीमा कॉन्फ़िगरेशन को पूरा करें

चेकपॉइंटबहु-घटक ऐप और विश्वास सीमाएं·3 मिनट चेकपॉइंट 7: बहु-घटक सीमा कॉन्फ़िगरेशन को पूरा करें अभी कोशिश करें। नीचे बहु-घटक ऐप जुड़ा हुआ है, दो रिक्त स्थान के साथ छोड़ा गया है। अविश्वसनीय लाया गया सामग्री प्राप्त करने वाली सीम पर सही नियंत्रण को ड्रैग करें और सबसे विशेषाधिकार प्राप्त घटक पर सही पहचान दायरे को ड्रैग करें। आंशिक ऐप

fetched = code_task. run(fetch_url=customer_page)

next_call(input=drop here(fetched))

mcp_server = MCPServer( system=customer_db, scope=drop here, # BLANK 2: identity scope ) ड्रैग टोकन (साझा बैंक, दो विचलनकारी हैं) treat_as_dataleast_privilege_read_onlyrun_as_instructionsfull_access

जमा करें अभी के लिए छोड़ें

स्क्रीन 21: संचयी कार्य: सभी तीन खोजें, प्रत्येक की व्याख्या करें, सुधार लिखें

संचयीसभी विषय·6 मिनट संचयी कार्य: सभी तीन खोजें, प्रत्येक की व्याख्या करें, सुधार लिखें नीचे एक चलाने योग्य पैकेज किया गया एक्सेलेरेटर है प्लेटफॉर्म में तैनात। तीन रोपण किए गए दोष हैं: एक पैकेजिंग परत में, एक तैनाती-और-संस्करण परत में, और एक बहु-घटक सीमा परत में। आपका कार्य सभी तीन खोजना है। तैनाती जैसा शिप किया गया

def build_agent(): return Agent( model="opus", system_prompt=SYSTEM_PROMPT, repo_path="/home/acme/checkout", tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn)

fetched = code_task. run(fetch_url=customer_page) next_call(input=fetched) अगली स्क्रीन में अपने तीन सही किए गए लाइनों को ले जाएं, जहां आप तैनाती को इकट्ठा और सत्यापित करते हैं। अपने शब्दों में, सभी तीन दोषों की पहचान करें।

मॉडल उत्तर प्रकट करें अभी के लिए छोड़ें

स्क्रीन 22: संचयी कार्य: सही किए गए तैनाती को इकट्ठा और सत्यापित करें

संचयीसभी विषय·6 मिनट संचयी कार्य: सही किए गए तैनाती को इकट्ठा और सत्यापित करें आपने इस मॉड्यूल में तीन दोषों की पहचान की है। अब फिक्स को इकट्ठा करें: अपने शब्दों में, वर्णन करें कि प्रत्येक दोष क्या था, आपने क्या बदला, और क्यों सही किया गया संस्करण तैनाती योग्य है। फिर नीचे सही किए गए कोड की समीक्षा करें और पुष्टि करें कि आपका तर्क रखता है। जब आप तैयार हों, मॉडल उत्तर प्रकट करें।

मॉडल उत्तर प्रकट करें अभी के लिए छोड़ें

सही किया गया तैनाती def build_agent(repo_path): # parameterized for reuse return Agent( model="us. anthropic. claude-opus-4-8", # pinned full Bedrock model ID system_prompt=SYSTEM_PROMPT, repo_path=repo_path, # set per engagement tools=[read_file, run_linter], )

deploy(platform="amazon_bedrock", identity=aws_role_arn, retain_previous_pinned_version=True) # rollback target kept

fetched = code_task. run(fetch_url=customer_page) next_call(input=treat_as_data(fetched)) # untrusted -> data, not instructions

assert eval_suite. run(model="us. anthropic. claude-opus-4-8") >= baseline_score मॉडल उत्तर: पहला दोष एक हार्डकोड किया गया रिपॉजिटरी पथ था। इसे पैरामीटरयुक्त करना पुन: उपयोग को पुनः स्थापित करता है: एक नई एनगेजमेंट मान सेट करती है बजाय लूप को संपादित करने के। दूसरा दोष एक चलती मॉडल उपनाम था। पूर्ण Bedrock मॉडल ID को पिन करना (anthropic. प्रत्यय के साथ) एक प्रतिधारण किए गए पूर्व संस्करण के साथ नियंत्रित रोलआउट को पुनः स्थापित करता है और यदि नया संस्करण प्रतिगमन करता है तो एक रोलबैक लक्ष्य देता है। तीसरा दोष लाया गया सामग्री थी सीधे निर्देशों के रूप में पारित। इसे treat_as_data() में लपेटना विश्वास सीमा को बंद करता है: एक अविश्वसनीय स्रोत से सामग्री को डेटा के रूप में माना जाता है, कुछ नहीं जो एजेंट को कार्य करना चाहिए। eval assertion प्रचार को एक साबित बेसलाइन स्कोर पर गेट करता है इससे पहले कि संस्करण शिप हो।

सभी तीन दोष उतरे · पास मैंने एक या अधिक याद किए · पुनः कोशिश करें

स्क्रीन 23: मुख्य निष्कर्ष

पुनरावृत्तिसभी विषय·3 मिनट मुख्य निष्कर्ष

01 बिल्ड ताजा होने पर पैकेज करें।एक एक्सेलेरेटर पुन: प्रयोज्य तर्क रखता है, ग्राहक-विशिष्ट भागों को दस्तावेज़ित पैरामीटर के रूप में उजागर करता है, और eval और ऑडिट लॉग को संपत्ति के साथ बंडल करता है। सही पैकेजिंग एक संपत्ति का उत्पादन करता है टीम कॉन्फ़िगर करती है। जो ग्राहक-विशिष्ट है इसका ज्ञान उन लोगों के चले जाने के बाद पुनर्निर्माण करने के लिए सबसे महंगा है।

02 एक रखरखाव कर्ता स्वीकार करता है जो वे सत्यापित कर सकते हैं।एक संपत्ति को साझा बुनियादी ढांचे में स्थानांतरित करना इसके आकार के लिए बनाए गए चैनल से मेल खाना, फिर समीक्षा बार को साफ करना: केंद्रित कोड, एक चलाने योग्य उदाहरण, एक परीक्षण, और धारणाओं का बयान, लाइसेंसिंग अधिकार तकनीकी समीक्षा से पहले पुष्टि किए गए। एक योगदान जो एक समीक्षक सत्यापित नहीं कर सकता वह कतार के पीछे बैठता है। तैयारी एक निजी संपत्ति को साझा बुनियादी ढांचे में स्थानांतरित करता है जो अन्य बनाते हैं।

03 जो शिप होता है उसे पिन करें।तैनाती प्लेटफॉर्म को ग्राहक के क्लाउड और अनुपालन मुद्रा के आधार पर चुनें, फिर चलती उपनाम के बजाय विशिष्ट मॉडल संस्करण को पिन करें और पूर्व संस्करण को उपलब्ध रखें। एक उपनाम एक किताब के वर्तमान संस्करण के लिए पूछने जैसा है: सुविधाजनक, लेकिन पाठ बदल सकता है। पिन करना एक निश्चित संस्करण का हवाला देता है, इसलिए एक अपस्ट्रीम मॉडल परिवर्तन कुछ है जो आप जानबूझकर अपनाते हैं बजाय कुछ जो रातोंरात कोई रोलबैक पथ के साथ आता है।

04 वह आयाम मापें जो प्लेसमेंट तय करता है।एक प्लेटफॉर्म पसंद केवल तब रक्षणीय है जब विलंबता, अनुपालन, और लागत को मापा जाता है: ग्राहक के क्षेत्र से विलंबता, उनके मौजूदा प्रमाणपत्र के विरुद्ध अनुपालन, और कुल प्रति कॉल लागत token कीमत अकेले के बजाय। विनियमित ग्राहकों के लिए, अनुपालन आमतौर पर पास-या-विफल है। स्कोपिंग के दौरान अनुपालन को एक बाधा के रूप में उठाना इसे अनुबंध समीक्षा पर बाद में अस्वीकार करने से रोकता है।

05 हर सीम को एक सीमा के रूप में चिह्नित करें।एक बहु-घटक एप्लिकेशन केवल इसके सबसे विशेषाधिकार प्राप्त सीम के रूप में निहित है। प्रत्येक घटक को न्यूनतम पहुंच के लिए दायरे में करें जो इसकी भूमिका की आवश्यकता होती है और हर बिंदु को चिह्नित करें जहां डेटा एक सीमा पार करता है। लाया गया सामग्री को डेटा के रूप में माना जाता है, निर्देशों के रूप में नहीं। एक घटक सीमा पर विश्वास स्पष्ट रूप से स्थापित किया जाना चाहिए। यह उस घटक से नहीं ले जाता है जिसने डेटा भेजा। जब एक सीम को सुरक्षित नहीं किया जा सकता, तो यह एक मानव मालिक के पास जाता है बजाय शिप किया जाता है।

अगला क्या आता है आप अब एक कार्यशील बिल्ड को एक तैनाती योग्य, ऑडिट करने योग्य संपत्ति तक ले जा सकते हैं: इसे पैकेज करें, इसे योगदान दें, इसे रखें और संस्करण करें, उस प्लेसमेंट का बचाव करें, और सीमाओं को समीक्षा के तहत एक साथ रखें। यह इस व्यक्तित्व के लिए बिल्ड-से-तैनाती चाप को पूरा करता है: पिछले मॉड्यूल में प्रोडक्शन कोड लिखने से इस मॉड्यूल में एक विनियमित ग्राहक को ऑडिट और एक टीम को पुन: उपयोग कर सकते हैं।

Anthropic सार्वजनिक संदर्भ (समय-संवेदनशील)

IDस्रोतप्रकारके लिए उपयोग किया गया S1platform. claude. com (Amazon Bedrock में Claude, Vertex AI पर Claude)उत्पाद दस्तावेज़तैनाती प्लेटफॉर्म, पहचान और डेटा मॉडल, निवास रूटिंग, क्षेत्रीय और वैश्विक अंतिम बिंदु। S2platform. claude. com (मॉडल IDs और संस्करण, मॉडल मूल्यह्रास)उत्पाद दस्तावेज़पिन किए गए मॉडल IDs, उपनाम संकल्प, जीवनचक्र और सेवानिवृत्ति, भागीदार-सेट अनुसूची। S3anthropic. com और Anthropic GitHub संगठन (Cookbook)उत्पाद और रिपॉजिटरीयोगदान चैनल, Cookbook केंद्रित उदाहरणों के लिए एक घर, योगदान सम्मेलन। S4Claude API के साथ बिल्डिंग (Skilljar)पाठ्यक्रम स्रोतeval डेटासेट, ग्रेडर, और मूल्यांकन पाइपलाइन तैनाती गेट के रूप में उपयोग की जाती है। S5Claude Code 101 In Action (Skilljar)पाठ्यक्रम स्रोतClaude Code agentic कार्य और बहु-घटक वर्कफ़्लो में MCP सर्वर भूमिकाएं।

आप अब एक कार्यशील बिल्ड को एक तैनाती योग्य, ऑडिट करने योग्य संपत्ति तक ले जा सकते हैं। इसे पैकेज करें, इसे योगदान दें, इसे रखें और संस्करण करें, उस प्लेसमेंट का बचाव करें, और सीमाओं को समीक्षा के तहत एक साथ रखें।

स्क्रीन 24: इस मॉड्यूल से मुख्य शर्तें

शब्दकोषमुख्य शर्तें·3 मिनट इस मॉड्यूल से मुख्य शर्तें वर्णक्रमानुक्रम। एक शब्द पर क्लिक करें इसकी परिभाषा को विस्तारित करने के लिए।

एक्सेलेरेटरएक कार्यशील समाधान पैकेज किया गया ताकि अगली एनगेजमेंट इसे फिर से बनाने के बजाय कॉन्फ़िगर करे। ग्राहक-विशिष्ट भाग दस्तावेज़ित पैरामीटर के रूप में उजागर किए जाते हैं, धारणाएं लिखी जाती हैं, और एक eval को साबित करने के लिए बंडल किया जाता है कि संपत्ति अभी भी एक नए संदर्भ में काम करती है। योगदान तैयारीजो एक रखरखाव कर्ता को एक योगदान सत्यापित करने की जरूरत है: केंद्रित कोड, एक चलाने योग्य उदाहरण, एक परीक्षण जो व्यवहार साबित करता है, एक पर्यावरण धारणाओं का बयान, और योगदान देने के लिए पुष्टि किए गए अधिकार। तैनाती प्लेटफॉर्मजहां एक Claude वर्कलोड चलता है। छह हैं: पहली-पक्ष Claude API, AWS पर Claude प्लेटफॉर्म, Amazon Bedrock में Claude, Amazon Bedrock पर Claude (विरासत), Google Vertex AI, और तीसरे-पक्ष प्लेटफॉर्म। एक ही मॉडल प्लेटफॉर्म द्वारा पहचान, डेटा निवास, विलंबता, और लागत पर भिन्न हो सकता है। मॉडल उपनाम बनाम पिन किया गया IDएक उपनाम जैसे opus या sonnet एक अनुशंसित संस्करण को हल करता है जो समय के साथ अपडेट होता है और तैनाती प्लेटफॉर्म में भिन्न हो सकता है। एक पिन किया गया पूर्ण मॉडल ID एक निश्चित स्नैपशॉट है। पिन करना वह है जो एक अपस्ट्रीम मॉडल परिवर्तन को प्रोडक्शन में एक मूक परिवर्तन बनने से रोकता है। विश्वास सीमाएक सीम जहां डेटा या निर्देश एक बहु-घटक ऐप में एक तैनाती वातावरण से दूसरे में चलते हैं। एक घटक द्वारा लाया गया सामग्री अविश्वसनीय है जब यह अगले तक पहुंचता है, इसलिए प्राप्त करने वाला घटक इसे डेटा के रूप में मानता है, निर्देशों के रूप में नहीं।

स्क्रीन 25: बधाई! आपने इस मॉड्यूल को सफलतापूर्वक पूरा किया।

मॉड्यूल पूर्णडेवलपर पथ·2 मिनट बधाई! आपने इस मॉड्यूल को सफलतापूर्वक पूरा किया। आप अब एक कार्यशील बिल्ड को एक तैनाती योग्य, ऑडिट करने योग्य संपत्ति तक ले जा सकते हैं: एक पुन: प्रयोज्य एक्सेलेरेटर, एक योगदान जो एक रखरखाव कर्ता सत्यापित कर सकता है, एक तैनाती प्लेटफॉर्म जानबूझकर चुना गया और संस्करण किया गया, और एक बहु-घटक ऐप में हर सीम एक विश्वास सीमा के रूप में चिह्नित। throughline: वह बिंदु जहां कोड काम करना शुरू करता है वह है जहां इस मॉड्यूल का काम शुरू होता है।

4 9 चेकपॉइंट में से पास किए गए

M1

MSO नींव Tokens, context windows, sampling, model tiers, prompting modes, और API transport mechanics।

M2

प्रोडक्शन-ग्रेड प्रॉम्प्टिंग, एजेंट और टूल-उपयोग प्रोडक्शन-तैयार प्रॉम्प्ट, टूल-उपयोग लूप, streaming, context और memory management, और checkpointed agent loops।

M3

Claude Code, MCP और एकीकरण अनुमति मोड, टिकाऊ प्रोजेक्ट संदर्भ, प्लगइन पैकेजिंग, और MCP एकीकरण बिना क्रेडेंशियल लीक किए।

M4

प्रोडक्शन इंजीनियरिंग, Evals, और सुरक्षा प्रोडक्शन ट्रैफिक के तहत सिस्टम को साबित करें और एक सुरक्षा समीक्षा से बचें।

M5

एक्सेलेरेटर और आईपी योगदान एक्सेलेरेटर पैकेज करें, सत्यापित योगदान तैयार करें, तैनाती प्लेटफॉर्म चुनें, और विश्वास सीमाओं को चिह्नित करें।

आप यहां हैं

मॉड्यूल की समीक्षा करें शुरुआत से शुरू करें

मॉड्यूल पूर्णता दर्ज की गई।