ASD-STE100 सिम्प्लिफ़ाइड टेक्निकल इंग्लिश में डॉक्यूमेंट्स को फ़ोर्स करने के लिए Agent Skill

मूल लेख ↗ Hacker News चर्चा ↗

इंजीनियर ASD‑STE100 का प्रयोग कर रहे हैं, जो aerospace manuals से आया एक नियंत्रित “Simplified Technical English” standard है, ताकि आधुनिक large language models द्वारा उत्पन्न लंबे, jargon-heavy prose को कम किया जा सके। कुछ लोग इस style guide को एक “agent skill” या default output mode के रूप में पैकेज करने में मूल्य देखते हैं, ताकि documentation गैर-देशी वक्ताओं और विचलित पाठकों के लिए अधिक स्पष्ट बने, जबकि आलोचक कहते हैं कि एक single prompt line या बाहरी linters समान परिणाम दे सकते हैं और ऐसे कई skills low-effort cruft हैं। व्यापक विषय AI outputs के बढ़ते verbose होने से निराशा और style constraints — STE से लेकर Economist guide और Orwell के rules तक — को AI-generated text को अधिक concise, precise, और readable बनाने के व्यावहारिक tools के रूप में तलाशना है.

LLM आउटपुट के लिए ASD‑STE100 के कथित लाभ

  • कई टिप्पणीकार “AI slop” को रोकने के लिए Simplified Technical English (STE) के उपयोग को पसंद करते हैं: लंबा, अत्यधिक अलंकृत, छद्म‑स्मार्ट गद्य।
  • बताए गए प्रभाव: छोटे वाक्य, अधिक स्पष्ट निर्देश, कम मार्केटिंग टोन, दस्तावेज़ और ईमेल लिखना आसान, विचलित पाठकों के लिए आउटपुट अधिक सहनीय।
  • कुछ लोग एजेंटों के लिए वैश्विक निर्देश के रूप में STE (या इसी तरह की सीमाओं) का उपयोग करते हैं और कहते हैं कि इससे पठनीयता बेहतर होती है, हालांकि यह “earth-shattering” नहीं है।
  • STE क्यों मौजूद है, इसका उदाहरण: घने चेतावनियों को छोटे, सीधे सुरक्षा निर्देशों में बदलना, खासकर गैर-देशी वक्ताओं के लिए।

समर्पित “agent skill” के बारे में संदेह

  • कई लोगों का तर्क है कि एक-लाइन system prompt (“use ASD‑STE100”) पूरे skill जितना ही काम करता है, और वे repo को “cruft” या कम-मेहनत वाला मानते हैं।
  • अन्य लोग जवाब देते हैं कि skills साझा किए जा सकने वाले, versioned bundles के रूप में उपयोगी हैं: instructions, style rules, troubleshooting notes, और helper scripts।
  • कुछ लोग एक iterative workflow बताते हैं: agent को देखते रहें, गलतियों को नए skill rules के रूप में कैप्चर करें, फिर समय के साथ उन्हें refine करें।

Prompting बनाम tooling और enforcement

  • चिंता यह है कि लंबे interactions में models किसी भी style constraint से drift कर जाते हैं।
  • सुझाव: docs और comments पर style लागू कराने के लिए linters (जैसे Vale) और pre-commit या post-tool hooks का उपयोग करें।
  • एक लिंक का दावा है कि Orwell के six writing rules को prompt के रूप में उपयोग करना कभी-कभी STE prompts से बेहतर होता है, “slop” को कम टोकनों में घटाने के लिए।

Model style समस्याएँ और तुलना

  • हाल के models, खासकर नए Claude/Opus variants, के बारे में कई शिकायतें हैं कि वे लंबा, meta-commentary-भरा, और कभी-कभी unreadable text बनाते हैं।
  • कुछ लोगों को नए GPT models तब अधिक सीधे लगते हैं जब उनसे blunt या plain language में पूछा जाए।
  • कुछ उपयोगकर्ता नोट करते हैं कि “personality” instructions अक्सर वास्तविक संक्षिप्तता के बजाय केवल और अधिक verbose sections जोड़ देती हैं।

STE पर बहस और व्यापक प्रवृत्ति

  • विशिष्ट STE examples और यह कि वे वास्तव में unambiguous हैं या नहीं, इस पर चर्चा; कुछ लोग कहते हैं कि domain context के बिना STE अकेले ambiguity ठीक नहीं कर सकता।
  • यह प्रश्न उठाया गया कि क्या भाषा को constrain करने से reasoning प्रभावित हो सकती है; कुछ का तर्क है कि style constraints ideally post-processing layer होनी चाहिए।
  • कई लोगों ने STE-संबंधित posts में अचानक spike नोट किया, जिसे एक वायरल tweet से जोड़ा गया; राय इस बात पर विभाजित है कि यह एक उपयोगी discovery है या AI-productivity का एक अस्थायी चलन।