कॉन्फ़िगरेशन और नॉलेज मैनेजमेंट

स्क्रीन 1: कॉन्फ़िगरेशन और नॉलेज मैनेजमेंट

मॉड्यूल 5 परिचय·4 मिनट

Claude का उपयोग करने और Claude को संचालित करने के बीच एक पंक्ति है।

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

कॉन्फ़िगरेशन वह कदम भी है जो व्यक्तिगत कौशल को टीम क्षमता में बदल देता है। जब Project, निर्देश और ज्ञान को क्यूरेट किया जाता है, तो दो लोग एक ही सवाल पूछने पर एक ही गुणवत्ता का जवाब पाते हैं। जब वे नहीं होते हैं, तो हर कोई रोज़ context को फिर से बनाता है और जवाब अलग हो जाते हैं।

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

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

• 1 निर्देश और ज्ञान स्रोतों के साथ Claude Projects को कॉन्फ़िगर करना।

• 2 अपलोड किए गए ज्ञान और कनेक्टर जैसे Google Drive और Gmail को प्रबंधित करना।

• 3 प्रभावी सिस्टम-स्तरीय निर्देश बनाना।

• 4 कॉन्फ़िगरेशन, ज्ञान स्रोतों और निर्देशों को सूचित करना, बनाए रखना और अपडेट करना।

एक बार सेट करें, हर बातचीत से लाभ उठाएं, फिर इसे बनाए रखें ताकि यह सच रहे। एक Project के निर्देश, ज्ञान और स्कोप किए गए Memory को कॉन्फ़िगर करना सीखें; कनेक्टर और उनकी सीमाओं को प्रबंधित करें; ऐसे स्थायी निर्देश लिखें जो टिके रहें; और रखरखाव समीक्षा चलाएं जो कॉन्फ़िगरेशन को क्षय से बचाती है।

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

---

स्क्रीन 2: Claude Projects को कॉन्फ़िगर करना

शिक्षण Projects को कॉन्फ़िगर करना·12 मिनट

एक Project में कई कॉन्फ़िगरेशन स्लॉट होते हैं, और कौशल एक आवर्ती आवश्यकता के प्रत्येक भाग को सही स्लॉट में डालना है। निर्देश व्यवहार को नियंत्रित करते हैं, ज्ञान आधार तथ्यों को रखता है, Skills प्रक्रियाओं को ले जाते हैं, और स्कोप किया गया Memory निरंतरता बनाए रखता है। प्रत्येक आवश्यकता के लिए सही स्लॉट चुनना यही है जो एक Project को सुचारू रूप से चलाता है।

चार कॉन्फ़िगरेशन तंत्र

यह देखने के लिए प्रत्येक कार्ड को फ्लिप करें कि उस स्लॉट में क्या जाता है।

स्थायी निर्देश

Claude को Project में हर बातचीत में कैसे व्यवहार करना चाहिए: टोन, प्रारूप डिफ़ॉल्ट, सत्यापन आदतें। व्यवहार, तथ्य नहीं।

ज्ञान आधार

दस्तावेज़, नीतियां और संदर्भ फ़ाइलें जिन पर Claude को फिर से अपलोड किए बिना आकर्षित करना चाहिए। तथ्य और संदर्भ, व्यवहार नहीं।

Skills

दोहराई जाने वाली प्रक्रियाएं जिन्हें Claude को एक कार्य प्रकार के लिए लगातार अनुसरण करना चाहिए। प्रक्रिया, एकबारी निर्देश नहीं। Skills खाता स्तर पर Customize के तहत रहते हैं, किसी एक Project के अंदर नहीं, एक Skill जो आप बनाते हैं वह किसी भी Project में पुन: उपयोग योग्य है जिसे इसकी आवश्यकता है।

स्कोप किया गया Memory

Project के भीतर निरंतरता, आपकी अन्य Projects से अलग रखी गई है ताकि context workstreams के बीच न फैले।

सही तंत्र चुनना

आवर्ती सवाल यह है: निर्देश, ज्ञान, या Skill? व्यवहार के बारे में एक नियम ("हमेशा स्रोतों का हवाला दें") एक निर्देश है। एक तथ्य जो Claude को चाहिए ("हमारा ब्रांड पैलेट ये हेक्स कोड हैं") ज्ञान है। एक बहु-चरणीय प्रक्रिया ("निष्कर्षों को हमारे मानक रिपोर्ट टेम्पलेट में प्रारूपित करें") एक Skill है, जो खाता स्तर पर Customize के तहत एक बार बनाया जाता है और किसी भी Project में पुन: उपयोग किया जाता है जिसे इसकी आवश्यकता है, न कि एक एकल Project के अंदर कॉन्फ़िगर किया जाता है।

एक प्रक्रिया को निर्देशों में डालना, या एक व्यवहार नियम को ज्ञान आधार में डालना, सबसे आम कॉन्फ़िगरेशन गलती है, और यह Project को बनाए रखना कठिन बनाता है।

कार्य किया गया उदाहरण: एक क्लाइंट खाता कार्यक्षेत्र

एक सलाहकार प्रति क्लाइंट एक Project सेट करता है। क्लाइंट A के लिए:

स्थायी निर्देश: "एक औपचारिक रजिस्टर में लिखें। किसी भी तथ्यात्मक दावे के लिए हमेशा स्रोत दस्तावेज़ का हवाला दें। जो कुछ भी आप अनिश्चित हैं उसे अनुमान लगाने के बजाय फ्लैग करें।"

ज्ञान आधार: क्लाइंट का ब्रांड गाइड, कार्य का वर्तमान विवरण, और पिछली तीन स्थिति रिपोर्टें।

Skill (खाता-स्तर, यहां पुन: उपयोग किया गया): फर्म का स्थिति-रिपोर्ट फॉर्मेटर, जो खाता स्तर पर Customize के तहत रहता है और किसी भी Project के लिए उपलब्ध है, इसलिए हर साप्ताहिक अपडेट एक ही संरचना में आता है।

स्कोप किया गया Memory: क्लाइंट के हितधारक नाम और स्थायी प्राथमिकताएं, जो कभी भी क्लाइंट B के Project में दिखाई नहीं देते।

Team या Enterprise पर, Project को अनुमतियों के तहत एनगेजमेंट टीम के साथ साझा किया जा सकता है, इसलिए हर कोई एक ही कॉन्फ़िगर किए गए आधार से काम करता है। Project-स्कोप किया गया Memory यह गारंटी देता है कि क्लाइंट A का context क्लाइंट B की बातचीत में दिखाई नहीं देता है, वह अलगाव जो एक-Project-प्रति-क्लाइंट को सुरक्षित बनाता है।

स्कोप किया गया Memory एक प्रथम-श्रेणी तंत्र के रूप में

Memory को अक्सर एक बाद की सोच के रूप में माना जाता है, लेकिन एक Project में, यह किसी अन्य कॉन्फ़िगरेशन स्लॉट की तरह है। निर्देश कहते हैं कि Claude को कैसे व्यवहार करना चाहिए और ज्ञान आधार कहता है कि क्या सच है। Skills खाता स्तर पर पुन: उपयोग योग्य प्रक्रियाएं ले जाते हैं, किसी भी Project के लिए उपलब्ध हैं जिसे उनकी आवश्यकता है। स्कोप किया गया Memory वह रखता है जो Project ने पहले से ही तय किया है: हितधारक नाम, स्थायी प्राथमिकताएं, पिछली बातचीत से निर्णय जिन्हें आप हर बार फिर से बताना नहीं चाहते।

जो शब्द मायने रखता है वह है "स्कोप किया गया"। एक Project का Memory आपकी अन्य Projects से अलग किया जाता है, इसलिए एक क्लाइंट या workstream के लिए बनाया गया context कभी दूसरे में दिखाई नहीं देता। वह अलगाव यही है जो Memory को संवेदनशील या क्लाइंट-विशिष्ट निरंतरता के लिए सुरक्षित बनाता है। Claude को बिना गलत दर्शकों को जानकारी प्रकट करने के जोखिम के बिना जो चाहिए वह याद रखता है। Memory बनाम ज्ञान में क्या जाता है यह प्रकार पर निर्भर करता है: एक स्थिर संदर्भ तथ्य ज्ञान में जाता है जबकि Project निर्णयों का एक विकसित रिकॉर्ड Memory में जाता है।

जब एक आवश्यकता दो तंत्रों में फैली हो

