अपॉइंटमेंट सूची में हैं। सॉर्टिंग बिना किसी त्रुटि संदेश के चलती है। फिर भी 2 दिसंबर, 18 जनवरी से पहले दिखाई देता है, क्योंकि प्रोग्राम तिथि मानों के बजाय कैरेक्टर स्ट्रिंग्स की तुलना करता है। एक कोडिंग एजेंट इस बग को विस्तार से समझा सकता है और फिर भी उसे गलत जगह ठीक कर सकता है। इसलिए दिलचस्प प्रश्न यह है: क्या वह अवलोकन से लेकर ऐसे बदलाव तक, जिसे सत्यापित किया जा सके, पूरे रास्ते को एक साथ बनाए रखता है?
Kimi Code ने K3.1 Pro को 23 अक्टूबर 2026 से उपलब्ध के रूप में सूचीबद्ध किया है। मॉडल परिचय इस पेशकश को अन्य बातों के अलावा प्रोग्रामिंग और लंबे एजेंट कार्यों की ओर लक्षित करता है। 25 अक्टूबर के स्रोतों के अनुसार, पूर्ण वेट फ़ाइलों की घोषणा केवल बाद की किसी तिथि के लिए की गई थी। सेवा तक पहुँच और एक स्थानीय मॉडल पैकेज दो अलग-अलग स्थितियाँ बनी हुई हैं।
एक दोहराया जा सकने वाला बग किसी बड़ी इच्छा से बेहतर है
पहले कार्य के लिए एक स्थानीय नमूना फ़ाइल पर्याप्त है। तीन अपॉइंटमेंट बनाइए, प्रत्येक में एक तिथि और एक ID हो। जानबूझकर दिन.महीना.वर्ष संकेतन का उपयोग कीजिए, ताकि वर्णानुक्रमिक तुलना तिथि के अनुसार सही क्रम होने का भ्रम न दे सके। बिना तिथि वाली एक चौथी पंक्ति एक अतिरिक्त स्थिति बनाती है, जिसे आपके कार्य में स्पष्ट रूप से संभाला जाना चाहिए।
termine = [
{"id": "A", "datum": "02.12.2026"},
{"id": "B", "datum": "18.01.2026"},
{"id": "C", "datum": "18.01.2026"},
{"id": "D", "datum": None}
]वांछित क्रम पहले से बताया जा सकता है: B और C, A से पहले, और बिना तिथि वाला अपॉइंटमेंट एक तय स्थान पर। समान दिनों के लिए इनपुट का क्रम बना रहता है। यह नियम संयोग से सही बैठने वाले किसी उदाहरण आउटपुट से अधिक महत्वपूर्ण है। यह बताता है कि प्रोग्राम को आगे के इनपुट के साथ कैसा व्यवहार करना चाहिए।
एजेंट को सॉर्टिंग का वह हिस्सा भी दीजिए जो वास्तव में दोषपूर्ण है। कारण के बारे में अनुमान मौजूदा कोड को पढ़ने का विकल्प नहीं है। कार्य में यह अपेक्षा रखी जा सकती है कि वह पहले तुलना के विशिष्ट बिंदु का नाम बताए और फिर केवल उसके लिए आवश्यक हिस्से को बदले।
तीन परिणाम अलग-अलग माँगिए
निदान, बदलाव और प्रमाण अलग-अलग प्रस्तुत करवाइए। निदान बताता है कि इस समय डेटा के किस रूप की तुलना की जा रही है। बदलाव सीमित हस्तक्षेप दिखाता है। प्रमाण उन्हीं इनपुट और पहले से तय नियमों का हवाला देता है। इससे एजेंट का एक लंबा उत्तर तीन ऐसे परिणामों में बँट जाता है जिनमें से प्रत्येक की जाँच की जा सकती है।
एक उपयुक्त निर्देश यह है: “इस डेटा के साथ गलत तिथि क्रम को दोहराइए। केवल सॉर्टिंग लॉजिक बदलिए। समान दिनों को उनके मूल क्रम में रखिए और अनुपस्थित तिथि मानों को अंत में रखिए। फिर मूल मामला और महीने की सीमा के पार का एक और मामला दिखाइए।”
यह भी जोड़िए कि क्या अछूता रहना चाहिए: फ़िल्टर, प्रदर्शन और संग्रहीत रिकॉर्ड। अन्यथा कोई एजेंट दिखने में सुरुचिपूर्ण ऐसा समाधान दे सकता है जो रास्ते में इंटरफ़ेस या डेटा प्रारूप को फिर से बना देता है। बड़ा हस्तक्षेप अपने-आप अधिक सावधानीपूर्ण नहीं होता।
मॉडल कॉल के बिना एक छोटा संदर्भ मार्ग
आप अंतर्निहित नियम को एजेंट से स्वतंत्र रूप से समझ सकते हैं। Python में, किसी मौजूदा तिथि स्ट्रिंग को datetime.strptime के साथ तिथि मान में बदला जा सकता है। बिना तिथि वाले मामले के लिए अपनी अलग सॉर्ट कुंजी चाहिए। यह एक संभावित संदर्भ व्यवस्था है, किसी विशेष प्रोजेक्ट के कोड के बारे में कोई दावा नहीं:
from datetime import datetime
def schluessel(eintrag):
wert = eintrag["datum"]
if wert is None:
return (1, datetime.max)
return (0, datetime.strptime(wert, "%d.%m.%Y"))
ergebnis = sorted(termine, key=schluessel)
assert [x["id"] for x in ergebnis] == ["B", "C", "A", "D"]यह शिक्षण उदाहरण मान्य स्ट्रिंग्स और None को कवर करता है। अमान्य कैलेंडर दिन एक अतिरिक्त आवश्यकता हैं और यहाँ चुपचाप ठीक नहीं किए जाते। यदि आप उन्हें समर्थित करना चाहते हैं, तो आपको वांछित त्रुटि संदेश या प्रबंधन भी निर्दिष्ट करना चाहिए।
एक छोटी सफलता वास्तव में क्या दिखाती है
सॉर्टिंग का एक पास हुआ मामला इस कार्य के लिए एक सफलता होगी। यह न तो त्रुटिरहित एजेंट कार्य को सिद्ध करता है और न ही किसी बड़े रिपॉज़िटरी के लिए सामान्य उपयुक्तता को। ठीक इसी कारण छोटा कार्य उपयोगी है: आप देख सकते हैं कि क्या कोई आवश्यकता रास्ते में खो जाती है और क्या एजेंट अपने बदलाव को मूल समस्या के आधार पर परखता है।
अनुरोध, वास्तविक पैच और चलाए गए टेस्ट कॉल को एक-दूसरे से अलग रखिए। “सभी टेस्ट पास हो गए” जैसा लिखित दावा तभी प्रमाण बनता है जब कॉल और उसका परिणाम वास्तव में उपलब्ध हों। यहाँ, लंबे एआई काम की ओर व्यावहारिक शुरुआत में एक संभालने योग्य बग, स्पष्ट सीमाएँ और ऐसा परिणाम शामिल है जिसे आप स्वयं समझ सकें।
स्रोत और स्थिति
25 अक्टूबर 2026 की स्थिति के अनुसार स्रोत। Kimi Code — नया क्या है, K3.1 Pro · Kimi K3.1 Pro का परिचय।
