تأیید عددی برتر از نحو؛ چرا CadQuery برای عامل‌های هوش مصنوعی کارآمدتر است

اگر امروز در حال طراحی خط لوله‌های تولید خودمختار هستید، انتخاب هستهٔ CAD شما نباید بر اساس سادگی زبان برنامه‌نویسی برای انسان باشد. مسئله اصلی این است که کدام ابزار به یک عامل (Agent) اجازه می‌دهد پیش از ارسال مدل به چاپگر، درستی ریاضی قطعه را اثبات کند. این تفاوت، شکاف حیاتی میان «درست به نظر رسیدن» در یک پیش‌نمایش و «معتبر بودن ریاضی» در یک مش (Mesh) است.

به گزارش ModelRift در ۱۲ سپتامبر ۲۰۲۶، تفاوت بنیادین میان OpenSCAD و CadQuery در نحوه شکست آن‌هاست. این یافته ثابت می‌کند که تنها راه اطمینان از عدم ارسال یک مدل سه-بعدی خراب توسط هوش مصنوعی، استفاده از تأییدات عددی است، نه تکیه بر رندرهای بصری.

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

جزئیات چیدمان آزمایش

در این آزمایش، شش عامل خودمختار مجهز به Claude Opus 5 (با پنجره بافت ۱ میلیون توکن) از طریق Claude Code به کار گرفته شدند. این عامل‌ها سه چالش با دشواری افزایونی را روی مک‌های سری M اجرا کردند. هر سلول به عنوان یک زیر-عامل general-purpose مجزا اجرا شد و هیچ ارتباطی بین آن‌ها برقرار نبود؛ به این معنا که بخشی از تفاوت در نتایج مربوط به تفاوت عملکرد عامل‌ها بود، نه لزوماً ابزارها.

برای رعایت عدالت، تیم تحقیق از نسخه‌های خاصی استفاده کرد: CadQuery 2.8.0 روی پایتون ۳.۱۴ و OpenSCAD 2026.06.12. در سمت OpenSCAD، از یک مهارت اختصاصی (openscad-skill) استفاده شد که مواردی چون نام‌گذاری فایل‌ها، حلقه‌های بازرسی-اصلاح (render-inspect-fix)، پیش‌تنظیمات دوربین و سینتکس Customizer را پوشش می‌داد. برای CadQuery، این مهارت‌ها عملیات-به-عملیات پورت شدند که مستلزم ایجاد یک رندرر کوچک offscreen و معیارهای اعتبار B-rep برای جایگزینی خط وضعیت CSG در OpenSCAD بود.

محدودیت‌های فنی و معیارهای ارزیابی

بر اساس مستندات این آزمایش، معیارهای سخت‌گیرانه‌ای برای ارزیابی تعیین شده بود:

• محدودیت عامل‌ها: هر عامل حداکثر ۱۲ نسخه برای اصلاح داشت. به آن‌ها دستور داده شده بود که هرگز موفقیت کاذب گزارش نکنند و موظف بودند هر شکست را با متن دقیق و کلمه-به-کلمه خطا گزارش کنند.
• اندازه فایل‌ها: حجم فایل‌های نهایی تقریباً یکسان بود؛ ۱۲.۴ کیلوبایت برای OpenSCAD و ۱۳.۱ کیلوبایت برای CadQuery.
• نابرابری دانش: برای CadQuery یک «برگه تقلب» (Cheatsheet) از API ارائه شد، زیرا مدل از پیش با سینتکس OpenSCAD به‌خوبی آشناست. این مورد به اصلاح سینتکس کمک کرد اما در حل مسائل هندسی تاثیری نداشت.
• تأیید مستقل: تیم تحقیق به گزارش‌های موفقیت خودِ ابزارها اعتماد نکرد. تمام فایل‌های STL نهایی از یک پارسر مستقل عبور کردند تا تعداد مثلث‌ها، جعبه احاطه (Bounding Box)، حجم، آب‌بندی (Watertightness)، لبه‌های غیرمنیفولد و مرزی، وجوه معکوس (Flipped faces) و اجزای متصل بررسی شوند.

