توسعه مبتنی بر مشخصات (Spec-Driven Development) چیست؟

چرا وایب کدینگ برای سیستم‌های سازمانی کافی نیست؟ تولید کد دیگر گران‌ترین بخش مهندسی نرم‌افزار نیست. AI Agentها امروز می‌توانند در چند دقیقه ساختار پروژه، endpoint، تست و migration بسازند. اما همین ارزان شدنِ تولید کد، هزینه‌ی ابهام را بالا برده است: هر نکته‌ای که در صورت‌مسئله نگفته‌ایم، جایی است که مدل آن را با حدس آماری پر می‌کند.

توسعه مبتنی بر مشخصات (Spec-Driven Development یا SDD) رویکردی مهندسی برای حل این مسئله است. در این رویکرد، مشخصات پروژه دیگر صرفاً سندی تشریفاتی یا تکمیلی نیست، بلکه به مرجع اصلی تصمیم‌گیری و توسعه تبدیل می‌شود و کد بر اساس آن شکل می‌گیرد. در این مقاله، تفاوت SDD و وایب‌کدینگ، پیشینه آن در مهندسی نرم‌افزار کلاسیک، اجزای یک مشخصات اجرایی، ابزارهای موجود در سال ۲۰۲۶ و مهم‌تر از همه، محدودیت‌ها و چالش‌های خود این رویکرد را بررسی می‌کنیم.

گلوگاه توسعه نرم‌افزار تغییر کرده است!

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

اما این محدودیت از بین نرفته است؛ فقط محل آن تغییر کرده است. امروز مدل‌های زبانی می‌توانند در چند ثانیه یک کامپوننت، سرویس یا حتی ساختار اولیه‌ی یک پروژه را تولید کنند. در نتیجه، چالش اصلی به‌تدریج از پرسش «چگونه آن را بسازیم؟» به پرسش مهم‌تری منتقل می‌شود: «دقیقاً چه چیزی باید ساخته شود؟»

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

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

جدول زیر این جابه‌جایی را خلاصه می‌کند:

وایب کدینگ چیست و کجا واقعاً کار می‌کند

اصطلاح وایب کدینگ (Vibe Coding) را آندری کارپاتی در فوریه ۲۰۲۵ مطرح کرد و به سرعت به یکی از پرتکرارترین واژه‌های صنعت تبدیل شد. منظور، سبکی از کار است که در آن توسعه‌دهنده به‌جای نوشتن مشخصات یا طراحی معماری، مستقیم با مدل وارد گفت‌وگو می‌شود: هدف کلی را می‌گوید، کد تولیدشده را اجرا می‌کند، اگر ظاهراً کار کرد جلو می‌رود و اگر نکرد پرامپت بعدی را می‌دهد.

یک نکته مهم که معمولاً نادیده گرفته می‌شود این است که استفاده از هوش مصنوعی هنگام کدنویسی، لزوماً به معنای وایب کدینگ نیست. داشتن Copilot در کنار ادیتور هم به‌خودی‌خود وایب کدینگ محسوب نمی‌شود. وایب کدینگ یک الگوی فرایندی مشخص است که در آن، پرامپت جای مشخصات را می‌گیرد؛ یعنی منظور، هدف و نیازمندی‌های واقعی پروژه در هیچ‌جا به شکلی پایدار، قابل بازبینی و قابل ردیابی ثبت نمی‌شوند.

جایی که وایب کدینگ انتخاب مناسبی است:

• ساخت اثبات مفهوم (PoC) و اعتبارسنجی سریع یک ایده.
• طراحی نمونه‌ی اولیه‌ی برای ارائه به ذی‌نفعان.
• نوشتن اسکریپت‌های یک‌بارمصرف و ابزارهای داخلی، تحلیل‌های اکتشافی داده.
• شرکت درهکاتون و آموزش.
• مواردی که هنوز نمی‌دانید چه می‌خواهید و باید با دیدن، تصمیم بگیرید.

جایی که فرمول می‌شکند

مشکل از لحظه‌ای شروع می‌شود که پروژه از مرز MVP عبور می‌کند. یک آلاچیق را می‌شود بدون نقشه ساخت؛ یک برج بیست‌طبقه را نه. سامانه‌ی پرداخت، حقوق و دستمزد، پرونده‌ی سلامت الکترونیک یا سیستم بانکی جایی است که هر تصمیم کوچک می‌تواند پیامد امنیتی، مالی، حقوقی یا عملیاتی داشته باشد.

چهار نقطه‌ی شکست ساختاری در وایب کدینگ

مشکلاتی که در ادامه بررسی می‌شوند، صرفاً ایرادهای اجرایی یا خطاهایی نیستند که بتوان با چند پرامپت بهتر برطرفشان کرد. این موارد، پیامدهای ذاتی یک فرایند بداهه‌محور و فاقد مشخصات دقیق هستند؛ فرایندی که در آن، تصمیم‌های مهم به‌جای ثبت و بررسی، به مدل زبانی واگذار می‌شوند.

