تصور کنید بخواهید از ساخت اپلیکیشنهای سادهای که فقط دادهها را ذخیره و نمایش میدهند (CRUD)، به خلق یک روایت سینمایی سه-بعدی جهش کنید؛ پروژه Loupe دقیقاً نقشه راه این مسیر است. این موزه دیجیتال تعاملی که در ۶ سپتامبر ۲۰۲۶ منتشر شد، اکتشافات علمی را به ابزاری لمسپذیر تبدیل کرده است و نکته شگفتانگیز این است که تمام آن را یک توسعهدهنده تنها با کمک عاملهای کدنویسی هوش مصنوعی ساخته است.
ساخت چنین تجربهای فراتر از نوشتن چند پرامپت ساده است و نیازمند هماهنگی دقیق میان گرافیک و وضعیتهای برنامه است. همانطور که در تحلیل قبلی ما دربارهی نشانگذاری (watermarking) در مدلهای آنتروپیک اشاره کردیم، تمرکز بر شفافیت بود، اما Loupe کاربرد عملی این مدلها را در مهندسی نرمافزارهای پیچیده به رخ میکشد. برای اکثر برنامهنویسان، فاصله بین یک صفحه وب معمولی و یک محیط سه-بعدی، یک مسیر دشوار از یادگیری جبر خطی و بهینهسازی GPU است.
معماری فنی
به نقل از گزارش dev.to، موزه Loupe بر پایه پشتهای مدرن از React بنا شده تا رندرینگ (Rendering) — یعنی همان فرآیند تبدیل کد به تصویر قابل مشاهده، شبیه به نقاشی لحظهای یک تابلو توسط هنرمند — در مرورگر با بالاترین سرعت رخ دهد. زیرساخت اصلی شامل موارد زیر است:
- Next.js و TypeScript برای مسیریابی، ساختار اپلیکیشن و قراردادهای تایپشده (Typed Contracts).
- Three.js و React Three Fiber به عنوان موتور سه-بعدی مبتنی بر مرورگر.
- Drei برای بارگذاری مدلها، کنترلهای مدار (Orbit Controls) و ابزارهای کمکی صحنه.
- GSAP برای ابزارهای انیمیشن سینمایی.
- Zustand برای مدیریت وضعیتهای مشترک نمایشگاهها.
- Vitest و Playwright برای تأیید خودکار عملکرد.
- Vercel برای میزبانی و استقرار.
تفکیک مسئولیتها
معماری این پروژه بهگونهای طراحی شده که رابط کاربری (Interface) از رندرکننده (Renderer) جدا باشد. رابط کاربری تصمیمات گسسته مثل انتخاب یک جهان، باز کردن یک پنل یا تغییر حالت نمایش را مدیریت میکند. در مقابل، رندرکننده تغییرات پیوسته مانند حرکت دوربین، چرخش اشیا و انیمیشن ذرات را بر عهده دارد. این جداسازی برای حفظ عملکرد و قابلیت نگهداری کد در بلندمدت حیاتی است.
مهندسی نمایشگاهها
این موزه یک اپلیکیشن واحد نیست، بلکه مجموعهای از مدلهای تعاملی متفاوت است. توسعهدهنده تصمیم گرفت هر نمایشگاه متناسب با موضوعش رفتار کند؛ زیرا از نظر او، یک سیاره و یک فرود ماه نباید مانند یک صفحه وب با داراییهای متفاوت رفتار کنند، بلکه باید مدلهای تعاملی متفاوتی داشته باشند.
- Atlas of Worlds: امکان گشتوگذار در سیارات و مقایسه ویژگیهای آنها را فراهم میکند. چالش مهندسی در اینجا مدیریت بافتها (Textures)، جهتگیری دوربین، حالتهای مشاهده و وضعیتهای برنامه بود.
- The Engine Is a River: بررسی یک موتور توربوفن و ایستگاههای جریان آن. این بخش نیازمند حل مسائل مربوط به بارگذاری مدلها، ذرات، شیدرهای گرافیکی و توضیحات متصل به هر بخش بود.
- Thirteen Minutes: روایتی از فرود موتوردار آپولو ۱۱ که بر پیشروی اسکرول، وضعیت صحنه و زمانبندی روایت تمرکز دارد.
- Becoming Human: سفری سینمایی در تکامل انسان که نیازمند توالی محتوایی و تداوم بصری بود.
- Dinosaurs, Reconsidered: بررسی نمونههای فسیلی و شواهد علمی که شامل آمادهسازی داراییها، یادداشتهای تعاملی و جابجایی بین مدلها میشد.
ساختار نمایشگاهها به مثابه اپلیکیشن
هر نمایشگاه تعاملی پیچیدهتر از یک کامپوننت ساده است. برای مدیریت این پیچیدگی، توسعهدهنده مخزن کد را با استفاده از مدل «Atlas of Worlds»، به سه لایه گسترده تقسیم کرد:
- لایه محتوا (Content Layer): فایلهایی مانند
atlas.ts،atlas-assets.tsوatlas-asset-licenses.jsonکه جهانها، داراییها، ویژگیها و توضیحات علمی را توصیف میکنند. - لایه منطق (Logic Layer): فایلهایی مانند
atlas-schema.ts،atlas-store.ts،atlas-scale.tsوworld-focus.tsکه محاسبات، انتقال وضعیتها، سیاستهای مقایسهای و رفتار تمرکز (Focus) را مدیریت میکنند. - لایه کامپوننت (Component Layer): فایلهایی مانند
AtlasExperience.tsx،AtlasStage.tsx،AtlasCanvas.tsxوAtlasFallback.tsxکه منطق را به تجربه بصری تبدیل میکنند.
این تفکیک باعث میشود تغییر یک توضیح علمی نیازمند دستکاری در کدهای دوربین نباشد. همچنین این ساختار برای انسانها و عاملهای هوش مصنوعی، مسائل کوچکتر و شفافتری برای حل کردن ایجاد میکند.
بررسی عمیق: خط لوله رندرینگ
در نمایشگاه Atlas of Worlds، برنامه از هندسه رویهای (Procedural Geometry) و بافتهای سطحی استفاده میکند. برای یک جهان تقریباً کروی، یک کره شکل پایه را فراهم میکند، اما جزئیات از طریق نگاشت بافت (Texture Mapping)، نورپردازی، قاببندی دوربین و تنظیمات متریال سطح ایجاد میشود. هدف این است که توان پردازشی رندرینگ فقط جایی صرف شود که بازدیدکننده بتواند آن را درک کند.
برای حفظ سرعت، رندرکننده نرخ پیکسلهای دستگاه (Device Pixel Ratio) را محدود میکند. این کار هزینههای رندرینگ را در نمایشگرهای با تراکم پیکسلی بالا کاهش میدهد، زیرا کانواس باید هر پیکسل رندر شده را رنگآمیزی (Shade) کند. یک تغییر کوچک در رزولوشن میتواند فشار روی واحد پردازش گرافیکی (GPU) — که مثل موتورخانهٔ گرافیکی سیستم است — را بهشدت تغییر دهد.
در نمایشگاه موتور توربوفن، توسعهدهنده از شیدرهای سفارشی برای بصریسازی جریان هوا استفاده کرد. ذرات جریان هوا دارای ویژگیهای خاصی هستند: فاز، زاویه، شعاع و سرعت. یک شیدر از این ویژگیها، زمان و پارامترهای موتور برای محاسبه موقعیتها و رنگها استفاده میکند. این کار مانع از ارسال هزاران بهروزرسانی موقعیت تکتک ذرات از طریق React میشود که در غیر این صورت باعث کرش کردن مرورگر میشد.
بصریسازی مبتنی بر شیدر
در اینجا بصریسازی بیشتر یک مدل توضیحی است تا یک شبیهسازی زنده. جزئیات کلیدی پیادهسازی عبارتند از:
- تعداد ذرات پویا: سیستم تعداد ذرات را بر اساس عرض کانواس تغییر میدهد. برای مثال، جریان بایپس در یک چیدمان عریضتر، ذرات بیشتری نسبت به یک چیدمان باریک دارد.
- تعادل عملکرد: با محاسبه موقعیتها در سطح شیدر، رندرکننده در نمایشگرهای کوچکتر کار کمتری انجام میدهد در حالی که رابطه جریان هوا حفظ میشود.
- محدودیتهای مفهومی: طراحی بصری بهگونهای مهندسی شده است که کاربر تصور نکند با تلهمتری زنده یا یک شبیهسازی دینامیک سیالات (CFD) محاسباتی طرف است.
کنترل روایت و وضعیت
در نمایشگاه آپولو ۱۱، تعامل با پیشروی اسکرول هدایت میشود. معماری برنامه، تفسیر موقعیت اسکرول را از اجرای وضعیت صحنه و حرکت دوربین جدا کرده است.
توسعهدهنده تابعی خاص به نام centeredBeatIndex ساخت تا تشخیص دهد کدام بخش از روایت در حال حاضر در مرکز دید (Viewport) کاربر قرار دارد:
export function centeredBeatIndex(
bounds: ReadonlyArray<{ top: number; bottom: number }>,
viewportHeight: number,
) {
const center = viewportHeight / 2;
const index = bounds.findIndex(
({ top, bottom }) => top <= center && bottom > center,
);
return index >= 0 ? index : null;
}
از آنجا که این تابع فقط اندازهها را میگیرد و یک شاخص (Index) برمیگرداند، میتوان آن را بدون نیاز به اجرای صحنه سه-بعدی تست کرد. این کار کمک میکند بفهمیم یک انیمیشن اشتباه، ناشی از تفسیر غلط اسکرول است، یا خطایی در پیشروی صحنه یا درونیابی دوربین رخ داده است.
مدیریت تغییر وضعیتها
سختترین بخش تجربه کاربری، مدیریت تغییر وضعیتهاست. وقتی کاربر سیارهای جدید را انتخاب میکند، Zustand بهطور همزمان حالت مشاهده، ویژگیهای فعال، راهنمای میدانی، پیشفرضهای نورپردازی و جهت دوربین را بهروز میکند.
تغییر جهان، حالت مشاهده را به پیشفرض آن جهان برمیگرداند و نقاط حساس (Hotspots) انتخاب شده را پاک میکند. این کار از ایجاد «وضعیتهای متناقض» — مثلاً دیدن ویژگیهای مریخ در حالی که کره زمین نمایش داده میشود — جلوگیری میکند. علاوه بر این، دستورات دوربین دارای یک شماره توالی (Sequence Number) هستند تا اطمینان حاصل شود که اقدامات تکراری — مانند دو بار فشار دادن دکمه Reset — به عنوان دستورات مجزا شناسایی شوند.
انیمیشن خارج از چرخه React
برای تضمین حرکت نرم، انیمیشنهای پیوسته از چرخه بهروزرسانی React خارج شدهاند. پروژه از رفرنسها و useFrame در React Three Fiber استفاده میکند تا اشیا را مستقیماً بهروز کند.
برای مثال، چرخش یک مش (Mesh) با استفاده از مقدار delta بهروز میشود: mesh.current.rotation.y += delta * rotationSpeed. استفاده از delta تضمین میکند که حرکت به زمان سپری شده وابسته باشد نه به نرخ فریم، تا سرعت در تمام دستگاهها یکسان بماند. در نمایشگاه موتور، حرکت خودکار دوربین به محض اینکه بازدیدکننده از کنترلهای مدار (Orbit Controls) استفاده کند، متوقف میشود تا دوربین به ورودی کاربر احترام بگذارد.
نقش عاملهای هوش مصنوعی
Claude و Codex در اینجا صرفاً ابزارهای تکمیل خودکار کد نبودند، بلکه به عنوان عاملهایی عمل کردند که میتوانستند در کل مخزن کد استدلال کنند. این رویکرد در واقع همان تحولی است که در یکپارچهسازی طراحی بصری و محیط ترمینال توسط Claude Code مشاهده کردیم، جایی که مرز بین کدنویسی و طراحی کمرنگ میشود. طبق تجربه توسعهدهنده، بزرگترین مزیت آنها توانایی ردیابی باگهایی بود که چندین فایل مختلف (از لودر گرفته تا کامپوننت صحنه، استور وضعیت و مرزهای Fallback) را بهطور همزمان درگیر میکردند.
برای رسیدن به بهترین نتیجه، یک چرخه بازخورد دقیق به کار گرفته شد:
۱. تعریف دقیق تجربه مورد نظر بازدیدکننده (مثلاً: «انتخاب یک ویژگی باید آن را در دید قرار دهد در حالی که کنترلهای دستی مدار حفظ شوند»).
۲. ارائه بستر (Context) مربوطه به عامل و درخواست بررسی تبدیل مختصات و رفتار تمرکز.
۳. اجرای تغییرات در یک محدوده محدود و مشخص.
۴. گزارش شکستهای خاص و اصلاح مجدد.
عملکرد و تأیید
یکی از چالشهای بزرگ، تجربه «اولین رندر» بود. در نمایشگاه دایناسورها، توسعهدهنده متوجه یک پرش بصری شد که در آن ابتدا یک تصویر ثابت و سپس مدل تعاملی ظاهر میشد. این موضوع نیاز به پیشبارگذاری (Preloading) گزینشی را برای تعادل بین هزینههای پهنای باند و تداوم بصری نشان داد. توسعهدهنده اشاره کرد که زمان دانلود، رمزگشایی، آمادهسازی GPU و تحویل بصری، همگی در عملکرد درکشده توسط کاربر نقش دارند.
تأیید نهایی از طریق ترکیبی از تستهای خودکار (با Vitest و Playwright) و استانداردهای کیفی صریح ذخیره شده در مخزن انجام شد. این استانداردها سوالات حیاتی میپرسیدند:
- بازدیدکننده باید چه چیزی را درک کند؟
- آیا هر کنترل رفتار معناداری دارد؟
- آیا منابع و محدودیتهای بازسازی مدلها قابل مشاهده هستند؟
- در صورت شکست در بارگذاری یک دارایی، تجربه کاربر چگونه خواهد بود؟
این رفتارها تضمین میکنند که موزه خارج از یک محیط ایدهآل دسکتاپ نیز کار کند، از جمله بررسی در دسترس بودن WebGL، تنظیمات کاهش حرکت (Reduced Motion) و حالتهای کاهش مصرف داده. تجربه آپولو بهطور خاص نزدیکی Viewport و حالتهای داده محدود را در نظر میگیرد.
تحلیل: تغییر در توسعه با کمک هوش مصنوعی
پروژه Loupe نشاندهنده تغییری بنیادین در نحوه نگاه ما به ابزارهای کدنویسی هوش مصنوعی است. ما در حال حرکت از «تولید تکه-کد» (Snippet Generation) به سمت «کمک معماری» (Architectural Assistance) هستیم. این تغییر پارادایم، سه رکن اصلی تبدیل سریع ایدهها به محصول را در معماریهای جدید هوش مصنوعی به چالش میکشد تا سرعت اجرا را افزایش دهد. توانایی یک عامل در درک رابطه بین یک استور Zustand و یک حلقه رندر Three.js، بار شناختی لازم برای جابجایی بین رشتههای فنی متفاوت را کاهش میدهد.
برای یک توسعهدهنده مستقل، این بدان معناست که سد ورود به دنیای کدنویسی خلاقانه سطح بالا فرو ریخته است. شما دیگر برای ساخت یک شبیهسازی سه-بعدی دقیق علمی، نیازی به یک مهندس گرافیک اختصاصی ندارید؛ بلکه به یک طراح محصول نیاز دارید که بداند چگونه یک عامل هوش مصنوعی را از طریق یک ماشین وضعیت (State Machine) پیچیده هدایت کند. این وضعیت جدید، بحثهای عمیقتری را درباره تضاد میان «چه بسازیم» و «چگونه بسازیم» در عصر ابزارهای کدنویسی سریع ایجاد کرده است.
برای مشاهده این اصول در عمل، میتوانید صفحه اصلی Loupe را بررسی کرده و کنترلهای دوربین را روی دستگاه خود آزمایش کنید تا ببینید بهینهسازیهای GPU چگونه عمل میکنند.
گام بعدی شما
- اگر توسعهدهنده هستید، سعی کنید به جای درخواست تکه-کد، «تجربه نهایی کاربر» را برای عامل تعریف کنید و از او بخواهید ارتباط بین لایههای مختلف کد را تحلیل کند.
- برای بهینهسازی برنامههای گرافیکی، مدیریت رندرینگ را از چرخه بهروزرسانیهای اصلی فریمورک (مانند React) جدا کنید.
- از ابزارهای تست بدون نیاز به محیط گرافیکی (Headless Testing) برای جداسازی منطق ریاضی از نمایش بصری استفاده کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو