‏دیزاین سیستم «آماده برای AI» یعنی چی؟

شان وویسن (Sean Voisen) تو این مقاله می‌پرسه «AI ready» بودن دیزاین سیستم دقیقاً یعنی چی. نویسنده می‌گه بیشتر تیم‌ها رفتن سراغ تاکتیک‌ها: مستندات قابل‌خوندن برای ماشین، tokenها با ساختار معنادار، AI skill، فایل llms.txt و MCP server (یعنی سروری که اطلاعات رو به مدل زبانی می‌ده). حتی چندتا leaderboard و استاندارد رقیب هم اومده، مثل Design System Doc Spec، فایل DESIGN.md گوگل و Design Data Specification ادوبی. ولی هیچ‌کدوم نمی‌گن نتیجهٔ «آماده بودن» باید چه شکلی باشه.

نویسنده یه آزمایش ذهنی می‌ذاره: مستندات رو به یه مدل خوب بده و بگو صفحهٔ تنظیمات بسازه. خروجی همهٔ قانون‌ها رو رعایت می‌کنه، کامپوننت‌ها و spacing و رنگ‌ها درستن، ولی هر طراحی ببینه می‌گه کار بدیه. به گفتهٔ اون مشکل اینه که AI رو بیرون سیستم می‌بینیم، در حالی که سؤال درست اینه که AI چقدر می‌تونه بخشی از خود سیستم باشه.

برای توضیح، نویسنده سراغ سایبرنتیک می‌ره. اول POSIWID، یعنی «هدف یه سیستم همون کاریه که واقعاً انجام می‌ده». به نظر اون دیزاین سیستم بدون آدم‌هایی که ازش استفاده می‌کنن اصلاً سیستم نیست. وقتی آدم رو با LLM عوض می‌کنی، یه قطعهٔ باربر سیستم رو عوض کردی و خروجی می‌شه «دریفت طراحیِ باورپذیر، در مقیاس، برای همیشه».

مفهوم دوم قانون Requisite Variety از اشبی (Ashby) هست، یعنی کنترل‌کننده باید حداقل به اندازهٔ آشفتگی‌هایی که باید مهار کنه تنوع رفتار داشته باشه. طراح انسانی یه کنترل‌کنندهٔ پرتنوعه؛ LLM با چندتا فایل Markdown تنوع کمتری داره. پس دو راه می‌مونه: محدود کردن تولید (قانون‌ها و context بیشتر برای کمتر کردن حالت‌های ممکن) یا کنترل خروجی (ارزیابی و حلقهٔ نقد). نویسنده می‌گه دیزاین سیستم فقط یه کف کیفیت تضمین می‌کنه و سقفش رو آدم‌ها نگه می‌دارن.

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

نکات کلیدی:

• تاکتیک‌های رایج: مستندات machine-legible، tokenها، AI skill، llms.txt و MCP server.
• استانداردهای رقیب: Design System Doc Spec، DESIGN.md گوگل، Design Data Specification ادوبی.
• دو راه مهار LLM: محدود کردن تولید با قانون‌ها، یا کنترل خروجی با ارزیابی و حلقهٔ نقد.
• تعریف نویسنده: سیستمی آماده‌ست که AI جای طراح بشینه و کف کیفیت نریزه، و تیم آگاهانه تعیین کنه کجا آدم لازمه.
• ایدهٔ design ledger ثبت خودکار تصمیم‌های طراحیه، ولی ریسک نظارت و تکرار تصمیم‌های قدیمی داره.