شرح سه چالش طراحی

هر دو عامل متن یکسانی را برای هر تکلیف دریافت کردند، بدون اینکه راهنمایی خاصی درباره ابزار داده شود. قوانین طراحی برای ضخامت دیوار، تلورانس‌ها و اورهنگ‌ها (Overhangs) برای هر دو طرف یکسان بود.

• T1 (ساده): یک بست L-شکل برای نصب روی دیوار. مشخصات شامل دو صفحه با زاویه ۹۰ درجه (ضخامت ۴ میلی‌متر)، دو تقویت‌کننده مثلثی (Gussets)، دو سوراخ Countersunk (زاویه ۹۰ درجه، قطر سر ۹ میلی‌متر)، دو سوراخ ساده، گوشه‌های عمودی بیرونی R3 و یک فیلت داخلی R4 بود. قطعه باید بدون نیاز به ساپورت قابل چاپ می‌بود.
• T2 (متوسط): یک محفظه دو تکه Snap-fit برای PCB با ابعاد ۵۰ در ۲۶ میلی‌متر. مشخصات شامل دیواره‌های ۲ میلی‌متری، تلورانس حفره ۰.۴ میلی‌متر در هر طرف، چهار ستون M2، یک برش USB-C با ابعاد ۹.۵ در ۳.۵ میلی‌متر و یک درب مجزا با لبه محیطی ۰.۲ میلی‌متر و گیره‌های فعال، به همراه پنج شکاف تهویه بود. قطعات باید در عمل روی هم فیت می‌شدند.
• T3 (سخت): یک آداپتور لوله با رزوه M24x2. مشخصات شامل یک فلنج شش‌ضلعی (۳۰ میلی‌متر بین تخت‌ها)، یک رزوه هلیکال واقعی (طول ۱۲ میلی‌متر)، یک بخش خاردار (Barb) به طول ۲۵ میلی‌متر با سه خار برای لوله با قطر داخلی ۱۲ میلی‌متر و یک کانال عبوری ۸ میلی‌متری بود. استفاده از حلقه‌های روی هم (Stacked rings) صراحتاً ممنوع بود و رزوه باید هندسه هلیکال واقعی می‌داشت.

تحلیل چالش اول: بست ساده

در طراحی بست L-شکل، هر دو ابزار موفق بودند اما منطق داخلی آن‌ها متفاوت بود. OpenSCAD صرفاً یک پروفیل دو-بعدی را گرد کرد و آن را اکسترود نمود و در تنها دو نسخه به نتیجه رسید. کد از یک ماژول corner_mask() با عملیات offset() استفاده کرد تا گرد کردن گوشه‌ها را فارغ از نحوه مونتاژ مدل مدیریت کند:

module corner_mask() { translate([0, 0, -eps]) linear_extrude(vert_h + 2*eps) offset(r = corner_r) offset(delta = -corner_r) square([plate_w, horiz_d]); }

در مقابل، CadQuery در نام‌گذاری لبه‌های خاص برای فیلت کردن دچار مشکل شد. یک‌سوم زمان اجرا صرف مبارزه با خطای مبهم BRep_API: command not done شد. این پیام نه نام لبه را می‌گفت و نه شعاع را. عامل مجبور شد با روش تقسیم‌بندی دستی مشکل را پیدا کند و بفهمد که دو فیلت ۳ میلی‌متری در یک دیوار ۴ میلی‌متری جا نمی‌شوند. کد نهایی نیازمند انتخاب‌گرهای پیچیده بود:

result = result.edges("|Z").edges( BoxSelector((-WIDTH, -EPS, -EPS), (WIDTH, EPS, V_HEIGHT + EPS)) + BoxSelector((-WIDTH, H_DEPTH - EPS, -EPS), (WIDTH, H_DEPTH + EPS, V_HEIGHT + EPS)) ).fillet(R_OUTER)

تحلیل چالش دوم: محفظه Snap-fit