۱. فرضیات نانوشته Unwritten Assumptions

هیچ پرامپتی، هرچقدر هم دقیق نوشته شده باشد، نمی‌تواند تمام جزئیات یک مسئله‌ی واقعی را پوشش دهد. برای مثال، وقتی از یک مدل زبانی می‌خواهید «پرداخت را پردازش کن»، ده‌ها پرسش بی‌پاسخ باقی می‌ماند:

اگر تراکنش ناموفق شد چه اتفاقی بیفتد؟ آیا باید عملیات مجدداً انجام شود؟ تعداد تلاش‌های مجدد یا Retry چند بار است؟ فاصله‌ی زمانی میان تلاش‌ها چقدر خواهد بود؟ آیا خطا در سیستم ثبت یا Log می‌شود؟ آیا باید یک رویداد یا Event برای تیم کشف تقلب ایجاد شود؟ اگر درگاه پرداخت در زمان مشخص پاسخ نداد، وضعیت تراکنش چه خواهد بود؟

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

پیامد خطرناک این وضعیت، چیزی است که می‌توان آن را «خطای بی‌صدا» یا Silent Failure نامید.

فرض کنید دو سرویس پرداخت در دو مقطع زمانی متفاوت با کمک هوش مصنوعی توسعه داده شوند. در سرویس اول، یک تراکنش ناموفق بلافاصله سه بار تکرار می‌شود؛ اما در سرویس دوم، تلاش مجدد هر یک ساعت انجام می‌گیرد. هر دو سرویس ممکن است تمام تست‌های واحد یا Unit Tests را با موفقیت پشت سر بگذارند و هیچ‌کدام نیز دچار توقف یا Crash نشوند.

بااین‌حال، در سطح کل سامانه، رفتار پرداخت سازمان یکپارچه نیست. این نوع ناسازگاری از خطاهای آشکار خطرناک‌تر است؛ زیرا معمولاً در مرحله‌ی توسعه دیده نمی‌شود و تنها در محیط عملیاتی یا Production Environment، آن هم زیر بار واقعی سیستم، خود را نشان می‌دهد.

۲. از دست رفتن تدریجی Context پروژه (Context Erosion)

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

به بیان دیگر، «ظرفیت زمینه» با «توجه مؤثر» یا Effective Attention یکسان نیست.

با بزرگ‌ترشدن پروژه، حجم تصمیم‌های معماری، تغییرات، اصلاحات، پچ‌ها و پرامپت‌های قبلی نیز افزایش می‌یابد. حتی اگر همه این اطلاعات از نظر فنی در دسترس مدل باشند، تضمینی وجود ندارد که مدل در روز سی‌ام پروژه، یک تصمیم معماری ثبت‌شده در روز اول را همچنان با همان میزان اهمیت در نظر بگیرد.

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

مدل زبانی معمولاً بر حل مسئله‌ای تمرکز می‌کند که در همان لحظه با آن روبه‌روست؛ نه بر حفظ یکپارچگی معماری، اهداف و رفتار کل سیستم.

۳. انحراف تدریجی از معماری Architectural Drift

فرض کنید از AI Agent بخواهید قابلیت «جست‌وجوی کاربر» را به سامانه اضافه کند. سریع‌ترین راه برای تولید خروجی ممکن است اجرای مستقیم یک Query در بخش Handler باشد.

اما اگر معماری پروژه تعیین کرده باشد که تمام دسترسی‌ها به پایگاه داده باید از Repository Layer عبور کنند، اجرای مستقیم کوئری در Handler یک نقض معماری یا Architectural Violation محسوب می‌شود.

این نقض‌های معماری در ابتدا کوچک و کم‌اهمیت به نظر می‌رسند:

یک کوئری مستقیم به پایگاه داده، افزودن یک Dependency جدید برای قابلیتی محدود، استفاده از الگویی متفاوت برای نام‌گذاری یا انتخاب روشی تازه برای Error Handling.

مشکل زمانی آغاز می‌شود که این استثناهای کوچک به‌تدریج روی هم انباشته شوند. در Vibe Coding، توسعه‌دهنده ممکن است کد تولیدشده را خط‌به‌خط بررسی نکند و صرفاً پس از اطمینان از اجرای ظاهری آن، به مرحله بعد برود. به همین دلیل، تخطی‌های معماری به‌مرور تثبیت می‌شوند و به بخشی از ساختار سیستم تبدیل می‌شوند.

پیامد این وضعیت در مقیاس سازمانی کاملاً جدی است:

نگهداشت یا Maintenance دشوارتر می‌شود، فرایند Onboarding اعضای جدید زمان بیشتری می‌گیرد، Refactoring کد پرریسک‌تر می‌شود و Incident Analysis نیز پیچیدگی بیشتری پیدا می‌کند.

