اتوماسیون با هوش مصنوعی
اتوماسیون یعنی یک رویداد اتفاق بیفتد، چند قدم پشت سرش اجرا شود و در آخر یک عمل انجام شود، بدون اینکه کسی دکمه ای بزند. هوش مصنوعی فقط جای همان قدمی می نشیند که به قضاوت احتیاج دارد؛ هر قدمی که با یک شرط ساده حل می شود باید شرط بماند، چون شرط هزینه ای ندارد، چیزی از خودش نمی سازد و وقتی خراب شود سر و صدا می کند.
- درس ۱۰ از ۱۵
- میانی
- رایگان، بدون ثبت نام
رویداد، قدم ها، عمل
همین پنج حلقه زیر هر اتوماسیونی هستند، از یک زپ دو مرحله ای تا یک گردش کار سی قدمی. تنها حلقه ای که به مدل احتیاج دارد سومی است.
-
۱
رویداد
فرمی پر شد، ایمیلی رسید، ساعت رسید. اینجاست که زاپیر بازه پولینگ دارد و پلن ارزان تر دیرتر می بیند.
-
۲
شرط
فیلتر ساده، بدون مدل. هزینه ندارد، چیزی از خودش نمی سازد و همیشه یک جواب می دهد.
-
۳
قضاوت
تنها قدمی که مدل در آن لازم است: دسته بندی، خلاصه، ترجمه. خروجی ساختاریافته بخواهید، نه متن آزاد.
-
۴
دروازه انسانی
هر جا خروجی از سازمان بیرون می رود یا چیزی را تغییر می دهد. هفته اول همیشه دستی.
-
۵
عمل
پیام، ردیف، تیکت. اینجا هم سقف تعداد بگذارید تا یک خطا به ارسال تکراری تبدیل نشود.
هیچ جای این زنجیر خودش خبر نمی دهد که پاره شده. پایش کردن یک حلقه اضافه نیست، بخشی از خود ساختن است.
آخرین بررسی: فکت ها و نام ابزارهای این درس در همین تاریخ با منابعشان بازبینی شده اند.
اتوماسیون از چه ساخته می شود، و هوش مصنوعی کجایش می نشیند
هر اتوماسیون، از ساده ترین تا پیچیده ترین، سه بخش دارد. یک رویداد که شروعش می کند: فرمی پر شد، ایمیلی رسید، ساعت هفت صبح شد. چند قدم که داده را عوض می کنند: فیلتر، تبدیل، صدا زدن یک سرویس دیگر. و یک عمل در انتها: پیامی فرستاده شد، ردیفی ثبت شد، تیکتی ساخته شد. همین. اگر یک ابزار اتوماسیون را باز کنید و بیشتر از این ببینید، دارید یک نسخه پیچیده تر از همین سه چیز را می بینید.
حالا سوال اصلی: هوش مصنوعی کجا وارد می شود. جواب کوتاه این است که فقط در قدم هایی که قضاوت لازم دارند. اینکه ایمیلی از یک آدرس مشخص آمده یا نه، قضاوت نیست، یک شرط است. اینکه متن آن ایمیل شکایت است یا سوال قیمت، قضاوت است. اگر این دو را با هم قاطی کنید، به یک سیستم می رسید که برای کاری که یک if حلش می کرد پول می دهد و گاهی جواب متفاوتی می دهد.
موضع ما صریح است: بیشتر چیزی که امروز با نام اتوماسیون هوش مصنوعی فروخته می شود، اتوماسیون معمولی است با یک مدل چسبانده شده روی آن. این بد نیست، ولی وقتی اسمش را عوض می کنند قیمتش هم عوض می شود. سوالی که باید بپرسید این است: کدام قدم این گردش کار بدون مدل انجام نمی شود. اگر جواب هیچ کدام بود، شما اتوماسیون می خواهید و نه هوش مصنوعی، و آن ارزان تر و پایدارتر است.

