۷ مرحله برای جلوگیری از انحراف عامل‌های هوش مصنوعی در کدنویسی

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

توسعهٔ مستند‌محور یا SDD (Spec Driven Development) با انتقال «منبع حقیقت» از پرامپت به یک سند مشخصات رسمی، این مشکل را حل می‌کند. در حال حاضر اکثر برنامه‌نویسان به پرامپت‌های زبان طبیعی تکیه می‌کنند که ذاتاً مستعد ابهام هستند. این موضوع شکافی ایجاد می‌کند که در آن یک عامل ممکن است ساعت‌ها وقت صرف ساخت ویژگی‌ای کند که بر اساس تفسیر غلط یک پیام در Slack بوده است. در واقع، وابستگی شدید این مدل‌ها به متون توصیفی همواره به عنوان سدی در برابر مهندسی سطح تولید شناخته شده است. SDD مکانیزمی را معرفی می‌کند که در آن انسان پیش از نوشتن اولین خط کد، در چرخه حضور دارد تا این شکاف را پر کند. در این روش، سند مشخصات — و نه تفسیر عامل از یک پیام چت — به مرجع نهایی و مقتداری تبدیل می‌شود که عامل باید دقیقاً از آن پیروی کند.

به نقل از گزارشی که در ۱۰ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، گردش‌کار SDD از یک خط لولهٔ هفت‌مرحله‌ای تشکیل شده است که برای تحمیل انضباط طراحی شده است. هر مرحله با یک «دروازهٔ بازبینی انسانی» جدا شده است؛ این دروازه‌ها به عنوان مکانیسم ایمنی اصلی عمل می‌کنند تا از این اتفاق جلوگیری شود که عامل‌ها با اعتمادبه‌نفس کامل، بر اساس یک تفسیر غلط، برای سه ساعت پیش از آنکه کسی متوجه شود، در مسیر اشتباه پیش بروند.

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

خط لولهٔ هفت‌مرحله‌ای

• قانون‌گذاری (Constitution): تعیین قوانین ثابت و جاری برای پروژه. این بخش شامل کنوانسیون‌های کدنویسی، محدودیت‌ها و مواردی است که در سراسر کدبیس همیشه صادق هستند.
• مشخص کردن (Specify): تعریف دقیق نیاز واقعی. این سند باید با جزئیات کافی نوشته شود، به‌گونه‌ای که اگر دو نفر مختلف آن را بخوانند، نتیجه‌ای یکسان بسازند.
• شفاف‌سازی (Clarify): تبدیل نیازهای مبهم به معیارهای پذیرش (Acceptance Criteria) قابل تست و بدون ابهام. در اینجا است که نمادگذاری EARS (Easy Approach to Requirements Syntax) کاربرد پیدا می‌کند و تضمین می‌کند که عامل عملاً نتواند نیاز را اشتباه بخواند. این رویکرد در راستای جایگزینی دستورالعمل‌های انتزاعی با مراجع دقیق است تا کد تولیدشده از همان ابتدا آماده‌ی محیط عملیاتی باشد.
• برنامه‌ریزی (Plan): تبدیل خروجی مراحل «مشخص کردن» و «شفاف‌سازی» به یک توالی عملیاتی و واقعی از کارها.
• وظایف (Tasks): تعریف واحدهای کوچک و مجزای اجرایی که عامل (یا یک برنامه‌نویس انسان) باید آن‌ها را اجرا کند.
• پیاده‌سازی (Implement): مرحله‌ای که در آن عامل واقعاً شروع به نوشتن کد می‌کند.
• تحلیل (Analyze): یک بررسی نهایی که در آن خروجی پیش از انتشار (و نه پس از آن) در برابر سند مشخصات تأیید می‌شود. این مرحله اغلب نادیده گرفته شده یا صرفاً برای تشریفات تأیید می‌شود، اما جایی است که یک استراتژی تست خوب ارزش خود را ثابت می‌کند؛ تحلیل دستیِ تغییرات (diff) در مقایسه با تأیید رفتار واقعی بر اساس سند مشخصات، عملاً بی‌ارزش است.

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

چشم‌انداز ابزارها

تیم‌های مختلف این گردش‌کار را از طریق سطوح متفاوتی از ابزارها، از ابزارهای سبک خط فرمان گرفته تا محیط‌های یکپارچه، پیاده می‌کنند:

• GitHub Spec Kit: یک ابزار خط فرمان (CLI) متن‌باز با مجوز MIT. این ابزار با مشخصات (Specifications) به عنوان منبع حقیقت اجرایی برای عامل برخورد می‌کند. این گزینه برای تیم‌هایی که می‌خواهند مالک گردش‌کار خود باشند و در ترکیب ابزارهای CLI با تنظیمات فعلی‌شان راحت هستند، بسیار مناسب است.
• AWS Kiro: یک محیط توسعه (IDE) کامل و عامل‌محور (Agentic) که از پایه بر اساس توسعه مستند‌محور ساخته شده است. Kiro در ۷ مه ۲۰۲۶ به‌صورت عمومی در سطح بین‌المللی عرضه شد. این IDE همراه با پلن‌های تیمی، یک CLI و تست‌های مشخصات مبتنی بر ویژگی (Property-based spec testing) عرضه می‌شود. تقاضا برای این رویکرد پیش از عرضه مشهود بود؛ به‌طوری که Kiro در دوره پیش‌نمایش بیش از ۲۵۰ هزار برنامه‌نویس را جذب کرد و در ۹۰ روز منتهی به عرضه عمومی، بیش از ۱۰۰ هزار نفر در لیست انتظار ثبت‌نام کردند. Kiro برای تیم‌هایی ایده‌آل است که می‌خواهند IDE به‌طور خودکار انضباط کاری را تحمیل کند. در مواجهه با پیچیدگی‌های مخازن متعدد، ابزارهایی مانند Repospec توانسته‌اند مشکل دسترسی عامل‌ها به مخازن مجزا را حل کنند و مکمل چنین محیط‌های توسعه‌ای باشند.
• بستر دستی (Manual Context): برای پروژه‌های کوچک، یک فایل AGENTS.md خوش‌ساخت یا فایل زمینه‌ای مشابه، در ترکیب با انضباط بازبینی دستی اغلب کافی است. با این حال، این رویکرد زمانی که بیش از دو یا سه نفر روی گردش‌کارهای یک عامل کار می‌کنند، مقیاس‌پذیر نیست، زیرا فاقد مکانیسم‌های تحمیلی موجود در Kiro یا Spec Kit است.

تلهٔ مدل آبشاری (Waterfall)

با وجود مزایا، شرکت Thoughtworks در رادار فناوری خود، توسعه مستند‌محور را در حلقه «ارزیابی» (Assess) قرار داده و نه «پذیرش» (Adopt). این یک سیگنال برای «پیشروی با احتیاط» است و نه یک تأیید کامل.

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

اجرای SDD بدون بروکراسی

برای جلوگیری از تبدیل این گردش‌کار به یک بار اداری و بوروکراتیک، تیم‌ها باید استراتژی‌های زیر را به کار بگیرند:

• مقیاس‌بندی بر اساس ریسک: مراحل را مانند یک پیچ تنظیم در نظر بگیرید. یک تغییر پیش‌پاافتاده، یک خط مشخصات می‌گیرد و مستقیماً به پیاده‌سازی می‌رود. یک تغییر پرریسک یا مبهم، تمام هفت مرحله و تمام دروازه‌های بازبینی را طی می‌کند.
• قانون‌گذاری مینیمال: فایل Constitution باید کوتاه و قاطع باشد. این فایل باید حاوی قوانینی باشد که واقعاً در کارهای روزمره اجرا می‌شوند، نه لیستی از آرزوهای ایده‌آل که بعد از هفته اول نادیده گرفته می‌شوند.
• اجرای سخت‌گیرانهٔ دروازه‌ها: هرگز بازبینی انسانی را حذف نکنید. این تنها شبکه ایمنی واقعی در این گردش‌کار است. اگر دروازه بازبینی صرفاً یک اعلان در Slack باشد که کسی آن را تا صبح روز بعد نمی‌خواند، مکانیسم ایمنی عملاً از بین رفته است.
• استفاده زودهنگام از EARS: معیارهای پذیرش را دقیقاً در مراحل شفاف‌سازی و برنامه‌ریزی به سبک EARS بنویسید. این کار باعث می‌شود ابهامات پیش از آنکه عامل کد تولید کند آشکار شوند، نه در طول بازبینی Pull Request که ممکن است انسان به‌طور کامل درک نکند.

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

گام بعدی شما

• برای تسک‌های بعدی خود، به جای پرامپت طولانی، یک سند «معیارهای پذیرش» (Acceptance Criteria) کوتاه بنویسید و از عامل بخواهید ابتدا آن را تأیید کند.
• اگر از ابزارهای CLI راحت هستید، GitHub Spec Kit را برای مدیریت منبع حقیقت پروژه امتحان کنید.
• در پروژه‌های تیمی، یک فایل AGENTS.md ایجاد کنید و قوانین ثابت کدبیس را در آن متمرکز کنید.

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