Vercel با بیش از 200 اجرای عامل، فایل عمومی design.md را منتشر کرد تا عامل‌ها و ابزارهای بیرون از کدبیس شرکت بتوانند صفحات وبی با «ظاهر و تجربه» مشابه Vercel تولید کنند، حتی بدون دسترسی مستقیم به کد داخلی.

نتایج اولیه: کاهش 57% در حالات خطا

در یک آزمایش شامل شش صفحه و سه سناریوی دسکتاپ، وقتی Codex همراه با GPT-5.5 صفحات را یک‌بار با بارگذاری design.md و یک‌بار بدون آن تولید کرد، شمارش خطاهای قطعی نشان داد وجود فایل باعث کاهش از 91 مورد خطا به 39 مورد شد — حدود 57% کاهش در این نمونه. با این حال، هر یک از شش صفحه یک خطای اساسی داشت که مانع انتشار نهایی شد؛ بنابراین فایلِ راه‌حلِ کامل برای همهٔ خطاها نیست.

مشکل اصلی: نگهداری دانش طراحی درون کدبیس

پیش از این Vercel مهارتِ «تفکر پشت طراحی محصول» را برای عامل‌هایی که داخل کدبیس کار می‌کردند منتشر کرده بود. آن رویکرد برای عامل‌های درون‌محیط مفید بود، اما عامل‌ها و ابزارهای بیرون از محیط توسعه به همان زمینهٔ طراحی دسترسی نداشتند. تلاش اولیه برای تبدیل آن دانش به یک پرامپت عمومی ساده ناکافی بود؛ زبان طراحی ذهنی و انتزاعی باعث تفسیرهای متفاوت از سوی مدل‌ها می‌شد و بخش مهمی از دانش در کدبیس باقی ماند.

معماری سه‌لایهٔ فایل design.md

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

  • راهنمای قضاوت طراحی (پرامپت اصلی): دستورالعمل‌های تصمیم‌گیری طراحی—از سلسله‌مراتب محتوا و نگارش تا تایپوگرافی و رنگ—و مشخص می‌کند چه الگوهایی مجاز نیستند.
  • شیوه‌نامهٔ سبک عمومی: قوانین مکانیکی و قابل‌استفادهٔ دوباره برای فاصله‌ها، چیدمان و رفتارهای استاندارد که از بروز تفاوت‌های نامتناسب بین خروجی‌ها جلوگیری می‌کند.
  • چرخهٔ ارزیابی: تبدیل بازخورد انسانی به به‌روزرسانی‌های فایل و تبدیل خطاهای مکانیکی به بررسی‌های قطعی که قابل اجرا و ردیابی باشند.

ابزار محلی برای ارزیابی

Vercel یک اپ محلی توسعه داد که به‌عنوان چارچوب ارزیابی عمل می‌کرد. این اپ هر دور تولید را همراه با پرامپت، ورودی‌ها، پیکربندی مدل، نسخهٔ فایل، اسکرین‌شات‌ها و بازخورد بازبین ذخیره می‌کرد. اصلاحات براساس نوع مشکل به لایهٔ مناسب هدایت می‌شد: تغییرات قضاوتی به‌صورت متن در فایل، مکانیک‌های قابل‌استفادهٔ دوباره در شیوه‌نامه، و خطاهای مکانیکی به بررسی‌های قطعیِ کدنویسی‌شده تبدیل می‌شدند.

نمونه صفحه تولیدشده با guidance فایل design.md

اتوماسیون بازخورد: design-agent و گردش‌کار Slack

برای جریان مستمر بازخورد و به‌روزرسانی، Vercel عامل «design-agent» را ساخت: با اشاره در یک رشتهٔ Slack، این عامل فایل جاری design.md را بارگذاری می‌کند، صفحهٔ درخواستی را مطابق شیوه‌نامه تولید می‌کند و سپس اسکرین‌شات کامل و آدرس صفحه را در Slack منتشر می‌کند. در پایان هفته، بازخوردها با نظرات GitHub و Figma تلفیق می‌شوند و موارد تکرارشونده به‌صورت خودکار به پیشنهاد تغییر برای بازبینی انسانی تبدیل می‌گردند.

آموخته‌های کلیدی برای توسعه‌دهندگان

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

ابعاد بزرگ‌تر: استانداردسازی دانش طراحی برای عامل‌ها

تجربهٔ Vercel نمونه‌ای روشن از تبدیل قضاوت انسانی به راهنمایی‌های قابل توزیع است. این رویکرد می‌تواند فرایند انتقال دانش طراحی بین محیط‌ها را استاندارد کند و امکان تولید خروجی‌های سازگارتر توسط عامل‌های مختلف را فراهم آورد. برای مطالعهٔ بیشتر دربارهٔ مهارت‌های مرتبط با طراحی و پرامپتینگ می‌توانید به صفحهٔ Prompt engineering در ویکی‌پدیا و سایت رسمی Vercel مراجعه کنید.

اقدامات پیشنهادی برای تیم‌ها

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

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