این تکلیف نیازمند دو قطعه (جعبه و درب) بود که با تلورانس ۰.۲ میلی‌متر روی هم قرار گیرند. هر دو عامل جعبه‌ای با ابعاد ۵۴.۸ در ۳۰.۸ در ۲۵.۰ میلی‌متر ساختند. اینجا بود که زنجیره‌های پارامتری CadQuery برتری خود را نشان دادند. چون ابعاد مشتق شده بودند و نه Hard-coded، تغییر در عمق لبه به‌طور خودکار لبه، صفحه، شکاف‌ها، شیار و خار را با هم جابه‌جا می‌کرد.

روش تأیید نیز متفاوت بود. OpenSCAD از دستورات echo برای چاپ اعداد استفاده می‌کرد تا انسان آن‌ها را بخواند، مثلاً: echo(str("cavity LxW = ", cav_l, " x ", cav_w, " (clearance/side ", pcb_clr, ")"));. اما CadQuery از دستورات assert استفاده کرد که اگر جعبه و درب تداخل داشتند، کل ساخت را متوقف می‌کرد: assert BOX.val().intersect(LID.val()).Volume() < 1e-6, "box and lid interfere".

برای یک عامل بدون نظارت، یک «کرش» یا توقف برنامه، سیگنالی مفید است؛ اما عددی که چاپ می‌شود و کسی آن را نمی‌خواند، هیچ ارزشی ندارد. OpenSCAD برای رسیدن به نتیجه به ۸ نسخه نیاز داشت، در حالی که CadQuery با ۵ نسخه موفق شد. سه نسخه از OpenSCAD صرف «بهداشت بولی» (Boolean hygiene) شد تا لبه‌های بسیار نازک (Slivers) ناشی از وجوه مماس و هم‌راستا پاک شوند.

تحلیل چالش سوم: رزوه هلیکال

سخت‌ترین تکلیف، آداپتور رزوه M24 بود. به‌طور غافلگیرکننده‌ای، OpenSCAD در سرعت و دقت تلاش اول پیروز شد و در یک نسخه و ۴۳ میلی‌ثانیه کار را تمام کرد. از آنجا که OpenSCAD عملیات Sweep ندارد، عامل رزوه را به صورت محاسبات خام رئوس و وجوه با استفاده از polyhedron با ۹۶ بخش در هر دور نوشت. عامل حتی از «تله رزوه» (جایی که دندانه‌های ISO دقیقاً یک گام را می‌پوشانند و باعث ایجاد سطوح تخت هم‌صفحه در ریشه می‌شوند) پیش‌گیری کرد و پروفیل را پایین‌تر از شعاع کوچک برد تا هلیکس به جای لمس کردن، از هسته عبور کند.

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

تنها بررسی حجم خطا را افشا کرد: قطعه ۷,۰۶۵ میلی‌متر مکعب بود در حالی که انتظار ۱۰,۳۲۳ میلی‌متر مکعب می‌رفت. بدتر اینکه قطعه خراب همچنان گزارش می‌داد valid=True و solids=1. افزایش تلورانس بولی به 1e-3 منجر به تولید جامدی با حجم منفی شد که باز هم گزارش valid=True می‌داد. این ثابت کرد که بازخورد بصری، یک کانال خطرناک برای عامل‌های هوش مصنوعی است.

خلاصه نتایج

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

• OpenSCAD: ۱۱ نسخه در مجموع، ۴۷۳ خط کد، ۲ خطای ابزاری، ۵ مورد هندسه اشتباه خاموش. زمان کل: ۲۰۶۱ ثانیه. توکن‌های مصرفی: ۲۹۷ هزار.
• CadQuery: ۱۱ نسخه در مجموع، ۵۷۳ خط کد، ۴ خطای ابزاری، ۴ مورد هندسه اشتباه خاموش. زمان کل: ۲۴۰۶ ثانیه. توکن‌های مصرفی: ۳۴۷ هزار.

حکم نهایی برای تمام ۶ فایل STL «پاک» بود، به این معنی که آب‌بند بودند، یک جزء متصل داشتند، لبه‌های غیرمنیفولد یا مرزی نداشتند و روی صفحه z=0 قرار داشتند.

تحلیل حالت‌های شکست

ModelRift یک رابطه آینه‌ای بین نحوه شکست این دو ابزار شناسایی کرد:

• CadQuery زود و با صدای بلند شکست می‌خورد. پیام‌های خطای آن اغلب ضعیف هستند، اما یک Exception باعث توقف اجرا می‌شود. مدلی که متوقف شده باشد، نمی‌تواند به‌طور تصادفی ارسال شود.
• OpenSCAD دیر و در سکوت شکست می‌خورد. می‌تواند گزارش NoError بدهد در حالی که خروجی‌های فاسد یا هندسه‌های حذف شده تولید می‌کند. در T2، در ۴۵ فراخوانی هیچ خطایی گزارش نکرد اما ستون‌های حذف شده و شکاف‌های جابه‌جا شده تولید کرد.

در دنیای تولید خودمختار، «موفقیت خاموش» گران‌ترین نوع شکست است.

قدرت پرس‌وجو (Interrogation)

CadQuery به عامل اجازه می‌دهد از هسته درباره هندسه‌ای که ساخته است سوال بپرسد. یک عامل می‌تواند زاویه یک سوراخ Countersink را با خواندن مستقیم داده‌های B-rep تأیید کند و سپس آن مشخصه را در assertهایی قرار دهد که در هر بار ساخت مجدداً اجرا شوند.

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

عملکرد و سرعت

OpenSCAD به‌طور قابل‌توجهی سریع‌تر است. زمان محاسبه مجدد هندسه ۳۰ تا ۱۰۰ برابر سریع‌تر از CadQuery بود (۱۶ میلی‌ثانیه در مقابل ۱.۹ ثانیه).

با این حال، در یک حلقه عامل که زمان استنتاج LLM در آن غالب است، این تفاوت سرعت بیشتر شبیه نویز است. این موضوع تنها برای Customizerهای زنده یا جستجوهای پارامتری گسترده تعیین‌کننده است. تنها نابرابری باقی‌مانده این بود که فایل CadQuery به یک برگه تقلب API نیاز داشت چون مدل سینتکس آن را به اندازه OpenSCAD نمی‌شناسد.

تحلیل: تغییر به سمت تأیید عددی

این بنچمارک این فرض را تغییر می‌دهد که «سینتکس بهتر» یا «کتابخانه‌های ساده‌تر» محرک‌های اصلی موفقیت AI CAD هستند. گلوگاه واقعی، «قابلیت تأیید» (Verifiability) است.

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

برای کاربر نهایی، این بدان معناست که پنجره «پیش‌نمایش» یک دروغ است. تنها حقیقت در سخت‌افزارهای تولید شده توسط AI، حسابرسی عددی مش صادر شده است. این مشابه بنچمارک Pantheon است، جایی که Codex در پیش‌نمایش‌ها قوی به نظر می‌رسید اما STLهایی با مشکلات هندسی در سقف ایوان ارسال می‌کرد.

گام‌های بعدی

ModelRift به دلیل محیط Sandbox، فرمت متنی فشرده و سرعت، همچنان از OpenSCAD استفاده می‌کند، اما در حال ادغام یک مرحله بررسی عددی جدید و یک رندرر لبه-ویژگی (Feature-edge renderer) است تا نقاط قوت تأیید CadQuery را شبیه‌سازی کند.

از آنجا که --view=edges در OpenSCAD فقط مثلث‌بندی (Triangle soup) را رسم می‌کند، ModelRift رندرری را پیاده می‌کند که خطوط محیطی را از روی زاویه بین وجوه مجاور در STL بازسازی کند. این کار تضمین می‌کند که عامل‌ها پیش‌نمایش‌هایی با خطوط واقعی قطعه دریافت کنند، نه تکه‌های مش.

دو تغییر به مهارت منتشر شده OpenSCAD بازمی‌گردد:

1. رندرر لبه-ویژگی برای بازخورد بصری بهتر از خطوط قطعه.
2. یک مرحله بررسی عددی اجباری (ضخامت دیوار، تلورانس‌ها، تداخل و حسابرسی مش) که عامل باید پیش از اعلام پایان مدل اجرا کند، بدون اینکه نظر خودِ ابزار را بپرسد.

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