رویکرد Multi-Pass: حذف بدهی معماری پیش از نوشتن اولین خط کد

اگر امروز از هوش مصنوعی برای نوشتن مستندات فنی استفاده می‌کنید، احتمالاً با متونی روبه‌رو هستید که ظاهر دقیقی دارند اما در اجرا شکست می‌خورند. یک پرامپت ساده به مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به‌ندرت مشخصاتی تولید می‌کند که آماده‌ی محیط عملیاتی باشد؛ در عوض، متونی با آنتروپی بالا تولید می‌کند که فاقد سخت‌گیری‌های مهندسی است.

به نقل از راهنمای فنی منتشر شده در dev.to در ۲۳ اوت ۲۰۲۶، یک خط لوله‌ی کامپایل چندمرحله‌ای طراحی شده است تا خروجی‌های مبهم را به الزامات قطعی و آماده‌ی پیاده‌سازی تبدیل کند. اکثر توسعه‌دهندگان با AI مانند یک نویسنده مستندات برخورد می‌کنند، اما این متدولوژی، مدل را به عنوان قطعه‌ای از یک سیستم ساختاریافته می‌بیند. این تغییر دیدگاه در واقع بخشی از روند گسترده‌تری است که در آن ماهیت توسعه نرم‌افزار از کدنویسی دستی به تفویض اختیار به عامل‌های AI تغییر می‌کند.

وقتی شما یک «جریان پرداخت» (Checkout Flow) را درخواست می‌کنید، مدل معمولاً لیستی از مراحل رابط کاربری را در قالب گلوله‌های متنی (Bullet points) ارائه می‌دهد. اما طبق این گزارش، مدل‌ها تقریباً همیشه موارد بحرانی مثل تداخلات زمانی (Race Conditions) در هنگام توکن‌سازی پرداخت، یا طرح‌های اعتبارسنجی سخت‌گیرانه برای داده‌های ارسالی (Payload) و مدیریت وضعیت‌های آفلاین را نادیده می‌گیرند. این شکاف، همان لحظه‌ای است که «بدهی معماری» (Architectural Debt) ایجاد می‌شود.

تصور کنید خانه‌ای را بر اساس طرحی بسازید که فقط نوشته است «آشپزخانه اینجا باشد»، بدون اینکه لوله‌کشی یا بار الکتریکی مشخص شده باشد. شما تازه وقتی دیوارها بالا رفته‌اند، متوجه مشکل می‌شوید. در نرم‌افزار، این یعنی تصمیمات طراحی مستندنشده در میانه اسپرینت، که سرعت تیم را می‌گیرد و باگ ایجاد می‌کند. یک برنامه‌ی دقیق، پیش‌درآمد کار نیست؛ بلکه پربازده‌ترین مرحله‌ی خودِ کار است.

مشکل تولید بدون محدودیت

مشکل اصلی خروجی‌های خام، نبودِ قابلیت مدل نیست، بلکه نبودِ محدودیت است. در طراحی سیستم، تولید بدون محدودیت منجر به «انحراف» (Drift) می‌شود. اگر توسعه‌دهنده مستقیماً از اولین پیش‌نویس AI کد بزند، ناگزیر با شکاف‌هایی مواجه می‌شود که نیاز به تصمیمات لحظه‌ای و مستندنشده دارد.

تیم‌ها با محدود کردن فضای تصمیم‌گیری در مراحل اولیه، می‌توانند عوامل کلیدی یکپارچه‌سازی را شناسایی کنند و ابهامات را پیش از اختصاص منابع مهندسی حل نمایند. برای رسیدن به این هدف، فرآیند تولید باید مانند یک خط لوله‌ی کامپایل عمل کند که خروجی اولیه را در معرض اعتبارسنجی خصمانه (Adversarial Validation) قرار می‌دهد. این رویکرد با قوانین مهندسی برای تبدیل عامل‌های AI به ابزارهای قابل‌اعتماد همسو است تا ریسک خطاهای پیش‌بینی‌نشده کاهش یابد.

