درون تجربه یک متخصص غیرفنی در اتوماسیون فرآیندهای دستی

تصور کنید کارمندی با دانش صفر در برنامه‌نویسی، تمام فرآیندهای پراکنده و خسته‌کننده گزارش هزینه‌های یک سازمان را به یک سامانه خودکار تبدیل کند. طبق گزارشی که در ۷ اکتبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این کاربر غیربرنامه‌نویس توانست با برخورد با هوش مصنوعی نه به عنوان یک تولیدکننده کد، بلکه به عنوان یک مهندس جونیور، ابزاری کاملاً عملیاتی و آماده برای محیط تولید (Production-ready) بسازد.

این اتفاق در حالی رخ می‌دهد که بسیاری از سازمان‌ها با پدیده «هوش مصنوعی سایه» (Shadow AI) و بروکراسی‌های پیچیده خرید نرم‌افزار دست‌وپنجه نرم می‌کنند. اکثر کارکنان با یک انتخاب دشوار روبرو هستند: یا باید با فرآیندهای دستیِ شکسته و ناکارآمد کنار بیایند یا ماه‌ها منتظر تأیید بخش IT برای خرید یک نرم‌افزار شخص ثالث باشند. برای این کاربر، راهکار باید رایگان، سازگار با موبایل و مستقر در اکوسیستم Google Workspace می‌بود تا بتواند بدون نیاز به طی کردن بررسی‌های امنیتی طولانی، از سد موانع اداری عبور کند.

ضرورت ساخت ابزار اختصاصی

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

علاوه بر این، ابزار ساخته شده باید سه شرط غیرقابل‌مذاکره را برآورده می‌کرد:

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

این محدودیت‌های شدید باعث شد به‌جای خرید یک محصول آماده از بازار، یک راهکار اختصاصی در محیط Workspace یا Office ساخته شود تا کاملاً با زیرساخت‌های موجود همسو باشد.

مشکل: پاک‌سازی دستی داده‌ها

پیش از ورود هوش مصنوعی، این کاربر مانند یک فیلتر انسانی برای اطلاعات تکراری عمل می‌کرد. شغل او شامل جمع‌آوری نوع مشابهی از داده‌ها از گروهی از افراد در یک بازه زمانی منظم و تبدیل آن‌ها به یک سند نهایی برای تأیید بود.

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

اولین تلاش او با استفاده از یک فرم آنلاین ساده، زمان پردازش را تقریباً ۵۰ تا ۶۶ درصد کاهش داد. اما این فرم «هوش» نداشت؛ یعنی می‌توانست داده جمع کند، اما نمی‌توانست بررسی کند که آیا یک ارسال کامل است یا خیر، و توانایی اسمبل کردن سند نهایی را نداشت. در واقع، فرم فقط توده‌ای از مواد خامِ کمی سازمان‌یافته‌تر را به کاربر تحویل می‌داد که باز هم نیاز به اسمبل و سازمان‌دهی دستی داشت.

فرآیند ساخت: هدایت به‌جای سینتکس

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

تست‌ها در تمام مراحل روی داده‌های واقعی و ارسال‌های واقعی انجام شد. مهارت اصلی در اینجا برنامه‌نویسی نبود، بلکه توانایی تعریف دقیق مفهوم «پایان کار» (Done) و رد کردن پاسخ‌هایی بود که از نظر فنی درست اما از نظر کاربردی بی‌فایده بودند.

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

عبور از سه شکست بحرانی

توسعه این ابزار خطی نبود. کاربر با سه شکست یا «گسست» خاص مواجه شد که او را مجبور کرد سیستم را مستحکم‌تر کند:

• اتلاف خاموش داده‌ها: در ابتدا، یک ارسال نشان داد که در لاگ‌ها فایلی پیوست شده است، اما آن فایل در سند نهایی وجود نداشت. مدل یک «ادعای مطمئن، مشخص و کاملاً غلط» کرده بود. این نوع توهمات مدل در محیط عملیاتی می‌تواند منجر به خطاهای فنی رایجی شود که اپلیکیشن‌های ساخته‌شده با هوش مصنوعی را در محیط تولید با شکست مواجه می‌کند. برای حل این مشکل، کاربر یک تغییر در قوانین ایجاد کرد: هیچ چیز «پیوست شده» علامت نمی‌خورد مگر اینکه سیستم ثابت کند فایل واقعاً جاسازی (Embed) شده است. اکنون هر پیوست به‌جای یک لینک یا تصویر کوچک که ممکن است منقضی شود، صفحه اختصاصی خود را دارد.
• تله سندباکس: کاربر سعی کرد صفحه‌ای همراه با لوگو و یک دکمه فراخوان (Call-to-action) بسازد. در حالی که این صفحه در دو پلتفرم مختلف زیبا به نظر می‌رسید، اما دکمه هنگام کلیک هیچ کاری انجام نمی‌داد. پس از تحقیق درباره نحوه سندباکس کردن محتوای جاسازی شده توسط پلتفرم‌ها، کاربر متوجه شد که تنها راه برای فعال نگه داشتن لینک‌ها، استفاده از بلوک‌های بومی خود پلتفرم است، نه تزریق کدهای سفارشی.
• پوسیدگی مستندات: در ابتدای کار یک راهنمای گام‌به‌گام ساخته شد، اما با بهبود ابزار، این راهنما به تصویری قدیمی تبدیل شد که «به آرامی می‌پوسید». به‌جای اصلاح دستی راهنما، کاربر فرآیند را طوری بازطراحی کرد که راهنما اکنون به‌طور خودکار و بر اساس آخرین نسخه ابزار، به‌روزرسانی و تولید شود.

نتیجه نهایی

محصول نهایی یک وب‌اپلیکیشن Google Apps Script است که کارهای سخت و تکراری را که پیش از این نیاز به دخالت انسانی داشت، انجام می‌دهد:

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

این مورد ثابت می‌کند که مانع ساخت ابزارهای داخلی دیگر سینتکس فنی نیست، بلکه توانایی ترسیم دقیق یک فرآیند تجاری است. ارزش از «چگونه کد زدن» به «چه چیزی را ساختن» (معماری فرآیند) تغییر یافته است. برای یک کارمند عادی، این یعنی توانایی حل «ناکارآمدی‌های خرد» بدون انتظار برای بودجه سازمانی. اما ریسک اینجاست که ابزارهای حیاتی ساخته شوند که سازنده اصلی در صورت تغییر منطق هوش مصنوعی، نتواند آن‌ها را نگهداری کند. این خطر شباهت زیادی به تله‌های پذیرفتنی بودن دارد که در آن عامل‌های هوش مصنوعی بدون تولید خروجی واقعی، در ظاهر در حال اجرا به نظر می‌رسند.

گام بعدی شما

• پیش از باز کردن پنجره چت با هوش مصنوعی، فرآیند شکسته خود را به صورت مجموعه‌ای از الزامات «اگر-آنگاه» (if-then) روی کاغذ ترسیم کنید.
• ابزارهای داخلی خود را در بستر اکوسیستم‌های موجود (مثل گوگل یا مایکروسافت) بسازید تا با موانع امنیتی سازمان مواجه نشوید.
• هرگز به تاییدات مدل اعتماد نکنید؛ برای هر ادعای فنی، یک مکانیسم اثبات (Proof) در کد بخواهید. این رویکرد برای جلوگیری از حلقه‌های تکرار و گزارش‌های جعلی موفقیت که در برخی آزمایشگاه‌های هوش مصنوعی مشاهده شده، حیاتی است.

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