برای ویرایش دسته‌جمعی ویژگی‌های سند، به یک عامل هوش مصنوعی یک استاندارد و یک پوشه بدهید و اجازه دهید از طریق GroupDocs.Metadata.Mcp که به‌صورت محلی اجرا می‌شود، بخواند، بنویسد و تأیید کند. یک درخواست کافی است تا شروع کنید:

برای هر سند در پوشه‌ام، مقدار Company را به «Acme Ltd» و Author را به «Research Team» تنظیم کنید، سپس به من بگویید کدام فایل‌ها را تغییر دادید.

نسخه گام‌به‌گام با پیکربندی و عیب‌یابی در مستندات موجود است: چگونه ویژگی‌های سند را به‌صورت دسته‌جمعی با یک عامل هوش مصنوعی اصلاح کنیم.

چرا استانداردهای متادیتا در ابتدا دچار انحراف می‌شوند؟

قالب‌ها شرکت قبلی را در هر فایل جدید می‌گذارند. تغییر نام تیم، نام قدیمی را در فیلد نویسنده باقی می‌گذارد. یک مهاجرت زمان‌مهرهایی می‌گذارد که معنایی ندارند. هیچ‌کس به‌صورت دستی ویژگی‌ها را در ۲۰۰ فایل ویرایش نمی‌کند، بنابراین انحراف باقی می‌ماند. یک عامل با حلقه ابزار مناسب برای این کار است، اما فقط اگر ویرایش توسط یک موتور انجام شود: یک مدل زبانی که «سند را بازنویسی» می‌کند تا نویسنده‌اش را تغییر دهد، محتوا را بازتولید می‌کند، در حالی که write_metadata فقط یک فیلد را تغییر می‌دهد و بدنه را دست‌نخورده می‌گذارد.

جریان کار چیست؟

جریان کار چهار مرحله دارد و هر مرحله یک درخواست دارد. آن را در Claude Desktop، Claude Code، Cursor، GitHub Copilot یا هر مشتری دیگری که سرور را ثبت کرده است، اجرا کنید.

  1. بررسی مجوز. بپرسید: «وضعیت مجوز سرور متادیتا چیست؟» عامل get_license_status را فراخوانی می‌کند. این کار را قبل از اجرای دسته‌جمعی انجام دهید، نه بعد.
  2. خواندن مقادیر فعلی. بپرسید: «ابتدا Author و Company فعلی هر فایل را فهرست کنید.» عامل search_metadata را با nameContains فراخوانی می‌کند که فقط ویژگی‌های منطبق را برمی‌گرداند.
  3. نوشتن فقط موارد نادرست. بپرسید: «فقط مواردی که اشتباه هستند را تغییر بدهید.» عامل write_metadata را برای هر فایل و هر ویژگی فراخوانی می‌کند.
  4. تأیید. بپرسید: «Author و Company را دوباره در فایل‌های جدید بخوانید و هر موردی که هنوز متفاوت است را به همراه دلیلش فهرست کنید.» به‌جای شمارش، فهرست خطاها را درخواست کنید.

چه کسی تصمیم می‌گیرد: عامل یا موتور؟

تصمیم توسط
کدام فایل‌ها در محدوده هستند و کدام مقادیر اشتباه هستند عامل، بر اساس استاندارد شما
کدام نام ویژگی به کدام فیلد در PDF، DOCX یا JPEG نگاشت می‌شود موتور: write_metadata نام کاربرپسند را بر حسب فرمت نگاشت می‌کند
آیا یک ویژگی در یک فرمت وجود دارد موتور: نوشتنی که اعمال نمی‌شود، 0 تغییر گزارش می‌دهد یا با پیامی شکست می‌خورد، هرگز موفقیت ساکت نیست
چه چیزی ذخیره شد و کجا ابزار: پیام مسیر ذخیره‌شده و تعداد فیلدهای تغییر یافته را برمی‌گرداند
آیا وضعیت نهایی با استاندارد مطابقت دارد عامل، با خواندن مجدد

write_metadata property را به‌عنوان یکی از Author، Title، Subject، Keywords، Comments، Copyright، Company یا Manager می‌پذیرد. mode می‌تواند set (جایگزینی، پیش‌فرض) یا add (افزودن، برای فیلدهای لیستی مانند Keywords) باشد.

