«جریان‌های کاری عامل‌محور»؛ راهکاری برای ساخت سریع رابط‌های سخت‌افزاری

تصور کنید سخت‌افزاری که سال‌ها در کشوی میزتان خاک می‌خورده، تنها در چند ساعت به یک ابزار کاربردی تبدیل شود. مایک کاسبرگ (Mike Kasberg) در ۲۰ اوت ۲۰۲۶ ثابت کرد که با کمک Claude و مدل‌های وزن‌باز (Open Weights) — یعنی مدل‌هایی که دستور پخت یا همان ساختار داخلی‌شان علناً منتشر شده — می‌توان بدون تسلط کامل بر کدنویسی، سخت‌افزارهای قدیمی را احیا کرد و آن‌ها را به نمونه‌های اولیه فعال تبدیل نمود.

این دستاورد در حالی رخ می‌دهد که توسعه‌دهندگان به‌شدت به سمت جریان‌های کاری عامل‌محور (Agentic) برای سخت‌افزارهای فیزیکی می‌روند. در حالی که ما پیش‌تر بررسی کردیم که چگونه زیر-عامل‌های Claude Code گاهی اوقات حجم عظیمی از توکن‌ها را مصرف می‌کنند — تا جایی که ممکن است پیش از خواندن حتی یک فایل، ۴۳۶ هزار توکن مصرف کنند — رویکرد کاسبرگ مسیری بهینه، تکرارشونده و اقتصادی برای رسیدن به موفقیت را نشان می‌دهد.

زمینه پروژه

ایده و انگیزه کاسبرگ از یک توییت توسط کاربر @steveruizok در مورد هک کردن دستگاه‌های ESP32 با استفاده از Claude نشأت گرفت. او همچنین از نظر بصری از @levelsio الهام گرفت؛ کسی که یک صفحه ساعت سفارشی کاسیو (Casio) را برای اپل واچ طراحی کرده بود.

کاسبرگ ساعت PineTime را یک یا دو سال بود که در اختیار داشت، اما دستگاه در کشوی او مانده بود؛ زیرا او زمان و انگیزه کافی برای یادگیری کدبیس پیچیده InfiniTime را نداشت. محیط کم‌ریسک یک پروژه سرگرمی (Hobby Project) به او اجازه داد تا بدون فشار ناشی از استانداردهای کدهای تولیدی (Production Code)، به‌سرعت روی ایده‌هایش آزمایش کند و آن‌ها را اصلاح نماید.

او هدف خود را ساعت PineTime قرار داد؛ دستگاهی ارزان‌قیمت که با فریم‌ور متن‌باز InfiniTime کار می‌کند. او برای پر کردن شکاف بین تولید کد توسط هوش مصنوعی و سخت‌افزار واقعی، از این ترکیب فنی استفاده کرد:

• سخت‌افزار: ساعت هوشمند PineTime (به قیمت ۲۷ دلار).
• شبیه‌ساز: InfiniSim که یک حلقه بازخورد سریع را در محیط اوبونتو فراهم می‌کرد.
• مدل‌ها: ترکیبی از Claude، Kimi K3، Kimi K2.6 و مدل‌های DeepSeek v4 (نسخه‌های Pro و Flash) از طریق پلتفرم OpenCode.

جزئیات توسعه

بر اساس گزارش کاسبرگ، فرآیند توسعه با کلون کردن مخزن InfiniSim آغاز شد که شامل یک زیر-ماژول git برای InfiniTime است. در گام اول، او از هوش مصنوعی خواست تا یک بیلد (Build) فعال و قابل اجرا ایجاد کند. او برای طراحی رابط بصری، عکسی از یک صفحه ساعت کاسیو را به عنوان مرجع به مدل داد و دستور داد کدهای یک صفحه ساعت موجود در InfiniTime را به‌عنوان نقطه شروع کپی کند تا ساختار کلی حفظ شود.

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

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

برای بهینه‌سازی سخت‌افزار محدود، او از یک روش ترکیبی استفاده کرد. او به‌جای تکیه بر المان‌های کاملاً برنامه‌نویسی شده، یک تصویر پس‌زمینه ثابت ۲۴۰ در ۲۴۰ پیکسل برای المان‌های ایستا ساخت و تنها داده‌های پویا و متغیر را به کد سپرد تا فشار روی پردازنده کاهش یابد.

محدودیت‌های سخت‌افزاری

طبق بررسی‌های فنی، این بهینه‌سازی محدودیت‌های فیزیکی دستگاه را آشکار کرد. چون ساعت نمی‌تواند کل تصویر را یک‌باره در حافظه RAM نگه دارد، داده‌ها باید به‌صورت استریم از سیستم فایل خوانده شوند. این موضوع منجر به دو گلوگاه عملکردی شد:

۱. سرعت انتقال: ارسال تصویر ۲۴۰ در ۲۴۰ از طریق بلوتوث به دستگاه حدود ۱۰ دقیقه زمان برد.
۲. نرخ نوسازی: صفحه نمایش هنگام ورق زدن توسط کاربر، ۱ تا ۲ ثانیه تأخیر در به‌روزرسانی دارد.

این تجربه نشان می‌دهد که سد ورود به دنیای سیستم‌های نهفته (Embedded Systems) برای یک علاقه‌مند معمولی در حال فروپاشی است. دیگر نیازی نیست هفته‌ها وقت صرف یادگیری یک کدبیس پیچیده مانند InfiniTime کنید تا نتیجه را روی مچ دستتان ببینید. هوش مصنوعی اکنون کدهای تکراری (Boilerplate) و حدس‌های معماری اولیه را مدیریت می‌کند و انسان در نقش ویراستار سطح بالا و مسئول کنترل کیفیت ظاهر می‌شود.

در واقع نقش توسعه‌دهنده از «نویسنده» به «کیوریتور» یا گزینش‌گر تغییر کرده است. کاسبرگ با تعریف وظایف مجزا و ارائه بازخوردهای عینی، از تله‌های مصرف بالای توکن در عامل‌های کاملاً خودگردان گریخت و در کسری از زمان معمول، به یک نمونه اولیه دست یافت.

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

گام بعدی شما

• اگر سخت‌افزار قدیمی دارید، از شبیه‌سازهای محیطی برای تست سریع کدهای تولیدشده توسط AI استفاده کنید.
• به‌جای سپردن کل پروژه به عامل‌های خودکار، از متد «اصلاح تک‌مرحله‌ای» برای کاهش خطا و هزینه توکن بهره ببرید.
• مخزن گیت‌هاب کاسبرگ و فایل AGENTS.md را برای یادگیری اشتباهات رایج در توسعه فریم‌ور مطالعه کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.