خط لوله‌ی پالایش سه مرحله‌ای

متدولوژی dev.to برای حل این مشکل، خروجی خام را از سه مرحله عبور می‌دهد تا از صحت فنی آن اطمینان حاصل شود:

۱. تعریف طرح‌واره ساختاری: سیستم توصیفات خام را استخراج کرده و آن‌ها را به یک JSON Schema یا اینترفیس TypeScript سخت‌گیرانه تبدیل می‌کند. این کار باعث می‌شود فیلدهای داده‌ای گمشده — مثلاً اینکه آیا آدرس صورت‌حساب اختیاری است یا خیر — پیش از رسیدن به دست برنامه نویس شناسایی شوند.

۲. نگاشت انتقال وضعیت: خط لوله هر وضعیت ممکن سیستم را ترسیم می‌کند. به‌جای یک «مسیر خوش‌بینانه» (Idle → Loading → Success)، یک ماتریس انتقال ایجاد می‌کند که تأخیر شبکه، رفتن اپلیکیشن به پس‌زمینه (Backgrounding) و وقفه‌های کاربر را محاسبه می‌کند.

۳. سنتز داستان‌های کاربر: تنها پس از تثبیت طرح‌واره و ماشین وضعیت است که AI داستان‌های کاربر را تولید می‌کند. این داستان‌ها به وضعیت‌ها و طرح‌واره‌های مشخص ارجاع می‌دهند و هرگونه حدس و گمان را از مرحله پیاده‌سازی حذف می‌کنند.

پیاده‌سازی برنامه‌نویسی شده

در سیستمی مانند Bridge، این خط لوله به‌صورت برنامه‌نویسی شده تعریف شده است. فرآیند با یک RawSpec (شامل توصیف ساده) شروع شده و توسط تابع refineSpecification که یک تابع ناهمگام (Asynchronous) است، پردازش می‌شود. این تابع سه گام اصلی را اجرا می‌کند:

• extractSchema: مدل‌های داده و مرزهای وضعیت را اعتبارسنجی می‌کند.
• mapStateTransitions: انتقال‌های گمشده و حالت‌های شکست (Failure Modes) را شناسایی می‌کند.
• generateUserStories: الزامات خوانا برای توسعه‌دهنده را به طرح‌واره تأیید شده متصل می‌کند.

خروجی نهایی (RefinedSpec) شامل یک شیء طرح‌واره بتنی، لیستی از وضعیت‌ها، آرایه‌ای از انتقال‌ها (که مبدأ 'from'، مقصد 'to' و محرک 'trigger' را تعریف می‌کند) و داستان‌های کاربر نهایی است.

تحمیل سخت‌گیری فنی

در مرحله طرح‌واره، سیستم عبارات مبهم مثل «ارسال جزئیات پرداخت» را با اینترفیس‌های دقیق جایگزین می‌کند. یک خطای رایج، استفاده از توصیفات مبهم داده‌ها است. برای یک جریان پرداخت، این یعنی تعریف یک CheckoutPayload که صراحتاً شامل موارد زیر باشد:

• cartId: یک شناسه رشته‌ای منحصربه‌فرد.
• paymentMethod: یک نوع Union که یا 'credit_card' یا 'digital_wallet' را به همراه یک توکن مشخص می‌کند.
• shippingAddress: یک شیء اجباری شامل خیابان، شهر، کد پستی و کشور.
• billingAddressSameAsShipping: یک پرچم Boolean.
• billingAddress: یک شیء اختیاری برای مواردی که آدرس صورت‌حساب با آدرس ارسال متفاوت است.

اگر خروجی اولیه AI منطق شرطی آدرس صورت‌حساب را فراموش کرده باشد، مرحله اعتبارسنجی این رابطه گمشده را تشخیص داده و مدل را مجبور به حل آن می‌کند.

