اقتصاد توسعهٔ افزونهٔ وردپرس با کمک هوش مصنوعی برای یک تیم کوچک
حسابداری صادقانهٔ هزینهها از زبان یک تیم کوچک که افزونهٔ آمار وردپرس میسازد. صورتحساب Anthropic پیش از بهینهسازی چه شکلی بود، حالا چه شکلی است، و صرفهجوییهای مرکب واقعاً از کجا میآیند.
پرسشی که در ماه اول نمیتوانستیم صادقانه به آن پاسخ دهیم
ساخت یک افزونهٔ وردپرس با Claude Code بهعنوان همکار روزانه چقدر هزینه دارد؟
در نخستین ماه ساخت Statnive، نمیتوانستیم به این پرسش پاسخ دهیم. مبلغ صورتحساب را میدانستیم، اما نمیدانستیم واقعاً چه چیزی آن را بالا میبرد. برخی روزها 3 دلار بود و برخی روزها 11 دلار، و این نوسان هیچ ارتباط روشنی با حجم کدی که منتشر میکردیم نداشت.
چهار ماه بعد، تصویر بسیار روشنتری در دست داریم. این نوشته همان حسابداری هزینه است: پول کجا میرود، چهار اهرمی که روی هم مینشینند و هزینهمان را تقریباً 2 تا 3 برابر کاهش میدهند، و آن یک عددی که از هر بهینهسازی منفردی مهمتر بود.
خلاصهاش این است: هزینهٔ روزانه از حدود 6 دلار در روز به حدود 2 تا 3 دلار در روز رسید، آن هم با همان میزان خروجی مهندسی. این صرفهجوییها جمعشونده نیستند؛ بلکه در هم ضرب میشوند.
هزینهٔ هوش مصنوعی واقعاً کجا خرج میشود
قیمتگذاری Anthropic برای مدلهای مرتبط با Claude Code، بهروز تا اوایل 2026، به این شکل است:
| مدل | ورودی / MTok | خروجی / MTok | بهترین کاربرد |
|---|---|---|---|
| Haiku 4.5 | $1 | $5 | کاوش فقطخواندنی، اعتبارسنجی، رفع اشکالات روتین |
| Sonnet 4.6 | $3 | $15 | کارهای استاندارد توسعه |
| Opus 4.7 | $5 | $25 | معماری پیچیده، استدلال عمیق |
در نگاه ساده، یک مدل را انتخاب میکنید و همان نرخ را در میزان مصرف توکنتان ضرب میکنید. اما واقعیت ریزتر از این است؛ و سه تا از چهار اهرم بهینهسازی که در ادامه میآید، دقیقاً از همین ریزهکاری بهره میبرند.
برای مرجع، بودجهٔ معمول توکن برای هر عملیات اینگونه است:
| نوع عملیات | توکن معمول | زمان واقعبینانه |
|---|---|---|
| رفع ساده (Haiku) | 2K–5K | 1–2 دقیقه |
| ویژگی استاندارد (Sonnet) | 10K–20K | 5–10 دقیقه |
| بازنویسی پیچیده (Sonnet + تفکر گسترده) | 30K–50K | 15–25 دقیقه |
| بازبینی معماری (Opus) | 50K–100K | 20–40 دقیقه |
وقتی اینها را در طول یک روز کاری ضرب کنید، همان حدود 6 دلار در روز برای یک مهندس از همینجا درمیآید. حالا همین را در یک سال ضرب کنید؛ آنوقت گفتوگو دربارهٔ بهینهسازی جدی میشود.
اهرم 1 — کش پرامپت (حدود 90% روی پیشوند پایدار)
Claude Code بهطور خودکار پیشوند پایدار هر گفتوگو را کش میکند: پرامپت سیستم، تعریف ابزارهای داخلی، فرادادهی مهارتها، و فایل ریشهای CLAUDE.md. خواندن از کش 0.1 برابر قیمت پایه هزینه دارد؛ یعنی 90% کاهش روی همان بخشی که کش شده است.
پیشوند پایدار در بیشتر تنظیمات بیش از 50K توکن است. بدون کش، در هر نوبت دوباره برای همان 50K توکن هزینه میپردازید. با کش، در هر نوبت بعد از نوبت اول، همانها را با 10% هزینه میخوانید.
دو قاعدهٔ کاربردی وجود دارد:
- محتوا را اول ثابت، آخر پویا بچینید. برخورد با کش به تطابق دقیق پیشوند نیاز دارد. هر چیز پویایی در ابتدای گفتوگو، کش را میشکند و یک بازخوانی کامل را تحمیل میکند. به همین دلیل، ما
CLAUDE.mdریشه و فرادادهی مهارتها را اول میگذاریم و زمینهٔ پویا (فایلهای تغییریافته، وضعیت شاخهٔ فعلی) را آخر. - پیشوند را با چیزی که هر نشست عوض میشود آلوده نکنید. این همان دلیل واقعی برای کوتاه و سبک نگهداشتن
CLAUDE.mdاست؛ هر بایتی که حذف میکنید، بایتی است که هنگام تغییر فایل لازم نیست دوباره کش شود، و پیشوندهای کششدهٔ کوتاهتر هنگام انقضا ارزانتر تازه میشوند.
کش بزرگترین اهرم تکنفرهٔ هزینه است و بیشترش خودکار انجام میشود. کار واقعی این است که آن را نشکنید.
اهرم 2 — مسیریابی مدل (3 برابر روی بخش مسیریابیشده)
هزینهٔ Haiku 4.5 به ازای هر توکن 3 برابر کمتر از Sonnet است. تفاوت توانایی برای کارهای فقطخواندنی و اعتبارسنجی ناچیز است. Anthropic پیشنهاد میکند که برای حدود 80% کارهای روتین، Haiku پیشفرض باشد.
در عمل، ما اینطور مسیریابی میکنیم:
| کار | مدل | چرا |
|---|---|---|
| کاوش کد («همهٔ جاهایی که X صدا زده میشود را پیدا کن») | Haiku (زیرعامل) | فقطخواندنی، قطعی |
| تریاژ شکست تستها | Haiku (زیرعامل) | تطبیق الگو، قضاوت کم |
| پیادهسازی ویژگی استاندارد | Sonnet (اصلی) | پیشفرض برای کار مولد |
| تصمیمهای معماری، طراحی اسکیما | Opus (اصلی، گاهبهگاه) | برای استدلال سخت، ارزش هزینهٔ بیشتر را دارد |
| پاس بازبینی کد | Haiku (زیرعامل فورک) | پرخوانش، با خروجی خلاصه |
مسیریابی زمانی بیشترین قدرت را دارد که با زیرعاملها همراه شود، چون زیرعاملها تنظیم مدل مستقل خودشان را، جدا از نشست اصلی، دارند. میتوانیم گفتوگوی اصلی را روی Sonnet اجرا کنیم و در همان حال، یک زیرعامل فورک کار پرخوانش را روی Haiku انجام دهد. مسیریابی مدل در مرز مهارت اتفاق میافتد، نه در مرز گفتوگو.
اهرم 3 — جداسازی زیرعامل (حدود 37% کاهش زمینهٔ اصلی)
زیرعاملها (که به آنها عامل فورک هم میگویند) پنجرهٔ زمینهٔ مستقل 200K توکنی خودشان را دارند. کاری که درون یک زیرعامل انجام میشود، گفتوگوی اصلی را آلوده نمیکند؛ فقط یک خلاصه بازمیگردد.
Anthropic مستند کرده است که زیرعاملها حدود 500 تا 1,000 توکن از بیش از 10,000 توکن کار داخلی را بازمیگردانند؛ یعنی تقریباً 37% کاهش زمینهٔ اصلی در کارهای پیچیده.
این کار دو اثر هزینهای دارد:
- صرفهجویی مستقیم توکن. بازبینی کدی که 30 فایل را میخواند و یک حکم برمیگرداند، توکنهایش را بهصورت جداگانه مصرف میکند. بدون جداسازی، آن 30 بار خواندن فایل در زمینهٔ اصلی میماند و در هر نوبت بعدی دوباره برایش هزینه برداشته میشود (با احتساب اثر کش).
- صرفهجویی توکن از مسیر کیفیت. زمینهٔ طولانی کیفیت بازیابی را افت میدهد؛ پژوهشها افت عملکرد 15 تا 47 درصدی را بهموازات پر شدن زمینه مستند کردهاند، همان مشکل «گمشدن در میانه». کیفیت پایینتر یعنی تلاشهای دوبارهی بیشتر، بازخوانیهای بیشتر و توکنهای بیشتر. تمیز نگهداشتن زمینهٔ اصلی، جلوی این کل دسته از اتلاف را میگیرد.
البته یک معاوضهٔ واقعی هم در کار است: تیمهای عامل تقریباً 7 برابر توکن بیشتری از نشستهای استاندارد مصرف میکنند، چون هر عامل یک نمونهٔ تازه با سربار راهاندازی خودش را ایجاد میکند. ما این را میپذیریم، چون هدفمان بهینهسازی کل توکن نیست؛ هدفمان تمیزی زمینهٔ اصلی و خروجی کلی است. از سوی دیگر، زیرعاملها روی Haiku در هر حال ارزان هستند.
اهرم 4 — بهتعویقانداختن ابزار MCP (حدود 85%)
این را بهتفصیل در نوشتهٔ جستجوی ابزار MCP پوشش دادیم. نسخهٔ کوتاهش این است:
بیستوچهار اتصالدهندهٔ MCP بدون بهتعویقانداختن، در هر نشست تقریباً 135,000 توکن سربار پایه مصرف میکردند. جستجوی ابزار این عدد را برای فهرست به حدود 3,000 توکن رساند و اسکیمای کامل هر ابزار هم بهمحض نیاز بارگذاری میشود. 85% کاهش، و دقت هم بالا رفت، و نشستها دیگر تنگ و خفه احساس نمیشدند.
اثر هزینهای این است: هر توکن سربار پایه، توکنی است که در هر نشست بخشی از پیشوند کششده میشود. بریدن 130K توکن سربار یعنی بریدن تقریباً 130K ضرب در 0.1 ضرب در نرخ هر توکن ضرب در همهٔ خواندنهای کش بهاندازهٔ هر نشست. حتی با 10% هزینه، این برای یک مهندس فعال صدها دلار در ماه میشود.
ضریب مرکب
حالا میرسیم به همان بخشی که اعداد خلاصه آن را نشان نمیدهند. این چهار اهرم ضربشونده هستند، نه جمعشونده.
یک نشست پایه را تصور کنید که مثلاً 0.30 دلار روی یک کار 5 دقیقهای خرج میکند. حالا هر اهرم را بهنوبت روی آن اعمال کنید:
| اهرم | اثر | هزینهٔ تجمعی |
|---|---|---|
| پایه | — | $0.30 |
| کش پرامپت (90% روی پیشوند پایدار) | پیشوند پایدار حدود 70% توکنهای نشست است | حدود $0.12 |
| مسیریابی مدل (3 برابر روی کار مناسب Haiku) | حدود 50% کار مناسب Haiku است | حدود $0.07 |
| جداسازی زیرعامل (37% کاهش زمینهٔ اصلی) | زمینهٔ اصلی کوچک میشود ← هزینهٔ تکراری کمتر | حدود $0.05 |
| بهتعویقانداختن ابزار MCP (85% روی سربار اسکیمای ابزار) | اسکیماها دیگر پایه نیستند | حدود $0.04 |
هر گام بهتنهایی متواضعانه است، اما ترکیبشان چشمگیر است. درصدهای دقیق آن چیزی نیست که اهمیت دارد؛ بینش ساختاری این است که بهینهسازیهای هزینهٔ توکن بهصورت ضربی روی هم مینشینند، چون روی بخشهای همپوشان صورتحساب اعمال میشوند. چهار تای آنها را درست کنید و مرتبهٔ بزرگی هزینه را عوض کردهاید.
به همین دلیل است که هزینهٔ روزانهٔ ما از حدود 6 دلار به حدود 2 تا 3 دلار رسید، بدون اینکه آنچه منتشر میکنیم تغییر کند. همان کد، همان تستها، همان آهنگ انتشار. فقط پیشفرضها فرق کردند.
حالا پولمان را روی چه چیزی خرج میکنیم
یک روز معمول مهندسی Statnive، پس از بهینهسازی، اینگونه است:
| فعالیت | هزینهٔ تقریبی |
|---|---|
| بازبینی کد صبحگاهی روی یک PR باز (فورکشده، Haiku) | حدود $0.20 |
| 2 ویژگی استاندارد در داشبورد React (Sonnet، همراه با کش) | حدود $0.80 |
1 اجرای دروازهٔ انتشار (مهارت statnive-release) | حدود $0.30 |
| پیشنویس مستندات و نوشتههای وبلاگ | حدود $0.40 |
| کاوش متفرقه و پرسشوپاسخ | حدود $0.50 |
| مجموع | حدود $2.20 |
در سطح کل تیم، صورتحساب ماهانهٔ Anthropic ما خیلی کمتر از هزینهٔ یک اشتراک SaaS قدیمی تنهاست. برای روشنتر شدن: همین صورتحساب هزینهٔ یک همکار هوش مصنوعی را تأمین میکند که در ساخت یک افزونهٔ وردپرس به کار میآید — افزونهای که کسبوکارهای واقعی از آن استفاده میکنند و 248 تست و 22 دروازهٔ انتشار جلوی هر انتشار را میگیرند.
تفکر گسترده: کلیدواژه را با کار جور کنید
یک ریزهکاری قیمتگذاری هست که دانستنش میارزد: حالتهای تفکر گستردهٔ Claude بودجههای وابسته به کلیدواژه دارند:
| کلیدواژه | بودجهٔ تفکر |
|---|---|
think | 5K–10K توکن |
think hard | 20K–50K توکن |
think harder | 50K–100K توکن |
ultrathink | 100K–128K توکن (بیشینه) |
این توکنها بهعنوان ورودی حساب میشوند. ارزانترین موردی را که با کار جور درمیآید به کار ببرید. ما برای کار روتین بهطور پیشفرض هیچ تعدیلکنندهٔ تفکری نمیگذاریم، برای تصمیمهای طراحیِ غیرپیشپاافتاده think hard به کار میبریم، و ultrathink را فقط برای پرسشهای واقعاً معماری نگه میداریم که استدلال عمیق ارزش خودش را در آنجا ثابت میکند. سراغ ultrathink رفتن برای رفع یک غلط تایپی، در توسعهٔ هوش مصنوعی معادل این است که یک پنجرهٔ Chrome با 50 تب باز کنید تا یک صفحهٔ وب بخوانید.
بهداشت نشست به اندازهٔ اهرمها به کمکمان آمد
یک یافتهٔ غیرمنتظره: بزرگترین نوسان در هزینهٔ روزانهٔ ما طول نشست بود، نه پیکربندی مهارت یا ابزار.
نشستهای طولانیِ خودگردان بدون بازنشانی زمینه، کیفیت را بهتدریج افت میدهند. همان اثر «گمشدن در میانه» — افت عملکرد 15 تا 47 درصدی بهموازات پر شدن زمینه — مستقیم به تلاشهای دوبارهی بیشتر، بازخوانیهای بیشتر و توکنهای هدررفتهٔ بیشتر ترجمه میشود. نشستهایی که از 80% زمینه فراتر میرفتند، بهطور معمول برای همان کار 2 تا 3 برابر نشستهای کوتاهتر هزینه میبردند.
دو قاعدهٔ بهداشتی حالا در روش کار ما جا افتاده است:
/clearبین کارهای نامرتبط. جابهجایی از یک اشکال فرانتاند به تغییر دروازهٔ انتشار، دو گفتوگوی متفاوت است. پاککردن زمینه هزینهای ندارد و جلوی آلودگی را میگیرد./compactپیشدستانه در 60 تا 70 درصد زمینه، نه در آستانهٔ فشردهسازی خودکار 95%. فشردهسازی خودکار در سقف، یک عملیات وحشتزده است که اطلاعات را از دست میدهد. فشردهسازی پیشدستانه وضعیت مهم را حفظ میکند و نویز را بازنشانی میکند.
ذخیرهٔ وضعیت در فایلها بهجای تاریخچهٔ گفتوگو، هر دو قاعده را امن میکند؛ هر چیز مهمی روی دیسک است، پس یک پاککردن آن را از بین نمیبرد.
چه چیزهایی را بهینه نکردیم
- هنوز هزینهٔ هر مهارت را اندازه نمیگیریم. میتوانیم مجموع روزانه را از طریق صورتحساب Anthropic ببینیم و برای وارسی موردی از فرمانهای محلی
/costو/statsاستفاده میکنیم، اما تخصیص هزینه به ازای هر مهارت را نداریم. ابزارهایی مثلccusage(که فایلهای نشست محلی JSONL خود Claude را میخواند) و Claude-Code-Usage-Monitor وجود دارند؛ ما هنوز آنها را یکپارچه نکردهایم. - نسبت زیرعاملهای ما احتمالاً خیلی پایین است. ما حالت فورک را برای بازبینیها و ممیزیها بهشدت به کار میبریم، اما بخش معناداری از کار استاندارد ما هم احتمالاً میتوانست فورک شود تا زمینهٔ اصلی تمیزتر بماند. این را دقیق اندازه نگرفتهایم.
- مقایسهٔ رسمی A/B اجرا نمیکنیم. عدد «6 دلار ← 2 تا 3 دلار» از مقایسهٔ هزینهمان پیش و پس از پایدار شدن بهینهسازیها میآید. آزمایش کنترلشدهای پشت آن نیست. عدد شما متفاوت خواهد بود.
برای نصف کردن دوبارهٔ آن چه لازم است
پاسخ صادقانه: احتمالاً هیچ کاری که ارزش انجام دادن داشته باشد.
میتوانستیم سختتر روی Haiku فشار بیاوریم. میتوانستیم کار بیشتری را در زیرعاملها دستهبندی کنیم. میتوانستیم قراردادهای بودجهبندیِ خروجیِ سختگیرانهتری در مهارتهایمان بنویسیم. هر کدام شاید 10 تا 20 درصد دیگر را میتراشید.
هزینهٔ یک مهندس بیشتر، چندین برابر کل هزینهٔ Anthropic ما است. صرف ساعتهای مهندسی برای بهینهسازی هزینهٔ هوش مصنوعی از یک حدی به بعد، یعنی ساعتهایی که صرف ساخت خودِ محصول نشده است. ما زمانی بهینه میکنیم که نشستها تنگ و خفه احساس شوند یا صورتحسابها غافلگیرکننده باشند. در غیر این صورت، فقط منتشر میکنیم.
Statnive را امتحان کنید
افزونهٔ آمار وردپرس با محوریت حریم خصوصی، ساختهٔ تیمی که حسابداری هزینه را به همان جدیت پوشش تست میگیرد. Statnive را رایگان از WordPress.org نصب کنید — دادههایتان روی سرور خودتان میمانند، هزینهٔ ما روی یک خط بودجهٔ واحد میماند، و کل عملکرد مهندسی، متنباز است.