خروجی ساخت‌یافته و تایپ‌دار هنوز از regex برای AI بهتر است
خیلی از قابلیت‌های AI هنوز به تجزیه امیدوارانه متن تکیه دارند. مدل نثر برمی‌گرداند و اپ با regex، برش رشته، یا شکل مؤدبانه‌ای از استیصال، ساختار را نجات می‌دهد. شروعش ارزان است. زندگی با آن گران است.
درد زود در تیم واقعی دیده می‌شود. قابلیت اطمینان، توجه توسعه‌دهنده، هزینه، و اعتماد محصول. این‌ها همان چیزهایی‌اند که یک فهرست «نکته» پوشش نمی‌دهد.
وقتی سراغ این الگو می‌روم که گردش کار تکرار شود، موفقیت تعریف شده باشد، و نگهداری از همان نسخه اول مهم باشد. اگر کاربرد هنوز مبهم است، دامنه را تنگ کن. زیرساخت عمومی را دور مسئله حل‌نشده نساز. سریع‌ترین مسیر معمولاً یک گردش کار تیز است با ورودی صریح و تعریف «به اندازه کافی خوب» برای انتشار اول.
الگوی سالم: schema را تعریف کن، وظیفه را به همان محدود کن، نتیجه را اعتبار کن، و بگذار بقیه اپ روی داده تایپ‌دار کار کند. از آن به بعد خروجی مدل برای تست، ذخیره، رندر، و رد شدن از منطق معمولی کسب‌وکار ساده‌تر است. regex جای خودش را دارد. گردش کار حیاتی نباید به باستان‌شناسی متن وابسته باشد.
مرز را قبل از کد بنویس
یک جمله برای وظیفه. شکل ورودی. شکلی که خروجی باید داشته باشد. ساده به نظر می‌رسد و جلوی رانش معماری را می‌گیرد، چون بقیه سیستم دور قرارداد پایدار طراحی می‌شود نه دور حس.
همان‌جا تصمیم بگیر چه بخشی مال مدل است و چه بخشی در کد معمولی اپ می‌ماند. هرچه گردش کار مهم‌تر شود این تمایز ارزشمندتر است. اگر قابلیت به صورتحساب، مجوز، داده پروداکشن، یا گذار وضعیت قابل مشاهده برای کاربر دست می‌زند، آن بخش‌ها با اعتبار سخت در اپ بمانند. AI جایی کمک کند که کار فازی است. پیامد را اپ مالک شود.
مثلاً «از این متن تیکت، شدت و محصول و یک خلاصه یک‌خطی در بیاور» قرارداد است. «یک تحلیل کامل بنویس» قرارداد نیست. دومی تو را به regex برمی‌گرداند چون هیچ‌کس شکل را نام نبرده.
در TypeScript این قرارداد باید واقعی باشد
در پشته TypeScript فایده روی هم جمع می‌شود. schema قرارداد مشترک می‌شود. UI و بک‌اند هم‌تراز می‌مانند. بازنویسی امن‌تر است چون مرز مدل دیگر یک توده ساختار ضمنی نیست. حتی شکست بهتر می‌شود: خروجی نامعتبر صریح است، نه تجزیه خاموشِ غلط.
مسیر کد را عمداً خسته‌کننده نگه دار. یک Route Handler تمیز، صف وقتی کار ناهمگام است، اعتبار خروجی تایپ‌دار، و لاگ دور قدم‌های گران یا شکست‌خیز. این‌ها معمولاً از یک لایه ارکستراسیون باهوش دیگر ارزشمندترند.
نسخه اول باید بتواند صادقانه خراب شود. وضعیت جزئی روشن، خطای قابل بازیابی، و مسیر موفقیت باریک، سالم‌تر از خودمختاری قبل از استحقاق است. اگر اعتبار شکست خورد، همان را به کاربر یا به صف بازبینی بده. سعی نکن با regex دوم «نجاتش» دهی. آن نجات، باگ را به داده تولیدشده تبدیل می‌کند.
خروجی ساخت‌یافته عدم‌قطعیت را حذف نمی‌کند. آن را به شکلی درمی‌آورد که اپ بتواند تمیز هندل کند. برای همین هنوز برای شکست اعتبار، داده ناقص، و رفتار جایگزین برنامه می‌ریزم. تفاوت این است که شاخه شکست اسم دارد.
تولید را فراموش نکن
آموزش ناقص است اگر فقط مسیر خوشحال را بگوید. اگر گردش کار می‌تواند کند، گران، یا ناهماهنگ شود، قبل از اولین عرضه باید معلوم باشد این را چطور مهار می‌کنی. تکرار، مهلت، صف، سقف نرخ، معیار، و دیدن موضوع توسط پشتیبانی جزو همان طراحی‌اند نه عملیات بعدی.
سه اشتباه رایج را زیاد می‌بینم. اول، بزرگ ساختن نسخه اول. تیم انتزاع پهن می‌سازد چون فرض می‌کند کاربرد آینده لازم دارد، بعد هفته‌ها انعطافی را نگهداری می‌کند که هنوز به کسی سود نداده. دوم، تعریف نکردن موفقیت. اگر کسی نداند چه کیفیتی، چه تأخیری، و چه قابلیتی قابل قبول است، پیاده‌سازی قابل قضاوت نیست و قابلیت آرام تبدیل به هدف متحرک می‌شود. سوم، نادیده گرفتن دست‌به‌دست شدن انسانی. حتی گردش کار خودکار به نقطه بازبینی، فرض قابل دیدن، و زمینه کافی نیاز دارد تا هم‌تیمی بدون مهندسی معکوس کل سیستم دخالت کند.
چک کوتاه برای عرضه: یک کاربرد محدود با قرارداد خروجی صریح. اعتبار قبل از اینکه کد پایین‌دست به نتیجه تکیه کند. کمترین مشاهده‌پذیری برای دیدن تأخیر و شکست و هزینه همین گردش کار. کاربر واقعی فقط بعد از اینکه می‌دانی کمی خراب شدن چه شکلی است.
الگوی غلط این است که سیستم تایپ را سند بدانی و رفتار واقعی در پرامپت و توده JSON موردی زندگی کند. هرچه AI در محصول بیشتر شود، ارزشمندتر است که بخش غیر AI بی‌رحمانه روشن و قویاً تایپ‌دار بماند. بهبود پلتفرم، معماری دورش را خودکار بهتر نمی‌کند. اگر گردش کار مبهم باشد، انتشار تازه فقط راه سریع‌تری برای شلختگی است.
تست را روی قرارداد بگذار نه روی نثر
یک مجموعه کوچک ورودی واقعی، خروجی معتبر، و خروجی تقریباً معتبر داشته باش. مورد سوم مهم‌تر از دموی خوش‌مسیر است: فیلد اضافه، نوع غلط، رشته خالی جایی که عدد می‌خواهی، و حذف فیلد اجباری. تست باید قبل از رسیدن به دیتابیس یا UI بشکند. اگر تستت فقط بررسی می‌کند که مدل «چیزی برگردانده»، دوباره به دنیای regex برگشته‌ای، فقط با امید بیشتر.
نسخه schema را کنار رکورد ذخیره کن اگر خروجی را نگه می‌داری. فردا فیلد را عوض می‌کنی و رکورد دیروز نباید ناگهان نامعتبر یا بدتر، بی‌صدا جور دیگری تفسیر شود. مهاجرت داده خروجی مدل همان مهاجرت بقیه داده است، با این فرق که تولیدکننده‌اش ناپایدارتر است.
پرسش‌های کوتاه
regex را کاملاً کنار بگذارم؟ برای خراشیدن متن آزاد و ابزار داخلی کم‌اهمیت، نه. برای چیزی که صورتحساب یا وضعیت کاربر را عوض می‌کند، بله.
اگر مدل حالت JSON دارد هنوز schema لازم است؟ بله. حالت JSON شکل را پیشنهاد می‌کند. اعتبار در اپ ثابت می‌کند همان شکل وارد منطق تو شده. یکی بدون دیگری کافی نیست.
اعتبار شکست خورد، تکرار کنم؟ یک بار با بازخورد خطای اعتبار گاهی منطقی است. تکرار کور، همان خروجی بد را گران‌تر می‌خرد. بعد از سقف، شکست را نشان بده.