सबसे स्वच्छ कॉन्फ़िगरेशन शायद ही कभी एक आवश्यकता को एक एकल स्लॉट में मैप करते हैं। सबसे आम पैटर्न एक व्यवहार नियम और वह तथ्य है जो इस पर कार्य करता है: "तथ्यात्मक दावों के लिए हमेशा स्रोत दस्तावेज़ का हवाला दें" एक स्थायी निर्देश है, लेकिन दस्तावेज़ जो यह उद्धृत करता है वह ज्ञान आधार में रहते हैं। न तो अकेले काम करता है: निर्देश के पास दस्तावेज़ों के बिना उद्धृत करने के लिए कुछ नहीं है, और दस्तावेज़ निर्देश के बिना असंगत रूप से उपयोग किए जाते हैं। Skills एक ही तरीके से जोड़ी जाती हैं: एक स्थिति-रिपोर्ट Skill प्रक्रिया ले जाती है, जबकि ब्रांड गाइड जो इसे प्रारूपित करता है वह ज्ञान में बैठता है। तो जब आप एक Project को कॉन्फ़िगर करते हैं, तो पूछें कि एक आवश्यकता किस स्लॉट में जाती है, और क्या इसे दो स्लॉट की आवश्यकता है।

---

स्क्रीन 3: कनेक्टर और अपलोड किया गया ज्ञान

शिक्षण कनेक्टर और अपलोड किया गया ज्ञान·8 मिनट

कनेक्टर Claude की पहुंच को उस डेटा तक बढ़ाते हैं जिसमें आप पहले से काम करते हैं, जैसे Google Drive और Gmail। वे शक्तिशाली हैं, और उनकी सीमाएं हैं।

उन्हें क्यूरेट किए गए स्रोतों के रूप में प्रबंधित करना, और बिल्कुल जानना कि प्रत्येक क्या कर सकता है और क्या नहीं कर सकता है, यही है जो उन्हें उपयोगी रखता है निराशाजनक होने के बजाय।

बाहरी स्रोतों को जोड़ना

एक कनेक्टर Claude को एक बाहरी सिस्टम तक पहुंचने देता है जिसे आप अधिकृत करते हैं, जैसे एक दस्तावेज़ के लिए अपने Drive को खोजना या एक प्रासंगिक ईमेल खोजना। आप प्रबंधित करते हैं कि क्या सुलभ है, और आप उस सेट को जानबूझकर रखते हैं न कि डिफ़ॉल्ट रूप से सब कुछ जोड़ने के बजाय।

क्षमता सीमाएं

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

दो क्षेत्र-अवलोकन किए गए नुकसान

विस्तार करने के लिए प्रत्येक पर क्लिक करें।

अपलोड किए गए ज्ञान को वर्तमान रखना

अपलोड किए गए ज्ञान को एक जुड़े हुए स्रोत की तरह ही देखभाल की आवश्यकता है: इसे वर्तमान, प्रासंगिक और डुप्लिकेट से मुक्त रखें। एक ज्ञान आधार जिसमें एक ही नीति के तीन संस्करण हैं Claude को गलत एक का हवाला देने के लिए आमंत्रित करता है। इसे एक साझा ड्राइव की तरह क्यूरेट करें, नए जोड़ते समय पुराने संस्करणों को हटाते हुए।

---

स्क्रीन 4: सिस्टम-स्तरीय निर्देश जो टिके रहें

शिक्षण सिस्टम-स्तरीय निर्देश·8 मिनट

टीमें एक ही सवाल का एक संस्करण पूछती रहती हैं: क्या हम हर बातचीत में उन्हें फिर से टाइप करने के बजाय एक बार guardrails को बेक कर सकते हैं? स्थायी निर्देश बिल्कुल वह तंत्र हैं।

आप सत्यापन व्यवहार, प्रारूप डिफ़ॉल्ट और टोन एक बार लिखते हैं, और Project में हर बातचीत उन्हें विरासत में पाती है।

Guardrails को एक बार लिखें

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

"हर तथ्यात्मक दावे के लिए स्रोत दस्तावेज़ का हवाला दें, और जब दस्तावेज़ कुछ कवर नहीं करते हैं तो अनुमान लगाने के बजाय 'मुझे नहीं पता' कहें।"

अब वह अनुशासन हर बातचीत में लागू होता है बिना किसी को इसके लिए पूछने की याद दिलाए।

उपयोग के मामलों का अनुमान लगाएं

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

सटीकता, या यह चुपचाप विफल हो जाता है