نگاشت انتقال وضعیت‌ها

در مرحله ماشین وضعیت است که بحرانی‌ترین شکاف‌ها آشکار می‌شوند. اپلیکیشن‌های موبایل به‌شدت وابسته به وضعیت هستند. یک مشخصات پالایش‌شده باید تمام فضای وضعیت را با یک ماتریس انتقال پوشش دهد. برای فرآیند پرداخت، این شامل وضعیت‌هایی چون:

• Idle و ValidatingCart
• TokenizingPayment و ProcessingTransaction
• Success ، Error_Network و Error_Declined است.

با متصل کردن هر وضعیت به یک انتقال (مثل SUBMIT ، RETRY ، CANCEL ، RESOLVE یا FAIL)، توسعه‌دهنده مجبور می‌شود تصمیم بگیرد سیستم در صورت شکست تراکنش چه کند. مثلاً اگر خطای شبکه در مرحله پردازش رخ دهد، سیستم باید تصمیم بگیرد که آیا اجازه RETRY را بدهد — که بدون کلیدهای Idempotency ریسک پرداخت مضاعف دارد — یا کاربر را به جریان پشتیبانی هدایت کند.

سنتز داستان‌های کاربر اجرایی

در نهایت، داستان‌های کاربر سنتز شده به صورت اجرایی در می‌آیند. یک داستان پالایش‌شده فقط نمی‌گوید «کاربر می‌تواند دوباره تلاش کند»، بلکه وضعیت و اکشن دقیق را مشخص می‌کند.

مثال از یک داستان پالایش‌شده: «به عنوان کاربری در وضعیت Error_Network ، وقتی اکشن RETRY را فعال می‌کنم، سیستم باید تلاش کند پرداخت را با استفاده از CheckoutPayload موجود مجدداً توکن‌سازی کند، بدون اینکه من را مجبور کند آدرس ارسال را دوباره وارد کنم.»

هزینه دقت

این سطح از سخت‌گیری، اصطکاکی عمدی ایجاد می‌کند. این روش نسبت به یک پرامپت ساده، هزینه محاسباتی و زمان تنظیم اولیه بیشتری می‌طلبد. سیستم در مرحله ایده‌پردازی، ایده‌های ناقص را به‌طور مکرر به عنوان خطای اعتبارسنجی علامت‌گذاری می‌کند.

با این حال، این اصطکاک یک سرمایه‌گذاری استراتژیک است. حل یک تداخل در ماشین وضعیت یا یک فیلد داده گمشده در مرحله برنامه‌ریزی، به‌مراتب ارزان‌تر از بازنویسی (Refactor) کد React Native یا Swift در میانه اسپرینت است. با محدود کردن فضای تصمیم‌گیری در ابتدا، توسعه‌دهنده بر اساس یک نقشه پایدار اجرا می‌کند.

این چرخش، مرکز ثقل کار را از مرحله کدنویسی به مرحله برنامه‌ریزی منتقل می‌کند. در واقع، مستندات دیگر پیش‌درآمد کار نیستند، بلکه خودِ کار هستند.

برای تیم‌هایی که در حال مقیاس‌دهی ادغام AI هستند، هدف دیگر یافتن «پرامپت کامل» نیست؛ بلکه ساخت سیستمی از اعتبارسنجی است که کیفیت اولیه پرامپت را بی‌اهمیت کند.

گام بعدی شما

• به‌جای درخواست مستقیم کد، ابتدا از AI بخواهید یک JSON Schema برای داده‌های ورودی و خروجی ماژول شما طراحی کند.
• برای هر ویژگی جدید، یک ماتریس انتقال وضعیت (State Transition Matrix) رسم کنید تا حالت‌های شکست (Edge Cases) را شناسایی کنید.
• داستان‌های کاربر خود را به وضعیت‌های تعریف‌شده در ماتریس متصل کنید تا ابهام در پیاده‌سازی حذف شود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.