انحراف تدریجی از معماری معمولاً با یک تصمیم بزرگ آغاز نمی‌شود؛ بلکه نتیجه انباشته‌شدن تعداد زیادی استثنای کوچک و ظاهراً بی‌ضرر است.

۴. نبود ردیابی‌پذیری Lack of Traceability

در هر سامانه‌ی حرفه‌ای و ماندگار، باید بتوان منشأ تصمیم‌های فنی و کسب‌وکاری را مشخص کرد. برای مثال، باید پاسخ روشنی برای این پرسش‌ها وجود داشته باشد:

چرا زمان انتظار یا Timeout پنج ثانیه تعیین شده است، نه سی ثانیه؟ چرا محدودیت نرخ درخواست یا Rate Limiting براساس نشانی IP اعمال می‌شود، نه شناسه‌ی کاربر؟ این نیازمندی از کجا آمده است؟ چه کسی آن را پیشنهاد داده و چه فرد یا واحدی آن را تأیید کرده است؟

اگر یک قابلیت صرفاً از مجموعه‌ای از پرامپت‌ها، اصلاحات و وصله‌ها ساخته شده باشد، معمولاً سابقه‌ی قابل اتکایی از نیت اولیه یا Design Intent باقی نمی‌ماند.

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

در جلسه‌ی Incident Review، یا هنگام ممیزی انطباق یا Compliance Audit، جمله‌ی «مدل این‌طور نوشت» پاسخ قابل قبولی نیست.

وقتی نیت، نیازمندی و منطق تصمیم‌ها ثبت نشده باشند، نگهداشت سیستم عملاً به مهندسی معکوس یا Reverse Engineering تبدیل می‌شود. تیم باید با بررسی کد موجود حدس بزند که طراحان قبلی چه هدفی داشته‌اند؛ هدفی که ممکن است از ابتدا نیز توسط مدل و براساس یک فرض نانوشته انتخاب شده باشد.

یک نمونه‌ی ملموس: بازیابی رمز عبور

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

• توکن یک‌بارمصرف است؟ انقضا دارد؟ چند دقیقه؟
• توکن به‌صورت هش‌شده ذخیره می‌شود یا به‌شکل خام؟
• محدودیت نرخ درخواست وجود دارد؟ بر چه مبنایی؟
• لینک پس از استفاده باطل می‌شود؟ چند توکن فعال هم‌زمان مجاز است؟
• اگر ایمیل واردشده در سیستم ثبت نشده باشد، چه پیامی به کاربر نمایش داده می‌شود؟

مورد آخر از همه ظریف‌تر است. اگر سیستم در پاسخ بگوید «این ایمیل در سامانه ثبت نشده است»، مهاجم می‌تواند با آزمودن نشانی‌های مختلف، حساب‌های کاربری موجود را شناسایی کند. این نوع حمله Account Enumeration نام دارد و می‌تواند مقدمه‌ای برای حملات بعدی باشد؛ هرچند در دمو، چنین پاسخی کاملاً عادی و بی‌ضرر به نظر می‌رسد.

در رویکرد SDD، این قواعد پیش از آغاز پیاده‌سازی ثبت می‌شوند: توکن پس از ۱۵ دقیقه منقضی می‌شود؛ برای ایمیل‌های موجود و ناموجود، پاسخ یکسان و عمومی نمایش داده می‌شود؛ تعداد درخواست‌های هر کاربر و هر IP در یک بازه زمانی مشخص محدود است؛ همه درخواست‌ها برای حسابرسی لاگ می‌شوند و در صورت بروز خطای داخلی، جزئیات فنی به کاربر نمایش داده نمی‌شود. سپس وظایف اجرایی بر اساس همین مشخصات تعریف می‌شوند.

تفاوت SDD و Vibe Coding در حجم مستندات نیست، بلکه در میزان ابهام‌ها و ناگفته‌هاست. هر قاعده یا نیازی که به‌صراحت بیان نشود، فضایی برای برداشت و حدس مدل ایجاد می‌کند.

توسعه مبتنی بر مشخصات چیست؟

SDD بازگشت به مدل آبشاری نیست. بلکه چارچوبی برای هدایت و کنترل فرایند توسعه در عصر AI Agentهاست.

در رویکردهای قدیمی، مشخصات اغلب به‌صورت سندی تهیه می‌شد که پس از تأیید یا عبور از یک مرحله اداری، به‌تدریج کنار گذاشته می‌شد. اما در SDD، مشخصات، سندی به‌روز است که نیازمندی‌ها، قواعد کسب‌وکار و تصمیم‌های اصلی پروژه در آن ثبت می‌شوند و پیاده‌سازی بر اساس آن پیش می‌رود.

مقایسه‌ی دو چرخه

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

تقسیم کار میان انسان و ماشین

