تصور کنید یک تیم توسعه با ده مدل مختلف از معماری سیستم دست‌وپنجه نرم می‌کند؛ جایی که مستندات چیزی می‌گویند، کد چیز دیگری اجرا می‌کند و هوش مصنوعی در میان این تضادها توهم می‌زند. این هرج‌ومرج دقیقاً همان نقطه‌ای است که NAEOS قصد دارد با معرفی NEIR (بازنمایی میانجی مهندسی NAEOS) آن را از بین ببرد. مهندسی نرم‌افزار در حال گذار از مجموعه‌ای از ابزارهای گسسته به یک خط لوله یکپارچه است که در آن، کد صرفاً یک مصنوع (Artifact) محسوب می‌شود.
به نقل از مستندات منتشر شده در ۱۰ سپتامبر ۲۰۲۶، این فناوری یک مرز معنایی ایجاد می‌کند تا «قصد» (Intent) سیستم را از «نحوه پیاده‌سازی» (Implementation) جدا کند. در جریان‌های کاری فعلی، اکثر ابزارهای کدنویسی مستقیماً بر اساس تولید کد از مشخصات (Specification-to-code) عمل می‌کنند. در این ساختارها، یک فایل YAML یا یک پرامپت به یک تولیدکننده داده می‌شود تا کد منبع را تولید کند. این روش در پروژه‌های کوچک جواب می‌دهد، اما در مقیاس صنعتی شکست می‌خورد؛ زیرا مهندسی نرم‌افزار زمانی پیچیده می‌شود که مشخصات باید چندین ماژول، سرویس، API، پایگاه‌داده، زیرساخت، الزامات امنیتی، استقرار، تست، عامل‌های هوش مصنوعی و محدودیت‌های معماری را توصیف کند.
وقتی مصرف‌کنندگان متعددی به این چرخه اضافه شوند — مانند یک تولیدکننده کد، یک تولیدکننده مستندات، یک عامل هوش مصنوعی، یک اعتبارسنج، یک تولیدکننده زیرساخت و یک تحلیل‌گر معماری — هر یک از آن‌ها باید مشخصات را به‌طور مستقل درک کنند. این امر مشکلی ایجاد می‌کند که در آن هر زیرسیستم، تفسیر خاص خود را از سیستم توسعه می‌دهد. در نهایت، تفسیر تولیدکننده کد، تفسیر اعتبارسنج و تفسیر هوش مصنوعی از یکدیگر فاصله می‌گیرند و منجر به یک کابوس مدیریتی می‌شوند که در آن مستندات یک چیز می‌گویند، اما زیرساخت چیز دیگری را اجرا می‌کند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی استانداردهای مدل‌های عامل‌محور اشاره کردیم، نبود یک منبع حقیقت واحد، بزرگ‌ترین مانع برای اتوماسیون کامل است. این ضرورت برای داشتن یک ساختار حاکم، دلیل نیاز عامل‌های هوش مصنوعی به یک «قانون اساسی مهندسی» برای مقیاس‌پذیری است تا از هرج‌ومرج در تصمیم‌گیری‌های خود جلوگیری کنند. NAEOS برای حل این مشکل، بر اساس مفهوم «سیستم‌عامل مهندسی»، از منطقی مشابه معماری کامپایلرهای سنتی استفاده می‌کند. یک کامپایلر سنتی نیازی ندارد که هر بک‌اِند (Backend) تمام زبان‌های منبع را بفهمد؛ در عوض، کد منبع قبل از هدف‌گذاری برای x86, ARM یا WASM، به یک بازنمایی میانجی (IR) تبدیل می‌شود. حالا NAEOS همین کار را با مهندسی نرم‌افزار می‌کند؛ ابتدا مشخصات مهندسی را به NEIR تبدیل می‌کند و سپس آن را به زبان‌هایی مثل Go، TypeScript یا پنجره‌های متنی (Context Windows) هوش مصنوعی می‌برد.
چرخش معنایی: قصد در برابر اجرا
NEIR یک زبان برنامه‌نویسی نیست، بلکه بازنمایی یک سیستم مهندسی است. تمرکز آن بر «قصد» معماری است، نه جزئیات کدنویسی. بر اساس مستندات NAEOS، این مدل مفاهیم کلیدی زیر را پوشش می‌دهد:
- معماری پروژه و دامنه (Project Architecture and Domain)
- ماژول‌ها و اجزا (Module and Component)
- سرویس‌ها و APIها (Service and API)
- زیرساخت و ذخیره‌سازی (Storage and Infrastructure)
- امنیت و هوش مصنوعی (Security and AI)
- متادیتای مستندات، استقرار و تست (Documentation, Deployment, and Testing Metadata)
برای مثال، یک تابع در زبان Go مانند func CreatePayment() error که منطق یک پرداخت را مدیریت می‌کند، صرفاً یک جزئیات اجرایی است. اما در NEIR، مدل مهندسی ثبت می‌شود: اینکه «سرویس پرداخت» متعلق به «دامنه پرداخت» است، یک API خاص مانند POST /payments را ارائه می‌دهد، به سرویس احراز هویت (Identity service) وابسته است، داده‌ها را در PostgreSQL ذخیره می‌کند، نیازمند احراز هویت است و باید سیاست‌های معماری خاصی را برآورده کند.
این تفکیک باعث می‌شود بتوانید زبان پیاده‌سازی را بدون تغییر در هویت مهندسی سرویس عوض کنید. یک «قصد» — مثلاً اینکه «باید یک سرویس پرداخت وجود داشته باشد که یک API HTTP ارائه دهد، نیازمند احراز هویت باشد و از PostgreSQL استفاده کند» — می‌تواند چندین پیاده‌سازی مختلف در Go، TypeScript یا Rust تولید کند. با جدا کردن قصد از اجرا، NAEOS از جفت‌شدگی شدید (Tight Coupling) ابزارهای پایین‌دستی با فرمت اصلی مشخصات جلوگیری می‌کند.
فراتر از درخت نحو (AST)
شاید بپرسید چرا یک درخت نحو (AST) — که ساختار نوشتاری یک سند را تحلیل می‌کند — کافی نیست؟ یک AST به این پرسش پاسخ می‌دهد که «سند چه گفته است؟» و ساختار نحوی ورودی را ترسیم می‌کند. برای مثال، اگر در مشخصات ذکر شده باشد services: - name: payments port: 8080، AST به ما می‌گوید که آن سند چگونه ساختار یافته است.
اما NEIR به این پرسش پاسخ می‌دهد که «سیستم مهندسی چه معنایی دارد؟». این ابزار آن نحو را به یک درک معنایی ترجمه می‌کند: نام سرویس = payments، پروتکل = HTTP، پورت = 8080، به همراه وابستگی‌ها، سیاست‌ها و اهداف استقرار آن. این تمایز معنایی است که یک IR را مفید می‌سازد.
تبدیل مستندات خام به NEIR در چهار مرحله مجزا رخ می‌دهد:
- پارسر (Parser): درک نحو اولیه ورودی.
- نرمال‌ساز (Normalizer): ایجاد بازنمایی‌های استاندارد (Canonical) برای حفظ یکپارچگی.
- حل‌کننده (Resolver): رمزگشایی روابط و ارجاعات در کل سیستم.
- NEIR: بازنمایی نهایی و حل‌شده از سیستم مهندسی.
این جداسازی باعث می‌شود کل خط لوله برای استدلال و تست، ساده‌تر شود. این فرآیند پالایش، یادآور رویکرد Multi-Pass در NAEOS است که اجازه می‌دهد بدهی‌های معماری پیش از نوشتن اولین خط کد شناسایی و حذف شوند.
مهندسی به‌مثابه یک گراف
از نظر مفهومی، NEIR مانند یک گراف مهندسی عمل می‌کند. در این ساختار، روابط به‌جای اینکه در متن پنهان باشند، به عنوان موجوداتی درجه‌یک (First-class citizens) تعریف می‌شوند و وظایف پردازش متن به پرس‌وجوهای مهندسی تبدیل می‌شوند. در یک فایل پیکربندی تخت (Flat)، روابط ضمنی هستند؛ اما در NEIR، آن‌ها صریح‌اند. برای مثال، گراف به‌طور دقیق ترسیم می‌کند که سرویس پرداخت یک API پرداخت ارائه می‌دهد، داده‌ها را در یک پایگاه‌داده پرداخت ذخیره می‌کند و روی کوبرنتیز مستقر شده است، در حالی که همزمان وابستگی خود را به سرویس احراز هویت حفظ می‌کند.
این رویکرد گراف‌محور اجازه می‌دهد پرس‌وجوهای مهندسی پیچیده‌ای اجرا شوند که با جست‌وجوی متنی ساده غیرممکن است، مانند:
- یافتن تمام سرویس‌هایی که به ماژول احراز هویت وابسته هستند.
- لیست کردن تمام APIهای ارائه شده توسط سرویس پرداخت.
- شناسایی تمام اجزایی که از PostgreSQL استفاده می‌کنند.
- یافتن تمام منابعی که یک سیاست (Policy) خاص را نقض می‌کنند.
- مکان‌یابی تمام مصنوعاتی که از یک گره خاص در مشخصات تولید شده‌اند.
این امر، اعتبارسنجی را به یک استدلال اجرایی تبدیل می‌کند. اگر معماری یک سلسله‌مراتب «دامنه $
ightarrow$ اپلیکیشن $
ightarrow$ زیرساخت» تعریف کند و لینک مستقیم از «دامنه $
ightarrow$ زیرساخت» را ممنوع کند، اعتبارسنج NAEOS می‌تواند گراف NEIR را بازرسی کند. به‌جای تکیه بر یک بازبین انسانی برای متوجه شدن تخلف، این قانون به یک ارزیابی گراف تبدیل می‌شود که نتیجه آن یا «معتبر» است یا «تخلف».
تغذیه بستر هوش مصنوعی و ردیابی
یکی از کاربردی‌ترین بخش‌های این فناوری، تولید بستر (Context) برای هوش مصنوعی است. به‌جای مدیریت دستی مجموعه‌ای عظیم از دستورالعمل‌ها — مانند READMEها، فایل‌های CLAUDE.md، .cursorrules، دستورات Copilot، یادداشت‌های توسعه‌دهنده و مستندات معماری — NAEOS بستر AI را مستقیماً از مدل مهندسی استخراج می‌کند.
با استفاده از یک «کامپایلر بستر AI»، NEIR یک منبع حقیقت واحد را به آداپتورهای مختلف برای محیط‌های کدنویسی AI می‌فرستد، از جمله:
- Claude Code
- Cursor
- GitHub Copilot
- Codex
- Gemini CLI
- سایر عامل‌های خودمختار
این یعنی تمام عامل‌های هوش مصنوعی از یک حقیقت مهندسی واحد تغذیه می‌شوند و احتمال توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد — در مورد محدودیت‌های معماری به شدت کاهش می‌یابد. ایده مهم، آداپتورهای تکی نیستند، بلکه منبع مشترک است: NEIR $
ightarrow$ مدل بستر AI $
ightarrow$ عامل‌ها.
این معماری همچنین ردیابی کامل (Traceability) را ممکن می‌سازد. در یک ساختار سنتی، فایلی مانند internal/payment/service.go فقط یک فایل است. اما در NAEOS، سیستم می‌تواند مصنوع را از طریق یک زنجیره ردیابی کند: مشخصات $
ightarrow$ NEIR $
ightarrow$ برنامه تولید $
ightarrow$ مصنوع. این به توسعه‌دهندگان اجازه می‌دهد دقیقاً بفهمند کدام گره در مشخصات، این جزء را تعریف کرده، کدام سیاست‌ها ارزیابی شده‌اند، کدام تولیدکننده کد را ساخته و از کدام نسخه مدل مهندسی استفاده شده است. این برای عیب‌یابی، حسابرسی، حاکمیت و بازتولیدپذیری حیاتی است.
بازتولیدپذیری و نقش هوش مصنوعی
بازنمایی‌های میانجی مشترک، زیربنای برتری برای بازتولیدپذیری ایجاد می‌کنند. در جریان‌های کاری استاندارد AI، فرآیند اغلب این‌گونه است: پرامپت $
ightarrow$ هوش مصنوعی $
ightarrow$ نتیجه‌ای متفاوت در فردا. NAEOS این نوسان را با یک زنجیره قطعی جایگزین می‌کند: مشخصات + شمای (Schema) + NEIR + سیاست‌ها + نسخه تولیدکننده $
ightarrow$ مصنوع مهندسی.
هوش مصنوعی همچنان می‌تواند در این فرآیند مشارکت کند، اما دیگر مجبور نیست هر بار کل بستر مهندسی را از ابتدا بازسازی کند. این امر خروجی را پایدار کرده و تضمین می‌کند که AI در چارچوب‌های مدل تثبیت‌شده عمل می‌کند.
هزینه انتزاع
البته این سطح از انتزاع رایگان نیست. طبق گزارش وب‌سایت dev.to، پیاده‌سازی یک IR چالش‌های متعددی را به همراه دارد:
- پیچیدگی شما (Schema Complexity): تعریف مدل معنایی نیازمند تلاش زیاد در مراحل اولیه است.
- منطق تبدیل (Transformation Logic): ساخت خط لوله از پارسر تا حل‌کننده، سربار ایجاد می‌کند.
- دغدغه‌های نسخه‌بندی (Versioning): مدل باید بدون شکستن مصرف‌کنندگان تکامل یابد.
- الزامات مهاجرت (Migration): انتقال از یک نسخه مدل به نسخه دیگر نیازمند ابزار است.
- اعتبارسنجی اضافی: خودِ IR نیز باید اعتبارسنجی شود.
- اجزای زمان اجرا (Runtime Components): برای اجرای خط لوله به قطعات متحرک بیشتری نیاز است.
برای پروژه‌های ساده که جریان آن‌ها صرفاً پیکربندی $
ightarrow$ قالب $
ightarrow$ کد است، یک تولیدکننده قالب ساده کافی است. اما برای سیستم‌های پیچیده با مصرف‌کنندگان متعدد، IR به یک دارایی معماری حیاتی تبدیل می‌شود.
همان‌طور که مدل تکامل می‌یابد، NAEOS باید نسخه‌بندی شما را مدیریت کند. برای مثال، اگر نسخه ۱ شامل Service، API و Database باشد، اما نسخه ۲ مفاهیمی مثل Event، SecurityPolicy و Deployment را اضافه کند، مصرف‌کنندگان به استراتژی‌های سازگاری نیاز دارند. یک IR بالغ باید سازگاری عقب‌رو و جلو‌رو، مهاجرت، اعتبارسنجی، منسوخ‌سازی (Deprecation) و مذاکره نسخه را مدیریت کند.
بازدهی معماری
با قرار دادن NEIR در مرکز، NAEOS یک مرز پایدار بین قصد انسانی و اجرای مهندسی ایجاد می‌کند. این امر اجازه می‌دهد سیستم تکامل یابد بدون اینکه هر زیرسیستم مجبور باشد هر بازنمایی را درک کند.
این موضوع NAEOS را به یک «سیستم‌عامل مهندسی» واقعی نزدیک‌تر می‌کند. همان‌طور که یک OS استاندارد مدل‌های پردازش، منابع و امنیت را فراهم می‌کند تا اپلیکیشن‌ها نیازی به درک جزئیات سخت‌افزار نداشته باشند، NAEOS موارد زیر را فراهم می‌کند:
- مدل مهندسی: بازنمایی معنایی هسته (NEIR).
- مدل سیاست: قوانینی که بر سیستم حاکم هستند.
- مدل اجرا: نحوه ساخت سیستم.
- مدل مصنوع: کد و زیرساخت حاصل.
- مدل بستر AI: حقیقت استخراج شده برای عامل‌ها.
در این چارچوب، کد یک مصنوع است و سیستم مهندسی، مدلی است که آن مصنوعات را تولید و مدیریت می‌کند. این امر نقش هوش مصنوعی را تغییر می‌دهد: AI دیگر منبع حقیقت نیست، بلکه یکی از موتورهای اجرایی است که بر اساس منبع حقیقت عمل می‌کند.
این تغییر، پرسش بنیادی توسعه AI را عوض می‌کند. هدف دیگر یافتن بهترین ابزار کدنویسی AI نیست، بلکه تعریف مدل مهندسی است که هر ابزاری باید بر اساس آن عمل کند.
در ادامه، در بخش سوم با عنوان «از مشخصات تا نرم‌افزار»، خط لوله کامپایل NAEOS را بررسی خواهیم کرد تا ببینیم چگونه این مدل معنایی به یک برنامه اجرایی، اعتبارسنجی‌شده و زمان‌بندی‌شده تبدیل می‌شود.
گفتگو