अस्पष्ट निर्देश यह घोषणा नहीं करते कि वे विफल हुए; वे बस चुपचाप काम नहीं करते। "पेशेदार बनें" Claude को लगभग कुछ भी कार्य करने के लिए नहीं देता है। "एक औपचारिक रजिस्टर का उपयोग करें, पहली बार उपयोग पर किसी भी संक्षिप्त नाम को परिभाषित करें, और पैराग्राफ को चार वाक्यों के तहत रखें" आउटपुट को बदलने के लिए काफी सटीक है।

एक निर्देश की परीक्षा यह है कि क्या दो अलग-अलग लोग इसे एक ही तरीके से पढ़ेंगे।

कार्य किया गया उदाहरण: एक निर्देश से पहले और बाद में

एक ही निर्देश, अस्पष्ट बनाम सटीक की तुलना करने के लिए टॉगल करें।

"रिपोर्टों को अच्छा और सटीक बनाएं।" आउटपुट गुणवत्ता बातचीत से बातचीत में भिन्न होती है; कुछ भी ठोस नहीं बदला।

"रिपोर्ट में हर आंकड़े के लिए, इसका स्रोत बताएं। यदि कोई आंकड़ा प्रदान किए गए डेटा में नहीं है, तो इसे 'अपरीक्षित' के रूप में चिह्नित करें न कि इसे शामिल करें। प्रत्येक रिपोर्ट को एक-वाक्य हेडलाइन के साथ शुरू करें।" अब सत्यापन व्यवहार सुसंगत है, और हेडलाइन हर बार दिखाई देती है।

---

स्क्रीन 5: कॉन्फ़िगरेशन को बनाए रखना

शिक्षण कॉन्फ़िगरेशन को बनाए रखना·10 मिनट

कॉन्फ़िगरेशन जीवंत संपत्ति हैं। निर्देश, ज्ञान, Skills और Memory सभी पुराने की ओर बढ़ते हैं, और पुरानी कॉन्फ़िगरेशन आउटपुट को चुपचाप कम करती है, कोई त्रुटि नहीं जो आपको सचेत करे। रखरखाव को शेड्यूल करना यही है जो आप क्षय को एक deliverable तक पहुंचने से पहले पकड़ते हैं।

समीक्षा cadence

प्रत्येक सक्रिय Project के लिए एक आवर्ती समीक्षा सेट करें: क्या स्थायी निर्देश अभी भी वर्तमान प्रक्रिया से मेल खाते हैं, क्या ज्ञान आधार पुरानी दस्तावेज़ों से मुक्त है, क्या सही Skills सक्षम हैं? सक्रिय Projects के लिए एक मासिक पास अधिकांश drift को पकड़ता है। संकेत कि आप बहुत लंबे समय तक प्रतीक्षा करते हैं वह है कि कोई दृश्यमान कारण नहीं है आउटपुट गुणवत्ता में गिरावट।

Skills संस्करण

Skills समय के साथ अपडेट होते हैं। Anthropic-निर्मित और संगठन-प्रदान किए गए Skills स्वचालित रूप से अपडेट होते हैं; आपकी अपनी कस्टम-अपलोड की गई Skills केवल तभी बदलती हैं जब आप उन्हें फिर से अपलोड करते हैं। एक गलत कॉन्फ़िगर किए गए या पुरानी Skill के लिए देखें जो आउटपुट को कम कर रहा है। एक Skill जो चुपचाप हर रन में थोड़ा गलत प्रारूप का उत्पादन करता है वह एक रखरखाव समस्या है, एक prompting समस्या नहीं।

Memory जीवनचक्र

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

कॉन्फ़िगरेशन भी additive है: जब Claude ने स्वचालित रूप से एक तथ्य को कैप्चर नहीं किया है जो मायने रखता है: एक बाधा, एक प्राथमिकता, पृष्ठभूमि का एक टुकड़ा, इसे स्पष्ट रूप से स्थायी निर्देश या Memory में जोड़ें न कि इसे हर सत्र में फिर से आपूर्ति करें।

कार्य किया गया उदाहरण: एक क्षीण सेटअप का ऑडिट

रखरखाव चेकलिस्ट कारणों को खोजता है: एक स्थायी निर्देश अभी भी एक मीट्रिक को संदर्भित करता है जिसे टीम ने पिछली तिमाही में नाम दिया था, ज्ञान आधार टेम्पलेट के दो संस्करण रखता है, और एक Memory प्रविष्टि एक हितधारक को रिकॉर्ड करता है जो चला गया है।