قاعده‌ای که هر ویرایشی را حفظ می‌کند چیست؟

write_metadata در هر فراخوانی یک ویژگی را تنظیم می‌کند و یک فایل جدید ذخیره می‌نماید. دو ویژگی روی یک سند یعنی دو فراخوانی، و فراخوانی دوم باید بر روی نتیجهٔ اولین اعمال شود. اگر فراخوانی دوم از نسخهٔ اصلی شروع شود، ویرایش اول ناپدید می‌شود. وقتی عاملی گزارش می‌دهد که هر دو ویژگی تنظیم شده‌اند اما فقط یکی باقی مانده، این دلیل آن است. این قاعده را در درخواست بگویید:

تغییر دوم را بر روی فایلی که توسط تغییر اول تولید شده اعمال کنید، نه بر روی نسخهٔ اصلی.

جلسه نمونه (مختصر)

You:    Set Company to "Acme Ltd" on every .docx in the folder. List current values first.
Agent:  [calls search_metadata: nameContains = "Company", per file]
Agent:  proposal-q1.docx   Company = "Contoso GmbH"   -> will change
        handbook.docx      Company = "Acme Ltd"       -> already correct
        notes.docx         (no Company property)      -> will add
You:    Go ahead. Name each file you produced.
Agent:  [calls write_metadata: property = Company, value = "Acme Ltd", mode = set]
Agent:  2 files changed, 1 unchanged. Each saved copy is named in the tool reply.

این یک تصویر کلی از جریان است، نه یک اسکرین‌شات ضبط‌شده.

چرا کل پوشه را در یک عبور اصلاح نکنیم؟

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

فرمت‌ها متفاوت‌اند. ویژگی‌ای که فرمت جایی برای آن ندارد، به‌عنوان 0 تغییر گزارش می‌شود یا با پیامی شکست می‌خورد، نه اینکه به‌صورت موفقیت پنهان ظاهر شود؛ این رفتار صحیح است اما به این معنی است که یک پوشهٔ ترکیبی می‌تواند نتیجهٔ جزئی بدهد. خطاها را به‌صورت فهرست درخواست کنید.

محدودیت‌ها در حالت ارزیابی چیست؟

در حالت ارزیابی فقط ۵ ویژگی اول سند قابل خواندن هستند و XMP و EXIF تا حدی در دسترس نیستند. نوشتن نیز به همان شکل محدود است. یک جریان «بررسی، سپس نوشتن» در ارزیابی فهرست کوتاهی را بررسی می‌کند، بنابراین ممکن است ویژگی‌ای که می‌خواهید اصلاح کنید را از دست بدهد. با get_license_status تأیید کنید و قبل از اعتماد به نتایج، یک فایل مجوز یا کلیدهای متری را اعمال کنید. یک مجوز موقت رایگان ۳۰ روزه در دسترس است.

سوالات متداول

آیا می‌توانم نویسنده را در ۱۰۰ سند Word به‌صورت همزمان تغییر دهم؟
بله، با یک درخواست که پوشه و مقدار را نام‌گذاری می‌کند. عامل برای هر فایل یک فراخوانی write_metadata برای ویژگی Author انجام می‌دهد، بنابراین ۱۰۰ فایل یعنی ۱۰۰ فراخوانی نوشتن.

آیا عامل فایل‌های اصلی من را بازنویسی می‌کند؟
ابزار یک فایل جدید ذخیره می‌کند و مسیر آن را برمی‌گرداند، بنابراین خروجی فایل اصلی نیست. از عامل بخواهید نام هر فایلی که تولید کرده است را بگوید و تا زمانی که نسخه‌های جدید را تأیید نکرده‌اید، فایل‌های اصلی را نگه دارید.

آیا عامل می‌تواند یک ویژگی سفارشی که در فهرست نیست تنظیم کند؟
مقادیر مستند property شامل Author، Title، Subject، Keywords، Comments، Copyright، Company و Manager هستند. هر چیز دیگری خارج از آنچه ابزار توصیف می‌کند، است.

عمیق‌تر بروید