تا حالا پیش آمده که یک کلمه کلیدی به هوش مصنوعی بدهید و در جواب، یک مقاله خشک، بی‌روح و پر از کلیشه‌های تکراری تحویل بگیرید؟ دلیل این اتفاق ضعف هوش مصنوعی نیست؛ بلکه نبود یک «نقشه راه» دقیق است. وقتی ما به عنوان انسان می‌خواهیم یک مقاله استاندارد بنویسیم، اول تحقیق کلمات کلیدی انجام می‌دهیم، بعد مقالات رقبا را در صفحه اول گوگل بررسی می‌کنیم، تیترهایشان را استخراج می‌کنیم و در نهایت بر اساس این داده‌ها، یک ساختار محتوایی یا بریف (Brief) می‌نویسیم. هوش مصنوعی هم دقیقاً به همین مسیر نیاز دارد.

برای اینکه بتوانیم تولید محتوا را از یک کار دستی و زمان‌بر به یک سیستم خودکار و هوشمند تبدیل کنیم، باید یک خط تولید (Workflow) بسازیم. خط تولیدی که خودش بگردد، تحلیل کند و در نهایت بنویسد.

معماری یک نویسنده خودکار

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

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

حالا چالش اصلی اینجاست: چگونه این مغزهای کوچک را به هم متصل کنیم تا یک خروجی نهایی و یکپارچه به ما بدهند؟

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

چرا بریف‌ها را با کد می‌نویسیم، نه با هوش مصنوعی؟

شاید ساده‌ترین کار این به نظر برسد که تمام اطلاعات استخراج شده از رقبا را به یک مدل زبانی (LLM) بدهیم و بگوییم: «برای من یک بریف محتوایی بنویس». اما در پروژه‌های واقعی و تجاری، ما معمولاً این کار را نمی‌کنیم.

ما ساختار اولیه بریف را با کدهای ساده (مثل جاوا اسکریپت) در دل جریان کاری خودمان می‌سازیم. این کار دو مزیت بزرگ دارد:

  • کاهش هزینه‌ها: هر بار که به هوش مصنوعی درخواستی می‌فرستیم، باید هزینه توکن‌های آن را بپردازیم. حذف یک مرحله پردازش میانی، هزینه‌های سیستم شما را به شدت کاهش می‌دهد.
  • کنترل کیفیت: وقتی خروجی نهایی مقاله خراب می‌شود، اگر بریف را هم هوش مصنوعی نوشته باشد، پیدا کردن مقصر سخت است! اما وقتی بریف با یک منطقِ کدنویسی شده و ثابت تولید شود، شما دقیقاً می‌دانید که مشکل از سمت نویسنده (LLM) است و می‌توانید فقط روی بهبود دستورات نهایی تمرکز کنید.

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

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

  • سیستم پرامپت (System Prompt): اینجا قوانین بازی را مشخص می‌کنید. به هوش مصنوعی می‌گویید: «تو یک نویسنده ارشد سئو هستی. لحن تو باید صمیمی و روان باشد. از جملات کوتاه استفاده کن و استانداردهای نگارشی را رعایت کن.» این بخش، هویت و چارچوب را می‌سازد.
  • یوزر پرامپت (User Prompt): اینجا دیتای متغیر را می‌دهید. یعنی کلمه کلیدی هدف، تیترهایی که از رقبا استخراج کرده‌اید و مسیری که مقاله باید طی کند.

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

ساختاریافته صحبت کنید؛ قدرت JSON

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

در اینجا ما از هوش مصنوعی می‌خواهیم که خروجی خود را با فرمت JSON به ما برگرداند. با این کار، دیتاها ساختاریافته می‌شوند. یعنی در خروجی، عنوان مقاله (Title)، توضیحات متا (Meta Description)، و بدنه اصلی متن هر کدام در بخش‌های جداگانه‌ای قرار می‌گیرند. این معماری به شما اجازه می‌دهد که در قدم‌های بعدی، با یک کلیک ساده، عنوان را به یک ستون اکسل و متن را به یک فایل متنی ارسال کنید.

نگاهی به آینده؛ از نتایج گوگل تا AI Overviews

دنیای جستجو در حال تغییر است. گوگل دیگر فقط یک لیست از لینک‌های آبی نیست. بخش AI Overview (پیشنهادات هوش مصنوعی گوگل) در حال تسخیر نتایج جستجو است.

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

حافظه پنهان و درک اسناد اختصاصی (مفهوم RAG)

وقتی در حال کار با ابزارهایی مثل NotebookLM هستید، شاید دوست داشته باشید این قابلیت را مستقیماً وارد سیستم خودکار خود کنید؛ اما متاسفانه دسترسی مستقیم (API) به آن وجود ندارد.

راهکار جایگزین و البته حرفه‌ای‌تر، استفاده از تکنیکی به نام RAG (Retrieval-Augmented Generation) است. فرض کنید می‌خواهید هوش مصنوعیِ شما، مقاله‌ها را بر اساس کاتالوگ محصولات خودتان یا اسناد داخلی شرکتتان بنویسد تا اطلاعات غلط تولید نکند. در روش RAG، شما ابتدا اسناد خود را به تکه‌های کوچک تقسیم می‌کنید، آن‌ها را به اعداد (Vector) تبدیل کرده و در یک دیتابیس ذخیره می‌کنید. حالا هر زمان که هوش مصنوعی می‌خواهد محتوایی تولید کند، اول در این دیتابیس جستجو می‌کند، اطلاعات دقیق را می‌خواند و سپس بر اساس آن‌ها جواب می‌دهد. این دقیقاً همان مکانیسمی است که موتورهای جستجوی تصویری در فروشگاه‌های آنلاین استفاده می‌کنند.

تست، خطا و تکامل

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

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