•  انسان: هدف، محدوده، قواعد کسب‌وکار، ملاحظات معماری، مصالحه‌ها و مرزهای پروژه را مشخص می‌کند.
•  AI Agent: بر اساس این چارچوب، راه‌حل را طراحی و با سرعت بیشتری پیاده‌سازی می‌کند.

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

وارونگی رابطه‌ی کد و مستندات

بیشتر مهندسان این تجربه را داشته‌اند: وارد تیم جدیدی می‌شوید، مستندات مرتب‌اند و دیاگرام‌ها قانع‌کننده به نظر می‌رسند؛ اما با بررسی کد متوجه می‌شوید که این اسناد وضعیت سه سال پیش سیستم را توصیف می‌کنند.

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

SDD این رابطه را تغییر می‌دهد. اگر میان کد و مشخصات ناسازگاری وجود داشته باشد، فرض اولیه این است که کد باید اصلاح شود؛ مگر اینکه تیم پس از بازبینی، آگاهانه تصمیم بگیرد مشخصات را تغییر دهد. در این رویکرد، هیچ تغییری نباید بدون ثبت و بازتاب در مشخصات وارد سیستم شود.

منطق این رویکرد را می‌توان با کامپایلر مقایسه کرد. وقتی برنامه را با یک زبان سطح بالا می‌نویسید، کد ماشین یا اسمبلی تولیدشده اهمیت دارد، اما معمولاً مستقیماً روی آن کار نمی‌کنید؛ زیرا خروجی‌ای است که از کد سطح بالاتر تولید شده است. در SDD نیز کد به‌تدریج چنین جایگاهی پیدا می‌کند: مشخصات هدف، قواعد و رفتار مورد انتظار را تعیین می‌کنند و کد بر اساس آنها تولید یا اصلاح می‌شود.

چه چیزی در SDD جدید است و چه چیزی نیست؟

بخشی از انتقادها به SDD از این تصور ناشی می‌شود که «این همان رویکردهایی است که قبلاً هم داشته‌ایم». پاسخ صادقانه این است: تا حد زیادی بله. SDD مجموعه‌ای عمل‌گرایانه از تجربه‌های چند دهه مهندسی نرم‌افزار است؛ اما نقش و وزن این اجزا را متناسب با توسعه مبتنی بر AI Agentها بازتعریف می‌کند.

SDD از چرخه توسعه نرم‌افزار یا SDLC، ایده مرحله‌بندی و کنترل در نقاط مشخص را می‌گیرد. یکی از نقدهای اصلی به مدل‌های قدیمی این بود که هر مرحله ممکن بود ماه‌ها طول بکشد و تا زمان آغاز پیاده‌سازی، نیاز بازار تغییر کرده باشد. SDD تلاش می‌کند نظم و قابلیت کنترل این فرایند را حفظ کند، بدون آنکه کندی مدل‌های سنتی را به پروژه تحمیل کند؛ زیرا با کمک AI Agentها، فاصله میان طراحی و تولید کد می‌تواند از چند ماه به چند ساعت کاهش یابد.

از PRD، ایده ثبت اهداف محصول، نیازمندی‌ها و قواعد کسب‌وکار را می‌گیرد؛ اما جایگاه آن را از سندی صرفاً راهنما به مرجعی الزام‌آور برای طراحی و پیاده‌سازی تغییر می‌دهد.

از TDD و BDD، این اصل را می‌گیرد که رفتار مورد انتظار باید پیش از تولید کد، به‌شکلی روشن و قابل ارزیابی تعریف شود. بااین‌حال، صرفاً پاس‌شدن تست‌ها کافی نیست. اگر تنها معیار موفقیت، سبزشدن تست‌ها باشد، مدل ممکن است با برگرداندن یک مقدار ثابت یا پیاده‌سازی راه‌حلی محدود که معماری سیستم را نقض می‌کند، تست را پاس کند. به همین دلیل، علاوه بر تست‌ها باید قواعد معماری، محدودیت‌های فنی و مراحل مشخصی برای بازبینی و تأیید نیز وجود داشته باشد.

از MDD، ایده تولید پیاده‌سازی بر اساس مدل را به ارث می‌برد. این ایده در گذشته با UML و مولدهای کد دنبال شد، اما اغلب به‌دلیل پیچیدگی زبان‌های مدل‌سازی، شکنندگی ابزارهای تولید کد و دشواری هماهنگ نگه‌داشتن مدل و کد به نتیجه مطلوب نرسید.

تفاوت مهم این بار، حضور AI Agentی است که می‌تواند متن نیازمندی‌ها، اسکیماها، کد موجود و توضیحات نوشته‌شده با زبان طبیعی را هم‌زمان بررسی کند و بر اساس مجموع این اطلاعات، پیاده‌سازی را تولید یا اصلاح کند.

اجزای یک مشخصات قابل اجرا

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