फिक्स रखरखाव है, एक नया prompt नहीं: निर्देश को अपडेट करें, पुरानी टेम्पलेट को हटाएं, पुरानी Memory प्रविष्टि को हटाएं। आउटपुट बिना किसी को prompt करने के तरीके को बदले मानक पर लौटता है।

---

स्क्रीन 6: मॉड्यूल 5 क्विज़

क्विज़ मॉड्यूल 5·5 मिनट

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

---

स्क्रीन 7: मुख्य टेकअवे

मॉड्यूल 5 मुख्य टेकअवे·5 मिनट

पांच चीजें जो इस मॉड्यूल में रखी जाती हैं:

कॉन्फ़िगरेशन लाभ है।

एक बार सेट करें, हर बातचीत पर लाभ उठाएं। एक कॉन्फ़िगर किया गया वातावरण Claude को संचालित करने को केवल इसका उपयोग करने से अलग करता है।

प्रत्येक आवश्यकता को सही तंत्र से मेल खाएं।

व्यवहार के लिए निर्देश, तथ्यों के लिए ज्ञान, प्रक्रियाओं के लिए Skills, निरंतरता के लिए स्कोप किया गया Memory।

प्रत्येक कनेक्टर की सीमा जानें।

कनेक्टर Claude की पहुंच को बढ़ाते हैं, लेकिन प्रत्येक की एक क्षमता किनारा है; इसे जानना निराशा और गलत तरीके से भेजी गई फिक्स को रोकता है।

निर्देश सटीक रूप से लिखें।

अस्पष्ट स्थायी निर्देश चुपचाप विफल हो जाते हैं; सटीक, परीक्षण योग्य लोग हर बातचीत में आउटपुट को बदलते हैं।

बनाए रखें या गुणवत्ता क्षय देखें।

कॉन्फ़िगरेशन पुराने हो जाते हैं। निर्देश, ज्ञान, Skills संस्करण और Memory की समीक्षा को शेड्यूल करें, या आउटपुट चेतावनी के बिना कम हो जाता है।

सभी उत्पाद व्यवहार विवरण जून 2026 के अनुसार claude. ai सुविधाओं पर आधारित हैं। सुविधा उपलब्धता और व्यवहार को प्रकाशन पर वर्तमान Anthropic दस्तावेज़ों के विरुद्ध सत्यापित किया जाना चाहिए:

• Claude Help Center: Projects, ज्ञान आधार, Skills, Memory, कनेक्टर, support. claude. com

• कनेक्टर सूची, क्षमता सीमाएं, और संगठन-निर्देशिका रूटिंग: पाठ 3 को अंतिम रूप देने से पहले वर्तमान व्यवहार की पुष्टि करें

• Skills संस्करण व्यवहार और Memory निर्यात/रीसेट: पाठ 5 को अंतिम रूप देने से पहले वर्तमान claude. ai व्यवहार की पुष्टि करें

• Team/Enterprise Project साझाकरण और संगठन-स्तरीय Memory नियंत्रण: स्तर उपलब्धता की पुष्टि करें

---

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

मॉड्यूल पूर्ण एसोसिएट पथ·2 मिनट

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

M1: उत्पाद और मॉडल चयन

किसी भी दिए गए कार्य के लिए सही प्रवेश बिंदु, मॉडल और सुविधाएं चुनें।

M2: Prompting

संरचित prompts बनाएं और उन्हें कार्य प्रकार के अनुसार अनुकूलित करें।

M3: आउटपुट मूल्यांकन

आउटपुट को मान्य करें और जानें कि मानव समीक्षा कब गैर-परक्राम्य है।

M4: कार्यप्रवाह एकीकरण

एक कार्यप्रवाह को Delegation मानदंड के विरुद्ध मैप करें और इसे सुरक्षित रूप से पुनः डिज़ाइन करें।

M5: कॉन्फ़िगरेशन

Projects, निर्देश और ज्ञान को कॉन्फ़िगर और बनाए रखें।

M6: शासन

उपयोग-मामले, डेटा, नीति और नैतिकता निर्णय को जिम्मेदारी से लागू करें।

M7: समस्या निवारण

कम प्रदर्शन का निदान करें और जब परिणाम कम हों तो कार्यप्रवाह को अनुकूलित करें।

M8: कोर्स सारांश और अगले कदम

यात्रा को दोहराएं, परीक्षा के लिए तैयार करें, और Developer और Architect ट्रैक के लिए escalation सीमाओं को पहचानें।