سوالی که باید سر هر قدم پرسیده شود
این قدم بدون مدل انجام می شود
شرط بگذارید
- فرستنده، تاریخ، مبلغ، وجود یک فیلد
- همیشه یک جواب، بدون هزینه
- وقتی خراب شود خطا می دهد
اینجا مدل بگذارید
- موضوع پیام، لحن، خلاصه، ترجمه
- خروجی ساختاریافته بخواهید، نه متن آزاد
- یک سوال یکسان دو جواب می گیرد
این سوال درباره امکان است و نه درباره کیفیت. مدل می تواند کارهای سمت راست را هم انجام بدهد، فقط گران تر و ناپایدارتر انجامشان می دهد.
n8n و زاپیر و میک؛ تفاوتی که به قیمت می خورد
مهم ترین تفاوت این سه ابزار رابط کاربری شان نیست، واحد شمارش شان است. صفحه قیمت خود n8n می نویسد قیمت بر اساس تعداد اجرای گردش کار در ماه است، مستقل از پیچیدگی. یعنی یک گردش کار سی قدمی هم یک اجرا حساب می شود. زاپیر بر اساس تسک حساب می کند، و صفحه خودش می گوید حالا قدم های هوش مصنوعی و کد و SDK هم زیر همان مدل تسک محور آمده اند. این تفاوت وقتی گردش کارتان چند قدم بیشتر می شود خودش را نشان می دهد، و بیشتر مقایسه های فارسی که فقط قیمت پایه را کنار هم می گذارند اصلا به آن نمی رسند.
عددها را همان روز از صفحه خودشان خواندیم. در n8n پلن Starter بیست یورو در ماه با پرداخت سالانه است و ۲۵۰۰ اجرا می دهد، Pro پنجاه یورو و ۱۰۰۰۰ اجرا، و Business ششصد و شصت و هفت یورو و ۴۰۰۰۰ اجرا. در زاپیر پلن رایگان صفر دلار است با صد تسک در ماه و فقط زپ های دو مرحله ای و بازه پولینگ پانزده دقیقه؛ Professional از نوزده دلار و نود و نه سنت شروع می شود با زپ چند مرحله ای و پولینگ دو دقیقه؛ و Team از شصت و نه دلار با بیست و پنج کاربر و پولینگ یک دقیقه.
درباره میک عددی نمی نویسیم و دلیلش را صریح می گوییم: دامنه make.com به این سرور کد ۴۰۳ می دهد، هم روی صفحه اصلی و هم روی صفحه قیمت، حتی با یوزرایجنت یک مرورگر معمولی. ما قیمتی را که خودمان از صفحه سازنده نخوانده ایم نمی نویسیم، و همین یک مورد چیزی درباره دسترسی هم می گوید: سرویسی که صفحه عمومی اش را به شما نشان نمی دهد، هنوز حساب باز نکرده اید و مشکل شروع شده.
و نکته ای که برای خواننده ایرانی از هر سه عدد بالا مهم تر است: n8n را می شود روی سرور خودتان اجرا کرد و مستنداتش راه نصب با داکر را می دهد. یعنی موضوع دسترسی به یک سرویس بیرونی از میان برمی خیزد و جایش را یک سوال دیگر می گیرد که مستندات خود n8n هم صریح گفته: خودمیزبانی دانش فنی می خواهد و اشتباه در آن به از دست رفتن داده و مشکل امنیتی و قطعی ختم می شود، و برای همین آن را به کاربران خبره توصیه می کند.
مجوز n8n را قبل از فروختنش به مشتری بخوانید
این بند را کمتر کسی می خواند و برای یک آژانس دقیقا همان جایی است که مشکل می سازد. فایل LICENSE.md در شاخه اصلی مخزن n8n می گوید بخش عمده نرم افزار زیر Sustainable Use License نسخه ۱.۰ منتشر شده، و آن مجوز صریح می نویسد که شما فقط برای مقاصد داخلی کسب و کار خودتان یا استفاده غیرتجاری و شخصی می توانید نرم افزار را به کار ببرید یا تغییرش بدهید، و می توانید آن را در اختیار دیگران بگذارید فقط اگر رایگان و برای مقاصد غیرتجاری باشد.
ترجمه عملی اش برای یک شرکت طراحی سایت این است: اینکه n8n را روی سرور خودتان بالا بیاورید و کارهای داخلی خودتان را با آن خودکار کنید، همان استفاده داخلی است و مشکلی ندارد. اینکه یک نمونه n8n بالا بیاورید و به مشتری هایتان به عنوان سرویس بفروشید، همان چیزی است که این بند درباره اش حرف می زند. همان فایل یک نکته دوم هم دارد که مهندس ها معمولا از آن غافل می شوند: فایل هایی که در نامشان .ee. یا در نام پوشه شان .ee دارند اصلا زیر این مجوز نیستند و مجوز سازمانی جدا می خواهند.
این را برای ترساندن نمی نویسیم و درباره وضعیت حقوقی هیچ حکمی نمی دهیم؛ می نویسیم چون همان الگویی است که در درس مدل های متن باز دیدید و اینجا هم تکرار می شود: کلمه رایگان و کلمه آزاد یکی نیستند، و مرزشان همیشه در فایل LICENSE نوشته شده و نه در صفحه بازاریابی. پانزده دقیقه خواندن آن فایل، قبل از اینکه پیشنهاد به مشتری داده شود، ارزان ترین کاری است که در این حوزه می شود کرد.
سه اتوماسیون واقعی، قدم به قدم
یکم، لید فرم تماس. رویداد این است که فرم تماس سایت پر شود. قدم اول یک شرط ساده است و نه مدل: اگر فیلد شماره خالی است یا متن کمتر از ده کاراکتر دارد، اسپم است و همان جا تمام. قدم دوم مدل است، و تنها قدمی که مدل در آن لازم است: متن پیام را بخواند و بگوید موضوعش چیست و در چه بازه بودجه ای صحبت شده، به شکل یک خروجی ساختاریافته با فیلدهای ثابت. قدم سوم دوباره شرط است: بر اساس آن موضوع، به آدم درست فرستاده شود. قدم چهارم عمل است: یک پیام در گروه تیم، با خود متن اصلی و نه فقط خلاصه مدل. و قدم پنجم که همیشه جا می افتد: هیچ پاسخی به مشتری فرستاده نمی شود. آدم می فرستد.
دوم، گزارش هفتگی سرچ کنسول. رویداد یک زمان بندی است، مثلا صبح شنبه. قدم اول دریافت داده هفته و هفته قبل است. قدم دوم محاسبه است و نه مدل: کوئری هایی که میانگین رتبه شان از هفته قبل بدتر شده و نمایش قابل توجهی دارند جدا می شوند. اینجا مدل هیچ کاری ندارد و اگر بگذاریدش، عدد اشتباه می دهد. قدم سوم مدل است: همان فهرست عددی را می گیرد و برای هر ردیف در یک خط می نویسد که این کوئری به کدام صفحه سایت مربوط است و چه چیزی ممکن است تغییر کرده باشد، با ذکر اینکه حدس است. قدم چهارم عمل است: یک ایمیل با جدول اعداد در بالا و حدس های مدل در پایین، به همین ترتیب و نه برعکس، چون هر کس خسته باشد فقط بالای ایمیل را می خواند.
سوم، پیش نویس ترجمه پست تازه. رویداد انتشار یک نوشته است. قدم اول جمع کردن متن و فهرست اصطلاحاتی است که ترجمه ثابت دارند، یعنی همان واژه نامه شما. قدم دوم مدل است و باید واژه نامه را در همان پرامپت ببیند، وگرنه هر بار یک معادل تازه می سازد. قدم سوم شرط است: اگر خروجی کوتاه تر از هفتاد درصد متن اصلی است، یعنی چیزی جا افتاده و باید علامت بخورد. قدم چهارم عمل است: پیش نویس به شکل پیش نویس ذخیره می شود، نه منتشر. این قدم چهارم قابل مذاکره نیست و دلیلش را در بخش بعد می خوانید.
در هر سه، الگو یکی است و عمدا هم یکی است: شرط ها کار را می برند جلو، مدل فقط جایی می آید که قضاوت لازم است، و آخرین قدمی که به دنیای بیرون می رسد دست آدم است. اگر گردش کاری بسازید که این سه ویژگی را ندارد، سریع تر ساخته اید و دیرتر می فهمید که کار نمی کند.
اتوماسیونی که خراب شود سر و صدا نمی کند
دو شکل خرابی وجود دارد و هر دو بی صدا هستند. اول اینکه اتوماسیون بایستد و هیچ کس نفهمد، چون خروجی نداشتنش دقیقا شبیه روزی است که ورودی نبوده. دوم و بدتر اینکه بایستد ولی نه کامل: قدم آخر دو بار اجرا شود، یا همان پیام هر پنج دقیقه یک بار برود. اولی هفته ها طول می کشد تا دیده شود و دومی چند ساعت، ولی دومی تا وقتی دیده شود آبروی شما را جلوی مشتری برده.
سه چیز جلوی بیشتر این حالت ها را می گیرد و هیچ کدام کار سختی نیست. یک ضربان: اتوماسیون هر بار که موفق اجرا شد یک ردیف با زمان بنویسد، و یک بررسی جدا هشدار بدهد اگر آخرین ردیف از حد معینی قدیمی تر شد. یعنی به جای اینکه منتظر خطا بمانید، منتظر سکوت می مانید. یک سقف: اگر تعداد اجرا در یک ساعت از عدد مشخصی گذشت، متوقف شود. و یک کلید خاموشی که در دسترس باشد و همه بدانند کجاست.
و یک عادت که ارزان تر از هر سه است: قدم آخر را که به دنیای بیرون می رسد، اولین هفته دستی نگه دارید. اتوماسیون کارش را بکند و در صف بگذارد، شما نگاه کنید و بفرستید. اگر بعد از یک هفته چیزی در آن صف نبود که جلویش را بگیرید، آن وقت خودکارش کنید. این تنها راهی است که بدون ریسک بفهمید سیستم واقعا درست کار می کند و نه فقط شبیه کار کردن است.
چهار چیزی که باید باشد و چهار چیزی که نباید
قبل از رها کردن باید باشد
- ضربان: هر اجرای موفق یک ردیف با زمان می نویسد
- هشدار سکوت: اگر آخرین ردیف کهنه شد، خبر بدهد
- سقف اجرا در ساعت، برای جلوگیری از ارسال تکراری
- کلید خاموشی که همه می دانند کجاست
به این چهار تکیه نکنید
- ایمیل خطای خود پلتفرم، که فقط خطای خودش را می گیرد
- اینکه اگر خراب شود حتما می فهمم
- گزارش هفتگی، که خرابی سه روزه را دیر نشان می دهد
- ارسال خودکار در هفته اول
این فهرست خرابی های ساکت را می گیرد و نه اشتباه های محتوایی. اینکه مدل دسته بندی را غلط زده باشد از این برگه رد می شود و فقط با نمونه گیری دستی پیدا می شود.
مسیر سریع با هوش مصنوعی
راه سریع این نیست که مدل گردش کار را برایتان بسازد؛ ابزارها هر چند ماه عوض می شوند و خروجی ای که برای نسخه پارسال نوشته شده باشد وقت شما را می گیرد. راه سریع این است که مدل مشخصات را بنویسد: همان جدولی که برای هر قدم می گوید قانون است یا قضاوت، چطور خراب می شود و چه کسی می فهمد. ساختن گردش کار از روی چنین جدولی نصف روز است؛ ساختنش بدون آن، دو هفته و یک اتوماسیون بی صدا. یک مدل قوی بردارید، چون کار قضاوت است.
- کاری را که امروز دستی انجام می دهید، همان طور که واقعا انجام می شود، در چند خط بنویسید. با استثناهایش، چون استثناها همان جایی هستند که اتوماسیون می شکند.
- دستور زیر را اجرا کنید و جدول را بگیرید. ستون سکوت را حذف نکنید، همان ستونی است که بقیه فهرست ها ندارند.
- هر ردیفی را که مدل «قضاوت» علامت زده دوباره خودتان نگاه کنید. مدل ها تمایل دارند کارهای ساده را هم قضاوت حساب کنند، و هر قضاوت اضافه یعنی هزینه و بی ثباتی اضافه.
- اول فقط ستون قانون را بسازید و یک هفته با همان کار کنید. قدم های قضاوت را هفته بعد اضافه کنید، یکی یکی، و هر بار خروجی هفته را نمونه گیری کنید.
نسخه آماده کپی
کاری که پایین نوشته ام امروز دستی انجام می شود و می خواهم خودکارش کنم. ابزار اسم نبر و پیشنهاد محصول نده.
کار: {همان چند خطی که نوشتید}
چیزی که هرگز نباید اتفاق بیفتد: {مثلا هیچ پیامی بدون تایید من به مشتری نرود}
حجم: {مثلا روزی حدود ۲۰ مورد}
یک جدول بده، یک ردیف برای هر قدم، با این ستون ها:
قدم | قانون ثابت است یا قضاوت | ورودی لازم | اگر این قدم خراب شود چه شکلی خراب می شود | آیا خرابی اش صدا دارد یا ساکت است | چه کسی می فهمد
قاعده ها:
- هر قدمی که با مقایسه یا شرط ساده حل می شود را قانون بنویس، حتی اگر یک مدل هم می تواند انجامش بدهد.
- برای هر قدم قضاوت، بنویس خروجی اش باید چه فیلدهایی داشته باشد.
- ستون سکوت را جدی بگیر: هر قدمی که خرابی اش خطا تولید نمی کند را صریح ساکت علامت بزن.
بعد از جدول، در پنج خط بگو اگر فقط ردیف های قانون را بسازم و هیچ مدلی در کار نباشد، چه چیزی از دست می رود.
قبل از اعتماد به خروجی: جدول یک نقشه است و نه یک سیستم کارکننده. سه چیز را حتما خودتان بازبینی کنید: ستون قانون یا قضاوت، چون مدل تمایل دارد کار خودش را زیادتر از آنچه هست نشان بدهد؛ ستون سکوت، چون خرابی های بی صدا همان هایی هستند که مدل هم کمتر می بیندشان؛ و آخرین قدمی که به بیرون می رسد، که تا وقتی یک هفته نتیجه اش را با چشم ندیده اید خودکار نمی شود. اگر پنج خط آخر جواب داد که بدون مدل چیز مهمی از دست نمی رود، آن پنج خط گران ترین چیزی است که از این دستور گرفته اید.
هوش مصنوعی در این کار
در یک اتوماسیون، مدل نقش یک قدم را بازی می کند و نه نقش سیستم را، و همین باعث می شود انتخاب ابزار اینجا با انتخاب ابزار برای گفتگو فرق کند. چیزی که مهم است این است که خروجی ساختاریافته بدهد و در هزار بار اجرا همان شکل را نگه دارد، نه اینکه در یک جواب طولانی درخشان باشد. موضع ما این است: برای قدم های مکانیکی و پرتکرار مثل دسته بندی و برچسب زدن، یک مدل سریع و ارزان بردارید و پولی که صرفه جویی می شود را خرج نمونه گیری دستی خروجی ها کنید. آن نمونه گیری چیزی است که هیچ مدلی جایش را نمی گیرد.
ابزارهایی که واقعا کمک می کنند
- n8n برای خواننده ایرانی مهم ترین گزینه است چون روی سرور خودتان اجرا می شود. قیمت ابری اش بر اساس تعداد اجرای گردش کار است و نه تعداد قدم. مجوزش را قبل از فروختن به مشتری بخوانید؛ بخش بالای همین صفحه دلیلش را گفته.
- Zapier راه اندازی اش از همه سریع تر است و برای امتحان کردن ایده در یک بعدازظهر مناسب. حساب کردنش بر اساس تسک است، پس گردش کار طولانی روی زاپیر گران تر از چیزی درمی آید که از روی قیمت پلن حدس می زنید.
- Gemini فارسی را خوب می فهمد و برای قدم دسته بندی و برچسب زدن روی پیام فارسی گزینه معقولی است. صفحه خود گوگل می گوید اپ وب جمنای در بیش از دویست و سی کشور و منطقه کار می کند و ایران در آن فهرست نیست.
- Claude برای نوشتن خود مشخصات اتوماسیون، یعنی همان جدول بخش بالا، جواب های صریح تری می دهد و راحت تر می گوید یک قدم اصلا به مدل احتیاج ندارد. ایران در هیچ کدام از دو فهرست کشورهای پشتیبانی شده انتروپیک نیست.
کجا نتیجه معکوس می دهد
خطر مشخص اتوماسیون این است که هر دو نوع خرابی اش بی صدا هستند. اتوماسیونی که ایستاده هیچ خبری نمی دهد، چون نبود خروجی از نبود ورودی قابل تشخیص نیست؛ و اتوماسیونی که در حلقه افتاده هم خبر نمی دهد، فقط همان پیام را بارها می فرستد و کسی که آن را دریافت می کند خبر می دهد، نه سیستم شما. برای همین پایش بخشی از ساختن است و نه کاری برای بعد. خطر دوم مربوط به داده است: هر قدمی که متن پیام مشتری را به یک سرویس بیرونی می فرستد، همان متن را از سازمان شما خارج کرده، و اینکه آن متن برای آموزش استفاده می شود یا نه به نوع حساب و تنظیمات بستگی دارد و انتروپیک این را در صفحه حریم خصوصی اش نوشته؛ در اتوماسیون این خطر بزرگ تر از گفتگوی دستی است چون هزار بار در روز تکرار می شود و کسی هر بار به آن فکر نمی کند. و خطر سوم، همان خطای انباشته درس ایجنت است در شکل ارزان ترش: یک دسته بندی غلط در قدم دوم، در قدم چهارم به یک پیام غلط برای یک مشتری واقعی تبدیل می شود، مگر اینکه آدمی بین آن دو ایستاده باشد. برای وضعیت دسترسی و پرداخت این ابزارها از ایران، راهنمای خرید را ببینید.
منبع ها: n8n: plans and pricing Zapier: plans and pricing n8n: Sustainable Use License n8n: self hosting takes technical knowledge Anthropic: is my data used for model training
حد این توصیه
قیمت هایی که در این صفحه آمده وضعیت ۶ سپتامبر ۲۰۲۶ است و پلن های این سرویس ها هر چند ماه عوض می شوند؛ تاریخ بررسی بالای همین صفحه دقیقا برای همین است. درباره میک هیچ عددی ننوشته ایم چون صفحه اش برای این سرور باز نمی شود، پس این درس مقایسه سه طرفه نیست و دو طرفه است. ما n8n را روی زیرساخت خودمان اجرا نکرده ایم و درباره مصرف منابع یا پایداری اش ادعایی نمی کنیم؛ آنچه درباره خودمیزبانی نوشته شده از مستندات خود n8n است. و آخر اینکه بخش مجوز توضیح متن است و نظر حقوقی نیست.
از تجربه خود ما
روی همین سرور یک تله داریم که هر اتوماسیون وبهوکی را بی صدا می کشد و پیدا کردنش برایمان وقت برد. فایل php.ini در سطر ۴۰۴ می گوید max_execution_time = 900، ولی php-fpm.conf در سطر ۴۰ می گوید request_terminate_timeout = 180، و آن که برنده است دومی است. یعنی هر درخواستی که از سه دقیقه بگذرد با سیگنال کشته می شود، و وقتی پروسه با سیگنال می میرد تابع های shutdown و بلوک های finally اصلا اجرا نمی شوند. نتیجه اش دقیقا همان چیزی است که این درس درباره اش هشدار می دهد: شاخه «اگر خطا داد» کد شما هیچ وقت اجرا نمی شود، پس اتوماسیون خطا گزارش نمی کند، هیچ چیزی گزارش نمی کند. عدد ۹۰۰ در php.ini یک طعمه است و ما هم اولش گولش را خوردیم. بعد از آن، کارهای زمان بر کرون این سایت را طوری نوشتیم که هر بار کمتر از این بودجه کار کنند و از جایی که مانده اند ادامه بدهند.
سوال هایی که واقعا پرسیده می شوند
برای شروع n8n بهتر است یا زاپیر
اگر می خواهید یک ایده را در یک بعدازظهر امتحان کنید، زاپیر سریع تر است. اگر گردش کار قدم های زیادی دارد یا داده نباید از سرور شما بیرون برود، n8n منطقی تر است چون بر اساس اجرا حساب می کند و روی سرور خودتان هم اجرا می شود. مجوز n8n را قبل از اینکه به مشتری بفروشیدش بخوانید.
در یک اتوماسیون از کدام مدل استفاده کنم
برای قدم های مکانیکی و پرتکرار مثل دسته بندی و برچسب زدن، یک مدل سریع و ارزان کافی است. مدل گران را برای جایی نگه دارید که واقعا قضاوت لازم است. انتخاب امروز را از بخش مرجع هوش مصنوعی همین سایت بردارید، نه از یک اسم مدل که در یک آموزش نوشته شده.
از کجا بفهمم اتوماسیونم خراب شده
با انتظار کشیدن برای سکوت و نه برای خطا. هر اجرای موفق یک ردیف با زمان بنویسد و یک بررسی جدا هشدار بدهد اگر آخرین ردیف از حد معینی قدیمی تر شد. ایمیل خطای خود پلتفرم کافی نیست، چون فقط خطاهای خودش را می بیند و نه ایستادن کامل را.