۱. مرزهای دامنه: چه چیزی در محدوده است و مهم‌تر چه چیزی صریحاً خارج از محدوده است. تیم‌ها معمولاً فقط «داخل محدوده» را می‌نویسند. برای AI Agent، نوشتن «خارج از محدوده» جلوی اضافه‌کاری و ساختن قابلیت‌های ناخواسته را می‌گیرد.

۲. بازیگران و سفر کاربر: چه کسی چه کاری انجام می‌دهد؟ کاربر نهایی، مدیر سیستم، سرویس بیرونی، یا کارِ زمان‌بندی‌شده؟

۳. شروط پذیرش و رفتار در شکست: نگویید «کار کند». بگویید در موفقیت، در شکست، در timeout، در ورودی نامعتبر و در نبود ورودی، دقیقاً چه باید بشود.

۴. قرارداد داده: چه فیلدهایی، با چه فرمتی، در چه منطقه‌ی زمانی؟ null مجاز است؟ ساختار پاسخ خطا چیست؟

۵. ویژگی‌های کیفی و محدودیت‌ها: امنیت، حریم خصوصی، کارایی، مشاهده‌پذیری، انطباق، دسترس‌پذیری.

EARS: نوشتن نیازمندی به‌گونه‌ای که قابل ارزیابی باشد

EARS مخفف Easy Approach to Requirements Syntax است؛ روشی که ریشه در صنعت هوافضا دارد و نیازمندی‌ها را در قالب‌های ساده و تکرارپذیر می‌نویسد. الگوی پایه:

WHEN <رویداد/شرط> THE SYSTEM SHALL <رفتار مورد انتظار>

مقایسه کنید:

ارزش واقعی EARS در سینتکس آن نیست؛ در این است که نویسنده را مجبور می‌کند درباره‌ی شرایط و رفتار مورد انتظار سیستم فکر کند. اگر نمی‌توانید نیازمندی را در این قالب بنویسید، احتمالاً هنوز خودتان آن را نفهمیده‌اید.

مرحله‌ی شفاف‌سازی

مهم‌ترین قاعده‌ی رفتاری در SDD این است: Agent نباید پیش‌فرض بگذارد، مگر اجازه داشته باشد. اگر نیازمندی ناقص است، باید متوقف شود و بپرسد.

این خلاف تمایل طبیعی مدل‌های زبانی است که برای کمک‌کنندگی بهینه شده‌اند. اما گاهی بهترین رفتار یک Agent، تولید نکردن کد و اعلام «اطلاعات کافی نیست» است.

فایده‌ی این مرحله، تبدیل حدس نامرئی به سؤال مرئی است. ابهام، دیگر چیزی نیست که زیر فرش برود؛ چیزی است که جریان کار روی آن متوقف می‌شود و تصمیمش در مشخصات ثبت می‌گردد.

حاکمیت: قوانین غیرقابل‌مذاکره‌ی مخزن

بزرگ‌ترین شکایت تیم‌ها از کد تولیدشده توسط Agent این است که «غریبه» به نظر می‌رسد: کتابخانه‌ای که پروژه ندارد، قرارداد نام‌گذاری متفاوت، مدیریت خطای دیگر، دور زدن لایه‌ی سرویس.

راه‌حل رایج، فایلی در پوشه اصلی پروژه است که قواعد غیرقابل‌مذاکره را مشخص می‌کند. در GitHub Spec Kit به آن constitution.md می‌گویند؛ در اکوسیستم Agentهای کدنویسی، قرارداد AGENTS.md (و معادل‌های اختصاصی هر ابزار) همین نقش را دارد.

📑 مشاهده سرفصل و خرید کامل‌ترین دوره از Prompt تا Production مهندسی نرم‌افزار در عصر هوش مصنوعی از نیک آموز 📑

این فایل باید فناوری‌های اصلی پروژه (Tech Stack)، ساختار پوشه‌ها، الگوی لاگ و مدیریت خطا، لایه‌ی مجاز دسترسی به داده، استراتژی تست، و قواعد افزودن Dependencyها را مشخص کند.

نکته‌ای که اغلب نادیده گرفته می‌شود، مشخص‌کردن صریح نبایدهاست. برای مدل کافی نیست فقط توضیح دهیم چه کاری باید انجام دهد؛ باید مرزها و کارهایی را که مجاز به انجامشان نیست نیز روشن کنیم:

•  لایه سرویس تحت هیچ شرایطی نباید دور زده شود.
•  روش جدیدی برای دسترسی به پایگاه داده اضافه نکن.
•  بدون تأیید صریح، هیچ Dependency جدیدی به پروژه اضافه نکن.

مرحله‌های بازبینی

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

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

ابزارها: SDD در عمل

تا اینجا بحث مفهومی بود. در سال‌های ۲۰۲۵ و ۲۰۲۶، این مفاهیم به ابزار تبدیل شده‌اند.

ابزار GitHub Spec Kit

