مطالعه موردی مهندسی
گردش کار مشخصات محصول
کاتالوگی به این بزرگی را نه میشود با دست نوشت، نه میشود بدون نظارت دست یک مدل زبانی داد. این همان حالت میانه است: عنوان و ویژگی و توضیحِ تولیدشده در صف میماند تا یک آدم تأییدشان کند، کنار کنترلهایی که اجرای این کار روی فروشگاه زنده را قابل دفاع میکنند.
مسئله تجاری
عنوانهای کاتالوگ ناهماهنگ بود، توضیحها نازک، و دادهی ویژگیها بسته به اینکه چه کسی واردشان کرده فرق میکرد. تولید متن بهتر بخش آسان ماجراست. سختش هر چیزی است که دور آن میچرخد: اینکه خرج فراخوانهای API از کنترل خارج نشود، یک جاب دوبار اجرا نشود، چیزی بدون اینکه آدمی خوانده باشدش روی صفحهی محصول زنده نوشته نشود، و بعداً بشود گفت چه چیزی عوض شد و به دست چه کسی.
آنچه تحویل دادم
- a2-seo-ai، یک افزونهی ماژولار وردپرس با یک دروازهی بازبینی انسانی صریح بین تولید و انتشار.
- دو نقش اختصاصی، مدیر سئو و بازبین، با چهار دسترسی جدا برای تنظیمات، تأیید، دیدن لاگ و اجرای جاب؛ تولید و تأیید هیچوقت یک دسترسی نیستند.
- یک گارد بودجه که سقف خرج API را میبندد، چون حلقهی بیکران روی یک API پولی مهمترین حالت شکست اینجاست.
- یک قفل جاب و یک لایهی idempotency، تا اجرای دوباره یا همپوشان نتواند یک محصول را دوبار پردازش کند.
- ذخیرهسازی رمزنگاریشده برای کلید API؛ اگر ثابتی تعریف شده باشد، کلید از آن خوانده میشود نه از دیتابیس.
- یک ابزار یکپارچگی با رنکمث، تا متادیتای تولیدشده در همان فیلدهایی ذخیره شود که افزونهی سئوی سایت واقعاً میخواند.
- یک مجموعه تست برای بخشهایی که با نگاهکردن به کد نمیشود درستیشان را فهمید: قفل جاب، زمانبندی، گردش بازبینی، idempotency و فعالسازی.
رویکرد فنی
- هیچچیز بدون عبور از دروازهی بازبینی روی محصول نوشته نمیشود. این محدودیت اول آمد و معماری دور همان ساخته شد، نه اینکه بعداً اضافه شود.
- دسترسی تأیید از دسترسی تولید جداست؛ یعنی کسی که میتواند یک دسته را اجرا کند، نمیتواند منتشرش هم بکند. همین کنترل است که واگذاری کل این کار را بیخطر میکند.
- گارد بودجه و قفل جاب هستند چون دو فاجعهی واقعبینانه همین دوتاست: خرجی که از کنترل خارج شود و دستهای که دوبار اجرا شود. جلوگیری از هر دو ارزان است و کشفشان بعد از وقوع گران.
- جابها و وضعیتشان در جدولهای خود افزونه ذخیره میشوند. هر اجرا قابل بازرسی و ازسرگیری است، نه یک تسک زمانبندیشده که اجرا میشود و فراموش.
- تستها مشخصاً منطق همزمانی و idempotency را هدف گرفتهاند، چون همین مسیرها در بازبینی کد درست بهنظر میرسند و زیر زمانبندی واقعی میشکنند.
نتیجه و شواهد
کاتالوگ با سرعتی بهتر میشود که یک تیم کوچک واقعاً از پس بازبینیاش برمیآید، و سابقهای میماند از اینکه چه تولید شد، چه تأیید شد و به دست چه کسی. دروازه هم بهاندازهی خود تولید بخشی از تحویل است.
اهمیت برای کارفرما
بیشتر ابزارهای محتوای هوش مصنوعی روی توان عملیاتی بهینه شدهاند. روی یک کاتالوگ فروشگاهی، محدودیت اصلی اعتماد است. گردش کاری که صاحب فروشگاه حاضر است روشن نگهش دارد، از گردش کاری که سریعتر متن بیشتری تولید میکند ارزش بیشتری دارد.
خلاصه اجرایی خوانا
خلاصه_اجرایی {
پروژه: "Product Specification Workflow"
افزونه: "a2-seo-ai (ماژولار، ووکامرس + رنکمث)"
دروازه: "تولید هیچوقت نمینویسد؛ یک بازبین تأیید میکند"
نقشها: "مدیر سئو، بازبین"
دسترسیها: "مدیریت تنظیمات، تأیید محتوا، دیدن لاگ، اجرای جاب"
گاردها: "گارد بودجه، قفل جاب، لایهی idempotency"
رازها: "رمزنگاریشده در حالت سکون؛ ثابت بر دیتابیس اولویت دارد"
تستها: "قفل جاب، زمانبند، گردش بازبینی، idempotency"
}ارزش حرفهای این پروژه
اگر قرار باشد جایی را به بازبین نشان بدهم، تفکیک دسترسیها و گارد بودجه است، نه مهندسی پرامپت. همین دوتا تعیین میکنند که این چیز روی فروشگاه زنده قابل اجراست یا نه.
اینکه تست را برای قفل جاب و idempotency نوشتم و نه برای متن تولیدشده، انتخابی عمدی بود دربارهی اینکه ریسک واقعی کجاست.