प्रॉम्प्ट से चेकआउट तक: आसान भाषा में POS का विवरण

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

आसान भाषा में POS का विवरण कैसा लगता है?

यह आपकी उस बात की तरह लगता है, जब आप मंगलवार के दिन किसी को अपना काउंटर दिखा रहे होते हैं:

"मैं एक रजिस्टर के साथ एक बेकरी चलाता हूँ। हम ब्रेड, पेस्ट्री और ड्रिप कॉफ़ी बेचते हैं। पेस्ट्री सिंगल या आधे दर्जन में बिकती हैं। कॉफ़ी दूध के विकल्पों के साथ दो साइज़ में आती है। लगभग हर कोई कार्ड से टैप करके भुगतान करता है, लेकिन हम कैश भी लेते हैं। पूरी ब्रेड की रोटियाँ यहाँ टैक्स-फ्री हैं; बाकी सब पर सेल्स टैक्स लगता है। ग्राहक आमतौर पर ईमेल पर रसीद चाहते हैं।"

कोई फ़ीचर का नाम नहीं, किसी स्क्रीन का वर्णन नहीं। सात वाक्य जो पूरी दुकान के सामने के हिस्से का संचालन करते हैं: कैटलॉग, विकल्प, भुगतान के प्रकार, टैक्स के नियम और रसीद। एक बिल्डर इसके साथ काम कर सकता है। जिसके साथ वह काम नहीं कर सकता, वह है "मेरे लिए बेकरी के लिए एक आधुनिक POS बनाएं", जो एक भावना का वर्णन करता है, व्यवसाय का नहीं।

कौन से पाँच विवरण तय करते हैं कि चेकआउट काम करेगा या नहीं?

वे विवरण जिनके बारे में एक नया कर्मचारी लंच तक पूछ लेगा। प्रत्येक को अपने शब्दों में शामिल करें:

• आप क्या बेचते हैं और उन्हें कैसे वर्गीकृत किया गया है। हर एक आइटम नहीं, बस कैटलॉग का ढांचा: आपकी श्रेणियां, और क्या आइटमों में साइज़ या ऐड-ऑन जैसे विकल्प हैं। एक POS इन विकल्पों को मॉडिफायर कहता है, और इन्हें छोड़ देना ही वह सबसे आम कारण है जिसकी वजह से पहला बिल्ड रजिस्टर पर गलत लगता है।

• लोग कैसे भुगतान करते हैं। कार्ड, कैश या दोनों, और क्या टिप देना आपके काउंटर का हिस्सा है।

• आपके टैक्स के नियम जैसे आप उन्हें वास्तव में लागू करते हैं। कानून नहीं, आपकी दुकान की वास्तविकता: किस पर टैक्स लगता है, क्या टैक्स-फ्री है, और क्या टैक्स शेल्फ़ की कीमत में शामिल है या काउंटर पर जोड़ा जाता है।

• रसीद पर क्या होना चाहिए। ईमेल, प्रिंट या दोनों, और उस पर कोई भी अनिवार्य जानकारी, जैसे आपका बिज़नेस नंबर या रिटर्न पॉलिसी।

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

आसान भाषा क्या नहीं कर सकती?

एक विवरण यह तय करता है कि सिस्टम कैसा व्यवहार करेगा; यह उसके नीचे काम करने वाले बुनियादी तंत्र को सही नहीं बना सकता। इन्वेंट्री जो तब भी सटीक बनी रहती है जब एक ही समय में एक ही आइटम की दो बिक्री होती हैं, दिन के अंत की रिपोर्ट जो मिलान करती हैं (वास्तव में लेन-देन किए गए पैसों से मेल खाती हैं), पहली बिक्री की तरह ही हज़ारवीं बिक्री पर भी एक ही तरह से लागू होने वाला टैक्स, और कार्ड भुगतान जो PCI नियमों (कार्ड उद्योग का सुरक्षा मानक) को पूरा करते हैं, ऐसी चीज़ें नहीं हैं जो एक वाक्य दे सके। जिस प्लेटफ़ॉर्म पर आपका विवरण जाता है, वह या तो इन्हें प्रदान करता है या नहीं।

यहीं पर खुद से करने (do-it-yourself) के प्रयास रुक जाते हैं। एक AI कोड जनरेटर उन्हीं सात वाक्यों से प्रभावशाली चेकआउट स्क्रीन बना देगा, और परिणाम तब तक सही दिखता है जब तक कि उस पर असली पैसा और असली स्टॉक लागू न हो। हमने मैप किया है कि यह दीवार कहाँ आती है: vibe coding a point of sale में और क्यों a top coding model still cannot ship a working POS अपने दम पर एक काम करने वाला POS नहीं बना सकता। आसान भाषा POS के उन हिस्सों के लिए एक पूर्ण स्पेक है जिन्हें आप देख सकते हैं। किसी न किसी को अभी भी उन हिस्सों का निर्माण करना होगा जिन्हें आप देख नहीं सकते।

आप पहले ड्राफ़्ट को कैसे बेहतर बनाते हैं?

उसी तरह जैसे आप उस नए कर्मचारी को सही करेंगे: विशेष रूप से, और एक बार में एक चीज़। जैसे ही आपके पास पूर्वावलोकन (प्रिव्यू) हो, एक टेस्ट सेल चलाएं, पहले अपना सबसे आम ऑर्डर, फिर सबसे अनोखा ऑर्डर। जब कुछ गलत हो, तो पूरी दुकान का फिर से वर्णन करने के बजाय एक साधारण वाक्य के साथ इसे ठीक करें ("आधे दर्जन में पूछा जाना चाहिए कि कौन सी छह पेस्ट्री चाहिए")। यदि स्क्रीन में ही सुधार की आवश्यकता है, तो prompt patterns that produce great POS layouts का उपयोग करें; स्क्रीन के बजाय लेन-देन का वर्णन करने से अधिकांश काम हो जाता है।

Final पर, वह लूप एक चैट की तरह है: वर्णन करें, प्रिव्यू करें, सुधारें, तैनात करें, जिसमें हर बदलाव को एक चेकपॉइंट के रूप में सहेजा जाता है जिसे आप रोल बैक कर सकते हैं। इसके चरण-दर-चरण निर्देश how to build your first flow में हैं, और यदि आप पहले से उपयोग किए जा रहे AI टूल में ही रहना चाहते हैं, तो आप connect your own AI over MCP (AI टूल्स को अन्य सॉफ़्टवेयर से जोड़ने का एक मानक तरीका) कर सकते हैं और उसी लाइव प्रिव्यू पर निर्माण कर सकते हैं। यदि आप यह जानने के लिए उत्सुक हैं कि हम यहाँ तक कैसे पहुँचे, तो इस पर एक लंबी कहानी है कि why prompting replaced visual builders।

तो, क्या आसान भाषा वास्तव में आपको प्रॉम्प्ट से चेकआउट तक ले जा सकती है?

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

यदि आप किसी विवरण को चालू रजिस्टर बनते देखना चाहते हैं, तो Getting Started with Build इसका पाँच मिनट का संस्करण है।