یک جعبه‌ابزار متن‌باز که گردش کار SDD را به دستورهای مشخص تبدیل می‌کند. چرخه‌ی اصلی آن constitution ← specify ← plan ← tasks ← implement است، به‌همراه دستورهای اختیاری برای اعتبارسنجی. دو مورد از این دستورهای اختیاری از منظر بحث ما جالب‌اند:

• clarify که پیش از تولید طرح، نقاط کم‌مشخص را با پرسش‌های ساختاریافته و پیاپی آشکار می‌کند — یعنی همان «دروازه‌ی شفاف‌سازی».
• analyze که پس از تولید وظایف و پیش از پیاده‌سازی، سازگاری و پوشش را میان همه‌ی مصنوعات بررسی می‌کند.

Spec Kit با شمار زیادی از AI Agentهای کدنویسی سازگار است و روی ابزارهای مختلف قابل نصب.

محیظ AWS Kiro

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

• md — نیازمندی‌ها با نمادگذاری EARS، شامل داستان‌های کاربر و شروط پذیرش
• md — معماری، دیاگرام توالی و ملاحظات پیاده‌سازی
• md — برنامه‌ی اجرایی با وظایف قابل ردگیری

Kiro در هر مرحله منتظر تأیید شما می‌ماند و تا پیش از تأیید، به مرحله‌ی بعد نمی‌رود.

اما بااین‌حال، این ابزار با انتقاد مهمی نیز روبه‌رو شده است. فایل‌های requirements.md و design.md در ابتدای فرایند تولید می‌شوند؛ اما اگر در جریان پیاده‌سازی محدودیت‌ها یا نیازهای تازه‌ای آشکار شود، این اسناد لزوماً به‌صورت خودکار به‌روزرسانی نمی‌شوند.

در نتیجه، ممکن است به‌تدریج میان مشخصات و وضعیت واقعی پیاده‌سازی فاصله ایجاد شود؛ پدیده‌ای که به آن Specification Drift گفته می‌شود. این وضعیت می‌تواند همان مشکل آشنای مدل آبشاری را دوباره ایجاد کند: اسناد در ابتدای کار تهیه می‌شوند، اما با ادامه پروژه از واقعیت سیستم عقب می‌مانند. در بخش بعد، این نقد را دقیق‌تر بررسی می‌کنیم.

پروتکل زمینه (MCP)

Agent برای تصمیم‌گیری درست، اغلب به اطلاعاتی بیرون از کد نیاز دارد: اسکیمای پایگاه داده، لاگ، متریک، تیکت‌ها. اتصال بی‌قاعده به این منابع یک ریسک امنیتی جدی است.

 (Model Context Protocol) کانالی استاندارد و قابل ممیزی برای این اتصال فراهم می‌کند. اصل حاکم روشن است: در SDD، زمینه فقط متن مشخصات نیست؛ واقعیت‌های عملیاتی سیستم هم بخشی از زمینه‌اند اما دسترسی به آنها باید کنترل‌شده، محدود و قابل حسابرسی باشد.

راستی‌آزمایی با Property-based testing

تست‌های متعارف معمولاً بر چند مثال مشخص تکیه دارند؛ برای نمونه، اگر ورودی ۲ باشد، خروجی باید ۴ شود. این تست‌ها مفیدند، اما فقط حالت‌هایی را پوشش می‌دهند که از قبل به ذهن ما رسیده‌اند.

در Property-Based Testing، به‌جای تعریف چند ورودی و خروجی مشخص، قواعدی تعریف می‌شوند که باید برای همه ورودی‌های معتبر و در تمام شرایط برقرار بمانند:

• موجودی حساب هرگز نباید منفی شود.
• decrypt(encrypt(x)) باید همان x را برگرداند.
• پس از افزودن یک عنصر به فهرستی مرتب، فهرست باید همچنان مرتب باقی بماند.

ابزار تست سپس تعداد زیادی ورودی متنوع تولید می‌کند تا حالتی را پیدا کند که این قواعد را نقض کند؛ مانند رشته خالی، عددی بسیار بزرگ، کاراکترهای غیرمعمول، منطقه زمانی متفاوت، ایموجی، مقدار null، آرایه‌ای بسیار بزرگ یا وقوع Race Condition.

این روش با SDD هم‌راستاست؛ زیرا هر دو بر تعریف دقیق رفتار مورد انتظار سیستم تکیه دارند. اگر نتوانید قواعدی را که باید همواره در سیستم برقرار بمانند مشخص کنید، احتمالاً هنوز رفتار واقعی آن را به‌طور کامل درک نکرده‌اید.

کجا SDD هزینه‌اش از فایده بیشتر است؟

هر رویکردی که فقط با مزایایش معرفی شود، مشکوک است. انتقادهای وارد به SDD جدی‌اند:

۱. سربار برای کارهای کوچک: نوشتن مشخصات، طرح فنی و فهرست وظایف برای تغییر یک متن ساده در رابط کاربری یا رفع یک باگ جزئی، منطقی نیست و فقط فرایند را سنگین‌تر می‌کند. SDD نباید به‌صورت یک نسخه ثابت برای همه کارها اجرا شود؛ میزان جزئیات و سخت‌گیری آن باید متناسب با پیچیدگی، ریسک و ماندگاری هر تغییر باشد.

۲. فاصله‌گرفتن مشخصات از پیاده‌سازی: همان‌طور که در بخش Kiro اشاره شد، اگر اسناد فقط در ابتدای کار تولید شوند و پس از آن به‌روزرسانی نشوند، همان مشکل قدیمی مستندات منسوخ را این بار با صرف زمان و هزینه بیشتر تکرار کرده‌ایم.

برای جلوگیری از این وضعیت، هر تغییری در رفتار یا طراحی سیستم باید همراه با کد و در همان Pull Request در مشخصات نیز ثبت شود. به این ترتیب، بازبینی‌کنندگان می‌توانند هم‌زمان تغییرات کد و مستندات مربوط به آن را بررسی کنند.

۳. توهم دقت: یک مشخصات مفصل لزوماً یک مشخصات درست نیست. می‌توان صفحات زیادی نوشت و همچنان مهم‌ترین قاعده‌ی کسب‌وکار را جا انداخت. حجم سند معیار کیفیت نیست.

۴. بازگشت تدریجی به مدل آبشاری: اگر مراحل بازبینی به کمیته‌های رسمی تأیید تبدیل شوند و هر تغییر کوچک به چندین امضا نیاز داشته باشد، چابکی فرایند عملاً از بین می‌رود. این نقاط کنترل باید سبک، تا حد امکان خودکار و در اختیار خود تیم باشند؛ نه اینکه به فرایندی اداری و زمان‌بر تبدیل شوند.

۵. مسئله‌ی اکتشاف. بخشی از طراحی خوب، دیدن است. اگر مجبور باشید همه‌چیز را پیش از دیدن هر خروجی مشخص کنید، ممکن است یک راهکار بهتر را از دست بدهید.

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

SDD در پروژه‌های قدیمی و محیط واقعی سازمان

دموهای ابزارهای هوش مصنوعی معمولاً خیره‌کننده‌اند؛ زیرا یک برنامه کوچک را از صفر می‌سازند. اما بیشتر تیم‌های واقعی با کدهای قدیمی و پیچیده سروکار دارند؛ کدهایی که حاصل سال‌ها تصمیم‌گیری، محدودیت‌های تاریخی، انتخاب‌های معماری، تست‌های ناقص، مهاجرت‌های نیمه‌تمام و نیازمندی‌های ثبت‌نشده‌اند.

در چنین محیطی، یک Agent که فقط یک پرامپت دریافت می‌کند، ممکن است کدی تولید کند که به‌تنهایی درست و قابل‌قبول به نظر برسد، اما با ساختار پروژه سازگار نباشد. برای مثال، ممکن است از ORM دیگری استفاده کند، الگوی مدیریت خطای پروژه را نادیده بگیرد یا منطقی را که پیش‌تر در یکی از سرویس‌ها پیاده‌سازی شده است، دوباره بنویسد.

به همین دلیل، SDD در پروژه‌های قدیمی اهمیت بیشتری پیدا می‌کند. مشخصات و فایل قواعد پروژه می‌توانند دانش ضمنی تیم را به‌صورت روشن ثبت کنند: در این پروژه چه الگوهایی رعایت می‌شوند، کدام بخش‌های قدیمی باید حفظ شوند، انجام چه کارهایی ممنوع است و مسئولیت هر لایه چیست.

همین سازوکار می‌تواند نوسازی سامانه‌های قدیمی را نیز کنترل‌پذیرتر کند. به‌جای آنکه AI Agent آزادانه کد موجود را تغییر دهد، ابتدا هدف و دامنه تغییر ثبت می‌شود، سناریوهای پذیرش مشخص می‌شوند، برنامه مهاجرت نوشته می‌شود و پیاده‌سازی به‌صورت مرحله‌ای و همراه با بازبینی پیش می‌رود.

نکته مهم دیگر برای سازمان‌های بزرگ این است که قواعد کسب‌وکار معمولاً عمر بیشتری از فناوری‌ها دارند. برای نمونه، قاعده «فرایند بازیابی رمز عبور باید دارای محدودیت تعداد درخواست باشد» ممکن است سال‌ها معتبر بماند، صرف‌نظر از اینکه Backend با Java نوشته شده باشد یا .NET.

