ज़्यादातर लोग Claude का इस्तेमाल सर्च बार की तरह करते हैं।
हर सत्र एक ही तरह से शुरू होता है। आप एक मार्केटिंग कॉपीराइटर हैं। मेरा व्यवसाय यह है। मेरा दर्शक वह है। अब मेरे लिए वह चीज़ लिखिए। फिर आप टैब बंद कर देते हैं, और अगले दिन आप पूरी ब्रीफिंग फिर से खरोंच से शुरू करते हैं, हर सुबह उसी कर्मचारी को प्रशिक्षित करते हैं और रात तक उन्हें सब कुछ भूलने देते हैं।
यह कोई वर्कफ़्लो नहीं है। यह शून्य से शुरू करना है, हमेशा के लिए।
Claude Projects इस समस्या को ठीक करते हैं, और लगभग कोई भी उन्हें सही तरीके से सेट नहीं करता। ज़्यादातर लोग एक प्रोजेक्ट बनाते हैं, उसमें निर्देशों की एक पंक्ति चिपकाते हैं, एक बेतरतीब PDF डालते हैं, और सोचते हैं कि यह सामान्य चैट से नाटकीय रूप से बेहतर क्यों नहीं लगता। शक्ति वास्तविक है, लेकिन वह उन विवरणों में रहती है जो सेटअप स्क्रीन नहीं समझाती।
यह Claude Projects को उस तरह से स्थापित करने का पूरा पाठ्यक्रम है जैसा कि वे लोग करते हैं जो वास्तव में उन पर निर्भर हैं। यहाँ हर सुविधा वास्तविक और मौजूदा है। अंत तक आपके पास एक ऐसा प्रोजेक्ट होगा जो स्वचालित रूप से हर बातचीत में पूरा संदर्भ लोड करता है, उसे फिर से ब्रीफ करने की कभी ज़रूरत नहीं होती, और ऐसा आउटपुट तैयार करता है जो एक सामान्य सहायक के बजाय आपकी तरह लगता है।
एक प्रोजेक्ट वास्तव में क्या है
मार्केटिंग को हटा दें, और एक Claude Project तीन चीजें हैं जो एक स्थायी कार्यक्षेत्र में बंडल हैं।
कस्टम निर्देश। एक सिस्टम-स्तरीय प्रॉम्प्ट जो स्वचालित रूप से प्रोजेक्ट के अंदर हर बातचीत पर लागू होता है। यह स्थायी ब्रीफ है जो Claude के व्यवहार को आकार देता है, जिससे वह बात कर रहा है, और वह किन नियमों का पालन करता है, बिना आपको चैट में कुछ भी टाइप किए।
एक ज्ञानकोष। फ़ाइलें और दस्तावेज़ जिन्हें Claude हर बातचीत में संदर्भित कर सकता है, हमेशा उपलब्ध, कभी पुनः अपलोड करने की ज़रूरत नहीं। स्टाइल गाइड, स्पेक्स, पिछले काम, संदर्भ सामग्री।
स्कोप्ड वार्तालाप। प्रोजेक्ट के अंदर सभी चैट एक साथ समूहित होते हैं और समान निर्देश और ज्ञान प्राप्त करते हैं।
एक महत्वपूर्ण बात जिसे पहले से समझ लेना चाहिए, क्योंकि यह लोगों को लगातार परेशान करता है। प्रोजेक्ट के अंदर वार्तालाप एक-दूसरे के साथ संदेश इतिहास साझा नहीं करते। साझा स्थिति निर्देश और फ़ाइलें हैं, चैट नहीं। प्रत्येक नया वार्तालाप केवल उन दो चीजों के साथ ताज़ा शुरू होता है। यह मायने रखता है कि आप नीचे सब कुछ कैसे डिज़ाइन करते हैं।
प्रोजेक्ट सभी Claude योजनाओं पर उपलब्ध हैं, जिसमें मुफ़्त भी शामिल है, हालाँकि मुफ़्त उपयोगकर्ता पाँच प्रोजेक्ट तक सीमित हैं, और प्रोजेक्ट निर्देश विशेष रूप से एक भुगतान सुविधा है। Pro, Max और Team पर आपको पूरा सेटअप मिलता है।
लगभग हर कोई जो गलती करता है
सेटअप से पहले, सबसे बड़ी एकल त्रुटि को समझें, क्योंकि इससे बचना ही अधिकांश लड़ाई है।
लोग ज्ञानकोष को भंडारण लॉकर की तरह मानते हैं। वे इसमें सब कुछ डाल देते हैं। पूरा ब्रांड मैनुअल। छह महीने के मीटिंग नोट्स। एक चालीस पेज की रणनीति डेक। तर्क सही लगता है। अधिक संदर्भ बराबर बेहतर आउटपुट।
यह उस तरह काम नहीं करता, और यहाँ कारण है। प्रोजेक्ट ज्ञान हर प्रतिक्रिया में पूरी तरह से लोड नहीं होता। Claude पुनर्प्राप्ति के माध्यम से प्रति क्वेरी सबसे प्रासंगिक सामग्री खींचता है। जब आप ज्ञानकोष को ढीली-ढाली संबंधित सामग्री से ओवरलोड करते हैं, तो आप उस सिग्नल को खोजने की Claude की क्षमता को कमजोर करते हैं जो वास्तव में मायने रखता है, और आप संदर्भ विंडो को फ़ाइलों से भरने का जोखिम उठाते हैं, जिससे वास्तविक बातचीत के लिए कम जगह बचती है।
वह नियम जो नाटकीय रूप से बेहतर आउटपुट उत्पन्न करता है, लोगों की अपेक्षा के विपरीत है। प्रत्येक ज्ञान दस्तावेज़ को संक्षिप्त और विशिष्ट रखें, लगभग एक से तीन पृष्ठ। एक तीन पृष्ठ की ब्रांड वॉइस गाइड एक चालीस पृष्ठ के ब्रांड मैनुअल को हर बार हराती है, क्योंकि उपयोगी सिग्नल सघन होता है और शोर कम होता है। ज्ञानकोष में सटीकता मात्रा को हर बार मात देती है।
चरण 1: वास्तविक इरादे से प्रोजेक्ट बनाएँ
Claude खोलें, साइडबार में Projects पर क्लिक करें, New project पर क्लिक करें।
नाम जितना दिखता है उससे अधिक मायने रखता है। इसे विशिष्ट रूप से नाम दें। "Newsletter" या "Client Proposals" या "API Documentation," "Work" या "Stuff" नहीं। कारण यह है कि आप कई प्रोजेक्ट बनाएँगे, और पूरी बात अलगाव है। एक अस्पष्ट नाम एक अस्पष्ट प्रोजेक्ट की ओर ले जाता है जो धीरे-धीरे असंबंधित बकवास जमा करता है, जो ठीक उपरोक्त कमजोरी की समस्या है।
यह पहले सिद्धांत की ओर ले जाता है जिसे अधिकांश लोग चूक जाते हैं। प्रति चिंता एक प्रोजेक्ट। अपने बैकएंड कोड और अपनी मार्केटिंग सामग्री को एक ही प्रोजेक्ट में न रखें। क्लाइंट A और क्लाइंट B को न मिलाएँ। अलग-अलग प्रोजेक्ट का मतलब साफ, अधिक केंद्रित संदर्भ है, और केंद्रित संदर्भ ही पूरा कारण है कि प्रोजेक्ट काम करते हैं। सब कुछ के लिए एक मेगा प्रोजेक्ट रखने की प्रवृत्ति उस सामान्य चैटबॉट को फिर से बनाने की प्रवृत्ति है जिससे आप बचना चाहते थे।
चरण 2: निर्देशों को एक स्थायी ब्रीफ की तरह लिखें, प्रॉम्प्ट की तरह नहीं
यह पूरे सेटअप का सबसे अधिक लाभ वाला हिस्सा है, और यहीं पर एक कमजोर प्रोजेक्ट और एक बेहतरीन प्रोजेक्ट के बीच का अंतर सबसे बड़ा है।
एक कमजोर निर्देश ब्लॉक कहता है "आप एक सहायक सहायक हैं जो मार्केटिंग सामग्री लिखता है।" यह Claude को कुछ भी नया नहीं देता जो उसके पास पहले से नहीं था।
एक मजबूत निर्देश ब्लॉक एक पूर्ण स्थायी ब्रीफ है जो किसी ऐसे व्यक्ति के लिए लिखा गया है जो आपके बारे में कुछ नहीं जानता, क्योंकि प्रोजेक्ट में हर नई बातचीत की शुरुआत में बिल्कुल यही स्थिति होती है। इसमें शामिल होना चाहिए कि आप कौन हैं और आप क्या करते हैं, प्राथमिक कार्य जिनके लिए यह प्रोजेक्ट मौजूद है, आपकी टोन और शैली वरीयताएँ, आपका आवश्यक आउटपुट प्रारूप, वह डोमेन ज्ञान जिसे Claude को मान लेना चाहिए, और महत्वपूर्ण रूप से, वे चीजें जो Claude को कभी नहीं करनी चाहिए।
यहाँ एक टेम्पलेट संरचना है जो लगभग किसी भी प्रोजेक्ट प्रकार में काम करती है:
ROLE
आप [विशिष्ट भूमिका] हैं जो [विशिष्ट डोमेन] पर काम कर रहे हैं। आप [विशिष्ट दर्शकों के लिए लिख रहे हैं जो उनके बारे में कुछ नहीं जानते]।
यह प्रोजेक्ट किस लिए है
यहाँ मुख्य कार्य [कार्य 1], [कार्य 2], [कार्य 3] हैं। मान लें कि हर अनुरोध इनमें से किसी एक से संबंधित है जब तक कि अन्यथा न कहा जाए।
कैसे उत्तर दें
टोन: [विशिष्ट]। प्रारूप: [विशिष्ट]। लंबाई: [विशिष्ट]।
जब तक वास्तव में अटक न जाएं, स्पष्ट प्रश्न न पूछें। एक उचित धारणा बनाएं, उसे बताएं, और आगे बढ़ें।
क्या मान लें
[डोमेन तथ्य, उत्पाद विवरण, स्थिति जो हर प्रतिक्रिया में दी गई मानी जानी चाहिए।]
कभी नहीं
[विशिष्ट चीजें जो Claude को इस प्रोजेक्ट में कभी नहीं करनी चाहिए: AI क्लिच, कुछ दावे, कुछ प्रारूप, जो भी आपके कठोर नियम हैं।]
वह एक निर्देश जो स्पष्ट प्रश्न न पूछने के बारे में है, उसका उल्लेख करने योग्य है। डिफ़ॉल्ट रूप से, Claude अक्सर "शुरू करने से पहले, क्या आप मुझे इसके बारे में और बता सकते हैं..." के एक दौर के साथ शुरू होता है। एक ऐसे प्रोजेक्ट के लिए जिसका आप प्रतिदिन उपयोग करते हैं, वह प्रस्तावना शुद्ध घर्षण है। इसे एक उचित धारणा बनाने, उसे बताने और आगे बढ़ने के लिए कहने से आगे-पीछे हट जाता है और हर सत्र को तुरंत गति देता है।
इन निर्देशों को उस पाठक के लिए लिखें जिसका आपके साथ शून्य इतिहास है, क्योंकि हर नई बातचीत वास्तव में वहाँ से शुरू होती है। निर्देश और फ़ाइलें ही एकमात्र ऐसी चीजें हैं जो आगे बढ़ती हैं। आपकी पिछली बातचीत की स्मृति नहीं।
चरण 3: सटीकता के साथ ज्ञानकोष बनाएँ
अब फ़ाइलें। नियम याद रखें। संक्षिप्त, विशिष्ट, प्रत्येक एक से तीन पृष्ठ। यहाँ वह है जो वास्तव में एक अच्छी तरह से निर्मित ज्ञानकोष में होना चाहिए, उदाहरण के रूप में एक सामग्री प्रोजेक्ट का उपयोग करते हुए।
एक वॉइस और स्टाइल गाइड। आप कैसे लिखते हैं। वाक्य लय, आपके द्वारा उपयोग किए जाने वाले शब्द, आपके द्वारा प्रतिबंधित शब्द, आपके आउटपुट का अहसास।
एक दर्शक दस्तावेज़। आप किसके लिए लिख रहे हैं, वे किसकी परवाह करते हैं, वे पहले से क्या जानते हैं, वे किस बारे में संदिग्ध हैं।
एक स्तंभ या दायरा दस्तावेज़। विशिष्ट विषय या श्रेणियाँ जिन्हें यह प्रोजेक्ट कवर करता है, ताकि Claude अपनी लेन में रहे।
सर्वोत्तम उदाहरणों का एक छोटा सेट। आपके वास्तविक सर्वोत्तम काम के तीन से पाँच टुकड़े। यह प्रदर्शन द्वारा विवरण की तुलना में कहीं अधिक प्रभावी ढंग से सिखाता है। Claude वास्तविक उदाहरणों से आपके पैटर्न को किसी भी मात्रा में निर्देश से बेहतर सीखता है।
कार्य के लिए विशिष्ट संदर्भ सामग्री। SEO नोट्स, उत्पाद स्पेक्स, तकनीकी बाधाएँ, जो कुछ भी डोमेन के लिए आवश्यक है।
प्रत्येक फ़ाइल को वर्णनात्मक रूप से नाम दें। "Brand Voice Guide v3," "Q2 Product Roadmap," "API Documentation Payments Module," "notes" या "stuff" नहीं। वर्णनात्मक नाम पुनर्प्राप्ति को सही क्वेरी के लिए सही दस्तावेज़ खोजने में मदद करते हैं, जो पूरी तंत्र है जिस पर आप भरोसा कर रहे हैं।
जानने योग्य सीमाएँ। Pro, Max और Team पर आपको प्रति प्रोजेक्ट 20 फ़ाइलें, प्रति फ़ाइल 30MB, PDF, टेक्स्ट, मार्कडाउन, कोड फ़ाइलें, CSV और इमेज का समर्थन मिलता है। यदि आप सटीकता नियम का पालन करते हैं तो यह पर्याप्त है। यदि आप सीमा तक पहुँच रहे हैं, तो समस्या लगभग हमेशा यह है कि आप सिग्नल के बजाय मात्रा अपलोड कर रहे हैं।
चरण 4: भरोसा करने से पहले पुनर्प्राप्ति का परीक्षण करें
यहाँ एक कदम है जो लगभग कोई नहीं करता है, और यह उन लोगों को अलग करता है जो सोचते हैं कि उनका प्रोजेक्ट काम करता है और जो जानते हैं कि यह काम करता है।
अपना ज्ञान अपलोड करने के बाद, प्रोजेक्ट में एक वार्तालाप खोलें और स्पष्ट रूप से परीक्षण करें कि क्या Claude प्रत्येक दस्तावेज़ को पुनः प्राप्त कर सकता है। सीधे पूछें:
प्रोजेक्ट ज्ञान में Brand Voice Guide के आधार पर, मुझे किसी पोस्ट की शुरुआती पंक्ति कैसे लिखनी चाहिए? आप जिस विशिष्ट मार्गदर्शन का उपयोग कर रहे हैं, उसे उद्धृत करें।
यदि Claude सटीक रूप से दस्तावेज़ का संदर्भ देता है, तो पुनर्प्राप्ति काम कर रही है। यदि वह एक सामान्य उत्तर देता है या मार्गदर्शन नहीं ढूंढ पाता है, तो कुछ गलत है। हो सकता है कि फ़ाइल संसाधित नहीं हुई, हो सकता है कि नामकरण बहुत अस्पष्ट है, हो सकता है कि दस्तावेज़ बहुत अधिक अन्य के नीचे दब गया हो। बेहतर है कि तीन सप्ताह बाद यह पता लगाने के बजाय कि Claude वास्तव में आपकी सबसे महत्वपूर्ण फ़ाइल कभी नहीं पढ़ रहा था, इसे परीक्षण में खोजें।
प्रत्येक महत्वपूर्ण दस्तावेज़ के लिए यह परीक्षण चलाएँ। इसमें पाँच मिनट लगते हैं और यह उस प्रोजेक्ट के बीच का अंतर है जिसके बारे में आप आशा करते हैं कि वह काम करता है और वह जिसके बारे में आप जानते हैं कि वह काम करता है।
चरण 5: प्रति वार्तालाप सही मॉडल चुनें
एक विवरण जो अधिकांश लोग पूरी तरह से चूक जाते हैं। एक प्रोजेक्ट के अंदर, आप प्रत्येक वार्तालाप के लिए स्वतंत्र रूप से चुन सकते हैं कि किस Claude मॉडल का उपयोग करना है। प्रोजेक्ट आपको एक मॉडल में बंद नहीं करता है।
यह लागत और गुणवत्ता के लिए मायने रखता है। प्रोजेक्ट के अंदर नियमित ड्राफ्टिंग के लिए तेज़ मॉडल का उपयोग करें, और उन वार्तालापों के लिए अधिक सक्षम मॉडल पर स्विच करें जिनमें गहन तर्क या जटिल संश्लेषण की आवश्यकता होती है। एक ही प्रोजेक्ट, एक ही निर्देश, एक ही ज्ञान, अलग-अलग इंजन इस बात पर निर्भर करता है कि विशिष्ट कार्य को क्या चाहिए। अधिकांश लोगों को कभी पता नहीं चलता कि वे ऐसा कर सकते हैं और या तो सब कुछ शीर्ष मॉडल पर चलाकर अधिक भुगतान करते हैं या सब कुछ तेज़ मॉडल पर चलाकर कम प्रदर्शन करते हैं।
चरण 6: वार्तालापों का उपयोग केवल कार्यों के रूप में नहीं, बल्कि सोचने के रूप में करें
यहाँ एक आदत है जो चुपचाप प्रोजेक्ट को समय के साथ कहीं अधिक शक्तिशाली बनाती है।
प्रोजेक्ट वार्तालापों का उपयोग केवल पूर्ण कार्यों के लिए न करें। उनका उपयोग जोर से सोचने के लिए करें। एक समस्या पर काम करें, अपने तर्क को समझाएँ, बात करें कि आप निर्णय क्यों ले रहे हैं। क्योंकि प्रोजेक्ट स्कोप्ड और सुसंगत है, ये सोचने वाले वार्तालाप Claude को आपके तर्क पैटर्न को समझने में मदद करते हैं, न कि केवल आपके आउटपुट पैटर्न को।
परिणाम यह है कि हफ्तों में, एक अच्छी तरह से उपयोग किए जाने वाले प्रोजेक्ट के अंदर Claude न केवल आपके प्रारूप बल्कि आपके निर्णय से मेल खाने लगता है। यह उन दृष्टिकोणों का सुझाव देता है जो फिट बैठते हैं कि आप वास्तव में कैसे सोचते हैं, क्योंकि इसने देखा है कि आप उस स्कोप्ड संदर्भ के अंदर कैसे सोचते हैं, न कि केवल आप क्या उत्पादन करते हैं।
चरण 7: इसे बनाए रखें, क्योंकि एक प्रोजेक्ट केवल अपनी फ़ाइलों जितना ही मौजूदा है
एक प्रोजेक्ट सेट और भूलने वाला नहीं है। यह केवल उतना ही सटीक है जितना इसके अंदर है, और पुराना ज्ञान आत्मविश्वास से गलत संदर्भ उत्पन्न करता है, जो कोई संदर्भ न होने से भी बदतर है।
एक रखरखाव की आदत बनाएँ। जब आपकी स्थिति बदलती है, तो वॉइस गाइड को अपडेट करें। जब कोई स्पेक संशोधित होता है, तो पुराने को बदलें। जब कोई रणनीति बदलती है, तो दायरा दस्तावेज़ को अपडेट करें। अपने प्रोजेक्ट निर्देशों की तिमाही समीक्षा करें, क्योंकि छह महीने पहले लिखे गए निर्देश अब सक्रिय रूप से आप जो कर रहे हैं, उसके विपरीत हो सकते हैं, और Claude पुराने नियम का ईमानदारी से पालन करेगा।
जो प्रोजेक्ट मूल्यवान रहते हैं, वे वे हैं जिन्हें लोग मौजूदा रखते हैं। जो चुपचाप बेकार हो जाते हैं, वे वे हैं जिन्हें एक बार सेट किया गया और फिर कभी नहीं छुआ गया, जबकि वास्तविक काम उनके आसपास आगे बढ़ गया।
नई परत: Cowork Projects
जानने योग्य है, क्योंकि यह ऊपर की सभी चीजों को महत्वपूर्ण रूप से विस्तारित करता है। 2026 के अपडेट के अनुसार, प्रोजेक्ट Claude Cowork, डेस्कटॉप एजेंटिक ऐप के अंदर भी रहते हैं, और यह संस्करण ऐसी क्षमताएँ जोड़ता है जो चैट-आधारित प्रोजेक्ट में नहीं हैं।
Cowork प्रोजेक्ट स्कोप्ड मेमोरी जोड़ते हैं जो सत्रों के बीच बनी रहती है, ताकि आप कह सकें "पिछले हफ्ते की रिपोर्ट पर निर्माण करें" और Claude को ठीक-ठीक पता हो कि वह क्या थी, बिना उस संदर्भ को आपके अन्य काम में लीक किए। वे समर्पित स्थानीय फ़ोल्डर जोड़ते हैं, ताकि प्रोजेक्ट आपकी मशीन पर वास्तविक फ़ाइलों को पढ़ और लिख सके। और वे शेड्यूल किए गए कार्य जोड़ते हैं, ताकि एक प्रोजेक्ट आपके द्वारा निर्धारित कैडेंस पर स्वचालित रूप से आवर्ती काम चला सके।
सेटअप तर्क ऊपर की सभी चीजों के समान है। स्पष्ट निर्देश, संक्षिप्त प्रासंगिक फ़ाइलें, प्रति चिंता एक प्रोजेक्ट। लेकिन छत ऊँची है, क्योंकि एक Cowork प्रोजेक्ट न केवल वार्तालापों को सूचित करता है, बल्कि वास्तविक फ़ाइलों के खिलाफ काम निष्पादित करता है और आपके बिना शेड्यूल पर चल सकता है। एक अच्छी पहली चाल इसे एक फ़ोल्डर पर इंगित करना और कहना है:
इस फ़ोल्डर में हर फ़ाइल पढ़ें। फिर इस कार्यक्षेत्र के बारे में आप जो जानते हैं उसे संक्षेप में बताएं: यहाँ क्या है, मैं शायद इसका उपयोग किस लिए करता हूँ, और आप किन निर्देशों का पालन करेंगे। यदि कुछ अस्पष्ट है, तो मान लेने से पहले पूछें।
वह एकल आदेश Claude को पहले दिन प्रोजेक्ट सीखने पर मजबूर करता है, और वहाँ से वह याद रखता है।
चार प्रोजेक्ट टेम्पलेट जिन्हें आप आज बना सकते हैं
सिद्धांत केवल तभी उपयोगी होता है जब वह ठोस हो। यहाँ चार प्रोजेक्ट सेटअप हैं जो सीधे सबसे सामान्य उपयोग मामलों में मैप होते हैं, प्रत्येक में यह बताया गया है कि निर्देशों बनाम ज्ञान में क्या जाता है, ताकि आप संरचना की नकल कर सकें।
सामग्री प्रोजेक्ट। निर्देश आपकी भूमिका को एक विशिष्ट दर्शकों के लिए लेखक के रूप में, आपकी टोन, आपके स्वरूपण नियम और आपके कठोर प्रतिबंधों को परिभाषित करते हैं। ज्ञान में एक वॉइस गाइड, एक दर्शक व्यक्तित्व, एक स्तंभ दस्तावेज़ और आपके सर्वश्रेष्ठ प्रदर्शन करने वाले तीन से पाँच टुकड़े होते हैं। यह वह प्रोजेक्ट है जो आपके द्वारा प्रकाशित हर चीज़ को हर बार एक अलग लेखक के बजाय आपकी तरह सुसंगत बनाता है। ज्ञानकोष में सर्वोत्तम उदाहरण यहाँ किसी भी निर्देश से अधिक काम करते हैं, क्योंकि वॉइस पकड़ी जाती है, सिखाई नहीं जाती।
कोड प्रोजेक्ट। निर्देश आपके स्टैक, आपके कन्वेंशन, आपके पसंदीदा पैटर्न और उन चीजों को परिभाषित करते हैं जो आप कभी नहीं चाहते। ज्ञान में एक आर्किटेक्चर दस्तावेज़, आपकी प्रमुख स्रोत फ़ाइलें, आपके कोडिंग मानक और प्रोजेक्ट के संपर्क में आने वाली किसी भी चीज़ के लिए API दस्तावेज़ होते हैं। Claude को इस पर इंगित करें और यह आपके मौजूदा पैटर्न से लड़ने वाले कोड का सुझाव देना बंद कर देता है और उनसे मेल खाना शुरू कर देता है। प्रति कोडबेस एक प्रोजेक्ट, कभी साझा नहीं, क्योंकि दो कोडबेस को मिलाना सुझाव पाने का सबसे तेज़ तरीका है जो किसी भी एक से मेल नहीं खाता।
क्लाइंट प्रोजेक्ट। प्रति क्लाइंट एक प्रोजेक्ट। निर्देश परिभाषित करते हैं कि क्लाइंट कौन है, उनका ब्रांड, उनकी प्राथमिकताएँ और उनके साथ आपके काम का दायरा। ज्ञान में उनके ब्रांड दिशानिर्देश, पिछली डिलीवरी, मीटिंग नोट्स आवश्यकताओं तक सीमित, और उनके लिए विशिष्ट कोई भी बाधाएँ होती हैं। इस तरह एक एकल ऑपरेटर या एजेंसी हर क्लाइंट के संदर्भ को पूरी तरह से अलग रखता है, ताकि क्लाइंट A की वॉइस क्लाइंट B के काम में कभी न बहे।
अनुसंधान प्रोजेक्ट। निर्देश परिभाषित करते हैं कि आप किस प्रश्न या डोमेन की जाँच कर रहे हैं और आप निष्कर्षों को कैसे संरचित करना चाहते हैं। ज्ञान में आपकी स्रोत सामग्री, आपके पिछले नोट्स और आपकी कार्यशील थीसिस होती है। जैसे-जैसे आप इसे और अधिक खिलाते हैं, यह हर चीज़ में एक तस्वीर बनाता है, और क्योंकि यह स्कोप्ड है, यह इस शोध को आपके द्वारा काम किए जा रहे किसी भी अन्य चीज़ से भ्रमित नहीं करता है। यह एक चैट-आधारित प्रोजेक्ट के दूसरे मस्तिष्क अवधारणा के सबसे करीब है, ज्ञान का एक निकाय जिससे आप पूछताछ कर सकते हैं जो सुसंगत रहता है क्योंकि यह सब कुछ असंबंधित से दीवार कर दिया गया है।
चारों में पैटर्न पर ध्यान दें। निर्देश स्थायी नियम और व्यवहार रखते हैं। ज्ञान संदर्भ सामग्री और उदाहरण रखता है। अलगाव जानबूझकर है, और सही सामग्री को सही परत में प्राप्त करना अधिकांश भाग है जो एक प्रोजेक्ट को काम करता है। व्यवहार करने के तरीके के बारे में एक नियम निर्देशों में होना चाहिए। एक दस्तावेज़ जिसे Claude को संदर्भित करने की आवश्यकता है, वह ज्ञान में होना चाहिए। उन्हें मिलाना, व्यवहार संबंधी नियमों को ज्ञान फ़ाइल में डालना या संदर्भ दस्तावेज़ों को निर्देश बॉक्स में चिपकाना, एक शांत तरीका है जिससे प्रोजेक्ट बिना किसी स्पष्ट कारण के कम प्रदर्शन करता है।
वह स्तरीय वैयक्तिकरण जो अधिकांश लोग चूक जाते हैं
एक और बात जानने योग्य है, क्योंकि यह ऊपर की सभी चीजों के ऊपर ढेर हो जाती है। प्रोजेक्ट निर्देश ही एकमात्र वैयक्तिकरण परत नहीं है जो Claude के पास है, और यह समझना कि वे कैसे संयोजित होते हैं, आपको बेहतर नियंत्रण देता है।
तीन परतें हैं, और वे सभी हर प्रतिक्रिया पर एक साथ लागू होती हैं। खाता-व्यापी निर्देश, आपकी प्रोफ़ाइल सेटिंग में सेट, प्रोजेक्ट की परवाह किए बिना हर चैट पर हर जगह लागू होते हैं। प्रोजेक्ट निर्देश केवल एक विशिष्ट प्रोजेक्ट के अंदर लागू होते हैं। और शैलियाँ, प्रति चैट सेट, उस एक वार्तालाप के लिए टोन और प्रारूप को ट्यून करती हैं।
व्यावहारिक कदम प्रत्येक का उपयोग वहाँ करना है जहाँ वह सबसे अच्छा है। वे नियम जो Claude के साथ आपके द्वारा की जाने वाली हर चीज़ पर लागू होते हैं, जैसे आपकी सामान्य संचार प्राथमिकताएँ, खाता-व्यापी प्रोफ़ाइल निर्देशों में डालें, ताकि आप उन्हें हर प्रोजेक्ट में दोहराएँ नहीं। प्रोजेक्ट-विशिष्ट संदर्भ और नियम प्रोजेक्ट निर्देशों में डालें। शैलियों का उपयोग एकमुश्त समायोजन के लिए करें जब किसी विशेष वार्तालाप को प्रोजेक्ट डिफ़ॉल्ट से भिन्न टोन की आवश्यकता होती है।
अधिकांश लोग सब कुछ एक परत में ठूंस देते हैं और यह नियंत्रण खो देते हैं। जब आप उन्हें सही ढंग से अलग करते हैं, तो आप अपनी सार्वभौमिक प्राथमिकताओं को हर एक प्रोजेक्ट में दोहराना बंद कर देते हैं, और प्रत्येक प्रोजेक्ट के निर्देश पूरी तरह से उस पर केंद्रित रहते हैं जो उस प्रोजेक्ट को अलग बनाता है। वह फोकस, फिर से, प्रोजेक्ट को अच्छी तरह से स्थापित करने का पूरा विषय है।
सेटअप जो वास्तव में संयोजित होता है
पूरी चीज़ को एक साथ रखें और यहाँ वह है जो एक ठीक से निर्मित प्रोजेक्ट आपको देता है जो एक सामान्य चैट कभी नहीं देगा।
हर बातचीत पहले से लोड पूर्ण संदर्भ के साथ शुरू होती है। आपकी आवाज़, आपके दर्शक, आपके नियम, आपकी संदर्भ सामग्री, एक शब्द लिखने से पहले सब कुछ मौजूद होता है। आप फिर से ब्रीफ करना बंद कर देते हैं। आप शून्य से शुरू करना बंद कर देते हैं। आप हर सुबह उसी कर्मचारी को प्रशिक्षित करना बंद कर देते हैं।
आउटपुट सामान्य लगना बंद कर देता है और आपकी तरह लगने लगता है, क्योंकि Claude आपके वास्तविक उदाहरणों और आपके वास्तविक मानकों से काम कर रहा है, न कि एक खाली स्लेट और एक जल्दबाजी में लिखी गई एक-पंक्ति प्रॉम्प्ट से।
और यह संयोजित होता है। पहले हफ्ते में छोटे सुधारों की आवश्यकता होती है क्योंकि Claude फ़ाइलों से आपके पैटर्न सीखता है। तीसरे हफ्ते तक, यह आपके दृष्टिकोण से इतनी अच्छी तरह मेल खाता है कि आप उन चीजों को समझाना बंद कर देते हैं जिन्हें आप हर बार समझाते थे। तीस मिनट का सेटअप महीनों में भुगतान करता है।
यहाँ ईमानदार निचली रेखा है। अधिकांश लोगों को यह लाभ कभी नहीं मिलता, सुविधा के कठिन होने के कारण नहीं, बल्कि इसलिए कि वे इसे नब्बे सेकंड में सेट करते हैं और कभी वे हिस्से नहीं करते जो वास्तव में मायने रखते हैं। सटीक ज्ञानकोष। वास्तविक स्थायी ब्रीफ। पुनर्प्राप्ति परीक्षण। रखरखाव की आदत।
उन चार चीजों को करें और Claude Projects आपके चैट के लिए एक फ़ोल्डर बनकर रह जाते हैं और Claude को सर्च बार के रूप में उपयोग करने और इसे एक ऐसी प्रणाली के रूप में चलाने के बीच का अंतर बन जाते हैं जो पहले से ही जानता है कि आप वास्तव में कौन हैं और आपको क्या चाहिए।
इस हफ्ते एक प्रोजेक्ट को ठीक से सेट करें। वह काम चुनें जो आप सबसे अधिक करते हैं। वास्तविक निर्देश लिखें। तीन संक्षिप्त दस्तावेज़ अपलोड करें। पुनर्प्राप्ति का परीक्षण करें। फिर देखें कि अगली बातचीत कितनी अलग लगती है।
@cyrilXBT को फॉलो करें पूर्ण बिल्ड, सटीक निर्देश टेम्पलेट और उन प्रोजेक्ट सेटअप के लिए जिनका मैं हर दिन उपयोग करता हूँ।