اگر چنین قواعدی فقط در کد فعلی پنهان مانده باشند، هر مهاجرت یا بازنویسی آینده به فرایندی دشوار برای کشف رفتار واقعی سیستم تبدیل می‌شود. بسیاری از پروژه‌های بازنویسی نیز دقیقاً به همین دلیل شکست می‌خورند: تیم نمی‌داند سامانه قدیمی واقعاً چه رفتاری داشته و کدام قواعد پنهان را اجرا می‌کرده است.

تعریف تازه‌ «انجام‌شده»

در رویکردهای رایج، «انجام‌شدن» یک قابلیت گاهی به این معناست که کد Merge شده و نسخه نمایشی نیز درست کار کرده است. جمله «مستندات را بعداً به‌روز می‌کنیم» هم اغلب به این معناست که این کار هرگز انجام نخواهد شد.

در SDD، تعریف انجام‌شدن سخت‌گیرانه‌تر است:

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

این سخت‌گیری در فرایند توسعه با AI Agentها ضروری است. وقتی ماشین می‌تواند در مدت کوتاهی حجم زیادی کد تولید کند، صرفاً اجراشدن کد معیار کافی برای موفقیت نیست؛ زیرا ممکن است پیاده‌سازی نادرستی بدون جلب توجه وارد محیط عملیاتی شود.

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

سخن پایانی توسعه مبتنی بر مشخصات

Vibe Coding ابزار نامناسبی نیست؛ بلکه برای موقعیت‌های مشخصی طراحی شده است. این رویکرد در اکتشاف، نمونه‌سازی و اعتبارسنجی سریع ایده‌ها بسیار مفید است. اما در سیستم‌هایی که قرار است سال‌ها توسعه پیدا کنند و نگه‌داری شوند، با چهار مشکل ساختاری روبه‌رو می‌شود: فرض‌های بیان‌نشده، از دست رفتن تدریجی اطلاعات و تصمیم‌های قبلی پروژه، انحراف از معماری و نبود امکان ردیابی تصمیم‌ها و تغییرات.

توسعه مبتنی بر مشخصات، پاسخی مهندسی به این مشکلات است؛ نه تلاشی برای بازگرداندن فرایندهای سنگین و اداری. اصل اساسی آن ساده است: مشخصات، قواعد و رفتار مورد انتظار سیستم را تعیین می‌کنند و کد بر اساس آنها شکل می‌گیرد. ابزارهایی مانند Spec Kit و Kiro این ایده را وارد فرایند عملی توسعه کرده‌اند؛ هرچند خود این ابزارها نیز بی‌نقص نیستند و اگر مشخصات هم‌زمان با پیاده‌سازی به‌روز نشوند، ممکن است از وضعیت واقعی سیستم عقب بمانند.

پیام اصلی این است که در شرایط جدید مهندسی نرم‌افزار، مزیت رقابتی لزوماً متعلق به تیمی نیست که سریع‌تر کد تولید می‌کند؛ بلکه به تیمی می‌رسد که مسئله را دقیق‌تر تعریف می‌کند و تصمیم‌های روشن‌تری می‌گیرد. هرچه AI Agentها سریع‌تر و توانمندتر شوند، اهمیت مشخصات نیز بیشتر می‌شود. بدون مشخصات روشن، سرعت فقط باعث می‌شود خطا و بی‌نظمی سریع‌تر گسترش پیدا کند؛ اما با مشخصات دقیق، همین سرعت می‌تواند به تولید نرم‌افزاری قابل‌اعتماد، قابل‌نگه‌داری و هم‌راستا با نیاز واقعی پروژه منجر شود.

پرسش‌های متداول توسعه مبتنی بر مشخصات

توسعه مبتنی بر مشخصات دقیقاً چیست؟

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

آیا SDD همان مدل آبشاری است؟

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

آیا برای هر تغییری باید مشخصات نوشته شود؟

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

EARS چیست؟

EARS قالبی ساختاریافته برای نوشتن نیازمندی‌ها با زبان طبیعی است. یکی از الگوهای رایج آن چنین است: وقتی <شرط> رخ می‌دهد، سیستم باید <رفتار> را انجام دهد.

هدف EARS این است که شرایط و رفتار مورد انتظار سیستم را روشن‌تر کند، ابهام را کاهش دهد و نیازمندی‌ها را قابل‌آزمون سازد.

تفاوت SDD و TDD در چیست؟

در TDD، رفتار مورد انتظار سیستم ابتدا در قالب تست تعریف می‌شود و سپس کد برای پاس‌کردن آن تست نوشته می‌شود. تمرکز اصلی این رویکرد بر رفتار قابل‌اجرا و قابل‌آزمون است.

SDD دامنه گسترده‌تری دارد. علاوه بر رفتار سیستم، محدوده مسئله، قواعد کسب‌وکار، قراردادهای داده، محدودیت‌های معماری و ویژگی‌های کیفی مانند امنیت، کارایی و قابلیت اطمینان را نیز دربر می‌گیرد. در SDD، تست یکی از ابزارهای تأیید مشخصات است، نه تمام آن.

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